搜索、管理、维护和生成测试数据包含了测试人员30%-60%的时间。这是一个不可否认的证据，数据准备是软件测试的一个耗时的阶段
创建测试数据
创建测试数据的方法主要分为三种:
- API调用;
- 数据库操作;
- 综合运用API调用和数据库操作
对于创建数据的技术手段而言，最佳的选择是利用API来创建数据，只有当API不能满足数据创建的需求时，才会使用数据库操作的手段.(业务内部实现可能相对复杂)
基于GUI操作生成测试数据
是最原始的创建测试数据的方法.执行业务场景,然后生成数据.
优点: 简单直接,技术上没有复杂性,可以最大程度保证数据的正确性.
缺点: 创建测试数据的效率非常低.不适合封装成测试数据工具,测试数据成功创建的概率不高,会引入不必要的测试依赖
在实际的测试过程中，我们很少直接使用基于GUI的操作生成测试数据。只有 在万不得已的情况下，比如没有其他更好的方式可以创建正确可靠的测试数据时，我们才会使用这个方法
基于GUI操作生成测试数据的方法一般只用于手工测试，因为自动化测试 中使用这种数据准备方法，基本相当于要开发一个完整的GUI自动化测试用例，代价太大
这个方法更重要的应用场景是，帮助我们找到创建一个测试数 据的过程中，后端调用了哪些API，以及修改了哪些数据库的业务表，是“通过API调用生成测试数据”，以及“通过数据库操作生成测试数据”这两种方法的基础。
通过API调用生成测试数据
通过API调用生成测试数据，是目前主流的测试数据生成方法。其实，当我们通过操作GUI界面生成测 试数据时，实际的业务操作往往是由后端的API调用完成的。所以，我们完全可以通过直接调用后端API生成测试数据
为了规避在创建测试数据时过于在乎实现细节的问题，在实际工程实践中，我们往往会把调用API生成 测试数据的过程封装成测试数据准备函数
业务实现过程调用API获取方式:
- 询问开发人员
- 直接阅读源代码
- 监控服务器端的调用日志，分析过程中API调用
优点:
- 可以保证创建的测试数据的准确性
- 测试数据准备的执行效率更高
- 调用过程逻辑清晰
缺点:
- 并不是所有的测试数据创建都有对应的API支持
- 业务测试数据需要按次序调用,并且数据具有传递性,增加了准备工作的复杂性
- 对于批量创建海量数据的场景比较困难
通过数据库操作生成测试数据
直接通过数据库操作，将测试数据插入到被测系统的后台数据库中
常见的做法是，将创建数据需要用到的SQL语句封装成一个个的测试数据准备函数，当我们需要创建数 据时，直接调用这些封装好的函数即可
前提是，你需要知道操作业务时，到底修改了哪些数据库的业务表,具体获取变更SQL方式:
- 询问开发
- 阅读代码
- 监控业务表变化,ddl sql
优点: 生成效率高,可以在较短的时间内创建大批量的测试数据
缺点:
- 业务操作复杂度高,准备工作成本高
- 容易出现数据不完整的情况
- 业务逻辑变更,维护成本高
综合运用API和数据库的方式生成测试数据
最典型的应用场景是，先通过API调用生成基础的测试数据，然后使用数据库的CRUD操作生成 符合特殊测试需求的数据.
尽量使用API方式创建数据,通过DB操作对API无法直接操作的数据进行补全,调整
测试数据准备时机
- 测试用例执行过程中,创建所需的数据往往耗时较长.从而使整体测试用例执行时间变长
- 测试执行前,批量生成需要用到的测试数据,很可能出现在执行用例过程中,预先创建好的数据已经无法正常使用的情况
- 微服务架构下,测试环境本身的不稳定,也会阻碍测试数据的顺利创建
从创建的时机来讲，创建测试数据的方法主要分为两种:
- 测试用例执行过程中，实时创建测试数据，我们通常称这种方式为On-the-fly。
- 测试用例执行前，事先创建好“开箱即用”的测试数据，我们通常称这种方式为Out-of-box。
对于相对稳定的测试数据，比如商品类型、图书类型等，往往采用Out-of-box的方式以提高效率;而对于那些只能一次性使用的测试数据，比如商品、订单、优惠券等，往往采 用On-the-fly的方式以保证不存在脏数据问题。
On-the-fly
测试用例中所有用到的测试数据，都在测试用例开始前实时准备。采用On-the-fly方 式创建的数据，都是由测试用例自己维护的，不会依赖于测试用例外的任何数据，从而保证了数据的准 确性和可控性，最大程度地避免了出现“脏”数据的可能
“脏”数据是指，数据在被实际使用前，已经被进行了非预期的修改
缺点:
- 实时创建测试数据比较耗时
- 测试数据本身存在复杂的关联性
- 服务架构的调整,测试环境并不是100%处于全部可用的状态
Out-of-box
在准备测试环境时就预先将测试需要用到的数据全部准 备好，而不是在测试用例中实时创建
会产生脏数据.数据很有可能在被使用前已经发生了非预期的修改,非预期的修改主要来自于以下三个方面
- 其他测试用例使用了这些事先创建好的测试数据，并修改了这些数据的状态
- 执行手工测试时，因为直接使用了事先创建好的数据，很有可能就会修改了某些测试数据
- 自动化测试用例的调试过程，修改了事先创建的测试数据
综合运用On-the-fy和Out-of-box
根据测试数据的特性，把它们分为两大类
- 死水数据,指那些相对稳定，不会在使用过程中改变状态，并且可以被多次使用的数据.哪些数据属于“死水数据”并不是绝对的，由测试目的决定
- 活水数据,指那些只能被一次性使用，或者经常会被修改的测试数据。最典型的数据是优惠券、商品本身、订单等类似的数据
综合运用这两类方法，可以以互补的方式解决测试数据准备的很多痛点，比如测试数据准备 比较耗时、测试数据存在“脏”数据的可能，以及测试环境不稳定造成的测试数据无法创建等问题
文章链接 https://fangzongzhou.github.io/2021/01/03/计算机/软件测试/测试数据/测试数据/