系统测试与调试.docx

系统测试与调试.docx

《系统测试与调试.docx》由会员分享，可在线阅读，更多相关《系统测试与调试.docx（10页珍藏版）》请在冰点文库上搜索。

系统测试与调试

3.4系统测试与调试

系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试。

测试的目的就是希望能以最少的人力和时间发现潜在的各种错误和缺陷。

应根据开发各阶段的需求、设计等文档或程序的内部结构精心设计测试实例，并利用这些实例来运行程序，以便发现错误的过程。

信息系统测试应包括软件测试、硬件测试和网络测试。

3.4.1测试人员的选择

测试是一个综合的过程，需要开发人员参与、需要独立的测试小组、还需要用户参与。

下面通过Microsoft公司的案例来说明关于测试的经验教训。

1.Microsoft公司的案例

在80年代初期，Microsoft公司的许多软件产品出现了“Bug”。

比如，在1981年与IBMPC机一起推出的BASIC软件，用户在用“.1”（或者其他数字）除以10时，就会出错。

在FORTRAN软件中也存在破坏数据的“Bug”。

由此激起了许多采用Microsoft操作系统的PC厂商的极大不满，而且很多个人用户也纷纷投诉。

Microsoft公司的经理们发觉很有必要引进更好的内部测试与质量控制方法。

但是遭到很多程序设计师甚至一些高级经理的坚决反对，他们固执地认为在高校学生、秘书或者外界合作人士的协助下，开发人员可以自己测试产品。

在1984年推出Mac机的Multiplan（电子表格软件）之前，Microsoft曾特地请ArthurAnderson咨询公司进行测试。

但是外界公司一般没有能力执行全面的软件测试。

结果，一种相当厉害的破环数据的“Bug”迫使Microsoft公司为它的２万多名用户免费提供更新版本，代价是每个版本10美元，一共化了20万美元，可谓损失惨重。

痛定思痛后，Microsoft公司的经理们得出一个结论：

如果再不成立独立的测试部门，软件产品就不可能达到更高的质量标准。

IBM和其它有着成功的软件开发历史的公司便是效法的榜样。

但Microsoft公司并不照搬IBM的经验，而是有选择地采用了一些看起来比较先进的方法，如独立的测试小组，自动测试以及为关键性的构件进行代码复查等。

Microsoft公司的一位开发部门主管戴夫·穆尔回忆说：

“我们清楚不能再让开发部门自己测试了。

我们需要有一个单独的小组来设计测试，运行测试，并把测试信息反馈给开发部门。

这是一个伟大的转折点。

”

但是有了独立的测试小组后，并不等于万事大吉了。

自从Microsoft公司在1984年与1986年之间扩大了测试小组后，开发人员开始“变懒”了。

他们把代码扔在一边等着测试，忘了唯有开发人员自己才能阻止错误的发生、防患于未来。

此时，Microsoft公司历史上第二次大灾难降临了。

原定于1986年７月发行的Mac机的Word3.0，千呼万唤方于1987年2月问世。

这套软件竟然有700多处错误，有的错误可以破坏数据甚至摧毁程序。

一下子就使Microsoft名声扫地。

公司不得不为用户免费提供升级版本，费用超过了100万美元。

2.测试人员的分工

从Microsoft公司的教训中可知，公司内部对产品的测试（称为α测试），需要开发人员与独立的测试小组共同参与。

开发人员应该执行“白盒”测试，即测试源程序的逻辑结构以及实现细节（“白盒”是指看得见程序的内部结构）。

而独立测试小组应该执行“黑盒”测试，即按照规格说明来测试程序是否符合要求（“黑盒”是指看不见程序的内部结构）。

比如在测试一个模块时，“白盒”测试方法要对模块的所有代码进行单步跟踪测试。

而“黑盒”测试方法只需测试模块的接口是否符合要求，它关心程序的外部表现而不是内部的实现细节。

小型的软件公司可能没有条件设立独立的测试小组，也有可能测试小组人员不多而忙不过来。

这时，可以让开发小组的成员相互测试对方的程序。

这里要强调的是，α测试不能依赖于开发人员或者测试小组中的任意一方，必须是双方共同参与。

