part04 软件测试方法论

132
1 软件测试工程师培训 软件测试方法论

Upload: aellaw

Post on 07-Jul-2015

155 views

Category:

Technology


4 download

TRANSCRIPT

Page 1: Part04 软件测试方法论

1

软件测试工程师培训

软件测试方法论

Page 2: Part04 软件测试方法论

2

主要内容 1 软件测试方法概述 2 软件测试规范 3 软件测试用例设计-黑盒测试 4 软件测试用例设计-白盒测试 5 小结

Page 3: Part04 软件测试方法论

3

1 软件测试方法概述 1.1 软件测试活动及信息流 1.2 测试方法 1.3 生成测试用例的信息来源 1.4 小结

Page 4: Part04 软件测试方法论

4

1.1 软件测试活动及信息流 测试是从大量的测试用例中选择有限的测试用例发现

软件中的大部分缺陷的一种技术 好的测试用例的 4 个特性:1. 检测软件质量的有效性,是否能发现缺陷,或至少可

能发现缺陷;2. 可仿效的测试用例可以测试很多内容,因而减少测试

用例的数量;3. 经济性,测试用例的执行、分析和调试是否经济4. 测试用例的可修改性,每次软件修改后对测试用例的

维护成本

Page 5: Part04 软件测试方法论

5

测试活动

标识 标志测试条件(确定测试什么)和测试的优先级

设计 设计测试用例(确定怎么测试)

开发 开发测试(设计脚本、数据等)

执行 执行测试用例

将测试结果与

比较 期望进行比较

Page 6: Part04 软件测试方法论

6

测试活动 1 测试条件取决于被测试验证的项目或

事件。如等价划分、边界值分析、因果图等。测试条件是被测环境的描述,可以用多种方式描述:如简单的语言,表格项形式或类似于流图的图表形式;标识测试条件的活动最好与开发活动(即 V 模型左边的活动)并行开展

Page 7: Part04 软件测试方法论

7

测试活动 2 设计测试用例

确定“怎样测试”。测试用例( test case )是按一定顺序执行的与测试目标( test object, 测试理由或目的)相关的一系列测试。测试用例设计将产生许多测试所包括的输入值、期望结果及其他任何运行测试的有关信息,如环境要求。期望输出包括应输出或建立的内容,应修改或更新或应删除的内容。期望输出集可以是一个很大的集合。

Page 8: Part04 软件测试方法论

8

测试活动 一个测

试用例

测试用例:POS1036

先决条件:

作为数据输入员注册到定单系统显示的主菜单

数据库系统必须含有标准数据集合

确保系统中没有其他活跃的新定单活动

步骤 输入 期望输出 测试条件

1 建立用任何一个标准的订单 项建立 一个 新订单,设置订单数为 100

显示订单确认信息 VB10

VB20

2 确认订单 打印具有正确细目购置订单

VB10

3 打印新订单报表 打印的新订单报表就是新创建的订单

VB10

VB23

4 取消订单 打印正确的取消购置订单信息

VB8

5 打印新订单报表 无打印订单输出 VB8

Page 9: Part04 软件测试方法论

9

测试活动 3 开发测试用例

包括准备测试脚本、测试输入、测试数据以及期望输出。测试脚本( test script )是 具有正规语法的数据和指令的集合,在测试执行自动工具使用中,通常以文件形式保存;必须先完成测试用例的先决条件( precondition),然后再执行测试。测试用例可能要求专门的硬件或软件,如网络环境或打印机等;期望输出可以组成成文件形式用于自动工具。对于手动测试,期望输出仅仅只是简单地记录在手工测试过程或脚本中。设置用于自动比较的期望输出比设置用于手工测试的期望输出复杂得多。在自动工具中要求每项内容都要拼写正确,而在手工测试中要求没这么严格。 测试开发的任何工作可以提前进行(相对 V 模型左边的活动进行),以后可以节省时间。

Page 10: Part04 软件测试方法论

10

测试活动 4 执行测试用例

对于手动测试来讲,测试者按事先准备好的手工过程进行测试,测试者输入数据、观察输出、记录发现的问题。 对于自动测试,可能只需要启动测试工具,并告诉工具执行哪些测试用例; 测试执行只能在软件开发完成后进行,即 V 模型右边的活动。

Page 11: Part04 软件测试方法论

11

测试活动 5 将测试结果与期望输出进行比较

应该对每次测试的实际输出进行分析研究,判断软件功能是否正确。该验证可以是非正的测试者主观判断,也可以是将实际输出与期望输出进行严格准确的比较。

一些信息比较,如可以在执行测试时进行显示屏幕上的信息,另一些输出比较,如修改数据库记录,只能在测试执行结束后进行。自动测试一般结合了这两种方法。

Page 12: Part04 软件测试方法论

12

测试阶段的信息流

被测模块 设 软 系统 客

计 件 其他 户

信 需 元素 参

息 求 与

被测模块

被测模块

单元测试

单元测试

单元测试

集成测试

确认测试

系统测试

验收测试

已 经 测试 过 的模块

已 集成 的软件

已 确认 的软件

可 交付 的软件

Page 13: Part04 软件测试方法论

13

测试阶段的信息流测试阶段的输入信息有两类: 软件配置:这是测试的对象,包括需求说明书、设计说明书和被测的源程序等。

测试配置:包括测试计划、测试步骤、测试用例(测试数据),以及具体实施测试的测试程序、测试工具等

Page 14: Part04 软件测试方法论

14

1.2 测试方法 静态方法 动态方法 黑盒测试 白盒测试

Page 15: Part04 软件测试方法论

15

静态方法和动态方法 静态方法的主要特征是在用计算机测试源程序时,计算机并不真正运行被测试的程序,只对被测程序进行特性分析。因此,静态方法常称为“分析”,静态分析是对被测程序进行特性分析的一些方法的总称。

动态方法的主要特征是计算机必须真正运行被测试的程序,通过输入测试用例,对其运行情况 (输入 /输出的对应关系 )进行分析。

Page 16: Part04 软件测试方法论

16

黑盒测试 黑盒测试( Black—box Testing)又称功

能测试、数据驱动测试或基于规格说明的测试,是一种从用户观点出发的测试。用这种方法进行测试时,被测程序被当作一个黑盒,在不考虑程序内部结构和内部特性,测试者只知道该程序输入和输出之间的关系或程序的功能的情况下,依靠能够反映这一关系和程序功能的需求规格说明书考虑确定测试用例和推断测试结果的正确性。软件的黑盒测试被用来证实软件功能的正确性和可操作性。

Page 17: Part04 软件测试方法论

17

白盒测试 白盒测试(White—box Testing)又

