幻灯片 1

Size: px

Start display at page:

Download "幻灯片 1"

炼羊太史
5 years ago
Views:

1 第三章软件测试的方法

2 主要内容 3.1 黑盒测试 3.2 白盒测试

3 3.1 黑盒测试黑盒测试方法的概念等价类划分法边界值分析法因果图法判定表法错误推测法

4 3.1.1 黑盒测试法的概念黑盒测试也称功能测试或数据驱动测试, 或基于规格说明的测试, 它是在已知产品所应具有的功能, 通过测试来检测每个功能是否都能正常使用在测试时, 把程序看作一个不能打开的黑盆子, 在完全不考虑程序内部结构和内部特性的情况下, 测试者在程序接口进行测试, 它只检查程序功能是否按照需求规格说明书的规定正常使用, 程序是否能适当地接收输入数锯而产生正确的输出信息, 并且保持外部信息 ( 如数据库或文件 ) 的完整性

5 黑盒测试的特点黑盒测试着眼于程序外部结构不考虑内部逻辑结构, 针对软件界面和软件功能进行测试黑盒测试是穷举输入测试, 只有把所有可能的输入都作为测试情况使用, 才能以这种方法查出程序中所有的错误实际上测试情况有无穷多个, 人们不仅要测试所有合法的输入, 而且还要对那些不合法但是可能的输入进行测试

6 黑盒测试有两种基本方法通过测试 : 实际上是确认软件能做什么, 而不会去考验其能力如何软件测试员只运用最简单, 最直观的测试案例在设计和执行测试用例时, 总是先要进行通过测试在进行破坏性试验之前, 看一看软件基本功能是否能够实现失败测试 : 在确信了软件正确运行之后, 就可以采取各种手段通过搞垮软件来找出缺陷纯粹为了破坏软件而设计和执行的测试案例, 被称为失败测试或迫使出错测试

7 黑盒测试主要发现几类错误功能不对或遗漏界面错误数据结构或外部数据库访问错误性能错误初始化和终止错误

8 等价类划分边界值分析因果图决策表法错误推测法具体的黑盒测试的设计方法在使用时, 要针对开发项目的特点加以适当的选择

9 3.1.2 等价类划分法由于穷举测试的数量太大, 以致于无法实际完成, 促使我们在大量的可能数据中选取其中的一部分作为测试用例把程序的输入域划分成若干部分, 然后从每个部分中选取少数代表性数据当作测试用例每一类的代表性数据在测试中的作用等价于这一类中的其他值, 也就是说, 如果某一类中的一个例子发现了错误, 这一等价类中的其他例子也能出现同样的错误使用这一方法设计测试用例, 首先必须在分析需求规格说明的基础上划分等价类, 列出等价类表在考虑等价类划分时, 先从程序的功能说明中找出每个输入条件, 然后为每个输入条件划分两个或更多个等价类

10 等价类可分两种情况有效等价类是指对程序的规格说明是有意义的合理的输人数据所构成的集合无效等价类是指对程序的规格说明是不合理的或无意义的输人数据所构成的集合

11 划分等价类的方法 1. 在输入条件规定了取值范围或值的个数的情况下, 则可以确立一个有效等价类和两个无效等价类. 例子 1: 例子 2: 1: 取值范围 : x 可以从 1 到 99 1 个有效等价类 : 0<x<100 x<1, x>99 2 个无效等价类 : x<1, x>99 2: 值的个数 : 1 张信用卡号可以有 2 个持有人 1 个有效等价类 : 0< 持有人 <3 2 个无效等价类 : 无持有人, 大于 2 个持有人

12 划分等价类的方法 ( 续 ) 2. 在输入条件规定了输入值的集合或者规定了必须如何的条件的情况下, 可确立一个有效等价类和一个无效等价类. 例子 : 输入必须是整数 1 个有效等价类 : 整数 1 个无效等价类 : 非整数

13 划分等价类的方法 ( 续 ) 3. 在输入条件是一个布尔值的情况下, 可确定一个有效等价类和一个无效等价类 : true, false 4. 在规定了输入数据的一组值 ( 假定 n 个 ),) 并且程序要对每一个输入值分别处理的情况下, 可确立 n 个有效等价类和一个无效等价类. 例子 : x 是枚举类型 : x=[1, 3,11, 19] 4 个有效等价类 : 4 个输入值 : 1, 3, 11, 19 1 个无效等价类 : 除开 4 个输入值的其它任意值, 如 5

14 划分等价类的方法 ( 续 ) 5. 在规定了输入数据必须遵守的规则的情况下, 可确立一个有效等价类 ( 符合规则 ) 和若干个无效等价类 ( 从不同角度违反规则 ).) 例子 : 用户名以字母开始, 不超过 20 个字符 1 个有效等价类 : 1 个正确的用户名若干个无效等价类 : 若干个不正确的用户名 6. 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下, 则应再将该等价类进一步的划分为更小的等价类.

