测试与改错(2)

　　尽管已经明白了测试的目的是为了发现尽可能多的缺陷，但当测试人员真的发现了一堆缺陷时，却不可乐颠颠地跑去恭喜那个倒霉的开发者，否则会打架的。

　　7.1.3 测试的真理

　　测试只能证明缺陷存在，而不能证明缺陷不存在。

　　这个真理告诉我们，对于一个复杂的系统而言，无论采取什么样的测试手段都不能证明缺陷已经不复存在。“彻底地测试”只是一种理想。在实践中，测试要考虑时间、费用等限制，不允许无休止地测试。

　　7.1.4 测试与质量的关系

　　测试有助于提高软件的质量，但是提高软件的质量不能依赖于测试。测试与质量的关系很象在考试中“检查”与“成绩”的关系。

　　学习好的学生，在考试时通过认真检查能减少因疏忽而造成的答题错误，从而“提高”了考试成绩(取得他本来就该得的好成绩)。

　　而学习差的学生，他原本就不会做题目，无论检查多么细心，也不能提高成绩。

　　所以说，软件的高质量是设计出来的，而不是靠测试修补出来的。

　　7.2 测试人员的选择

　　测试需要开发人员参与吗?

　　测试需要独立的测试小组吗?

　　测试需要用户参与吗?

　　让我们先看一看Microsoft公司关于测试的经验教训，再回答上述问题。

　　7.2.1 Microsoft公司的经验教训

　　在80年代初期，Microsoft公司的许多软件产品出现了“Bug”。比如，在1981年与IBM PC机一起推出的BASIC软件，用户在用“.1”(或者其他数字)除以10时，就会出错。在FORTRAN软件中也存在破坏数据的“Bug”。由此激起了许多采用Microsoft操作系统的PC厂商的极大不满，而且很多个人用户也纷纷投诉。

　　Microsoft公司的经理们发觉很有必要引进更好的内部测试与质量控制方法。但是遭到很多程序设计师甚至一些高级经理的坚决反对，他们固执地认为在高校学生、秘书或者外界合作人士的协助下，开发人员可以自己测试产品。在1984年推出Mac机的Multiplan(电子表格软件)之前，Microsoft曾特地请Arthur Anderson咨询公司进行测试。但是外界公司一般没有能力执行全面的软件测试。结果，一种相当厉害的破环数据的“Bug”迫使Microsoft公司为它的2万多名用户免费提供更新版本，代价是每个版本10美元，一共化了20万美元，可谓损失惨重。

　　痛定思痛后，Microsoft公司的经理们得出一个结论：如果再不成立独立的测试部门，软件产品就不可能达到更高的质量标准。IBM和其它有着成功的软件开发历史的公司便是效法的榜样。但Microsoft公司并不照搬IBM的经验，而是有选择地采用了一些看起来比较先进的方法，如独立的测试小组，自动测试以及为关键性的构件进行代码复查等。Microsoft公司的一位开发部门主管戴夫·穆尔回忆说：“我们清楚不能再让开发部门自己测试了。我们需要有一个单独的小组来设计测试，运行测试，并把测试信息反馈给开发部门。这是一个伟大的转折点。”

　　但是有了独立的测试小组后，并不等于万事大吉了。自从Microsoft公司在1984年与1986年之间扩大了测试小组后，开发人员开始“变懒”了。他们把代码扔在一边等着测试，忘了唯有开发人员自己才能阻止错误的发生、防患于未来。此时，Microsoft公司历史上第二次大灾难降临了。原定于1986年7月发行的Mac机的Word 3.0，千呼万唤方于1987年2月问世。这套软件竟然有700多处错误，有的错误可以破坏数据甚至摧毁程序。一下子就使Microsoft名声扫地。公司不得不为用户免费提供升级版本，费用超过了100万美元。[Cusumano 1995]

　　7.2.2 测试人员的分工

　　从Microsoft公司的教训中可知，公司内部对产品的测试(称为α测试)，需要开发人员与独立的测试小组共同参与。开发人员应该执行“白盒”测试，即测试源程序的逻辑结构以及实现细节(“白盒”是指看得见程序的内部结构)。而独立测试小组应该执行“黑盒”测试，即按照规格说明来测试程序是否符合要求(“黑盒”是指看不见程序的内部结构)。比如在测试一个模块时，“白盒”测试方法要对模块的所有代码进行单步跟踪测试。而 “黑盒”测试方法只需测试模块的接口是否符合要求，它关心程序的外部表现而不是内部的实现细节。

　　小型的软件公司可能没有条件设立独立的测试小组，也有可能测试小组人员不多而忙不过来。这时，可以让开发小组的成员相互测试对方的程序。

原文转自：http://www.uml.org.cn/Test/200608303.htm