1.背景
一个测试用例基本要素包括以下 3 点：
- 前置条件，或者叫被测对象的初始状态
- 执行步骤
- 预期结果
在简单模块或单元测试中，大家对于前置条件的理解很容达成共识。但在面对一个复杂系统时，则关于前置条件容易困扰，或是因为可操作性，或是因为可界定性。
2.前置条件的组成
- 被测对象的程序版本
- 在测一个库、一个类、一个可执行程序时，版本很容易定义；但面对一个网站时，要说清楚版本不是一件容易的事情。
- 被测对象的相关数据，包括
- 数据库里的数据
- 缓存服务中的数据
- 队列中的数据
- 配置文件中的信息
- ……
- 测试环境
- 测试工具与被测对象的网络拓扑情况
- 测试工具、被测对象、通讯网络等计算、带宽、存储资源的情况
3.关于被测对象相关数据的准备
极简情况：测试一个类的方法
可以通过构造函数、借助 set 接口等来保证方法调用前，类处在一个确定的状态中。
正常情况：测试一个网站的注册功能
空库的情况下，
- 第一次执行注册 a 用户 时成功
- 第二次执行注册 a 用户时反馈失败。
此时都代表网站正常，但两次测试属于不同的测试用例，因为其系统的初始情况不一样。
为了可重复验证测试功能，需要在注册 a 用户，清除掉 a 用户的注册信息，以保证可重入性。此时，注册测试用例的前置条件中的数据要求就是，数据库中没有 a 用户的信息。
正常情况：测试列表的翻页功能
因为数据记录条数不同，导致页面显示的情况会不同。比如说：
- 空数据
- 不满一页的数据
- 10 页的数据
- 100 页的数据
此时，就需要让数据库里的数据处在不同的数据量情况下，才能进行有效测试。可选的方案包括：
- 每次测试前，人工清理和准备需要的数据
- 每次测试前，执行专用的数据生成 SQL（含清理数据）
- 在数据库里提前生成4 种数据，借助一些其他查询条件来区分。即重点测试翻页功能，其他功能就能用来辅助功能测试。
- 提前创建4 种数据库快照，按需恢复到需要的数据库状态。
4.说明
- 离开前置条件来谈测试用例执行结果，很难界定是否真是系统的 bug。
- 并不需要控制所有前置条件的一致性，一是单个测试用例只与有限的数据相关，二是控制绝对一致的成本很高，不划算。