15 划分等价类实例给出某一天 ( 年, 月, 日 ), 计算出它的下一天, 取值范围为 : 年 :1000<=: year <=3000 月 :1<=month: <=12 日 :1<=: day <=31 如 1999 年 3 月 4 日的下一天是 :1999: 年 3 月 5 日 1 为每一个等价类规定一个唯一的编号. 有效等价类编号无效等价类编号输入条件 1000<= 年 <=3000 1<= 月 <=12 1<= 日 <=31 1 年 < 年 > 月 <1 4 月 >12 5 日 <1 6 日 >31 7

16 划分出的等价类按以下三个原则设计测试用例 1 为每一个等价类规定一个唯一的编号. 2 设计一个新的测试用例, 使其尽可能多地覆盖尚未被覆盖地有效等价类, 重复这一步. 直到所有的有效等价类都被覆盖为止. 3 设计一个新的测试用例, 使其仅覆盖一个尚未被覆盖的无效等价类, 重复这一步. 直到所有的无效等价类都被覆盖为止.

17 覆盖等价类的测试用例测试用例编号年月日覆盖等价类的编号

18 3.1.3 边界值分析法边界值分析 (Boundary( Value Analysis,BVA BVA) ) 是一种补充等价划分的测试用例设计技术, 它不是选择等价类的任意元素, 而是选择等价类边界的测试用例大量的错误是发生在输入或输出范围的边界上, 而不是发生在输入输出范围的内部. 因此针对各种边界情况设计测试用例, 可以查出更多的错误.

19 边界值分析法设计测试用例在设计测试用例时, 对边界附近的处理必须给予足够的重视, 为检验边界附近的处理专门设计测试用例, 常常可以取得良好的测试效果 BVA 不仅重视输人条件边界, 而且也从输出域导出测试用例使用边界值分析方法设计测试用例, 首先应确定边界情况. 通常输入和输出等价类的边界, 就是应着重测试的边界情况. 应当选取正好等于, 刚刚大于或刚刚小于边界的值作为测试数据, 而不是选取等价类中的典型值或任意值作为测试数据.

20 基于边界值分析方法选择测试用例的原则 1) ) 如果输入条件规定了值的范围, 则应取刚达到这个范围的边界的值, 以及刚刚超越这个范围边界的值作为测试输入数据. 2) ) 如果输入条件规定了值的个数, 则用最大个数, 最小个数, 比最小个数少一, 比最大个数多一的数作为测试数据. 3) ) 根据规格说明的每个输出条件, 使用前面的原则 1. 4) ) 根据规格说明的每个输出条件, 应用前面的原则 2.

21 基于边界值分析方法选择测试用例的原则 ( 续 ) 5) ) 如果程序的规格说明给出的输入域或输出域是有序集合, 则应选取集合的第一个元素和最后一个元素作为测试用例. 6) ) 如果程序中使用了一个内部数据结构, 则应当选择这个内部数据结构的边界上的值作为测试用例. 7) ) 分析规格说明, 找出其它可能的边界条件.

22 选择测试用例 -- 实例年 :1000<=: year <=3000 年边界值为 : 999, 1000, ,2999, 3000, 月 :1<=month: <=12 月边界值为 :0,1,2:, 11, 12, 13 日 :1<=: day <=31 日边界值为 :0,1,2,: 30, 31, 32

23 测试用例列表测试用例输入年输入月输入日输出输入年超出范围输入年超出范围输入月超出范围输入月超出范围输入日超出范围输入日超出范围输出超界

24 3.1.4 因果图法等价划分方法和边界值分析方法, 都是着重考虑输入条件, 但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合, 可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类, 他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合. 例子的复杂性 : 1,3, 5,7,8,105 10,1212 月份为 31 天,4,6,9,11, 月份为 30 天, 二月闰年是 29 天, 一般是 28 天, 必须考虑多种条件的组合相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图 ( 逻辑模型 ).) 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

25 因果图因果图中用来表示 4 种因果关系的基本符号 : c 1 e 1 恒等 c 1 e 1 ~ 非 c 1 c 1 c 2 e 1 e 1 c 3 或 c 2 与

26 因果图 ( 续 ) 因果图中的 4 种基本关系 : 在因果图的基本符号中, 图中的左结点 ci 表示输入状态 ( 或称原因 ), 右结点 ei 表示输出状态 ( 或称结果 ) ci 与 ei 取值 0 或 1,0 表示某状态不出现,1, 则表示某状态出现恒等 : 若 c1 是 1,, 则 e1 也为 1, 否则 e1 为 0 非 : 若 c1 是 1,, 则 e1 为 0, 否则 e1 为 1 或 : 若 c1 或 c2 或 c3 是 1,, 则 e1 为 1, 否则 e1 为 0 与 : 若 c1 和 c2 都是 1,, 则 e1 为 1, 否则 e1 为 0

