PR/MR 驱动的 AI 测试平台：从代码变更到风险结论

我一直在做一个 AI 测试平台，核心思路不是”单纯生成测试用例”，而是让 Agent 参与完整链路：接收 PR/MR 事件 → 分析代码变更 → 选测试范围 → 生成或执行测试 → 真实调用目标服务做 smoke 验证 → 汇总结果产出报告。

为什么这么做

传统测试平台的痛点是：测试用例是”静态资产”，而代码是”动态变更”的。每次 PR 改了一点代码，测试同学要人工判断”这次改动影响哪些用例、要不要跑、跑哪些”——这个判断本身就是高价值的脑力劳动，但往往因为信息不对称做不准。

所以平台的核心是把”变更 → 影响 → 范围 → 验证 → 结论”这条链路自动化。

架构概览

GitHub/GitLab Webhook
        │
        ▼
   事件接入层 (FastAPI)
        │
        ▼
   Agent 编排引擎 ──► LLM 路由
        │
        ├─► 代码变更分析 (CLI 解析器)
        ├─► 影响面评估
        ├─► 测试范围选择
        ├─► 测试生成 / 执行 (Celery 异步)
        ├─► 真实服务 smoke 验证
        └─► 报告汇总

几个关键设计：

• FastAPI 后端 + React 前端 + SQLite（开发），Celery 跑异步任务
• WebSocket 推送实时进度，Agent 干到哪一步前端能实时看到
• Webhook 自动触发 + 手动执行双入口
• LLM 路由：不同任务路由到不同模型，控制成本和质量

双轨测试：生成测试 vs 真实服务测试

这是我觉得最有价值的设计。一条变更进来，会同时跑两条线：

1. 生成测试：基于变更自动生成单测/集成测试并执行
2. 真实服务测试：用最小运行配置 + OpenAPI 自动发现，动态生成按场景统计的集成测试脚本，真实调用目标服务

两条线的结果都进报告，互相印证。生成测试能快速反馈”代码本身对不对”，真实服务测试能反馈”集成起来对不对”。

报告要能下结论

测试报告最忌讳只罗列数据不下结论。平台的报告会给出：

• 业务风险结论：这次变更风险高/中/低
• 发布建议：放行 / 谨慎放行 / 阻断
• 关键证据摘要：为什么这么建议
• 建议关注的角色：比如”建议后端同学重点关注支付模块”

这样测试报告就从”一堆 pass/fail”变成了”决策依据”。

一些反思

做这个平台的过程中，我越来越觉得：

• Agent 的价值在编排，不在单点能力。单个 LLM 调用谁都会，难的是把多个步骤串成稳定可追溯的链路。
• 真实服务验证不可省。只跑生成测试容易”自欺欺人”，代码改了生成测试也跟着改，但真实服务的行为没验证。
• 报告要面向决策。技术同学看明细，但发布决策者要看结论。

后面会继续分享这个平台里几个具体模块的实现细节。