软件工程方法与实践7-测试

软件工程方法与实践第7章软件测试电子教案第7章

软件测试7.1软件测试概述7.2软件测试技术7.3软件调试技术7.4多模块的软件测试7.5特定应用软件的测试7.6小结7.1.1软件测试任务 ◆软件测试是软件质量“层层把关”的一个重要环节，是软件产品在“发布”之前，对需求分析、设计和实现（编码）等开发工作的最后复审。 ◆软件测试的基本目标是采用行之有效的测试方案，找出迄今未被发现的、尽可能多的错误，并加以纠正。 ◆软件测试任务： ①

测试任务——通过采用一定的测试策略，找出软件中的错误； ②调试任务，或称为纠错任务——如果测试到错误，定位软件中的故障源，加以纠正。

测试和调试的流程

◆测试和调试的流程实际是一个带回溯的线性有序过程。 ◆每一次测试都需要为之准备若干个必要的测试数据。把用于测试过程的测试数据称为测试用例。图7.1软件测试和调试的流程软件测试结果错误信息改正信息测试用例期望结果测试评价调试7.1.2软件测试原理

1.测试的特性 ◆复杂性。测试的复杂性来源于错误的多样性。软件错误可划分为语法错误、结构性错误、功能性错误和接口错误等类型。 ◆心理因素。测试主要是靠人的智力因素完成的一项技术性工作。测试人员除了技术素质之外，往往对测试目的、测试性质和选择测试对象等存在着一些心理上的认识问题，这或多或少会影响测试行为。 7.1.2软件测试原理 ◆不彻底性。“程序测试只能证明错误的存在，不能证明错误不存在”揭示了软件测试一个重要性质——不彻底性。彻底的测试往往是一个无穷量的“穷举”测试，实际上往往是行不通的。 ◆经济性。软件测试是一项经济性活动，测试的投入—效益比应该是非常关注的指标。测试投入的成本是时间、人力和资源等，其经济效益是“找没找到错”、“找到了多少错”。测试投入是有限的，测试也只能是有限的。7.1.2软件测试原理

2.测试的正确观点 ◆被测对象一定有错（该假定是合理的）。 ◆测试要能发现尽可能多的错误，争取测试效益最大化。 ◆测试仅能证明错误的存在，而不能证明错误的不存在。

7.1.2软件测试原理

3.测试的原则 ⑴

提高软件的可测试性 软件系统或产品在开发的全过程中，应该考虑提高软件的可测试性，这将使得软件测试能够更容易、更有效地进行。7.1.2软件测试原理 ⑵

测试的组织 软件测试应该有组织、有计划地进行，提高测试效益。 ◆测试活动必须和软件过程相关活动并行进行，尽早发现错误，不要“秋后算账”。 ◆建立独立的测试机构，避免心理上的和实质性的利益冲突。 ◆设计高产的测试方案，尽可能多地发现错误。 ◆测试成本投入不要“平均”分配，而是有计划、有重点地分步实施测试。7.1.2软件测试原理

⑶

测试文档 测试文档主包括测试计划和测试报告两方面内容。测试计划主要是测试立项说明，测试用例设计，以及测试步骤；测试报告主要是测试结论说明。 测试需要设计一个测试用例集合。每一个测试用例都包括一组测试数据和一个相应的期望结果，可描述为：测试用例=｛测试数据+预期结果｝ 测试结果可相应地描述为：测试结果=｛测试数据+预期结果+实际结果｝

7.1.3测试方法分类图7.2软件测试方法的分类软件测试静态测试（程序不执行）动态测试（程序执行）“办公桌”检查会审走查（排查）静态分析器（自动工具）代码评审（人工方式）黑盒测试（测试功能）白盒测试（测试结构）静态测试方法

静态测试是基于不执行程序（脱机）的，主要以人工方式分析程序、发现错误的测试方法。静态测试主要能测试程序的语法错误和结构性错误。 静态测试有自动方式的静态分析器（静态分析程序）和人工方式的代码评审。

动态测试方法

动态测试是基于执行程序的（联机的），通过试运行的测试过程，推断产品某个行为特性是否有错误。动态测试主要能测试程序的功能性错误和接口错误。 动态测试提供了一种有助于确保良好测试的机制，揭示了最大可能发现错误的科学性。

