《软件测试52讲》
1、测试基础知识篇——（0~11讲）
2、GUI自动化测试篇——（12~21讲）
3、API自动化测试篇——（22~24讲）
4、代码测试篇——（25~27讲）
5、性能测试篇——（28~34讲）
6、测试数据准备篇——（35~38讲）
持续更新中~
测试数据准备篇
35——如何准备测试数据？
从创建测试数据的维度来看，测试数据准备方法主要可以分为四类：
基于 GUI 操作生成测试数据；
通过 API 调用生成测试数据；
通过数据库操作生成测试数据；
综合运用 API 和数据库的方式生成测试数据。
36——浅谈测试数据的痛点
测试数据的痛点
1、在测试用例执行过程中，创建所需的数据往往会耗时较长，从而使得测试用例执行的时间变长；
2、在测试执行之前，先批量生成所有需要用到的测试数据，就有可能出现在测试用例执行时，这些事先创建好的数据已经被修改而无法正常使用了的情况；
3、在微服务架构下，测试环境本身的不稳定，也会阻碍测试数据的顺利创建。
从测试数据创建的时机来看，主要分为 On-the-fly（实时创建）和 Out-of-box（事先创建测试数据）两类方法
On-the-fly 方法又称为实时创建方法，指的是在测试用例的代码中实时创建测试用例所要使用到的测试数据，具有数据可靠性高的优点，但是会比较耗时。
Out-of-box 方法又称为开箱即用方法，指的是在准备测试环境时就事先准备好测试需要用到的全部数据。这样可以有效缩短测试用例的执行时间，但是存在“脏”数据的问题。
根据测试数据的特性，把它们分为两大类
“死水数据”是指那些相对稳定，不会在使用过程中改变状态，并且可以被多次使用的数据。
“活水数据”是指那些只能被一次性使用，或者经常会被修改的测试数据。
“死水数据”适合用 Out-of-box 的方式，而“活水数据”适合采用 On-the-fly 的方式。
37——测试数据的“银弹”-统一测试数据平台（上）
在测试数据准备1.0 时代，准备测试数据最典型的方法就是，将测试数据准备的相关操作封装成数据准备函数。
归纳起来，这个时代的数据准备函数，主要有两种封装形式：
第一种是，直接使用暴露全部参数的数据准备函数，虽说灵活性最好，但是每次调用前都需要准备大量的参数，从使用者的角度来看便利性比较差；
第二种是，为了解决便利性差的问题，我们引入了更多的专用封装函数，在灵活性上有了很大的进步，但是也带来了可维护差的问题。
38——测试数据的“银弹”-统一测试数据平台（下）
测试数据准备的 3.0 时代
为了解决 2.0 时代跨平台使用数据准备函数的问题，我们将基于 Java 开发的数据准备函数用
Spring Boot 包装成了 Restful API，并且结合 Swagger 给这些 Restful API 提供了 GUI 界面和文档。
这样一来，我们就可以通过 Restful API 调用数据准备函数了，而且由于 Restful API 是通用接口，
所以只要测试框架能够发起 http 调用，就能使用这些 Restful API。于是，几乎所有的测试框架都
可以直接使用这些 Restful API 准备测试数据。
由此，测试数据准备工作自然而然地就发展到了平台化阶段。我们把这种统一提供各类测试数据的
Restful API 服务，称为“统一测试数据平台”。
1. 引入了 Core Service 和一个内部数据库。其中，内部数据库用于存放创建的测试数据的元数据；Core Service 在内部数据库的支持下，提供数据质量和数量的管理机制。
2. 当一个测试数据被创建成功后，为了使得下次再要创建同类型的测试数据时可以更高效，CoreService 会自动在后台创建一个 Jenkins Job。这个 Jenkins Job 会再自动创建 100 条同类型的数据，
并将创建成功的数据的 ID 保存到内部数据库，当下次再请求创建同类型数据时，这个统一测试数据平台就可以直接从内部数据库返回已经事先创建的数据。在一定程度上，这就相当于将原本的 On-the-fly 转变成了 Out-of-box，
缩短整个测试用例的执行时间。当这个内部数据库中存放的 100 条数据被逐被使用，导致总量低于 20 条时，对应的 Jenkins Job 会自动把该类型的数据补足到 100 条。而这些操作对外都是透明的，完全不需要我们进行额外的操作。