绿色的状态码也会“撒谎”。你的 POST /orders 接口返回了 201 Created，响应体看起来完美无缺，测试也顺利通过了。但数据行真的以正确的状态写入数据库了吗？库存数量更新了吗？如果测试只读取 HTTP 响应，那它验证的只是 API 声称了什么，而不是系统实际做了什么。要弥补这个差距，你必须直接查看数据库。

这正是数据库查询在测试场景中派上用场的地方。你可以在请求前预置一个已知的数据状态，发起请求，然后查询数据表，确认磁盘上的真实数据是否如预期。Apifox 通过“数据库连接”和“数据库操作”处理器内置了这一能力，你可以在同一个测试场景中，将 SQL 或 NoSQL 命令作为步骤来运行，无需额外的脚本去衔接。关于如何用 Apifox 构建测试场景的基础知识，官方指南有详细说明，这里就不展开了。

数据库操作在测试中的价值

一个从不触碰数据库的 API 测试，本质上就是个黑盒。它完全信赖响应内容。大多数情况下这没问题，但有趣的 Bug 往往藏在 API 返回内容与持久化内容之间的差异里：状态字段从未切换、外键指向了空处、逻辑删除变成了物理删除。

数据库步骤能帮你实现纯 HTTP 测试无法做到的几件事：

• 预置精确的初始状态，让测试不受残留数据干扰。
• 根据事实真相进行断言，通过读取 API 声称已写入的数据行来验证。
• 提取真实值，从数据库中取出一个值并传递给下一个请求，这样你的测试使用的是服务器实际生成的 ID，而不是猜测的值。

Apifox 把这个功能分成了两部分。首先，在“设置 > 数据库连接”下创建一个可复用的连接。然后，将“数据库操作”步骤作为前置操作（在请求前运行）或后置操作（在请求后运行）添加到请求中。一个连接可以在项目中的每个场景里重复使用。

规划前需要留意覆盖范围。MySQL、SQL Server（2014 及更新版本）、PostgreSQL 和 Oracle 在免费版中可用。ClickHouse、MongoDB 和 Redis 则是付费功能。MongoDB 和 Redis 的官方文档都明确指出，连接这些数据库需要付费计划。因此，下面的 MySQL 演练适用于免费版，而 Mongo 和 Redis 部分则需要付费。

步骤 1：创建数据库连接

打开“设置 > 数据库连接”，点击右上角的 + 新建。选择你的数据库类型，然后填写连接信息：

• 数据库地址（例如 db.staging.internal 或 127.0.0.1）
• 端口（MySQL 默认为 3306）
• 用户名 和 密码
• 数据库名（例如 shop）

填写完成后，点击“测试连接”确认连通性，然后保存。

步骤 2：在测试场景中添加数据库操作

进入一个测试场景，点击请求步骤旁的“+”号，选择“数据库操作”。在编辑器中选择你刚创建的连接，然后编写 SQL 语句。例如，在请求完成后，通过一个后置操作来验证数据：

SELECT status FROM orders WHERE order_id = '{{order_id}}';

这里使用了变量 {{order_id}}，它可能来自前一个请求的响应。然后，你可以通过“提取结果到变量”功能，将查询结果中的字段赋值给一个新变量，用于后续的断言或请求。

MySQL 示例

假设你有一个创建订单的接口，你想验证它是否真的写入了数据库。在请求后添加一个“数据库操作”后置步骤，运行如下 SQL：

SELECT * FROM orders WHERE order_id = '{{order_id}}';

然后，使用“提取结果到变量”并设置 JSONPath 为 $[0].status，将结果中的 status 字段值提取出来。接着，你可以添加一个断言步骤，验证这个变量是否为 pending。这样，你就从数据库层面确认了 API 的行为。

MongoDB

MongoDB 的连接配置类似，支持使用 Connection String 或单独的主机、端口和凭据。Apifox 会自动将匹配的 ID 字符串转换为 ObjectId，所以无需手动处理。当你需要 BSON 类型时，可以使用辅助函数 ISODate(...)、ObjectId(...)、NumberDecimal(...) 和 NumberLong(...)。MongoDB 官方文档详细说明了这些函数如何映射到存储值。

需要提醒的是，MySQL 流程中描述了将 JSONPath 提取到变量的方法，但 MongoDB 和 Redis 的文档并未明确说明相同的提取结果到变量的机制。因此，在依赖该功能前，最好先在控制台验证查询结果。

Redis

Redis 连接需要填写 Host、Port、Password 和 Database Index。可视化操作使用操作类型下拉菜单，支持 GET、SET 和 DELETE。要读取缓存的会话，选择 GET 并将 Key 设为类似 user:session:123 的值。对于下拉菜单未涵盖的任何命令，可以使用“运行 Redis 命令”标签页来执行任何有效命令：

