第3章 白盒测试用例设计方法

1、软件质量保证与测试第第3 3章章 软件测试的方法软件测试的方法西安财经学院软件质量保证与测试第第3 3章章 软件测试的方法软件测试的方法3.1 逻辑覆盖测试逻辑覆盖测试3.2 基本路径测试基本路径测试3.3 循环测试循环测试3.4 代码检查代码检查3.5 小结小结软件质量保证与测试方法论和具体方法方法论和具体方法p 从方法论看，更多体现了一种哲学的思想，例如辩证统一的方法，在测试中有许多对立统一体，如静态测试和动态测试、白盒测试和黑盒测试、自动化测试和手工测试等。p 软件测试的方法论来源于软件工程的方法论，例如有面向对象的开发方法，就有面向对象的测试方法；有敏捷方法，就有和敏捷方法对应的测试方

2、法。软件质量保证与测试黑盒子和白盒子黑盒子和白盒子功能测试功能测试数据驱动测试数据驱动测试 结构测试结构测试逻辑驱动测试逻辑驱动测试 客户需求事件驱动输入输出软件质量保证与测试静态的和动态的静态的和动态的主持人主持人作者记录员列席人员内审员内审员技术专业人员用户代表不正式正式互审 走读 审查会议运行程序运行程序软件质量保证与测试自动测试和手工测试自动测试和手工测试手工模拟用户手工模拟用户操作操作软件质量保证与测试3.1 3.1 逻辑覆盖测试逻辑覆盖测试3.1.1 3.1.1 语句覆盖语句覆盖3.1.2 3.1.2 判定覆盖判定覆盖3.1.3 3.1.3 条件覆盖条件覆盖3.1.4 3.1.4

3、判定条件覆盖判定条件覆盖3.1.5 3.1.5 条件组合覆盖条件组合覆盖3.1.6 3.1.6 路径覆盖路径覆盖软件质量保证与测试白盒测试方法白盒测试方法v 白盒测试也称结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例，主要用于软件或程序验证。v 采用白盒测试方法必须遵循以下几条原则，才能达到测试的目的： 保证一个模块中的所有独立路径至少被测试一次。 所有逻辑值均需测试真 (true) 和假 (false) 两种情况。 检查程序的内部数据结构，保证其结构的有效性。 在上下边界及可操作范围内运行所有循环。软件质量保证与测试白盒测试方法白盒测试方法v

4、 白盒测试法检查程序内部逻辑结构，对所有逻辑路径进行测试，是一种穷举路径的测试方法。但即使每条路径都测试过了，仍然可能存在错误。因为： 穷举路径测试无法检查出程序本身是否违反了设计规范，即程序是否是一个错误的程序。 穷举路径测试不可能查出程序因为遗漏路径而出错。 穷举路径测试发现不了一些与数据相关的错误。软件质量保证与测试测试覆盖标准测试覆盖标准软件质量保证与测试测试覆盖标准测试覆盖标准v上页小程序的流程图，其中包括了一个执行达20次的循环。那么它所包含的不同执行路径数高达520（1013）条，若要对它进行穷举测试，覆盖所有的路径。假使测试程序对每一条路径进行测试需要1毫秒，同样假定一天工作2

5、4小时，一年工作365，那么要想把如图所示的小程序的所有路径测试完，则需要3170年。软件质量保证与测试白盒测试方法白盒测试方法v 白盒测试主要是检查程序的内部结构、逻辑、循环和路径。常用测试用例设计方法有： 逻辑覆盖逻辑覆盖：以程序的内部逻辑结构为基础，分为语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖等。 基本路径测试基本路径测试：在程序控制流程的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。软件质量保证与测试例：实现一个简单的数学运算例：实现一个简单的数学运算v Dim a,b As Integerv Dim c As Doublev If (a

6、0 And b0) Thenv c=c/av End ifv If (a1 or c1) Thenv c=c+1v End if1. c=b+c软件质量保证与测试3.1.13.1.1 语句覆盖语句覆盖p语句覆盖法的基本思想是设计若干测试用例，运行被测程序，使程序中的每个可执行语句至少被执行一次软件质量保证与测试续续只需设计一个测试用例: a=2，b=1，c=6；即达到了语句覆盖。软件质量保证与测试续续v 【优点】【优点】 ：可以很直观地从源代码得到测试用例，无须细分每条判定表达式。v 【缺点】【缺点】 ：由于这种测试方法仅仅针对程序逻辑中显式存在的语句，但对于隐藏的条件是无法测试的。如在多分支

