文章目录

• 1. 测试用例的概念
• 2. 设计测试用例的好处
• 3. 基于需求设计测试用例
• • 3.1 功能性需求
  • 3.2 非功能性需求
• 4. 设计测试用例的具体方法
• • 4.1 等价类
  • 4.2 边界值
  • 4.3 错误猜测法
  • 4.4 场景设计法
  • 4.5 因果图法
  • 4.6 正交法
• 5. 测试用例的粒度

1. 测试用例的概念

测试用例就是测试人员向被测试系统发起的一组集合，该集合包括测试环境，测试数据，测试步骤，预期结果

2. 设计测试用例的好处

在测试前都要先设计测试用例，设计测试用例有如下好处：

1. 测试用例是测试人员执行测试的依据
2. 在做回归测试的时候，测试用例可以复用
3. 测试用例可以衡量需求的覆盖率
4. 测试用例是自动化测试的依据
5. 测试用例具有借鉴意义，后续测试人员可以借鉴前人写的测试用例

测试用例的编写往往是根需求编写的，那么如何根据需求来编写测试用例p>

3. 基于需求设计测试用例

在基于需求设计测试用例之前，测试人员要进行如下操作：

1. 测试人员首先要分析需求，验证需求的合理性，正确性，无二义性，并且逻辑自洽
2. 其次再是细化需求，从需求中提取出测试点，根据测试点设计测试用例

在测试人员分析需求时往往分析功能性需求和非功能性需求

3.1 功能性需求

功能性需求是为了满足软件的基本功能，往往从以下几个方面进行分析考虑

1. 从界面考虑，验证界面功能

比如QQ登陆页面，有许多的按钮对应不同的功能

2. 从业务角度考虑，把功能串起来进行测试

比如增加一条用户信息，然后是查询，修改或者删除

3. 验证功能之间的交互性，一致性

比如微信发朋友圈，你发送的内容要和微信好友在朋友圈看到的一致

4. 一个功能的多个输入

比如登陆功能，要使用不同的账 和密码进行登陆测试

5. 功能的异常测试
6. 功能的易用性，体验性的测试

主要是验证用户在使用上是否符合用户使用习惯，使用起来是否舒适等

7. 功能涉及的算法

比如滴滴打车，一个顾客叫了一个车，系统要根据某些算法算出距该顾客最近的车

3.2 非功能性需求

非功能需求是在功能性需求的基础上做一些限制，满足特定场景的需求，让用户有更好的体验，比如软件的兼容性，性能，安全性，可靠性，可移植性，易用性等

不同的软件对于非功能性的需求往往是不同的，如：

• 客户端的软件：像word，ppt，xmind，播放器对功能和要求很简单，对性能，安全性要求比较低，对软件的可移植性要求比较高，因为这些不需要联 就可以使用
• 企业软件：比如聊天软件，像飞Q，飞书，钉钉，对功能有一定要求，对兼容性，安全性，性能要求低，因为企业软件用的用户比较少
• 商业软件：像QQ，微信等，对功能，性能，安全性，可移植性，易用性要求都很高，因为商业软件使用的用户基数大

4. 设计测试用例的具体方法

设计测试用例的常用方法有：等价类，边界值，错误猜测法，场景设计法，因果图，正交法，下面就对这几种常用设计测试用例的常用方法展开具体的介绍

4.1 等价类

根据输入（特殊情况下考虑输出），把输入划分成若干个等价类，从每一个等价类当中取一个测试用例进行测试，如果这个测试用例通过，我们就说这个测试用例代表的等价类测试通过

等价类可以解决的情况

等价类有有效等价类和无效等价类

• 有效等价类：符合需求规格说明书的数据
• 无效等价类：不符合需求规格说明书的数据

注意：测试的时候有效等价类和无效等价类都得测试

示例：注册 易邮箱时，针对账 和密码设计测试用例

• 卡插反：提示无法识别，重新正确插入，操作正常的情况下可以取款成功
• 卡消磁：提示无效卡，无法取款
• 卡锁定：提示用户被锁定，请解锁后重新操作
• 密码输入为空：提示请输入正确密码，输入正确密码取款成功

4.5 因果图法

因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系，因果图法是借助图形来设计测试用例的一种系统方法，

使用场景：当输入有多个，并且不同的输入组合对应着不同的输出，这个时候我们可以用因果图来进行测试用例的分析，根据分析的结果来设计测试用例

因果图的几种关系

恒等：输入为真，输出为真

如何使用因果图法来设计测试用例p>

1. 分析所有的输入和输出
2. 找出输入和输出之间的逻辑关系
3. 根据输入和输出画出因果图
4. 根据因果图画出判定表
5. 根据判定表去设计测试用例

示例：淘宝618活动，订单已提交，并且购物金额大于300或者有红包，则有优惠，否则无优惠

1. 分析所有的输入和输出

输入：订单已提交，购物金额大于300，有红包
输出：有优惠，没优惠

2. 找出输入和输出之间的逻辑关系

订单已提交，购物金额大于300，有红包，有优惠
订单已提交，购物金额小于300，有红包，有优惠
订单已提交，购物金额大于300，没红包，有优惠
订单已提交，购物金额小于300，没红包，没优惠
订单未提交，没优惠

3. 根据判定表，写测试用例

订单已提交，金额大于300，有红包，有优惠
订单已提交，金额大于300，没红包，有优惠
订单已提交，金额小于300，有红包，有优惠
订单已提交，金额小于300，没红包，没优惠
订单没提交，金额大于300，有红包，没优惠
订单没提交，金额大于300，没红包，没优惠
订单没提交，金额小于300，有红包，没优惠
订单没提交，金额小于300，没红包，没优惠

4.6 正交法

根据正交法从大量的测试数据中，选取出最优的数据组合，根据最优的数据组合的结果来衡量整个测试的输出结果

正交法的目的是为了

5. 测试用例的粒度

测试用例的粒度指测试用例编写的

测试用例不能写的过于复杂和过于简单

• 过于复杂：

测试用例写得过于复杂或详细，会带来两个问题，一个是效率问题，另一个是维护成本问题，还有如果测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维

• 过于简单：

测试用例写的过于简单，则可能失去了测试用例的意义，设计过于简单的测试用例其实并没有真正的进行设计，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已，测试用例设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试

测试用例的粒度应该介于两者之间，具体设计应该根据项目的实际情况，测试资源的情况来决定应该设计出何等粒度的测试用例