信息系统分析与开发技术（第3版） 课件 第九章 信息系统测试方法和技术

第九章信息系统测试方法和技术目录9.1测试概述9.2测试步骤9.3测试方法9.4测试过程9.5面向对象的测试9.6系统测试管理9.7信息系统测试案例1983年IEEE提出的软件工程术语中给软件测试下的定义是：“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。该定义明确指出测试的目的是为了检验信息系统是否满足需求。GrenfordJ.Myers对测试的概念和目标的归纳： ⑴测试是为了发现错误而执行程序的过程； ⑵测试是为了证明程序有错，而不是证明程序无错误；⑶好的测试方案是能够发现迄今为止尚未发现的错误的测试方案； ⑷成功的测试是发现了至今尚未发现的错误的测试。

9.1.1测试的概念和目标9.1测试概述测试的目标就是希望能以最少的人力和时间发现潜在的各种错误和缺陷。从上述的目标可以归纳出测试的定义是“为了发现错误而执行程序的过程”。具体的说，测试是根据开发各阶段的需求、设计等文档或程序的内部结构精心设计测试用例（即输入数据和预期的输出结果），并利用这些测试用例来运行程序，以便发现错误的过程。9.1.1测试的概念和目标9.1测试概述假设一个程序P有输入量X和Y及输出量Z。在字长为32位的计算机上运行。若X、Y取整数，按黑盒方法进行穷举测试：可能采用的测试数据组：232×232

＝264

如果测试一组数据需要1毫秒，一年工作365×24小时，完成所有测试需5亿年

9.1.1测试的概念和目标9.1测试概述白盒测试对一个具有多重选择和循环嵌套的程序，不同的路径数目可能也是天文数字。给出一个小程序的流程图，它包括了一个执行20次的循环，包含的不同执行路径数达520条。对每一条路径进行测试需要1毫秒，一年工作365×24小时，测试完需3170年

9.1.1测试的概念和目标9.1测试概述

不论使用什么测试技术，我们都不可能采用穷举测试，如何选择测试用例？

以尽可能少的数据发现尽可能多的错误

9.1.1测试的概念和目标9.1测试概述信息系统测试应包括软件测试、硬件测试和网络测试。硬件测试、网络测试可以根据具体的性能指标来进行，而信息系统的开发工作主要集中在软件上。所以我们所说的测试更多的是指软件测试。软件测试不仅是测试程序，而是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。

9.1.1测试的概念和目标9.1测试概述1.给测试配备最好的人员2.测试必须由独立的部门实施3.应当对每一个测试结果做全面的检查。4.应当尽早地、及时地和不断地进行测试5.测试用例应由输入数据和与之对应的预期输出结果组成。6.设计测试用例时，应当包括合理的输入条件和不合理的输入条件7.严格执行测试计划，排除测试的随意性8.充分重视测试中的群集现象9.妥善保存所有的测试数据（文件）9.1.2测试的原则9.1测试概述①按照是否关注软件结构与算法分类，可以分为黑盒测试和白盒测试。②按照程序是否被执行分类，可以分为静态测试和动态测试。③按照信息系统测试过程分类，可以分为单元测试、集成测试、确认测试、验收测试和系统测试。④按照测试对象分类，可以分为单元测试、组件测试、模块测试、程序测试、系统测试和文档测试。⑤按照信息系统测试的内容分类，可以分为回归测试、功能测试、负载测试、压力测试、性能测试、易用性测试、安装与反安装测试、恢复测试、安全性测试、兼容性测试和比较测试。⑥按照测试执行时是否需要人工干预分类，可以分为手工测试和自动化测试。9.1.3测试分类9.1测试概述目录9.1测试概述9.2测试步骤9.3测试方法9.4测试过程9.5面向对象的测试9.6系统测试管理9.7信息系统测试案例（1）拟定测试计划在制定测试计划时，要充分考虑整个项目的开发时间和开发进度，以及一些人为因素、客观条件等，使得测试计划是可行的。测试计划的主要内容有测试内容、进度安排、测试所需的环境和条件（包括设备、被测项目、人员等）、测试培训安排等。（2）编制测试大纲测试大纲是测试的依据。它明确详尽地规定了在测试中针对系统的每一项功能或特性所必须完成的基本测试项目和测试完成的标准。无论是自动测试还是手动测试，都必须满足测试大纲的要求。9.2测试步骤（3）设计和生成测试用例。在设计测试用例时，产生测试设计说明文档，其内容主要包括被测项目、输入数据、测试过程、预期输出结果等。（4）实施测试。测试的实施阶段是由一系列的测试周期组成的。在每个测试周期中，测试人员和开发人员将依据预先编制好的测试大纲和准备好的测试用例，对被测软件或设备进行完整的测试。（5）生成测试报告。测试完成后，要形成相应的测试报告，主要对测试进行概要说明，列出测试的结论，指出缺陷和错误。9.2测试步骤