7、的逻辑运算中无法全面的考虑。语句覆盖是最弱的逻辑覆盖。软件质量保证与测试3.1.23.1.2 判定覆盖判定覆盖p判定覆盖法的基本思想是设计若干用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断真假值均曾被满足。p一个判定往往代表着程序的一个分支，所以判定覆盖也被称为分支覆盖。软件质量保证与测试续续 a=2，b=1 ，c=6可覆盖判断M的Y分支和判断N的Y分支； a=-2，b=-1 ，c=-3可覆盖判断M的N分支和判断N的N分支 。 这两组测试用例可覆盖所有判定的真假分支。判断M判断N软件质量保证与测试续续 a=1，b=1 ，c=-3 可覆盖判断M的Y分支和判断N的N

8、分支 ； a=1，b=-2 ，c=3可覆盖判断M的N分支和判断N的Y分支 ； 同样的这两组测试用例也可覆盖所有判定的真假分支。判断M判断N软件质量保证与测试续续v 【优点】【优点】：判定覆盖具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。v 【缺点】【缺点】：往往大部分的判定语句是由多个逻辑条件组合而成，若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。判定覆盖仍是弱的逻辑覆盖。软件质量保证与测试3.1.33.1.3 条件覆盖条件覆盖p条件覆盖的基本思想是设计若干测试用例，执行被测程序以后，要使每个判断中每个

9、条件的可能取值至少满足一次。result=maxint（iN) and (result=maxint)TrueFalsei0 取真 记为 T1 取假 记为 F1 条件 b0 取真 记为 T2 取假 记为 F2v 判断Q表达式:设条件 a1 取真 记为 T3 取假 记为 F3 条件 c1 取真 记为 T4 取假 记为 F4判断M判断N软件质量保证与测试续续它覆盖了判定M的N分支和判断N的Y分支。我们用条件覆盖设计的思想就是让测试用例能覆盖T1、T2、T3、T4、F1、F2、F3、F4判断M判断N软件质量保证与测试续续v 【优点】【优点】：增加了对条件判定情况的测试，增加了测试路径。v 【缺点】【

10、缺点】：条件覆盖不一定包含判定覆盖。例如，我们刚才设计的用例就没有覆盖判断M的Y分支和判断N的N分支。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。软件质量保证与测试3.1.43.1.4 判定条件覆盖判定条件覆盖p判定-条件覆盖是判定和条件覆盖设计方法的交集，即设计足够的测试用例，使得判断条件中的所有条件可能取值至少执行一次，同时，所有判断的可能结果至少执行一次软件质量保证与测试判断M判断N续续按照判定条件覆盖的要求，我们设计的测试用例要满足如下条件：1.所有条件可能至少执行一次取值；2.2.所有判断的可能结果至少执行一次。所有判断的可能结果至少执行一次。要满足要满足T1、T

11、2、 T3 、T4F1、 F2 、F3、F4软件质量保证与测试续续判断M判断N要满足要满足T1、T2、 T3 、T4F1、 F2 、F3、F4软件质量保证与测试续续v 【优点】【优点】 ：能同时满足判定、条件两种覆盖标准。v 【缺点】【缺点】 ：判定/条件覆盖准则的缺点是未考虑条件的组合情况。软件质量保证与测试3.1.53.1.5 条件组合覆盖条件组合覆盖p条件组合覆盖的基本思想是设计足够的测试用例，使得程序中每个判断的所有可能的条件取值组合都至少出现一次。p它与条件覆盖的差别是它不是简单地要求每个条件都出现“真”与“假”两种结果，而是要求让这些结果的所有可能组合都至少所有可能组合都至少出现一

