测试用例的概念以及方法总结

1. 概念

• 测试用例定义

  测试用例又叫做test case，是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。

• 测试用例的特性

  • 有效性

    测试用例的能够被使用，且被不同人员使用测试结果一致。

  • 可复用性

    良好的测试用例具有重复使用的功能，如：回归测试

  • 易组织性

    好的测试用例会分门别类地提供给测试人员参考和使用。

  • 可评估性

    从测试管理的角度，测试用例的通过率和软件缺陷的数目是软件产品质量好坏的测试标准。

  • 可管理性

    从测试管理的角度，测试用例的通过率和软件缺陷的数目是软件产品质量好坏的测试标准。

2. 测试用例的要素

测试用例编号	测试项目(测试模块)	预置(前提)条件	测试输入	预期输出	操作步骤	测试用例标题	级别
ST-子项名-01	手机登录	手机正常使用	手机号	正常登录	输入手机号并确认	测试能否手机登录成功	重要

• 测试用例八大要素

  1. 测试用例编号

     编号由字符和数字组合成的字符串,用例编号具有唯一性、容易识别, 如下表

  2. 测试项目/模块

     测试的项目属于哪个项目或者被测试的需求、被测的模块、被测的单元等等

  3. 预置条件 执行当前测试用例需要的前提条件,如果前提条件不满足,则后面的测试步骤不能进行或者得不到预期结果

  4. 测试输入 测试用例执行过程中需要加工的外部信息.根据测试用例的具体条件有手工输入、数据库等

  5. 预期输出 测试用例的预期输出结果,包括返回值内容、界面响应结果等.

  6. 操作步骤

     执行当前测试用例需要经过的操作步骤，需要明确的给出一个步骤的描述，测试用例执行人员可以根据该步骤完成测试用例执行

  7. 测试用例标题

     对测试用例的简单描述。用概括的语言描述该测试用例的测试点。每个测试用例的标题不能够重复，因为每个测试用例的测试点事不一样的。

  8. 级别

     对于测试用例的重要程度的区分.包含如下几种:

     • 高级别：保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例

     • 中级别：重要程度介于高和低之间的测试用例

     • 低级别：实际使用的频率不高，对系统业务功能影响不大的模块或功能的测试用例

• 其他要素

  • 用例的设计者:能准确找到测试用例的设计人员,对用例修改时能方便找到人员
  • 用例设计日期: 方便检查用例的设计进度
  • 对应的开发人员: 出现bug后能及时找到相应的人员进行修复
  • 测试结果: 执行用例最后执行的结果, 包括:pass、fail、block
  • 测试类型: 功能、性能、压力等等

3. 测试用例的设计原则

• 明确性

  测试人员要尽量避免测试用例存在含糊的因素，在测试过程中，测试用例的测试结果是唯一的。

• 代表性

  尽量将具有相似功能的测试用例抽象合并，功能相似的用例要合并。

• 简洁性

  测试用例简洁，可读性良好，测试过程目的明确，测试结果唯一。 测试用例要用陈述性语句 一句话直指问题的核心 ,不要使用浮夸的修饰手法

4. 小结

测试用例要素是为了便于我们快速的设计测试用例,因此要掌握最常用的八大要素, 但是每家公司的具体要求不一样,要根据公司要求灵活添加测试的元素.

---

等价类划分法

• 官方定义:

  等价类测试方法是把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据作为测试用例。使用等价类划分方法设计测试用例要经历划分等价类（列出等价类表）和选取测试用例两步。它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性。

• 等价类划分

  在测试中最完美的测试是使用穷举测试,把所有的数据都测一遍.但是实际工作中不能采用,因为效率太低了. 理想的测试时:使用最少的测试数据,达到最好的测试质量.

• 合理假设

  测试某等价类的代表值就等于对这一类其它值的测试。