由于每种测试所花费的成本不同，如果测试步骤安排得不合理，将造成为了寻找错误原因而浪费大量的时间，以及重复测试。因此，合理安排测试步骤对于提高测试效率、降低测试成本有很大的作用。信息系统测试分别按硬件系统、网络系统和软件系统进行测试，最后对整个系统进行总的综合测试。测试的步骤如图7.1所示。9.2测试步骤9.2测试步骤在进行信息系统开发中，通常需要根据项目的情况选购硬件设备。在设备到货后，应在各个相关厂商配合下进行初验测试，初验通过后将与软件、网络等一起进行系统测试。初验测试所作的工作主要有：①配置检测。检测是否按合同提供了相应的配置。②硬件设备的外观检查。③硬件测试。首先进行加电检测，观看运行状态是否正常，有无报警、屏幕有无乱码提示和死机现象，是否能进入正常提示状态。然后进行操作检测，用一些常用的命令来检测机器是否能执行命令，结果是否正常。通过以上测试，要求形成相应的硬件测试报告，在测试报告中包含测试步骤、测试过程和测试结论等。

9.2.1硬件测试9.2测试步骤如果信息系统不是单机，需要在局域网或广域网运行，按合同会选购网络设备。在网络设备到货后，应在各个相关厂商配合下进行初验测试，初验通过后将与软件、硬件等一起进行系统测试。初验测试所做的工作主要有：①网络设备的外观检查。对交换机、路由器等网络设备及配件进行开箱检查，检查外观有无明显划痕和损伤。②硬件测试。对交换机、路由器等硬件进行加电检测，观察其工作状态是否正常，有无错误和报警。③网络连通测试。检测网络是否连通。可以用PING、TELNET、FTP等命令来检查。通过以上测试，要求形成相应的网络测试报告，在测试报告中包含测试步骤、测试过程和测试的结论等。

9.2.2网络测试9.2测试步骤软件测试可以分成四个步骤：单元测试、集成测试、系统测试和验收测试。单元测试是对程序的最小单位——模块进行测试，检验每个模块是否能单独工作，从而发现模块的编码问题和算法问题；然后将多个模块连接起来，进行集成测试，以检验概要设计中对模块之间接口设计的问题；系统测试是将开发的软件与硬件和其它因素综合起来进行全面的检测，对整个系统进行总的功能、性能等方面的测试；在提交用户的时候进行验收测试，确认系统是否已经满足客户的需求。

9.2.3软件测试9.2测试步骤目录9.1测试概述9.2测试步骤9.3测试方法9.4测试过程9.5面向对象的测试9.6系统测试管理9.7信息系统测试案例1.白盒测试白盒测试（White-boxTesting），也称为结构测试，将软件看成透明的白盒，根据程序的内部结构和逻辑来设计测试用例，对程序的路径和过程进行测试，检查是否满足设计的需要，主要用于软件验证。白盒测试是以程序的源代码为基础进行测试而不使用用户界面。这种类型的测试需要从代码句法中发现内部代码在算法、溢出、路径、条件等中的缺陷或者错误，进而加以修正。测试者必须看到被测的源程序，以被测对象的内部设计知识为基础，选定专门的测试用例，以便检查和发现逻辑路径、模块间接口、共享和传递数据结构中的缺陷。

9.3.1白盒测试和黑盒测试9.3测试方法1.白盒测试白盒测试的原则为：（1）程序模块中的所有独立路径至少执行一次；（2）在所有的逻辑判断中，取“真”和取“假”的两种情况至少都能执行一次；（3）每个循环都应在边界条件和一般条件下各执行一次；（4）测试程序内部数据结构的有效性。白盒测试主要方法有逻辑覆盖和基本路径测试。逻辑覆盖又包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖等。

9.3.1白盒测试和黑盒测试9.3测试方法白盒测试用例设计包括：（1）逻辑覆盖，以程序内在逻辑结构为基础的测试，包括以下六种类型：①语句覆盖：每一条可执行语句至少覆盖一次；②条件覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次；③判定覆盖：又称为分支覆盖，设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次；

9.3.1白盒测试和黑盒测试9.3测试方法（1）逻辑覆盖（续）④判定/条件覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条件的所有可能取值至少执行一次，并且每个可能的判断结果也至少执行一次；⑤路径覆盖：设计足够多的测试用例，运行所测程序，要覆盖程序中所有可能的路径；⑥条件组合覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的所有可能的条件取值至少执行一次。

9.3.1白盒测试和黑盒测试9.3测试方法(A>1)

and

(B=0)(A=2)

or

(X>1)X=X/AX=X+1TTFFabdce

9.3.1白盒测试和黑盒测试9.3测试方法1.白盒测试测试用例的设计格式如下【输入的(A,B,X)，输出的(A,B,X)】为图例设计满足语句覆盖的测试用例是:【(2,0,4)，(2,0,3)】覆盖ace语句覆盖是最弱的逻辑覆盖准则语句覆盖9.3.1白盒测试和黑盒测试9.3测试方法满足要求的测试用例:【(2,0,4)，(2,0,3)】覆盖ace【(1,1,1)，(1,1,1)】覆盖abd判定覆盖1.白盒测试

9.3.1白盒测试和黑盒测试9.3测试方法对于第一个判断：条件A＞1取真为，取假为

条件B＝0取真为，取假为对于第二个判断：条件A＝2取真为，取假为

条件X＞1取真为，取假为条件覆盖T4