12、次。出现一次。软件质量保证与测试续续v 按照条件组合覆盖的基本思想，对于前面的例子，我们把每个判断中的所有条件进行组合，设计组合条件如表所示，而我们设计的测试用例就要包括所有的组合条件。软件质量保证与测试续续覆盖了所有组合，但覆盖路径有限，1-2-5 没被覆盖软件质量保证与测试续续要满足要满足1、2、3、4、5、6、7、8条件组合条件组合软件质量保证与测试续续v 【优点】【优点】：条件组合覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。v 【缺点】【缺点】：线性地增加了测试用例的数量。软件质量保证与测试3.1.63.1.6覆盖覆盖p顾名思义，路径覆盖就是设计所有的测试用例，来覆盖程序中的所

13、有可能的执行路径。软件质量保证与测试续续软件质量保证与测试续续v 【优点】【优点】 ：这种测试方法可以对程序进行彻底的测试，比前面五种的覆盖面都广。v 【缺点】【缺点】 ：需要设计大量、复杂的测试用例，使得工作量呈指数级增长，不见得把所有的条件组合都覆盖。软件质量保证与测试 从前面的例子我们可以看到，采用任何一种覆盖方法都不能满足我们的要求，所以，在实际的测试用例设计过程中，可以根据需要将不同的覆盖方法组合起来使用，以实现最佳的测试用例设计 。软件质量保证与测试逻辑覆盖法逻辑覆盖法v 根据覆盖目标的不同，逻辑覆盖又可分为语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖和路径覆盖。 语句覆

14、盖：选择足够多的测试用例，使得程序中的每个可执行语句至少执行一次。 判定覆盖：通过执行足够的测试用例，使得程序中的每个判定至少都获得一次“真”值和“假”值， 也就是使程序中的每个取“真”分支和取“假”分支至少均经历一次，也称为“分支覆盖”。 条件覆盖：设计足够多的测试用例，使得程序中每个判定包含的每个条件的可能取值（真/假）都至少满足一次。软件质量保证与测试逻辑覆盖法（续）逻辑覆盖法（续） 判定/条件覆盖：设计足够多的测试用例，使得程序中每个判定包含的每个条件的所有情况（真/假）至少出现一次，并且每个判定本身的判定结果（真/假）也至少出现一次。 满足判定/条件覆盖的测试用例一定同时满足判定覆盖

15、和条件覆盖。 组合覆盖：通过执行足够的测试用例，使得程序中每个判定的所有可能的条件取值组合都至少出现一次。 满足组合覆盖的测试用例一定满足判定覆盖、条件覆盖和判定/条件覆盖。 路径覆盖：设计足够多的测试用例，要求覆盖程序中所有可能的路径。 软件质量保证与测试3.2 3.2 基本路径测试基本路径测试v 程序流程图又称框图，是我们最熟悉，也是最容易理解的一种程序控制结构的图形表示了。在这种图上的框里面常常标明了处理要求或者条件，但是，这些标注在做路径分析时是不重要的。为了了更加突出控制流的结构，需要对程序流程图做一些简化。v 控制流图（可简称流图）是对程序流程图进行简化后得到的，它可以更加突出的表

16、示程序控制流的结构。v 控制流图中包括两种图形符号：节点和控制流线。 节点由带标号的圆圈表示，可代表一个或多个语句、一个处理框序列和一个条件判定框（假设不包含复合条件）。 控制流线由带箭头的弧或线表示，可称为边。它代表程序中的控制流。软件质量保证与测试续续在控制流图中只有两种图形符号，它们是：1.节点：以标有编号的圆圈表示。它代表了程序流程图中矩形框表示的处理、菱形表示的两个到多个出口判断以及两条到多条流线相交的汇合点。2.控制流线或弧：以箭头表示。它与程序流程图中的流线是一致的，表明了控制的顺序。为了方便讨论，控制流线通常标有名字，如图中所标的a、b、c等。在下图中，给出了简化的例子。其中（

