使用Bugzilla的步骤

没有测试用例的代码不用写，因为写了也白写，因为不知道是否已经实现了。这句话跟我们常说的“眼见为实”很类似，除非我能验证，否则我不知道你是否已经完成了这个功能。

软件的一个特点就是太抽象，不可捉摸，也很难衡量。这又让我想起了一个东西，那就是“黑洞”。你是看不见黑洞的，人们之所以知道它的存在，是通过它周围的物理现象推导出来的。也就是说，有些东西，你是无法直接感知的，它只有通过别的事物表现出来，你才能认识到它。自然科学基本就是建立在这个基础之上的，所以我们有各种各种的科学仪器，以及各种度量衡来感知和描述我们所认识的世界！

所以，对于一个软件，我们也需要一个度量工具。但是不像实体的物质那样，软件的性质并不能从外观上看出来。所以，衡量一个软件，就像我们在认识一个新事物的时候一样，需要不断的尝试。就像盲人摸象，你需要从不同的角度去感知它，然后拼凑出一个整体的模型，当然不免有以偏概全的时候，但是只要数据足够多，还是可以比较准确地描述出新事物的真实面目的。而对于物理外形的软件，为了了解它的属性，我们只能通过研究其对外界的输入而产生的输出进行了解。足够多的输入和足够多的输出，我们就可以建立一个基本的软件的模型，即输入输出模型，这就是这个软件的对外表现。就像我们轰击原子核，从而发现质子一样，我们也许要对软件进行轰击。

当然了，对于软件，我们还是可以预测其对输入的输出情况的，这就是软件设计的功能。所以，为了知道软件是否实现了特定功能，我们只要把我们需要的输入数据输入，在检测软件的输出，看看是否符合预期就知道其是否达到了预期的目的了。当然了，我们不能穷尽所有的输入和输出，只能采用归纳统计来推算。这也是自然科学的原理，从反复出现的现象中总结规律，再用现实的数据对规律进行验证，多次由多人在不同的条件下如果都验证通过了，就说明这真的是规律了，至少在目前看来......我们不能否认这些所谓的规律完全是偶然，也许真的是偶然，谁知道呢！我们永远不知道世界的真相，我们只能不断的猜测.......得到相对的真理。

说了这么多，就是想说，测试用例很重要。没有测试用例，你就不知道你写的代码是否真的完成了。所以，我建议，把每个测试用例都当作一个Bug写入Bugzilla里，进行跟踪。一开始，所有的Bug肯定都是打开的，随着开发的进行，用例就会一个个的通过，Bug也就一个个的关闭，等到所有的Bug都关闭了，开发也算结束了----所以，开发什么结束？等所有的测试用例通过的时候！这就是TDD--测试驱动开发。所以，如果你对某个功能在某种情形下的行为不放心，请把这个担忧写成一个测试用例，甚至是代码，从而确保这个情况会被测试，如果通不过，你会知道！