《软件工程——理论、方法与实践》课件第12章.ppt

1、1 1第12章 软件验证和确认第12章 软件验证和确认12.1 验证和确认12.2 软件审查12.3 软件测试12.4 软件测试方法12.5 面向对象的测试12.6 IBM Rational Functional Tester本章小结习题2 2第12章 软件验证和确认12.1 验证和确认传统的测试观念认为：应等待系统开发完毕，再对其进行测试，但这是极为不合理的。通常，影响软件质量的因素不只限于程序代码本身，还与软件过程的各个开发活动，如需求分析、软件设计等工作密切相关。因此表现在程序中的错误，并不一定是编码所引起的。错误在初期也许只是范围很小的隐藏问题，但各开发阶段的连续性会使其逐步扩展。如果

2、早期开发中出现的错误不能及时发现和解决，将带到设计、编码、测试等各阶段，影响会逐步扩大。3 3第12章 软件验证和确认有统计表明，因需求分析设计不完整而引起的功能错误占整个软件错误的27%；因总体设计错误而引起的系统错误占整个软件错误的16%；由编码错误引起的数据错误占整个软件错误的10%；因程序员编码引起的编程错误占整个软件错误的4%；由文档和硬件所引起的其他错误占整个软件错误的4%。因此，对软件的错误检查工作应着眼于整个软件生存期，以保证软件的质量。据有关机构研究表明：在开发周期中，每推后一步实施错误检查，成本就会增加10%。因此，若不能尽早地检出错误，则在后期活动和软件交付后，会因纠正这

3、些错误而付出很高的代价，并有可能导致系统不可用等严重的后果。4 4第12章 软件验证和确认验证和确认(Verification&Validation，V&V)工作是在整个软件生命周期中对软件的规范性评估活动，以保证软件开发各个环节的正确性。软件验证(Verification)试图证明在软件生存期的各个阶段，软件产品或中间产品是否能满足客户需求，包括逻辑协调性、完备性和正确性。5 5第12章 软件验证和确认软件确认(Validation)是一系列的活动和过程，其目的是保证软件产品能够符合其描述的要求。它包括需求规格说明的确认和程序的确认，而程序的确认又分为静态确认和动态确认。静态确认一般不在计算

4、机上实际执行程序，而是通过人工分析或程序正确性证明来确认程序的正确性；动态确认主要是通过动态分析和程序测试来检查程序的执行状态，以确认程序是否有问题。显然，验证和确认是两个相互独立但却相辅相成的活动，二者很容易混淆。6 6第12章 软件验证和确认 验证的作用是检查软件是否符合它的描述，因此验证活动应该检查系统是否满足了它所定义的功能的和非功能的需求，强调对于过程的检验。而确认应该保证软件满足客户的期望。它不局限于检查系统是否符合它的描述，而是要说明软件是否最终满足了客户的要求，强调对于结果的检验。但是，验证和确认的目标都是要发现软件缺陷，并确定软件系统是否实现了需要的功能和特性。7 7第12章

5、 软件验证和确认验证与确认工作都是软件质量的保证活动。在对需求理解与表达的正确性、设计与表达的正确性、实现的正确性以及运行的正确性的验证中，任何一个环节上发生了问题都可能在软件测试中表现出来。在V&V过程中，可以使用软件审查和软件测试两种系统检查和分析技术。软件审查是对系统的各种表示形式，如需求文档、设计图和程序源代码等，进行分析和检查。这个过程贯穿软件开发过程的所有阶段。审查活动可以辅之一些能对系统源文本和相关联的文档的自动分析。软件审查和自动分析是一种静态V&V技术，不需要系统的执行。8 8第12章 软件验证和确认软件测试是使用测试数据对软件的实现进行运行检查，查看系统的输出内容以及运行行

6、为是否符合要求。测试是V&V过程中的动态技术，需要让系统运行起来以观察其动态行为。图12.1给出了软件检查和软件测试在软件过程中的位置。从图中可以看出软件检查可以用于所有阶段的活动，而软件测试只能用于原型或可执行程序完成以后。9 9第12章 软件验证和确认图12.1 静态、动态和有效性检验1010第12章 软件验证和确认 审查技术包括程序审查、自动化的源代码分析和形式化检验。但是，静态的软件审查只能检查程序及其描述之间的吻合程度，不能够说明软件真是有用的，并且也不能检验软件的非功能特性，如性能和可靠性等。因此，软件测试就是必不可少的，系统的有效性和非功能特性只有通过软件测试才能验证。1111第