9.3.1白盒测试和黑盒测试9.3测试方法条件覆盖测试用例覆盖分支条件取值【(2,0,4)，(2,0,3)】L1(c,e)【(1,0,1)，(1,0,1)】L2(b,d)【(2,1,1)，(2,1,2)】L3(b,e)或【(1,0,3)，(1,0,4)】L3(b,e)【(2,1,1)，(2,1,2)】L3(b,e)

9.3.1白盒测试和黑盒测试9.3测试方法条件组合覆盖就是设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。记 ①A＞1,B＝0作

②A＞1,B≠0作

③A≯1,B＝0作 ④A≯1,B≠0作 ⑤A＝2,X＞1作

⑥A＝2,X≯1作

⑦A≠2,X＞1作

⑧A≠2,X≯1作

9.3.1白盒测试和黑盒测试9.3测试方法测试用例覆盖条件覆盖组合【(2,0,4),(2,0,3)】(L1) ①,⑤【(2,1,1),(2,1,2)】(L3) ②,⑥【(1,0,3),(1,0,4)】(L3) ③,⑦【(1,1,1),(1,1,1)】(L2) ④,⑧

9.3.1白盒测试和黑盒测试1.白盒测试9.3测试方法（2）基本路径测试①程序的控制流图：描述程序控制流的一种图示方法；②计算程序环境复杂性：通过对程序控制流程图的分析和判断来计算模块复杂性。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界；③导出测试用例：通过程序控制流程图的基本路径来导出基本的程序路径的集合；④准备测试用例：确保基本路径集中的每一条路径的执行；⑤图形矩阵：是在基本路径测试中起辅助作用的软件工具，利用它可以实现自动地确定一个基本路径集。

9.3.1白盒测试和黑盒测试1.白盒测试9.3测试方法

9.3.1白盒测试和黑盒测试1.白盒测试9.3测试方法2.黑盒测试黑盒测试（Black-boxTesting），也称为功能测试或数据驱动测试，将软件看成不能被打开的黑盒子，在完全不考虑软件的内部结构和特性的情况下，测试软件的外部特性。根据系统分析说明书设计测试用例，通过输入和输出的特性检测判定是否满足指定的功能。黑盒测试是从用户观点出发的测试，已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用。在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试。黑盒测试只检查程序功能是否符合需求规格说明书的规定，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。

9.3.1白盒测试和黑盒测试9.3测试方法

黑盒测试只作用于程序的接口处，主要是为了发现以下几类错误：（1）是否有错误的功能或遗漏的功能？（2）界面是否存在错误？输入是否能够正确接受？输出是否正确？（3）是否有数据结构或外部数据库访问错误？（4）性能是否能够接受？（5）是否有初始化或终止性错误？黑盒测试方法主要用于软件确认测试，具体方法包括等价类划分、边界值分析、因果图和错误推测法等。

9.3.1白盒测试和黑盒测试9.3测试方法黑盒测试用例设计包括：（1）等价类划分：把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。（2）边界值分析：对输入的条件进行分析并且汲取其中的边界值条件，然后通过对这些边界值的测试来查出更多的错误。（3）错误推测法：靠经验和直觉来推测程序中可能存在的各种错误，从而有针对性地编写测试用例。可以列举出可能的错误和可能发生错误的地方，然后选择用例。（4）因果图：通过画因果图，在图上标明约束和限制，转换成判定表，然后设计测试用例。因果图法适合于检查程序输入条件的各种组合情况。（5）功能图FD：通过使用功能图形式化地表示程序的功能说明，并机械地生成功能图的测试用例。

9.3.1白盒测试和黑盒测试9.3测试方法白盒测试和黑盒测试这两种测试方法从完全不同的起点出发，各有侧重、各有优缺点，构成互补关系。白盒测试可以有效地发现程序内部的编码和逻辑错误，但无法检验出程序是否完成了规定的功能。黑盒测试可以根据程序的规格说明检测出程序是否完成了规定的功能，但未必能够提供对代码的完全覆盖，而且规格说明往往会出现歧义或不完整的情况，这在一定程度上降低了黑盒测试的效果。因此，在实际测试中这两种方法往往被结合起来使用，一般来说在单元测试阶段白盒法使用较多而在集成测试阶段则较多用到黑盒方法。

9.3.1白盒测试和黑盒测试9.3测试方法1.静态测试静态测试（StaticTest）是对软件文档或程序进行扫描分析，不运行程序代码。采用人工检测或计算机辅助静态分析工具评审软件设计规格说明书和程序代码，度量程序静态复杂度，检查软件是否符合编程标准，静态测试只进行特性分析。

9.3.2静态测试和动态测试9.3测试方法1）编码的标准和规范标准是建立起来和必须遵守的规则。规范是建议最佳做法，推荐更好方式。2）代码走查代码走查依靠人工或借助分析工具检查程序代码以发现错误或缺陷。3）代码审查代码审查是一种正式的检查和评估方法，它是用逐步检查源代码中有无逻辑或语法错误的办法来检测故障。4）评审评审通常在审查后进行，审查小组根据代码审查的错误记录来评估该程序，决定是否需要重新进行审议。

9.3.2静态测试和动态测试9.3测试方法2.动态测试动态测试（DynamicTest）的基本特征是通过运行软件来检验软件的动态行为和运行结果的正确性，包括被测程序、测试数据和软件需求规约三个基本要素。根据动态测试在软件开发过程中所处的阶段及其作用，可分为单元测试、集成测试、系统测试、验收测试和回归测试，贯穿于整个软件开发过程的各个阶段。

