（一）系统测试概述

系统测试是根据系统开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例，并利用这些测试用例去运行系统，以发现系统错误的过程。好的测试方案是尽可能地发现至今尚未发现的错误的测试方案。成功的测试则是发现至今尚未发现的错误的测试。测试并不能保证程序是完全正确的，成功的测试也不应是没有发现错误的测试。

在管理信息系统开发及实施过程中，系统测试是保证系统得以顺利运行的关键性一步，它是提高软件质量和可靠性的有效手段。管理信息系统涉及管理、软件、硬件、人员等各方面以及软件开发活动的一系列过程，尽管人们采取了许多消除缺陷发生的措施，甚至将55%以上的开发力量投入系统测试中，但错误仍不可避免地发生。本节将对目前系统测试中所使用的战略、主流技术以及规范化的测试文档作详细介绍，其中，软件测试是核心。

（二）系统测试的目的与原则

1.系统测试的目的

结合经济效益和技术手段两方面的考虑，测试的目的是以最少人力、物力和时间投入，尽可能早、尽可能多地找出软件中潜在的各种错误和缺陷。由此目的所带来的附加收获是，它能证明软件的功能和性能与需求相符合。

2.系统测试的原则

在测试过程中还要注意以下一些原则或公理，它们是系统开发和测试的“交通规则”或者“生活法则”。

（1）所有的测试都应追溯到系统说明书，或者更进一步就是用户需求。因为系统测试的目标在于揭示错误，而最严重的错误是那些无法满足用户需求的错误，导致的后果就是用户不满意，不接受，甚至要求赔偿。

（2）尽早地、不断地进行系统测试。由于系统的复杂性和抽象性，以及软件开发各个阶段的多样性等，使得开发的每个环节都可能产生错误，把测试贯穿于开发过程的始终，坚持软件开发的阶段评审，从而可以尽早发现和预防错误，达到减少开发费用和提高质量的目的。

（3）系统测试是有风险的行为。如果不去测试所有的情况，那就是选择了风险。但是穷举法又是绝对不可取的，因为任何一个小程序的完全测试数目都是一个天文数字。这时的主要测试原则就是把无边无际的可能减少到可以控制的范围，以及针对风险做出明智抉择，去粗取精。

图7—1说明了测试量和发现的系统错误数量之间的关系。如果试图测试所有情况，费用将大幅增加，而错误遗漏的数量并不会因为费用追加而明显下降。如果减少测试或者错误地确定测试对象，那么费用很低，但是会漏掉大量错误。我们的目标是找到满意的测试量，由于涉及寻找费用的发生，所以并不一定要找到图中的“*”点，其附近的点均可。

图7—1　软件项目最优的测试量

（4）找到的错误越多，就说明系统缺陷越多。生活中的寄生虫和系统缺陷几乎一样，两者都成群出现，发现一个，附近就会有一群。原因有很多，比如程序员疲劳，同一个程序员往往犯同样的错误，系统网络架构的不合理等，在这里也要注意，并非所有的错误都能修复。

（5）除检查系统应完成的任务外，还应检查系统是否做了它不应该做的事。尤其是在网络环境下要注意流出与流入数据的检验与加密，以保证系统和数据的安全。

（三）系统测试与开发各阶段的关系

系统开发是一个自顶向下、逐步细化的过程，而测试则是自底向上、逐步集成的过程，低一级别的测试为高一级别的测试做准备工作，但这并不排除两者并行测试，系统测试与系统开发各阶段的关系如图7—2所示。

单元测试将对每一个功能模块进行测试，以消除模块内部在逻辑上和功能上的错误及缺陷。在单元测试的基础上，对照系统设计进行集成测试，检测和排除子系统及系统在结构上的错误。在集成测试的基础上，对照系统需求进行确认测试，最后从系统全体出发运行系统，看是否满足需求。

图7—2　系统测试与系统开发过程的关系

系统不仅仅是表面的那些东西，通常要靠有计划、有条理的开发过程来建立。从开始到计划、编制、测试，一直到公开使用的过程中，都有可能发现系统错误。图7—3显示了随着时间推移，系统错误修复费用的增长情况。

图7—3　修复费用增长曲线

（四）系统测试的过程