7、12章 软件验证和确认12.2 软 件 审 查12.2.1 程序审查软件审查涉及文档和程序的审查，程序审查即对所实现的程序源代码审查，其审查的目标是评审和检出程序中的错误和缺陷，可能是逻辑上的错误，也可能是错误的条件设置或是与机构和项目定义的标准不相符。1212第12章 软件验证和确认程序审查通常可关注以下几点：所有的变量是否都有初始化？所有常量是否符号化？数组上下界定义是否正确？条件语句的每个条件设置是否正确？循环是否一定会结束？Case语句是否考虑了所有情形？组合语句的括号是否匹配？所有的输入数据是否都用到？所有的输出之前是否被赋值？1313第12章 软件验证和确认 所有的函数和过程调用接

8、口参数类型、位置和数目是否匹配？多个组件共享的数据结构定义是否正确？链接对象被修改后，相关的链接指针是否修改正确？使用动态存储分配时，是否正确地分配和回收？异常处理时，是否考虑了所有可能出现的异常情况？1414第12章 软件验证和确认程序审查的过程是一个正式的过程，至少由4个人组成的小组来实行，包括程序作者、代码阅读者、测试者和仲裁者。审查小组应系统地分析代码并指出可能的缺陷。为了更好地完成审查工作，程序审查活动开始之前，首先需要对被检查的代码有一个精确的描述，因为要详细审查每一个程序组件，并发现其可能存在的缺陷，如果没有一个完整、准确的描述，是难以做到的；其次，审查小组的成员应该熟悉机构的标

9、准，以能检出程序中不符合标准的部分。另外，所审查的程序集合应是一个最新的、语法正确的代码版本，否则由于版本的差异会造成审查结果的错误和工作量的浪费。图12.2是一个通用的程序审查过程，为很多软件开发机构所采用。1515第12章 软件验证和确认图12.2 审查过程1616第12章 软件验证和确认程序审查的效率，即一定的时间内检查的代码量取决于审查小组的经验、所使用的程序设计语言以及系统相关联的应用域。根据IBM对审查过程的计算，有以下结论：(1)在总体观察阶段，每小时大约可以分析500行源程序代码。(2)在个别准备阶段，每小时大约可以检查125行源程序代码。(3)在会议期间，每小时能审查9012

10、5行代码。1717第12章 软件验证和确认12.2.2 自动静态分析自动静态分析能检查出来的缺陷在表12.1中列出。有些缺陷并不一定就会使程序出错，比如变量未被初始化，但这些编码过程中的缺陷，却可能是一些错误产生的来源。自动静态分析列出程序中存在的缺陷和错误，有助于消除程序中隐含的错误源，有助于降低软件开发代价和提高软件质量。1818第12章 软件验证和确认1919第12章 软件验证和确认12.3 软 件 测 试12.3.1 软件测试的目的和原则Glen Myers在他的软件测试著作中就软件测试提出如下观点：测试是一个为了寻找错误而运行程序的过程；一个好的测试用例是指很可能找到迄今为止尚未被发

11、现的错误的用例；一个成功的测试是指揭示了迄今为止尚未被发现的错误的测试。2020第12章 软件验证和确认人们在长期测试实验中积累了不少经验，总结出了测试的一些基本原则以帮助提高测试的效率：(1)尽早地并不断地进行软件测试。(2)程序员或程序设计机构应避免测试自己设计的程序。(3)测试用例中不仅要有输入数据，还要有与之对应的预期结果。(4)测试用例的设计不仅要有合法的输入数据，还要有非法的输入数据。(5)在对程序修改之后要进行回归测试。2121第12章 软件验证和确认(6)程序中尚未发现的错误的数量通常与该程序中已发现的错误的数量成正比。(7)妥善保留测试计划、全部测试用例、出错统计和最终分析报

12、告，并把它们作为软件的组成部分之一，为维护提供方便。(8)应当对每一个测试结果做全面检查。(9)严格执行测试计划，排除测试的随意性。2222第12章 软件验证和确认12.3.2 单元测试通常软件测试过程活动分为单元测试、集成测试、系统测试和确认测试。图12.3显示了软件测试的4个步骤。2323第12章 软件验证和确认图12.3 软件测试的过程2424第12章 软件验证和确认1接口测试由于模块接口是数据出入模块的通道。接口不正常，其他测试则无从进行，所以在其他测试开始之前，首先要对通过模块接口的数据进行测试。接口测试应做如下考虑：(1)模块接收实际参数个数是否与模块形式参数个数一致，实际参数与形