动态测试方法

⑴黑盒测试（BlackBoxTesting）

测试软件已知的全部功能是否完全可供使用，基本不涉及软件的内部逻辑结构，也称为功能测试或软件接口测试。黑盒测试适用于组件（模块或对象）规模较大、控制结构较复杂的软件测试。 ⑵白盒测试（WhiteBoxTesting）

测试软件的逻辑路径（程序控制结构），也称为逻辑覆盖测试或结构测试。白盒测试适用于组件（模块或对象）的规模较小、控制结构较清晰的软件测试。7.1.4测试终止标准

根据软件测试的经济性和有限性，测试不可能发现所有的错误。因此，测试工作进行到何种程度才算完成任务，而且测试效果“最佳”，即潜在错误数最少，这可选择使用以下两种实用的测试终止标准之一。 ⑴

规定测试策略和应达到的目标 ⑵

规定至少要查出的错误数7.2软件（动态）测试技术预期结果测试用例图7.3软件动态测试过程设计测试用例准备测试数据用测试数据运行程序测试结果分析测试报告测试结果7.2.1测试用例设计

◆测试用例是不可能预知的，因此不能自动生成，需要专门为之设计。

◆软件测试是一个有穷测试，测试需要基于一个可能的测试用例子集，而软件测试机构应该制定出科学而合理的选择测试用例子集的策略（简称测试策略），指导测试用例的设计。 ◆不同的测试方法和测试策略各有所长，即使综合运用了多个策略设计测试用例，仍然不能保证测试能发现一切错误。但是，一个最优化的测试策略无疑是测试成本和测试效果之间的一个科学、合理的折中。

7.2.2黑盒测试方法 ◆黑盒测试是从输入集合中选择出一个极有可能发现错误的输入子集，根据功能描述分析，检查其相应的输出是否是预期的结果。

◆黑盒测试由于注重于功能和数据信息域的测试，一般能发现功能错误或有遗漏、性能错误、数据结构或数据库访问错误、界面有错、初始化或终止错误等一些类型的错误。它既适用于由功能模块组成的系统，也适用于由对象构成的系统。 7.2.2黑盒测试方法 ◆黑盒测试方法带有经验性质的设计测试用例原则： ①

对有输入的所有功能，既要用有效的输入来测试，也要用无效的输入来测试。

②

经过菜单调用的所有功能都应该被测试，包括通过同一个菜单调用的组合功能也要测试。

③

设计的测试用例数量，能够达到合理测试所需的“最少”（减少测试成本）。

④

设计的测试用例，不仅能告知有没有错误，而且能告知错误可能是某些类型（提高测试效率）。等价分类法

等价分类法的测试是基于合理的假定：程序输入域总可以划分成若干个不同性质的等价类，每个等价类中的一个典型值在测试中的作用与该类所有其他值的作用相同，因此，可以从每个等价类中只取有代表性的一组数据作为测试数据。 等价分类测试是用一个测试用例独立地发现一类错误。测试的用例设计是基于输入（包括有效的和无效的）的等价类评估。

等价分类法实现步骤 ①

根据被测对象的规格说明，列出所有输入的有效和无效的等价类； ②

为每一个等价类设计一个测试用例； ③

执行一系列测试用例，分析是否得到预期结果。边界值分析法

边界值分析法是一种具有高度针对性的等价分类测试法。 输入域的边界值比中间值更容易发生错误，在等价类中不是选择典型值或任意值，而是选择一组检查边界值的测试用例，使暴露出错误的可能性更大。 边界值分析法实现步骤 ①根据输入和输出的规格说明，分别列出所有输入/输出的有效和无效的等价类； ②为每一个输入/输出等价类选取一个或多个等价类边界值的测试用例； ③执行设计的一系列测试用例，分析是否得到预期结果。

错误推测法

错误推测法是依靠测试者的直觉和经验，推测可能存在的错误类型，从各种可能的测试方案中选择最可能发现错误的测试方案。 错误推测法采用的是一种凭借先验知识对被测对象做类比测试的思路。这种类比测试的效果，在很大程度上取决于测试者的经验丰富程度和对被测对象的了解程度。 错误推测法常被很有效地用于测试那些已发现了较多错误，即“错误成群”的程序段。7.2.3白盒测试方法

