第-章-系统测试优秀文档

管理信息系统主讲邹凯博学笃行盛德日新7第7章系统测试了解系统测试的原则、方法、手段理解测试情况设计的几种基本方法掌握系统测试过程常见的测试类型掌握系统测试文档的结构及要求了解基本的测试工具第七章系统测试7.1系统测试概述7.2系统测试过程7.3系统测试文档7.4测试工具简介系统测试在系统开发过程中占有重要的地位。任何一个系统分析员，在系统分析和设计时都不可能把所有问题都考虑周到；任何一个程序员在系统实现时，总是或多或少地发生差错。然而对系统而言，不允许出现任何差错，所以测试是非常重要的。可以说，测试就是寻找“系统错误”，特别是寻找不经常出现的错误、隐藏着的错误。此外，还要对系统的容错、纠错能力等进行测试。第七章系统测试7.1系统测试概述7.1.1系统测试的原则7.1.2系统测试的方法7.1.3系统测试过程中应注意的问题7.1.4测试情况设计7.1系统测试概述著名软件测试专家迈尔斯（GrenfordJ.Myers）在《软件测试技巧》一书中，就系统测试目的提出以下观点：①测试是为了发现错误而执行程序的过程；②测试是为了证明程序有错，而不是证明程序无错误；③一个好的测试用例，在于能够发现至今未能发现的错误；④一个成功的测试是发现了至今未发现过的错误。7.1.1系统测试的原则根据测试目的，一般情况下应遵循的测试原则是：1）应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。不应把软件测试仅仅看作是软件开发的一个独立阶段，而应当把它贯穿到软件开发的各个阶段中。坚持在软件开发的各个阶段的技术评审,这样才能在开发过程中尽早发现和预防错误，把出现的错误克服在早期，杜绝某些发生错误的隐患。2）测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。测试以前应当根据测试的要求选择测试用例（Testcase），用来检验程序员编制的程序，因此不但需要测试的输入数据，而且需要针对这些输入数据的预期输出结果。7.1.1系统测试的原则3）程序员应避免测试自己的程序。程序员应尽可能避免测试自己编写的程序，程序开发小组也应尽可能避免测试本小组开发的程序。如果条件允许，最好建立独立的软件测试小组或测试机构。这点不能与程序的调试（debuging）相混淆。调试由程序员自己来做更有效。4）在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。合理的输入条件是指能验证程序正确的输入条件，不合理的输入条件是指异常的、临界的，可能引起问题异变的输入条件。软件系统处理非法命令的能力必须在测试时受到检验。用不合理的输入条件测试程序时，往往比用合理的输入条件进行测试能发现更多的错误。7.1.1系统测试的原则5）充分注意测试中的群集现象。在被测程序段中，若发现错误数目多，则残存错误数目也比较多。这种错误群集性现象，已为许多程序的测试实践所证实。根据这个规律，应当对错误群集的程序段进行重点测试，以提高测试投资的效益。6）严格执行测试计划，排除测试的随意性。测试之前应仔细考虑测试的项目，对每一项测试做出周密的计划，包括被测程序的功能、输入和输出、测试内容、进度安排、资源要求等。7.1.1系统测试的原则7）应当对每一个测试结果做全面检查。有些错误的征兆在输出实测结果时已经明显地出现了，但是如果不仔细地全面地检查测试结果，就会使这些错误被遗漏掉。8）妥善保存测试计划，测试用例，出错统计和最终分析报告。按照测试计划要求，将所有测试过程进行详细记录，并将测试文档资料完整保存，以便在以后的系统维护中查阅。7.1.2系统测试的方法按照迈尔斯的定义，测试是一个执行程序的过程，即要求被测程序在机器上运行。其实，不执行程序也可以发现程序的错误。为便于区分，一般把前者称为“动态测试”，后者称为“静态分析”。广义地说，它们都属于程序测试，测试的方法分类见图7.1。

7.1.2系统测试的方法图7.1测试的方法分类程序

测试

静态分析

（程序不执行）

动态测试（程序执行）静态分析器分析

（自动方式）代码评审

（人工方式）

黑盒测试（测试程序功能）

白盒测试（测试程序结构）代码会审代码走查

桌面检查

1.静态分析

顾名思义，静态分析就是通过对被测程序的静态审查，发现代码中潜在的错误。这种方法的主要特性是不利用计算机运行被测试的程序，而是采用其他手段达到检测的目的。它一般用人工方式完成，故亦称人工测试或代码评审；也可借助于静态分析器在机器上以自动方式进行检查，但不要求程序本身在机器上运行。

