测试用例设计

测试用例设计

判定表法设计测试用例 — 判定表相关概念

判定表

是分析和表达多逻辑条件下执行不同操作的工具。
判定表是由条件桩、动作桩、条件项、动作项四部分内容构成的表格。

条件桩（Condition Stub）

列出了问题的所有条件。通常认为列出条件的次序无关紧要。

动作桩（Action Stub）

列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

条件项（Condition Entry）

列出针对所列条件的取值。在所有可能情况下的真假值。

动作项（Action Entry）

列出在条件项的各种取值情况下应该采取的动作。

判定表中的规则

任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。

判定表的化简

合并判定表中两条或多条具有相同动作，并且其条件项之间存在着极为相似关系的规则这一过程。

判定表法设计测试用例 — 使用判定表设计测试用例

判定表使用场景

如果程序中多个条件决定多个动作，并且每个条件的取值只有两种，且条件和动作之间的逻辑关系明确。

判定表的优点

能够将复杂的问题按照各种可能的情况全部列举出来，简明并且可以避免遗漏。

判定表的建立步骤

• 列出所有的条件和动作
• 确定规则的个数（假如有n个条件，每个条件有两个取值（0,1），就可以产生2的n次方种规则）
• 填写判定表
• 化简判定表

例1：问题要求：“……对功率大于50马力的机器、维修记录不全或已运行10年以上的机器，应优先维修处理……” 。这里假定，“维修记录不全”和“优先维修处理”均已在别处有更严格的定义 。

1）列出所有的条件和动作

• 条件：功率大于50马力?/维修记录不全?/已运行10年以上？
• 动作：优先维修处理/其它处理方式

2）确定规则的个数

• 这里有3个条件，每个条件有两个取值，故应有8种规则。

3）填写判定表

4）化简判定表

• 首先，找出判定表中相似的规则。

5）合并相似规则，就得到了化简后的判定表。

因果图法设计测试用例 — 因果图相关概念

因果图

是分析输入条件之间的联系及相互组合、输入与输出之间关系的分析方法。这里的输入就是原因，输出就是结果，所以这种分析方法称为因果图。

因果图的关系

恒等：Ci=1,Ei=1;Ci=0,Ei=0.

非：Ci=1,Ei=0;Ci=0,Ei=1.

或：C1、C2、C3有一个是1，Ei为1； C1、C2、C3全是0，Ei为0。

与：C1、C2、C3有一个是0，Ei为0； C1、C2、C3全是1，Ei为1。

约束

输入或输出状态相互之间还可能存在某些依赖关系，称为约束。

因果图的约束

A、输入条件的约束有以下四类

• 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。

B、输出条件约束：M约束（强制）：若结果a是1，则结果b强制为0

因果图法设计测试用例 — 使用因果图设计测试用例

因果图使用场景

适合于检查程序输入条件的各种组合情况，分析输入与输出之间的关系。

因果图的优点

以图形化的方式将输入与输出之间的关系、输入条件、输出条件之间的相互约束标示出来，方便生成判定表，并能避免遗漏。

因果图法设计测试用例的步骤

• 分析软件规格说明描述, 找出原因（即输入条件或输入条件的等价类）和结果（即输出条件）, 并给每个原因和结果赋予一个标识符
• 分析软件规格说明描述中的语义，找出原因与结果之间、原因与原因之间对应的关系，根据这些关系，画出因果图
• 由于语法或环境限制, 有些原因与原因之间、原因与结果之间的组合情况不可能出现，为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件
• 把因果图转换为判定表，并化简判定表
• 以最终的判定表的每一列为依据设计测试用例

例2： 用户登录系统时需要输入用户名、用户密码、验证码，且验证码在1分钟内有效。如果用户输入的用户名、用户密码和验证码都正确则可以登录到系统；如果用户名、用户密码和验证码有一个未输入则给出对应的提示信息，如果多于一项未输入，那么提示输入次序在前的输入项；如果用户名或用户密码不正确，则提示“用户，不存在或密码不正确”；如果验证码失效给出失效提示信息。

输入项为空的逻辑在画因果图时不考虑，我们只分析输入错误和正确的情况。

1）找出原因和结果

• 原因：a、用户名，b、用户密码，c、验证码
• 结果：ab、用户不存在或密码不正确，c1、验证码不正确，c2、验证码失效， d、登入系统

2、3）分析因果关系，画出因果图，并在因果图上添加相关约束

4）将因果图转化为判定表，并化简

5）以最终判定表的每一列为依据设计测试用例

场景分析法设计测试用例 — 场景分析相关概念

场景

应用软件一般都是用事件触发来控制流程的，事件触发时的情景便形成了场景。

事件流

同一事件不同的触发顺序和处理结果就形成事件流，事件流分为基本流和备选流。

基本流

程序从开始执行直到成功结束所经过的最短路径。

备选流

一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中；也可能起源于另一个备选流，执行后加入基本流或者终止用例。

一个典型的场景分析图

场景分析法设计测试用例 — 使用场景分析设计测试用例

场景分析法

通过分析事件流设计测试用例的方法。

场景分析法的使用场景

