测试数据的准备、痛点及解决方案

最近看了几篇关于测试数据的文章，在此总结记录一下。文章尾部为阅读的原文，有兴趣的同学可以查看一下。

1.测试数据的准备主要有以下几种方式：

1）基于 GUI 操作生成测试数据

优点：

简单直接，无任何复杂性

缺点：

创建数据效率低

基于 GUI 的测试数据创建方法不适合封装成测试数据工具

测试数据成功创建的概率不会太高（因为非常依赖UI页面的稳定性）

会引入不必要的依赖

备注：此种生成数据方法是2）和3）的基础，所以确实有存在的意义

2）通过 API 调用生成测试数据

优点：

可以保证创建的测试数据的准确性。

测试数据准备的执行效率更高，因为该方法耗时低

把创建测试数据的 API 调用过程进行封装，方便调用

缺点：

部分数据依赖于数据库的 CRUD 操作(增删改查)

部分业务的复杂性，会增加api函数的复杂性

api生成测试数据的方式，对于需要批量创建海量数据的场景，会力不从心。

3）通过数据库操作生成测试数据

4）综合运用 API 和数据库的方式生成测试数据

在实际项目中，业界往往会综合采用 API 和数据库的方式生成测试数据，即通过 API 调用生成基础数据，然后使用数据库的 CRUD 操作进一步生成符合特殊测试需求的数据。

2.测试数据创建时机

1）On-the-fly（实时创建）

采用On-the-fly方式创建的数据，都是由测试用例自己维护的，不会依赖于测试用例外的任何数据，从而保证了数据的准确性和可控性，最大程度地避免了出现“脏”数据的可能。

弊端：

实时创建测试数据比较耗时。

测试数据本身存在复杂的关联性。

微服务架构的调整，由于api不可用会导致造数失败

2）Out-of-box（事先创建测试数据）

Out-of-box方法，又称开箱即用方法，指的是在准备测试环境时就预先将测试需要用到的数据全部准备好，而不是在测试用例中实时创建。因此，我们可以节省不少测试用例的执行时间，同时也不会存在由于环境问题无法创建测试数据而阻碍测试用例执行的情况。

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

非预期的修改主要来自于以下三个方面：

其他测试用例使用了这些事先创建好的测试数据，并修改了这些数据的状态；

执行手工测试时，因为直接使用了事先创建好的数据，很有可能就会修改了某些测试数据；

自动化测试用例的调试过程，修改了事先创建的测试数据；

业内有些公司会将所有事先创建好的测试数据列在一个 Wiki 页面，然后按照不同的测试数据区段来分配使用对象。

3）综合运用 On-the-fly 和 Out-of-box

为了充分利用 On-the-fly 和 Out-of-box 这两种方式的各自优点，并且规避各自的缺点，实际的工程实践中，往往是采用综合运用 On-the-fly 和 Out-of-box 的方式来实现测试数据的准备的。

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

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

这里需要特别说明的是，哪些数据属于“死水数据”并不是绝对的，由测试目的决定。

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

4）总结：

On-the-fly 方法又称为实时创建方法，指的是在测试用例的代码中实时创建测试用例所要使用到的测试数据，具有数据可靠性高的优点，但是会比较耗时。

Out-of-box 方法又称为开箱即用方法，指的是在准备测试环境时就事先准备好测试需要用到的全部数据。这样可以有效缩短测试用例的执行时间，但是存在“脏”数据的问题。

“死水数据”和“活水数据”的角度来看，如何综合运用上述两种方式创建测试数据：其中“死水数据”适合用 Out-of-box 的方式，而“活水数据”适合采用 On-the-fly 的方式。

3.测试数据的“银弹”- 统一测试数据平台（上）

在 1.0 时代，准备测试数据最典型的方法就是，将测试数据准备的相关操作封装成数据准备函数。

归纳起来，这个时代的数据准备函数，主要有两种封装形式：

第一种是，直接使用暴露全部参数的数据准备函数，虽说灵活性最好，但是每次调用前都需要准备大量的参数，从使用者的角度来看便利性比较差；

第二种是，为了解决便利性差的问题，我们引入了更多的专用封装函数，在灵活性上有了很大的进步，但是也带来了可维护差的问题。

所以，为了可以更高效地准备测试数据，我们即将迎来测试数据准备的 2.0 时代，拭目以待吧。

4.测试数据的“银弹”- 统一测试数据平台（下）

1）Builder Pattern 是一种数据准备函数的封装方式。

Builder Pattern 的便利性：

如果仅仅需要一个全部采用缺省参数的数据的话，你可以直接使用 TestDataBuilder.build() 得到；

如果你对其中的某个或某几个参数有特定要求的话，你可以通过“.withParameter()”的方式指定，而没有指定的参数将自动采用默认值。

2）Builder Pattern 对于新需求的使用方案：

在实际工程项目中，随着 Builder Pattern 的大量使用，又逐渐出现了更多的新需求，归纳总结为以下 4 点：

有时候，出于执行效率的考虑，我们不希望每次都重新创建测试数据，而是希望可以从被测系统的已有数据中搜索符合条件的数据；

但是，还有些时候，我们希望测试数据必须是全新创建的，比如需要验证新建用户首次登录时，系统提示修改密码的测试场景，就需要这个用户一定是被新创建的；