动态测试包括覆盖率分析、功能确认与接口测试、性能分析等内容。

9.3.2静态测试和动态测试9.3测试方法1）覆盖率分析覆盖率分析主要对代码的执行路径覆盖范围进行评估，语句覆盖、判定覆盖、条件覆盖、条件/判定覆盖、修正条件/判定覆盖、基本路径覆盖都是从不同要求出发，为设计测试用例提出依据。2）功能确认与接口测试这部分的测试包括各个单元功能的正确执行、单元间的接口，包括单元接口、局部数据结构、重要的执行路径、错误处理的路径和影响上述几点的边界条件等内容。

9.3.2静态测试和动态测试9.3测试方法3）性能分析代码运行速度缓慢是开发过程中一个重要问题。如果不能解决应用程序的性能问题，将降低并极大地影响应用程序的质量，于是查找和修改性能瓶颈成为调整整个代码性能的关键。目前性能分析工具大致分为纯软件的测试工具、纯硬件的测试工具（如逻辑分析仪和仿真器等）和软硬件结合的测试工具三类。2.动态测试

9.3.2静态测试和动态测试9.3测试方法1.验证验证是检验软件是否已正确地实现了产品规格说明书所定义的系统功能和特性。验证过程提供证据表明软件相关产品与所有生命周期活动的要求（如正确性、完整性、一致性和准确性等）相一致。验证工作的内容：1）验证工具验证的主要工具是审查单，对于不同的验证类型有不同的审查单。例如，有需求审查单、功能设计规格说明审查单、内部设计说明审查单、测试计划审查单、代码验证审查单等。

9.3.3验证和确认9.3测试方法验证工作的内容：2）验证不同阶段的文档①验证需求：验证需求就是要保证用户的需求在转化成设计之前能得到完全理解。②验证功能设计：验证功能设计就是要确保功能设计完全符合用户的需求。③验证内部设计：验证内部设计就是确保内部设计完全符合功能设计规格说明。④验证代码：验证代码就是要确保代码完全符合内部设计规格说明。

9.3.3验证和确认9.3测试方法2.确认确认是指能够保证所开发的系统可追溯到用户需求的一系列活动。确认过程提供证据表明软件是否满足系统需求，并解决了相应问题。确认主要包括单元确认、集成确认、系统确认和验收确认。验证是检验开发的软件产品和设计规格说明书的一致性，而确认是检验产品功能的有效性，即是否满足用户的实际需求。验证和确认是互相补充的。因此应将验证和确认结合起来，发挥它们的最大作用。

9.3.3验证和确认9.3测试方法1.自动化测试软件测试的工作量往往很大，而且在软件测试的过程中有许多工作是重复性的。由于在软件生命周期中约50%的成本可能用于测试，因此如何使软件测试自动化已成为软件测试人员研究的课题。软件测试自动化的程度越高，就会使测试人员感到测试变得非常容易，同时能够帮助测试人员进行更加彻底的测试，降低软件测试的成本，帮助提高软件质量。软件测试自动化还有可能使原来一些手工不能测试的工作得以进行。

9.3.4自动化测试和随机测试9.3测试方法1.自动化测试软件测试自动化是试图用自动化手段帮助人们进行测试。软件测试活动本身质量的高低从根本上来说取决于所采用的软件测试方法。如果所采用的软件测试方法本身并不是一种好方法，也就不能指望将这种软件测试方法自动化以后能够带来高质量的测试。软件测试自动化涉及到软件测试活动的各个方面。从选择和产生测试数据、组织软件的测试运行、考察和记录软件动态运行的行为、判断软件动态行为的正确性、结束测试过程和通过软件测试结果分析软件性质等各个方面都存在可以自动化的可能。在软件生命周期中各个阶段都可以使用到各种自动化测试工具，这些工具常被称为CAST（ComputerAidedSoftwareTesting）工具。

9.3.4自动化测试和随机测试9.3测试方法自动化测试的优点：（1）具有一致性和可重复性。（2）方便进行回归测试。（3）增加软件信任度。（4）更好地利用资源。（5）速度快，效率高。

9.3.4自动化测试和随机测试9.3测试方法在以下的一些情况下可能比较适合自动化测试：（1）产品型项目。（2）能够自动编译、自动发布的系统。（3）增量式开发、持续集成的项目。（4）回归测试。（5）需要频繁运行测试。（6）多次重复、机械性动作。（7）将繁琐的任务转化为自动化测试。

9.3.4自动化测试和随机测试9.3测试方法自动化测试的局限性：（1）软件自动化测试并不能代替人的工作，不能期望将所有的测试活动进行自动化。软件测试工具不能发现所有的问题，测试人员还需要做大量的工作。（2）软件测试自动化可能降低测试的效率。（3）自动化测试不能发现大量的错误。（4）缺乏测试经验。如果测试的组织差、文档较少或不一致，则自动化测试的效果会比较差。（5）技术问题。商用软件自动化测试工具是软件产品。如果产品不具备解决问题的能力和技术支持或者产品适应环境变化的能力不强，将使得软件自动化测试工具的作用大大降低。

