使用Bugzilla的步骤

使用Bugzilla的步骤

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

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

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

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

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