软件工程-09.ppt

1、1,第九章软件测试用例设计,软件工程课件,软件工程,2,软件工程第九章 软件测试用例设计,9.1 测试用例设计概述 9.2 软件测试用例设计方法 9.3 白盒测试用例设计方法 9.4 黑盒测试用例设计方法 9.5 单元测试的测试用例设计 9.6 集成测试的测试用例设计 9.7 系统测试的测试用例设计,软件工程,3,9.1 测试用例设计概述,测试用例是为有效地发现软件缺陷的最小测试执行单元。,测试用例的重要性 测试用例是测试人员执行测试的重要参考依据。不同的测试人员根据相同的测试用例所得到的输出应该是一致的，测试实际上就是测试用例的计划、执行和跟踪过程。 良好的测试用例具有复用的功能，在测试过程

2、中可以重复使用。因此，设计良好的测试用例可以大大节约时间，提高测试效率。 测试用例是在长期测试实践中积累起来的。组织好这些测试用例，可帮助测试者有效使用它们。 测试用例的通过率是检验程序代码质量的例证。衡量程序代码的质量，量化的标准应该是测试用例的通过率和软件缺陷（bug）的数目。 测试用例也是检验测试人员进度、工作量以及跟踪管理测试人员的工作效率的因素。尤其适用于对于新的测试人员考核，从而更加合理做出测试安排和计划。,软件工程,4,测试用例数和软件规模的关系,对软件质量的要求不同，测试用例数与程序源代码规模的比例不同。如航天软件的测试用例数与程序源代码行数的比例就高于普通民用软件。 软件的规

3、模不同，若要达到相同的软件质量，软件的测试用例数与程序代码行数的比例页不同，大规模软件应该比小规模软件更高些。,软件工程,5,测试用例设计说明的书写规范,在ANSIIEEE 829 1983 标准中列出了和测试设计相关的测试用例编写规范和模板。 标准模板中主要元素如下。 标识符：每个测试用例应有一个惟一的标识，作为引用的基本元素。 测试项：测试用例应准确地描述被测试项及其特征。如做 Windows 应用程序的窗口测试，测试对象是整个应用程序用户界面，其特性要求包括窗口缩放、界面布局、菜单等。 测试环境要求：用来表明执行该测试用例需要的测试环境，可根据被测模块对测试环境的需求来描述测试用例的测试

4、环境。 输入数据：用来执行测试用例的输入数据。 对应输出数据：表示按照指定的环境和输入标准得到的期望输出结果。 测试用例间的关联：用来标识该测试用例与其他的测试（或其他测试用例）间的依赖关系。,软件工程,6,9.2 软件测试用例设计方法,静态测试和动态测两类的测试 静态测试：不必执行程序，目的是收集有关程序代码的结构信息而非查错。 主要采用检查、分析、评审等人工测试的方法； 动态测试 需要执行程序，目的是查错。 主要有：黑盒测试、白盒测试,软件工程,7,9.2.1 黑盒测试（Black-Box Test）,把测试对象看做一个黑盒，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求

5、和功能规格说明，检查程序的功能是否符合它的功能说明。 黑盒测试叫做功能测试或数据驱动测试。 采用黑盒测试方法就意味着测试要在软件的接口处进行。,软件工程,8,黑盒测试方法主要是为了发现以下几类错误： 1)是否有不正确或遗漏了的功能？ 在接口上，输入能否正确地接受? 能否输出正确的结果? 是否有数据结构错误或外部信息 (例如数据文件) 访问错误? 性能上是否能够满足要求? 是否有初始化或终止性错误? 用黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确的输出。 但这是不可能的。,第三方测试大多采用黑盒测试方法,软件工程,9,9.2.2 白盒测试

6、（White-Box Test）,此方法把测试对象看做一个玻璃盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。 白盒测试又称为结构测试、逻辑驱动测试、开盒测试、玻璃盒测试、基于程序的测试. 。,软件工程,10,对于有多重循环的程序，穷举测试是不可能的。 例如，给出一个小程序的流程图，它包括了一个执行 20 次的循环。 循环内有 5 条不同的路径，循环 20 次，则组合起来可能的不同执行路径数达 520 条。 假设对每一条路径进行测试需要1毫秒，一年工作365 天，每天工作 24 小时，要想把所有路径测试完，需 3024 年。,软件工程,11

7、,9.3 白盒测试用例设计方法,逻辑覆盖 判定结构分析 循环结构分析 基本路径覆盖,软件工程,12,9.3.1 逻辑覆盖,逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术。它属白盒测试。 语句覆盖 判定覆盖 条件覆盖 判定条件覆盖 条件组合覆盖 路径覆盖 介绍逻辑覆盖的方法时均以下页的图为例。,软件工程,13,软件工程,14,1. 语句覆盖,语句覆盖就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。 图中，正好所有的可执行语句都在路径ace上 测试用例的设计格式如下【输入的(A, B, X)，对应输出的(A, B, X)】 为图例设计满足语句覆盖的测试用例是:Tes