系统的测试过程如图7—4所示。

图7—4　系统测试的过程

1.单元测试

单元测试主要以模块为单位进行测试，即测试已设计出的单个模块的正确性。单元测试的主要内容包括：

（1）模块接口，即测试模块之间信息是否能够准确地流进、流出；

（2）数据结构，即测试模块在工作过程中，其内部的数据能否保持完整性，包括内部数据的内容、形式及相互关系是否正确；

（3）边界条件，即测试为限制数据加工而设置的边界处模块能否正常工作；

（4）覆盖条件，即测试模块的运行能否达到满足特定的逻辑覆盖；

（5）出错处理，即测试模块工作中发生错误时，其中的出错处理措施是否有效。

2.组装测试

在每个模块完成单元测试后，需按照所设计的结构图把它们连接起来，进行组装测试。组装测试的内容包括：

（1）各模块是否无错误地连接；

（2）能否保证数据有效传输及数据的完整性和一致性；

（3）人机界面及各种通信接口能否满足设计要求；

（4）能否与硬件系统的所有设备正确连接。

3.确认测试

组装测试完成后，在各模块接口无错误并满足软件设计要求的基础上，还需进行确认测试。确认测试的主要内容有：

（1）功能方面应测试系统输入、处理、输出是否满足要求；

（2）性能方面应测试系统的数据精确度、时间特性（如响应时间、更新处理时间、数据转换及传输时间、运行时间等）、适应性（在操作方式、运行环境及其他软件的接口发生变化时应具备的适应能力）是否满足设计要求；

（3）其他限制条件的测试，如可使用性、安全保密性、可维护性、可移植性、故障处理能力等。

4.系统测试

在软件完成确认测试后，应对软件与其他相关部分或全部软硬件组成的系统进行综合测试。系统测试的内容包括对各子系统或分系统之间的接口正确性的检查和对系统的性能、功能的测试。系统测试一般通过以下几种测试来完成：

（1）恢复测试，即采取各种人工方法让软件出错使其不能正常工作，进而检验系统的恢复能力。如果系统本身能够进行自动恢复，则应检验重新初始化、检验点设置机构、数据恢复以及重新启动是否正确。

（2）安全测试，即设置一些企图突破系统安全保密措施的测试用例，检验系统是否有安全保密漏洞。对某些与人身、机器和环境的安全有关的软件，还需特别测试其保护和防护手段的有效性和可能性。

（3）强度测试，即检验系统的极限能力，主要确认软件系统在超临界状态下性能降级是否是灾难性的。

（4）性能测试，即测试安装在系统内的软件的运行性能，这种测试需与强度测试结合起来进行。为了记录性能，需要在系统中安装必要的测量仪表或度量性能的软件。

5.验收测试

系统测试完成，且系统试运行了预定的时间后，企业应进行验收测试，确认已开发的软件能否达到验收标准，包括对测试有关的文档资料的审查验收和对程序测试验收。对于一些关键性的软件，还必须按照合同进行一些严格的特殊测试，如强化测试和性能降级执行方式测试等，验收测试应在软件投入运行后所处的实际工作环境中进行。验收测试的内容包括：

（1）文档资料的审查验收，即检查所有与测试有关的文档资料是否编写齐全，并得到分类编目。这些文档资料主要包括各测试阶段的测试计划、测试申请及测试报告等。

（2）余量要求。必须实际考察计算机存储空间，输入、输出通道和批处理时间的使用情况，要保证它们至少都有20%的余量。

（3）功能测试。必须根据系统实施方案中规定的功能对被验收的软件逐项进行测试，以确认该软件是否具备规定的各项功能。

（4）性能测试。必须根据系统实施方案中规定的性能对被验收的软件进行逐项测试，以确认该软件的性能是否得到满足。

（5）强化测试。必须按照GB8566软件开发规范中的强化测试条款进行，开发单位必须设计强化测试用例，其中包括典型运行环境、所有运行方式及在系统运行期间可能发生的其他情况。

（6）性能降级执行方式测试。在某些设备或程序发生故障时，对于允许降级运行的系统，必须确定能够安全完成的性能降级方式，开发单位必须按照应用企业指定的所有性能降级执行方式或性能降级执行方式组织来设计测试用例，应设定典型的错误原因和所导致的性能降级执行方式。开发单位必须确保测试结果与需求规格说明中包括的所有运行性能需求一致。