9.3.4自动化测试和随机测试9.3测试方法2.随机测试随机测试（Ad-hocTesting）随机测试没有书面测试用例、记录期望结果、检查列表、脚本或指令，主要是根据测试者的经验对软件进行功能和性能抽查。基本思想是对软件的输入空间进行随机取样，以此作为软件系统测试数据。随机取样可按照软件实际使用时的概率分布进行，也可按照其它概率分布进行。前者称为代表性随机测试，后者称为非代表性随机测试。

9.3.4自动化测试和随机测试9.3测试方法随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试用例（TestCase）没有覆盖到的部分。对于软件更新和新增加的功能要重点测试。重点对一些特殊点、特殊的使用环境、并发性进行检查。尤其对以前测试发现的重大Bug，进行再次测试，可以结合回归测试一起进行。

9.3.4自动化测试和随机测试9.3测试方法理论上，每一个被测软件版本都需要执行随机测试，尤其对于将要发布的版本更要重视随机测试。随机测试最好由具有丰富测试经验的熟悉被测软件的测试人员进行测试。对于被测试的软件越熟悉，执行随机测试越容易。只有不断地积累测试经验，包括具体的测试执行和对缺陷跟踪记录的分析，不断总结，才能提高。

9.3.4自动化测试和随机测试9.3测试方法目录9.1测试概述9.2测试步骤9.3测试方法9.4测试过程9.5面向对象的测试9.6系统测试管理9.7信息系统测试案例1.单元测试的定义单元测试是对软件基本组成单元进行的测试。单元测试的对象是软件设计的最小单位——模块。单元测试是在系统开发过程中要进行的最低级别的测试活动，在单元测试活动中，各独立单元模块将在与系统的其他部分相隔离的情况下进行测试。单元测试集中对源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确实现了规定的功能。其目的在于发现各个模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以并行进行单元测试。

9.4.1单元测试9.4测试过程2.单元测试的目标单元测试的主要目标是确保各单元模块编码的正确性，不仅测试代码的功能性，还要保证代码在结构上可靠和健全，并且能够在所有条件下正确响应。单元测试的具体目标有：（1）数据能够正确地流入和流出单元；（2）单元内部数据保持完整性；（3）在为限制数据加工而设置的边界处，能够正确工作；（4）单元的运行要满足特定的逻辑覆盖；（5）能够正确、有效地处理单元中发生的错误。

9.4.1单元测试9.4测试过程3.单元测试的任务单元测试任务：

1）模块接口测试

2）模块局部数据结构测试

3）模块中所有独立执行通路测试

4）模块的各条错误处理通路测试

5）模块边界条件测试

9.4.1单元测试9.4测试过程4.单元测试过程单元测试的过程主要由以下几个步骤组成：1）在详细设计阶段完成单元测试计划2）建立单元测试环境，完成测试设计和开发3）执行单元测试用例，并且详细记录测试结果4）判定测试用例是否通过5）提交《单元测试报告》

9.4.1单元测试9.4测试过程1.集成测试的定义集成测试是在软件系统集成过程中所进行的测试，将已分别通过测试的单元按照设计要求组合起来再进行的测试。主要目的是检查软件单元之间的接口是否正确。集成测试主要是测试软件单元的组合能否正常工作以及与其它组的模块能否集成起来工作，还要测试构成系统的所有模块组合能否正常工作。

9.4.2集成测试9.4测试过程2.集成测试的任务1）将各模块连接起来，检查模块调用时，数据经过接口是否丢失；

2）将各个子功能模块组合起来，检查能否达到预期要求的各项功能；

3）一个模块的功能是否会对另一个模块的功能产生不利影响；

4）全局数据结构是否有问题，会不会被异常修改；

5）单个模块的误差积累起来，是否被放大，从而达到不可接受的程度。

9.4.2集成测试9.4测试过程3.集成测试的基本方法集成测试通常采用非增量式集成测试和增量式集成测试这两种模式。（1）非增量式集成测试模式。先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序。这种方法容易出现混乱，因为测试时可能发现很多错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。 （2）增量式集成测试模式。把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完成后，再把下一个需要测试的模块结合起来测试。程序一段一段地扩展，测试的范围一步一步地增大，错误易于定位和纠正，界面的测试亦可做到完全彻底。

9.4.2集成测试9.4测试过程1.系统测试的定义通过单元测试和集成测试，仅能保证软件开发的功能得以实现，不能确认在实际运行时，它是否满足用户的需要，是否大量存在实际使用条件下会被诱发产生错误的隐患。系统测试将通过确认测试，作为基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等系统元素结合起来，在实际运行环境下对计算机系统进行一系列的组装和确认测试。系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与其矛盾的地方，系统测试用例应根据需求规格说明书来设计，并在实际运行环境下运行。

9.4.3系统测试9.4测试过程2.系统测试的基本方法1）功能测试（FunctionalTesting）功能测试是系统测试中最基本的测试，它不管软件内部的实现逻辑，主要根据产品的需求规格说明书和测试需求列表，验证产品的功能实现是否符合产品的需求规格。2）压力测试（StressTesting）压力测试也称为强度测试、负载测试。压力测试是模拟实际应用的软硬件及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试系统的性能、可靠性、稳定性等。压力测试总是迫使系统在异常的资源配置下运行。

