开头

现在很多测试平台都想接 AI。

最常见的形态是：在页面右下角加一个聊天框，让用户输入问题。

比如：

帮我生成测试用例。
帮我分析这个缺陷。
帮我总结这次测试报告。

这个功能看起来很快能上线，也容易演示。

但如果只有聊天框，AI 很难真正进入测试流程。

因为测试平台需要的不是“能聊天的 AI”，而是“能基于平台数据做决策辅助的 AI”。

1. 聊天框的问题

聊天框最大的问题是上下文缺失。

用户输入一句话：

订单取消需求怎么测？

AI 并不知道：

• 本次代码改了哪些方法。
• 这些方法影响哪些接口。
• 哪些自动化用例已经执行。
• 哪些分支没有覆盖。
• 历史上订单取消出过什么缺陷。
• 当前版本上线时间和风险边界。

没有这些数据，AI 只能输出通用测试点。

通用测试点的问题是：看起来完整，但无法指导优先级。

2. 测试平台真正需要的 AI

测试平台里的 AI，应该嵌入具体流程。

例如：

在需求评审阶段

AI 可以根据需求描述和历史缺陷，生成风险问题清单。

输出不是测试用例，而是评审问题：

• 是否涉及状态机变化？
• 是否影响已有接口兼容？
• 是否需要补充幂等逻辑？
• 是否涉及数据迁移或灰度开关？

在测试设计阶段

AI 可以根据 Diff、接口、链路和业务约束，生成测试场景。

重点是场景优先级，而不是堆数量。

在执行阶段

AI 可以根据覆盖率和执行记录，提示未覆盖风险。

例如：

支付回调主流程已覆盖，但重复回调分支未覆盖。
该分支关联历史缺陷，建议补测。

在复盘阶段

AI 可以根据链路快照、日志、异常和最近变更，辅助缺陷归因。

这比单纯“问 AI 为什么报错”更可靠。

3. AI 功能应该围绕数据按钮设计

与其做一个空聊天框，不如在关键页面放具体按钮。

例如：

• 在 Diff 页面：生成回归范围。
• 在覆盖率页面：解释未覆盖风险。
• 在缺陷页面：生成复盘摘要。
• 在测试报告页面：生成管理层摘要。
• 在用例页面：补充边界场景。

这些按钮背后都自动带上平台上下文。

用户不需要手动复制一堆信息，AI 也不会凭空猜。

4. 上下文构建比模型选择更重要

很多团队一开始就纠结用哪个模型。

模型当然重要，但在测试平台场景里，更关键的是上下文构建。

同一个模型，输入不同，结果会完全不同。

差的输入：

帮我推荐回归范围。

好的输入：

需求：订单取消逻辑调整。
变更方法：OrderCancelService#cancelOrder, InventoryService#releaseStock。
影响入口：POST /order/cancel, Job: close-timeout-order。
覆盖情况：接口取消已覆盖，定时任务未覆盖，重复取消分支未覆盖。
历史缺陷：重复取消导致库存重复释放。
输出目标：给出上线前必须补测的场景。

测试平台要做的，就是自动生成好的输入。

5. 输出也必须结构化

AI 输出如果是一大段自然语言，测试人员仍然很难执行。

建议统一输出结构：

风险等级：高/中/低
影响入口：接口、RPC、MQ、定时任务
必测场景：按优先级排序
已覆盖场景：列出证据
未覆盖风险：说明原因
补测建议：可执行动作
研发确认：需要人工判断的问题

结构化输出有三个好处：

1. 方便测试人员执行。
2. 方便平台保存和复盘。
3. 方便后续做指标统计。

6. AI 建议必须可审核

测试平台不能让 AI 直接替团队做最终决策。

更合理的定位是：

AI 给建议，人来审核，平台留痕。

每条 AI 建议最好能追溯来源：

• 来自哪段 Diff。
• 来自哪条链路。
• 来自哪条历史缺陷。
• 来自哪个未覆盖方法。

如果 AI 建议无法追溯，就很难被研发和测试负责人信任。

7. 最小可用 AI 接入方式

如果你正在做测试平台，可以先从三个按钮开始：

按钮 1：生成回归建议

输入：Diff + 历史链路 + 历史缺陷。

输出：影响入口、必测场景、风险等级。

按钮 2：解释未覆盖风险

输入：变更方法 + 覆盖率 + 业务链路。

输出：哪些未覆盖可接受，哪些必须补测。

按钮 3：生成测试报告摘要

输入：执行记录 + 覆盖率 + 缺陷 + 风险项。

输出：管理层可读的质量结论。

这三个按钮比一个泛聊天框更容易产生实际价值。

8. 总结

测试平台接 AI，不是接个聊天框就完事了。

真正有价值的 AI 测试能力，需要做到：

• 嵌入测试流程。
• 自动携带上下文。
• 输出结构化建议。
• 建议可审核、可追溯。
• 结果能沉淀到平台指标。

AI 不应该是平台旁边的玩具，而应该成为精准测试闭环中的解释层和推荐层。