以上五类测试是一个商品化系统不可缺少的，每种测试都要事先设计，事后写报告归档。测试完成的标准为：由于难以判定软件是否还有错误，因此，什么时候停止测试就难以断言。增加测试可以增加可靠性，但测试费用也增加。通常停止测试的情况是在规定的测试时间以后没有再发现问题（如微软对一般系统的测试时间是72小时），或者是执行完所有测试用例以后没有再发现问题。

除了上述测试之外，在交付测试的系统正式投入测试之前应进行一定范围的人工测试，这不是上机实际运行，而是测试小组的会审（Inspections）和走查（Walkthroughs）

在程序的人工测试中，程序会审由作者读他的程序，3～4个有经验的测试人员听取他的解释。事实证明，这种方法可以发现30%～70%的逻辑设计和编码错误，但对定义分析错误收效甚微。

走查和会审类似，但不是由程序员读他自己的程序，而是走查小组的测试人员事先把程序在纸面上“执行”一次，提出执行中发生的问题，以便发现重大的逻辑错误。开走查会议时，对于有问题的部分，测试人员和程序作者一起在黑板上运行，以求找出问题的症结。

IBM公司的人工测试效率高达80%，就是说，在所有测出的错误中80%是在人工测试中发现的。这就证实了计算机心理学家温伯格（Weinberg）的断言——“人工读程序是非常必要的”。

（五）系统测试技术

1.黑盒子测试

不深入代码细节的软件测试方法称为黑盒子测试。它是动态的，因为程序正在运行——软件测试员充当客户来使用它；它是黑盒子，因为测试时不知道程序如何工作。测试工作就是进行输入、接受输出、检验结果。黑盒子测试常常被称为行为测试，因为测试的是软件在使用过程中的实际行为。软件测试人员不关心程序内部是如何实现的，而只是检查程序是否符合它的“功能说明”，所以使用黑盒子法设计的测试用例完全是根据程序的功能说明来设计的。

根据微软的经验，黑盒测试的内容主要有以下几个方面：

（1）菜单/帮助测试。在软件产品开发的最后阶段，文档里发现的问题往往是最多的。因为在软件测试过程中，开发人员会修复测试人员发现的错误，而且可能会对软件的一些功能进行修改，同时项目经理也会根据情况调整软件的特性。所以，在软件开发和测试过程中，所有的功能和特性都不是固定不变的，都会进行调整。

（2）Alpha/Beta测试。Alpha测试是由一个用户在开发场所进行的，用户在开发者的“指导”下对软件进行测试，开发者负责记录使用中出现的错误。Beta测试是由软件的最终用户在一个或多个用户场所进行的，开发者通常不会在场。因此，Beta测试是软件在一个开发者不能控制的环境中的“活的”应用，用户记录下所有在测试中遇到的问题，并报告给开发者，然后开发者对系统进行最后的修改。在此过程中，产品特征不断地修改。当发现错误后，在开发人员修改的同时，项目经理也会对产品计划做出相应的调整，产品计划不是一成不变的。

（3）回归测试。回归测试的目的就是保证以前已经修复的错误在软件交付前不会再出现。实际上，许多错误都是在回归测试时发现的。在此阶段，首先要检查以前找到的错误是否已经更正了。值得注意的是，有的错误经过修改之后可能又产生了新的错误，回归测试可以保证已更正的错误不再重现，而且不产生新的错误。

（4）RTM测试（Release to Manufacture Testing）。这是为软件真正的交付做好准备的测试。

在黑盒子测试法中还有以下一些测试技巧：

（1）等价类划分法。这种方法根据黑盒法的思想，在所有可能的输入数据中取一个有限的子集作为测试用数据，通常是将模块的输入域划分成有效等价类和无效等价类两种。所谓有效等价类，是指对程序的功能要求来讲有意义的、合理的输入数据所构成的集合；而无效等价类是指那些不合理的或非法的输入数据所构成的集合。例如，某模块的合理输入是0～100，大于0且小于100的数据属于有效等价类，小于0或大于100的数据为无效等价类，测试数据可以从这两个等价类中抽取。(www.daowen.com)