9.4.3系统测试9.4测试过程3）容量测试容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值，系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。对软件容量的测试，能让软件开发商或用户了解该软件系统的承载能力或提供服务的能力。如某个电子商务网站所能承受的、同时进行交易或结算的在线用户数。知道了系统的实际容量，如果不能满足设计要求，就应该寻求新的技术解决方案，以提高系统的容量。

9.4.3系统测试9.4测试过程

压力测试、容量测试和性能测试的测试目的虽然有所不同，但其手段和方法在一定程度上比较相似，通常会使用特定的测试工具，来模拟超常的数据量、负载等，监测系统的各项性能指标，如CPU和内存的使用情况、响应时间、数据传输量等。一定要设法破坏它!

9.4.3系统测试9.4测试过程5）安全测试安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。6）容错测试容错测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。容错测试首先要采用各种办法强制系统发生故障，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化、检查点、数据恢复和重新启动等机制的正确性。对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。

9.4.3系统测试9.4测试过程1.验收测试的定义验收测试是在软件产品完成了功能测试和系统测试之后，在产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段，通过了验收测试，产品就进入发布阶段。验收测试一般根据产品规格说明书严格检查产品，检查产品和产品规格说明书的一致性，同时考虑用户的实际使用情况，确保所开发的软件产品符合用户的各项要求。验收测试的目标是确认被测系统满足其操作需求，并确保在将系统正式交付给用户前正常工作并可以使用。验收测试是在测试组的协助下由一个或多个用户代表来进行测试。它对应于系统开发的需求分析阶段。

9.4.4验收测试9.4测试过程2.验收测试标准完成软件验收要通过一系列黑盒测试。验收测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。无论是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确，人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意。

9.4.4验收测试9.4测试过程3.验收测试的主要内容1）配置复审 配置复审是验收复审的一个重要环节，其目的在于保证软件配置齐全、分类有序，并且包括软件维护所必需的细节。2）合法性检查 检查开发者在软件开发时，使用的开发工具是否合法。对在编程中使用的一些非本单位自己开发的，也不是由开发工具提供的控件、组件、函数库等，检查其是否有合法的发布许可。3）软件文档检查文档质量的度量准则就是评审各阶段文档的合适性。文档检查主要包括：完备性、正确性、简明性、可追踪性、自说明性、规范性。

9.4.4验收测试9.4测试过程3.验收测试的主要内容4）软件代码测试源代码一般性检查仅对系统关键模块的源代码进行抽查。软件一致性检查主要包括编译检查、装/卸载检查、运行模块检查。5）软件功能和性能检查软件功能和性能检查主要包括界面测试、可用性测试、功能测试、稳定性测试、性能测试、强壮性测试、逻辑性测试、破坏性测试、安全性测试等。6）测试结果交付内容测试结束后，由测试组填写软件测试报告，并将测试报告与全部测试材料一并交给用户代表。测试报告主要有软件测试计划、软件测试日志、软件文档检查报告、软件代码测试报告、软件系统测试报告、测试总结报告、测试人员签字登记表。

9.4.4验收测试9.4测试过程4.α、β测试一个软件产品，可能拥有众多用户，不可能由每个用户验收，此时多采用称为α、β测试的过程，以期发现那些似乎只有最终用户才能发现的问题。α测试是指软件开发公司组织内部人员模拟各类用户行为，对即将面市软件产品(称为α版本)进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。经过α测试调整的软件产品称为β版本。β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。

9.4.4验收测试9.4测试过程目录9.1测试概述9.2测试步骤9.3测试方法9.4测试过程9.5面向对象的测试9.6系统测试管理9.7信息系统测试案例1.对认定的对象的测试

OOA中认定的对象是对问题空间中的结构、其它系统、设备、被记忆的事件、系统涉及的人员等实际实例的抽象。对它的测试可以从如下方面考虑：（1）认定的对象是否全面，其名称应该尽量准确、适用，问题空间中所涉及到的实例是否都反映在认定的抽象对象中。（2）认定的对象是否具有多个属性。只有一个属性的对象通常应看作其它对象的属性而不是抽象为独立的对象。

9.5.1面向对象层次结构测试9.5面向对象的测试1.对认定的对象的测试（3）对认定为同一对象的实例是否有共同的、区别于其它实例的共同属性，是否提供或需要相同的服务，如果服务随着不同的实例而变化，认定的对象就需要分解或利用继承性来分类表示。（4）如果系统没有必要始终保持对象代表的实例信息、提供或者得到关于它的服务，那么认定的对象也无必要。

9.5.1面向对象层次结构测试9.5面向对象的测试2.对认定的结构的测试认定的结构指的是多种对象的组织方式，用来反映问题空间中的复杂实例和复杂关系。认定的结构分为两种：分类结构和组装结构。分类结构体现了问题空间中实例的一般与特殊的关系；组装结构体现了问题空间中实例的整体与局部的关系。

9.5.1面向对象层次结构测试9.5面向对象的测试认定的分类结构测试要点如下：对于结构中的一种对象，尤其是处于高层的对象，是否在问题空间中含有不同于下一层对象的特殊可能性，即是否能派生出下一层对象；对于结构中的一种对象，尤其是处于同一低层的对象，是否能抽象出在现实中有意义的更一般的上层对象；对所有认定的对象，是否能在问题空间内向上层抽象出在现实中有意义的对象；高层的对象的特性是否完全体现下层的共性，低层的对象是否有高层特性基础上的特殊性。

