测试用例设计方法（二）

判定表驱动方法分析

一、方法简介

定义： 判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

判定表的优点： 能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。 在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。

阅读指南判定表

		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
建议	重读					√
	继续						√
	跳下一章							√	√
	休息	√	√	√	√

组成部分：
判定表通常由四个部分组成：

• 条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
• 动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
• 条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。
• 动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

规则及合并：

• 规则：任何一个条件组合的特定区之及其响应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列。
• 化简：就是规则合并有两条或多条规则具有相同的动作，并且其条件项之间存在着极为相似的关系。

规则及规则合并举例
1)如下图左端，两规则动作项一样，条件项类似，在1、2条件项分别取Y、N时，无论条件3取何值，都执行同一操作。即要执行的动作与条件3无关。于是可合并。“－”表示与取值无关。

2)与上类似，下图中，无关条件项“－”可包含其他条件项取值，具有相同动作的规则可合并。

3)化简后的读书指南判定表

		1	2	3	4
问题	你觉得疲倦吗？	-	-	Y	N
	你对内容感兴趣吗？	Y	Y	N	N
	书中内容使你胡涂吗？	Y	N	-	-
建议	请回到本章开头重读	x
	继续读下去		X
	跳到下一章去读				x
	停止阅读，请休息			x

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

判定表的优点和缺点

• 优点：它能把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏。
• 缺点：不能表达重复执行的动作，例如循环结构。

适合使用判定表设计测试用例的条件
①规格说明以判定表形式给出,或很容易转换成判定表。
②条件的排列顺序不会也不影响执行哪些操作。
③规则的排列顺序不会也不影响执行哪些操作。
④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则。
⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要。
这5个必要条件的目的是为了使操作的执行完全依赖于条件的组合。其实对于某些不满足这几条的判定表，同样可以借以设计测试用例，只不过尚需增加其它的测试用例罢了.

二、示例

1.问题要求：”……对功率大于50马力的机器、维修记录不全或已运行10年以上的机器，应给予优先的维修处理……” 。这里假定，“维修记录不全”和“优先维修处理”均已在别处有更严格的定义 。请建立判定表。
解答：
①确定规则的个数：这里有3个条件，每个条件有两个取值，故应有222=8种规则。
②列出所有的条件茬和动作桩：
③填入条件项。可从最后1行条件项开始，逐行向上填满。如第三行是： Y N Y N Y N Y N，第二行是： Y Y N N Y Y N N等等。
④填入动作桩和动作顶。这样便得到形如图的初始判定表。

⑤化简。合并相似规则后得到

正交实验设计方法

方法简介

利用因果图来设计测试用例时, 作为输入条件的原因与输出结果之间的因果关系,有时很难从软件需求规格说明中得到。往往因果关系非常庞大,以至于据此因果图而得到的测试用例数目多的惊人，给软件测试带来沉重的负担，为了有效地,合理地减少测试的工时与费用,可利用正交实验设计方法进行测试用例的设计。
正交实验设计方法:依据Galois理论,从大量的（实验）数据（测试例）中挑选适量的,有代表性的点（例）,从而合理地安排实验（测试）的一种科学实验设计方法.类似的方法有:聚类分析方法,因子方法方法等.

设计步骤

1、提取功能说明,构造因子–状态表
把影响实验指标的条件称为因子.而影响实验因子的条件叫因子的状态.利用正交实验设计方法来设计测试用例时,首先要根据被测试软件的规格说明书找出影响其功能实现的操作对象和外部因素,把他们当作因子,而把各个因子的取值当作状态.对软件需求规格说明中的功能要求进行划分,把整体的概要性的功能要求进行层层分解与展开,分解成具体的有相对独立性的基本的功能要求.这样就可以把被测试软件中所有的因子都确定下来,并为确定个因子的权值提供参考的依据.确定因子与状态是设计测试用例的关键.因此要求尽可能全面的正确的确定取值,以确保测试用例的设计作到完整与有效。
2、加权筛选,生成因素分析表
对因子与状态的选择可按其重要程度分别加权.可根据各个因子及状态的作用大小,出现频率的大小以及测试的需要,确定权值的大小。
3、利用正交表构造测试数据集

功能图分析方法

方法简介

一个程序的功能说明通常由动态说明和静态说明组成.动态说明描述了输入数据的次序或转移的次序.静态说明描述了输入条件与输出条件之间的对应关系.对于较复杂的程序,由于存在大量的组合情况,因此,仅用静态说明组成的规格说明对于测试来说往往是不够的.必须用动态说明来补充功能说明.功能图方法是用功能图FD形式化地表示程序的功能说明,并机械地生成功能图的测试用例. 功能图模型由状态迁移图和逻辑功能模型构成.状态迁移图用于表示输入数据序列以及相应的输出数据.在状态迁移图中,由输入数据和当前状态决定输出数据和后续状态.逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系.逻辑功能模型只适合于描述静态说明,输出数据仅由输入数据决定.测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成.功能图方法其实是是一种黑盒白盒混合用例设计方法。