27 因果图中的约束因果图 ( 续 ) 在实际问题中输入状态相互之间输出状态相互之间可能存在某些依赖关系, 称为约束对于输入条件的约束有 E I O R 四种约束, 对于输出条件的约束只有 M 约束 E 约束 ( 异 ):a 和 b 中最多有一个可能为 1,, 即 a 和 b 不能同时 1 I 约束 ( 或 ):a b c 中至少有一个必须为 1,, 即 a b c 不能同时为 0 O 约束 ( 唯一 ):a 和 b 必须有一个且仅有一个为 1 R 约束 ( 要求 ):a 是 1 时,b, 必须是 1,, 即 a 为 1 时,b, 不能为 0 M 约束 ( 强制 ): 若结果 a 为 1,, 则结果 b 强制为 0

28 因果图 ( 续 ) 因果图中用来表示约束关系的约束符号 : E 异 a b I 或 a b c O 唯一 a b a a R M 要求 b 强制 b

29 利用因果图生成测试用例的基本步骤 (1) 分析软件规格说明描述中, 那些是原因 ( 即输入条件或输入条件的等价类 ), 那些是结果 ( 即输出条件 ), 并给每个原因和结果赋予一个标识符. (2) 分析软件规格说明描述中的语义. 找出原因与结果之间, 原因与原因之间对应的关系. 根据这些关系, 画出因果图. (3) 由于语法或环境限制, 有些原因与原因之间, 原因与结果之间的组合情况不可能出现. 为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件. (4) 把因果图转换为判定表. (5) 把判定表的每一列拿出来作为依据, 设计测试用例.

30 从因果图生成的测试用例 ( 局部, 组合关系下的 ) 包括了所有输入数据的取 TRUE 与取 FALSE 的情况, 构成的测试用例数目达到最少, 且测试用例数目随输入数据数目的增加而线性地增加. 原因 ( 输入 ) M1:month 有 30 天 M2:month 有 31 天,12 月除外 M3:12 月 M4:2 月 D1:1<=Day<=27 D2: day=28 D3: day=29 D4: day=30 D5: day=31 Y1: 闰年 Y2: 非闰年结果 ( 输出 ) R1: 天数加 1 R2: 月数加 1, 天复位到 1 R3: 年数加 1, 月复位到 1, 天复位到 1 R4: 不可能

31 3.1.5 判定表法判定表 (Decision( Table) ) 是分析和表达多逻辑条件下执行不同操作的情况下的工具. 在程序设计发展的初期, 判定表就已被当作编写程序的辅助工具了. 它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确.