代码审查一般按代码审查单阅读程序，查找错误。内容包括：检查代码和设计的一致性；检查代码的标准性、可读性；检查代码逻辑表达的正确性和完整性；检查代码结构的合理性等。按照评审的不同组织形式，代码评审又可区分为代码会审、走查和桌面检查三种。对某个具体的程序，通常使用一种或一种以上评审方式进行综合评审。2.动态测试动态测试是实际运行被测程序，输入相应的测试用例，判定执行结果是否符合要求，从而检验程序的正确性、可靠性和有效性。动态测试可分为两类：一类把被测程序看成一个黑盒，根据程序的功能来设计测试用例，称为黑盒测试；另一类则根据被测程序的内部结构设计测试用例，测试者需事先了解被测程序的结构，故称为白盒测试。7.1.2系统测试的方法①黑盒测试。黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否能按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边界分析、因果图、猜测错误等，主要用于软件确认测试。7.1.2系统测试的方法②白盒测试。白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作的过程，可通过测试来检测程序内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等7.1.2系统测试的方法白盒测试需全面了解程序内部逻辑结构，对所有逻辑路径进行测试，是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数有时是天文数字，但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序；第二，穷举路径测试不可能查出程序中因遗漏路径而出错；第三，穷举路径测试可能发现不了一些与数据相关的错误。7.1.2系统测试的方法2）α测试和β测试如果软件是为多个客户开发，那么由每个客户都实施正式的验收测试是不现实的。大多数软件产品的开发人员采用所谓α测试和β测试的步骤，以便让最终用户快速找出错误。α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。被测试的软件由开发人员安排在可控的环境下进行检验，并记录发现的错误和使用中的问题。7.1.2系统测试的方法β测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。与α测试不同的是，开发者通常不在测试现场。因而，β测试是在开发者无法控制的环境下进行的软件现场应用。在β测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告，开发者在综合用户的报告之后，做出修改，最后将软件产品交付给全体用户使用。

7.1.3系统测试过程中应注意的的问题

在测试过程中一般把发现的错误bug按其严重性大致分为4类：致命错误（系统崩溃或挂起、破坏数据）、严重错误（使系统不稳定、产生错误结果、菜单功能无法实现）、一般错误（在完成某一功能时出现的错误，但并不影响该功能的实现）、建议项

（软件不完善或用户使用不方便之处）。7.1.3系统测试过程中应注意的的问题下面，对一些显而易见的、容易被开发者忽略的错误进行列举和分析，这些错误一般很容易避免和修改，但会给用户造成使用上的困难。1）易用性问题：用户无法使用或不方便使用

①不符合用户操作习惯。如：快捷键定义不科学、不实用，键位分布不合理、按键太多，甚至没有快捷键。

②界面中英文混杂，界面元素参差不齐，文字显示不全。③无自动安装程序或安装程序不完善。④界面中的信息不能及时刷新，不能正确反映当前数据状态，可能误导用户。如：数据库中剩余记录个数和参数设置对话框中的预设值常常显示为历史值而不是当前值。7.1.3系统测试过程中应注意的的问题⑤提示信息意义不明或为原始的英文提示。⑥要求用户输入多余的、本来系统可以自己得到的数据。如：服务是否启动，安装后用户要手动修改某些配置文件。⑦某一项功能的冗余操作太多。如：对话框嵌套层次太多。⑧不能记忆用户的设置或操作习惯，用户每次进入都需要重新操作一次初始环境。⑨对复杂的操作无联机帮助。④界面中的信息不能及时刷新，不能正确反映当前数据状态，可能误导用户。QALoad是客户/服务器系统、企业资源配置（ERP）和电子商务应用的自动化负载测试工具，它通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能。版本跟踪的目的是便于对版本加以区分、检索和跟踪，以表明各个版本之间的关系。①程序运行过程中不断申请但不完全释放资源，造成系统性能越来越低，并出现不规律的死机现象。无疑这是比手工编制更高效、更先进的方法。又如，新的软件系统中的一些文件名和计算机系统中别的软件系统中的一些文件完全同名时，两种软件系统之间如何实现相互协调操作。①各模块是否无错误地连接；逻辑覆盖是对一系列测试过程的总称，它是在使用白盒测试法时，选用测试用例执行（即这里所说的覆盖）程序逻辑路径的方法。Myers）在《软件测试技巧》一书中，就系统测试目的提出以下观点：⑤可以进行回归测试（即重新再做所有的或者部分已做过的测试），以保证不引入新的错误。②提高用户对软件开发的认识。6、什么是测试用例？简述测试用例在系统测试中的作用和地位。②需要编写一个驱动程序作为测试的控制程序，用来协调测试用例的输入和输出；测试文件的编写是测试工作规范化的一个重要组成部分。设计用例，使得判断中的每个条件的所有可能结果至少出现一次，而且判断本身所有可能结果也至少出现一次；例如，数据穿过模块接口时可能丢失；7.1.3系统测试过程中应注意的的问题2）稳定性问题：影响用户正常工作①程序运行过程中不断申请但不完全释放资源，造成系统性能越来越低，并出现不规律的死机现象。②不能重现的错误，有些与代码中的未初始化变量有关，有些与系统不检查异常情况有关。③对一般性错误的屏蔽能力较差。④对输入的数据没有进行充分并且有效的有效性检查，造成不合要求的数据进入数据库。7.1.3系统测试过程中应注意的的问题3）其他问题①用户文档问题：无标准，无新功能使用方法，无版本改动说明。不仅要认为没有说明文档的产品不是一个完整的产品，也要认为没有说明或没有正确说明的功能是一个没有完全实现的功能，因为用户无法用得起来。②兼容性问题：对硬件平台或软件平台的兼容性不好。比如：在这台计算机上可以稳定运行，而在另一台上运行就极不稳定。③数据接口问题：未提供与一些常用的文件格式的接口。如TXT文件、Word文件7.1.4测试情况设计测试是不存在错误的证明，尽管有些软件经过“精心测试”，但运行后还是不可靠。正如迪杰斯特拉（EdsgerW.Dijkstra）所述“测试可能是一种表明存在错误的有效途径，但无法表明不存在错误”。意思就是，如果一个软件用测试数据运行时输出发生错误，则该软件必然存在着错误；但如果输出是正确的，软件可能仍然存在错误；特定的测试只能显示软件在这套特定的测试数据下能正确运行。7.1.4测试情况设计因此，在测试过程中，无论是采用人工测试还是计算机辅助测试，其中最重要的问题就是设计有效的测试情况，常用的的测试情况设计方法有：逻辑覆盖、等价划分、边界分析、因果图和猜测错误等。其中逻辑覆盖测试是白盒测试方法，其余是黑盒测试方法。