称结构测试、逻辑驱动测试或基于程序的测试。它依赖于对程序细节的严密检验,针对特定条件和 /与循环集设计测试用例,对软件的逻辑路经进行测试。在程序的不同点检验“程序的状态”以判定其实际情况是否和预期的状态相一致。软件的白盒测试用来分析程序的内部结构。

Page 18: Part04 软件测试方法论

18

白盒测试 白盒测试要求对某些程序的结构特性做到一定程度的覆盖,或者说是“基于覆盖的测试” 。最为常见的程序结构覆盖有 :

语句覆盖:它要求被测程序的每一可执行语句在测试中尽可能都检验过,这是最弱的逻辑覆盖准则;

分支覆盖或判定覆盖:要求程序中所有判定的分支尽可能得到检验;

条件覆盖:当判定式中含有多个条件时,要求每个条件的取值均得到检验;

判定/条件覆盖:同时考虑条件的组合值及判定结果的检验;

路径覆盖:只考虑对程序路径的全面检验。取得测试覆盖的方法——程序插装

Page 19: Part04 软件测试方法论

19

白盒测试 既然黑盒测试是测试软件与需求的一致

性,为什么还要白盒测试? 编程是容易发生逻辑错误和作出不正确的假

设 如对执行路径假设不正确,会产生设计错误

,白盒测试能发现这样的错误 录入错误是随机的

Page 20: Part04 软件测试方法论

20

黑盒测试与白盒测试的比较 黑 盒 测 试 白 盒 测 试

测 试 规 划根据用户的规格说明,即针对命令、信息、报表等用户界面及体现它们的输入数据与输出数据之间的对应关系,特别是针对功能进行测试。

根据程序的内部结构,比如语句的控制结构,模块间的控制结构以及内部数据结构等进行测试。

特点

优 点 能站在用户立场上进行测试。 能够对程序内部的特定部位进行覆盖测试。

缺 点 •不能测试程序内部特定部位。• 如果规格说明有误,则无法发现。

• 无法检验程序的外部特性。• 无法对未实现规格说明的程序内

部欠缺部分进行测试。

方 法 举 例基于图的测试等价类划分边值分析比较测试

语句覆盖判定覆盖条件覆盖

判定 / 条件覆盖基本路径覆盖循环覆盖

模块接口测试

Page 21: Part04 软件测试方法论

21

测试阶段与测试方法测试阶段 目的 执行者 测试方法单元测试 查找独立模块中逻辑错误、

数据错误和算法错误软件工程师 白盒测试

集成测试 查找模块之间接口错误 软件工程师测试人员

白盒测试、自顶向下或自底向上

确认测试 确认软件是否满足软件需求 测试人员 黑盒测试模拟用户操作

系统测试 对系统中各个组成部分进行综合性检验

测试人员 黑盒测试模拟用户操作

回归测试 确认软件变更后是否仍满足软件需求

测试人员 黑盒测试模拟用户操作

α测试与 β测试

用户 黑盒测试模拟用户操作

验收测试 确认软件是否满足用户需求 用户、项目组测试人员

黑盒测试模拟用户操作

Page 22: Part04 软件测试方法论

22

1.3 测试信息来源 基于软件规约生成测试用例 基于软件设计生成测试用例 基于程序生存测试用例

Page 23: Part04 软件测试方法论

23

1.4 小结 软件测试主要工作就是确定合适的测试

用例; 测试过程贯穿在整个软件开发活动中; 测试方法: 动态、静态、黑盒、白盒等

Page 24: Part04 软件测试方法论

24

2 软件测试用例设计-黑盒测试 2.0 概述 2.1 等价类划分 2.2 因果图 2.3 边值分析 2.4 判定表驱动测试 2.5 正交实验设计法 2.6 自动测试用例生成方法 2.7 小结

Page 25: Part04 软件测试方法论

25

2.0 概述

这种方法是把测试对象测试对象看做一个黑一个黑盒子盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明。

黑盒测试又叫做功能测试功能测试或数据驱数据驱动测试动测试。

Page 26: Part04 软件测试方法论

26

黑盒测试方法是在程序接口上进行测试,主要是为了发现以下错误 : 是否有不正确或遗漏了的功能是否有不正确或遗漏了的功能 ? 在接口上,输入能否正确地接受输入能否正确地接受 ?

能否输出正确的结果能否输出正确的结果 ? 是否有数据结构错误或外部信息是否有数据结构错误或外部信息(例如数据文件 ) 访问错误访问错误 ?

性能上是否能够满足要求性能上是否能够满足要求 ? 是否有初始化或终止性错误是否有初始化或终止性错误 ? 

黑盒测试目标

Page 27: Part04 软件测试方法论

27

用黑盒测试发现程序中的错误,必须在所有可能的输入条件所有可能的输入条件和输出条件和输出条件中确定测试数据,来检查程序是否都能产生正确的输出。

但这是不可能不可能的。

Page 28: Part04 软件测试方法论

28

假设一个程序 P 有输入量 X 和 Y 及输出量Z 。在字长为 32位的计算机上运行。若X 、Y 取整数,按黑盒方法进行穷举测试:

可能采用的 测试数据组: 2 32×2 32

= 2 64 如果测试一 组数据需要 1毫秒,一年工作 365× 24 小时

,完成所有测试需 5亿年。

Page 29: Part04 软件测试方法论

29

2.1 测试用例设计方法-等价类划分 选取测试用例 等价类划分的办法是把程序的输入域划

分成若干部分,然后从每个部分中选取少数代表性数据当作测试用例。

在分析需求规格说明的基础上划分等价类,列出等价类表。

Page 30: Part04 软件测试方法论

30

2.1.1 等价类 所谓等价类是指某个输入域的集合。它

表示,如果用集合中的一个输入条件作为测试数据进行测试不能发现程序中的错误,那么使用集合中的其它输入条件进行测试也不可能发现错误。也就是说,对揭露程序中的错误来说,集合中的每个输入条件是等效的。

Page 31: Part04 软件测试方法论

31

有效等价类和无效等价类 在考虑等价类时,应该注意区别两种不同的情况:

*有效等价类:有效等价类指的是对程序的规格说明是有意义的、合理的输入数据所构成的集合。在具体问题中,有效等价类可以有一个,也可以是多个。

*无效等价类:无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题,无效等价类至少应有一个,也可能有多个。

Page 32: Part04 软件测试方法论

32

等价类 输入条件 有效等价类 无效等价类 输入条件:…项数可以从 1 到 999… 有效等价类为“ 1〈项数〈 999” 无效等价类为“项数 <1” 及“项数 >999”

Page 33: Part04 软件测试方法论

33

2.1.2 经典例子