◆白盒测试（逻辑覆盖测试）法是有选择地执行（或覆盖）程序中某些最有代表性路径的测试方法。 ◆白盒测试方法是从程序的控制结构路径导出测试用例集的。测试用例集执行（或覆盖）程序逻辑的程度可以划分成不同等级，从而反映不同的软件测试质量。 ◆白盒测试方法带有经验性质的设计测试用例原则： ①

保证一个模块中的所有独立路径至少被执行一次。 ②

对所有逻辑值均需测试“True”分支和“False”分支。 ③

在上、下边界，以及可操作范围内运行所有循环。 ④

检查内部数据结构，以确保其有效性。路径测试法

路径测试法是根据程序的控制流路径设计测试用例的一种最基本的白盒测试技术。

路径测试法的实现步骤：

⑴把过程设计描述（如PDL、流程图、N-S图图等）映射为一个相应的程序图描述。 （程序流图，简称程序图是程序控制流的图形描述，实际是一种简化了的程序流程图，在路径测试法中是考察测试路径的支持工具。图矩阵是一种表格形式的数据结构，常用做程序图的辅助描述。）程序流图示例

4,512,311867910R1R2R3R4（a）流程图（b）程序流图图7.4从程序流程图映射程序流图的示例1121374568910路径测试法

⑵确定程序图的环形复杂性。 （环形复杂性是一种以图论为基础的，为程序逻辑复杂性提供定量的测度。该度量用于基本路径测试法，是将计算所得的值定义程序路径基本集的独立路径数，提供确保所有语句至少执行一次的测试数目的上界。） 程序图G的环形复杂性V(G)可用三种方法计算： ①V(G)等于程序图G的区域数。 ②V(G)=E﹣N+2，E是程序图G的边数，N是程序图G的节点数。 ③V(G)=P+l，P是程序图G中判定的节点数。路径测试法

⑶从执行路径基本集导出的测试用例，进行测试。 定义执行路径的基本集有三种情况： 如果是保证每一条语句至少被执行一次，称为语句覆盖或程序图的点覆盖； 如果是保证每个判定的所有分支被至少被执行一次，称为判定覆盖或程序图的边覆盖； 同时满足语句覆盖和判定覆盖标准的测试，称为完全覆盖或程序图的路径覆盖。 路径覆盖是白盒测试法的基本要求。

设计测试路径示例

（a）程序流图（b）测试路径图7.6为被测程序设计测试路径的示例覆盖标准覆盖节点/边测试路径点覆盖1,2,3,4acd

边覆盖a,b,c,d,eacd,be1,2,3,4acd,be/a,b,c,d,eae,bcd路径覆盖abdec1234控制结构测试法

路径测试也是控制结构测试技术之一。路径测试简单、高效，由于其本身并不充分，只能要求达到语句覆盖和/或判定覆盖程度。 控制结构测试法最常用的是条件测试和循环测试等技术。 条件测试

①分支测试（判定测试）是最简单的条件测试策略。达到分支测试的覆盖程度是指每条语句，每个判定表达式的每个分支（True值和False值分支）都至少执行一次。 ②条件测试是指每条语句，每个判定表达式的true值和false值，以及判定表达式中每个条件的true值和false值都至少执行一次。 ③条件组合测试的覆盖程度最强。它要求使得每个判定表达式中所有条件的各种组合都至少执行一次。满足条件组合的测试，也就一定满足分支测试和条件测试。

循环测试

循环程序结构有简单循环、串接循环、嵌套循环和不规则循环等。循环测试策略注重于循环构造的有效性。 ①简单循环的测试集应采用（n是循环最大次数）：

·整个跳过循环；

·只有1次通过循环；

·2次通过循环；

·m次通过循环（m＜n）；

·n-1，n，n+l次通过循环。循环测试

②嵌套循环采用的测试策略： ·从最内层循环开始，将其他循环设置为最小值。 ·对最内层循环使用简单循环测试，使外层循环的循环计数最小，并为范围外或排除的值增加其他测试。 ·由内向外构造下一个循环的测试，但其他的外层循环为最小值，并使其他的嵌套循环为典型值。 ·继续直到测试完所有的循环。循环测试