7.1.4测试情况设计1）逻辑覆盖逻辑覆盖是对一系列测试过程的总称，它是在使用白盒测试法时，选用测试用例执行（即这里所说的覆盖）程序逻辑路径的方法。覆盖程度由低到高大致分为以下几类：①语句覆盖。设计若干测试用例，使程序中每一可执行语句至少执行一次；②判断覆盖。设计用例，使程序中的每个逻辑判断的取真取假分支至少经历一次；③条件覆盖。设计用例，使判断中的每个条件的可能取值至少满足一次；1）逻辑覆盖④判断/条件覆盖。设计用例，使得判断中的每个条件的所有可能结果至少出现一次，而且判断本身所有可能结果也至少出现一次；⑤条件组合覆盖。设计用例，使得每个判断表达式中条件的各种可能组合都至少出现一次；显然，满足⑤的测试用例也一定是满足②、③、④的测试用例。⑥路径覆盖。设计足够的测试用例，使程序的每条可能路径都至少执行一次。⑦如果把路径覆盖和条件组合覆盖结合起来，可以设计出检错能力更强的测试数据用例。7.1.4测试情况设计2）等价类划分等价类划分是用黑盒测试法设计测试用例的一种技术。它是将程序（或者模块）输入定义域中的所有可能的输入数据（含有效和无效）划分成若干个等价类，每一类的一个代表性的数据在测试中的作用，就等价于这一类中的所有其他数据。也就是说，如果某一类的一个用例发现了错误，这一等价类中的所有其他用例也能发现同样的错误，反之亦然。借以实现测试的经济性，大大减少测试的工作量。【例7.1】某工厂公开招工，规定报名者年龄应在20周岁至39周岁之间（到1999年6月30日止），即出生年月不早于1960年7月，不晚于1979年6月。报名程序具有自动检验输入数据的功能。如出生年月不在上述范围内，将拒绝接受，并显示“年龄不合格”等出错信息。试用等价分类法设计对这一程序功能的测试用例。第一步：划分等价类。假定已知出生年月由6位数字字符表示，前4位代表年，后2位代表月，则可以划分为3个有效等价类，7个无效等价类，如表7-1所示。输入数据有效等价类无效等价类出生年月①6位数字字符②有非数字字符③少于6个数字符④多于6个数字符对应数值⑤在196007-197906之间⑥<196007⑦>197906月份对应数值⑧在1-12之间⑨等于“0”⑩>127.1.4测试情况设计第二步：设计有效等价类需要的测试用例。表7-1中的①、⑤、⑧等３个有效等价类，可以公用一个测试用例，例如：测试数据期望结果

测试范围197011输入有效①、⑤、⑧7.1.4测试情况设计第三步：为每一无效等价类至少设计一个测试用例。本例具有７个无效等价类，需要不少于７个测试用例。例如

测试数据期望结果