8、t1: 【(2, 0, 4)，(2, 0, 3)】 覆盖 ace【P1】。 “语句覆盖是最弱的逻辑覆盖准则” 。 如果第一个判 断“and”错为“or”，第二个判断“or”错为“and”，使用以上 测试用例，查不出问题。 因此，使用语句覆盖，可能查不出判定中逻辑运算中出现的错误。,软件工程,15,2. 判定覆盖,判定覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。 判定覆盖又称为分支覆盖。 对于图例，如果选择路径P1和P2，就可得满足要求的测试用例。 Test1:【(2, 0, 4)，(2, 0, 3)】覆盖 ace【P1】Test2:【(1, 1

9、, 1)，(1, 1, 1)】覆盖 abd【P2】,或者 Test1:【(2, 1, 1)，(2, 1, 2)】覆盖 abe【P3】Test2:【(3, 0, 3)，(3, 0, 1)】覆盖 acd【P4】,使用判定覆盖，有可能查不出在判定的条件中存在的错误。 例如，若把图例中第二个判定中的条件 X1 错写成X1，那么利用上面两组测试用例，仍能得到同样结果。,软件工程,16,3. 条件覆盖,条件覆盖：使得程序中每个判断的每个条件的可能取值至少取得一次。,测试用例 覆盖分支 条件取值 Test1:【(2, 0, 4)，(2, 0, 3)】 P1(c, e) T1T2T3T4 Test2:【(1,

10、 1, 1)，(1, 1, 1)】 P2(b, d) F1F2F3F4,对于第一个判断：条件 A1 取真为T1，取假为F1；条件 B0 取真为T2，取假为F2。 对于第二个判断：条件A2 取真为T3，取假为F3；条件X1 取真为T4，取假为F4。,测试用例 覆盖分支 条件取值 Test1:【(1, 0, 3)，(1, 0, 4)】 P3(b, e) F1T2F3T4 Test2:【(2, 1, 1)，(2, 1, 2)】 P3(b, e) T1F2T3F4,为解决这一矛盾，需要对条件和分支兼顾，有必要考虑下面的条件判定覆盖。,从结果来看，这一组测试用例覆盖了所有条件的取值，但没有覆盖所有的分支

11、。,软件工程,17,判定条件覆盖:判断中每个条件的可能取值至少执行一次，每个判断中的每个分支至少执行一次。 可取覆盖P1和P2的测试用例，覆盖所有分支和所有条件的取值。,4. 判定条件覆盖,真值表,先取覆盖 P1 和 P2 的测试用例，覆盖所有分支和所有条件的取值。再判断哪些条件取值执行不到，据此补充一个测试用例 测 试 用 例 条件取值 覆盖分支 执行条件 【(2, 0, 4), (2, 0, 3)】 T1T2T3T4 c, e T1T2T3 【(1, 1, 1), (1, 1, 1)】 F1F2F3F4 b, d F1F3F4 【(3, 1, 2), (3, 1, 3)】T1F2F3T4

12、b, e T1F2F3T4 第3个补充了前两个没有执行到的T4和F2。,软件工程,18,5. 条件组合覆盖,条件组合覆盖就是设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。 记 A1, B0 作 T1T2判定1的取真分支 A1, B0 作 T1F2判定1的取假分支 A1, B0 作 F1T2判定1的取假分支 A1, B0 作 F1F2判定1的取假分支 A2, X1 作 T3T4判定2的取真分支 A2, X1 作 T3F4判定2的取真分支 A2, X1 作 F3T4判定2的取真分支 A2, X1 作 F3F4判定2的取假分支 对于两个判定各 4 个条件取值组合

13、，最多需要有42 = 16 个测试用例，最少需要 4 个测试用例。 测 试 用 例 条件取值 覆盖组合 路径 【(2, 0, 4), (2, 0, 3)】 T1T2T3T4 , P1(c, e) 【(2, 1, 1), (2, 1, 2)】 T1F2T3F4 , P3(b, e) 【(1, 0, 3), (1, 0, 4)】 F1T2F3T4 , P3(b, e) 【(1, 1, 1), (1, 1, 1)】 F1F2F3F4 , P2(b, d),软件工程,19,6. 路径测试,路径测试就是设计足够的测试用例，覆盖程序中所有可能的路径。 测 试 用 例 通过路径 覆盖条件 执行条件 【(2,

14、 0, 4), (2, 0, 3)】 P1(c, e) T1T2T3T4 T1T2T3 【(1, 1, 1), (1, 1, 1)】 P2(b, d) F1F2F3F4 F1F3F4 【(1, 1, 2), (1, 1, 3)】 P3(b, e) F1F2F3T4 F1F3T4 【(3, 0, 3), (3, 0, 1)】 P4(c, d) T1T2F3F4 T1T2F3F4 路径覆盖是最强的覆盖，但由此例知，F2未执行。,软件工程,20,9.3.2 判定结构分析,当程序中判定多于一个时，形成的分支结构可以分为两类：嵌套型分支结构和连锁型分支结构。 对于嵌套型分支结构，若有 n 个判定语句，则