13、式参数的属性是否匹配，实际参数与形式参数的单位是否一致。(2)调用其他模块时，所给的实际参数的个数是否与被调用模块的形参个数相等，实际参数的属性是否与被调模块的形参属性匹配，实际参数的单位是否与被调模块的形参单位匹配。2525第12章 软件验证和确认(3)调用内部函数所用参数的个数、属性和次序是否正确。(4)是否存在与当前入口点无关的参数引用。(5)输入是否仅改变了形式参数。(6)全程变量在各模块中的定义是否一致。(7)常数是否当作变量传送。2626第12章 软件验证和确认若一个模块需要完成外部的输入或输出时，还应检查下述各点：(1)文件属性是否正确。(2)OPEN/CLOSE语句是否正确。(

14、3)格式说明与I/O语句是否匹配。(4)缓冲器大小与记录长度是否匹配。(5)文件是否先打开后使用。(6)文件结束的条件是否处理过。(7)I/O的错误是否处理过。(8)输出信息中是否有正文的错误。2727第12章 软件验证和确认2局部数据结构测试检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源。应仔细设计测试用例，力求发现以下可能的错误：(1)不正确或不一致的说明。(2)错误的初始化或错误的缺省值。(3)拼写错或截短的变量名。(4)不一致的数据类型。(5)上溢、下溢和地址错误。2828第12章 软件验证和确认3重要的执行路径测试计算中常见的

15、错误包括：(1)算术运算优先次序不正确或理解错误。(2)运算方式不正确。(3)初始化不正确。(4)精度不够。(5)表达式的符号表示错误。2929第12章 软件验证和确认比较判断与控制流常常紧密相关，因而测试用例还应致力于发现下列错误：(1)不同的数据类型比较。(2)逻辑运算不正确或优先次序错误。(3)因为精度误差造成本应相等的量不相等。(4)比较不正确，或变量不正确。(5)循环不终止或循环终止不正确。(6)当遇到分支循环时，出口错误。(7)错误地修改循环变量。3030第12章 软件验证和确认4异常处理测试一个好的设计应能预见各种出错条件，并预设各种出错处理路径。出错处理路径同样需要认真测试，测

16、试应着重检查下列问题：(1)错误描述难以理解。(2)错误提示与实际错误不相符。(3)在程序自定义的出错处理段运行之前，系统已介入。(4)对错误的处理不正确。(5)提供的错误信息不足，无法确定错误位置和差错。3131第12章 软件验证和确认5边界测试单元测试首先应按照图12.4所示配置测试环境，设计辅助测试模块驱动(Driver)模块和桩(Stub)模块。驱动模块用来调用被测模块，主要用来接收测试数据，启动被测模块，打印测试结果。桩模块接收被测试模块的调用，用来模拟被测模块的调用模块。其次，要编写测试数据。根据关于单元测试要解决的测试问题设计测试用例。然后用测试用例运行待测程序，进行动态测试，并

17、给出单元测试报告。3232第12章 软件验证和确认图12.4 单元模块测试环境3333第12章 软件验证和确认12.3.3 集成测试 1自顶向下方法 自顶向下集成从主控模块(“主程序”)开始，沿着软件的控制层次从上往下集成模块并进行测试，可采用深度优先和宽度优先两种策略。深度优先策略按照系统的纵向路径逐步集成测试系统，先组装在系统结构的一条主控路径上的所有模块。主控路径的选择取决于软件的应用特性，如选取最左边的路径，先组合模块M1、M2和M5，接着是M8，如果M2的某个功能需要，可组合M6，然后再构造中央和右侧的控制通路，参看图12.5。3434第12章 软件验证和确认图12.5 自顶向下集成

18、测试3535第12章 软件验证和确认自顶向下综合测试可归纳为五个步骤：(1)用主控制模块做测试驱动程序，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代。(2)依据所选的集成策略(深度优先或宽度优先)，每次只用一个实际模块替换一个桩模块。(3)每集成一个模块立即测试一遍。(4)只有每组测试完成后，才用实际模块替换下一个桩模块。(5)为避免引入新错误，需不断进行回归测试(即全部或部分地重复已做过的测试)。3636第12章 软件验证和确认2自底向上结合自底向上测试是从软件结构最低层的模块开始向上组装模块，进行集成测试，当测试到较高模块时，所需的下层模块均已测试完毕，因而不再需要桩模块。自底

19、向上综合测试可归纳为以下四个步骤：(1)把底层模块组合成一个特定软件子系统，见图12.6中的模块族1、2、3。3737第12章 软件验证和确认图12.6 自底向上集成测试3838第12章 软件验证和确认(2)为每个模块族设计一个驱动软件，作为测试的控制程序，以协调测试用例的输入和输出；图12.6中，虚线连接的D1、D2、D3是各个族的驱动程序。(3)对模块族进行测试。(4)按系统结构逐层向上，用实际模块替换驱动程序，将模块族集成起来组装成新的模块族再进行测试，直至全部完成。例如，在图12.6中，族1、族2属于Ma，因而去掉D1和D2将这两个族直接与Ma接口；同样族3与Mb接口前将D3去掉；Ma