测试范围MAY,70输入无效②19705输入无效③1968011输入无效④195512年龄不合格⑥196006年龄不合格⑦196200输入无效⑨197222输入无效⑩7.1.4测试情况设计让几个有效等价类公用一个测试用例，可以减少测试次数，有利而无弊；但若几个无效等价类合用一个测试用例，就可能使错误漏检测。就上例而言，假定把“195512”（对应无效等价类程序显示出“年龄不合格”处仍不能证明程序对月份为“00”的输入数据也具有识别和拒绝接受的功能。再进一步讲，其实在第一步“划分等价类”时，就应防止有意或无意地将几个独立的无效等价类写成一个无效等价类。例如，若在上例中把⑨、⑩两个无效等价类合并写成“末２位的对应值为0或>12”，则与之相应的测试用例也将从原来的２个减为１个，对程序的测试就不够完全了。7.1.4测试情况设计3）边界分析经验表明，程序在处理边缘情况时常会出现错误，例如，许多程序错误出现在数组下标，数据结构和循环等等的边界附近。因此，设计检查边界值的测试用例暴露程序错误的可能性会更大。所谓边界条件，是相对于输入情形输出等价类直接在其边缘上，稍高于其边界和低于其边界的这些状态条件。7.1.4测试情况设计使用边界值分析方法设计测试用例，通常输入等价类和输出等价类的边界值，选取刚好等于、稍小于、稍大于等价类边界值的数据作为测试用例。

边界分析法与等价类法有两方面区别：①边界分析不是从某个等价中随便挑一个作为代表，而是选出一个或几个元素，使得这个等价类的每个边界都要作为测试对象。②边界分析不仅根据输入条件，还要根据输出的情况（按输出等价类）设计测试用例。7.1.4测试情况设计4）因果图因果图法也是较常用的一种黑盒测试技术。因果图是一种简化了的逻辑图。当被测程序具有多种输入条件，程序的输出又依赖于输入条件的各种组合时，用因果图直观地表明输入条件和输出动作之间的因果关系，能帮助测试人员把注意力集中到与程序功能有关的那些输入组合，比采用等价分类法有更高的测试效率，但这种方法的操作步骤比较复杂。

7.1.4测试情况设计5）猜错所谓猜错，就是猜测被测程序在哪些地方容易出错，然后针对可能的薄弱环节来设计测试用例。它的基本想法是列举出程序中可能有的错误和容易发生错误的特殊情况，并且根据这些情况设计测试用例。显然，它比前２种方法更多地依靠测试人员的直觉与经验。所以，一般都先用前２种方法设计测试用例，然后用猜错法补充一些例子作为辅助的手段。7.2系统测试过程7.2.1单元测试7.2.2集成测试7.2.3确认测试7.2.4系统测试7.2.5验收测试7.2.6系统调试7.2系统测试过程测试是提高软件可靠性的重要的手段，其目的就是通过典型数据的试运行发现问题、错误，进而修改错误，从而提高软件的可靠性、稳定性。但正如迪杰斯特拉所指出的“测试只能说明程序有错，并不能证明程序不存在错误”。所以从20世纪60年代以来，人们就寄希望于软件的正确性证明，希望研究出实用的技术与工具，来证明软件的确能完成预定的功能。如果实现，则测试工作量可以大大减轻，软件可靠性将更有保证。7.2系统测试过程软件测试过程与整个软件开发过程基本上是平行进行的。测试计划早在需求分析阶段就应该开始制定，其它相关工作，包括测试大纲的制定、测试数据的生成、测试工具的选择和开发等，也应在测试阶段之前进行。充分的准备工作可以有效地克服测试的盲目性、缩短测试周期、提高测试效率，并且起到测试文档与开发文档互查的作用。7.2系统测试过程