“ 输入三个整数作为三边的边长构成三角形。当此三角形为一般三角形、等腰三角形及等边三角形时,分别做计算…”

注意输入和输出条件

有效等价类型

号码

无效等价类 号码

12 13 14 15 16 17

整数

1

a 为非整数

一边为非整数 b 为非整数 c 为非整数 a,b 为非整数

两边为非整数 b,c 为非整数 a,c 为非整数

三边 a,b,c均为非整数 18

19 20 21 22 23 24

三个数

2

只给 a

只给一边 只给 b

只给 c

只给 ab

只给两边 只给 b,c

只给 ac

给出三个以上 25

26 27 28 29 30 31

非零数

3

a 为 0

一边为零 b 为 0 c 为 0 a,b 为 0

二边为零 b,c 为 0 a,c 为 0

三边 a,b,c均为 0 32

33 34 35 36 37 38

正数

4

a<0

一边<0 b<0 c<0 a<0且 b<0

二边<0 a<0且 c<0 b<0且 c<0

三边均<0:a<0且 b<0且 c<0 39

40 41 42 43 44

构成一般

三角形

a+b>c

b+c>a

a+c>b

5

6

7

a+b<0 a+b=0 b+c<a b+c=a a+c<b a+c=b

45

构成等腰

三角形

a=b b=c 且两边

之和 a=c 大于第三边

8 9 10

构成等腰

三角形 a=b=c 11

表 4.1 例 1 的等价类型表

Page 34: Part04 软件测试方法论

34

有效等价类 覆盖有效等价类的测试用例: a b c 覆盖等价类号码 3 4 5 ( 1 ) --( 7) 4 4 5 ( 1 ) --( 7),( 8) 4 5 5 ( 1 ) --( 7),( 9)

5 4 5 ( 1 ) -- ( 7 ),

( 10) 4 4 4 ( 1 ) -- ( 7 ),

( 11 )

Page 35: Part04 软件测试方法论

35

无效等价类

Page 36: Part04 软件测试方法论

36

2. 1.3 问题讨论 问题:给出下面的有效和无效等价类 输入条件:“…统计全国各省、市、自治区的人口…”

输入条件:“标识符应以字母开头…” 输入条件:长度为 1-20的字符串 输入条件:数据库中的值域 , CHAR(20), NOT NULL

Page 37: Part04 软件测试方法论

37

2. 2 测试方法-因果图 采用因果图方法( Cause 一 Effect Graphics )能够帮助我们按一定步骤,高效率地选择测试用例,同时还能为我们指出,程序规格说明描述中存在着什么问题。

Page 38: Part04 软件测试方法论

38

2. 2.1 因果图介绍 4 种符号分别表示了规格说明中向 4 种因果关系

因果图中使用了简单的逻辑符号,以直线联接左右结点。左结点表示输入状态(或称原因),右结点表示输出状态(或称结果)。

Ci 表示原因,通常置于图的左部; ei 表示结果,通常在图的右部。 ci 和 ei均可取值 0或 1 , 0表示某状态不出现, 1 表示某状态出现。

(a)恒等 ( b)非

V A

(c)或 (d)与

图 4.1 因果图的基本符号

C1 e1

C1

e1

C1

e1

C2

C2

C3

C1 e1

Page 39: Part04 软件测试方法论

39

关系 ①恒等:若 ci 是 1 ,则 ei也是 1 ;否则

ei 为 0。 ②非:若 ci 是 1 ,则 ei 是 0;否则 ei

是 1 。 ③或:若 c1 或 c2 或 c3 是 1 ,则 ei 是

1 ;否则 ei 为 0。“或”可有任意个输入。 ④与:若 c1 和 c2都是 1 ,则 ei 为 1 ;

否则 ei 为 0。“与”也可有任意个输入。

Page 40: Part04 软件测试方法论

40

约束 输入状态相互之间还可能存在某些依赖关系

某些输入条件本身不可能同时出现。输出状态之间也往往存在约束

Page 41: Part04 软件测试方法论

41

输入条件约束类型 对于输入条件的约束有以下 4 类: ① E约束(异): a 和 b 中至多有一个可能为

1 ,即 a 和 b不能同时为 1 。 ② I约束(或): a 、 b 和 c 中至少有一个必

须是 1 ,即 a 、 b 和 c不能同时为 0。 ③ O约束(唯一); a 和 b 必须有一个,且仅

有 1 个为 1 。 ④R约束(要求): a 是 1时, b 必须是 1 ,

即不可能 a 是 1时 b 是 0。

Page 42: Part04 软件测试方法论

42

输出条件约束类型 输出条件的约束只有: M约束(强制):若结果 a 是 1 ,则结

果 b强制为 0。

Page 43: Part04 软件测试方法论

43

2. 2.2 步骤 ①分析程序规格说明的描述中,哪些是原

因,哪些是结果。原因常常是输入条件或是输入条件的等价类。而结果是输出条件。

②分析程序规格说明的描述中语义的内容,并将其表示成连接各个原因与各个结果的“因果图”。

Page 44: Part04 软件测试方法论

44

步骤 ③由于语法或环境的限制,有些原因和

结果的组合情况是不可能出现的。为表明这些特定的情况,在因果图上使用若干个特殊的符号标明约束条件。

④把因果图转换成判定表。 ⑤把判定表中每一列表示的情况写成测试用例

Page 45: Part04 软件测试方法论

45

2. 2.3 例子 软件规格说明书 “第一列字符必须是 A或 B,第二列字符必须是一个数字,在此情况下进行文件的修改。但如果第一列字符不正确,则给出信息 L,如果第二列字符不是数字,则给出信息M。”

Page 46: Part04 软件测试方法论

46

原因和结果 原因: 1——第一列字符是 A; 2——第一列字符是 B; 3——第二列字符是一数字。 结果: 21——修改文件; 22 ——给出信息 L; 23——给出信息M。

Page 47: Part04 软件测试方法论

47

因果图和具有约束的因果图

11 为中间节点; 考虑到原因 1 和原因 2不可能同时为 1 ,因此在因果图上施加E约束。

Page 48: Part04 软件测试方法论

48

判定表 根据因果图建立如下的判定表

表中 8种情况的左面两列情况中,原因①和原因②同时为 1 ,这是不可能出现的,故应排除这两种情况。表的最下一栏给出了 6种情况的测试用例,这是我们所需要的数据。

1 2 3 4 5 6 7 8 1 1 1 1 1 0 0 0 0 2 1 1 0 0 1 1 0 0 3 1 0 1 0 1 0 1 0

条件

11 / / / / / / / / / / / / 1 1 1 1 0 0

原 因

22 / / / / 0 0 0 0 1 1 21 / / / / 1 0 1 0 0 0