20、与Mb最后与Mc接口。3939第12章 软件验证和确认12.3.4 系统测试1恢复测试 恢复测试主要检查系统的容错能力。当系统出错时，能否在指定的时间内修正错误并重新启动系统。恢复测试首先要采用不同的方式强迫系统出现故障，然后验证系统是否能尽快恢复。如果恢复由系统自动完成，则将重新初始化时间、检测点、数据恢复情况以及重新启动时间等作为软件的可恢复性评价指标。若恢复需人工干预，则需估算出修复的平均时间，确定其是否在可接受的限制范围以内。4040第12章 软件验证和确认2安全性测试系统的安全性测试是要检验在系统中已存在的安全性、保密性措施是否发挥作用，有无漏洞。在安全性测试过程中，测试人员应采用各

21、种办法尝试攻击系统。如设法截取或破译口令；专门编写软件破坏系统的保护机制；故意导致系统失败，企图趁系统恢复之机非法进入；试图通过浏览非保密数据而导出自己所需的信息；等等。系统安全设计的准则是使非法入侵的代价超过被保护信息的价值，这样攻击就会失去意义。4141第12章 软件验证和确认3压力测试压力测试是要检查在系统运行环境中从正常到发生故障可承受的负载。压力测试通常在一个非正常数量、频率等荷载下运行一个系统。如当中断的平均速度是一个或两个时，设计每秒产生十个中断的测试；定量地增长数据输入率，检查输入子功能的反应能力；运行需要最大内存或其他资源的测试用例；运行可能导致虚拟操作系统崩溃的测试用例等。

22、4242第12章 软件验证和确认4性能测试性能测试是测试软件被组装进系统的环境下运行时的性能。性能测试应覆盖测试过程的每一步。即使在单元测试阶段，单个模块的性能也可以通过白盒测试来评价，而不是等到所有系统模块全组装以后，再确认系统的真正性能。性能测试有时是与压力测试联系在一起的，常常需要硬件和软件测试设备。4343第12章 软件验证和确认12.3.5 确认测试确认测试又称有效性测试、合格测试或验收测试，是软件交付前的最后测试。实际上，对于软件开发人员来说，不可能完全预见用户实际使用程序的情况。如用户可能会使用一些非常规的数据组合，也可能难以理解系统给出的输出或提示信息等。因而，当开发者为用户建

23、立起软件后，还要由用户进行一系列的确认测试，以确保用户的所有需求得到满足。4444第12章 软件验证和确认12.4 软件测试方法软件测试通过动态执行被测程序来完成，由执行结果分析程序可能出现的错误。软件测试把程序看做一个函数，输入的全体称为函数的定义域，输出的全体称为函数的值域，函数则描述了输入的定义域与输出值域的关系。4545第12章 软件验证和确认这样软件测试的算法可归纳为：(1)选取定义域中的有效值，或定义域外无效值。(2)对已选取的值决定预期的结果。(3)用选取的值执行程序。(4)观察程序行为，记录执行结果。(5)将程序运行的结果与预期的结果相比较，不吻合则程序有错。4646第12章

24、软件验证和确认12.4.1 白盒测试方法 如果已知软件内部结构和算法，就可以测试其内部是否符合设计要求。这种测试方法称为白盒测试(White-box Testing)，是对软件的过程性细节进行检验。白盒测试又称为结构测试或逻辑驱动测试，是将测试对象比作一个打开的盒子，它允许测试人员利用程序内部的逻辑结构和相关信息来设计或选择测试用例，对软件的逻辑路径进行测试，可以在不同点检查程序的状态，以确定实际状态与预期状态是否一致。4747第12章 软件验证和确认从表面来看，白盒测试是可以进行完全的测试的，从理论上讲也应该如此。只要能确定测试模块的所有逻辑路径，并为每一条逻辑路径设计测试用例，并评价所得到

25、的结果，就可得到100%正确的程序。但在实际测试中，这种穷举法是无法实现的，因为即使是很小的程序，也可能会出现数目惊人的逻辑路径。如图12.7所示是一个小程序的流程图。4848第12章 软件验证和确认图12.7 白盒测试中的穷举测试4949第12章 软件验证和确认1基本路径测试 基本路径测试是Tom MeCabe提出的一种白盒测试技术，其基本思想是：以软件过程描述为基础(例如，详细设计的程序流程图、PDL或源代码等)，通过分析它的控制流程计算复杂度，导出基本路径集合，并设计一组测试用例，确保程序中的每个语句至少执行一次，每一条路径都至少通过一次。路径测试的测试用例设计可借助于程序流图。5050