15、存在 n+1 条路径，需要 n+1 个测试用例； 对于连锁型分支结构， 若有 n 个判定语句，需要有 2n 个测试用例，覆盖它的 2n 条路径。 当 n 很大时，路径数成为天文数字，因此，就有覆盖率的问题。,嵌套型分支结构,连锁型分支结构,软件工程,21,为减少测试用例的数目，可采用实验设计法，抽取部分路径进行测试。 由于抽样服从均匀分布，因此，在假定各条路径的重要性相同，或暂不明确各条路径的重要性的情况下可以做到均匀抽样。 如果明确了各条路径的重要性，还可以采取加权的办法，筛选掉部分路径，再进行抽样。,软件工程,22,单重循环,嵌套循环,连锁循环,非结构循环,9.3.3 循环结构分析,循环分

16、为 4 种不同类型：简单循环、连锁循环、嵌套循环和非结构循环。,软件工程,23,在数组 A1.n 中从第i 个位置起选择最小值，用 k 记忆最小值的位置。 k = i; for ( j = i+1; j = n; j+ ) if ( Aj Ak ) k = j;,单重循环情形 零次循环：从循环入口到出口 一次循环：检查循环初始值 二次循环：检查多次循环 m次循环： 检查在多次循环 最大次数循环、比最大次数多一次、少一次的循环。,测试用例选择,软件工程,24,嵌套循环情形 对最内层循环做简单循环的全部测试。所有其他层的循环变量置为最小值； 逐步外推，对其外面一层循环进行测试。测试时保持所有外层循

17、环的循环变量取最小值，所有其他嵌套内层循环的循环变量取“典型”值。 反复进行，直到所有各层循环测试完毕。 对全部各层循环同时取最小循环次数，或者同时取最大循环次数。 连锁循环 如果各个循环互相独立，则可以用与简单循环相同的方法进行测试。 但如果几个循环不是互相独立的，则需要使用测试嵌套循环的办法来处理。 非结构循环 这一类循环应该使用结构化程序设计方法重新设计测试用例。,软件工程,25,9.3.4 基本路径测试,基本路径测试方法把覆盖的路径数压缩到一定限度内，程序中的循环体最多只执行一次。 设计出的测试用例要保证在测试中，程序的每一个可执行语句至少要执行一次。,1.程序的控制流图,软件工程,2

18、6,复杂性度量方法： (1) 控制流图的区域数 （2） V(G) =E N +2 =11-9+2=4 其中，V(G) 是图G中环路数，E是图中弧数，N是图中结点数 （3） V(G) =P+1 =3+1 P 是图G中判定结点数,软件工程,27,2. 程序环路复杂性,程序环路复杂性给出了程序基本路径集中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必需的测试用例数目的上界。 从控制流图来看，一条独立路径是至少包含有一条在其他独立路径中从未有过的边的路径。 例如，在控制流图中，一组独立的路径是path1：1 - 11path2：1 - 2 - 3 - 4 - 5 - 10 - 1 - 1

19、1path3：1 - 2 - 3 - 6 - 8 - 9 - 10 - 1 - 11path4：1 - 2 - 3 - 6 - 7 - 9 - 10 - 1 - 11,路径 path1，path2，path3，path4组成了控制流图的一个基本路径集。,软件工程,28,确保基本路径集中的每一条路径的执行。,3. 导出测试用例,举例：选择排序（C/C+描述）,基本路径集 path1: 1-3 path2: 1-2-5-8 path3: 1-2-5-9 path4: 1-2-4-6 path5: 1-2-4-7 测试用例 Path1: 1-3 取 n = 1 Path2: 1-2-5-8-3 取

20、n = 2 预期结果：路径5-8-3不可到达 Path3: 1-2-5-9-3 取 n = 2 预期结果：路径5-9-3不可到达 path4: 1-2-4-6-5-8-3 取 n = 2, v0 = 2, v1 = 1 预期结果：k = 1, v0 = 1, v1 = 2 path4: 1-2-4-6-5-9-3 取 n = 2，v0 = 2, v1 = 1 预期结果：k = 1, 路径 9-3 不可到达 path5: 1-2-4-7-5-8-3 取 n = 2，v0 = 2, v1 = 1 预期结果：k = 0, 路径 8-3 不可到达 path5: 1-2-4-7-5-9-3 取 n =