KEYS user:*

这样，你就能确认 API 应该写入的缓存条目，或在测试前清除缓存，以验证接口是否会重新填充它。

高级变体与限制

在构建大型测试套件前，有几个点值得了解：

• 循环：当你在 ForEach 步骤中遍历行时，使用 {{$.StepID.element.field}} 引用当前循环项，其中 StepID 是循环步骤的实际编号。这在每次迭代中断言一行数据时非常方便。
• 基于数据库值的分支：提取状态字段，然后根据它路由场景的剩余部分。将数据库读取与测试场景中的条件逻辑相结合，能让测试在数据状态为 paid 时走一条路径，在 pending 时走另一条路径。
• 环境路由：下文会详细说明，简而言之：为每个环境定义一个连接，Apifox 会自动选择正确的连接。
• 存储过程：可视化界面无法处理存储过程这类复杂操作。请保持步骤中的 SQL 语句简单直接。
• Oracle 设置：Oracle 需要在你的机器上安装单独的 Oracle Client 才能建立连接。

按环境管理凭据

你肯定不希望测试意外触碰生产数据。Apifox 的解决方案是每个环境对应一个数据库连接。你可以创建一个 staging 连接和一个 local 连接，每个连接都有自己的主机和密码。

然后，使用右上角的下拉菜单切换环境。Apifox 会自动将场景中的每个查询路由到与当前选定环境匹配的连接。选择 staging，你的 SELECT 语句就会针对 staging 数据库运行；切换到 local，完全相同的步骤就会针对你本地的数据库运行，无需修改 SQL 或步骤。凭据随环境而异，无需在运行中手动重新配置。

由于这些凭据存储在本地且不进行同步，这也确保了生产密码不会出现在共享的云端项目中。每位工程师持有自己的凭据。

使用 Apifox CLI 自动化工作流

一旦场景在 App 中验证通过，就可以在 CI 中无头运行它，这样每次拉取请求都能重新验证数据库，而不仅仅是 HTTP 契约。安装 CLI 并进行身份验证：

npm install -g apifox-cli apifox login --with-token

然后针对选定的环境，通过 ID 运行你构建的精确场景：

apifox run --access-token $APIFOX_ACCESS_TOKEN -t -e -r cli

这里 -t 是测试场景 ID，-e 是环境 ID，-r 是报告器（cli、html 或 junit；多个报告器用逗号分隔，如 -r html,cli）。需要留意的是，数据库连接详情是本地的，因此运行器需要导出的配置才能从 CI 访问你的数据库。如果你从数据集中为场景提供行数据，数据驱动测试的相关文档展示了每一行如何运行相同的数据库断言，而调度 API 测试的相关文档则涵盖了如何定时运行，以便失败的数据库断言能像其他测试一样显现出来。

常见问题

哪些数据库是免费的，哪些是付费的？ MySQL、SQL Server（2014 及更新版本）、PostgreSQL 和 Oracle 属于免费计划。ClickHouse、MongoDB 和 Redis 需要付费计划。MongoDB 和 Redis 文档都指出其连接性是付费功能，因此在规划 NoSQL 套件之前，请先查看定价页面。

我可以在后续请求中使用数据库中的值吗？ 可以。添加一个带有数据库操作的后置操作，运行 SELECT，然后使用“提取结果到变量”功能，配合变量名和 JSONPath 表达式（如 $[0].fulfillment_ref）从第一行中隔离出字段。之后通过 {{variable_name}} 引用它。关于 HTTP 响应的相同链式调用思路，在测试步骤之间传递数据的文档中有详细介绍。

我的团队成员会自动获得我的数据库连接吗？ 不会。连接凭据存储在每个客户端的本地，不会同步到云端，每个团队成员都需要自行配置连接。这是刻意为之，为了确保生产密码不进入共享项目。

我的 MySQL 8 连接一直失败，为什么？ MySQL 8 默认使用 caching_sha2_password 身份验证插件，这可能会阻止连接。使用 ALTER USER ... IDENTIFIED WITH mysql_native_password 将用户切换为 mysql_native_password 并重新连接。

我可以运行存储过程或复杂的数据库逻辑吗？ 无法通过可视化界面实现。它支持标准的 SELECT、INSERT、UPDATE 和 DELETE 语句，但不支持存储过程等复杂操作。请保持你的测试步骤为直接的语句。

总结

数据库查询将 API 测试从“响应看起来正确”提升到了“数据实际上是正确的”。在场景内部，通过前置操作预置已知状态，通过后置操作验证持久化行，并提取服务器生成的值以链式传递到下一个请求。为每个环境设置一个连接，相同的步骤即可安全地针对 staging 或本地环境运行，无需修改。