谈谈测试用例中的前置条件

1.背景

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

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

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

2.前置条件的组成

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

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

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

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

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

空库的情况下,

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

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

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

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

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

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

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

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

4.说明

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