• 类型划分

  • 有效等价类

    有效等价类是指对对于程序的规格说明来说是合理的、有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.

  • 无效等价类

    无效等价类指对程序的规格说明是不合理的、无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。利用无效等价类可校验程序对于无效数据的处理能力,检测程序的健壮性、容错能力

• 等价类

  等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，具有等价特性。

• 注意

  设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据,也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。

• 设计测试用例步骤

  1. 确定需求
  2. 确定有效等价类和无效等价类
  3. 对每条等价类设计测试用例

---

边界值法

• 介绍

  边界值分析法就是对输入或输出边界值进行测试的,也是一种黑盒测试. 边界值分析法通常作为等价类划分法的补充,其测试用例来自等价类的边界; 长期的经验得知,大量的错误是发现在输入或输出范围的边界上，而不是发生再输入输出范围的内部，因此针对各种边界情况设计测试用例，可以查出更多错误.

• 等价类划分法的区别:

  • 等价类划分法可以挑选等价范围内任意一个数据作为代表 边界值分析法要求每个边界值都要作为测试条件
  • 边界值分析法不仅考虑输入条件,同样考虑输出产生的测试情况

• 常见的边界值

  • 边界点(上点) 输入范围的边界点
  • 离点 离边界点最近的点
  • 内点 输入范围内的任意一个点

• 步骤:

  1. 明确需求
  2. 确定有效和无效等价类
  3. 明确输入条件中的边界值
  4. 编写测试用例

---

因果图法

• 定义

  因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法， 它适合于检查程序输入条件的各种组合情况

• 特点：

  1. 考虑输入条件的相互制约及组合关系
  2. 考虑输出条件对输入条件的依赖关系

• 背景

  等价类划分法和边界值分析法都是着重考虑输入条件，但没有考虑输入条件的各种组合，输入条件之间的相互制约关系，这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。 如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合，相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。

• 核心

  因果图法比较合适输入条件比较多的情况，测试所有的输入条件的排列组合，所谓的原因就是输入，所谓的结果就是输出。 "因"= 输入条件 "果"= 输出结果

• 主要考虑内容

  1. 所有输入/输出条件的相互制约关系以及组合关系
  2. 输入条件的依赖关系，也就是什么样的输入组合会产生怎么样的输出结果，即"因果关系"

• 因果图中的符号

  • 基本符号

    通常在因果图中用Ci表示原因，用Ei表示结果，各结点表示状态，可取值‘0’或‘1’。‘0’表示某状态不出现‘1‘表示某状态出现。

  • 约束条件

    • E(exclude) 约束: a和b中至多有一个为1.
    • I(include) 包含: a、b和c中至少有一个必须是1.
    • M(mandatory) 强制: 若结果a是1,结果b强制为0.
    • O(only) 唯一: a和b必须有一个，且仅有1个为1.
    • R(required) 要求: a是1时，b必须是1.

• 因果图法基本步骤

  1. 找出所有的原因，原因即输入条件或输入条件的等价类。
  2. 找出所有的结果，结果即输出条件。
  3. 明确所有输入条件之间的制约关系以及组合关系。 哪些条件不能组合到一起，哪些条件可以组合到一起
  4. 明确所有输出条件之间的制约关系以及组合关系。 哪些输出结果不能同时输出，哪些输出结果可以同时输出
  5. 找出什么样的输入条件组合会产生哪种输出结果。
  6. 把因果图转换成判定表/决策表。
  7. 为判定表/决策表中的每一列表示的情况设计测试用例。

• 案例：交通一卡通自动充值软件

  • 系统需求

    • 系统只接收50或100元纸币，一次只能使用一张纸币，一次充值金额只能为50元或100元；
    • 若输入50元纸币，并选择充值50元，完成充值后退卡，提示充值成功；
    • 若输入50元纸币，并选择充值100元，提示输入金额不足，并退回50元；
    • 若输入100元纸币，并选择充值50元，完成充值后退卡，提示充值成功，找零50元；
    • 若输入100元纸币，并选择充值100元，完成充值后退卡，提示充值成功；
    • 若输入纸币后在规定时间内不选择充值按钮，退回输入的纸币，并提示错误；
    • 若选择充值按钮后不输入纸币，提示错误