32 判定表的四个组成部分条件桩 (Condition( Stub): 列出了问题的所有条件动作桩 (Action( Stub): 列出了问题规定可能采取的操作. 条件项 (Condition( Entry): 列出针对它左列条件的取值. 在所有可能情况下的真假值. 动作项 (Action( Entry): 列出在条件项的各种取值情况下应该采取的动作. 规则 : 任何一个条件组合的特定取值及其相应要执行的操作. 在判定表中贯穿条件项和动作项的一列就是一条规则. 显然, 判定表中列出多少组条件取值, 也就有多少条规则, 既条件项和动作项有多少列. 条件桩条件项动作桩动作项规则

33 判定表的建立步骤 1 确定规则的个数. 假如有 n 个条件, 每个条件有两个取值 (0,1( 0,1), 故有 n*n 种规则. 2 列出所有的条件桩和动作桩. 3 填入条件项. 4 填入动作项. 等到初始判定表. 5 简化, 合并相似规则 ( 相同动作 ).)

34 适合使用判定表设计测试用例的条件 1 规格说明以判定表形式给出, 或很容易转换成判定表. 2 条件的排列顺序不会也不影响执行哪些操作. 3 规则的排列顺序不会也不影响执行哪些操作. 4 每当某一规则的条件已经满足, 并确定要执行的操作后, 不必检验别的规则. 5 如果某一规则得到满足要执行多个操作, 这些操作的执行顺序无关紧要.

35 条件 1: 年条件 2: 月条件 3: 日动作 1: 天数加 1 动作 2: 月数加 1, 天复位到 1 动作 3: 年数加 1, 月复位到 1, 天复位到 1 不可能规则 1 M1 D1 是规则 2 M1 D2 是规则 3 M1 D3 是规则 4 M1 D4 是规则 5 M1 D5 是规则 6 M2 D1 是规则 7 M2 D2 是规则 8 M2 D3 是规则 9 M2 D4 是规则 10 M2 D5 是规则 11 M3 D1 是规则 12 M3 D2 是规则 13 M3 D3 是规则 14 M3 D4 是规则 15 M3 D5 是规则 16 M4 D1 是

36 简化后的决策表条件 1: 年条件 2: 月条件 3: 日动作 1: 天数加 1 动作 2: 月数加 1, 天复位到 1 动作 3: 年数加 1, 月复位到 1, 天复位到 1 不可能规则 1-3 M1 D1~ D3 是规则 4 M1 D4 是规则 5 M1 D5 是规则 6-9 M2 D1 ~D4 是规则 10 M2 D5 是规则 M3 D1 ~ D4 是规则 15 M3 D5 是规则 16 M4 D1 是规则 17 Y1 M4 D2 是规则 18 Y2 M4 D2 是规则 19 Y1 M4 D3 是规则 20 Y2 M4 D3 是

37 用决策表设计出的测试用例表 : 测试用例规则编号输入年输入月输入日期望输出 1 规则规则规则不可能 4 规则规则规则规则规则规则规则规则规则不可能 13 规则不可能

38 将用边界法设计出的测试用例与用决策表设计出的测试用例进行汇总 : 测试用例规则编号输入年输入月输入日期望输出 1 规则规则规则不可能 4 规则规则规则规则规则规则规则规则规则不可能 13 规则不可能 14 边界法输入年超出范围 15 边界法输入年超出范围

39 3.1.4 错误推测法错误推测法 : 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 错误推测方法的基本思想 : 列举出程序中所有可能有的错误和容易发生错误的特殊情况, 根据他们选择测试用例. 例如 : 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为 0 的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

40 综合策略 1 首先进行等价类划分, 包括输入条件和输出条件的等价划分, 将无限测试变成有限测试, 这是减少工作量和提高测试效率最有效的方法 2 在任何情况下都必须使用边界值分析方法经验表明, 用这种方法设计出的测试用例发现程序错误的能力最强 3 可以用错误推测法追加一些测试用例, 这需要依靠测试工程师的智慧和经验 4 对照程序逻辑, 检查已设计出的测试用例的逻辑覆盖程度如果没有达到要求的覆盖标准, 应当再补充足够的测试用例

41 综合策略 ( 续 ) 5 如果程序的功能说明中含有输入条件的组合情况, 则一开始就可选用因果图法和判定表驱动法 6 对于参数配置类的软件, 要用正交试验法选择较少的组合方式达到最佳效果 7 功能图法也是很好的测试用例设计方法, 我们可以通过不同时期条件的有效性设计不同的测试数据

42 3.2 白盒测试白盒测试的基本概念白盒测试的两种方法白盒测试用例设计方法覆盖测试路径测试最少测试用例数

43 3.2.1 白盒测试的基本概念白盒测试是一种被广泛使用的逻辑测试方法, 是由软件内部逻辑驱动的一种单元测试方法通过检查软件内部的逻辑结构, 对软件中的逻辑路径进行覆盖测试 ; 在程序不同地方设立检查点, 检查程序的状态, 以确定实际运行状态与预期状态是否一致只有对程序内部十分了解才能进行适度有效的白盒测试

44 白盒测试的优缺点优点 * 迫使测试人员去仔细思考软件的实现 * 可以检测代码中的每条分支和路径 * 揭示隐藏在代码中的错误 * 对代码的测试比较彻底缺点 * 无法检测代码中遗漏的路径和数据敏感性错误 * 不验证需求规格 (specification) 的正确性

45 静态方法白盒测试的两种方法动态方法

46 静态方法静态分析是一种不通过执行程序而进行测试的技术静态分析的关键功能是检查软件的表示和描述是否一致, 没有冲突或者没有歧义它瞄准的是纠正软件系统在描述表示和规格上的错误, 是任何进一步测试的前提在静态结构分析中, 测试者通过使用测试工具分析程序源代码的系统结构数据结构数据接口内部控制逻辑等内部结构, 生成函数调用关系图模块控制流图内部文件调用关系图子程序表宏和函数参数表等各类图形图表, 可以清晰地标识整个软件系统的组成结构, 使其便于阅读与理解, 然后可以通过分析这些图表, 检查软件有没有存在缺陷或错误

47 源程序的静态分析方法生成各种引用表 1 标号交叉引用表 2 变量交叉引用表 3 子程序 ( 宏函数 ) 引用表 4 等价表 5 常数表错误静态分析错误静态分析主要用于确定在源程序中是否有某类错误或危险结构 1 类型和单位分析 2 引用分析 3 表达式分析 4 接口分析

48 动态方法动态分析的主要特点是当软件系统在模拟的或真实的环境中执行之前之中和之后, 对软件系统行为的分析动态分析包含了程序在受控的环境下使用特定的期望结果进行正式的运行它显示了一个系统在检查状态下是正确还是不正确

49 3.2.3 白盒测试用例设计方法覆盖测试路径测试最少测试用例数

50 覆盖测试语句覆盖判定覆盖条件覆盖判定 / 条件覆盖组合覆盖路径覆盖判断覆盖语句覆盖组合覆盖判断 / 条件覆盖条件覆盖

51 例子 : 图中红色字母代表程序执行路径

52 语句覆盖主要特点 : 语句覆盖是最起码的结构覆盖要求, 语句覆盖要求设计足够多的测试用例, 使得程序中每条语句至少被执行一次用例设计 : ( 如果此时将 A 路径上的语句 1 T 去掉, 那么用例如下 ) 测试用例 X Y X+Y 路径 1 50(x<80) 50(y<80) 100(x+y <140) OBDE 2 90(x>=90) 70(y<80) 160(x+y >140) OBCE

53 语句覆盖 ( 续 ) 优点 : 可以很直观地从源代码得到测试用例, 无须细分每条判定表达式缺点 : 由于这种测试方法仅仅针对程序逻辑中显式存在的语句, 但对于隐藏的条件和可能到达的隐式逻辑分支, 是无法测试的在本例中去掉了语句 1 T 去掉, 那么就少了一条测试路径在 if 结构中若源代码没有给出 else 后面的执行分支, 那么语句覆盖测试就不会考虑这种情况但是我们不能排除这种以外的分支不会被执行, 而往往这种错误会经常出现

54 判定覆盖主要特点 : 判定覆盖又称为分支覆盖, 它要求设计足够多的测试用例, 使得程序中每个判定至少有一次为真值, 有一次为假值, 即 : 程序中的每个分支至少执行一次每个判断的取真取假至少执行一次用例设计 : 测试用例 X Y 条件 X>=80and Y>=80 条件 X+Y>=140 和 (X>=90 或 Y>=90) 路径 True True( 但执行不了 ) OAE False False OBDE False True OBCE

55 判定覆盖 ( 续 ) 优点 : 判定覆盖比语句覆盖要多几乎一倍的测试路径, 当然也就具有比语句覆盖更强的测试能力同样判定覆盖也具有和语句覆盖一样的简单性, 无须细分每个判定就可以得到测试用例缺点 : 往往大部分的判定语句是由多个逻辑条件组合而成 ( 如, 判定语句中包含 AND OR CASE), 若仅仅判断其整个最终结果, 而忽略每个条件的取值情况, 必然会遗漏部分测试路径

56 条件覆盖主要特点 : 条件覆盖要求设计足够多的测试用例, 使得判定中的每个条件获得各种可能的结果, 即每个条件至少有一次为真值, 有一次为假值用例设计 : 条件真值代号表 : 编号条件真值代号 True 假值代号 False 1 X>=80 t1 -t1 2 Y>=80 t2 -t2 3 X+Y>=140 t3 -t3 4 X>=90 t4 -t4 5 Y>=90 t5 -t5

57 条件覆盖 ( 续 ) 测试用例表 1: 测试用例 X Y 覆盖条件路径 t1, -t2, t3, t4, -t5 OBCE t1, t2, -t3, -t4,t5 OBDE 或者, 测试用例表 2: 测试用例 X Y 覆盖条件路径 t1, t2, t3, t4, t5 OAE t1,-t2, -t3, -t4,-t5 OBDE

58 条件覆盖 ( 续 ) 优点 : 条件覆盖比判定覆盖, 增加了对符合判定情况的测试, 即每个条件至少有一次为真值, 有一次为假值缺点 : 要达到条件覆盖, 需要足够多的测试用例, 但条件覆盖并不能保证判定覆盖条件覆盖只能保证每个条件至少有一次为真, 而不考虑所有的判定结果

59 判定 / 条件覆盖主要特点 : 设计足够多的测试用例, 使得判定中每个条件的所有可能结果至少出现一次, 每个判定本身所有可能结果也至少出现一次用例设计 : 测试用例 X Y 条件 X>=80and Y>=80 条件 X+Y>=140 和 (X>=90 或 Y>=90) 覆盖条件路径 True True( 但执行不了 ) t1, t2, t3, t4, t5 OAE False False -t1,-t2, -t3, -t4,-t5 OBDE False True t1,-t2, t3, t4,-t5 OBCE

60 判定 / 条件覆盖 ( 续 ) 优点 : 判定 / 条件覆盖满足判定覆盖准则和条件覆盖准则, 弥补了二者的不足缺点 : 判定 / 条件覆盖准则的缺点是未考虑条件的组合情况

61 组合覆盖主要特点 : 要求设计足够多的测试用例, 使得每个判定中条件结果的所有可能组合至少出现一次显然满足多条件覆盖的测试用例是一定满足判定覆盖条件覆盖和判定 / 条件覆盖的用例设计 : 编号组合条件代号 1 X>=80,Y>=80 T1, T2 2 X>=80,Y<80 T1, -T2 3 X<80, Y>=80 -T1, T2 4 X<80, Y<80 -T1, -T2 5 X+Y>=140, X>=90, Y>=90 T3, T4, T5 6 X+Y>=140, X>=90, Y<90 T3, T4, -T5 7 X+Y>=140, X<90, Y<90 T3, -T4, -T5 8 X+Y>=140, X<90, Y>=90 T3, -T4, T5 9 X+Y<140, X>=90, Y>=90 : 不可能 -T3, T4, T5 10 X+Y<140, X>=90, Y<90 -T3, T4, -T5 11 X+Y<140, X<90, Y<90 -T3, -T4, -T5 12 X+Y<140, X<90, Y>=90 -T3, -T4, T5

62 组合覆盖 ( 续 ) 组合判定测试用例表测试用例 X Y 组合号覆盖条件路径 ,5 T1,T2,T3,T4,T5 OAE ,6 T1,-T2, T3,T4,-T5 OBCE , 7 -T1,-T2, T3,-T4,-T5 OBDE , 11 -T1,-T2, -T3,-T4,-T5 OBDE , 8 -T1,T2, T3,-T4,T5 OBCE , 10 T1,-T2, -T3,T4,-T5 OBDE , 12 -T1,T2,-T3,-T4,T5 OBDE

63 组合覆盖 ( 续 ) 优点 : 多重条件覆盖准则满足判定覆盖条件覆盖和判定 / 条件覆盖准则更改的判定 / 条件覆盖要求设计足够多的测试用例, 使得判定中每个条件的所有可能结果至少出现一次, 每个判定本身的所有可能结果也至少出现一次并且每个条件都显示能单独影响判定结果缺点 : 线性地增加了测试用例的数量

64 路径覆盖主要特点 : 设计足够的测试用例, 覆盖程序中所有可能的路径用例设计 : 测试用例 X Y 路径 OAE OBDE OBCE OBCE

65 路径覆盖 ( 续 ) 优点 : 这种测试方法可以对程序进行彻底的测试, 比前面五种的覆盖面都广缺点 : 对于比较简单的小程序, 实现路径覆盖是可能做到的但如果程序中出现较多判断和较多循环, 可能的路径数目将会急剧增长, 要在测试中覆盖所有的路径是无法实现的为了解决这个难题, 只有把覆盖路径数量压缩到一定的限度内, 如程序中的循环体只执行一次在实际测试中, 即使对于路径数很有限的程序已经做到路径覆盖, 仍然不能保证被测试程序的正确性, 还需要采用其他测试方法进行补充

66 综合运用各种覆盖方法贯穿在程序内部的逻辑存在着不确定性和无穷性, 尤其对于大规模复杂软件因此我们不能穷举所有的逻辑路径, 即使穷举也未必会带来好运 ( 穷举不能查出程序逻辑规则错误, 不能查出数据相关错误, 不能查出程序遗漏的路径 ) 那么正确使用白盒测试, 就要先从代码分析入手, 根据不同的代码逻辑规则语句执行情况, 选用适合的覆盖方法任何一个高效的测试用例, 都是针对具体测试场景的逻辑测试不是片面的测试正确的结果或是测试错误的结果, 而是尽可能全面地覆盖每一个逻辑路径

67 白盒的测试用例需要做到保证一个模块中的所有独立路径至少被使用一次对所有逻辑值均需测试 true 和 false 在上下边界及可操作范围内运行所有循环检查内部数据结构以确保其有效性

68 路径测试路径表达式基本路径测试方法循环测试方法

69 路径表达式为了满足路径覆盖, 必须首先确定具体的路径以及路径的个数通常采用控制流图的边 ( 弧 ) 序列和节点序列表示某一条具体路径, 更为概括的表示方法为 : (1) 弧 a 和弧 b 相乘, 表示为 ab, 它表明路径是先经历弧 a, 接着再经历弧 b,, 弧 a 和弧 b 是先后相接的 (2)) 弧 a 和弧 b 相加, 表示为 a+b, 它表明两条弧是或的关系, 是并行的路段路径数的计算 : 在路径表达式中, 将所有弧均以数值 1 来代替, 再进行表达式的相乘和相加运算, 最后得到的数值即为该程序的路径数

70 基本路径测试方法路径测试就是从一个程序的入口开始, 执行所经历的各个语句的完整过程从广义的角度讲, 任何有关路径分析的测试都可以被称为路径测试完成路径测试的理想情况是做到路径覆盖, 但对于复杂性大的程序要做到所有路径覆盖 ( 测试所有可执行路径 ) 是不可能的在不能做到所有路径覆盖的前提下, 如果某一程序的每一个独立路径都被测试过, 那么可以认为程序中的每个语句都已经检验过了, 即达到了语句覆盖这种测试方法就是通常所说的基本路径测试方法

71 基本路径测试方法 ( 续 ) 基本路径测试方法是在控制流图的基础上, 通过分析控制结构的环形复杂度, 导出执行路径的基本集, 再从该基本集设计测试用例控制流图 ( 可简称流图 ) 是对程序流程图进行简化后得到的, 它可以更加突出的表示程序控制流的结构控制流图中包括两种图形符号 : 节点和控制流线 1) 节点由带标号的圆圈表示, 可代表一个或多个语句一个处理框序列和一个条件判定框 ( 假设不包含复合条件 ) 2) 控制流线由带箭头的弧或线表示, 可称为边它代表程序中的控制流

72 基本路径测试方法 ( 续 ) 常见结构的控制流图其中, 包含条件的节点被称为判定节点 ( 也叫谓词节点 ), 由判定节点发出的边必须终止于某一个节点, 由边和节点所限定的范围被称为区域顺序结构 IF 选择结构 WHILE 重复结构 UNTIL 重复结构 CASE 多分支结构

73 基本路径测试方法 ( 续 ) 环形复杂度环形复杂度也称为圈复杂度, 它以图论为基础, 为程序逻辑复杂度提供定量尺度的软件度量环形复杂度的应用可以将环形复杂度用于基本路径方法, 它可以提供 : 程序基本集的独立路径数量 ; 确保所有语句至少执行一次的测试数量的上界独立路径是指程序中至少引入了一个新的处理语句集合或一个新条件的程序通路采用流图的术语, 即独立路径必须至少包含一条在本次定义路径之前不曾用过的边测试可以被设计为基本路径集的执行过程, 但基本路径集通常并不唯一

74 基本路径测试方法 ( 续 ) 计算程序环路复杂性进行程序的基本路径测试时, 程序的环路复杂性给出了程序基本路径集合中的独立路径条数, 这是确保程序中每个可执行语句至少执行一次所必须的测试用例数目的上界基本路径集不是惟一的, 对于给定的控制流图, 可以得到不同的基本路径集通常环路复杂性可用以下 3 种方法求得 1 将环路复杂性定义为控制流图中的区域数 2 设 E 为控制流图的边数,N, 为图的结点数, 则定义环路的复杂性为 V(G)=E-N+2 3 若设 P 为控制流图中的判定结点数, 也可定义 V(G)=P+1

75 基本路径测试方法 ( 续 ) 基本路径测试方法包括以下 4 个步骤 : (1)) 画出程序的控制流图 (2)) 计算程序的环形复杂度, 导出程序基本路径集中的独立路径条数, 这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界 (3)) 导出基本路径集, 确定程序的独立路径 (4)) 根据 (3)( ) 中的独立路径, 设计测试用例的输入数据和预期输出