26、第12章 软件验证和确认程序流图(控制流图)简称流图，它将程序流程图或程序代码中的结构化元素转变为一个有向图，可以认为是流程图的简化形式。在程序控制结构中，分支、循环节点被称为谓词节点。在将程序转换为程序流图时，每个谓词节点对应于程序流图中的一个节点，不含谓词节点的多个顺序语句可映射为流图的一个节点；如果分支判断条件中含有复合条件，则要增加谓词节点。图12.8所示为由程序流程图导出的程序流图。5151第12章 软件验证和确认图12.8 程序流程图及对应的程序流图5252第12章 软件验证和确认在确立程序流图后，可根据程序流图找出需测试的基本路径，在此基础上设计测试用例。因此，基本路径测试主要有

27、4个步骤：(1)根据详细设计或源程序代码结果，导出程序流图。例如，图12.9所示为一个根据求平均值程序导出的控制流图。5353第12章 软件验证和确认图12.9 求平均值的流程图5454第12章 软件验证和确认(2)计算需测试的基本路径数，这可以通过计算环路复杂性来达到。根据MeCabe的定义，环路复杂性根据程序流图边数和节点数来计算：V(G)=E-N+2其中，E是程序流图中的边数；N是流图的节点数。5555第12章 软件验证和确认该公式适用于结构化程序，即程序仅含一个入口和一个出口。环路复杂性V(G)还可以用谓词节点数来计算，则V(G)=谓词节点数+1。因此，图12.9所对应的程序流图的环路

28、复杂性为V(G)=17-13+2=6或 V(G)=谓词节点数+1=5+1=6环路复杂性确立了需要测试的基本路径数，在本例中，表明至少应测试6条基本路径。环路复杂性同样是度量一个程序复杂程度的重要指标。其数值越大，程序的复杂程度越高。5656第12章 软件验证和确认(3)确定线路的基本路径集，也即独立路径集。所谓独立路径是指至少引入程序的一个新处理语句集合或一个新条件的路径。如果使用程序流图术语描述，独立路径是至少包含一条在定义该路径之前不曾用过的边。利用环路复杂性可以导出程序基本路径集合中独立的路径数，这是保证程序中每个语句至少执行一次所需要的测试路径数量的下限。5757第12章 软件验证和确

29、认根据上面的计算，图12.9有6条独立路径。路径1：12101113 路径2：12101213 路径3：123101113 路径4：12345892 路径5：123456892 路径6：12345678925858第12章 软件验证和确认(4)设计测试用例。软件测试人员可以根据判断点给出的条件，选择适当数据作为测试用例，以保证每一条路径可以被测试。每一个测试用例执行后，与预期的结果进行比较，如果所有的测试用例都执行完毕，则可以确信程序中所有可执行语句至少被执行了一次。值得注意的是，有一些独立路径往往不是完全独立的(如路径1)，它可能是程序正常控制的一部分。在测试时，这些路径可以是另一条路径测试

30、的一部分。5959第12章 软件验证和确认2逻辑覆盖测试 逻辑覆盖是一组覆盖方法的总称，它以程序的内部逻辑结构为基础设计测试用例。具体可分成语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖等。图12.10给出一个小程序的流程图。6060第12章 软件验证和确认图12.10 一个小程序的流程图6161第12章 软件验证和确认 语句覆盖要选择足够的测试用例，使得被测程序的每条语句至少执行一次。例如，可以选取测试用例的输入为：A=2，B=0，X=3，可覆盖路径sacbed。则可以执行程序中的每一条语句，达到语句覆盖的标准。语句覆盖是比较弱的覆盖标推。判定覆盖又称分支覆盖，它是选择足够的测试用

31、例，使得程序中每个判定至少取值一次真和一次假，从而使每个判定框的每一个分支至少执行一次。6262第12章 软件验证和确认 例如，为了使(A1)and(B=0)出现一次真，也出现一次假，同时，使(A=2)or(X1)出现一次真，也出现一次假。因为：A=3，B=0使(A1)and(B=0)真；A=3，X=1使(A=2)or(X1)假；A=2，B=1使(A1)and(B=0)假；A=2，X=1使(A=2)or(X1)真。所以，综合起来可以选取A=3，B=0，X=1，覆盖路径sacbd；A=2，B=1，X=1，覆盖路径sabed。这时，测试用例可以不考虑X1和X1，B=0，A1，B0分别各出现一次。同

