在 AI 逐步参与接口开发和测试的当下，自动化测试的门槛正在被不断拉低。很多过去需要反复手动操作、人工造数据的事情，现在都可以交给 AI 来处理，而 Apifox 在接口测试这件事上，也正在发生类似的变化。
在 Apifox 中，自动化测试主要围绕两类使用方式展开：「单接口测试」和「测试场景」。
如果你没有看到「单接口测试」这个模块，那是因为 Apifox 版本较旧，更新到最新版即可。
「单接口测试」展示的是「接口管理」中的所有 HTTP 接口，但功能更加聚焦，只包含测试用例、测试报告和文档三个部分，无法编辑接口本身。这样的设计可以让测试人员专注于测试用例的创建和执行。
「测试场景」则是把多个接口或用例串联起来，设置接口调用顺序和数据传递关系，用来还原一次完整的业务流程。
不论是单接口测试，还是测试场景，在 AI 的参与下，都能让接口测试逐步过渡到更自动化、更可复用的执行方式。接下来，我们就分别看看，这两种测试方式在实际使用中能帮你解决的问题。
单接口的自动化测试
单接口的自动化测试关注的是接口本身是否稳定、输入输出是否符合预期。每个测试用例都是独立执行的，重点在于把单个接口在不同数据下验证清楚。
AI 生成测试用例
在「单接口测试」模块下打开任意接口，点击 「AI 生成用例」后，AI 会根据接口参数和响应结构自动生成一组测试用例。
如果你只想生成特定的用例，也不必勾选默认类型，只要把需求直接描述给 AI，测试用例就会生成。例如，可以让 AI 生成一条“登录成功并提取 token”或“根据已有参数生成签名字段 sign 并发送”的测试用例。
更详细的描述方式，可以明确已知条件和规则，例如：
为这个接口生成一条“正向”的测试用例。 接口需要一个签名参数 sign，签名规则如下： 1. 取请求中所有非空参数（不包含 sign），按参数名 ASCII 顺序排序，按 key=value 拼接，用 & 连接，并在末尾加上密钥 SECRET_KEY。 2. 对拼接后的字符串进行 MD5 加密并转为大写，作为 sign 的值。 测试用例要求： 1. 发送请求前，前置脚本生成 sign，要有注释。 2. 将 sign 加入请求参数中发送。这样一来，AI 会完全按照你的规则生成用例，而不会出现遗漏或理解偏差。
测试数据的生成
在生成测试用例的同时，AI 还会为不同类型的用例准备对应的测试数据集，用来覆盖多种真实输入情况。
在正常业务场景的用例中，测试数据通常由多组语义上有效的参数值组成。例如在登录接口的测试中，虽然都是合法的邮箱和密码，但数据集中会包含多种常见邮箱写法，比如带点号、带加号、数字邮箱或企业邮箱等，用来验证接口在正常使用场景下的兼容性和稳定性。
而在异常或边界场景的测试用例中，测试数据则会刻意构造不符合规则的输入。例如「使用无效的邮箱格式登录，期望返回 400 错误码」这一类用例中，数据集中会包含缺少@符号、缺少域名、包含空格等不同形式的非法邮箱，用来验证接口是否能够正确识别并拦截异常请求。
测试数据的引用
在测试用例中，你可以通过{{变量名}}的方式引用这些测试数据，将变量插入到请求参数、请求体等位置。测试执行时，Apifox 会从数据集中依次取值并发起请求，从而在不重复编写用例的情况下，用不同数据多次验证同一个接口。
批量执行与测试报告
当用例和对应的测试数据都准备好之后，你可以选择多个测试用例一起执行。每个用例都会按照各自的配置独立运行，执行结果最终会统一汇总在测试报告中，方便整体查看。
不过，在真实的业务中，接口往往不是孤立存在的。当一次请求的返回结果，需要作为下一次请求的输入时，测试的关注点也就从“一个接口”转向了“一整条调用链”。这时候，就需要用到「测试场景」了。
测试场景
在真实的业务中，一个接口往往很难单独完成任务。比如登录之后才能下单，下单成功后才能查询订单详情，前一个接口的返回结果，常常会成为下一个接口的输入。这类依赖关系，用「单接口测试」很难完整覆盖。
「测试场景」关注的不再是某一个接口是否返回正确，而是一整条调用链在串联执行时，是否能够按预期走通。
把接口串成流程
在 Apifox 中，新建一个测试场景后，你可以将多个接口或已有的用例按顺序加入进来，明确每一步的执行顺序。
在流程中传递数据
当接口之间存在依赖关系时，测试场景允许你把前一步接口的返回数据，作为变量传递给后续步骤使用。比如“创建订单”接口返回的 id，可以被直接用于后续的查询或更新操作。
这种数据传递并不需要额外编写代码，而是通过变量引用的方式，把接口之间的上下游关系清晰地表达出来。
用例缺少时怎么办
在编排测试场景的过程中，往往是先把一条主流程跑顺的。比如“登录 → 创建订单 → 查询订单”，每一步对应一个已经存在的测试用例。
但在实际编排时，你可能会发现一个很现实的问题：流程里的某一步，其实还没有现成的测试用例可以直接用，或者现有用例不完全符合流程需求。
例如登录步骤，你不仅关心“是否成功”，还需要把返回的 token 提取为环境变量，供后续接口使用。但现有单接口测试用例可能只做了基础登录校验，没有配置 token 提取。
如果你不熟悉如何把返回字段提取成变量，也不懂脚本的写法。这时可以先暂停测试场景的编排，切换到该接口的「单接口测试」页面，直接把需求交给 AI，比如说明：“生成一条登录成功后提取 token 并保存为环境变量的测试用例，并包含必要的断言”。
如果需要更可控的测试用例，可以在「高级设置」里启用分步生成。
启用后，会先生成用例列表（含用例名称和描述），你可以人工修改并确认无误，再生成完整的用例详情数据。
生成后回到测试场景，这条用例就可以直接作为登录步骤使用，后续接口通过「动态值」引用 token，流程就可以继续往下编排。
如果需要在「测试场景」中使用测试数据，也可以先在「单接口测试」里让 AI 生成带“测试数据”的用例，然后通过「批量编辑」把 CSV 格式的数据集复制到测试场景中，这样子造数据就方便了很多。
通过这种方式，测试场景始终围绕“主流程怎么走”来搭建，而 AI 的作用，则扮演了随用随补的角色。哪里缺一步，就在对应接口通过 AI 生成对应的用例，然后立刻接回流程。
总结
AI 并没有改变接口测试本身要验证什么，而是降低了开始和补齐测试的成本。
在“单接口测试”阶段，它主要解决的是用例生成慢、覆盖不全的问题，让测试可以更快进入验证阶段，而不是停留在准备数据和写用例上。
当测试进入“测试场景”阶段，关注点从单个接口的正确性，转向接口之间在真实调用顺序下是否能够正常协作。
在这个过程中，测试用例并不需要一次性准备齐全。随着测试场景逐步搭建，可以随时回到单接口测试，通过 AI 补充当前场景真正需要的用例，再继续编排测试步骤。这种方式减少了无效用例的提前投入，也少一些 credit 的消耗。
整体来看，Apifox 将单接口测试、测试场景和 AI 能力放在同一条工作流中，把接口测试中最容易卡住的几个环节（写用例、准备数据、串联流程）都放到了可操作的位置上。
如果你之前对自动化测试的印象还停留在“配置复杂、上手成本高”，不妨直接在 Apifox 里从一个接口开始，生成几条用例，跑一次测试场景，很快就能感受到这种方式在实际使用中的差别。
可以前往 Apifox 帮助文档，查看更多功能说明和操作指南。如有任何问题，欢迎在 Apifox 用户群与我们交流沟通。