21、2，v0 = 2, v1 = 1 预期结果：k = 0, v0 = 1, v1 = 2,n,软件工程,29,9.4 黑盒测试用例设计方法,等价类划分 边界值分析 判定表法 因果图法 规范导出法,内部边界值法 错误推测法 接口测试 使用各种测试方法的综合策略,软件工程,30,9.4.1 等价类划分,等价类划分方法把所有可能的输入数据，划分成若干部分，然后从每一部分中选取少数代表性的数据做为测试用例。 等价类划分方法步骤： 1、划分等价类（列出等价类表）2、选取测试用例,划分等价类 等价类是指在某个输入域的子集合中，各个输入数据对于揭露程序中的错误都是等效的。测试某等价类的代表值就等价于对这一类其

22、他值的测试。等价类的划分有两种不同的情况： 有效等价类：是对于程序规格说明来说，是合理的，有意义的输入数据构成的集合。 无效等价类：是指对于程序规格说明来说，是不合理的，无意义的输入数据构成的集合。 在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。,软件工程,31,划分等价类的原则。 (1)如果输入条件规定了取值范围，或值的个数，则可确立一个有效等价类和两个无效等价类。 如，在程序规格说明中对输入条件有一句话： “ 项数可以从1到999 ” 则有效等价类是“1项数999” 两个无效等价类是“项数1”或“项数999”。在数轴上表示成:,无效等价类,有效等价类,无效等价类,1,999,(

23、2)如果输入条件规定了输入值的集合，或者是规定了“必须如何”的条件，这时可确立一个有效等价类和一个无效等价类。 例如，在Pascal语言中对变量标识符规定为“以字母打头的串”。那么所有以字母打头的构成有效等价类，而不在此集合内（不以字母打头）的归于无效等价类。,软件工程,32,如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类。 为每一个输入值确立一个有效等价类，和一个无效等价类。 例如，在教师上岗方案中规定对教授、副教授、讲师和助教分别计算分数，做相应的处理。 因此可以确定 4 个有效等价类为教授、副教 授、讲师和助教，一个无效等价类，它是所有不符合以上身分的人员的输入值的集

24、合。 如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。 例如，Pascal语言规定 “一个语句必须以分号;结束”。这时可以确定一个有效等价类 “以;结束”，若干个无效等价类 “以:结束”、“以,结束”、“以 结束”、“以LF结束”。,软件工程,33,确立测试用例 在确立了等价类之后，建立等价类表，列出所有划分出的等价类。 再从划分出的等价类中按以下原则选择测试用例： 为每一个等价类规定一个唯一编号； 设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止； 设计一个新的测试用例

25、，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。,软件工程,34,用等价类划分法设计测试用例的实例 在某一Pascal语言版本中规定： “标识符是由字母开头，后跟字母或数字的任意组合构成。编译器能够区分的有效字符数为8 个，最大字符数为 80 个。” 并且规定：“标识符必须先说明，再使用。”“在同一说明语句中，标识符至少必须有一个。”,用等价类划分方法，建立输入等价类表:,软件工程,35, VAR x，T1234567：REAL； BEGIN x := 3.414； T1234567 := 2.732； . (1), (2), (4), (8), (9),

26、 (12), (14) VAR ：REAL； (3) VAR x，：REAL; (5) VAR T12345678：REAL； (6) VAR T12345.：REAL； (7) 多于80个字符, VAR T$：CHAR； (10) VAR GOTO：INTEGER； (11) VAR 2T：REAL； (13) VAR PAR：REAL； (15) BEGIN . PAP := SIN (3.14 * 0.8) / 6；,下面选取了 9 个测试用例，它们覆盖了所有的等价类。,软件工程,36,例题：对用户输入的分数进行评级，其中90到100为A，80-89为B，70-79为C，60-69为D，

27、60以下为E。输入分数要求必须是正整数或0。根据分析得出以下等价类划分列。,软件工程,37,9.4.2 边界值分析,边界值分析也是黑盒测试方法，是对等价类划分方法的补充。 经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。 例如，有一段小程序，输入三个整数a、b和c，判断它们能否构成三角形。只有在 a0、b0、c0、a+bc、a+cb、b+ca 时才能构成三角形。但如果把六个不等式中的任一个大于号“”错写成大于等于号“”，那就不能构成三角形。 问题恰出现在容易被疏忽的边界附近。边界是指，输入等价类时，稍高于其边界值

28、及稍低于其边界值的一些特定情况。 使用边界值分析方法设计测试用例，首先应确定边界情况。通常应当针对输入等价类的边界，选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据，而不是选取等价类中的典型值或任意值做为测试数据。,软件工程,38,如何确定边界？通常的边界检查原则： 数字：最大最小刚大于最大刚小于最小、 字符串： 位置（首位末位首位前末位后） 长度（零 很大 超出缓冲区） 取值范围（刚到达边界 刚超出边界） 其他如质量、大小、速度、方位、尺寸、空间等都可按照最轻 最重，最大最小，最快最慢、最高最低、最短最长、空满等确定边界。,软件工程,39,使用边界值分析，最重要的是确定正确的边界值域。