32、理，在b点的判断条件要考虑A=2，X1，A2，X1分别各出现一次。根据条件覆盖的标准，测试用例可以选取：A=2，B=0，X=1(满足A1，B=0，A=2，X1)的条件；A=1，B=1，X=2(满足A1，B0，A=2，X1)的条件。显然，这一组数据满足了条件覆盖的标准，但不满足判定覆盖标准，因为在第二个判定点b中，只执行了真值的分支。6464第12章 软件验证和确认按照判定覆盖标准选取的测试用例不一定能满足条件覆盖标准，反之，用条件覆盖标准选取的测试用例不一定能满足判定覆盖标准。判定条件覆盖就是同时以这两种标准来选取测试用例的。判定条件覆盖是选用足够的测试用例，使得判定表达式中每个条件都取得各种

33、可能的值，并且每个判定表达式也都取得各种可能的结果。6565第12章 软件验证和确认根据这个标准，可以选用下面的测试用例：A=2，B=0，X=3(满足A1，B=0，A=2，X1的条件)，覆盖路径sacbed；A=1，B=1，X=1(满足A1，B0，A=2，X1的条件)，覆盖路径sabd。条件组合覆盖是选择足够的测试用例，使得每个表达式中条件的各种可能组合都至少出现一次，表12.2列出了对应此例的8种组合及测试用例。6666第12章 软件验证和确认6767第12章 软件验证和确认测试用例选取时应基于用尽量少的测试用例覆盖尽可能多的条件组合，因此表中选取一个测试用例覆盖了两种条件组合。注意，能满足

34、条件组合覆盖标准的测试用例，同时也满足判定覆盖、条件覆盖和判定条件覆盖标准，显然，它是这几种覆盖标淮中最强的。.6868第12章 软件验证和确认3循环测试对于单个循环，假设n是允许通过循环的最大次数，应该进行下列测试：跳过整个循环(零循环)；只执行循环一次(一次循环)；执行循环两次(两次循环)；执行循环m次，其中mn-1(某个中间次数循环)；执行循环n-1、n、n+1次(比最大次数少一次、最大次数、比最大次数多一次循环)。6969第12章 软件验证和确认对于嵌套循环：从最内层循环开始测试，把其他循环都设置为最小值；对最内层循环使用简单测试方法，使外层循环的迭代参数取最小值，并且为越界或非法值增

35、加一些额外的测试；由内向外，对下一个循环进行测试，保持它的所有外层循环的循环变量为最小值，其他的嵌套循环的循环变量取“典型”值。如此连续进行，直到测试完所有循环。7070第12章 软件验证和确认12.4.2 黑盒测试方法黑盒测试主要检查以下错误：(1)功能不正确或者不完整；(2)界面错误；(3)数据结构或者外部数据库访问错误；(4)性能错误；(5)初始化或者终止错误。7171第12章 软件验证和确认1等价类划分 等价类划分法把所有可能的输入数据划分成若干个等价类(子类，子集)，每个类中的任何一个元素，在测试中的作用等价于这一类中的其他元素。也就是说，如果用等价类中的一个元素作为测试用例，能检测

36、出程序的某一个错误，那么，这一等价类中的其余元素作为测试用例也能发现同样的错误；反之，如果用等价类中的一个元素不能检测出程序的某一个错误，那么，采用这个等价类中其余的元素也不能发现程序中同样的错误。除非某一个测试用例属于几个等价类的交集。7272第12章 软件验证和确认 等价类划分时根据输入条件，可把输入数据划分为有效等价类(合法输入类)和无效等价类(非法输入类)等。有效等价类是指相对软件的规格说明而言，是合理的、有意义的输入数据的集合。选用这些数据验证程序是否实现了软件规格需要说明定义的功能和性能。无效等价类是指相对软件的规格说明而言，是不合理的、没有意义的输入数据的集合。选用这些数据验证程

37、序实现的功能和性能是否符合软件需求规格说明的要求。7373第12章 软件验证和确认 如何划分等价类是一个重要问题，以下是可供参考的几条原则：(1)如果输入条件规定了取值范围或者值的个数，则可以确定一个有效等价类和两个无效等价类。例如，假设输入的条件规定了取值范围是0150,则有效等价类定义是“0 x150”,无效等价类是“x150”，如图12.11所示。7474第12章 软件验证和确认图12.11 取值范围7575第12章 软件验证和确认(2)如果规定了输入数据的一组值，而且程序要对每一个输入值分别进行处理，这时可以为每一个允许输入的值定义一个有效等价类，把所有不允许输入值的集合定义为一个无效