③如果串接循环的各个循环彼此独立，则参照简单循环的策略进行循环测试；如果串接循环的循环不是独立的，则使用嵌套循环的策略进行测试。 ④对于不规则循环一般应重新设计，改为结构化程序结构。数据流测试法

数据流测试法是根据程序的变量定义和使用的位置来选择测试路径的一种方法。 数据流测试方法也可用于包含嵌套If语句和循环语句的程序选择测试路径，并能够有效地发现数据流错误。但是，数据流测试的覆盖率测度和路径选择比条件测试更为困难。数据流测试法要点

①假设每条语句都赋予独特的语句号，每个函数都不改变其参数和全局变量。对于语句号为S的语句定义：DEF（S）=﹛X︱语句S包含变量X的定义﹜USE（S）=﹛X︱语句S包含变量X的使用﹜

②如果存在从语句S到语句S’的路径，该路径不含X变量的其他定义，称变量X在语句S的定义在语句S’仍有效。那么就存在变量X的定义—使用链，即DU链。DU链的描述形式为[X，S，S’]。

③要求每个DU链至少测试一次，这称为DU测试策略（DU测试并不能保证覆盖程序的所有分支）。 7.2.4自动测试工具

使用辅助测试的软件工具——测试工具无疑能极大地降低测试成本，提高测试效率。 测试软件工具有：测试数据生成器、动态分析器、模拟器、启示器、文件比较器和报告生成器等，通常把它们集成在一个模块测试工作平台中使用。测试工作平台示例

图7.7测试工作平台示例文件比较器测试数据生成器测试数据预期结果测试结果(运行环境)模拟器被测程序动态分析器执行报告测试报告测试用例描述报告生成器(测试结果)启示器常用的测试工具

测试数据生成器可以为测试某一个，或某种类型的系统自动生成大量的输入数据。

动态分析器可以分析被测程序中每个语句的执行次数，在软件测试和调试过程中都很有用。

文件比较器程序能自动化地检查测试结果。 7.3.1软件调试过程

调试是在测试暴露出错误之后，以确定与之相联系的故障源，并修改设计和代码排除这个故障的有序过程。 软件调试是将软件测试找到的错误症状与其内部原因联系起来的智力过程。

需求/设计描述图7.8软件调试过程定位错误设计错误修复修复错误对程序再测试测试用例测试出错结果7.3.1软件调试过程 ◆调试过程分两个步骤：定位错误，根据测试结果表明错误存在的迹象（称为错误）进行分析，验证或确定引起错误的准确位置；修复错误，仔细研究以确定出错的原因（称为故障），并设法改正错误。 ◆为了确定故障源，调试常需要进行某些诊断测试，加以验证。如果处理不当可能带入新的错误。 ◆为了确保调试的正确性，需要重复进行暴露这个错误的某些原始测试，即回归测试，验证故障确实被排除了。调试过程往往需要和测试过程交替进行。 ◆软件测试一般由专业测试人员进行，而软件调试最好由编程人员自己承担。 7.3.2软件调试策略 ◆调试过程如何在程序的所有元素（语句、数据结构、输入/输出等）中找到错误根源的那个（或几个）程序元素，实属不易。 ◆在使用调试技术之前，都应该对错误的症状进行全面的分析和周密的思考，得出对故障的推测，然后使用适当的调试技术检验推测的正确性，也就是说，任何一种调试技术都应该以试探的方式使用。 ◆调试过程的关键不是调试技术，而是分析错误症状找出确切的故障出处的调试策略。试探法调试策略

试探法是调试人员分析错误症状，凭借经验猜想故障的位置，然后使用适当的调试技术，获取程序中被怀疑处附近的信息。

试探法是带有很大盲目性的试探策略，较为低效，适用于结构比较简单的小规模程序。回溯法调试策略

回溯法是调试人员检查错误症状，确定最先发现症状的地方，然后沿着源程序的控制流往回追踪程序代码，直到找出错误根源或确定故障范围为止。回溯法的另一种形式是正向追踪，就是使用输出语句检查一系列中间结果，以确定最先出现错误的地方。

回溯法对于规模小的程序是一种比较好的调试策略。但是，随着程序规模扩大，回溯的路径数目可能会变得越来越大，以至于使彻底回溯变得完全不可能。对分查找法调试策略