（2）边界条件测试法。边界条件是特殊情况，因为编程从根本上说不怀疑边界有问题。软件是极端的——或者对或者不对。但是，许多软件在处理大量中间数据时都是对的，但是可能在边界处出现许多问题。如果软件测试问题包含边界条件，那么数据类型可能是数值、字符、位置、数量、速度、地址和尺寸。同时，考虑这些类型的下述特征：第一个/最后一个、开始/完成、空/满、最慢/最快、最大/最小、超过/在内、最短/最长和最高/最低。如果要选择在等价分配中包含哪些数据，就根据边界来选择。

（3）次边界条件测试。有些边界在软件内部，最终用户几乎看不见，但是软件测试仍有必要检查，这样的边界称为次边界条件或者内部边界条件。寻找这样的边界不要求软件测试员是程序员或者具有阅读源代码的能力，但是确实要求大体了解软件的工作方式。常见的次边界条件测试发生在2的乘方和ASCII表这两方面。

（4）默认、空白、空值和零值测试。这种情况在软件说明书中常常被忽视，程序员也经常遗忘，但是在实际使用中却时有发生。好的软件会处理这种情况。它通常将输入内容默认为合法边界内的最小值或者合法区间内的某个合理值；或者返回错误提示信息。这些值一般在软件内进行特殊处理，所以不要把它们与合法情况和非法情况混在一起，而要建立单独的等价区间。在这种默认情况下，如果用户输入0或-1作为非法值，就可以执行不同的软件处理过程。

（5）错误推测法。测试人员也可以通过经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的程序。错误推测法在很大程度上依赖直觉和经验进行。它的基本思想是列出程序中可能有的错误和容易发生错误的特殊情况，并且根据它们选择测试方案。

2.白盒子测试

白盒子测试即结构测试，它与程序内部结构有关，要利用程序结构的实现细节设计测试实例。它将测试程序设计风格、控制方法、源语句、数据库设计和编码细节。

例如，测试复利的财务程序所基于的计算公式为：

其中：P=本金，r=年利率，n=每年复加的利率次数，t=年数，A=若干年的本息合计。

优秀的黑盒测试员可能选择n=0的测试用例，但是白盒子测试员在看到代码中的公式之后，就知道这样做将导致除零错误，从而使公式乱套。

然而，如果n是另一项计算的结果，或者是经过一系列公式处理过的数值，这就需要考虑是否会出现0值的可能，测试员需要指出什么样的程序输入会导致它的出现。

白盒子测试主要考虑的是测试实例对程序内部逻辑的覆盖程度。在实际运用中，程序员按照覆盖程序从低到高的程度划分为：语句覆盖，判定覆盖，条件覆盖，判定条件覆盖，条件组合覆盖。

（1）语句覆盖，即选择足够的测试实例，使得程序中的每一个语句都能执行一次。

（2）判定覆盖，即判定覆盖比语句覆盖严格，它的含义就是设计足够的测试实例，使得程序中每个判定至少都获得一次“真值”和“假值”的机会。

（3）条件覆盖，即对于每个判定中所包含的若干个条件，应设计足够多的测试实例，使得判定中的每个条件都取到“真”和“假”两个不同的结果。

（4）判定条件覆盖，用判定条件覆盖所设计的测试用例能够使得判断中每个条件的所有可能取值至少执行一次，同时每个判断的所有可能判断结果至少执行一次。

（5）条件组合覆盖，在判定条件覆盖测试的基础上，设计足够多的测试实例，使得每个判定中条件的各种可能组合都至少出现一次。

（6）路径测试，即设计足够多的测试用例覆盖程序中所有可能的路径，它是由汤姆·麦凯布（Tom McCabe）首先提出来的一种白盒子测试技术，该方法允许测试用例设计者通过分析控制结构的环路复杂性，导出基本可执行路径集合。

值得注意的是，即使是条件组合覆盖的测试也仍然不能发现全部错误，还需要黑盒测试作补充。

3.强力测试

在各种极限情况下对产品进行测试（例如，很多人同时使用该软件或者反复运行该软件），以检查产品的长期稳定性。

