关于测试数据，除了创建的方法之外，另一个重点就是应该在什么时机创建这些测试数据。
比如，是在测试用例中实时创建测试数据，还是在准备测试环境时一下子准备好所有的测试数据呢？
哦对了，处理测试数据问题还高频出现在面试当中。
一、准备测试数据的痛点
- 某些场景下，创建所需的数据往往会耗时较长，从而使得测试用例执行的时间变长。
- 对于事先批量生成的数据，就有可能出现在测试用例执行时，这些数据因为被修改而无法正常使用的情况。
- 在微服务架构下，测试环境本身的不稳定，也会阻碍测试数据的顺利创建。
选择在不同的时机创建测试数据，就是为了解决准备测试数据的不同痛点。
二、数据实时创建
指的是在测试用例的代码中实时创建要使用到的测试数据。
这也是我最常用的方法。比如，我有个商品列表要测试查询，我会在测试用例之前去插入对应的数据。
采用实时创建方式，都是由测试用例自己维护的，不会依赖于测试用例外的任何数据，从而保证了数据的准确性和可控性，最大程度地避免了出现“脏”数据的可能。
这里的“脏”数据是指，数据在被实际使用前，已经被进行了非预期的修改。
但是，随着软件架构的发展，以及软件发布频率的快速增长，这种方式的弊端越来越明显：
1. 实时创建测试数据比较耗时
在测试用例执行的过程中实时创建测试数据，将直接导致测试用例的整体执行时间变长。
2. 测试数据本身存在复杂的关联性
很多时候你为了创建一个你需要使用的业务数据，往往需要先创建一堆其他相关联的数据，越是业务链后期的数据，这个问题就越严重。
比如，创建订单数据。由于创建订单的数据准备函数需要提供诸如卖家、买家、商品ID 等一系列的前置数据，所以就不得不先创建出这些前置数据。这样做，一方面测试数据准备的复杂性直线上升，另一方面创建测试数据所需要的时间也会变得更长。
3. 微服务依赖
现在大量的互联网产品都采用了微服务架构，很多时候测试环境并不是 100% 全部可用的状态。
比如，注册用户和用户登录隶属于两个不同的微服务，此时注册用户的微服务恰好因为某种原因不可用，那么这时就无法成功创建这个用户，也就无法创建测试数据。因此，整个测试用例都无法顺利执行。
为了解决上面的3个问题，就要考虑事先创建测试数据了。
三、事先创建测试数据
在准备测试环境时就预先将测试需要用到的数据全部准备好，而不是在测试用例中实时创建。
优点
- 节省不少测试用例的执行时间。
- 不会存在由于环境问题无法创建测试数据而阻碍测试用例执行的情况。
虽然克服了数据实时创建的问题，但是也带来了新的问题：脏数据。
我之前创建好的数据，可能被其他人修改了，导致我不能继续用了。比如，事先创建好的用户进行登录测试，但这个用户的密码被其他人无意中修改了，导致测试用例执行时登录失败。
这些非预期的修改主要来自于以下三个方面：
- 其他测试用例使用这些测试数据，并修改了这些数据的状态。
- 执行手工测试时，看到现成的测试数据就直接用了，导致状态的修改。
- 自动化测试用例的调试过程中，修改了事先创建的测试数据。
四、综合使用
既然各种方法仍然有着自己的缺点，那么综合起来使用，用优点互相弥补对方的缺点。
可以结合项目的特性，给测试数据分为两大类：死水数据、活水数据。
1. 死水数据
指那些相对稳定，不会在使用过程中改变状态，并且可以被多次使用的数据。比如，商品分类、商品品牌、场馆信息等，这种适合使用事先创建。
但是，哪些数据属于“死水数据”并不是绝对的，由测试目的决定，不能一概而论。
2. 活水数据
指那些只能被一次性使用，或者经常会被修改的测试数据。比如，优惠券、商品本身、订单等类似的数据，这种适合使用实时创建。
二者相结合，实时创建的数据因为有了事先创建的数据支持，往往不需要从源头开始造起，可以基于现有的生成。比如，使用实时创建方式创建订单数据，可以直接使用事先创建的用户数据作为买家数据。