对分查找法，如果己经知道变量在程序内若干个关键点的正确值，则可以用赋值语句或输入语句在程序“中点”附近加入这些变量的正确值，然后检查程序的输出。如果输出结果是正确的，则故障在程序“中点”的前半部分；反之，故障在程序的后半部分。对于程序中有故障的那部分再重复使用对分查找法，直到把故障范围缩小到容易诊断为止。

归纳法调试策略

归纳法是从个别或特殊推断一般的规范方法，调试策略是分析线索（错误征兆）之间的关系找出故障。 ⑴

收集有关数据：列出程序中已经知道的，对或不对的一切数据，包括那些不产生错误结果的测试数据。 ⑵

组织数据：整理数据以便发现规律。特别要总结在什么条件下出现错误，在什么条件下不出现错误的一些数据信息。

归纳法调试策略

⑶导出假设：分析研究线索之间的关系和规律，推测故障的一个（或多个）假设。如果无法推测，则转到⑴步重复这个过程；如果有多种假设，则选择其中最大可能性的为假设。

⑷

验证假设：用假设来解释所有原始的测试结果。如果能圆满解释一切现象，假设证实，表明故障找到了；否则表明假设不成立或不完备，或可能还有多个故障同时存在，转道⑴步重复这个过程。演译法调试策略

演绎法是从一般前提条件出发，经过不断排除过程导出结论的规范方法。调试策略是先列出所有可能成立的原因或假设，然后逐一排除不正确的原因，直到最后证明剩下的确实是错误的根源为止。

⑴

列举可能的原因：根据已有的测试信息和测试数据，列举出所有可能产生错误的原因。

⑵

排除不正确的原因：分析已有的信息/数据，力求排除列出的原因。如果所有列出的原因都排除了，则需提出新的原因，转到⑴步重复这个过程。如果排除之后余下的原因只有一个，则就是故障的假设；如果余下的原因多于一个，则选最大可能性的原因为假设。 ⑶

细化假设：利用已知线索进一步具体化确定的假设，以便确定故障的位置。 ⑷

验证假设：（与归纳法相同）。演绎法调试策略7.4多模块的软件测试 除了很小的程序，软件（产品）大都是多模块的。大型软件一般由子系统构成，子系统由多个功能模块构成，而每个模块又包含多个过程或函数。 多模块系统的测试过程应该和系统开发过程相结合，采用分阶段增量式进行。这样做是遵循分解的思想，能够在不同的层次，有重点地测试不同类型的错误，从而取得更好的测试效果。

7.4.1多模块的测试层次

多模块程序的软件测试分成单元测试、集成测试、确认测试和系统测试四个层次。图7.9多模块分层次的测试过程测试报告测试报告软件设计信息软件需求信息系统其他配置集成测试系统测试确认测试已组装软件已确认软件可运行系统模块测试报告单元测试模块测试报告单元测试模块测试报告单元测试┇┇7.4.2单元（模块）测试

◆多模块程序的单元（模块）测试是整个测试过程的基础。由于测试范围小，减少了测试的复杂性，而且多个单元可以并行测试，缩短了测试周期。 ◆单元测试任务是测试模块内部重要的执行路径、出错处理路径、局部数据结构、边界条件，以及模块的接口等。测试步骤一般为：编译→静态分析器检查→代码评审→动态测试 ◆单元测试的动态测试，可采用黑盒测试方法和/或白盒测试方法，重点是发现模块的功能性错误。7.4.3集成测试

◆集成测试是把多模块按照一定的集成方法和策略，逐步组装成子系统，进而组装成整个系统的测试，也称为综合测试或组装测试。 ◆一般，集成测试和系统集成过程同步进行，即集成测试融合在系统集成过程之中。所以，集成测试是在构造程序体系结构的过程中，通过测试发现与接口有关问题的系统化技术。 ◆多模块集成测试策略也与集成方式相对应的，分成自顶向下测试、自底向上测试和混合（三明治）式测试。三种集成测试策略的特点