使用

1.功能图
功能图由状态迁移图和布尔函数组成.状态迁移图用状态和迁移来描述.一个状态指出数据输入的位置（或时间）,而迁移则指明状态的改变.同时要依靠判定表或因果图表示的逻辑功能.例,一个简化的自动出纳机ATM的功能图。

2.测试用例生成方法
从功能图生成测试用例,得到的测试用例数是可接受的. 问题的关键的是如何从状态迁移图中选取测试用例.若用节点代替状态,用弧线代替迁移,则状态迁移图就可转化成一个程序的控制流程图形式.问题就转化为程序的路径测试问题（如白盒测试）问题了。

3.测试用例生成规则
为了把状态迁移（测试路径）的测试用例与逻辑模型（局部测试用例）的测试用例组合起来,从功能图生成实用的测试用例,须定义下面的规则.在一个结构化的状态迁移（SST）中,定义三种形式的循环:顺序,选择和重复.但分辨一个状态迁移中的所有循环是有困难的。

4.从功能图生成测试用例的过程
1)生成局部测试用例:在每个状态中,从因果图生成局部测试用例.局部测试用例由原因值（输入数据）组合与对应的结果值（输出数据或状态）构成。
2)测试路径生成:利用上面的规则（三种）生成从初始状态到最后状态的测试路径。
3)测试用例合成:合成测试路径与功能图中每个状态中的局部测试用例.结果是初始状态到最后状态的一个状态序列,以及每个状态中输入数据与对应输出数据的组合。

5.测试用例的合成算法:采用条件构造树。

场景设计方法

一、方法简介

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。

基本流和备选流：如下图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。

二、示例

1、描述
下图所示是ATM例子的流程示意图。

2、场景设计：如下表

场景1——成功提款	基本流
场景2——ATM内没有现金	基本流	备选流2
场景3——ATM内现金不足	基本流	备选流3
场景4——PIN有误（还有输入机会）	基本流	备选流4
场景5——PIN有误（不再有输入机会）	基本流	备选流4
场景6——账户不存在/账户类型有误	基本流	备选流5
场景7——账户余额不足	基本流	备选流6

注：为方便起见，备选流3和6（场景3和7）内的循环以及循环组合未纳入上表。

3、用例设计
对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。
TC（测试用例）ID号 场景/条件 PIN 账号 输入（或选择）的金额 账面
金额 ATM内的金额 预期结果
CW1 场景1：成功提款 V V V V V 成功提款
CW2 场景2：ATM内没有现金 V V V V I 提款选项不可用，用例结束
CW3 场景3：ATM内现金不足 V V V V I 警告消息，返回基本流步骤6，输入金额
CW4 场景4：PIN有误（还有不止一次输入机会） I V n/a V V 警告消息，返回基本流步骤 4，输入 PIN
CW5 场景4：PIN有误（还有一次输入机会） I
V n/a V V 警告消息，返回基本流步骤 4，输入 PIN
CW6 场景4：PIN有误（不再有输入机会） I V n/a V V 警告消息，卡予保留，用例结束

4.数据设计
一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。
测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据，如表所示。

TC（测试用例）ID号	场景/条件	PIN	账号	输入（或选择）的金额（元）	账面金额（元）	ATM内的金额（元）	预期结果
CW1	场景1：成功提款	4987	809-498	50.00	500.00	2 000	成功提款。账户余额被更新为450.00
CW2	场景2：ATM内没有现金	4987	809-498	100.00	500.00	0.00	提款选项不可用，用例结束
CW3	场景3：ATM内现金不足	4987	809-498	100.00	500.00	70.00	警告消息，返回基本流步骤6，输入金额
CW4	场景4：PIN有误（还有不止一次输入机会）	4978	809-498	n/a	500.00	2 000	警告消息，返回基本流步骤4，输入PIN
CW5	场景4：PIN有误（还有一次输入机会）	4978	809-498	n/a	500.00	2 000	警告消息，返回基本流步骤4，输入PIN
CW6	场景4：PIN有误（不再有输入机会）	4978	809-498	n/a	500.00	2 000	警告消息，卡予保留，用例结束

错误推测方法

1. 定义：基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。
2. 错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

例如, 输入数据和输出数据为0的情况；输入表格为空格或输入表格只有一行。 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

测试用例设计综合策略

综合策略

• 在任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强。
• 必要时用等价类划分方法补充一些测试用例。
• 用错误推测法再追加一些测试用例。
• 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。
• 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。

设计步骤

• 构造根据设计规格得出的基本功能测试用例；
• 边界值测试用例；
• 状态转换测试用例；
• 错误猜测测试用例；
• 异常测试用例；
• 性能测试用例；
• 压力测试用例。

优化方法

• 利用设计测试用例的8种方法不断的对测试用例进行分解与合并；
• 采用遗传算法理论进化测试用例；
• 在测试时利用发散思维构造测试用例。