动作

23 / / / / 0 1 0 1 0 1

结 果

测试 用例

/ / / / / / / /

/ / / / / / / /

A3 A8

AM A?

B5 B4

BN B!

C2 X6

DY P;

Page 49: Part04 软件测试方法论

49

2. 2.4 讨论 在较为复杂的问题中,这个方法常常是十分有效的,它能有力地帮助我们确定测试用例

如果哪个开发项目在设计阶段就采用了判定表,也就不必再画因果图,而是可以直接利用判定表设计测试用例了。

Page 50: Part04 软件测试方法论

50

2. 3 测试用例设计方法-边值分析 在软件设计和程序编写中,常常对于规

格说明中的输入域边界或输出域边界不够注意,以致形成一些差错。实践证明,在设计测试用例时,对边界附近的处理必须给予足够的重视,为检验边界附近的处理专门设计测试用例,常常取得良好的测试效果。

Page 51: Part04 软件测试方法论

51

2. 2.1 边值分析遵循的原则 ①如果输入条件规定了取值范围,或是规定了值的个数,应以该范围的边界内及刚刚超出范围的边界外的值,或是分别对最大、最小个数及稍小于最小、稍大于最大个数作为测试用例。例如,如果程序的规格说明中规定:“重量在 10公斤至 50公斤范围内的邮件,其邮费计算公式为……”。作为测试用例,我们应取 10 及 50 ,还应 取 10.01,49.99,9.99 及50.01 等。如果另一问题规格说明规定:“某输入文件可包含 1 至 255 个记录,……”,则测试用例可取 1 和 255 ,还应取 0及 256等。

Page 52: Part04 软件测试方法论

52

遵循以下几条原则 ②针对规格说明的每个输出条件使用前面的第( 1 )条原则。例如,某程序的规格说明要求计算出“每月保险金扣除额为 0至 1165. 25元”,其测试用例可取0. 00及 1165. 2 、还可取一 0. 01及 1165. 26等。如果另一程序属于情报检索系统,要求每次”最多显示 1 条情报摘要”,这时我们应考虑的测试用例包括 1 和 4 ,还应包括 0和 5 等。

Page 53: Part04 软件测试方法论

53

遵循以下几条原则 ③如果程序规格说明中提到的输入或输

出域是个有序的集合(如顺序文件、表格等),就应注意选取有序集的第一个和最后一个元素作为测试用例。

④分析规格说明,找出其它的可能边界条件。

Page 54: Part04 软件测试方法论

54

2. 2.2 例子 某一为学生考试试卷评分和成绩统计的程序,其规格说明指出了对程序的要求: 程序的输入文件由 80个字符的一些记录组成,这些记录分为三组: ① 标题 这一组只有一个记录,其内容为输出报告的名字。 ②试卷各题标准答案记录 每个记录均在第 80个字符处标以数字“ 2” 。该组的第一个记录的第 1 至第 3 个字符为题目编号(取值为 1 一 999)。第 10至第 59个字符给出第 1 至第 50 题的答案(每个合法字符表示一个答案)。该组的第 2 ,第 3……个记录相应为第51 至第 100,第 101 至第 150,…题的答案。

③每个学生的答卷描述 该组中每个记录的第80个字符均为数字“ 3” 。每个学生的答卷在若干个记录中给出。如甲的首记录第 1 至第 9字符给出学生姓名及学号,第 10至第 59字符列出的是甲所做的第 1 至第 50 题的答案。若试题数超过 50,则第 2 ,第 3……纪录分别给出他的第 51 至第 100,第 101 至第 150……题的解答。然后是学生乙的答卷记录。 若学生最多为 200 人,输入数据的形式如图 4 。 15 所示。

Page 55: Part04 软件测试方法论

55

学生考卷评分和成绩统计程序输入数据的形式

Page 56: Part04 软件测试方法论

56

该程序应给出 4 个输出报告,即:

①按学生学号排序,每个学生的成绩(答对的百分比)和等级报告。

②按学生得分排序,每个学生的成绩。

③平均分数,最高与最低分之差。 ④按题号排序,每题学生答对的百分

比。

Page 57: Part04 软件测试方法论

57

输入条件 测试用例

输入文件 空输入文件

标题 无标题记录

只有 1 个字符的标题

具有 80 个字符的标题

出题个数 除了 1 个题

除了 50 个题

除了 51 个题

除了 100 个题

除了 999 个题

没有出题

题目是非数值量

答案记录 标题记录后没有标准答案记录

标准答案记录多 1 个

标准答案记录少 1 个

学生人数 学生人数为 0

学生人数为 1

学生人数为 200

学生人数为 201

学生答题 某学生只有 1 个答卷记录,但有两个标准答案记录

该学生是文件中的第 1 个学生

该学生是文件中的最后 1 个学生

学生答题 某学生有 2 个答卷记录,但只有 1 个标准答案记录

该学生是文件中的第 1 个学生

该学生是文件中的最后 1 个学生

输出条件 测试用例

学生得分 所有学生得分相同

所有学生得分不同

一些学生(不是全部)得分相同(用以计算等级) 1 个学生得 0 分 1 个学生得 100 分

输出报告 (1),(2)

1 个学生编号最小(检查排序) 1 个学生编号最大

学生数恰好使报告印满一页(检查打印)

学生数使报告 1页打印不够,恰好多 1人

输出报告(3) 平均值取最大值(所有学生都得满分)

平均值为 0(所有学生都得 0 分)

标准偏差取最大值(1学生得 0 分,1学生得 100 分)

标准偏差相同(所有学生得分相同)

输出报告(4) 所有学生都答对第 1题

所有学生都答错第 1题

所有学生都答对最后 1题

所有学生都答错最后 1题

题数恰好使报告打印在 1页上

报告打印完 1页后,恰剩 1题未打

Page 58: Part04 软件测试方法论

58

2. 4 判定表驱动测试 在一些数据处理问题中,某些操作是否实施依赖于多个逻辑条件的取值。也即在这些逻辑条件取值的组合所构成的多种情况下,分别执行不同的操作。处理这类问题的一个非常有力的分析和表达工具是判定表( Decision Table )。

Page 59: Part04 软件测试方法论

59

2. 3.1 例子 1 一张关于科技书阅读指南的判定驱动

表: 3 个问题 8种情况 1 2 3 4 5 6 7 8

你觉得疲倦吗? Y Y Y Y N N N N

你对内容感兴趣吗? Y Y N N Y Y N N 问

书中内容使你胡涂吗? Y N Y N Y N Y N

请回到本章开头重读 x x

继续读下去 x x

跳到下一章去读 x x

停止阅读,请休息 x x