17、a）图示一个含有两个出口判断和循环的程序流程图，我们把它简化成（b）的形式，称这种简化了的程序流程图叫做控制流图。 （a） （b）软件质量保证与测试基本路径测试法基本路径测试法1.依据代码绘制流程图2.确定流程图的圈复杂度（cyclomatic complexity ）3.确定线性独立路径的基本集合( basis set )4.设计测试用例覆盖每条基本路径软件质量保证与测试示例示例 源代码源代码Procedure: process records1.Do While records remain2.Read record;3.If record field 1 = 0 Then4.store

18、in buffer;5.increment counter;6.Else If record field 2 = 0 Then7.reset counter;8.Else store in file;9.End If10.End If11. End DoEnd软件质量保证与测试示例示例 流程图流程图1910112457836V(G) = 4软件质量保证与测试基本路径测试基本路径测试:流程图简化流程图简化12,387694,51011有的时候，我们可以把几个节点合并成一个，合并的原则是：若在一个节点序列中没有分支，则我们可以把这个序列的节点都合并成一个节点。软件质量保证与测试流程图的圈复杂度流程

19、图的圈复杂度 V(G) = 区域数量(由节点、连线包围的区域，包括图形外部区域) V(G) = 连线数量 - 节点数量 + 2 V(G) = 简单可预测节点数量 + 1圈复杂度（圈复杂度（Cyclomatic complexityCyclomatic complexity）: :代码逻辑复杂度的 度量，提供了被测代码的路径数量。复杂度越高，出错的概率越大。V(G)modules软件质量保证与测试流程图复杂度例子流程图复杂度例子V(G)=412,378694,51011Region 1Region 2Region 3Region 4软件质量保证与测试确定线性独立的路径集合确定线性独立的路径集合

20、独立路径独立路径： 至少引入一系列新的处理语句或条件的任何路径 基本集基本集： 由独立路径构成的集合 由基本集导出的测试用例测试用例，保证每行代码语句至少被执行一次 基本集合基本集合不一定唯一软件质量保证与测试 Path1: 1-2-3-6-7-9-10-1-11示例：基本路径测试用例示例：基本路径测试用例 Path2: 1-2-3-6-8-9-10-1-11 Path3: 1-2-3-4-5-10-1-11Path4: 1-111910112458736软件质量保证与测试测试用例覆盖集合中每条路径测试用例覆盖集合中每条路径基本路径测试并不是测试所有路径的组合，仅仅保证每条基本路径被执行一次

21、不需要活动图, 但最好绘制程序流程图 计算每个逻辑测试，也就是布尔操作符数加1 最好每个单元都进行基本路径测试，对关键组件则是必要的软件质量保证与测试3.3 循环测试循环测试v简单循环v串接循环v嵌套循环v复杂循环软件质量保证与测试n目标: 在循环内部及边界上执行测试循环测试循环测试 1 11.简单循环简单循环(迭代次数n) 完全跳过循环 只经过循环一次 经过循环两次 经过循环m（ m n ）次 分别经过循环n-1, n, n+1 次软件质量保证与测试循环测试循环测试 2 22. 2. 嵌套嵌套（Nested）循环循环在最里面的循环完成前面所述的简单循环测试，同时设定外部循环的最小迭代次数逐步