“白盒测试”必须由开发者自己执行，因为别的测试人员无法了解到程序的内部实现细节。

而“黑盒测试”必须由独立的测试人员执行，因为开发者难以做到客观、公正。

开发者在测试自己的程序时存在一些弊病：

（1）开发者对自己的程序印象深刻，并总以为是正确的（自信是应该的）。

倘若在设计时就存在理解错误，或因不良的编程习惯而流下隐患，那么他本人很难发现这类错误。

（2）开发者对程序的功能、接口十分熟悉，他自己几乎不可能因为使用不当而引发错误，这与大众用户的情况不太相似，所以自己测试程序难以具备典型性。

（3）程序设计有如艺术设计，开发者总是喜欢欣赏程序的成功之处，而不愿看到失败之处。

让开发者去做“蓄意破坏”的测试，就象杀自己的孩子一样难以接受。

即便开发者非常诚实，但“珍爱程序”的心理让他在测试时不知不觉地带入了虚假成份。

软件产品正式发行前，在公司外部邀请一些用户对产品进行测试，称为β测试。

β测试的涉及面最广，最能反映用户的真实愿望，但花费的时间最长，不好控制。

一般地，软件公司与β测试人员之间有一种互利的协议。

即β测试人员无偿地为软件公司作测试，定期递交测试报告，提出批评与建议。

而软件公司将向β测试人员免费赠送或者以很大的优惠价格发行软件的正式版本。

3.4.2系统测试的常用方法

不论是对软件的模块还是整个系统，总有共同的内容要测试，如正确性测试，容错性测试，性能与效率测试，易用性测试，文档测试等。

“白盒测试”是指开发人员从程序内部对上述内容进行测试，而“黑盒测试”是指独立的测试人员从程序外部对上述内容进行测试。

很多软件工程教材讲述了各种各样的测试方法并例举了不少示例本节简明地讲述常用的系统测试方法。

1.正确性测试

正确性测试又称功能测试，它检查软件的功能是否符合规格说明。

由于正确性是软件最重要的质量因素，所以其测试也最重要。

基本的方法是构造一些合理输入，检查是否得到期望的输出。

这是一种枚举方法。

倘若枚举空间是无限的，那可惨了，还不如回家种土豆有盼头。

测试人员一定要设法减少枚举的次数，否则没好日子过。

关键在于寻找等价区间，因为在等价区间中，只需用任意值测试一次即可。

等价区间的概念可表述如下：

记（A,B）是命题f（x）的一个等价区间，在（A,B）中任意取x1进行测试。

如果f（x1）错误，那么f（x）在整个（A,B）区间都将出错。

如果f（x1）正确，那么f（x）在整个（A,B）区间都将正确。

上述测试方法称为等价测试，来源于人们的直觉与经验，可令测试事半功倍。

还有一种有效的测试方法是边界值测试。

即采用定义域或者等价区间的边界值进行测试。

因为程序员容易疏忽边界情况，程序也“喜欢”在边界值处出错。

例如测试

的一段程序。

凭直觉等价区间应是（0,1）和（1,+∞）。

可取x=0.5以及x=2.0进行等价测试。

再取x=0以及x=1进行边界值测试。

有一些复杂的程序，我们难以凭直觉与经验找到等价区间和边界值，这时枚举测试就相当有难度。

在用“白盒测试”方式进行正确性测试时，有个额外的好处：

如果测试发现了错误，测试者（开发人员）马上就能修改错误。

越早改正错误，付出的代价就越低。

所以大多数软件公司要求程序员在写完程序时，马上执行基于单步跟踪的“白盒测试”。

2.容错性测试

容错性测试是检查软件在异常条件下的行为。

容错性好的软件能确保系统不发生无法意料的事故。

比较温柔的容错性测试通常构造一些不合理的输入来引诱软件出错，例如：

（1）输入错误的数据类型，如“猴”年“马”月。

（2）输入定义域之外的数值。

3.性能与效率测试

性能与效率测试主要是测试软件的运行速度和对资源的利用率。

有时人们关心测试的“绝对值”，如数据送输速率是每秒多少比特。