”读书指南”判定表

Page 60: Part04 软件测试方法论

60

判定表组成 条件桩( Condition Stub ) 动作桩( Action Stub ) 条件项( Condition Entity) 动作项( Action Entity)

Page 61: Part04 软件测试方法论

61

规则及规则合并 任何一个条件组合的特定取值及其相应要执

行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然,判定表中列出多少组条件取值,也就有多少条规则,即条件项和动作项有多少列。

化简 就是规则合并有两条或多条规则

具有相同的动作, 并且其条件项之间 存在着极为相似的关系

两条规则合并成一条 两条规则的进一步合并

Page 62: Part04 软件测试方法论

62

一个规则合并的例子 一个规则合并的例子 1 2 3 4

你觉得疲倦吗? - - Y N

你对内容感兴趣吗? Y Y N N 问

书中内容使你胡涂吗? Y N - -

请回到本章开头重读 x

继续读下去 X

跳到下一章去读 x

停止阅读,请休息 x

化减后的”读书指南”判定表

Page 63: Part04 软件测试方法论

63

2. 3.2 例子 2 问题要求:”……对功率大于 50马力的机器、维修记录不全或已运行 10 年以上的机器,应给予优先的维修处理……”

假定,“维修记录不全”和“优先维修处理”均已在别处有更严格的定义

按 5 步建立判定表

Page 64: Part04 软件测试方法论

64

建立判定表的步骤 ①确定规则的个数。这里有 3 个条件,每个条

件有两个取值,故应有 2*2*2=8种规则。 ②列出所有的条件茬和动作茬。 ③填人条件项。为防止遗漏可从最后 1 行条件

项开始,逐行向上填满乙如第三行是: Y N Y N Y N Y N第二行是: Y Y N N Y Y N N等等。

Page 65: Part04 软件测试方法论

65

建立判定表的步骤 ④填人动作桩和动作顶。这样便得到

形如图的初始判定表。 1 2 3 4 5 6 7 8

功率大于 50马力吗? Y Y Y Y N N N N

维修记录不全吗? Y Y N N Y Y N N 条

运行超过 10年吗? Y N Y N Y N Y N

进行优先处理 x x X X X 动

作 作其他处理 X x x

初始判定表

Page 66: Part04 软件测试方法论

66

建立判定表的步骤 ⑤化简。合并相似规则后得到图。

1 2 3 4 5

功率大于 50马力吗? Y Y Y N N

维修记录不全吗? Y N N - - 条

运行超过 10年吗? - Y N Y N

进行优先处理 x x X 动

作 作其他处理 x x

化减后的判定表

Page 67: Part04 软件测试方法论

67

2. 3.3 判定表在功能测试中的应用 一软件规格说明 (1) 当条件 1 和条件 2满足,并且条件 3

和条件 4不满足,或者当条件 1 、 3 和条件 4满足时,要执行操作 1 。

(2) 在任一个条件都不满足时,要执行操作 2 。

(3) 在条件 1不满足,而条件 4 被满足时,要执行操作 3 。

Page 68: Part04 软件测试方法论

68

规则 只给出了 16种规则中的 4 种

根据规格说明得到的判定表 默许的规则

规则 1 规则 1 规则 1 规则 1

条件 1 Y Y N N

条件 2 Y - N -

条件 3 N Y N -

条件 4 N Y N Y

操作 1 x x

操作 2 x

操作 3 x

根据规则说明得到的判定表

规则 5 规则 6 规则 7 规则 8

条件 1 - N Y Y

条件 2 - Y Y N

条件 3 Y N N N

条件 4 N N Y -

默许操作 x x x x

默许的规则

Page 69: Part04 软件测试方法论

69

2.3.4 判定表的优点和缺点 优点:它能把复杂的问题按各种可能的情况一一列举出来,简明而易于理解,也可避免遗漏。

缺点:不能表达重复执行的动作,例如循环结构。 其他??

Page 70: Part04 软件测试方法论

70

使用判定表设计测试用例的Beizer 条件 ①规格说明以判定表形式给出,或是很容易转换成判定表。

②条件的排列顺序不会也不应影响执行哪些操作。 ③规则的排列顺序不会也不应影响执行哪些操作。 ④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则。

⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要。

B。 Beizer提出这 5 个必要条件的目的是为了使操作的执行完全依赖于条件的组合。其实对于某些不满足这几条的判定表,同样可以借以设计测试用例,只不过尚需增加其它的测试用例罢了。

Page 71: Part04 软件测试方法论

71

2.5 正交实验设计法 把软件功能测试作为实验的一种,从大量的实

验点中选出适量有代表性的点,应用依据伽罗瓦理论导出的“正交表”,合理安排实验的一种科学的实验设计方法。

从规约中找出影响其功能实现的操作对象和外部因素作为因子,因子的取值作为状态,构造因素分析表,利用正交表进行各因子的专题组合,构造有效的测试数据集,并由此建立因果图。

Page 72: Part04 软件测试方法论

72

2.6 自动测试用例设计 一些测试工具可以进行部分测试用例自动化,

“测试输入生成工具”,该方法也可以用于某些场合,但自动工具不可能完全替代智力的测试活动;

自动方式可以生成大量的测试用例,但他不区分哪些测试是最重要的。这些要求有创造力的智力活动只能由测试人员完成。

所有测试生成工具依赖于生成测试的算法,工具比使用相同算法的测试人员的测试更彻底、更精确,但人工测试时可以考虑附加测试。

Page 73: Part04 软件测试方法论

73

三种测试输入生成工具 基于代码测试输入生成 基于界面测试生成 基于规格说明测试生成

Page 74: Part04 软件测试方法论

74

基于代码测试输入生成 通过检测软件代码结构生成测试输入。通过代码的路径由判断点确定的段组成。自动生成每个路径段逻辑覆盖条件的轮廓文件。与覆盖工具一起使用较好。

只产生测试输入,还需要对测试输出进行比较,不能判断软件产生的输出是否正确,只是说明代码应该做什么。也不能发现丢失的代码

另一种方法:可以生成满足较小变化测试准则的测试。变化测试(Mutation test )是指代码或输入做较小的改变,检测系统是否可以正确地处理或测试稍微改变的版本。该方法可以检查系统的容错能力和测试套件的充分性。

规格说明 期望输出

测试输入 代码 测试输出

Page 75: Part04 软件测试方法论

75

基于界面测试生成 用于某些定义好的界面如 GUI或Web

应用生成测试。如果屏幕含有各种菜单、按钮及检查框,则工具生成访问每个控件的测试事例。

还可以测试 Internet 和 Intranet页面。工具可激活WWW页面的每个链接,然后对每页做相同的测试;该方法对于发现某类缺陷是有效的,可以部分生成期望输出,即连接存在或断开状况,但不能判断连接是否在正确的位置;

