准备测试数据是我们测试过程中非常重要的一环，不管你是哪种类型的测试，都避不开。通常，我们有 4 种方法。
一、基于 GUI 操作生成
GUI 就是图形用户界面。基于 GUI 操作生成测试数据，是最原始的创建测试数据的方法。
比如，想要测试用户登录功能，那么首先就要准备一个已经注册的用户。那么就可以直接通过 GUI 界面来注册一个新用户，然后用这个新用户完成用户登录功能的测试。
优点
· 简单直接。
· 所建数据完全来自真实业务流程，最大限度保证数据准确性。
缺点
· 创建效率低：每次执行 GUI 业务操作都只能创建一条数据，而执行过程费时。
· 不适合封装复用：如果想封装GUI的创建数据操作进行复用，就相当于在开发 GUI 自动化测试用例了。无论是从开发工作量，还是从执行效率来讲，这都不是一个好的选择。
· 引入不必要依赖：比如，你的被测对象是用户登录功能，但是通过 GUI 页面操作准备这个已经注册的用户，就首先要保证用户注册功能没有问题，而这显然是不合理的。
通常来看，这种方法只用在手工测试环节。在 GUI 自动化里实现代价太大，还不够稳定。
但是，这种方式的必要性还是存在的。它可以帮助我们找到在创建数据的过程中，后端调用了哪些 API，为后续的 API 相关的工作打下基础。
二、调用 API 生成
通过 API 调用生成测试数据，是目前主流的测试数据生成方法了。
其实在我们用 GUI 操作生成数据时，背后就是各种 API 在工作，所以我们绕开繁重的 GUI 直接操作 API 岂不美哉？
而且，直接调用 API 也更容易封装成测试数据准备函数，方便复用。
获取 API
要调用 API 之前，得先知道有哪些 API：
· 直接询问开发人员，最直接。
· 如果你有一定的代码基础，可以直接阅读源代码，这个方法也可以作为直接询问方法的补充。
· GUI 操作一遍，同时观察 API 调用日志（比如，F12、日志系统）。
优点
· 可以保证创建的测试数据的准确性，因为本质与 GUI 背后调用 API 一样。
· 测试数据准备的执行效率更高，因为绕开了 GUI 操作。
· 封装成测试数据函数更方便，因为这个调用过程的代码逻辑非常清晰。
· 测试数据的创建可以完全依赖于 API 调用，就算后续逻辑有变更，你调用 API 得到的就是变更处理后的数据。
缺点
· 并不是所有的测试数据创建都有对应的 API 支持。
· 有时需要多个 API 顺序调用，增加了测试数据准备函数的复杂性。
· 虽然 API 创建效率比起 GUI 已经大幅提示，但是对于需要批量创建海量数据的场景，还是会力不从心。
因此，我们还需要通过数据库的 CRUD 操作生成测试数据。
三、通过数据库操作生成
通过数据库操作生成测试数据，也是目前主流的测试数据生成方法，弥补了上述 API 方式的一些不足。
通常我们会：
· 直接通过数据库连接工具，直接向表里添加数据，比如Navicat。
· 编写 sql 执行。
· 把 sql 编写到函数里，方便调用。
获取 相关业务表
要操作数据表，还是得先知道，要操作哪些表：
· 直接向开发人员索要使用到的 SQL 语句。
· 直接阅读产品源代码，从里面自取。
· 同样可以借助系统日志，里面通常会记录一些sql的执行记录。
优点
· 生成效率非常高。
· 适合大批量数据创建场景，比如需要百万级的测试数据。
缺点
· 很多时候，一个前端操作引发的数据创建，往往会修改很多张表，因此封装的数据准备函数的维护成本要高得多。
· 容易出现数据不完整的情况，当对于表的操作理解不全，就可能出现漏插入表数据的情况。
· 当业务逻辑发生变化时，即 SQL 语句有变化时，需要维护和更新已经封装的数据准备函数。
现在看起来，没有一个是十全十美的方法。
四、综合运用 API 和数据库的方式生成
的确，到现在没有一个是完美的方法，但是我们可以组合起来使用啊。
最典型的应用场景是，先通过 API 调用生成基础的测试数据，然后使用数据库的 CRUD 操作生成符合特殊测试需求的数据。
比如，我要创建一个用户，这个用户得有一个国籍属性。但是，创建用户的 API 生成的用户数据，是不带有国籍的。那我就先用 API 创建数据，然后去数据库修改这个数据，增加国籍这个字段的值就好了。
随着现在系统服务引入的其他中间件也越来越多，可能还需要涉及到缓存、消息队列的数据创建，届时再进行分享。