例如，微软在测试IE4.0的时候，由于当时有一个非常强的竞争对手，所以要保证IE4.0的高质量和高性能，为了测试IE4.0的长期稳定性，开发小组专门设计了一套自动测试程序，它一分钟可以下载上千个页面，用此测试程序对IE4.0进行了连续72小时的测试，因为根据微软的经验，如果一个软件产品能通过72小时的强力测试，则该产品在72小时后出现问题的可能性微乎其微，所以，72小时是微软产品强力测试时间的标志。

当然，上面只是提到了系统强力测试的一个方面，对于运行中的系统，还要考虑对硬件的强力测试，例如，把输入数据的量提高一个数量级来测试数据库服务器的响应情况、使用在一个虚拟的操作系统中会引起颠簸的测试实例、在总线型网络中对通信阻塞的测试等。目的都是为了测试系统的长期稳定性。

4.兼容性测试

随着各生产厂商各种标准的统一，硬件的兼容性测试在系统测试中已经显得不那么重要，在这里我们重点介绍软件兼容性的问题。

随着用户对各种厂商的各种类型软件之间共享数据能力和同时执行多个程序能力的要求越来越强，测试程序之间能否协作变得越来越重要。现在程序之间大多需要导入和导出数据，在各种操作系统和Web浏览器上运行，与同时运行在同一种硬件上的其他软件交叉操作。

软件兼容性测试工作目标是保证软件按照用户期望的方式进行交互。其中包括平台和应用程序的兼容、向前和向后兼容、数据共享兼容性。

这部分的测试比较复杂，需要整体分析产品说明书和所有支持说明书，还需要与程序员讨论，尽可能深入地审查代码以保证软件的使用。

5.易用性测试

软件编出来是要用的，但是有时开发小组在编写代码的技术方面投入了太多精力，以致忽视软件最重要的方面——最终的使用者。易用性是交互适应性、实用性和有效性的集中体现。

用于与软件程序交互的方式称为用户界面或UI，现在我们使用的个人计算机都有复杂的图形用户界面（GUI），优秀的UI通常通过符合标准和规范、直观性、一致性、灵活性、舒适性、正确性、实用性7个要素体现出来。

（1）通用标准和规范由软件易用性专家开发，它们是由大量正式测试、经验、技巧和错误得出的方便用户的规则。如果软件严格遵守这些规则，就自然具备优秀UI的其他要素。

（2）在评价直观性的时候通常考虑以下几个问题：用户界面是否洁净？所需功能或者期待的响应是否明显并在预期的地方出现？有多余功能吗？界面整体是否太复杂了？局部是否做得太多？是否感到信息太庞杂？如果其他所有努力失败，帮助系统真能帮忙吗？

（3）一致性通常是测试软件本身和其他软件的一致性，在从一个程序转向另一个程序时，要注意软件的特性，确保相似操作以相似方式进行。在审查软件时想一想以下几个方面：快捷键和菜单选项，术语和命令，按钮位置和等价的按键，例如，OK键的位置总是在上方或者左方，Cancel按钮的等价按键通常是Esc，这些都需要保持一致。

（4）灵活性允许用户选择做什么和怎样做，不过其中要注意的是，灵活性可能发展为复杂性。

（5）舒适性就是讲究软件使用的感觉，我们可以适当地增加一些色彩和音效，在用户执行严重错误的操作前提出警告，并且允许用户恢复由于错误操作导致丢失的数据，在速度性能上应和大多数人的思维保持同步，如果操作缓慢，至少应该向用户反馈操作持续时间，并且显示它正在工作，没有停滞。其状态图如图7—5所示。

图7—5　状态栏显示完成的工作量

（6）正确性就是测试程序是否做了该做的事，正确性的问题一般很明显，在测试系统说明书时就可以发现。

6.网站测试

网站测试囊括许多领域，包括配置测试、兼容性测试、易用性测试、文档测试，假如网站是全球范围的，还包括本地化测试。网页由文字、图形、表单、指向网站其他网页的超级链接等组成（如图7—6所示）。

