测试学习9

如何准备测试数据

• 从创建测试数据的维度看，测试数据准备的方法主要可以分为四类：
  • 基于GUI操作生称数据
  • 通过API调用生成测试数据
  • 通过数据库操作生成测试数据
  • 综合运用API和数据库的方式生成测试数据

基于GUI操作生成测试数据

• 是最原始的创建测试数据的方法，简单来说，就是采用E2E的方式来执行业务场景，然后生成数据的方法
• 如：测试用户登陆功能，首先准备一个已经注册的用户，可以通过GUI界面注册一个新用户完成登陆功能测试
• 这个方法的优点是简单直接，在技术上没有任何复杂性，而且创建的数据完全来自真实的业务流程，可以最大程度保证数据的正确性；缺点也很明显，主要体现在以下四个方面：

1，创建测试数据的效率非常低，一次GUI业务操作只能创建一条数据，基于GUI操作的执行过程比较耗时
2，基于GUI的测试数据创建方式不适合封装成测试数据工具。由于测试数据的创建都是通过GUI操作实现的，所以把这种方法封装成测试数据准备工具的过程，其实就是开发GUI自动化测试用例，无论是开发工作量还是执行效率，把基于GUI操作的测试数据创建方法封装成测试数据的准备工具都不是最佳选择
3，测试数据成功创建的概率不会太高。测试数据准备的成功率受限于GUI自动化执行的稳定性，任何界面的变更都有可能引发数据创建失败
4，会引入不必要的测试依赖。如：测试对象是用户登陆，通过GUI页面操作准备这个已经注册的用户，需要首先保证用户注册功能没有问题

• 鉴于以上四个原因，实际测试过程中，很少直接使用基于GUI操作生成测试数据。GUI操作生成测试数据的方法一般只适合手工测试，因为自动化测试中使用这种数据准备方法，基本上要开发一个完整的GUI自动化测试用例，代价太大
• 这种方法更重要的应用场景是，帮助我们找到创建一个测试数据过程中，后端调用了哪些API，以及修改了哪些数据库的业务表，是 '通过API调用生成测试数据’和 '通过数据库操作生成测试数据’这两种方法的基础

通过API调用生成测试数据

• 是目前主流的测试数据生成方法。当我们通过操作GUI界面生成测试数据时，实际的业务操作往往是由后端的API调用完成的，所以我们完全可以通过直接调用后端API生成测试数据
• 为了避免在创建测试数据时过于在乎实际细节的问题，在实际工程中，往往会把调用API生成测试数据的过程封装成测试数据准备函数
• 如何知道操作调用了哪些后端API

1，直接问开发人员
2，如果有一定代码基础，可以直接阅读源代码
3，在一个你可以独占的环境上执行GUI操作创建测试数据，与此同时监控服务端的调用日志，分析这个过程到底调用了哪些API

• 通过API调用生成测试数据的方法，优点主要体现在以下几个方面：

可以保证创建的测试数据准确性，原因是使用了和GUI操作同样的API调用
测试数据准备的执行效率更高，因为该方法跳过了耗时的GUI操作
把创建测试数据的API调用过程，封装成测试数据函数更方便，因为这个调用过程的代码逻辑非常清晰
测试数据的创建可以完全依赖API的调用，当测试数据的内部逻辑有变更时，由于此时API内部的实现逻辑也会由开发人员同步更新，所以我们依旧可以通过调用API来得到逻辑变更后的测试数据，这个过程对使用来说是完全透明的

• 但是这种方法也有缺点，主要体现在

1，并不是所有测试数据创建都有相应的API支持，也就是说，并不是所有的数据都可以通过API调用的方式创建，有些操作还必须依赖数据库的CRUD操作，那么这时，就不得不在测试数据准备函数中加入数据库的CRUD操作生成测试数据了
2，有时，创建一条业务线上的测试数据，往往需要按一定的顺序依次调用多个API，并且会在多个API调用之间传递数据，这也无形中增加了测试数据的准备函数复杂性
3，虽然相比GUI操作方式，基于API调用的方式在执行速度上已经得到了大幅提升，并且还可以很方便实现并发执行(jmeter/locust)，相比需要创建海量数据的场景，还是会力不从心

• 因此，业界往往还会通过数据库的CRUD操作生成测试数据

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

• 也是主流的测试数据生成方法，实现的原理很简单，就是直接通过数据库操作，将测试数据插入到被测系统的后台数据库中
• 常见的做法是，将创建数据需要用到的SQL语句封装成一个个的测试数据准备函数，当我们需要创建数据使，直接调用封装好的函数即可
• 这么做的前提是，需要知道前端用户通过GUI操作注册新用户时，到底修改了哪些数据库的业务表