29、对于输入输出等价类，选取正好等于、刚刚大于和刚刚小于边界值的数据作为测试数据。 例如，判断三角形问题，问题的提法是：程序接受 3 个整数 a、b 和 c 作为输入，用做三角形的边。整数 a、b 和 c 必须满足以下条件： C11a200 C21b200 C31c200 C4ab + c C5ba + c C6ca + b 按照构成三角形的条件 C1、C2和C3，整数a、b、c的边界值为1和200，稍超出边界的值为0和201。 C4、C5和C6的边界值分别是b+ca+1、a+cb+1和b+ca+1。,软件工程,40,C11a200 C21b200 C31c200 C4ab + c C5ba +

30、c C6ca + b,软件工程,41,9.4.3 判定表法,判定表是一种用来表示和分析复杂逻辑关系的工具，最适合描述在多个逻辑条件取值的组合所构成的复杂情况下，分别要执行哪些不同的动作。 例如，下表给出了一个用于三角形问题的判定表的例子。在表中 ci 是条件，ai 是判定结果，由（ci , ai）构成的规则可视为测试用例。 在某些条件取值中出现了“”，表示这个条件在相应规则中被忽略。,软件工程,42,三角形问题的判定表,软件工程,43,细化后的判定表,软件工程,44,三角形问题的测试用例,软件工程,45,9.4.4 因果图法,因果图的适用范围 如果在测试时必须考虑输入条件的各种组合情况时，可使

31、用一种适合于描述多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。 因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。 用因果图生成测试用例的基本步骤 分析软件规格说明中，哪些是原因（即输入条件或其等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。 分析软件规格说明的语义，找出原因与结果之间对应的关系。根据这些关系，画出因果图。 由于语法或环境限制, 有些原因与原因之间，原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件。把把因果图转换成判定表。 判定表的每一列拿出来作为依据，设计测试

32、用例。,软件工程,46,在因果图中出现的基本符号 通常在因果图中用 Ci 表示原因，用 Ei 表示结果，各结点表示状态， “0”表示状态不出现，“1”表示状态出现。 主要的原因和结果之间的关系有: a) 恒等 b)非,为了表示原因与原因之间，结果与结果之间可能存在的约束条件，在因果图中可以附加一些表示约束条件的符号。,软件工程,47,例如，有一个处理单价为5元钱的饮料的自动售货机软件测试用例的设计。其规格说明如下： 若投入 5 元钱或 10 元钱的硬币，押下橙汁或啤酒的按钮，则相应的饮料就送出来。 若售货机没有零钱找，则一个显示零钱找完的红灯亮。这时，在投入 1 0元钱并押下按钮后，饮料不送出

33、来而且 10 元钱也退出来； 若有零钱找，则显示零钱找完的红灯灭，在送出饮料的同时退还5元硬币。 1)分析这一段说明，列出原因和结果 结果： 21. 售货机零钱找完灯亮 22. 退还10元硬币 23. 退还5元硬币 24. 送出橙汁饮料 25. 送出啤酒饮料 2)画出因果图。所有原因结点列在左边，所有结果结点列在右边。建立中间结点，表示中间状态: 11. 投入 10 元硬币且押下饮料按钮 12. 押下橙汁或啤酒的按钮 13. 应找 5元零钱且售货机有零钱找 14. 钱已付清 3)由于 2 与 3 ，4 与 5 不能同时发生，分别加上约束条件E。 4)因果图转换成判定表。 5)在判定表中选择测试

34、用例。,原因: 1. 售货机有零钱找 2. 投入10元硬币 3. 投入5元硬币 4. 押下橙汁按钮 5. 押下啤酒按钮,软件工程,48,软件工程,49,软件工程,50,9.4.5-1 规范（规格）导出法,规范导出法是根据规格说明的描述来设计测试用例。每一个测试用例用来测试一个或多个规格说明的陈述语句。 例如，考虑一个计算平方根的函数的规格说明： 输入：实数（浮点数） 输出：实数（浮点数） 规格：当输入一个 0 或者比 0 大的数时，返回其正平方根； 当输入一个小于 0 的数时，显示错误信息“平方根非法输入值小于0”，并返回 0；库函数Print_Line可以用来输出错误信息。 测试用例1：输入

35、 4，输出 2。对应规范中的第一句陈述（当输入一个 0 或比 0 大的数时，返回其正的平方根）。 测试用例2：输入 -1，输出 0。对应规范中的第二、第三句陈述,软件工程,51,9.4.5-2 内部边界值测试法,在许多情况下，可以从单元的功能规格说明中导出等价类和边界值测试。 但一个单元也可能有内部边界，它们只能从单元的结构化规格说明中找到。 例如，考虑用伪代码描述的用连续迭代法求平方根函数的一个片段： Calculate first approximation LOOP Calculate error EXIT_LOOP WHEN error desired accuracyAdjust a