该方法可以执行部分测试事例设计活动,产生测试输出,对于检测“ roll-call” 即某个东西确实在某处确实有用。手工测试非常枯燥,应该采用自动测试。

规格说明 期望输出

测试输入 代码 测试输出

Page 76: Part04 软件测试方法论

76

基于规格说明测试生成 在规格说明形式化并可被工具分析的前提下,基于规格说明测试工具可以生成测试输入及期望结果;如果面向对象规格说明足够严格的话,这种工具还可以进行面向对象规格说明的测试。

例如,如果一个输入域的允许范围被严格定义,那么工具可以产生边界值以及有效等价类和无效等价类的样值。

某些基于规格说明的工具可以进行结构化的英文规格说明或因果图的测试,可以发现一些规格说明的缺陷,如规格说明含混或冗长

好处是检查软件应该做什么,而不是软件做了什么。

从规格说明中推导测试用例越枯燥,则这类工具的潜力就越大。

规格说明 期望输出

测试输入 代码 测试输出

Page 77: Part04 软件测试方法论

77

自动测试用例生成的优点 自动化测试用例生成用于设计的繁琐部

分,如激活每个菜单项或者从已知的数据范围计算边界值;

可以生成针对源程序的一套完成的测试用例(代码、界面和规格说明)

可以发现某种类型的缺陷,如丢失连接,非工作窗口项或者不符合规格说明的软件;

Page 78: Part04 软件测试方法论

78

自动测试用例生成的限制 基于代码方法不能生成期望输出 基于界面方法只能产生部分期望输出 基于代码和基于界面方法不能发现规格说明的

缺陷; 基于规格说明的方法依赖于规格说明的质量; 所有的方法可以产生大量的测试,而实际操作起来比较困难;

测试前仍需要专家判断产生的测试的必要性,并考虑任何工具都无法产生的测试;

Page 79: Part04 软件测试方法论

79

2.7小结 理解和熟练使用 4 种进行测试用例设计

的方法:等价类划分、因果图、边值分析、判定表驱动;

自动测试用例设计的原理和方法,

Page 80: Part04 软件测试方法论

80

4 、 软件测试用例设计-白盒测试 3.0 概述 3.1 程序结构分析 3.2 逻辑覆盖 3.3 路径分析 3.4 域测试 3.5 程序插装 3.6 程序变异 3.7 小结

Page 81: Part04 软件测试方法论

81

3.0 3.0 概述概述

此方法把测试对象看做一个透明的把测试对象看做一个透明的盒子盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试。

通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。

Page 82: Part04 软件测试方法论

82

软件人员使用白盒测试方法,主要想对程序模块进行如下的检查: 对程序模块的所有独立的执行路径所有独立的执行路径至少测

试一次; 对所有的逻辑判定所有的逻辑判定,取“取“真真”与取“”与取“假假”的两种”的两种情况都至少测试一次情况都至少测试一次;

在循环的边界和运行界限内执行循环体; 测试内部数据结构的有效性内部数据结构的有效性,等。

Page 83: Part04 软件测试方法论

83

对一个具有多重选择和循环嵌套多重选择和循环嵌套的程序,不同的路径数目可能是天文不同的路径数目可能是天文数字数字。给出一个小程序的流程图,它包括了一个执行 20 次的循环。

包含的不同执行路径数达 5 20 条,对每一条路径进行测试需要 1毫秒,假定一年工作 365 × 24 小时,要想把所有路径测试完,需 3170年。

Page 84: Part04 软件测试方法论

84

Page 85: Part04 软件测试方法论

85

3.13.1 程序结构分析-基本路径测程序结构分析-基本路径测试试

基本路径测试方法把覆盖的路径数压缩到一定限度内,程序中的循环体最多只程序中的循环体最多只执行一次执行一次。

它是在程序控制流图的基础上,分析控分析控制构造的环路复杂性制构造的环路复杂性,导出基本可执行导出基本可执行路径集合路径集合,设计测试用例的设计测试用例的方法。设计出的测试用例要保证在测试中,程序的每一个可执行语句至少要执行一次。

Page 86: Part04 软件测试方法论

86

3.1.1. 3.1.1. 程序的控制流图程序的控制流图

符号○为控制流图的一个结点,表示一个或多个无分支的 PDL 语句或源程序语句。箭头为边,表示控制流的方向。

Page 87: Part04 软件测试方法论

87

在选择或多分支结构中,分支的汇聚处应有一个汇聚结点。

边和结点圈定的区域叫做区域,当对区域计数时,图形外的区域也应记为一个区域。

如果判断中的条件表达式是由一个或多个逻辑运算符 (OR , AND , NAND , NOR) 连接的复合条件表达式,则需要改为一系列只有单条件的嵌套的判断只有单条件的嵌套的判断。

Page 88: Part04 软件测试方法论

88

Page 89: Part04 软件测试方法论

89

Page 90: Part04 软件测试方法论

90

3.1.2. 3.1.2. 程序环路复杂性程序环路复杂性

程序的环路复杂性给出了程序基本程序基本路径集中的独立路径条数路径集中的独立路径条数,这是确保程序中每个可执行语句至少执行一次所必需的测试用例数目的上界。

从控制流图来看,一条独立路径是至少包含有一条在其它独立路径中从未有过的边的路径。

Page 91: Part04 软件测试方法论

91

例如,在图示的控制流图中,一组独立的路径是path1 : 1 - 11path2 : 1 - 2 - 3 - 4 - 5 - 10 - 1 - 11path3 : 1 - 2 - 3 - 6 - 8 - 9 - 10 - 1 - 11path4 : 1 - 2 - 3 - 6 - 7 - 9 - 10 - 1 - 11

路径 path1 , path2 , path3 , path4组成了控制流图的一个基本路径集。

Page 92: Part04 软件测试方法论

92

3.1.2. 3.1.2. 导出测试用例导出测试用例

导出测试用例,确保基本路径确保基本路径集中的每一条路径的执行集中的每一条路径的执行。

根据判断结点给出的条件,选择适当的数据以保证某一条路径可以被测试到 — 用逻辑覆盖用逻辑覆盖方法方法。

Page 93: Part04 软件测试方法论

93

每个测试用例执行之后测试用例执行之后,与预期结果进与预期结果进行比较行比较。如果所有测试用例都执行完毕,则可以确信程序中所有的可执行语句至少被执行了一次。

必须注意,一些独立的路径 (如例中的路径 1),往往不是完全孤立的,有时它是程序正常的控制流的一部分,这时,这些路径的测试可以是另一条路径测试的一部分。