场景分析一般在分析业务流程或流程化处理功能时使用。

场景分析法的优点

场景分析法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。

场景分析法设计测试用例的步骤

• 分析软件规格说明描述，整理出基本流和备选流
• 根据基本流和备选流组合关系生成场景
• 分析所有场景，合并测试内容重复的场景
• 根据场景逐一设计测试用例

例：在用信用卡网上支付时，输入信用卡卡号、查询密码和实时短信验证码，信息全部正确且账户金额充足的情况下可以完成付款。如果相关信息不正确则给出对应提示信息；多条信息不正确时按输入顺序提示；短信验证码一分钟内有效，出错三次则退出本次支付。

1）整理基本流和备选流

• 基本流：正常支付
• 备选流1：账户不存在；
• 备选流2：查询密码不正确；
• 备选流3：短信验证码不正确；
• 备选流4：短信验证码失效；
• 备选流5：账户余额不足；
• 备选流6：退出支付

2）根据事件流生成场景

• 场景1：基本流
• 场景2：基本流-备选流1
• 场景3：基本流-备选流2
• 场景4：基本流-备选流3
• 场景5：基本流-备选流4
• 场景6：基本流-备选流5-备选流6
• 场景7：基本流-备选流1-备选流2-备选流3-备选流6
• 场景8：基本流-备选流3-备选流4-备选流5-备选流6

3）合并重复场景

• 场景1：基本流
• 场景2：基本流-备选流5-备选流6
• 场景3：基本流-备选流1-备选流2-备选流3-备选流6
• 场景4：基本流-备选流3-备选流4-备选流5-备选流6

4）根据最终的场景逐一设计测试用例

测试用例总结 — 测试用例设计策略

• 任何情况下都要使用边界值分析法设计测试用例，经验表明这种测试用例发现程序错误的能力最强。
• 使用等价类划分法补充必要的测试用例。
• 如果程序规格说明中多个条件决定多个动作，每个条件的取值只有两种，并且条件和动作之间的逻辑关系明确，那么使用判定表法设计测试用例。
• 针对程序规格说明中含有多个条件的组合，输入与输出关系比较复杂的情况，使用因果图法设计测试用例。
• 针对程序规格说明中的复杂业务流程、操作流程等，使用场景分析法设计测试用例。
• 对照程序实现逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到覆盖要求，应当分析具体情况，补充足够的测试用例。
• 分析程序规格说明，使用错误推测法补充一部分测试用例。
• 测试过程中针对具体实现，将已有测试用例未覆盖的部分，选用合适的测试用例设计方法再补充一些必要的测试用例。

测试用例总结 — 测试用例编写策略

• 功能测试用例覆盖的功能点需要尽量小，方便测试执行时提取用例。
• 对于常用控件的测试可以整理出针对控件的通用测试点，在具体的功能测试用例中就可以不再编写通用测试点已经覆盖的内容了。
• 对于系统相关流程的测试用例，可以提取出来，编写有针对性的流程测试用例。
• 对于业务关联性比较强的功能，可以提取出来，针对存在的业务场景编写功能测试用例。

测试用例总结 — 测试用例的维护管理

测试用例伴随着软件产品的整个生命周期，随着软件功能的日渐完善，测试用例也在不断改进、扩充和完善。在这个过程中，如何维护和管理测试用例将是直接影响软件测试质量的重要工作内容。

维护测试用例的原因

• 软件需求变更
• 需求分析错误
• 测试需求误解或遗漏
• 测试用例遗漏

测试用例的维护

日常维护主要有测试用例修改、测试用例删除和测试用例增加。

用例修改

测试设计人员在设计测试用例时考虑不够全面，对测试需求的理解偏差或误解，功能实现和设计存在出入等都是造成测试用例修改的直接原因。

用例删除

测试用例的删除主要是因为软件相关功能发生较大变化或已去掉，对应测试用例已不适用时，就需要删除对应用例；冗余的测试用例也需要删除。

用例增加

测试人员在测试过程中发现有测试用例未覆盖的功能，用例评审时发现有未覆盖的测试需求，需求分析错误或收到新的需求时都需要新增对应功能的测试用例。

用例维护注意事项

• 用例的维护都需要保留维护记录
• 同一软件不同现场功能出入较大的话，需要根据现场维护不同的测试用例
• 同一软件多版本共存的话，需要在测试用例中标注不同版本的用例差异

测试用例的管理

测试用例根据公司代码和文档管理体制的不同采用对应的管理方式。如果公司资料文档使用同一个管理软件的话，将测试用例直接纳入管理软件测试相关目录即可；如果测试是作为一个完全独立的部门，相关资料文档有自己的管理软件的话，则将测试用例纳入自己软件的相关目录。

管理测试用例的作用

• 保护测试人员工作成果。
• 测试人员变动不会影响测试工作的正常进行。

用例管理注意事项

• 用例设计人员只有上传和更新用例文档的权限，不具有删除用例文档的权限，删除用例文档需经过相关人员核准。
• 用例文档更新的人员、日期等历史信息需要能够查询。
• 用例执行人员不具有编辑用例文档的权限。
• 所有的用例评审结论文档都需要纳入文档管理系统。