76 基本路径测试方法 ( 续 ) void sort ( int irecordnum, int itype ) 1 { 2 int x=0; 3 int y=0; 4 while ( irecordnum-- > 0 ) 5 { 6 If ( itype==0 ) 7 x=y+2; 8 else{ 9 If ( itype==1 ) 10 x=y+10; 11 else 12 x=y+20; 13 } 14 }

77 基本路径测试方法 ( 续 ) 画出控制流图 : 如右图所示计算环形复杂度 : 10( ( 条边 )-) 8( ( 个节点 )+) + 2 = 4 导出独立路径 ( 用语句编号表示 ) 路径 1: 路径 2: 路径 3: 路径 4:

78 基本路径测试方法 ( 续 ) 设计测试用例 : 测试用例 1 测试用例 2 测试用例 3 测试用例 4 输入数据 irecordnum = 0 itype = 0 irecordnum = 1 itype = 0 irecordnum = 1 itype = 1 irecordnum = 1 itype = 2 预期输出 x = 0 y = 0 x = 0 y = 0 x = 10 y = 0 x = 0 y = 20

79 循环测试方法从本质上说, 循环测试的目的就是检查循环结构的有效性通常, 循环可以划分为简单循环嵌套循环串接循环和非结构循环 4 类 (1)) 测试简单循环设其循环的最大次数为 n, 可采用以下测试集 : 跳过整个循环 ; 只循环一次 ; 只循环两次 ; 循环 m 次, 其中 m<n; 分别循环 n-1 n 和 n+1 次