有时人们关心测试的“相对值”，如某个软件比另一个软件快多少倍。

在获取测试的“绝对值”时，我们要充分考虑并记录运行环境对测试的影响。

例如计算机主频，总线结构和外部设备都可能影响软件的运行速度；若与多个计算机共享资源，软件运行可能慢得像蜗牛爬行。

在获取测试的“相对值”时，我们要确保被测试的几个软件运行于完全一致的环境中。

硬件环境的一致性比较容易做到（用同一台计算机即可）。

但软件环境的因素较多，除了操作系统，程序设计语言和编译系统对软件的性能也会产生较大的影响。

如果是比较几个算法的性能，就要求编程语言和编译器也完全一致。

性能与效率测试中很重要的一项是极限测试，因为很多软件系统会在极限测试中崩溃。

例如，连续不停地向服务器发请求，测试服务器是否会陷入死锁状态不能自拔；给程序输入特别大的数据，看看它是否吃得消。

4.易用性测试

易用性测试没有一个量化的指标，主观性较强。

调查表明，当用户不理解软件中的某个特性时，大多数人首先会向同事、朋友请教。

要是再不起作用，就向产品支持部门打电话。

只有30%的用户会查阅用户手册。

[Cusumano1995]

一般认为，如果用户不翻阅手册就能使用软件，那么表明这个软件具有较好的易用性。

5.文档测试

文档测试主要检查文档的正确性、完备性和可理解性。

好多人甚至不知道文档是软件的一个组成部分。

正确性是指不要把软件的功能和操作写错，也不允许文档内容前后矛盾。

完备性是指文档不可以“虎头蛇尾”，更不许漏掉关键内容。

有些学生在证明数学题时，喜欢用“显然”两字蒙混过关。

文档中很多内容对开发者可能是“显然”的，但对用户而言不见得都是“显然”的。

文档不可以写成散文、诗歌或者侦探、言情小说，要让大众用户看得懂，能理解。

很多程序员能编写出好程序，却写不出清晰的文档。

不要说自己以前语文学得差，现在已没救了，找借口不是办法。

没有人天生就能写出好程序，都是练出来的。

同理，若第一次写不好文档，就多写几次文档，慢慢地就会写出好文档来。

3.4.3调试

调试的任务就是根据测试时所发现的错误，找出原因和具体的位置，进行改正。

调试工作主要由程序开发人员来进行，最好是谁开发的程序就由谁来进行调试。

目前常用的调试方法有以下几种。

试探法。

调试人员分析错误的症状，猜测问题的所在位置，利用在程序中设置输出语句，分析寄存器、存储器的内容等手段来获得错误的线索，一步步地试探和分析出错误位置。

这种方法效率很低，适合于结构比较简单的程序。

回朔法。

调试人员从发现错误症状的位置开始，人工沿着程序的控制流程往回跟踪程序代码，直到找出错误根源为止。

这种方法适合于小型程序，对于大规模程序，由于其需要回朔的路径太多而变得不可操作。

对分查找法。

这种方法主要用来缩小错误的范围。

如果已经知道程序中的变量在若干位置的正确取值，可以在这些位置上给这些变量以正确值，运行程序观察输出结果，如果没有发现问题，则说明从赋值给变量开始到输出结果之间的程序没有出错，问题可能在除此之外的程序中，否则错误就在所考察的程序中。

然后对有错误的程序段再使用这种方法，直到把故障范围缩小到比较容易诊断为止。

归纳法。

归纳法就是从测试所暴露的问题出发，收集所有正确或不正确的数据，分析它们之间的关系，提出假设的错误原因，用这些数据来证明或反驳，从而查出错误所在。

演绎法。

根据测试结果，列出所有可能的错误原因。

分析已有的数据，排除不可能和彼此矛盾的原因。

对余下的原因，选择可能性最大的，利用已有的数据完善该假设，使假设更具体。

3.4.3测试流程图

软件测试流程图如图3-6所示，每个阶段的测试具体流程如图3-7、3-8、3-9所示。

图3-6软件测试流程图图3-7需求阶段测试流程图

图3-8设计和编码阶段测试流程图图3-9集成、系统、验收阶段测试流程图