36、pproximation END_LOOP RETURN my_answer 对该内部边界值分析包括 3 个需要测试的条件： 测试用例1：误差恰好大于期望精度。 测试用例2：误差等于期望精度。 测试用例3：误差恰好小于期望精度。 内部边界值测试可以用来发现一些内部错误。如误把“”写做“=”。但内部边界值测试应作为一种补充方法，在其他方法的最后使用。,软件工程,52,错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。 例如，如果所有的资源都需要动态申请，最容易出错的地方就是资源释放的语句。 可以利用不同测试阶段的经验和对软件系统的认识来设计测试用

37、例。 例如，在单元测试中某程序模块已经遇到错误,在系统测试中可以在这些可能出现问题的地方再组织测试用例。 在前一个版本中发现的常见错误在下一个版本的测试中有针对性地设计测试用例。 错误猜测是基于经验和其他一些测试技术（如边界值测试） 为了最大限度地利用有效的经验并逐步丰富测试用例设计技术，可以建立一个错误类型的列表（常见错误检查表） 一个好的错误猜测可能发现被别的测试方法很容易地遗漏的错误。但反过来，错误猜测也可能是白白浪费时间。,9.4.5-3 错误猜测法,软件工程,53,9.4.6 接口测试,当模块或子系统集成为更大的系统时就需要进行接口测试。 接口测试的目的是检测那些由于接口有误或对接口

38、做出了无效假设而造成的系统缺陷。 程序构件的接口类型有： 参数接口 共享内存接口 程序接口 消息传递接口 接口错误是常见的系统错误，有3种接口错误: 接口误用：构件调用时接口使用不当造成的错误。例如，在参数接口情形，使用的参数类型、排列顺序或参数个数不匹配。 接口误解：调用者构件误解了被调用构件的接口描述，或对被调用者的行为作了错误的假设而造成的错误。例如，调用折半搜索例程时使用了未排序的数组导致搜索失败。 计时错误：在实时系统中，系统使用了共享内存接口或消息传递接口可能产生的错误。原因在于数据的生产和消费的速度可能不同。,软件工程,54,9.4.7 使用各种测试方法的综合策略,在任何情况下都

39、必须使用边界值分析法。用这种方法设计出测试用例发现程序错误的能力最强。 必要时用等价类划分法补充一些测试用例。 用错误推测法再追加一些测试用例。 对照程序逻辑，检查已有测试用例的逻辑覆盖程度。如果未达到要求的覆盖标准，应再补充足够的测试用例。 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。,软件工程,55,为系统运行设计用例 单元测试设计中的第一个测试用例最有可能是用最简单的方法执行被测单元。 当第一个测试用例可以正常执行，至少知道测试环境和被测试单元是可用的，可以增强人的自信心。 如果运行失败，最好选择一个更简单的输入对被测单元进行测试调试。 可用的测试方法有：规范导

40、出法，等价类划分等。,9.5 单元测试用例设计,单元测试用例设计的根据是详细设计说明。,软件工程,56,为正向测试设计用例 正向测试的测试用例用于验证被测单元的功能和性能指标是否能够兑现。 测试用例的设计者应该通读相关的详细设计说明。每一个测试用例，都是针对详细设计说明中的一项或多项内容来设计的。 可用的测试方法有：规范导出法，等价类划分，状态图法等。 为逆向测试设计用例 逆向测试的测试用例用来验证被测软件单元有没有做它不应该做的事情。 它主要依赖边界值分析或状态迁移等方法来构造测试用例，需要依靠测试设计者的经验和判断。 可用的测试方法有：错误猜测法；边界值分析；内部边界值测试；状态图法等。,

41、软件工程,57,为满足特殊需求设计用例 从系统的性能、安全性、保密性的角度来设计测试用例。尤其对于安全及保密要求较高的系统，在测试设计说明中应该特别标明用来进行安全及保密的测试用例。 可用的测试方法为规范导出法。 为代码覆盖设计用例 设计好的测试用例可以保证较高的代码测试覆盖率。 在单元测试方案中，为了达到特定的测试覆盖目标，可能还需要补充足够的测试用例。 当为测试覆盖率而补充的测试用例设计好后，测试设计说明基本完成，就可以具体执行测试用例了。 可用的测试方法有：判定表法；条件测试；数据流测试；状态图法等,软件工程,58,为覆盖率指标完成设计用例 测试过程中的动态分析可以产生代码覆盖率测量值，

42、以指示是否已经达到了覆盖目标。因此需要在测试设计说明中增加一个完善代码覆盖率的步骤。 在被测试的代码中可能包含有复杂的判断条件，循环以及分支语句，因此在执行测试用例的过程中，覆盖率的目标有可能无法达到。当这种情况发生时，有必要分析为什么会导致覆盖率目标没有达到。一般的原因可能有： 不可能的路径或条件； 不可到达的或冗余的代码； 测试用例不足等。 可用的测试方法有：判定表法；条件测试；数据流测试（数据定义使用测试）；状态图法等。,软件工程,59,9.5.2 单元测试用例设计方法,单元测试的测试用例设计应与代码检查以及评审工作相结合，根据设计信息选取测试数据。 单元测试用例的设计既可以使用白盒测试