9.5.1面向对象层次结构测试9.5面向对象的测试认定的组装结构测试要点如下：整体（对象）和部件（对象）是否在考虑的问题空间中有实际应用，其组装关系是否符合现实的关系。整体（对象）中是否遗漏了反映在问题空间中的有用部件（对象）。部件（对象）是否能够在空间中组装新的有现实意义的整体（对象）。

9.5.1面向对象层次结构测试9.5面向对象的测试3.对构造的类层次结构的测试

为了能充分发挥面向对象的继承共享特性，OOD的类层次结构通常基于OOA中产生的分类结构的原则来组织，着重体现父类和子类间的一般性和特殊性。在当前的问题空间，对类层次结构的要求是能在解空间里构造实现全部功能的结构框架。为此测试要注意如下几个方面：类层次结构是否涵盖了所有定义的类；是否能体现OOA中所定义的实例关联、消息关联；子类是否具有父类没有的新特性；子类间的共同特性是否完全在父类中得以体现。

9.5.1面向对象层次结构测试9.5面向对象的测试在面向对象软件测试中，单元的概念发生了变化。封装的特性使每个类和类的实例（对象）包装了属性（数据）和操纵这些数据的操作。最小的可测试单位是封装的类或对象，类包含一组不同的操作，因此，单元测试的意义发生了较大变化。已经不再是孤立地测试单个操作，而是将操作作为类的一部分。父类中定义的某个操作被许多子类继承。但在实际应用中，不同子类中的某个操作在使用时又有细微的不同，所以还必须对每个子类中的某个操作进行测试。

9.5.2面向对象的单元测试9.5面向对象的测试根据测试层次结构，面向对象软件测试总体上呈现从单元级、集成级到系统级的分层测试结构。根据测试层次结构确定相应的测试活动，并形成相应的层次如表7-1所示。由于面向对象软件从宏观上来看是各个类之间的相互作用，因此，测试方法中将对类层的测试作为单元测试，而对于由类集成的模块测试作为集成测试，系统测试与传统测试层次相同。

9.5.2面向对象的单元测试9.5面向对象的测试传统的集成测试，有两种方式通过集成已完成的功能模块进行测试。第一，自顶向下集成；第二，自底向上集成。因为面向对象软件没有层次的控制结构，传统的自顶向下和自底向上集成策略已不能再使用。一次集成一个操作到类中（传统的增量集成方法）通常是不可能的。面向对象的集成测试通常需要在整个程序编译完成后进行。

9.5.3面向对象的集成测试9.5面向对象的测试面向对象的程序是由若干对象组成的，这些对象互相协作以解决某些问题。对象的协作方式决定了程序能做什么，从而决定了这个程序执行的正确性。因此，一个程序中对象的正确协作，即交互对于程序的正确性是非常关键的。交互测试的重点是确保对象（这些对象的类已被单独测试过）的消息传送能够正确进行。交互测试的执行可以使用嵌入到应用程序中的交互对象，或者在独立测试工具（例如Tester类）提供的环境中，交互测试通过使得该环境中的对象相互交互而执行。

9.5.3面向对象的集成测试9.5面向对象的测试2.面向对象集成测试的常用方法常用方法有抽样测试和正交阵列测试。1）抽样测试 抽样测试提供了一种运算法则，它使我们能够从一组可能的测试用例中选择一个测试系列。但并不要求一定要首先明确如何来确定测试用例的总体。测试过程的目的在于定义感兴趣的测试总体，然后定义一种方法，以便在这些测试用例中选择哪些被构建、哪些被执行。2）正交阵列测试 正交阵列测试提供了一种特殊的抽样方法，这种方法通过定义一组交互对象的配对方式组合，以尽力限制测试配置组合数目的激增。

9.5.3面向对象的集成测试9.5面向对象的测试系统测试是测试整个系统以确定是否能够满足所有行为，测试目的主要有：第一，找出系统中存在的缺陷；第二，发现导致实际操作和系统需求之间存在差异。系统测试应该尽量搭建与用户实际使用环境相同的测试平台，应该保证被测系统的完整性，对没有的系统设备或部件，也应有相应的模拟手段。系统测试时，应该参考OOA分析的结果，对应描述的对象、属性和各种服务，检测软件是否能够完全“再现”问题空间。系统测试不仅是检测软件的整体行为表现，从另一个侧面看，也是对软件开发设计的再确认。

9.5.4面向对象的系统测试9.5面向对象的测试1）功能测试 测试是否满足开发要求，是否能够提供OO设计所描述的功能，用户的需求是否得到满足。功能测试是系统测试最常用和必须的测试，通常以正式的软件规格说明书为测试标准。2）性能测试 测试软件的运行性能。这种测试常常与强度测试结合进行，需要事先对被测软件提出性能指标，如传输连接的最长时限、传输的错误率、计算的精度、记录的精度、响应的时限和恢复时限等。

