系统测试与调试.docVIP

3.4 系统测试与调试 系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试。测试的目的就是希望能以最少的人力和时间发现潜在的各种错误和缺陷。应根据开发各阶段的需求、设计等文档或程序的内部结构精心设计测试实例，并利用这些实例来运行程序，以便发现错误的过程。信息系统测试应包括软件测试、硬件测试和网络测试。 3.4.1 测试人员的选择 测试是一个综合的过程，需要开发人员参与、需要独立的测试小组、还需要用户参与。下面通过Microsoft公司的案例来说明关于测试的经验教训。 1. Microsoft公司的案例 在80年代初期，Microsoft公司的许多软件产品出现了“Bug”。比如，在1981年与IBM PC机一起推出的BASIC软件，用户在用“.1”（或者其他数字）除以10时，就会出错。在FORTRAN软件中也存在破坏数据的“Bug”。由此激起了许多采用Microsoft操作系统的PC厂商的极大不满，而且很多个人用户也纷纷投诉。 Microsoft公司的经理们发觉很有必要引进更好的内部测试与质量控制方法。但是遭到很多程序设计师甚至一些高级经理的坚决反对，他们固执地认为在高校学生、秘书或者外界合作人士的协助下，开发人员可以自己测试产品。在1984年推出Mac机的Multiplan（电子表格软件）之前，Microsoft曾特地请Arthur Anderson咨询公司进行测试。但是外界公司一般没有能力执行全面的软件测试。结果，一种相当厉害的破环数据的“Bug”迫使Microsoft公司为它的２万多名用户免费提供更新版本，代价是每个版本10美元，一共化了20万美元，可谓损失惨重。 痛定思痛后，Microsoft公司的经理们得出一个结论：如果再不成立独立的测试部门，软件产品就不可能达到更高的质量标准。IBM和其它有着成功的软件开发历史的公司便是效法的榜样。但Microsoft公司并不照搬IBM的经验，而是有选择地采用了一些看起来比较先进的方法，如独立的测试小组，自动测试以及为关键性的构件进行代码复查等。Microsoft公司的一位开发部门主管戴夫·穆尔回忆说：“我们清楚不能再让开发部门自己测试了。我们需要有一个单独的小组来设计测试，运行测试，并把测试信息反馈给开发部门。这是一个伟大的转折点。” 但是有了独立的测试小组后，并不等于万事大吉了。自从Microsoft公司在1984年与1986年之间扩大了测试小组后，开发人员开始“变懒”了。他们把代码扔在一边等着测试，忘了唯有开发人员自己才能阻止错误的发生、防患于未来。此时，Microsoft公司历史上第二次大灾难降临了。原定于1986年７月发行的Mac机的Word 3.0，千呼万唤方于1987年2月问世。这套软件竟然有700多处错误，有的错误可以破坏数据甚至摧毁程序。一下子就使Microsoft名声扫地。公司不得不为用户免费提供升级版本，费用超过了100万美元。 2. 测试人员的分工 从Microsoft公司的教训中可知，公司内部对产品的测试（称为α测试），需要开发人员与独立的测试小组共同参与。开发人员应该执行“白盒”测试，即测试源程序的逻辑结构以及实现细节（“白盒”是指看得见程序的内部结构）。而独立测试小组应该执行“黑盒”测试，即按照规格说明来测试程序是否符合要求（“黑盒”是指看不见程序的内部结构）。比如在测试一个模块时，“白盒”测试方法要对模块的所有代码进行单步跟踪测试。而“黑盒”测试方法只需测试模块的接口是否符合要求，它关心程序的外部表现而不是内部的实现细节。 小型的软件公司可能没有条件设立独立的测试小组，也有可能测试小组人员不多而忙不过来。这时，可以让开发小组的成员相互测试对方的程序。 这里要强调的是，α测试不能依赖于开发人员或者测试小组中的任意一方，必须是双方共同参与。“白盒测试”必须由开发者自己执行，因为别的测试人员无法了解到程序的内部实现细节。而“黑盒测试”必须由独立的测试人员执行，因为开发者难以做到客观、公正。开发者在测试自己的程序时存在一些弊病： （1）开发者对自己的程序印象深刻，并总以为是正确的（自信是应该的）。倘若在设计时就存在理解错误，或因不良的编程习惯而流下隐患，那么他本人很难发现这类错误。 （2）开发者对程序的功能、接口十分熟悉，他自己几乎不可能因为使用不当而引发错误，这与大众用户的情况不太相似，所以自己测试程序难以具备典型性。 （3）程序设计有如艺术设计，开发者总是喜欢欣赏程序的成功之处，而不愿看到失败之处。让开发者去做“蓄意破坏”的测试，就象杀自己的孩子一样难以接受。即便开发者非常诚实，但“珍爱程序”的心理让他在测试时不知不觉地带入了虚假成份。 软件产品正式发行前，在公司外部邀请一些用户对产品进行测试，称为β测试。β测试的涉及