零数据跑通全流程：测试智能体如何自动生成可执行用例

一位开发者用四个多月时间打造了测试智能体，并录屏展示从空系统到测试报告的全过程。这条视频最值得关注的地方不在于功能罗列，而在于它回答了一个行业普遍疑虑：AI生成的测试用例，到底能不能直接跑起来？

从零开始：项目、环境与接口导入

演示从一个完全清空的系统开始——所有数据表被清空，没有项目、没有环境、没有接口。第一步创建项目并选择接口自动化类型，随后创建环境。出于隐私考虑，环境信息被隐藏，但流程本身没有跳过任何环节。

接口导入支持两种方式，演示选择了读取本地报文进行解析。上传一份报文后，系统解析出两个接口。作者选中首页接口直接发送请求，状态码返回200，响应数据正常，证明项目与环境配置无误。

这一步看似基础，却是一个容易被忽略的验证点：许多AI测试工具在接口导入后并不保证环境连通性，而这里把「发一次真实请求」作为进入用例设计前的检查动作。

用例设计：参数约束识别是关键

选中接口后点击「设计测试用例」，系统开始一系列操作：锁定接口、查询对应数据表、提取请求参数。首次运行时，它会自动识别每个参数的中文含义、数据类型和取值范围，并要求人工确认一次。

演示中可以看到具体识别结果：某个枚举字段被识别为只有1和2两个值，状态字段被限定在1到12的范围内，密码长度限制为6到8位，手机号字段则标记为需要符合真实号码格式。

这种约束识别直接决定了生成数据的质量。作者特别强调，系统生成的手机号是符合规范的真实号码，不是随机数字；用户名等字段的取值也严格落在预设区间内，而非随意填充。用例覆盖了正交组合、边界值、选项缺失、必填缺失等测试方法，并为每条用例标注优先级。

正交组合是一种系统化的测试用例设计方法，核心思想是用最少的用例覆盖多个输入参数之间的所有两两交互组合（pairwise），而非穷举全部笛卡尔积。例如三个参数各有3、4、5种取值，全组合需60条，正交表可压缩到十余条仍保证任意两参数的所有取值对至少出现一次。在AI生成测试数据的场景中，正交组合能显著降低用例数量、控制执行成本，同时避免因随机采样导致某些参数组合长期未被覆盖。它通常与边界值分析配合使用：边界值负责验证取值范围的两端与临界点，正交组合负责验证参数之间的交互影响，二者结合才能在用例数量与覆盖度之间取得平衡。

断言与数据库校验：不止于请求参数

更值得关注的是断言层。每条生成的用例包含五层断言，第一层是对最外层状态码的校验，此外还有对响应体的断言和对数据库的断言。

演示中的接口同时包含新增和编辑操作，系统针对这两种场景分别生成了对应的断言逻辑。对于用户名唯一性这类业务约束，系统会自动生成删除操作——因为如果本次新增使用了某个用户名，下次再用它新增就会触发重复提示，删除动作保证了用例之间的数据独立性。

换句话说，生成的用例不需要人工修改请求参数、优先级、具体数值或断言，开箱即可执行。

用例之间的数据独立性是自动化测试能否稳定复跑的前提。若多条用例共用同一个用户名、订单号或唯一键，先执行的用例写入数据后，后续用例再使用相同值就会触发唯一性冲突，导致本应通过的用例失败——这类失败被称为「用例污染」，与产品缺陷无关，却会严重干扰对测试结果的判读。常见解法有三种：一是如文中所述，在用例内自动生成删除或回滚操作，执行后清理数据；二是为每次执行生成带时间戳或随机后缀的唯一值；三是通过测试夹具（fixture）在用例前后统一准备与销毁数据。对于涉及数据库写入的接口，断言层还需校验落库结果，否则仅校验HTTP响应体可能漏掉「接口返回成功但数据未正确持久化」的问题。

批量评审：让问题在入库前暴露

生成之后进入评审环节。32条用例被分成每组10条批量执行，左侧实时显示执行状态，最终给出汇总结果。

评审结果分为三类：直接通过可入库的9条、存在缺陷的用例、以及需要人工确认的用例。演示中出现了一条失败用例，原因是参数约束模型被错误设置为「用户已存在」，导致生成的请求参数与预期不符——这恰好说明评审机制的价值：它把模型配置错误在入库前就暴露出来，而不是等到测试执行阶段才发现。

作者指出，这类问题通常源于首次设计约束模型时的误操作，修正后重新生成即可。

评审门禁（review gate）指在测试资产正式进入用例库之前设置的人工或自动审核环节，目的是把低质量用例拦截在上游。AI生成的用例一旦直接入库并进入回归套件，错误用例会持续产生误报，团队逐渐丧失对结果的信任，最终整套用例被弃用。批量评审通常关注三类问题：生成所依赖的配置（如参数约束模型）是否正确、用例预期值是否与业务规则一致、用例之间是否存在数据依赖或执行顺序耦合。把评审前置到入库前，修复成本远低于在测试执行阶段排查误报，也便于将发现的问题反向修正约束模型，使后续生成质量持续提升。

执行验证：未经修改的用例直接运行

评审通过后，9条用例直接入库，作者强调整个过程中没有对任何一条用例做过手动修改。随后直接运行测试。

执行结果逐条展示期望值与实际值，失败用例会附带实际返回结果作为证据。从创建项目、配置环境、解析接口、设计用例、评审到执行测试，全流程走通，且在用例设计阶段没有做人工编辑。

作者最后对比了市面同类工具：之前的工具生成用例后往往还需要人工编辑请求参数、优先级和断言，而这个系统的差异在于把这些环节尽量自动化。约束模型只需在首次设计时确认一次，后续同类接口的用例生成会直接复用，不再重复弹出。

这个演示说明了什么

AI生成测试用例的常见质疑是「生成容易执行难」——参数不合规、断言缺失、用例之间互相污染，都会导致生成的用例沦为摆设。这个演示针对的正是这一痛点：约束驱动的数据生成保证了参数合法性，多层断言覆盖了响应和数据库，删除操作解决了用例独立性问题。

当然，单接口场景的演示还不足以证明复杂业务链路下的表现，约束模型的准确性也依赖首次人工确认的质量。但至少在这个流程里，从零数据到可执行用例的链路是闭合的。