Page 94: Part04 软件测试方法论

94

3.2 3.2 逻辑覆盖逻辑覆盖

语句覆盖语句覆盖 判定覆盖判定覆盖

条件覆盖条件覆盖

判定-条件覆盖判定-条件覆盖 条件组合覆盖条件组合覆盖 路径覆盖路径覆盖。

逻辑覆盖是以程序内部的逻辑结构为程序内部的逻辑结构为基础基础的设计测试用例的技术。它属白盒测试。

Page 95: Part04 软件测试方法论

95

Page 96: Part04 软件测试方法论

96

L1(a c e)→ →

( ) ( ){ } ( ) ( ){ }= > = = >A B A X A1 0 2 1and and or

( ) ( ) ( )( ) ( ) ( )

= > = =

> = >

A B A

A B X A

1 0 2

1 0 1

and and or

and and

( ) ( )( ) ( ) ( )

= = =

> = >

A B

A B X A

2 0

1 0 1

and or

and and

Page 97: Part04 软件测试方法论

97

L2 (a b d)→ →

( ) ( ){ } ( ) ( ){ }= A B A X> = = >1 0 2 1and and or

( ) ( ){ } ( ) ( ){ }= > = = >A B A X1 0 2 1or and and

( ) ( ) ( )( ) ( ) ( )

= A A X

B A X

> = >

= = >

1 2 1

0 2 1

and and or

and and

( ) ( )( ) ( ) ( )

= ≤ ≤

≠ ≠ ≤

A X

B A X

1 1

0 2 1

and or

and and

Page 98: Part04 软件测试方法论

98

L3 (a b c)→ →

( ) ( ){ } ( ) ( ){ }= > = = >A B A X1 0 2 1and and or

( ) ( ){ } ( ) ( ){ }= > = = >A B A X1 0 2 1or and or

( ) ( )( ) ( ) ( ) ( )

= > >

= = = >

A 1 and X 1 or

B 0 and A 2 or B 0 and X 1

( ) ( )( ) ( ) ( ) ( )

= ≤ >

≠ = ≠ >

A X

B A B X

1 1

0 2 0 1

and or

and or and

Page 99: Part04 软件测试方法论

99

L4 (a c d)→ →

( ) ( ){ } ( ) ( ){ }= > = = >A B A X A1 0 2 1and and or

( ) ( ) ( ) ( )= > = ≠ ≤A B A X A1 0 2 1and and and

Page 100: Part04 软件测试方法论

100

3.2.13.2.1 语句覆盖语句覆盖 

语句覆盖就是设计若干个测试用例,运行被测程序,使得每一可执行每一可执行语句至少执行一次语句至少执行一次。

在图例中,正好所有的可执行语句都在路径路径 L1L1上,所以选择路径 路径 L1L1设计测试用例,就可以覆盖所有的可执行语句。

Page 101: Part04 软件测试方法论

101

测试用例的设计格式如下【输入的 (A, B, X) ,输出的 (A, B, X) 】

为图例设计满足语句覆盖语句覆盖的测试用例是 :【 (2, 0 , 4) , (2, 0 , 3) 】 

覆盖 ace【 L1】

( ) ( )( ) ( ) ( )

A B

A B X A

= =

> = >

2 0

1 0 1

and or

and and

Page 102: Part04 软件测试方法论

102

3.2.23.2.2 判定覆盖判定覆盖

判定覆盖就是设计若干个测试用例,运行被测程序,使得程序中程序中每个判断的取真分支和取假分支每个判断的取真分支和取假分支至少经历一次至少经历一次。

判定覆盖又称为分支覆盖分支覆盖。 对于图例,如果选择路径路径 L1L1 和L2L2 ,就可得满足要求的测试用例:

Page 103: Part04 软件测试方法论

103

【 (2, 0 , 4) , (2, 0 , 3) 】覆盖 ace【 L1】【 (1, 1, 1) , (1, 1, 1) 】覆盖 abd【 L2】

( ) ( )( ) ( ) ( )

A X

B A X

≤ ≤

≠ ≠ ≤

1 1

0 2 1

and or

and and

( ) ( )( ) ( ) ( )

A B

A B X A

= =

> = >

2 0

1 0 1

and or

and and

Page 104: Part04 软件测试方法论

104

如果选择路径 L3 和 L4 ,还可得另一组可用的测试用例 :【 (2, 1, 1) , (2, 1, 2) 】覆盖 abe【 L3】【 (3, 0, 3) , (3, 1, 1) 】覆盖 acd【 L4】

( ) ( ) ( )( ) ( ) ( )

A X B

A B X

≤ > ≠

= ≠ >

1 1 0

2 0 1

and or and

or and

( ) ( ) ( )( )

A B A

X A

> = ≠

1 0 2

1

and and and

Page 105: Part04 软件测试方法论

105

3.2.33.2.3 条件覆盖条件覆盖

条件覆盖就是设计若干个测试用例,运行被测程序,使得程序中每个判断每个判断的每个条件的可能取值至少执行一次的每个条件的可能取值至少执行一次。

在图例中,我们事先可对所有条件的取值加以标记。例如,

对于第一个判断: 条件 A> 1 取真为 ,取假为

条件 B= 0 取真为 ,取假为

T1 T1

T2 T2

Page 106: Part04 软件测试方法论

106

对于第二个判断: 条件 A= 2 取真为 ,取假为

条件 X> 1 取真为 ,取假为

测试用例 覆盖分支 条件取值【 (2, 0 , 4) , (2, 0, 3) 】 L1(c, e) 【 (1, 0 , 1) , (1, 0, 1) 】 L2(b, d) 【 (2, 1, 1) , (2, 1, 2) 】 L3(b, e)

T3 T3T4

T4

T T T T1 2 3 4

T T T T1 2 3 4

T T T T1 2 3 4

Page 107: Part04 软件测试方法论

107

或 测 试 用 例覆盖分支 条件取值【 (1, 0 , 3) , (1, 0, 4) 】 L3(b, e) 【 (2, 1, 1) , (2, 1, 2) 】 L3(b, e)

T T T T1 2 3 4

T T T T1 2 3 4

Page 108: Part04 软件测试方法论

108

3.2.43.2.4判定-条件覆盖判定-条件覆盖判定-条件覆盖就是设计足够的测

试用例,使得判断中每个条件的所判断中每个条件的所有可能取值至少执行一次有可能取值至少执行一次,同时每每个判断中的每个条件的可能取值至个判断中的每个条件的可能取值至少执行一次少执行一次。

Page 109: Part04 软件测试方法论

109

测 试 用 例 覆盖分支 条件取值【 (2, 0 , 4) , (2, 0 , 3) 】 L1(c, e)【 (1, 1, 1) , (1, 1, 1) 】 L2(b, d)