43、也可以使用黑盒测试，但以白盒测试为主。 白盒测试可使用语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、路径覆盖等技术。 白盒测试最低的覆盖率目标是： 语句覆盖率达到100； 分支覆盖率达到100； 覆盖程序中的主要路径，即覆盖完成需求和设计功能的代码所在的路径和程序异常处理执行到的路径。,软件工程,60,单元测试白盒测试用例覆盖需求： 对程序模块所有独立执行路径至少覆盖一次。 对所有逻辑判定，真、假两个分支都至少覆盖一次。 在循环的边界和运行界限内执行循环体。 测试内部数据结构的有效性等。 单元测试黑盒测试测试用例覆盖需求： 测试程序单元的功能是否实现。 测试程序单元性能是否满足要求（可选）。 是

44、否有可选的其他测试特性，如边界、安全性、可靠性、强度测试、人机交互界面测试等。,软件工程,61,1. 操作级的测试用例,在面向对象程序中，每个操作都作用在它所在类的属性上并通过参数表实现数据的输入输出。 如果一个操作的内聚性很高，而且提供的功能又比较复杂，可以考虑对其孤立地进行测试。 如果操作与属性的关联很强，必须考虑几个与该属性有关的操作之间的相互作用。 对单个操作孤立地测试类似于在传统的结构化程序中对单个函数的测试，许多相关的测试技术都可以使用。,面向对象程序的单元测试的被测单元通常是一个类、类树或一个孤立的类操作。,软件工程,62,等价类划分法 标识该操作的功能； 识别该操作的输入和输出

45、； 把每个输入数据的取值范围划分为若干个等价类，在每个等价类中选取一个内部值再加上若干边界值； 针对操作中采用的算法或模型，排除各个输入数据和变量之间取值的冲突； 通过枚举产生各个输入数据和变量的所有取值的组合，排除有冲突的组合，剩余的每个组合作为一个测试数据组； 针对每个测试数据组给出预期的输出结果。,软件工程,63,判定表法 针对那些依据输入参数和属性值的不同取值组合而选择不同动作的操作。为此设计一个判定表。 递归函数测试 在面向对象程序的单元测试中，需要对递归操作单独测试。 对于递归操作的测试首先要达到分支覆盖，即保证每个分支都被测试到；其次，由于递归函数中的许多常见错误能够逃脱分支覆盖

46、的测试用例集的检测，还要测试以下情况： 零次递归； 一次递归； 多次递归（有时需要测试最大次数递归，特别是对消耗资源较多的递归操作）； 试图破坏平凡情况的前置条件； 试图破坏一次调用自己的前置条件； 试图破坏一次调用自己的后置条件。,软件工程,64,多态消息测试 在面向对象程序中，如果一个操作（设为A）引用了需要动态绑定的操作（设为B），在单独对 A 操作进行测试时，需要覆盖 B 操作可能绑定的所有实现。 通常有两种情况： 用来调用 B 操作的对象是 A 操作的输入参数或类成员变量，需要测试该参数或变量的其他可能取值（想象C+中的重载操作+，根据参数类型绑定不同实现）； 用来调用 B 操作的对

47、象是在 A 操作中根据输入参数或变量创建的，此时需要测试能够创建出的各个类的对象（想象C+中的模板）。,软件工程,65,2. 类级测试,合理的测试是将这些相互依赖的操作放在一起进行测试。这就是所谓的类级测试。 不变式边界测试 首先准确定义类的不变式，其次寻找违反类不变式的操作调用序列，将其作为测试用例。然后再寻找满足不变式状态的操作调用序列作为测试用例。 在不变式的边界上出现不满足的状态。例如，一个栈类Stack的类不变式为Stack.top = 0，不变式边界为Stack.top = 0，违反不变式的状态为Stack.top = -1，即空栈状态。如果在空栈时调用操作Pop()，就是违反不变

48、式的调用序列。 如果不变式是几种状态的析取，则需要考虑每个状态从满足转换到不满足时，其他状态是否会发生相应的转换。例如，不变式为 (a = 0 | b = 0)，可以考虑当 b 小于零时，a 的值从 a = 0 变化到 a 0。类似地，还应该考虑 a = 0 的情况。,软件工程,66,模态类测试 模态类是指类在处于特定的状态下时，只能接受对某些特定操作的调用。 测试时首先需要对类的状态建模，确定类的不同状态、每个状态下可接受的操作调用以及状态间的转换关系，从而获得类状态图。 基于状态图，生成调用序列来覆盖状态图上的边和路径。其中每个调用序列可以作为该类的一个测试用例。 例如，栈Stack就是模