---

判定表法

• 定义

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

• 使用场景

  适合于有多个输入和对个输出,输入和输出之间有相互的组合关系, 输入输出之间有相互的制约和依赖关系

• 组成

  判定表是由条件桩、动作桩、条件项、动作项四部分组成,如下图.

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

• 规则

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

• 化简

  规则合并有两条或多条规则具有相同动作,并且其条件项之间存在着极为相似的关系。

• 步骤

  1. 明确规则个数
  2. 列出所有条件桩和动作桩
  3. 填入条件项
  4. 填入动作项到初始判定表
  5. 简化,合并相似规则

• 案例1: 公交卡充值

• 案例2：维修设备

  • 问题要求 对于功率大于50马力的机器且维修记录不全 或 运行10年以上的机器,应优先维修.

• 优缺点

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

---

正交表法

• 定义

  正交法,也叫正交实验法或者正交排列法, 就是使用最小的测试过程集合获得最大的测试覆盖率。 "正交实验"是研究多因素、多水平的一种实验方法,它利用正交表来对实验进行设计,通过少数实验代替全面的实验。 在一项实验中,把影响试验结果的量称为试验因素(因子)，简称因素。因素可以理解为试验过程中的自变量，试验结果可以看成因素的函数。 在试验过程中，每一个因素可以处于不同的状态或状况，把因素所处的状态或状况，称为因素的水平，简称水平。

• 历史案例

  1992年AT&T公司,针对某一个软件做了一个回归测试： 在18个周（4个半月）的时间范围内测试1500条测试用例。后来开发时间推迟了，测试时间被压缩了。测试经理想了一个办法，两个人在8个周（2个月）测试1000条测试用例。但是测试经理不能保证该软件就是完全没有问题的。后来他决定用正交表去重新设计一下测试用例，422条测试用例，42个bug。测试完毕后，软件上线了。在上线的两年时间内。凡事被测试到的领域，都没有发现任何问题。后来呢，他从头到尾有总结了一番：有可能只会测试出32条bug。

• 前后对比：

  • 测试用例的条数少了
  • 测试出来bug的数量多了

• 要点

  所有组合中，只要任意两个因素间 进行了全排列即可。

• 步骤

  1. 根据需求把空间即其取值列举出来
  2. 根据空间和空间的取值个数,选择一个合适的正交表
  3. 根据控件的个数,选择正交表的次幂,也就是正交表中包含的最大值, 例如,4个控件,选择4次幂
  4. 根据控件取值个数,选择正交表的底,也就是正交表包含的最大值, 例如, 每个控件有3个取值,底是3
  5. 把控件及其取值映射到正交表中
  6. 把控件名字分别映射到正交表的列名位置
  7. 把正交表中每一列的数字分别用对应的控件取值替代
  8. 根据正交表,编写测试用例

• 案例

  实现"字符属性设置"的测试用例编写

  | 字体 | 字符样式 | 字体颜色 | 字号 | | :------: | :------: | :------: | :--: | | 仿宋 | 粗体 | 红色 | 20号 | | 楷体 | 斜体 | 绿色 | 30号 | | 华文彩云 | 下划线 | 蓝色 | 40号 |

• allpairs工具的使用

  1. 利用Excel准备一个表格
  2. 将表格内容贴到txt文本中，并保存
  3. 通过allpairs 命令生成
  4. 拷贝结果到测试用例中

• 使用场景

  需求中条件的组合量比较大的时候 需求两个两个相互组合的时候

---

场景法

• 定义

  从起点，通过一系列操作步骤（事件），达成某一结果，到终点的过程测试。 场景法主要用于冒烟测试。在通过了场景测试后，再通过其他方法进行更为细腻的测试。