22、向外循环进行直到所有循环被测试软件质量保证与测试循环测试循环测试 3 34.4.其它非结构循环其它非结构循环重新设计重新设计! !3.3.串行连接的循环串行连接的循环独立循环 可以分别看着简单循环测试依赖性循环 可以看着是嵌套循环软件质量保证与测试静态测试定义静态测试定义v静态测试不实际运行软件，主要对软件的编程格式、结构等方面进行评估。v可以有人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。软件质量保证与测试 静态测试的方法静态测试的方法u代码检查 代码审查 代码走查 桌面检查 同行评分（略）u静态结构分析u代码质量度量软件质量保证与测试3.4 代码检查代码检查3.4.1 代

23、码审查v以组为单位阅读代码，是一系列规程和错误检查技术的集合。v通常由4人组成，其中一人是协调人，一人是程序的编写者，其他人员通常是程序的设计人员以及测试专家软件质量保证与测试协调人的职责？协调人的职责？v为代码检查分发材料、安排进程v在代码检查中起主导作用v记录发现的所有错误v确保所有错误随后得到改正软件质量保证与测试代码审查活动安排代码审查活动安排v在审查的前几天，协调人将程序清单和设计规范分发给其他成员。所有成员在检查之前熟悉这些材料。v审查时，由编码人员逐条语句讲述程序的逻辑结构。在讲述的过程当中，小组的其他成员提问题、判断是否存在错误。v对照历来常见的编码错误列表分析程序软件质量保证

24、与测试注意事项注意事项v协调人负责保证会的讨论高效的进行，每个参与者都将注意力集中在查找错误而不是修正错误v会后要确保错误得到修正v对错误清单要分析、归纳，用以提炼错误列表v会议时间在90-120分钟，不间断v每小时大约阅读150行代码，不要过多软件质量保证与测试代码审查的作用？代码审查的作用？v发现错误v程序员会在编程风格、算法选择及编程技术等方面得到反馈v其他参与者通过他人的错误、风格等受益匪浅v能够较早的发现程序中容易出错的部分，为后面的测试找到侧重点软件质量保证与测试用于代码审查的错误列表用于代码审查的错误列表-part11.是否有引用的变量未赋值或初始化2.下标的值是否在范围之内3.

25、是否存在非整数下标4.是否存在虚调用(dangling reference)对于所有的通过指针或引用变量的引用,当前引用的内存单元是否分配?5.当使用别名时属性是否匹配6.记录和结构的属性是否匹配,即变量值的类型或属性是否与编译器所预期的一致7.是否计算位串的地址?是否传递位串参数?8.基础的存储属性是否正确9.跨过程的结构定义是否匹配10.索引或下标操作是否有”仅差一个”的错误11. 继承需求是否得到满足软件质量保证与测试v 运算错误：运算错误：1 1是否存在非算术变量间的运算？是否存在非算术变量间的运算？2 2是否存在混合模式的运算？是否存在混合模式的运算？3 3是否存在不同字长变量间的运

26、算？是否存在不同字长变量间的运算？4 4目标变量的大小是否小于赋值大小？目标变量的大小是否小于赋值大小？5 5中间结果是否上溢或下溢？中间结果是否上溢或下溢？6 6是否存在被是否存在被0 0除？除？7 7是否存在二进制的不精确度？是否存在二进制的不精确度？8 8变量的值是否超过了有意义的范围？变量的值是否超过了有意义的范围？9 9操作符的优先顺序是否被正确理解？操作符的优先顺序是否被正确理解？10. 10. 整数除法是否正确？整数除法是否正确？用于代码审查的错误列表用于代码审查的错误列表-part2软件质量保证与测试v数据声明错误：1.是否所有的变量都已声明？2.默认的属性是否被正确理解？3.

27、数组和字符串的初始化是否正确？4.变量是否赋予了正确的长度、类型和存储类？5.初始化是否与存储类相一致？6.是否有相似的变量名？软件质量保证与测试v比较错误：1.是否存在不同类型变量间的比较？2.是否存在混合模式的比较运算？3.比较运算符是否正确？4.布尔表达式是否正确？ 5.比较运算是否与布尔表达式相混合？6.是否存在二进制小数的比较？7.操作符的优先顺序是否被正确理解？8.编译器对布尔表达式的计算方式是否被正确理解？软件质量保证与测试v控制流程错误：1.是否超出了多条分支路径？2.是否每个循环都终止了？3.是否每个程序都终止了？4.是否存在由于入口条件不满足而跳过循环体？5.可能的循环越界