2通常在编写出每一个模块之后就对它做必要的测试（单元测试），编码与单元测试属于软件生存周期的同一阶段。在结束这一阶段之后，对软件系统还要进行各种综合测试（如图7.2）。被测模块被测模块单元测试集成测试确认测试系统测试验收测试设计信息软件需求运行环境……客户需求7.2系统测试过程测试流程图可以看出，软件测试的这五个过程是一种逐步深入的过程，互相又有交叉，同时这五个过程又是相对独立的，每一个过程有自己的测试计划、用例、报告等。在每一个过程中都必需包括拟定软件测试计划、编制软件测试流程、设计和生成测试用例、实施测试和生成软件问题报告等基本测试活动。7.2.1单元测试单元测试是对软件设计的最小单位—模块进行正确性检验的测试工作，测试模块在语法、格式和逻辑上的错误。使用的测试方法以详细设计为基础，了解I/O条件和模块的逻辑结构。先采用白盒测试法，尽可能达到穷尽测试，然后再用黑盒测试法，使之对任何合理和不合理的输入都能够鉴别和响应。代码覆盖率检查：Numega中的truecoverage，Rational的Purecoverage，Telelogic公司的logiscope,，Macabe公司的Macabe等；按照测试计划要求，将所有测试过程进行详细记录，并将测试文档资料完整保存，以便在以后的系统维护中查阅。③其他限制条件的测试，如可使用性、安全保密性、可维护性、可移植性、故障处理能力等。集成测试的主要目标是要求符合实际软件结构，解决模块接口的一致性问题。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序；①用户文档问题：无标准，无新功能使用方法，无版本改动说明。为使测试文档起到桥梁的作用，使它有助于程序员编制程序，有助于管理人员监督和管理软件的开发，文档的编制必须保证一定的质量和规范。但正如迪杰斯特拉所指出的“测试只能说明程序有错，并不能证明程序不存在错误”。如：快捷键定义不科学、不实用，键位分布不合理、按键太多，甚至没有快捷键。按照测试计划要求，将所有测试过程进行详细记录，并将测试文档资料完整保存，以便在以后的系统维护中查阅。可以说，测试就是寻找“系统错误”，特别是寻找不经常出现的错误、隐藏着的错误。①各模块是否无错误地连接；但如果输出是正确的，软件可能仍然存在错误；必须根据需求规格说明书中规定的性能，对被验收的软件进行测试，以确认该软件的性能是否得到满足，开发单位应提交开发阶段内各测试阶段所作的测试分析报告，包括测试中发现的错误类型，以及修正活动情况。掌握系统测试过程常见的测试类型它一般用人工方式完成，故亦称人工测试或代码评审；组装测试的主要内容有：7.2.1单元测试在单元测试期间主要评价模块的下述五个特性，它们也是测试用例选择的重要依据：①模块接口：对测试模块，是否正确无误地流入和流出；②局部数据结构：在模块工作过程中，其内交换数据能否保持完整性，包括内部数据的内容、形式及相互关系是否正确；③边界条件：在为限制数据加工而设置的边界处模块是否能正常工作；④覆盖条件：模块的运行能否达到满足特定的逻辑覆盖；⑤出错处理：模块运行中发生了错误，其中的出错处理设施是否有效。