文字的检测主要是检查拼写错误。如果有电子邮件地址、电话号码或者邮编等联系信息，要检查是否正确。保证版权声明正确，日期无误。要测试每个网页是否都有正确的标题。超级链接在网页中一定要显眼，每一个链接都要检查，确保它跳转到正确的目的地，并在正确的窗口打开并得到及时回应。

图7—6　网站测试内容举例

查找网页，最好的做法是对拿到Web服务器上的实际网页进行简单的代码范围分析，确定测试是否真的是全部网页，没有遗漏的，也没有多余的。

在表单的测试中要注意边界数据和不同类型数据的输入情况，如何拒绝错误数据？要求是否真正做到？这些都是需要考虑的问题。

网站测试同样也需要进行兼容性测试，每一个浏览器和版本支持的特性都有细微的差别。各硬件平台都有自己的操作系统、屏幕布局、通信软件等，它们都会影响网站在屏幕上的外观。一个网站可能在某个浏览器中表现极佳，但是在另一个浏览器中根本无法显示，在编制时需要解决的是浏览器插件、浏览器选项、视频分辨率和色深等方面的问题。

相对而言，网站测试的技术性不是很强，重点测试的应该是网站的易用性、兼容性和信息的权威性，使之全方位地贴近用户和访问者。

（六）相关测试文档及报告的撰写

1.测试计划

通常，测试计划应包括以下内容：

（1）概述。测试计划首先应说明该测试是做什么的。

（2）测试目标和发布标准。测试计划文档中一定要有测试的最终目标，必须使自己和别人明白为什么必须做这个测试，该测试需要达到的目标是什么。测试计划要明确定义发布标准的范围，并为每一个发布标准定义详细的阶段性目标。

（3）计划将测试的领域。测试计划应列出被测试系统的所有特性，以及每个领域的关键功能，同时，测试计划还应给出对应的每个测试领域的测试规范。

（4）测试方法描述。从系统测试的总体决定系统的测试方法，如前面讲过的基本验证测试、接受性测试等。

（5）测试进度表。测试计划需要为测试的每一个阶段定义详细的进度表，并且该进度表必须与项目经理的要求以及系统开发的进度相一致。实际上，测试进度表依赖于项目经理和开发人员制定的进度表。

（6）测试范围和工具。测试计划中必须给出测试所需的测试平台及相关机器配件和网络开发方案，还必须说明将使用的测试工具，测试人员可以利用已有的工具，如果没有合适的，还必须自己开发。

2.测试规范

所谓测试规范，是指为每一个在测试计划中确定的测试领域所写的文档，用来描述该领域中的测试需求。

在编写测试规范之前，需要参考项目说明书中的系统规范，以及开发人员写的开发计划。在测试计划中主要包括以下一些要素：背景信息、被测试的特性、功能考虑、测试考虑、测试想定等。其中，测试想定是一个重要内容，根据测试想定，我们可以很容易地产生测试案例。表7—1是微软的一个测试想定的例子。

表7—1　测试想定

3.Bug报告

测试人员在测试过程中记录的Bug一般通过报告的形式向开发人员报告。一份Bug报告应该包括以下几个要点：Bug名称、被测试的软件的版本、优先度与严重性、报告测试的步骤、Bug造成的后果、预计的操作后果等。所有这些信息可以放在一个数据库中，它为系统的调试和以后的维护提供了相当重要的信息。开发小组中的项目经理和决策人员根据这些Bug的统计数字和走势了解系统开发的进度，开发人员可以通过这些Bug报告中清晰的测试数据很容易地找到问题。

4.测试报告

测试报告是对测试阶段工作的总结，测试报告的内容主要包括：

（1）引言：介绍测试的目的、范围，测试的角度和标准，测试结果概要。

（2）测试计划和配置：包括系统配置、运行配置、测试标准和评价等。

（3）单元测试：描述对系统各模块测试的结果。

（4）组装测试：描述系统各部件组合后的功能测试结果、正常数据和过载数据下的测试，以及在错误数据下的测试和结果。

（5）确认测试：描述系统功能、性能测试的结果。

（6）系统测试：描述软件与其他相关部分或全部软硬件组成的系统综合测试的结果。

（7）验收测试：描述对有关的文档资料和程序的测试验收的结果。

（8）附录：包括参考文献、异常情况小结、测试数据等。