80 循环测试方法 ( 续 ) (2)) 测试嵌套循环如果将简单循环的测试方法用于嵌套循环, 可能的测试次数会随嵌套层数成几何级数增加此时可采用以下办法减少测试次数 : * 测试从最内层循环开始, 所有外层循环次数设置为最小值 ; * 对最内层循环按照简单循环的测试方法进行 ; * 由内向外进行下一个循环的测试, 本层循环的所有外层循环仍取最小值, 而由本层循环嵌套的循环取某些典型值 ; * 重复上一步的过程, 直到测试完所有循环

81 循环测试方法 ( 续 ) (3)) 测试串接循环若串接的各个循环相互独立, 则可分别采用简单循环的测试方法 ; 否则采用嵌套循环的测试方法 (4)) 对于非结构循环这种情况, 无法进行测试, 需要按结构化程序设计的思想将程序结构化后, 再进行测试

82 Z 路径覆盖下的循环测试方法 Z 路径覆盖是路径覆盖的一种变体, 它是将程序中的循环结构简化为选择结构的一种路径覆盖循环简化的目的是限制循环的次数, 无论循环的形式和循环体实际执行的次数, 简化后的循环测试只考虑执行循环体一次和零次 ( 不执行 ) 两种情况, 即考虑执行时进入循环体一次和跳过循环体这两种情况在循环简化的思路下, 循环与判定分支的效果是一样的, 即 : 循环要么执行要么跳过