9.5.4面向对象的系统测试9.5面向对象的测试3）强度测试 测试系统的能力最高实际限度，即软件在一些超负荷的情况下，功能实现情况。如要求软件某一行为的大量重复、输入大量的数据或大数值数据、对数据库进行大量复杂的查询等。4）恢复测试 采用人工干扰使软件出错，中断使用，检测系统的恢复能力，特别是通讯系统。恢复测试时，应该参考性能测试的相关测试指标。

9.5.4面向对象的系统测试9.5面向对象的测试5）安全测试 验证安装在系统内的保护机构确实能够对系统进行保护，使之不受各种各样的干扰。在进行安全测试时，需要设计一些测试用例试图突破系统的安全保密措施，检验系统是否有安全保密的漏洞。6）可用性测试 测试用户是否能够满意使用。具体体现为操作是否方便，用户界面是否友好等。系统测试需要对被测的软件结合需求分析做仔细的测试分析，建立测试用例。

9.5.4面向对象的系统测试9.5面向对象的测试目录9.1测试概述9.2测试步骤9.3测试方法9.4测试过程9.5面向对象的测试9.6系统测试管理9.7信息系统测试案例测试管理是对测试活动进行组织、计划、监管和控制，确保测试工作在信息系统质量保障中发挥更好的作用，主要包括以下内容。1．制订测试计划确定各阶段的测试目标和策略，明确要完成的测试任务，估算完成测试任务所需的时间和资源，设计测试组织和岗位职责，安排测试活动和分配资源，部署跟踪和控制测试过程的任务，形成测试计划。2．设计测试方案根据测试计划设计测试方案，包括各测试阶段使用的测试用例，并提交评审后使用。

9.6.1测试管理概述9.6系统测试管理3．实施测试方案使用测试用例运用程序，将获得的运行结果与预期结果进行比较和分析，记录、跟踪和管理系统故障，形成测试报告。4．测试配置管理测试配置管理是软件配置管理的子集，应用于测试的各阶段。5．测试资源管理测试资源管理主要包括对人力资源和工作场所、相关设施和技术支持的管理。6．测试过程监控测试过程监控是指采用适宜的方法对上述测试过程及结果进行实时监控，以保障测试过程的有效性。

9.6.1测试管理概述9.6系统测试管理1．确定测试小组的组织模式根据测试人员具有的技能，测试小组可以分为基于技能的组织模式和基于项目的组织模式。基于技能的组织模式要求每个测试人员关注自己的专业领域，必须掌握专业测试工具的使用方法和复杂的测试技术，适用于科技领域的信息系统测试。基于项目的测试模式可以将不同测试技能水平的人员分配到一个项目中，分工协作，以确保测试工作的顺利开展。

9.6.2测试组织管理9.6系统测试管理2．组建测试小组组建测试小组时，应按照测试工作负荷配置合适的测试人员。复杂的测试工作应由测试工程师负责，他们具有独立的测试技能，能够编制测试计划，设计测试用例，熟练使用先进的测试工具，对软件故障进行隔离等。较为简单的测试工作可交由初级测试技术人员承担。

9.6.2测试组织管理9.6系统测试管理3．安排测试任务，估算测试工作量明确测试任务，对各项任务进行合理的组织安排，并根据测试任务估算测试工作量。4．确定测试文档确定需要交付和归档的测试文档。这些测试文档一般包括测试计划文件、测试用例文档、测试日志文档、测试实践报告和测试总结报告等。5．管理测试件测试件也是一类软件，需要管理好。测试件一般有测试工具、测试驱动程序、测试桩模块等。

9.6.2测试组织管理9.6系统测试管理6．确定测试需求测试需求主要解决“测试什么”，即指明被测对象中什么需要测试。确定测试需求通常是以信息系统开发需求为基础的分析，通过对需求的细分化和分解，形成测试内容。7．组织测试设计测试设计的主要任务是确定测试各阶段需要运用的测试要素，如测试用例等。组织和协调好测试设计任务是系统测试管理的重要环节之一。

9.6.2测试组织管理9.6系统测试管理1．测试准备任命测试组长，组建测试小组，参加有关项目计划、分析和设计会议，获取需求分析文档、系统设计文档和程序编写文档，参加产品相关知识的培训。2．测试计划编制测试计划的目标是确定测试范围、测试策略和测试方法，以及对可能出现的问题或风险的所需的资源和投入进行分析和估计，以指导测试的执行。测试计划的内容通常包括测试目的、测试标准、测试策略、资源配置、责任明确、进度安排、风险分析、测试用例的设计方法、使用和维护策略、测试工具的开发和使用等。

9.6.3测试过程管理9.6系统测试管理3．测试需求分析测试需求是根据测试目标及软件规格说明和相关接口需求说明文件，明确各种测试需求，包括环境需求、对测试对象的要求、测试工具需求、测试代码需求、测试数据要求等。测试需求分析必须保证需求的可跟踪性和全覆盖性。4．测试设计测试设计描述测试各阶段需要运用的测试要素，包括测试用例、测试工具、测试代码、测试规程的设计思路、设计准则和具体内容。

9.6.3测试过程管理9.6系统测试管理5．测试执行建立和配置测试环境，根据用例准备测试数据，执行测试。6．测试结果分析测试结束后，对测试结果进行分析，以确定软件产品质量，为产品的改进或发布提供数据和支持，同时做好测试结果的审查和分析，做好测试报告的撰写和审查。

9.6.3测试过程管理9.6