38、等价类。例如，在学校内对教授、副教授、讲师、助教进行统计，则定义教授、副教授、讲师、助教4个有效等价类，所有不符合这4类人员的输入值定义为一个无效等价类。(3)如果规定了输入条件是一个布尔量，则可以定义一个有效等价类和一个无效等价类。7676第12章 软件验证和确认(4)如果规定了输入数据必须遵循的规则，则可以定义一个有效等价类和若干个无效等价类，即把符合规则的输入定义为一个有效等价类，把从各种不同角度违反规则的输入定义为一个无效等价类。(5)如果已划分的等价类中各个元素在程序中的处理不同，则应将此等价类进一步划分成更小的等价类。7777第12章 软件验证和确认(6)设计一个新的测试用例，使得

39、尽可能多地覆盖尚未被覆盖的有效等价类。重复这一步，直到所有有效等价类都被覆盖为止，即有效等价类的测试用例尽量公用，以减少测试次数。(7)设计一个新的测试用例，使得覆盖一个且只覆盖一个尚未被覆盖的无效等价类。重复这一步，直到所有无效等价类都被覆盖为止。也就是说，无效等价类至少每类一例，以防止漏掉本来可能发现的错误。7878第12章 软件验证和确认2边界值分析 经验表明，编程人员往往会在处理边界数据上发生问题，边界值相邻近数据都属于敏感区，比如一组数据的上、下界、循环变量的终值，因此有必要在设计测试用例时考虑边界数据，选用边界值作为测试用例更有效，有利于发现更多的错误。这种在边界上选取测试用例的方

40、法称为边界值分析方法。边界值分析属于一种特殊的等价类划分方法，是用得最多的方法之一。7979第12章 软件验证和确认在使用边界值分析方法选择测试用例时，可以参考以下原则：(1)如果输入条件规定了值的范围，则应取刚好到达该范围的边界值和刚好超过该范围的边界值作为测试用例。例如，输入取值范围是整型数199，则等价类的划分是：199是有效等价类；小于1和大于99是两个无效等价类。应在1和99的边界分别选取测试用例，则可选择0、1、2、98、99、100等。(2)如果输入条件规定了值的个数，则应取最大个数、最小个数、比最大个数多1个、比最小个数少1个等作为测试用例。例如，输入的数据个数规定为1229个

41、，则可以选用1个、229个、0个、230个数据作为测试用例。8080第12章 软件验证和确认(3)对于输出条件规定了值的范围和个数，可以分别参考原则(1)和(2)。(4)如果程序中使用的数据结构有预定义边界(例如，定义数组有100项)，则应在该边界测试数据结构。8181第12章 软件验证和确认为了说明黑盒测试方法，这里综合利用等价类划分和边界值分析的方法实现对一个查找关键字的过程函数Search进行等价类划分并产生相应的测试用例。下列文本框内为Search过程的接口定义，对于黑盒测试来说，仅需要根据待测程序的接口来产生黑盒测试用例，因此文本框内并不包含完整的程序或程序内部的实现结构。该接口定义

42、表明Search有两个输入参数Key和T，分别为需查找的关键字和待查找的数组序列；两个输出参数Found和L分别返回查找的结果和相匹配的关键字在数组中的定位。在这个接口定义中，有严格的前置和后置条件定义。8282第12章 软件验证和确认8383第12章 软件验证和确认等价类的划分可以首先将输入分为有效的和无效的等价类两类，由于该程序为一个过程函数，查找关键字Key为调用者给定的符合类型定义的参数，类型前置条件说明有待查找的数组T不会为空，至少有一个元素，因此输入参数不存在无效的等价类；对于输出应考虑查找到和未查找到匹配元素两种情况；再结合边界条件分析，包括数组仅包含一个元素、与Key匹配的元素

43、在数组的第一个或最后一个，我们给出如表12.3所示的等价类，共分为6个等价类。根据表12.3定义的等价类，可以产生如表12.4所示的测试用例。8484第12章 软件验证和确认8585第12章 软件验证和确认8686第12章 软件验证和确认3错误猜测法人们在长期测试实践中积累的经验是宝贵的，错误猜测法实际上是一种猜错。所谓猜错也就是凭实践经验和感觉，猜测被测试程序哪些地方最容易出错，并且以此来设计测试用例。错误猜测法的基本思想是，凭经验列举出程序中全部可能有错误的地方和最容易发生错误的情况，并且以它们为依据选择测试用例。8787第12章 软件验证和确认12.5 面向对象的测试 面向对象的主要特性