• 概念及定义

  现在的软件几乎都是由事件触发来控制流程的， 事件触发时的情景便形成了场景， 而同一事件不同的触发顺序和处理结果形成事件流。

• 要素

  下图中经过用例的每条不同路径都反映了基本流和备选流，都用箭头来表示。基本流用直黑线来表示，是经过用例的最简单的路径。每个备选流自基本流开始，之后，备选流会在某个特定条件下执行。备选流可能会重新加入基本流中（备选流 1 和 3），还可能起源于另一个备选流（备选流 2），或者终止用例而不再重新加入某个流（备选流 2 和 4）。 

• 说明

  遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景： 场景 1 基本流 场景 2 基本流 备选流 1 场景 3 基本流 备选流 1 备选流 2 场景 4 基本流 备选流 3 场景 5 基本流 备选流 3 备选流 1 场景 6 基本流 备选流 3 备选流 1 备选流 2 场景 7 基本流 备选流 4 场景 8 基本流 备选流 3 备选流 4 注：为方便起见，场景 5、6 和 8 只描述了备选流 3 指示的循环执行一次的情况。

  ---

   

流程分析法

• 由来

  流程分析法主要是针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计，是从白盒测试设计方法中的路径覆盖分析法借鉴过来的一种方法。 在白盒测试中，路径就是指函数代码的某个分支组合，路径覆盖法需要构造足够的用例覆盖函数的所有代码路径。 路径覆盖法: 把所有测试条件写成测试用例,白盒是根据代码分支分析写测试用例 在黑盒测试中，若将软件系统的某个流程看成路径的话，则可以针对该路径使用路径分析的方法设计测试用例。 黑盒测试是看文档来写测试用例,不需要看代码

• 步骤:

  1. 详细了解需求；
  2. 根据需求说明或界面原型，找出业务流程的各个页面以及各页面之间的流转关系；
  3. 画出业务流程；
  4. 写用例，覆盖所有的路径分支。

• 案例-ATM

  1. ATM机功能
  2. 绘制出可达矩阵
  3. 使用深度或者广度法进行遍历
  4. 写测试用例

• 使用场景

  一般用于测试非常重要的系统（ATM机、医疗设备）

---

 错误推断法

• 定义

  错误推测法是: 基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

• 基本思想

  根据经验,列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

• 使用场景

  适用于项目时间比较短促，任务比较繁重的情况下，而且测试经验较多。

---

测试用例的力度

• 简单

  仅仅试测试的纲要，可能只包含测试的内容。 简单的测试用例其实并没有进行"设计"，而仅仅是记录。只是提醒测试人员主要功能有哪些。

• 复杂

  包含具体的输入项、每一个步骤、期待的结果。

• 中庸

  过于简单，会导致测试有遗漏，而且根据测试执行人员的水平不同导致偏差较大。 过于复杂，会导致效率太低，维护成本太高，限制测试人员的思维 一般在工作中都介于两者之间

 

---

测试用例设计方法总结

• 测试用例的本质（基于需求）

  • 理解需求、反映需求，忠于需求

  • 需求会变化，则测试用例也应该是活的，变化的

    "及时响应变更比遵循计划更有价值"

• 原则

  1. 根据程序的重要性和一旦发生故障带来的损失，来确定测试等级和测试重点
  2. 认真选择测试策略。用尽可能少的测试用例发现尽可能多的错误。测试用例不足则会导致风险的增大；测试过度导致资源的浪费。需要找到平衡点

• 方法选取

  1. 先关注主要功能也业务流程、业务逻辑是否正确实现，考虑场景法
  2. 需要输入数据的地方，考虑等价类划分法
  3. 在任何情况行都使用边界值法
  4. 如果程序的功能中包含输入条件的组合情况，则选取因果图和判定表法
  5. 对于配置类软件，需要考虑参数的组合情况，考虑使用正交排列法
  6. 对照程序逻辑，如果发现没有达到要求的覆盖标准。适当补充更多的测试用例
  7. 采用错误推断法，追加其他测试用例