从"人工设计"到"智能扩展"：关于自动生成测试用例的一些实践和思考
这段时间在做内部测试平台建设时，我们一直在思考一个问题：自动化测试到底怎么才能真正提效，而不是只把人工写脚本这件事搬到平台上？
回头看，很多团队在自动化建设初期，都会先解决"能跑"的问题，比如接口管理、环境管理、用例维护、批量执行、定时巡检、结果通知等。这些能力当然很重要，但做久了会发现，自动化真正的瓶颈，往往不是"执行能力不够"，而是测试用例生产效率不够、覆盖扩展能力不够、测试设计越来越依赖个人经验。
所以最近我们把一个重点放在了"自动生成测试用例"这件事上，也越来越觉得，这可能会是测试平台下一阶段最值得投入的方向之一。
一、为什么自动生成测试用例值得做
在实际项目里，大家都知道写测试用例并不是简单的"补几个参数"。一个完整的测试用例设计，通常要考虑很多问题：
- 这个接口主要的业务目标是什么？
- 正常输入有哪些典型组合？
- 边界值和异常值应该怎么覆盖？
- 哪些字段是强约束，哪些字段是弱约束？
- 上下游接口依赖关系是什么？
- 哪些历史缺陷需要回归覆盖？
这些工作本质上都属于测试设计，而测试设计往往既花时间，又强依赖经验。项目节奏快的时候，很容易出现几种情况： - 有接口定义，但没有及时补齐测试用例
- 有测试用例，但只覆盖主干路径
- 正常场景覆盖了，异常场景不完整
- 单接口测了，但真实业务链路没串起来
- 每次新增接口，都要重复做一轮基础设计
这也是为什么很多自动化平台虽然已经有了执行能力，但整体收益还是不够明显。因为如果测试用例的供给跟不上，执行能力再强，平台能发挥出来的价值也有限。
二、我们理解的"自动生成测试用例"不只是生成一段脚本
很多人提到自动生成测试用例，第一反应可能是：根据接口文档自动生成一个请求模板，再附带几个断言。这当然算一种生成，但如果只停留在这个层面，价值其实有限。
我们更希望做的，是把自动生成测试用例分成几个层次来看：
1. 基础层：生成可执行的接口测试骨架
这是最基础的一层。比如根据 YApi 的接口定义，自动生成：
- 请求方法
- 路径
- 请求头
- Query 参数
- Body 参数结构
- 默认断言（状态码、响应时间、基础字段校验）
这一层解决的是"从 0 到 1"的问题，让一个接口至少可以快速进入可执行状态。
2. 扩展层：自动补齐多种输入组合
真正提升覆盖率的，不是生成一个样例，而是生成一组有代表性的测试场景。比如：
- 必填字段齐全的正常场景
- 非必填字段缺失场景
- 边界值场景
- 枚举值组合场景
- 空值 / null / 非法类型场景 超长、超范围、格式错误场景
如果只生成一个"happy path"，自动化的意义会比较有限；但如果平台能自动扩展多组有针对性的入参，测试覆盖价值就会明显提升。
3. 场景层：生成更贴近业务流程的链路用例
接口不是孤立存在的。很多实际问题都出现在多接口串联的流程里，比如登录、下单、支付、审批、状态流转等。
所以我们觉得，自动生成测试用例的下一步，不能只停留在单接口，而是要逐步探索：
- 前置接口生成的数据，能不能自动作为后置接口输入
- 多接口上下游参数依赖，能不能自动识别
- 常见业务主链路，能不能自动拼装为端到端场景
这个方向一旦能做起来，平台的自动化能力会从"接口验证"走向"业务链路验证"。
三、基于当前平台，我们觉得最值得推进的几个方向
结合现在平台已有能力，比如 YApi 差异识别、自动化执行、定时巡检、准入检查、结果通知等，自动生成测试用例这块，我觉得可以重点往下面几个方向推进。
1. 基于 YApi 入参定义，自动组合更多正常场景
现在很多接口文档已经有比较完整的参数结构，这本身就是很好的生成基础。后续可以利用 AI 理解参数间关系，自动组合更丰富的正常输入场景，而不是只生成一个默认请求。
比如一个创建订单接口，AI 可以基于字段定义自动扩展出：
- 最小必填参数场景
- 全字段场景
- 不同业务类型组合场景
- 不同支付方式 / 发货方式组合场景 不同用户类型下的合法参数组合
这类能力的价值在于，它能帮助测试更快补齐"主路径覆盖"，尤其是在新接口、新需求较多的情况下，能明显减少重复性设计工作。
2. 自动生成异常入参与异常用例
从测试角度看，很多线上问题并不是"正常逻辑完全跑不通"，而是异常输入处理不完善。比如：
- 必填参数缺失
- 参数类型错误
- 枚举值非法 数值超范围
- 字段长度超限 特殊字符 / 空值 / null 值处理异常
所以我们认为，自动生成测试用例不能只生成正常场景，更应该重点补齐异常场景。
而且异常用例不只是"请求失败"这么简单，还应该带上预期校验，例如： - 是否返回正确 code 码
- 是否返回合理错误提示
- 是否符合统一错误码规范
- 是否存在不该通过却通过的情况
如果这部分能做好，对平台提升覆盖质量会很有帮助，因为这正是人工最容易漏、但业务风险又比较高的一块。
3. 结合历史缺陷和已有用例，做更聪明的生成
单看接口文档，很多时候只能生成"结构正确"的测试用例；但真正有价值的测试设计，通常还会参考历史问题。
比如某个接口以前经常出：
- 时间格式兼容问题
- 金额精度问题
- 状态流转问题
- 空列表 / 空对象处理问题 并发更新问题
如果平台后续能结合历史缺陷、历史失败记录、已有高价值用例去辅助生成，那自动生成出来的用例就不再只是"格式正确"，而会更贴近真实风险点。
这个方向本质上是在做一件事：把团队历史经验沉淀回平台，再反哺后续测试设计。
4. 探索 N2N 多接口串行场景的自动化扩展
这是我觉得挑战大，但也很值得探索的方向。
因为单接口测试解决的是局部问题，而很多业务系统真正有价值的测试，其实在流程里。比如：
- 创建数据 -> 查询数据 -> 修改数据 -> 审核数据
- 用户注册 -> 登录 -> 下单 -> 支付 -> 查询订单
- 配置变更 ->生效校验 -> 状态确认 -> 结果回写
如果平台后续能够基于接口依赖关系、字段传递关系、典型业务主链路，尝试自动生成串行场景用例，那么自动生成测试的价值会被放大很多。
当然这件事不容易，因为它不再只是"参数补全"，而是要做更深的业务理解和依赖推断。但也正因为难，一旦做出来，平台差异化会很明显。
5. 从"生成用例"走向"生成断言"
现在很多自动生成测试用例，只关注请求部分，断言还是比较弱，通常只校验状态码、响应时间、字段存在性。但从真实测试角度看，断言的质量往往决定了这个用例有没有价值。
所以后续我觉得可以进一步探索：
- 根据接口语义自动生成关键字段断言
- 根据业务特征生成状态断言
- 结合数据库 / 缓存 / 消息队列做结果断言
- 对异常场景自动生成 code码和错误文案断言
也就是说，未来更理想的方向不是"生成一个能跑的请求"，而是"生成一个有测试价值的完整用例"。
四、自动生成测试用例真正落地时，需要注意什么
这个方向很值得做，但我觉得也不能过度乐观。因为自动生成测试用例并不意味着"可以完全替代人工测试设计"，至少现阶段还做不到。
它更适合解决的是：
- 提升基础用例产出速度
- 自动补齐常规覆盖 帮助发现明显遗漏
- 降低自动化接入门槛
- 让测试从重复性设计中抽出来，更多关注高风险场景
真正高价值的复杂业务判断、策略判断、边界判断，依然需要人工参与。
所以我比较认同一种定位：
自动生成测试用例，不是替代测试，而是放大测试设计能力。
平台负责提供基础生产力，AI 负责辅助扩展和启发，测试同学负责做业务判断、质量把关和重点场景补强。这样更现实，也更容易真正落地。
五、对测试平台下一阶段的一点期待
如果从平台演进角度看，我觉得自动生成测试用例会是一个非常关键的能力。因为它刚好连接了几个核心环节：
- 上游连接接口文档、接口变更、历史资产
- 中间连接测试设计、测试覆盖、断言生成
- 下游连接自动执行、准入判断、缺陷闭环
一旦这条链路做顺了，平台就不只是"跑已有用例"，而是开始具备"持续生产测试能力"的潜力。
我自己对下一阶段比较期待的，是把这件事往三个层次推进： - 先把基础生成做稳：根据 YApi 快速生成结构完整、可执行的基础接口用例
- 再把覆盖扩展做深：自动生成正常 / 异常 /边界场景，提高覆盖广度
- 最后把业务场景做透：探索 N2N 串行流程、业务断言、缺陷归因等更高阶能力
如果能走到这一步，测试平台的角色就会发生明显变化。它不再只是承载自动化资产，而会越来越像一个真正参与测试设计、质量判断和风险控制的质量工程平台。
六、结语
过去我们说自动化测试，更多是在讨论"怎么把测试脚本跑起来"；现在再看，真正值得投入的方向，是"怎么让平台持续产出更有价值的测试用例"。
自动生成测试用例不是一个简单的功能点，它背后对应的是测试生产方式的变化：
从依赖人工重复设计，逐步走向平台化沉淀、智能化扩展、持续化演进。
这件事肯定不会一蹴而就，但我觉得值得持续投入。因为一旦做成，它带来的不只是效率提升，更是测试能力边界的扩大。