如何编写测试用例

我们为什么需要编写测试用例？

  测试用例，简单来说就是对测试任务的描述。试想下，把一个软件直接丢个一位测试新人，要求其测试，他会怎么做？他很有可能，拿起软件，很努力很努力的把他所想到的所有要点都测试一遍，如果恰巧没发现问题，便回答“已测试完毕”。但如果你是这个测试任务的发布者，收到这样的结果，肯定是不放心的，你会不清楚这位新人到底测试了什么，有没有哪些遗漏点，每个测试要点是否都用到有效的方法确实测到了…诸如此类的疑问肯定不停地冒出。

  那么，我们会很自然的想到，用一个文档，将测试的方案、方法、结果等记录下来，便可以很好的向他人展示测试工作是如何进行的，这个文档就是“测试用例集”，是由很多个测试用例组成。

  编写测试用例，给他人展示只是其附加作用，我认为其核心意义在于帮助测试人员梳理思路，得到更全面得测试点，并且在开始动手前就写好，避免了测试时思绪被结果所混乱，而导致对结果的误判等情况。

什么是测试用例

  摘抄下百度百科：

  测试用例(Test Case)是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。简单地认为，测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。

  概念总是非常的抽象，直接看看测试用例模板，以Excel形式大致如下：

  每一个测试案例，包含用例编号、用例标题、测试项目、用例级别、预置条件、测试输入、执行步骤预期结果等要点：

测试用例的设计方法

等价类

  等价类法，就是把所有的可能输入数据，即将程序的输入域划分成若干子集，然后从每一个子集中选取少数具有代表性的数据作为测试用例，就可以用少量代表性的测试数据，取得较好的测试结果。

  等价类又可分为有效等价类和无效等价类：

• 有效等价类:是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合，利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
• 无效等价类:与有效等价类的定义恰巧相反；

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

边界值

  边界值分析方法是对等价类划分方法的补充，大量的错误是发生在输入或者输入范围的边界上，而不是输入范围的内部，因此针对各种边界情况设计测试用例，可以查出更多的错误。

  比如，预期的输入参数范围为：大于等于0，且小于等于100的整数。那么便需要选取其边界及相邻数据进行测试：-1 ，0 ，1 ，99，100，101，分别对0和100的边界进行测试。

判定表法

  判定表法，表示的是有多个输入和多个输出，而且输入与输入之间有相互的组合关系、输入和输出之间有相互
的制约和依赖关系。

  再通俗点来说，就是决定事情的结果时，有多个参数，将这些参数排列组合，列出每种组合形式对应的结果。这种方法，就叫判定表法。

  判定表由以下四部分组成：

• 条件桩：系统的所有可能输入情况，每种情况是完全独立的
• 动作桩：系统的所有可能采取的操作（输出情况），这些操作的排列顺序没有约束
• 条件项：分别将输入条件是否成立进行排列组合
• 动作项：列出在上述输入条件时，每个动作桩是否成立

  来个实例，更直观的理解，待测试的需求逻辑如下：

订购单的检查，如果金额大于500元，且未过期，则发出批准单和提货单； 如果金额大于500元，但过期了，则不发批准单；如果金额小于等于500元则不论是否过期都发出批准单和提货单，在过期的情况下还需要发出通知单。

  判定表法，可以视作将所有的合理输入场景列出来，然后判断其预期结果。但是未考虑不合理的输入，比如订单金额为负数等情况。

因果图法

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

  因果图法中使用了4种符号分别表示了规格说明中向4种因果关系，可以查看该博客，对符号了详细介绍，我就不直接搬运了：《因果图法的介绍与示例分析【转载】》

  来个实例：

某软件规格说明书包含这样的要求：第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改，但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息M。

  1.根据题意，原因和结果如下：
  原因：

• 1——第一列字符是A；
• 2——第一列字符是B；
• 3——第二列字符是一数字。

  结果：

• 21——修改文件；
• 22 ——给出信息L；
• 23——给出信息M。

  2.其对应的因果图如下：

11为中间节点；考虑到原因1和原因2不可能同时为1，因此在因果图上施加E约束。

  3.根据因果图建立判定表。

  表中8种情况的左面两列情况中，原因①和原因②同时为1，这是不可能出现的，故应排除这两种情况。表的最下一栏给出了6种情况的测试用例，这是我们所需要的数据。

状态迁移图法

  状态—迁移图(STD)或状态—迁移表被用来描述系统或对象的状态，以及导致系统或对象的状态改变的事件，从而描述系统的行为。属于结构化分析方法使用工具。

  使用步骤：

（1）将软件需求规格说明书划分为需求子片段，分析需求子片段，找出状态和状态迁移的条件

（2）设定一个初始状态，以圆圈为节点（代表状态），以箭线为跳转方向（跳转条件）画出状态迁移图

（3）根据状态迁移图，生成状态时间表，状态转换树，以及测试路径

（4）添加非法测试路径，结合等价类和边界值生成最终的测试用例

  实例：

1.需求片段：容器（能够容纳200只苹果，每次放入一个）

2.状态：空；半满；满 条件：放入；取出

3.状态迁移图

4.状态事件转换表

5.状态转换树（矩形框代表节点）

6.得出测试路径

路径1：空–半满–空

路径2：空–半满–满--半满

7.添加非法测试路径

空—取出；满–放入

场景法

  场景法主要是以用户实际使用场景为视角，通常以正常的用例场景分析开始，然后再着手其他的场景分析，穷举遍历所有备选流，把每个流程都写作一份测试案例。

上图中就有以下场景：

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