83 补充设计测试用例在实践中, 除了前面给出的各种方法外, 通常还可以采用以下三种方法来补充设计测试用例 : (1)) 通过非路经分析得到测试用例这种方法得到的测试用例是在应用系统本身的实践中提供的, 基本上是测试人员凭工作经验的得到, 甚至是猜测得到的 (2)) 寻找尚未测试过的路径并生成相应的测试用例这种方法需要穷举被测程序的所有路径, 并与前面已测试路径进行对比 (3)) 通过指定特定路径并生成相应的测试用例

84 最少测试用例数计算为实现测试的逻辑覆盖, 必须设计足够多的测试用例, 并使用这些测试用例执行被测程序, 实施测试我们关心的是 : 对于某个具体的程序来说, 至少需要设计多少个测试用例这里提供一种估算最少测试用例数的方法我们知道, 结构化程序是由 3 种基本控制结构组成 : 顺序型 ( 构成串行操作 ) 选择型 ( 构成分支操作 ) 和重复型 ( 构成循环操作 ) 为了把问题化简, 避免出现测试用例极多的组合爆炸, 把构成循环操作的重复型结构用选择结构代替这样, 任一循环便改造成进入循环体或不进入循环体的分支操作了

85 最少测试用例数计算 ( 续 ) 用 N-S 图表示程序的 3 种基本控制结构 : 图中 A B C D S 均表示要执行的操作,P, 是可取真假值的谓词,Y, 表真值,N, 表假值图中的 (c) 和 (d) 两种重复型结构代表了两种循环在做了简化循环的假设以后, 对于一般的程序控制流, 我们只考虑选择型结构事实上它已经能体现顺序型和重复型结构了