◆自顶向下测试能较早展示整个程序的概貌，但在测试上层模块时要使用桩模块，很难模拟出真实模块的全部功能。使用桩模块较多，增加了设计测试用例的困难。 ◆自底向上测试从下层模块开始，设计测试用例比较容易，但在测试的早期不能显示出整个程序的概貌。 ◆混合式测试的策略是，关键模块采取自底向上测试，使设计测试用例变得较容易；使具有重要功能的模块及早与有关模块相连，以便早暴露可能存在的问题；除关键模块和少数与之相关的模块外，其余模块，尤其是上层模块采用自顶向下的测试方法，以便尽早得到软件总体概貌。7.4.4确认测试

◆确认测试是对已集成的整个软件测试，其目的是确认已组装完成的程序是否能满足需求规格说明书（SRS）的全部需求，即验证软件的有效性。 ◆典型的确认测试包括有效性测试（主要采用黑盒测试方法）和配置复审（主要采用人工评审方法）等。 ◆确认测试是软件开发组织实施的最后一项开发活动。同集成测试一样，确认测试也应该由独立的测试机构负责实施。

◆系统测试（验收测试）是验收的主要工作。系统测试是检查被测程序安装到系统上，与系统的其他软/硬件配置能否协调工作，完成需求说明书规定的任务。 ◆系统测试一般采用黑盒测试法。系统测试发现的问题往往和需求分析的差错有关，涉及的面比较广，解决也比较困难。 ◆系统测试一般应由用户单位组织实施。软件开发单位应该提供良好的系统测试条件，负责回答和解决测试中可能发现的一切质量问题。

7.4.5系统测试

7.5.1面向对象软件测试

面向对象软件是基于类/对象的，其特有的封装、继承、多态等机制，给面向对象测试带来了一定的困难。 面向对象软件测试的策略和测试要点： 1.测试视角的扩大 面向对象测试的重点从过程构件（模块）的测试移向了类的测试。 面向对象测试范围扩大到对OOA和OOD模型的复审，这增加了测试的工作量，也增加了测试的复杂性。7.5.1面向对象软件测试

2.软件测试层次 面向对象软件测试主要分为：

算法层测试 类层测试 对象群集层 面向对象系统层测试7.5.1面向对象软件测试

3.OO软件的集成测试 面向对象系统没有严格的层次控制结构，相互调用的功能也分散在不同的类中，类通过消息申请和提供服务；面向对象程序具有动态特性，程序的控制流往往无法确定。因此，面向对象软件不太适用渐增式集成测试，一般采用基于方法的集成测试。 面向对象基于方法的集成测试策略有：基于线程的测试和基于使用的测试。7.5.1面向对象软件测试

4.OO软件的高级测试 面向对象软件也必须经过规范的高级测试（确认测试和系统测试）。它们主要采用黑盒法，对照OOA所描述的对象、属性和各种服务等，检测软件是否能够完全“再现”问题空间。OOA的对象—行为模型、时序图等都可以用来导出测试用例。 系统测试应该尽量构建与用户的实际使用环境相同的测试平台，保证被测系统的完整性。7.5.1面向对象软件测试

5.OO软件的测试用例 测试用例的设计思路有基于故障和基于用例。 面向对象测试的类测试用例是为测试类的状态，设计合适的操作序列。类测试用例设计步骤： ①

选定检测的类。 ②

确定测试覆盖标准。 ③

利用结构关系图确定待测试类的所有关联。 ④

根据程序中类的对象设计测试用例，确认使用什么输入激发类的状态、使用类的服务和期望产生什么行为等。7.5.2人机界面软件测试

◆人机界面测试是“以人为本”评价界面的可使用性，并检测它是否符合用户需求工程。 ◆人机界面交互方式的多样性，而且交互操作相关的排列数目很大，使得人机界面软件更加复杂，再加上复用构件的封装性、多媒体部件的共存性等，增加了对界面进行测试评价的难度。 ◆常见的人机界面测试方案：

1.对需求说明文档（SRS）中软件质量度量所描述的可使用属性进行量化值测试。 2.测试者运用自己的经验和判断，设计界面测试策略。7.5.2人机界面软件测试

◆常用的人机界面测试方法： ①问卷调查方式，收集用户对界面意见的有关信息。 ②观察用户在系统使用过程中的表现，并与用户对如何使用系统完成某项任务进行交流。 ③对典型的系统使用过程进行摄像。 ④在软件中嵌入一段统计代码，收集最常用的功能和最容易犯错误的信息。 ◆根