如何进行测试需求分析：从接收需求到用例设计

如何进行用例设计，如何让设计好的用例覆盖全面，将代码存在的问题在上线前更早发现是每一个测试工程师必备的技能。那么如何达到这些指标呢？如何将用例设计既快又全面呢？今天小编就告诉大家常用设计用例的方法，以及每个方法的适用范围，便于大家更快的选择出最优的方法。

从需求到用例设计

在项目中我们从拿到产品需求到最后的用例设计完成，都要经历哪些事情，包括今天要讲的用例设计方法是在哪个阶段使用，上面的图会告诉你答案。

设计用例方法

1.等价类

定义：把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例。等价类数据一般分为有效等级类和无效等级类。

构造测试用例方法：

1）明确需求

2）分析需求中包含功能数

3）确认每一个独立功能具有多少输入

4）确认每个输入的规则

5）针对每个输入设计等价类表：有效数据和无效数据。以三边是否能组成三角形为例

6）构造测试用例：输入和操作进行组合

2.边界值

定义：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充。这种情况下，其测试用例来自等价类的边界。

与等价划分的区别:

注：上点是边界上的点；离点是指距离上点最近的点，开区间在域内，闭区间在域外。

3.判定表

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

判定表的组成：

判定表通常由四个部分组成如下图所示：

条件桩（Condition

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

动作桩（Action

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

3)条件项（Condition

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

4)动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

5）规则及规则合并

A 规则

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

B 化简 ：就是规则合并 。

a. 有完全相同的动作桩；

b. 条件桩中只有一个不同项

构造测试用例方法：

1 ）需求中 找到 条件桩：输入参数要满足的条件

2 ）需求中 找到 动作桩：满足条件后得到的结果

3 ）组合所有的条件桩形成2的n次方个组合，n代表条件桩的个数

4 ）分析需求 中提到的 每一组条项桩所对应的一个或多个动作桩

5 ）查看是否可以合并， 但合并时要谨慎，因为合并后容易发生漏测

6 ）写测试用例，每一列对应一条测试用例（不存在的结果可以忽略，因没有数据可取）

以下 是形成 普通 三角形 的判定表 ：

4.流程分析法（场景设计）

简介：现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。类似于白盒测试中的路径覆盖，通过画流程图分析功能的路径。

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

快速画流程图方法：

1 ）从需求 中找到 判定条件（如果，假如，当）

2 ）将这些判定框罗列到流程图中（可以暂时不用考虑顺序），注意挖掘SRS中没有提到的隐性判定条件

3 ）先画基本流（正常路径），再画备选流（分支）

构造测试用例方法：

1 ）分析业务，画出流程图

2 ）根据基本路径写基于业务场景的测试用例（用例 数= 判定条件个数+1）

5.正交试验

简介：把影响实验指标的条件称为因子。影响实验因子的条件叫因子的状态（水平）。利用正交试验设计方法设计用例时,首先要从需求中找出影响其功能实现的操作对象和外部因素,把他们当作因子。而各个因子的取值当作状态。确定因子与状态是设计测试用例的关键。因此要求尽可能全面的正确的确定取值,以确保测试用例的设计作到完整与有效。

构造

测试用例方法：

1）从需求中找出因子（输入参数）

2）从需求中找出因子状态（输入参数对应的取值）并编号，画出因子状态表

3）合并或补充因子状态表，代入正交表

4）拆分正交表，替换成文字，一行是一条用例，以打印机功能为例，正交试验表如下：

6.因果图

定义 ：

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

构造测试用例方法：

1）需求分析找出原因，然后给原因编号

2）需求分析找出结果，然后给结果编号

3）根据需求分析文档，分析原因与结果之间的关系

4）根据需求分析文档，分析原因与原因之间的关系

5）根据需求分析文档，分析结果与结果之间的关系

6）根据需求分析文档，画因果图

7）依据因果图去除判定表中不存在的组合

8）判定表中每一列对应一条测试用例

7.输入域覆盖

简介

： 输入 的数据包含一些 易 引出内存溢出和内存泄露（区别，定义）的 类型边界 ， 或者一些特殊 值

如电话号码等。

构造测试用例方法：

1 ）SRS分析对应的输入参数是否存在特殊值和类型边界

2 ）若存在，则补充特殊值和类型边界的测试数据（检查是否会出现内存溢出）

8.输出域覆盖

简介：分析输出结果的形式（提示信息，输出的显示结果，数据库的记录等）

构造测试用例方法：

1 ）通过与开发的沟通，明确对应功能所有可能的输出结果有哪些

2 ）逐一罗列（输出的形式主要针对提示信息和显示结果）

3 ）检查对照现有测试用例是否已经覆盖了所有的输出

4）若没有完全覆盖，则根据输出结果要求，倒推补充测试用例

9.异常分析

定义：基于经验和直觉推测程序中所有可能存在的各种错误,

从而有针对性 的设计测试用例的方法

基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。如网络异常、断电、服务器宕机等

构造测试用例方法：

1）根据需求分析文档，构造环境异常（网络、电源、服务器、程序关闭）

2）补充异常测试用例

适用范围

通过上述的介绍，设计用例的方法这么多，如何选择使用哪种方法呢？文章开篇中的流程图，处理过程为什么用流程分析而不用状态迁移法呢？下面小编总结了各种方法的优缺点以及适用范围，希望可以帮助大家。

我们在实际工作中，可能一个功能会存在多种情况，所以大家要灵活使用方法，必要时设计用例方法要进行组合使用，设计出的用例才能更全面。一般情况下，一份用例最少用到2种以上方法才能全面覆盖测试点。

原文转自：www.uml.org.cn/Test/201906171.asp