文章内容来源于《软件测试52讲》

在什么时机创建这些测试数据合适呢？
比如，是在测试用例中实时创建测试数据，还是在准备测试环境时一下子准备好所有的测试数据呢。

其实，在不同的时机创建测试数据，就是为了解决准备测试数据的不同痛点。那么，准备测试数据的痛点，都体现在哪些方面呢？
1、在测试用例执行过程中，创建所需的数据往往会耗时较长，从而使得测试用例执行的时间变长；
2、在测试执行之前，先批量生成所有需要用到的测试数据，就有可能出现在测试用例执行时，这些事先创建好的数据已经被修改而无法正常使用了的情况；
3、在微服务架构下，测试环境本身的不稳定，也会阻碍测试数据的顺利创建。

一、On-the-fly（实时创建）

在测试用例的代码中实时创建要使用到的测试数据。
比如，对于用户登录功能的测试，那么在测试用例开始的部分，首先调用创建新用户的数据准备函数来生成一个新用户，接下来的测试将会直接使用这个新创建的用户。

采用 On-the-fly 方式创建的数据，都是由测试用例自己维护的，不会依赖于测试用例外的任何数据，从而保证了数据的准确性和可控性，最大程度地避免了出现“脏”数据的可能。（这里的“脏”数据是指，数据在被实际使用前，已经被进行了非预期的修改。）

缺点：

• 实时创建测试数据比较耗时
  我在测试绩效统计时，用例执行时间中，有 30%-40% 的时间花在了测试数据的实时准备上，也就是说测试数据的实时准备花费了差不多一半的测试用例执行时间。

• 测试数据本身存在复杂的关联性
  很多时候为了创建一个需要使用的业务数据，往往需要先创建一堆其他相关联的数据，越是业务链后期的数据，这个问题就越严重。
  比如，创建订单数据这个最典型的案例。由于创建订单的数据准备函数需要提供诸如卖家、买家、商品 ID 等一系列的前置数据，所以就不得不先创建出这些前置数据。这样做，一方面测试数据准备的复杂性直线上升，另一方面创建测试数据所需要的时间也会变得更长。
  为了缓解这个问题，你可以考虑将部分相对稳定的数据事先创建好，而不要采用 On-the-fly 的方式去创建所有的数据。

• 微服务架构的调整（很多时候测试环境并不是 100% 处于全部可用的状态）
  比如，为了测试用户登录功能，根据 On-the-fly 的策略，首先需要创建一个新用户。假设在微服务架构下，注册用户和用户登录隶属于两个不同的微服务，而此时注册用户的微服务恰好因为某种原因处于不可用状态，那么这时就无法成功创建这个用户，也就是无法创建测试数据。因此，整个测试用例都无法顺利执行，显然这不是我们想要的结果。

二、Out-of-box（开箱即用方法）

在准备测试环境时就预先将测试需要用到的数据全部准备好，而不是在测试用例中实时创建。
因此，我们可以节省不少测试用例的执行时间，同时也不会存在由于环境问题无法创建测试数据而阻碍测试用例执行的情况。也就是说 Out-of-box 方法可以克服 On-the-fly 方法的缺点，那么这个方式又会引入哪些致命的新问题呢？

最致命的问题是“脏”数据

比如，我们在测试用例中使用事先创建好的用户进行登录测试，但这个用户的密码被其他人无意中修改了，导致测试用例执行时登录失败，也就不能顺利完成测试了。那么，此时这个测试用户数据就成为了“脏”数据。

由此可见，这些事先创建好的测试数据，在测试用例执行的那个时刻，是否依然可用其实是不一定的，因为这些数据很有可能在被使用前已经发生了非预期的修改。

非预期的修改来自：

• 其他测试用例使用了这些事先创建好的测试数据，并修改了这些数据的状态；
• 执行手工测试时，因为直接使用了事先创建好的数据，很有可能就会修改了某些测试数据；
• 自动化测试用例的调试过程，修改了事先创建的测试数据；

为了解决这些“脏”数据，我们只能通过优化流程去控制数据的使用。
目前，业内有些公司会将所有事先创建好的测试数据列在一个 Wiki 页面，然后按照不同的测试数据区段来分配使用对象。

比如，假设我们事先创建了 1000 个测试用户，那么用户 ID 在 0001-0200 范围内数据给这个团队使用，而用户 ID 在 0201-0500 范围内的数据则给另一个团队使用。这个分配工作，要靠流程保证，那么前提就是所有人都要遵守这些流程。

但凡需要靠流程保证的一定不是最靠谱的，因为无法确保所有人都会遵守流程。也正是因为这个原因，在实际项目中我们还是会经常看到由“脏”数据引发测试用例执行失败的案例。

更糟糕的是，如果自动化测试用例直接采用硬编码的方式，去调用那些只能被一次性使用的测试数据（比如订单数据、优惠券等）的话，你会发现测试用例只能在第一次执行时通过，后面再执行都会因为测试数据的问题而失败。

所以，还需要在测试用例级别保证测试数据只被调用一次，而这往往会涉及到跨测试用例的测试数据维护问题，往往实现起来非常麻烦。
所以说，Out-of-box 方法不适用于只能一次性使用的测试数据场景。

三、综合运用 On-the-fly 和 Out-of-box

在实际的测试项目中，我们可以根据测试数据的特性，把它们分为两大类，用业内的行话来讲就是“死水数据”和“活水数据”。

死水数据：是指那些相对稳定，不会在使用过程中改变状态，并且可以被多次使用的数据。
比如，商品分类、商品品牌、场馆信息等。这类数据就非常适合采用 Out-of-box 方式来创建。

说明：哪些数据属于“死水数据”并不是绝对的，由测试目的决定。

比如，用户数据在大多数的非用户相关的测试用例中基本属于“死水数据”，因为绝大多数的业务测试都会包含用户登录的操作，而且并不会去修改用户本身的数据属性，所以这时我们就可以将用户数据按照“死水数据”处理，也就是采用 Out-of-box 的方式创建。

活水数据：是指那些只能被一次性使用，或者经常会被修改的测试数据。
最典型的数据是优惠券、商品本身、订单等类似的数据。这类数据通常在被一次性使用后状态就发生了变化，不能反复使用。那么这类测试数据，就更适合采用 On-the-fly 自维护的方式。