测试用例设计

1、测试用例概述

测试用例是测试工作的指导，是软件测试必须遵守的准则。更是软件测试质量稳定的根本保障。

• 测试用例的内容是一系列情景和步骤的描述，并对每个步骤中必须列出依靠输入的数据，预计输出结果。将这一过程整理成测试文档，称为测试用例。
• 测试用例就是将软件测试的行为活动，做一个科学化的组织归纳。
• 是思想活动的集合

2、为什么需要测试用例

• 根据测试用例的多少和执行难度，估算测试工作量，便于测试项目的时间和资源管理与跟踪；
• 减少回归测试的复杂程度
• 在软件版本更新后只需修正少量的测试用例便可展开测试工作，降低工作强度、缩短项目周期；
• 根据测试用例的操作步骤和执行结果，可以方便地书写软件测试缺陷报告；
• 可以根据测试用例的执行等级，实施不同级别的测试；
• 总结：软件测试是有组织性、步骤性和计划性的，为了能将软件测试的行为转换为可管理的、具体量化的模式，需要创建和维护测试用例。

3、优质测试用例应具备的特性

有效性：

• 测试用例是测试过程中的重要参考依据。
• 不同测试人员根据相同的测试用例，得到的输出应该是一致的。
• 对于准确的测试用例的计划、执行和跟踪是测试有效性的有力证明。

可复用性：

• 良好的测试用例具有重复使用的功能，使得测试过程事半功倍。
• 设计良好的测试用例将大大节约项目执行时间，提高测试效率。

易组织性：

• 小项目可能也会有成千上万的测试用例
• 测试用例在使用中被反复的更新、修改或者新增，所以能有效地组织这些测试用例是非常重要的。

可评估性：

• 从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保证。
• 软件质量好坏的量化标准：测试用例的通过率和软件BUG的数量。

可管理性：

• 测试用例也可以作为检验测试人员工作进度、执行工作量以及跟踪、管理测试人员工作效率的因素
• 尤其是比较适用于新的测试人员的检验，从而更加合理的做出测试计划。

4、测试用例设计思路

测试用例的设计是一种思路，可以从如下角度分析：

（1）根据被测软件的功能和特性设计测试用例

•   - 根据被测试功能点设计测试用例
•   - 根据软件性能指标设计测试用例
•   - 根据软件的兼容性要求设计测试用例
•   - 根据软件的国际化用户要求设计国际化测试用例

（2）根据软件的组成元素设计测试用例

•   - 根据模块设计用例
•   - 设计联机帮助和文档手册的设计用例
•   - 设计软件的模版等数据文件的测试用例

（3）根据软件的开发阶段（里程碑）设计测试用例

•   - 单元测试设计用例
•   - 集成测试设计用例
•   - 系统测试设计用例
•   - 验收测试设计用例

（4）根据被测的最小目标，确定测试用例的测试目标

（5）根据用户使用环境确定测试环境

（6）根据以下因素确定测试用例的步骤

•  用户使用软件的步骤或者特定场景，确定测试执行步骤地具体内容
•  执行者对产品的熟悉程度确定步骤的详细或粗略程度
•  被测特性的复杂性也决定步骤的详细或粗略程度
•  测试用例的执行方法（手工测试或自动化测试）确定步骤地内容表示
•  自动测试用例要编写和调试测试脚本，手工测试给出执行步骤
•  根据设计规格说明书确定期望的测试用例执行结果

5、测试用例设计方法

等价类划分

• 等价类划分方法把所有可能的输入数据，即程序的输入划分成若干类，然后从每一类中选取少数      有代表性的数据做为测试用例/数据。
• 等价类是某个输入的子集合。在该子集合中，各个输入数据对于揭露程序中的BUG都是等效的。|测试某等价类的代表值就等价于对这一类其它值的测试。
• 等价类的划分有两种不同的情况：

①有效等价类：代表对程序的有效输入。

        ② 无效等价类：代表的则是其他任何可能的输入（即不       合理的，无意义的输入值）。

• 使用等价类设计测试用例要经历划分等价类（列出等价类表）和选取测试用例/数据两步。
• 划分等价类的原则：
  

                (1)如果输入条件规定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类。

                (2) 如果输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可以确立一个有效等价类和一个无效等价类。

(3) 如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类。

(4) 在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。

(5) 在规定了输入数据必须遵守的规则情况下，可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。

• 根据等价类划分选取用例/数据

(1)根据上述原则，列出所有的有效等价类和无效等价类

(2).设计一个新的测试用例，使其尽可能多地覆盖那些尚未被涵盖的有效等价类，重复这一步，直到所列出的所有有效等价类都被覆盖为止

(3).设计一个新的测试用例，使其覆盖一个且仅一个尚未被涵盖的无效等价类，重复这一步，直到所列出的所有无效等价类都被覆盖为止。