7.2.2集成测试用经过单元测试的模块组装成设计所规定的软件系统的过程就是“集成”。集成测试是组装软件的系统技术之一。集成测试的主要目标是要求符合实际软件结构，解决模块接口的一致性问题。例如，数据穿过模块接口时可能丢失；一模块可能对另一模块产生副作用；子功能组装以后，可能系统总的功能达不到；单个模块看来是可以接受的误差，组装以后积累起来的软件误差可能大到无法让人接受的程度；全程数据结构可能有问题等，都是集成测试要解决的问题。7.2.2集成测试组装测试的主要内容有：①各模块是否无错误地连接；②能否保证数据有效传送及数据的完整性和一致性；③人机界面及各种通信接口能否满足设计要求；④除了在存储器中需要分配绝对地址的程序段外，是否具有新定位的能力；⑤能否与软件需求规格说明中规定的所有设备正确联接。组装模块的过程可以分为自顶向下组装法和由底向上组装法。7.2.2集成测试1）自顶向下组装自顶向下集成测试是一个递增的组装软件结构的方法。从主控模块（主程序）开始沿控制层向下移动，把模块一一组合起来。分两种方法：第一、先深度：按照结构，用一条主控制路径将所有模块组合起来；第二、先宽度：逐层组合所有直接下属模块，在每一层水平地沿着结构移动。7.2.2集成测试组装过程分以下五个步骤：①用主控模块作为测试驱动程序，其直接下属模块用承接模块来代替；②根据所选择的集成测试法（先深度或先宽度），每次用实际模块代替下述的承接模块；③在组合每个实际模块时都要进行测试；④完成一组测试后再用一个实际模块代替另一个承接模块；⑤可以进行回归测试（即重新再做所有的或者部分已做过的测试），以保证不引入新的错误。7.2.2集成测试2）由底向上组装由底向上集成测试是从端点模块即软件结构中不调用其他模块的模块开始进行组装以及测试。在逐步处理上层模块时所需要的子模块总是可以得到的，因此不需要承接模块。由底向上组装可以按照以下步骤：①将低层模块组合成实现某个特定的软件子功能的簇；②需要编写一个驱动程序作为测试的控制程序，用来协调测试用例的输入和输出；③测试模块簇；④去掉小簇的驱动程序，将几个小簇合并成大簇，再重复②③④步，这样沿着软件结构逐步向上组装。7.2.3确认测试集成测试通过以后，软件已经组装成一个完整的软件包，这时就可以进行确认测试，用确认测试用例测试程序，将结果与期望值比较，测试软件是否满足需求规格说明的要求，即验证软件功能与用户要求的一致性。在软件需求说明书的有效性标准中，详细定义了用户对软件的合理要求，其中包含的信息是有效性测试的基础和根据。测试计划给出了必须进行的测试类型，测试过程确定了验证软件有效性的特殊测试用例。此外，还必须对文件资料是否完整正确，软件的易移植性、兼容性、出错自动恢复功能和易维护性进行确认。7.2.3确认测试在使用测试用例完成有效性测试以后，如果发现软件的功能和性能与软件需求说明有差距时，需要列出缺陷表。在软件工程的这个阶段若发现需求不一致，修改的工作量往往是很大的，不大可能在预定进度完成期限之前得到改正，往往要与用户协商解决。确认测试的主要内容有：①功能方面应测试系统的输入、处理、输出是否满足需求；②性能方面应测试系统的数据精确度、时间特性（如响应时间、更新处理时间、数据转换及传输时间等）、适应性（在操作方式，运行环境与其他软件的接口发生变化时，应具备的适应能力）是否满足设计要求；③其他限制条件的测试，如可使用性、安全保密性、可维护性、可移植性、故障处理能力等。7.2.4系统测试系统测试是将通过确认测试的软件作为整个计算机系统的一个元素，与硬件、外设等等其他元素结合在一起，对软件系统进行整体测试和有效性测试。一般相当大的工作量集中在软件系统的某些模块与计算机系统中有关设备打交道时的默契配合方面。例如：当软件系统中调用打印机这种常见输出外设时，软件系统如何通过计算机系统平台的控制去合理驱动、选择、设置、使用打印机。又如，新的软件系统中的一些文件名和计算机系统中别的软件系统中的一些文件完全同名时，两种软件系统之间如何实现相互协调操作。再如，新的软件系统和别的软件系统对系统配置和系统操作环境有矛盾时如何相互协调。如此等等的问题都是系统测试要解决的问题。7.2.4系统测试系统测试的内容应包括对各子系统或分系统间的接口正确性的检查和对系统的功能、性能的测试。系统测试一般通过以下几种测试来完成：①恢复测试。恢复测试是要采取各种人工方法使软件出错，而不是能正常工作，进而检验系统的恢复能力。如果系统本身能够自动地进行恢复，则应检验：重新初始化、检验点设置机构、数据以及重新启动是否正确。如果这一恢复需要人工干预，则应考虑平均修复时间是否在限定的范围内。结合起来进行。为记录性能需要再安装必要的仪表或度量性能的软件。7.2.4系统测试②安全测试。安全测试就是设置一些企图突破系统安全保密措施的测试用例，检验系统是否有安全保密的漏洞。对某些与人身、机器和环境的安全有关的软件，还需特别测试其保护措施和防护手段的有效性和可靠性。③强度测试。强度测试检验系统的能力最高能达到什么实际限度。在强度测试中程序被强制在它的设计能力极限状态下运行，进而超出极限，以验证在超出临界状态下性能降低不是灾难性的。④性能测试。性能测试检验安装在系统内的软件运行性能，这种测试需与强度测试结合起来进行。为记录性能需要再安装必要的仪表或度量性能的软件。因果图法也是较常用的一种黑盒测试技术。①各模块是否无错误地连接；比如：在这台计算机上可以稳定运行，而在另一台上运行就极不稳定。必须根据需求规格说明书中规定的性能，对被验收的软件进行测试，以确认该软件的性能是否得到满足，开发单位应提交开发阶段内各测试阶段所作的测试分析报告，包括测试中发现的错误类型，以及修正活动情况。这种错误群集性现象，已为许多程序的测试实践所证实。代码覆盖率检查：Numega中的truecoverage，Rational的Purecoverage，Telelogic公司的logiscope,，Macabe公司的Macabe等；这种错误群集性现象，已为许多程序的测试实践所证实。1）应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。用经过单元测试的模块组装成设计所规定的软件系统的过程就是“集成”。④完成一组测试后再用一个实际模块代替另一个承接模块；广义地说，它们都属于程序测试，测试的方法分类见图7.⑤提示信息意义不明或为原始的英文提示。另外，在软件测试过程中，测试用例数量大，测试计划和测试报告多，维护工作量大，往往需要选择自动化的测试管理系统。7.2.5验收测试系统测试完成后，并使系统试运行了预定的时间，企业应进行验收测试。确认已开发的软件能否达到验收标准，包括对测试有关的文档资料的审查验收和对程序测试验收。对于一些关键性软件，还必须按照合同一些严格条款进行特殊测试，如强化测试和性能降级执行方式测试等，验收测试应在软件投入运行后所处的实际生产环境下进行。验收测试的目的是测试程序的操作和合同规定的要求是否一致。通常以用户为主体来进行，由用户设计测试用例，确定系统功能和性能的可接受性，按照合同中预定的验收原则进行的测试，这是一种非常实用的测试，实质上就是用户用大量的真实数据试用软件系统。7.2.5验收测试①文档资料的审查验收。所有与测试有关的文档资料是否编写齐全，并得到分类编写，这些文档资料主要包括各测试阶段的测试计划、测试申请及测试报告等。②余量要求。必须实际考察计算机存储空间，输入、输出通道和批处理间接使用情况，要保持至少有20%的余量。③功能测试。必须根据需求规格说明书中规定的功能，对被验收的软件逐项进行测试，以确认软件是否具备规定的各项功能。④性能测试。必须根据需求规格说明书中规定的性能，对被验收的软件进行测试，以确认该软件的性能是否得到满足，开发单位应提交开发阶段内各测试阶段所作的测试分析报告，包括测试中发现的错误类型，以及修正活动情况。开发单位必须设计性能测试用例，并预先征得用户的认可。

