一、前言

1.1 什么是测试用例

测试用例就是为了事实测试向被测试系统发起的一组集合，包含测试环境，测试数据，测试步骤，预期结果（用例编号，测试概述，重要性，优先级，操作方式，前置条件…）

1.2 编写测试用例的意义

• 测试用例是测试执行的依据
• 测试用例可以衡量需求的覆盖率
• 测试用例是可以复用的，在进行回归测试的时候不用重新编写，提高效率
• 后人可以借鉴
• 手工测试用例是自动化测试的依据

1.3 测试用例的标准

• 用例的表达清楚直观，无二义性
• 用例操作步骤明确，可操作性强
• 用例的输入输出明确，预期结果是一定的
• 用例的可维护性要好
• 用例对需求的覆盖率高
• 用例可以强有力的展现BUG

二、测试用例编写方法

2.1 基于需求设计测试用例

众所周知，需求才是测试人员进行测试的根本依据

测试人员需要进行需求的分析，需要进行验证需求的合理性和正确性，保证无二义性。然后再从需求中提取出测试项，将测试项进行细细划分，提取出一个个测试点，编写成测试用例

否则需求都存在问题，就没有进行测试的必要

想要将测试对象的所有相关功能都进行测试，可以将页面从上到下，从左到右，一一去分析每一个测试点，确保没有遗漏

2.1.1功能项

(1)从界面开始进行测试

界面测试就是对测试对象的外观进行测试，被测试的对象必须要符合 U I 设计稿的要求

(2) 验证软件的具体功能

测试软件的功能，需要有整体思维，不能光关注某一项功能，还需要将于该功能相关的功能进行穿起来测试。

(3) 同一个功能的不同输入对应不同的输出

(4) 功能之间的交互性

(5) 异常功能的测试

(6) 功能用到的算法的验证

2.1.2非功能项

非功能性测试就是在软件本身具有的功能上做出的一些限制

• 性能
• 易用性
• 兼容性
• 可靠性
• 安全性
• 容错性
• 可移植性
• 可维护性
• …

2.2 具体的设计测试用例方法

2.2.1 等价类

事实上，测试用例是没有办法穷举的，等价类的出现就可以帮助我们解决这个问题

一般情况下，我们可以根据输入，把输入划分成若干个等价类，从每个等价类中选择测试用例进行测试，如果被选中的测试用例通过了测试，我们就认为该测试用例代表的等价类测试通过

示例：登录页面的密码要求以字母开头，字母（不管大小写）、数字、特殊字符都包含，长度在6~12位

等价类划分：

长度符合要求

1. 字母开头，只包含字母
2. 字母开头，还包含数字
3. 字母开头，还包含特殊字符
4. 字母开头，还包含数字和特殊字符
5. 数字开头，只包含数字
6. 数字开头，还包含字母
7. 数字开头，还包含特殊字符
8. 数字开头，还包含字母和特殊字符
9. …

长度不符合要求

1. …

有效等价类

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

无效等价类

不符合需求规格说明的集合

在示例中，只有第4类（字母开头，还包含数字和特殊字符，长度符合要求）是有效等价类，其余的都是无价等价类

2.2.2 边界值

边界值方法针对输入和输出的边界进行测试用例的设计，往往和等价类方法结合在一起使用。取边界值时需要取边界上的值，也要取边界左右两边的值

例如上面示例中密码长度6~12位，这就涉及到了边界条件，取 5，6，7，11，12，13

2.2.3 因果图

当有很多的输入时，不同的输入及其组合会有不同的输出，此时就适合使用因果图法进行测试用例的编写

因果图，就是一种逻辑图，能够简洁明了的表明输入调节条件和输出结果之间的关系

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

1. 分析出所有的输入和输出
2. 找到输入和输出之间的组合关系
3. 根据关系画出因果图
4. 根据因果图写出判定表
5. 根据判定表写出测试用例

示例：火锅店有优惠活动，手机上提交订单后，金额大于100或者有优惠券，就可以享受优惠

步骤一：分析出所有的输入和输出

输入：金额大于100、金额小于等于100、有优惠券、没有优惠券、提交订单、未提交订单

输出：享受优惠、无法享受优惠

步骤二：找到输入和输出之间的组合关系

1. 提交订单，金额大于100，有优惠券，享受优惠
2. 提交订单，金额大于100，没有优惠券，享受优惠
3. 提交订单，金额小于等于100，有优惠券，享受优惠
4. 提交订单，金额小于等于100，没有优惠券，无法享受优惠
5. 未提交订单，金额大于100，有优惠券，无法享受优惠
6. 未提交订单，金额大于100，没有优惠券，无法享受优惠
7. 未提交订单，金额小于等于100，有优惠券，无法享受优惠
8. 未提交订单，金额小于等于100，没有优惠券，无法享受优惠

步骤三：根据关系画出因果图

步骤四：根据因果图写出判定表

步骤五：根据判定表写出测试用例

在这里的测试用例内容和步骤二的内容有所重叠，不同的是5、6、7、8都是没有提交订单的情况，可以等价为一类，只测试其中一个，1、2、3、4都需要进行测试

2.2.4 场景设计法

很多的软件是由各种不同的场景，基于不同事件的触发，不同事件的触发会导致场景走向不同的事件流

不同场景中的每一个场景都是由不同的功能点串接起来的，不同的功能点就会有不同的输出，输出的不一样就会导致不同的结果

该方法可以比较生动地描绘出事件触发时的情景，方便测试用例的设计，理解与执行，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向

示例（关于注册）：

根据场景不同，选择的不同，所导致的结果不同

就拿用户激活这一场景来说，可以挖掘的测试点有

• 用户提交注册信息后多久才会收到用户激活链接
• 收到的激活链接邮件是否内容有误，链接是否无法访问
• 限制获取用户激活链接的频率
• 用户成功收到邮件，登录时再输入邮件和密码就不会发送邮件，并提示信息
• 用户没有收到邮件，登录时再输入邮件和密码，再次发送激活邮件
• 收到邮件后，在24小时内进行激活，用户激活成功
• 收到邮件后，24小时后进行激活，此时激活链接失效，用户激活失败
• 收到邮件，激活成功，链接未失效，用户再次激活，提示已激活
• 收到邮件，激活成功，24小时后链接失效了，用户再次激活，提示已激活
• 用户激活成功后，是否真的注册成功

2.2.5 错误猜测法

错误猜测法是一种根据测试人员的经验和直觉猜测某一块功能可能出现的问题，有针对性的进行测试用例编写的方法。该方法属于探索性测试，针对性强，依赖测试人员能力水平的方法。适用于用例设计后，作为补充，加强设计测试用例

2.2.6 正交排列法

根据正交性来设计测试用例，从大量的实验数据中根据正交原则取出最优的数据的组合，根据最优数据组合试验结果，来分析测试的结果。

了解即可~