边界值分析

边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。

所谓边界值，是指输入和输出等价类中那些恰好处于边界、或超过边界、或在边界以下的状态

边界值分析方法和等价类划分方法不同的两个方面：

•   与从等价类中挑选任意一个元素作为代表不同，边界值分析需要选择一个或多个元素，以便等价类的每个边界都经过一次测试。
•   如果输入条件规定了一个输入值范围，那么应针对范围的边界值设计测试用例。
• 如果输入条件规定了输入值的数量，那么应针对最小数量输入值、最大数量输入值，以及比最小数量少一个、比最大数量多一个的情况设计测试用例。

因果图

• 使用前提：如果在测试时必须考虑输入条件的各种组合，就可使用因果图来设计测试用例。它适合于描述“对于多种条件的组合，会相应产生多个动作”的情况。
• 因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。
• 生成基本步骤：

(1)将软件规格说明（用例）分解成可执行的片断。

(2)确定软件规格说明（用例）中的因果关系。

(3)分析软件规格说明（用例）的语义内容，并将其转换为连接因果图关系的布尔图。

(4) 给图加上注解符号，说明由于语法或者环境的限制而不能联系起来的“因”和“果”。

(5) 通过仔细的跟踪图中的状态变化情况，将因果图转换为一个有限项的判定式。

(6) 将判定式表中的列转换为测试用例

• 因果图示例

例如，有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下：

若投入5角钱或1元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来。

若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入1元硬币并押下按钮后，饮料不送出来而且1元硬币也退出来；

若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还5角硬币。”

(1)分析这一段说明，列出原因和结果:

1. 售货机有零钱找

2. 投入1元硬币

3. 投入5角硬币

4. 押下橙汁按钮

5. 押下啤酒按钮

(2)建立中间结点，表示处理中间状态

11. 投入1元硬币且押下饮料按钮

12. 押下〖橙汁〗或〖啤酒〗的按钮

13. 应当找5角零钱并且售货机有零钱找

14. 钱已付清

(3)结果：

21. 售货机〖零钱找完〗灯亮

22. 退还1元硬币

23. 退还5角硬币

24. 送出橙汁饮料

25. 送出啤酒饮料

(4) 画出因果图。所有原因结点列在左边，所有结果结点列在右边。

(5) 由于 2 与 3 ，4 与 5 不能同时发生，分别加上约束条件E。

(6)转换成因果图判定表。

判定表驱动分析方法——判定表又称为决策表

当模块中包含复杂的条件组合，并要根据这些条件选择动作时，使用判定表能清晰地表示出复杂的条件组合与各种动作之间的对应关系。

一张判定表的田字型结构：条件桩、条件项、动作项、动作桩规则。

决策表的读表方法：顺时针方向。

条件桩	条件项   （条件的组合）
动作桩	动作项

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

判定表的绘制步骤：

• 判定表中列出多少组条件取值，也就有多少条规则，条件项和动作项就有多少列。
• 确定规则的个数。假如有n个条件，每个条件有两面个取值(0,1)，故有2n种规则。
• 列出所有的条件桩和动作桩
• 填入条件项
• 填入动作项。制定判定表
• 简化。合并相似规则或者相同动作

错误推测法

• 人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。这就是错误推测法。
• 错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。

场景法

• 现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。
• 提出这种测试思想的是Rational 公司，并在RUP2000 中文版当中有其详尽的解释和应用。
• 用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有基本流和备选流。

数据驱动法

概要

• 是一种成熟的自动化测试技术
• 强调测试逻辑与测试数据分离
• 对于手工测试也是很好的方法
• 适用于需要用不同数据进行重复测试的情形
• 通过测试数据调整测试覆盖率

原理

• 以参数代替测试步骤中原始数据
• 测试数据依参数保存在数据文件中（Excel）
• 测试步骤和测试数据相对分离
• 执行时将测试数据按参数代入测试步骤执行

优点

• 大大简化了测试步骤
• 通过分离测试逻辑和测试数据，使设计测试逻辑和数据时分别关注于使用各自的设计方法
• 有利于测试分工的细化
• 测试逻辑更加简洁易懂
• 很容易转化成自动测试脚本

6、测试用例书写标准

• 标示符——用来说明这个文档的编号、名称或者用途等
• 测试项——本测试文档测试的对象
• 文档拥有者、版本编号、创建日期——谁写的？版本号？创建日期？修改日期？
• 测试环境要求——软件运行的环境（软环境和硬环境）
• 测试动作描述——测试一步一步执行的详细步骤描述
• 预期值——软件的设计要求的数据
• 测试数据——为本测试用例执行准备的验证数据
• 测试用例间关联——这份测试用例可能会跟谁相关联，组合测试