T T T T1 2 3 4

T T T T1 2 3 4

( ) ( )( ) ( ) ( )

A B

A B X A

= =

> = >

2 0

1 0 1

and or

and and

( ) ( )( ) ( ) ( )

A X

B A X

≤ ≤

≠ ≠ ≤

1 1

0 2 1

and or

and and

Page 110: Part04 软件测试方法论

110

Page 111: Part04 软件测试方法论

111

3.2.53.2.5 条件组合覆盖条件组合覆盖

条件组合覆盖就是设计足够的测试用例,运行被测程序,使得每个判断的每个判断的所有可能的条件取值组合至少执行一所有可能的条件取值组合至少执行一次次。

记 ① A> 1, B= 0 作 ② A> 1, B≠0 作

③ A≯1, B= 0 作 ④ A≯1, B≠0 作

T T1 2

T T1 2

T T1 2

T T1 2

Page 112: Part04 软件测试方法论

112

⑤ A= 2, X> 1 作 ⑥ A= 2, X≯1 作 ⑦ A≠2, X> 1 作 ⑧ A≠2, X≯1 作

T T3 4

T T3 4

T T3 4

T T3 4

Page 113: Part04 软件测试方法论

113

测 试 用 例 覆盖条件 覆盖组合【 (2, 0, 4), (2, 0 , 3) 】 (L1)

① , ⑤

【 (2, 1, 1), (2, 1, 2) 】 (L3) ② , ⑥

【 (1, 0, 3), (1, 0 , 4) 】 (L3) ③ , ⑦

【 (1, 1, 1), (1, 1, 1) 】 (L2) ④ , ⑧

T T T T1 2 3 4

T T T T1 2 3 4

T T T T1 2 3 4

T T T T1 2 3 4

Page 114: Part04 软件测试方法论

114

3.3 3.3 路径测试路径测试

路径测试就是设计足够的测试用例,覆覆盖程序中所有可能的路径盖程序中所有可能的路径。

测 试 用 例 通过路径 覆盖条件【 (2, 0 , 4) , (2, 0 , 3) 】 ace (L1)

【 (1, 1, 1) , (1, 1, 1) 】 abd (L2) 【 (1, 1, 2) , (1, 1, 3) 】 abe (L3)

【 (3, 0 , 3) , (3, 0 , 1) 】 acd (L4)

T T T T1 2 3 4

T T T T1 2 3 4

T T T T1 2 3 4

T T T T3 41 2

Page 115: Part04 软件测试方法论

115

3.2.13.2.1 条件测试路径选择条件测试路径选择

当程序中判定多于一个时,形成的分支结构可以分为两类:嵌套型分支结构嵌套型分支结构和连锁型分支结构连锁型分支结构。

对于嵌套型分支结构嵌套型分支结构,若有 n 个判定语句,需要 n+1 个测试用例;

对于连锁型分支结构连锁型分支结构, 若有 n 个判定语句,需要有 2 n 个测试用例,覆盖它的 2 n

条路径。当 n较大时将无法测试。

Page 116: Part04 软件测试方法论

116

Page 117: Part04 软件测试方法论

117

3.2.23.2.2 循环 测 试路径选循环 测 试路径选择择

循环分为 4 种不同类型: 简单循环简单循环连锁循环连锁循环嵌套循环嵌套循环非结构循环非结构循环。

Page 118: Part04 软件测试方法论

118

Page 119: Part04 软件测试方法论

119

(1) (1) 简单循环简单循环 ① 零次循环:从循环入口到出口

② 一次循环:检查循环初始值 ③ 二次循环:检查多次循环 ④ m次循环: 检查在多次循环 ⑤ 最大次数循环、比最大次数多一次、少一次的循环。

Page 120: Part04 软件测试方法论

120

(2)(2) 嵌套循环嵌套循环① 对最内层循环做简单循环的全部测试。

所有其它层的循环变量置为最小值;② 逐步外推,对其外面一层循环进行测试。

测试时保持所有外层循环的循环变量取最小值,所有其它嵌套内层循环的循环变量取“典型”值。③ 反复进行,直到所有各层循环测试完毕

。④ 对全部各层循环同时取最小循环次数,

或者同时取最大循环次数

Page 121: Part04 软件测试方法论

121

如果各个循环互相独立,则可以用与简单循环相同的方法进行测试。但如果几个循环不是互相独立的,则需要使用测试嵌套循环的办法来处理。

( 3 )连锁循环

Page 122: Part04 软件测试方法论

122

(4) (4) 非结构循环非结构循环这一类循环应该使用结构化程序

设计方法重新设计测试用例。

Page 123: Part04 软件测试方法论

123

3.4 域测试 基于程序结构的测试方法 针对域错误,对输入空间进行分析,选

择适当的测试点,检验输入空间中的每个输入是否产生正确的结果。

假设限制过多,难以运用到实际中。

Page 124: Part04 软件测试方法论

124

3.5 符号测试 另辟途径解决测试用例选择问题。 基于代数运算执行测试,是测试和验证

的折衷方法

Page 125: Part04 软件测试方法论

125

3.6 程序插装 借助往被测程序中插入操作来实现测试

目的的方法。

Page 126: Part04 软件测试方法论

126

3.7 程序变异 是一种错误驱动测试,针对某类特定程

序错误实现测试。 程序强变异 程序弱变异

Page 127: Part04 软件测试方法论

127

3.8 小结 白盒测试方法分类 基本路径测试 逻辑覆盖测试 路径测试

Page 128: Part04 软件测试方法论

128

专题小结 软件测试用例设计-黑盒测试

测试的关键就是确定正确的测试用例。本部分详细介绍几种软件测试用例设计方法:等价类划分、因果图、边值分析、判定表驱动测试和测试用例自动生成原理和方法。

Page 129: Part04 软件测试方法论

129

专题小结 软件测试用例设计-白盒测试 程序结构分析 逻辑覆盖测试 路径

Page 130: Part04 软件测试方法论

130

专题小结 学习要求:1. 理解软件开发过程中每一阶段的软件测试方

法,理解他们的作用和意义。能够根据问题选择正确的软件测试方法

2. 熟练掌握软件测试用例的设计方法,将设计得到的测试用例编到软件测试用例表中,根据软件测试用例表进行软件测试、填写软件测试记录。

3. 结合实际的测试用例设计过程,理解自动测试用例的原理和方法。

Page 131: Part04 软件测试方法论

131

专题小结 训练:1. 测试用例的设计2. 编制软件测试用例表,进行软件测试

Page 132: Part04 软件测试方法论

132

谢谢 !