7.2.5验收测试⑤强化测试。强化测试必须按照GB8566-88《计算机软件开发规范》中的强化测试条款进行。开发单位必须设计强化测试用例，其中应包括典型的运行环境、所有的运行方式，以及在系统运行期可能发生的其他情况。⑥性能降级执行方式测试。在某些设备或程序发生故障时，对于允许降级运行的系统，必须确定经用户批准的能够安全完成的性能降级执行方式，开发单位必须按照用户指定的所有性能降级执行方式或性能降级地方式组合来设计测试用例，应设定典型的错误原因和所导致的性能降级执行方式。开发单位必须确保测试结果与需求规格说明中包括的所有运行性能需求一致。⑦安装测试。安装测试的目的不是检查程序的错误，而是检查软件安装时产生的问题，即程序和库、文件系统、配置管理系统的接口有什么问题。7.2.6系统调试系统测试的目的是为了发现尽可能多的错误，对于所暴露的错误最终是需要改正，系统调试的任务就是根据测试时所发现的错误，找出原因和具体的位置，并进行改正，调试工作主要是由程序开发人员来进行，也就是说，谁开发的程序由谁来调试。调试的结果有两个：一是能确定错误原因并进行了纠正，为了保证错误已排除，需要重新执行暴露该错误的原测试用例以及某些回归测试，另一种是未找出错误原因，那么只能对错误原因进行假设，根据假设设计新的测试用例证实这种推测，若推测失败，需进行新的推测，直至找到错误并纠正。常用的系统调试方法主要有试探法、回溯法、对分查找法、归纳法和演绎法

7.3系统测试文档7.3.1测试文档规范7.3.2测试文件7.3系统测试文档为了保证测试质量，软件测试必须完成规定的文档，测试文档资料属于软件文档里的管理文档，它主要是为软件管理人员和开发人员提供服务。测试文档资料从大的方面可分为测试计划和测试分析报告两类。测试计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许偏差的范围等，测试计划又可分为测试计划与测试设计说明、测试规程以及测试用例几个部分。在测试分析报告中，需要对测试结果加以分析，并提出测试的结论性意见。测试分析报告包括综合测试报告和验收测试报告。7.3.1测试文档规范为使测试文档起到桥梁的作用，使它有助于程序员编制程序，有助于管理人员监督和管理软件的开发，文档的编制必须保证一定的质量和规范。高质量、规范化测试文档的编制应体现在以下几个方面：1）精确性：文档的行文应当十分确切，不能出现多义性的描述，同一测试课题的几个测试文档应当是协调一致、没有矛盾的。2）清晰性：文档的编写应力求简明，如有可能，配以适当的图表，以增强其清晰性。7.3.1测试文档规范3）规范性：在软件测试的过程中，测试文档的编制应该规范化，测试文档的测试计划、测试分析报告应有一定的规范化标准，这样有利于测试人员和开发人员、管理人员的沟通和理解，避免一些不必要的重复性的工作。4）灵活性：对于不同的软件项目，其规模和复杂度有许多差异，不能一律使用同一规范，应根据具体软件开发项目，决定编制测试文档的规范化程度。5）版本控制：版本管理是对系统测试的不同版本进行标识和跟踪的过程。版本跟踪的目的是便于对版本加以区分、检索和跟踪，以表明各个版本之间的关系。一个版本是软件测试的一个实例，在性能、侧重点和深度方面与其他版本有所不同，或是修正、补充了前一版本的某些不足。测试文档的版本控制也是编制测试文档规范化的一个重要内容。