更多的时候，我们并不关心这些测试数据是新创建的，还是通过搜索得到的，我们只希望以尽可能短的时间得到需要的测试数据；

甚至，还有些场景，我们希望得到的测试数据一定是来自于 Out-of-box 的数据。

为了能够满足上述的测试数据需求，我们就需要在 Builder Pattern 的基础上，进一步引入 Build Strategy 的概念。顾名思义，Build Strategy 指的是数据构建的策略。

为此，我们引入了 Search Only、Create Only、Smart 和 Out-of-box 这四种数据构建的策略。这四类构建策略在 Builder Pattern 中的使用很简单，只要按照以下的代码示例指定构建策略就可以了：

UserBuilder.withCountry(“US”).withBuildStrategy(BuildStrategy.SEARCH_ONLY.build();UserBuilder.withCountry(“US”).withBuildStrategy(BuildStrategy.CREATE_ONLY).build();UserBuilder.withCountry(“US”).withBuildStrategy(BuildStrategy.SMART).build();UserBuilder.withCountry(“US”).withBuildStrategy(BuildStrategy.OUT_OF_BOX).build();

结合着这四类构建策略的代码，我再和你分享一下，它们会在创建测试数据时执行什么操作，返回什么样的结果：

当使用 BuildStrategy.SEARCH_ONLY 策略时，Builder Pattern 会在被测系统中搜索符合条件的测试数据，如果找到就返回，否则就失败（这里，失败意味着没能返回需要的测试数据）；

当使用 BuildStrategy.CREATE_ONLY 策略时，Builder Pattern 会在被测系统中创建符合要求的测试数据，然后返回；

当使用 BuildStrategy.SMART 策略时，Builder Pattern 会先在被测系统中搜索符合条件的测试数据，如果找到就返回，如果没找到就创建符合要求的测试数据，然后返回；

当使用 BuildStrategy.OUT_OF_BOX 策略时，Builder Pattern 会返回 Out-of-box 中符合要求的数据，如果在 Out-of-box 中没有符合要求的数据，build 函数就会返回失败；

由此可见，引入 Build Strategy 之后，Builder Pattern 的适用范围更广了，几乎可以满足所有的测试数据准备的要求。

3）测试数据准备的 3.0 时代

将所有的数据准备函数在SpringBoot的支持下转变为了RestfulAPI，为跨平台和跨语言的各类测试框架提供了统一的数据准备方案。

统一测试数据平台的架构设计中最重要的两个部分：

--引入了 Core Service 和一个内部数据库。其中，内部数据库用于存放创建的测试数据的元数据；Core Service 在内部数据库的支持下，提供数据质量和数量的管理机制。

--当一个测试数据被创建成功后，为了使得下次再要创建同类型的测试数据时可以更高效，Core Service 会自动在后台创建一个 Jenkins Job。这个 Jenkins Job 会再自动创建 100 条同类型的数据，并将创建成功的数据的 ID 保存到内部数据库，当下次再请求创建同类型数据时，这个统一测试数据平台就可以直接从内部数据库返回已经事先创建的数据。

在一定程度上，这就相当于将原本的 On-the-fly 转变成了 Out-of-box，缩短整个测试用例的执行时间。当这个内部数据库中存放的 100 条数据被逐渐被使用，导致总量低于 20 条时，对应的 Jenkins Job 会自动把该类型的数据补足到 100 条。而这些操作对外都是透明的，完全不需要我们进行额外的操作。

这就是测试数据准备的 3.0 时代的最佳实践了。

相关文章：

https://mp.weixin.qq.com/s?__biz=MzIyNTIzNzM3Ng==&mid=2650805744&idx=2&sn=d89f79447b3d344c2f304771fce7f3ba&chksm=f3f6751fc481fc09e9503ac2ff311b4202412380d9e8413150619c93fe38c00bbd4002d3eed8&mpshare=1&scene=24&srcid=04158wfglL0n5vECouoqiPnH#rd

https://mp.weixin.qq.com/s?__biz=MzIyNTIzNzM3Ng==&mid=2650805744&idx=3&sn=7a82a82fd8d5bf7483b771e74789dd8f&chksm=f3f6751fc481fc0945e24ce256397d58d05852eb4bd24da117e50de782500b3a2cd7f8840042&mpshare=1&scene=24&srcid=04150t80cKjyXCbC3yQyyAyj#rd

https://mp.weixin.qq.com/s?__biz=MzIyNTIzNzM3Ng==&mid=2650805744&idx=4&sn=e2d9b55a3d086e1d5eef77bb3b5ef598&chksm=f3f6751fc481fc09f5059bf8726fcb5330e374689a52126e9d052510d26b396e85580baf40ce&mpshare=1&scene=24&srcid=0415w541r3xxeTpBdo2D8TzF#rd

https://mp.weixin.qq.com/s?__biz=MzIyNTIzNzM3Ng==&mid=2650805744&idx=5&sn=27f52d70961aeb22e3d68d94e80ab2d1&chksm=f3f6751fc481fc0913c961c49d877e1cfcd1b0b4c2be37c28c4643a0f3906128ed5e5f178d0d&mpshare=1&scene=24&srcid=0415EHb3RrydihPgMZLGtiu1#rd