1.背景

一个测试用例基本要素包括以下 3 点：

• 前置条件，或者叫被测对象的初始状态
• 执行步骤
• 预期结果

在简单模块或单元测试中，大家对于前置条件的理解很容达成共识。但在面对一个复杂系统时，则关于前置条件容易困扰，或是因为可操作性，或是因为可界定性。

2.前置条件的组成

• 被测对象的程序版本
  • 在测一个库、一个类、一个可执行程序时，版本很容易定义；但面对一个网站时，要说清楚版本不是一件容易的事情。
• 被测对象的相关数据，包括
  • 数据库里的数据
  • 缓存服务中的数据
  • 队列中的数据
  • 配置文件中的信息
  • ……
• 测试环境
  • 测试工具与被测对象的网络拓扑情况
  • 测试工具、被测对象、通讯网络等计算、带宽、存储资源的情况

3.关于被测对象相关数据的准备

极简情况：测试一个类的方法

可以通过构造函数、借助 set 接口等来保证方法调用前，类处在一个确定的状态中。

正常情况：测试一个网站的注册功能

空库的情况下，

• 第一次执行注册 a 用户 时成功
• 第二次执行注册 a 用户时反馈失败。

此时都代表网站正常，但两次测试属于不同的测试用例，因为其系统的初始情况不一样。

为了可重复验证测试功能，需要在注册 a 用户，清除掉 a 用户的注册信息，以保证可重入性。此时，注册测试用例的前置条件中的数据要求就是，数据库中没有 a 用户的信息。

正常情况：测试列表的翻页功能

因为数据记录条数不同，导致页面显示的情况会不同。比如说：

• 空数据
• 不满一页的数据
• 10 页的数据
• 100 页的数据

此时，就需要让数据库里的数据处在不同的数据量情况下，才能进行有效测试。可选的方案包括：

• 每次测试前，人工清理和准备需要的数据
• 每次测试前，执行专用的数据生成 SQL（含清理数据）
• 在数据库里提前生成4 种数据，借助一些其他查询条件来区分。即重点测试翻页功能，其他功能就能用来辅助功能测试。
• 提前创建4 种数据库快照，按需恢复到需要的数据库状态。

4.说明

• 离开前置条件来谈测试用例执行结果，很难界定是否真是系统的 bug。
• 并不需要控制所有前置条件的一致性，一是单个测试用例只与有限的数据相关，二是控制绝对一致的成本很高，不划算。