28、是否正确？6.是否存在“仅差一个”的迭代错误？7.DO/END语句是否匹配？8.是否存在不能穷尽的判断？9.输出信息中是否有文字或语法错误？软件质量保证与测试v输入/输出错误：1.文件属性是否正确？2.OPEN语句是否正确？3.I/O语句是否符合格式规范？4.缓冲大小与记录大小是否匹配？5.文件在使用前是否打开？6.文件在使用后是否关闭？7.文件结束条件是否被正确处理？8.是否处理了I/O错误？软件质量保证与测试v 接口错误：1.形参的数量是否等于实参的数量？2.形参的属性是否与实参的属性相匹配？3.形参的量纲是否与实参的量纲相匹配？4.传递给被调用模块的实参个数是否等于其形参个数？5.传递给

29、被调用模块的实参属性是否与其形参属性匹配？6.传递给被调用模块的实参量纲是否与其形参量纲匹配？7.调用内部函数的实参的数量、属性、顺序是否正确？8.是否引用了与当前入口点无关的形参？9.是否改变了某个原本仅为输入值的形参？10.全局变量的定义在模块间是否一致？11.常数是否以实参形式传递过？软件质量保证与测试3.3.2 代码走查代码走查v人员：协调人、秘书、测试人员、程序员等。v区别：不同于仅阅读程序或使用错误列表，代码走查的参与者“使用了计算机”，被指定为测试员的人会带着一些书面的测试用例参加会议。v每个测试用例都在人们脑中进行推演，程序状态记录在纸上。v提供了启动代码走查和质疑程序员逻辑思

30、路及其设想的手段软件质量保证与测试3.4.3 桌面检查桌面检查v由一个人阅读程序，对照错误列表检查程序，对程序推测测试数据，可视为由单人进行的代码检查或代码走查。v效率非常低，why?（1）完全没有约束）完全没有约束（2）开发人员测试自己的程序）开发人员测试自己的程序（3）没有展示自己能力，缺乏良好的效应）没有展示自己能力，缺乏良好的效应结论：桌面检查胜于没有检查，但其效果远远逊于代码审结论：桌面检查胜于没有检查，但其效果远远逊于代码审查和代码走查查和代码走查软件质量保证与测试2.2静态结构分析静态结构分析v 静态结构分析主要是以图形的方式表现程序的内部结构。 例如函数调用关系图、函数内部控制

31、流图。其中： 函数调用关系图以直观的图形方式描述一个应用程序中各个函数的调用和被调用关系； 控制流图显示一个函数的逻辑结构，由许多节点组成，一个节点代表一条语句或数条语句，连接结点的叫边，边表示节点间的控制流向。软件质量保证与测试2.3代码质量度量代码质量度量根据ISO/IEC9126国际标准的定义，软件质量包括六个方面：v功能性(functionality)v可靠性(reliability)v可用性(usability)v有效性(efficiency)v可维护性(maintainability)v轻便性(portability)软件的质量是软件属性的各种标准度量的组合。？软件质量保证与测试3.5.3 3.5.3 基于模型的软件测试基于模型的软件测试v 基于模型的测试（Model-based testing，MBT）是利用模型来生成相应的测试用例，然后根据实际结果和原先预想的结果的差异来测试系统v 先从概念上形成模型，然后试图用数学的方法来描述这个模型，形成仿真模型，完成所需的测试软件质量保证与测试MBTMBT的优缺点的优缺点v 测试效率高v 对逻辑复杂故障测试效果好v 容易实现自动化测试优点优点缺点缺点n误报问题误报问题n漏报问题漏报问题n模型机理模型机理软件质量保证与测试软件测试模型软件测试模型v 故