读书笔记：准备测试数据

准备测试数据的基本方法
*基于GUI操作生成测试数据
*通过API调用生成测试数据
*通过数据库操作生成测数据
*综合运用API和数据库生成测试数据

1. 基于GUI操作生成测试数据
   简单的说是采用E2E的方式来执行业务场景，然后生成测试数据的方法。
   缺点：
   *创建测试数据的效率非常低
   *基于GUI的测试数据创建方法不适合封装成测试数据工具
   *测试数据很难创建成功
   *会引入不必要的测试依赖
2. 通过API调用生成测试数据
   目前主流的测试数据准备方法
   缺点：
   *并不是所有的测试数据创建方式都有对应的API
   *创建一条业务线上的数据，往往需要按一定顺序依次调用多个API，且会在多个API调用之间传递数据，增加数据准备的复杂些
   *对于需要批量创建海量数据的场景，基于API调用方式还是会力不从心
3. 通过数据库操作生成测试数据
   目前主流测试数据生成方法
   缺点：
   *一个前端操作引发的数据创建，需要修改很多业务表，因此封装的数据准备函数维护成本比较高
   *容易出现数据不完整的情况
   *当业务逻辑变化时，需要维护和更新已经封装的数据准备函数
4. 综合运用API和数据库生成测试数据
   测试准备时机：实时创建和事先创建
   实时创建缺点
   *实时创建测试数据比较耗时
   *测试数据本身存在复杂的关联性
   *来自微服务架构的挑战时：大量的互联网产品都采用微服务架构，很多时候测试环境并不是百分之百处于全部可用的状态
   事先创建方法
   在准备测试环境时预先将测试需要用到的数据全部准备好，而不是在测试用例中实时创建。
   缺点：
   *其他测试用例使用了这些事先创建好的测试数据或手工测试使用了，或者自动化脚本修改了测试数据导致成为脏数据，解决方法：将测试数据列在一个wiki页面，然后用不同的测试数据区段来分配使用对象。
   统一测试数据平台：
   测试数据准备1.0时代
   1.将测试数据准备的相关操作封装成数据准备函数
   缺点：
   *如果参数或参数是个对象很多调用起来很麻烦，但大多数情况下只要一些默认的值

测试准备2.0
2.0，测试准备函数不再暴露参数的方式进行封装，而是引入生成器模式封装
例：userBuilder.build()
userBuilder.withCountry(“us”).build();
测试数据生成策略解决以下需求：
1.出于执行效率的考虑，我们不希望每次都重新创建测试数据，而是希望可以从被测试系统的已有数据中搜索符合条件的数据
2.有时候希望是重建的
等方式我们引入build Strategy的概念：
引入：SEARCH_ONLY，CREATE_ONLY，SMART和OUT_OF_BOX四种策略
userBuilder.withCountry(“us”).withBuild Strategy(BuildStategy.Search_only).build();
测试准备数据3.0
3.0为了解决跨平台，将准备数据的函数用spring Boot 包装成 restful API，并结合swagger 提供文档。
测试准备数据4.0
解决多个开发专业团队加入使用，维护困难
解决方法：测试数据准备函数的脚手架代码，各个业务团队的开发人员只要基于提供的脚手架代码来完成测试数据函数的具体实现。脚手架代码可以按照预先定义的方式打包成JAR包，并将JAR包以动态注册的方式加入统一测试数据平台，整个过程可以通过统一测试数据平台的界面完成。思想：去中心化和平台化。