一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第8天，点击查看活动详情。 准备测试数据是我们测试过程中非常重要的一环，不管你是哪种类型的测试，都避不开。通常，我们有 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 创建数据，然后去数据库修改这个数据，增加国籍这个字段的值就好了。
随着现在系统服务引入的其他中间件也越来越多，可能还需要涉及到缓存、消息队列的数据创建，届时再进行分享。