49、态类，有栈空、栈非空非满、栈满等 3 个状态。在栈空状态Stack只接受进栈操作Push()，在栈满状态Stack类只接受退栈操作Pop()。可针对这些限制来构建相应的状态图，据此设计测试用例。 非模态类测试 非模态类是指该类对所接受的操作调用序列没有任何限制。 例如，把一个计算SIN的算法定义为一个类，这就是非模态类。它没有特定的状态，所以不能用状态图来指导开发测试用例。,软件工程,67,对于子类的测试通常不能限定在子类中定义的属性和操作上，还需要考虑父类对子类的影响。,3. 类树级的测试,多态服务测试 通过继承实现多态时，子类对父类中多态操作的覆盖应保持父类对该操作的规格说明。 假设已存在

50、父类的一个测试用例集，在对子类进行测试时，可以选取其中涉及相关多态操作的测试用例，并把子类的实例当作父类的实例用这些选出来的测试用例执行。 展平测试 将子类自身定义的操作和属性以及从父类和祖先类继承来的操作和属性全部放在一起组成一个新类（如果操作间存在覆盖关系，还需要确定哪些操作是子类真正拥有的），并对其进行测试。,软件工程,68,9.6 集成测试的测试用例设计,集成测试是界于白盒测试和黑盒测试之间的灰盒测试，因此在该测试的用例设计方法中，综合使用两类测试中的测试分析方法。 一般经过集成测试分析之后，测试用例的大致轮廓已经确定，集成测试用例设计的基本要求就是要充分保证其正确性，保证其能无误地完

51、成测试项既定的测试目标，以满足相应的测试覆盖率要求,软件工程,69,9.6.1 集成测试用例设计的步骤,为系统运行设计测试用例 单元测试是不彻底的，对于模块间的接口信息内容的正确性，相互调用关系是否符合设计规格无法检查，需靠集成测试来保证。 集成测试关注的是各模块的接口是否能用。因此，集成测试的第一步工作就是设计一些起码能够保证系统运行的测试用例，也就是验证最基本功能的测试用例。 集成测试的测试用例需根据测试目标设计。 可用的测试方法有：等价类划分、边界值分析、判定表法等。,软件工程,70,为正向测试设计测试用例 正向集成测试的重点就是验证集成后的模块是否按照设计实现了预期的功能。 基于这样的

52、测试目标，可以直接根据概要设计文档导出相关的用例。 可用的测试方法有：等价类划分、状态图法、规范导出法等。,软件工程,71,为逆向测试设计测试用例 集成测试中的逆向测试包括 分析被测接口是否实现了需求规格没有描述的功能； 检查规格说明中可能出现的接口遗漏； 判断接口定义是否有错误和可能的接口异常错误（接口数据错误，接口数据顺序错误）等。,对于面向对象程序和GUI进行测试有时还要考虑可能出现的状态异常，包括：,是否遗漏或出现了不正确的状态转换； 是否遗漏了有用的消息； 是否会出现不可预测的行为； 是否有非法的状态转换（如从一个页面可以非法进入某些只有登录以后或经过身份验证才可以访问的页面）； 是

53、否有一个可能的潜行路径； 是否会有一个不期望的消息而引起失效； 是否会接受一个没有定义的消息等。,软件工程,72,为满足特殊要求设计测试用例 特殊需求包括系统的安全性、性能、可靠性等。在对模块进行单元测试和集成测试阶段就开展满足特殊需求的测试，为整个系统是否能够满足这些特殊需求把关。 可用的测试方法为规范导出法。 为高覆盖率设计测试用例 与单元测试关注的重点不同，在集成测试阶段应关注的重点是功能覆盖和接口覆盖。 通过对集成后的模块进行分析，来判断哪些功能以及哪些接口没有被覆盖到来设计测试用例。 可用的测试方法有：功能覆盖分析、接口覆盖分析等。 测试用例补充 在集成测试阶段能够及时跟踪项目变化，

54、按照需求增加和补充集成测试用例，保证进行充分的集成测试。,软件工程,73,9.7 系统测试的测试用例设计,系统测试用例设计基本上都是用黑盒测试方法。 系统测试的关键问题是：如何确定和选择测试用例才能保证对系统进行充分的测试? 除了常见的黑盒测试用例设计方法外，现在流行借助于一些行为模型或 UML 模型来设计和确定系统测试用例。 此外，还要制定一些标准，以便在避免不必要的测试用例冗余的同时度量系统测试的充分性。,软件工程,74,9.7.1 基于场景设计测试用例,在用事件触发来控制流程的软件中，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。 通过描绘事件触发时的情景，测试者设计测试用例，用以检查软件的功能需求是否得到满足。 场景测试方法是基于 IBM 公司提出的 RUP（统一建模语言）的测试用例生成方法。 该方法从用例出发，通过对每个用例的场景进行分析，逐步实现测试用例的构造。,软件工程,75,9.7.2 基于功能图设计测试用例,基于功能图来设计测试用例的方法是一种黑盒测试方法。它用功能图表示程序的功能说明，并机械地生成功能图的测试用例。 功能图模型由状态图和功能说明构成，状态图用于表示输入数据的变换序列以及相应的输出数据，功能说明用于表示在状