7.3.2测试文件测试文件（SoftwareTestingDocumentation）描述了要执行的软件测试及测试的结果。由于软件测试是一个很复杂的过程，同时也涉及到软件开发中其它一些阶段的工作，对于保证软件的质量和它的正常运行有着重要意义。必须把对它的要求、测试过程及测试的结果以正式的文件形式写出。测试文件的编写是测试工作规范化的一个重要组成部分。测试文件不只是在测试阶段才考虑，它应在软件开发初期的需求分析阶段就开始着手，因为测试文件与用户有着密切的关系。在设计阶段的一些设计方案也应在测试文件中得到反映，以利于设计的检验。测试文件对于测试阶段工作的指导与评价作用更是非常明显的。需要特别指出的是，在已开发的软件投入运行的维护阶段，常常还要进行再测试或回归测试，这时还会用到测试文件。7.3.2测试文件1）测试文件的类型根据测试文件所起的不同作用，通常把它分成两类，即测试计划及分析报告。测试计划详细规定了测试的要求，包括测试的目的和内容、方法和步骤以及评价测试的准则等。由于要测试的内容可能涉及到软件的需求和软件的设计，因此必须及早开始测试计划的编写。测试计划的编写从需求分析阶段开始，到软件设计阶段结束时完成是适当的。7.3.2测试文件测试分析报告应说明对测试结果的分析情况，经过测试证实了软件具有的功能以及它的欠缺和限制，并给出评价的结论性意见。这个意见既是对软件质量的评价，又是决定该软件能否交付用户使用的一个依据。由于它要反映测试工作的情况，自然是在测试阶段内编写。根据测试文件编制的不同方法，它又有手工编制和自动编制两种。所谓自动编制，其特点在于，编制过程中得到文件编制软件的支持，并可将编好的文件记录在机器可读的介质上。借助于有力的工具和手段，使得更容易完成信息的查找、比较、修改等操作。无疑这是比手工编制更高效、更先进的方法。7.3.2测试文件2）测试文件的使用测试文件的重要作用可从以下几个方面看出：①验证需求的正确性。测试文件中规定了用以验证软件需求的测试条件，研究这些测试条件对弄清用户需求的意图是十分有益的。②提高用户对软件开发的认识。测试过程吸收用户参加，可让他们理解一个自动化应用系统的开发与运行要涉及到的复杂问题和一些细节。用户协助编制测试文件将有助于他们了解开发过程。③提高用户对应用系统本身的认识。如果用户能够协助准备测试条件，并将其写成文件，他们就将对开发的应用系统有较好的理解。同时，也有助于用户澄清他们一些可能模糊的认识。如果对应用系统如何工作的细节并不了解，那就不可能给出测试条件，并根据这些条件取得预期的结果。7.3.2测试文件④检验测试资源。测试计划不仅用文件的形式把测试过程要完成的任务规定下来，还应说明测试工作必不可少的资源，进而检验这些资源是否可以得到，即它的可用性如何。如果某个测试计划已经开发出来，但所需资源还是不落实的，那就必须及早解决。⑤明确任务的风险。用户理解了测试计划，他便弄清了测试可以做什么，不能做什么。了解测试任务的风险有助于用户对潜在的、可能出现的问题，事先作好思想上和物质上的准备，例如争取另外的测试资源。⑥生成测试用例。测试用例的好坏决定着测试工作的成功和效率，选定测试用例是做好测试工作的关键一步。在测试文件编制过程中，按照规定的要求精心设计测试用例有着重要意义。7.3.2测试文件⑦评价测试结果。测试文件应包含测试用例，即若干测试数据及其对应的预期测试结果。完成测试后，将测试结果与预期结果进行比较，便可对已进行的测试提出评价意见。⑧再测试。测试文件中规定和说明的部分内容，在后期的维护阶段往往由于各种原因需要进行修改完善，凡是对修改完善后的内容都需要对相关部分进行重新测试（可能包括某些接口），这就是再测试。⑨决定测试的有效性。完成测试后，把测试结果写入文件，这对分析测试的有效性，甚至整个软件的可用性提供了必要的依据。同时还能证实有关方面的见解。7.4测试工具简介测试工作在软件开发整个过程中占有极为重要的位置，而全人工测试是非常麻烦的，所以测试过程的自动化已成为测试发展的重要方向。测试工具的选择对测试的规范化影响很大，目前已开发出了各种自动化软件测试工具，它们为软件测试提供了强有力的支持。测试工具从测试的方法上可以分为两种：白盒测试工具和黑盒测试工具。7.4测试工具简介①白盒测试工具主要有：

内存资源泄漏检查：Numega中的bouncechecker，Rational的Purify等；

代码覆盖率检查：Numega中的truecoverage，Rational的Purecoverage，Telelogic公司的logiscope,，Macabe公司的Macabe等；

代码性能检查：Numega中的truetime，Rational的Quantify等；代码静态度量分析质量检查工具：logiscope和Macabe等。7.4测试工具简介NuMegaDevPartnerStudio是康博(compuware)软件公司开发的自动化白盒工具包，它是一个全面的SmartDebugging工具包，能自动地检查企业级或Internet级用多语言创建的组件和应用中出现的软件错误和性能问题，并能很快地给予解决。它主要用于代码开