44、包括封装、继承、多态等。这些特性充分体现了分解、抽象、模块化、信息隐蔽等思想，使得软件的复用性提高，有效地控制了软件的复杂性，从而提高了生产率，缩短了生产时间。然而这些特性同时也带来了传统语言设计不可能引发的错误，显然，这些错误应用传统的软件测试方法、技术或者经验很难发现。因此针对面向对象软件，要想达到测试的真正目的，就必须改变测试的策略和方法。8888第12章 软件验证和确认12.5.1 对象类的测试 软件测试的基本策略是从单元测试开始，逐步进入集成测试，最后进行确认测试和系统测试。对于传统的软件系统来说，单元测试的对象是软件设计的最小的可编译的程序单元(过程模块)，它检查在模块中实现的算法

45、的正确性及返回值与预定结果的符合程度，一旦把所有单元都测试完，就把这些模块组装起来，进行集成测试，以便发现与接口有关的各种错误和新单元加入到程序中所带来的副作用。最后，把系统作为一个整体来测试，以发现软件需求中的错误。8989第12章 软件验证和确认在面向对象的软件开发中，“封装”导致了类和对象的定义，这意味着类和类的实例(对象)包装了属性(数据)和处理这些数据的操作(也称为方法或服务)。其核心是“对象”，传统软件开发中的“单元”概念发生了改变。也就是说，封装起来的类和对象是最小的可测试单元。一个类可以包含一组不同的操作，而一个特定的操作也可能定义在一组不同的类中。因此，在面向对象测试中，类测

46、试用于代替传统测试方法中的单元测试。9090第12章 软件验证和确认 类测试就是为了验证类的实现与类的规约是否一致的活动。完整类的测试应该包括：类属性的测试、类操作的测试、可能状态下的对象测试。继承使得类测试变得困难，因此“孤立”的类测试是不可行的，操作的测试应该包括其可能被调用的各种情况。例如，在一个类层次中，操作A在超类中定义并被一组子类继承，每个子类都可用操作A，但是A调用子类中定义的操作并处理子类的私有属性。由于在不同的子类中使用操作A的环境有所不同，因此有必要在每个子类的语境中测试操作A。这就是说，当测试面向对象软件时，不能再独立地对操作A进行测试。9191第12章 软件验证和确认1

47、2.5.2 对象集成测试传统的集成测试是采用自顶向下或自底向上或二者混合的两头逼近策略，通过用渐增方式集成功能模块进行的测试。但是由于面向对象程序没有层次的控制结构，相互调用的功能也是分散在不同的类中，类通过消息的相互作用来请求和提供服务，所以集成测试的策略应有所改变。面向对象集成测试主要关注系统的结构和内部的相互作用。面向对象软件的集成测试有两种方法：基于线程的测试(Thread-based Testing)和基于使用的测试(Use-based Testing)。9292第12章 软件验证和确认基于线程的测试是指把响应系统的一个输入或一个事件所需要的一组类集成起来进行测试。应当分别集成并测试

48、每个线程，同时为了避免产生副作用再进行回归测试。基于使用的测试首先测试几乎不使用服务器类的那些类(称为独立类)，把独立类都测试完之后，接着测试使用独立类的最下层的类(称为依赖类)。然后，根据依赖类的使用关系，从下到上一个层次一个层次地持续进行测试，直至把整个软件系统测试完为止。9393第12章 软件验证和确认除了上述两种测试方法，集群测试是面向对象软件集成测试的一个步骤。为了检查一群相互协作的类，应精心设计测试用例，以发现协作错误。通过研究对象模型可以确定协作类。为减少测试工作的工作量，在进行集成测试时，可参考类图或实体关系图，确定不需要被重复测试的部分，从而优化测试用例，使测试能够达到一定的

49、标准。9494第12章 软件验证和确认12.6 IBM Rational Functional Tester购买并安装了IBM Rational Functional Tester后，工作界面如图12.12所示。9595第12章 软件验证和确认图12.12 IBM Rational Functional Tester工作界面9696第12章 软件验证和确认1创建Functional Tester项目开始记录前，首先必须创建一个 Functional Test项目。在 Functional Tester 菜单中，单击菜单【文件】【新建】【Functional Test项目】，如图12.13所示，

50、输入项目名称和位置。可以选择将项目添加到源控制来将 ClearCase 用于此项目的软件配置管理，然后单击【完成】。9797第12章 软件验证和确认图12.13 创建Functional Tester项目9898第12章 软件验证和确认2录制脚本单击功能测试工具栏中的录制功能测试脚本按钮()，开始录制脚本。选择刚创建的项目。在脚本名称字段中，输入将使用的应用程序的名称。不要选择将脚本添加到源控件选项(如果该选项可用)，单击【完成】。Functional Tester窗口自动最小化，并显示Recording Monitor，如图12.14所示。9999第12章 软件验证和确认图12.14 Rec