开头
很多团队想把 AI 接到测试平台里，第一反应是加一个聊天框：
输入需求，让 AI 生成测试点。
这个方向可以做 Demo，但很难真正落地。
因为一次真实发版的测试范围，不只取决于需求描述，还取决于代码变更、历史链路、覆盖率、缺陷记录、业务入口和团队执行情况。
所以，AI 精准测试系统的核心不是“AI 问答”，而是一套数据闭环。
1. 总体架构图
可以先用这张图理解整体结构：
flowchart LR
A[代码仓库 / Git Diff] --> B[变更分析]
C[Java Agent] --> D[链路采集]
E[测试执行] --> F[覆盖率采集]
D --> G[链路快照]
F --> H[覆盖率报告]
B --> I[风险分析服务]
G --> I
H --> I
J[历史缺陷 / 用例库] --> I
I --> K[AI 上下文构建]
K --> L[AI 回归推荐]
L --> M[测试执行清单]
M --> N[结果复盘 / 指标看板]
这套架构不是为了炫技，而是为了回答一个具体问题：
本次变更应该测哪里，以及现在测得够不够？
2. 变更分析层：先知道改了什么
精准测试的第一步一定是变更分析。
输入通常来自：
- Git Commit。
- Merge Request。
- 发布分支 Diff。
- 需求关联的代码变更。
输出最好不要只停留在文件级，而是尽量到类和方法级：
变更文件：OrderService.java
变更类：OrderService
变更方法：createOrder, cancelOrder
变更类型：修改
方法级变更后续才能和调用链、覆盖率、用例更精确地关联。
3. Java Agent 采集层：记录运行态事实
静态 Diff 只能说明代码发生了变化，但不能说明业务请求如何经过这些代码。
Java Agent 的价值在于记录运行态事实：
- 请求入口。
- 调用类和方法。
- 方法耗时。
- 异常信息。
- SQL、Redis、MQ 等资源访问。
- TraceId 或请求上下文。
例如一次下单请求可能形成这样的链路：
POST /order/create
-> OrderController#create
-> OrderService#createOrder
-> InventoryService#lockStock
-> CouponService#useCoupon
-> PaymentService#createPayOrder
当 InventoryService#lockStock 被修改时，平台就能知道它影响了下单链路，而不是只知道“库存服务有改动”。
4. 覆盖率采集层：确认测到了没有
覆盖率在精准测试里不是最终目标，而是证据。
我们真正关心的是：
- 本次变更方法有没有被覆盖？
- 高风险链路有没有被执行？
- 异常分支有没有被触达？
- 历史缺陷相关路径有没有回归？
因此覆盖率报告要从“总体百分比”升级为“增量覆盖证据”。
示例：
本次变更方法：PaymentCallbackService#handleCallback
覆盖状态：已覆盖
未覆盖分支：重复回调异常分支
关联历史缺陷：支付重复通知导致订单状态异常
建议：补充重复回调场景
这样的覆盖率才会直接影响测试决策。
5. 风险分析服务：把数据关联起来
有了 Diff、链路和覆盖率，还需要一个风险分析服务把它们串起来。
它可以做这些事情：
- 变更方法关联历史调用链。
- 调用链关联接口、RPC、MQ、定时任务。
- 本次测试执行记录关联覆盖率。
- 历史缺陷关联高风险模块。
- 输出风险等级和优先级。
风险分析服务不一定一开始就很复杂。早期可以用规则实现：
如果变更方法未覆盖，并且出现在核心交易链路中，则标记为高风险。
如果变更方法已覆盖，但异常分支未覆盖，则标记为中风险。
如果变更方法只影响后台查询，并且已有自动化覆盖，则标记为低风险。
规则能先跑起来，AI 再做解释和补充。
6. AI 上下文构建：决定推荐质量
AI 输出质量取决于输入质量。
不要只给 AI 一句需求描述，而要构建结构化上下文：
需求背景：支付回调逻辑调整
变更方法：PaymentCallbackService#handleCallback
影响入口：POST /pay/callback, MQ: order-status-topic
本次覆盖：主流程已覆盖，重复回调分支未覆盖
历史缺陷：重复回调曾导致订单状态回滚
当前目标：推荐本次必须回归的场景
然后要求 AI 输出固定结构：
- 变更摘要。
- 风险等级。
- 影响入口。
- 必测场景。
- 未覆盖风险。
- 需要人工确认的问题。
结构化输入 + 结构化输出，是 AI 在工程平台里可用的前提。
7. 指标看板：让团队看到价值
精准测试最终要服务团队效率和质量，所以必须有指标。
建议至少看这些：
- 增量代码覆盖率。
- 变更方法覆盖率。
- 推荐回归场景采纳率。
- 未覆盖风险关闭率。
- 回归测试耗时变化。
- 缺陷逃逸率变化。
不要只汇报“接入了 AI”。管理层更关心的是：
- 回归有没有更快？
- 风险有没有更透明？
- 漏测有没有减少？
- 测试结论有没有更可解释？
8. 总结
AI 精准测试系统不是单个功能，而是一条链路：
Diff → Agent 链路 → 覆盖率 → 风险分析 → AI 推荐 → 执行复盘
其中 AI 不是起点，而是最后的解释、归纳和推荐层。
如果前面的工程事实不完整，AI 只会输出漂亮但没法执行的建议。
下一篇我会继续拆：Java Agent 在精准测试里到底能采集什么，以及采集边界应该怎么设计。