86 最少测试用例数计算 ( 续 ) 例如 : 下图表达了两个顺序执行的分支结构当两个分支谓词 P1 和 P2 取不同值时, 将分别执行 a 或 b 及 c 或 d 操作显然, 要测试这个小程序, 需要至少提供 4 个测试用例才能作到逻辑覆盖, 使得 ac ad bc 及 bd 操作均得到检验其实, 这里的 4 是图中的第 1 个分支谓词引出的两个操作, 及第 2 个分支谓词引出的两个操作组合起来而得到的, 即 2 2=42=4 并且, 这里的 2 是由于两个并列的操作, 即 1+1=2 而得到的

87 最少测试用例数计算 ( 续 ) 对于一般的更为复杂的问题, 估算最少测试用例个数的原则也是同样的 : 如果在 N-S 图中存在有并列的层次 A1 A2,A1 A1 和 A2 的最少测试用例个数分别为 a1 a2,, 则由 A1 A2 两层所组合的 N- S 图对应的最少测试用例数为 a1 a2 a2 如果在 N-S 图中不存在有并列的层次, 则对应的最少测试用例数由并列的操作数决定, 即 N-S 图中除谓词之外的操作框的个数

88 最少测试用例数计算 ( 续 ) 例 : 如下图所示的两个 N-S 图, 至少需要多少个测试用例完成逻辑覆盖? 对于第一个 N-S 图 : 由于图中并不存在并列的层次, 最少测试用例数由并列的操作数决定, 即为 1+1+1=3 对于第二个 N-S 图 : 由于图中没有包含并列的层次, 最少测试用例数仍由并列的操作数决定, 即为 =5

89 最少测试用例数计算 ( 续 ) 例 : 如下图所示的 N-S 图, 至少需要多少个测试用例完成逻辑覆盖? 分析该 N-S 图 : 图中的 2345 和 67 是并列的两层其中,2345, 层对应的最少测试用例数为 =5,67 层对应的测试用例数为 1+1+1=3,2345 和 67 这两层组合后对应的测试用例数为 5 3=15 最后, 由于两层组合后的部分是不满足谓词 1 时所要做的操作, 还要加上满足谓词 1 要做的操作, 因此整个程序所需测试用例数为 15+1=16

标题

软件测试的方法多种多样, 可以从不同角度加以分类 : 从是否需要执行被测软件的角度, 分为静态测试和动态测试 ; 从是针对系统的外部功能还是针对系统的内部结构的角度, 分为黑盒测试和白盒测试 ; 从软件测试的策略和过程的角度, 分为单元测试集成测试确认测试系统测试和验收测试等本章主要介绍静态测试和动态测试以及黑盒测试和白盒测试 3.1 软件测试技术的分类 3.1.1 从是否需要执行被测软件的角度分类