凌晨2点17分，我被手机震动吵醒。监控告警：用户服务响应时间P99飙到了8秒，错误率突破5%。我打开笔记本连上VPN，发现是订单服务的数据库连接池满了。翻了一下日志，罪魁祸首是一周前上线的批量退款功能——里面一个条件分支从来没测到过，导致特定组合下SQL查询没有加索引，全表扫描拖死了整个库。
这不是第一次了。这个项目是5年前的Java单体应用，50万行代码，单元测试覆盖率只有12%，而且大多是只测happy path的空壳测试。每次改代码都像拆炸弹，CI流水线里只有一个简单的mvn test，没有覆盖率门禁，没有变异测试，甚至连测试运行时间监控都没装——结果就是频繁的半夜故障。
我决定赌一把：用大模型自动生成单元测试，并且构建一个能自我完善的生成循环，目标是至少80%分支覆盖。不是那种给一个方法写死几个assert的玩具，而是能理解函数意图、生成边界用例、自动Mock依赖，并且根据覆盖率报告迭代补齐缺失用例的完整流水线。我用的是OpenAI最新模型（GPT-4o，2024年11月版本），配合JaCoCo和一套自己写的Python编排脚本，在一个真实的支付模块上跑了三个星期。结果覆盖率从12%冲到87%，顺带揪出两个隐藏了4年的bug。但中间翻车翻得比过山车还刺激——AI生成的Mock直接连上了生产数据库，差点把线上数据搅了。
30秒速览
- - 现有AI测试工具只能一次性补全，缺乏覆盖率反馈，我搭建了一个循环：解析代码→生成测试大纲→生成代码→JaCoCo覆盖率报告→反馈补充，使支付模块分支覆盖从12%冲到87%。
- - Mock生成是最危险的环节，LLM会创建真实数据库连接，导致线上数据污染；必须用K8s NetworkPolicy沙盒隔离，并禁止@Autowired/真实依赖。
- - 覆盖率报告需要被解析成未覆盖分支描述，再发给LLM补充用例，经过3~5轮迭代可稳定超过80%。
- - CI集成时加硬性门槛（覆盖率不达标阻塞MR），同时Prometheus监控全局覆盖率和测试执行时间，防止生成超时或退步。
- - 真实项目发现了两个隐藏4年的缺陷，但生成代码仍需人工review，不能完全信任。
现有AI测试生成工具为什么全跪了
Copilot只能写片段，不理解业务上下文
GitHub Copilot和JetBrains AI Assistant我都买了一年。它们对补全单行断言很顺手，但一遇到需要Mock复杂依赖链的方法就直接摆烂。比如我们的OrderService.refund()方法依赖了PaymentGateway、InventoryService、NotificationService，还依赖一个内部的RiskEngine线程池。Copilot根本不知道这些依赖该被Mock还是真实调用，它只会套用最常见的模式——结果就是生成一堆需要完整Spring上下文才能跑的“单元测试”，实际上更像是集成测试，启动时间30秒以上，CI根本跑不动。
Tabnine和Codeium没有覆盖率反馈回路
Tabnine和Codeium强在补全速度，但它们生成的测试是一次性的。你把光标放在一个方法上，它吐出一段JUnit代码，到此为止。没有后续步骤：这段测试覆盖了多少分支？哪些条件未命中？生成的Mock是否真的隔离了外部调用？你只能人工逐个检查。我让团队在一个结算模块上试过Codeium，它生成了230个测试方法，一跑覆盖率却只有41%，因为大部分测试都在重复同一条正常路径，边界情况和异常流根本没碰到。（延伸阅读：我照着普林斯顿SWE‑Agent论文搭了一条需求即交付管线，但在生成验收标准上卡了两个月——LLM在第287次构建时给我上了一课）
我必须自己搭一个循环
这些工具的共同问题是：它们把“生成测试”看作一个单次任务，而不是一个持续改进的过程。真正的单元测试补全应该是一个反馈控制系统——你得有一个覆盖率的测量器，然后把差距喂回生成器，让它补充。我干DevOps这几年最深的感悟是：没有观测性的自动化就是定时炸弹。所以我的方案是：
代码解析(AST) → 测试大纲生成(LLM) → 测试实例化(带Mock策略)
→ 运行+覆盖率分析(JaCoCo) → 未覆盖分支提取 → 再次提示LLM补充
→ 重复直到覆盖率达标或达到最大轮次。
这套流程我用Python脚本来编排，后面会具体展开。
先把代码结构喂给LLM，别让它从零乱猜
用tree-sitter把方法签名和文档全挖出来
第一步是准确解析待测代码。我选了tree-sitter的Java解析器，比正则匹配稳妥得多。对于每个目标方法，我提取：方法签名、参数列表、返回类型、throws声明、Javadoc注释、以及方法体内调用的所有外部方法。我还特意提取了字段依赖——也就是类里面通过@Autowired或构造函数注入的那些字段，因为后面Mock策略全靠这些。
提取出来的信息被组织成结构化JSON，作为LLM提示词的一部分。下面是我写的Python脚本核心片段，负责解析一个Java文件并输出每个方法的结构化信息：（延伸阅读：凌晨两点，线上模型开始胡言乱语，因为有人改了我的Prompt注释——于是我把MLflow塞进了LLM实验流水线）
import tree_sitter_java as tsjava
from tree_sitter import Language, Parser
JAVA_LANGUAGE = Language(tsjava.language())
parser = Parser(JAVA_LANGUAGE)
def extract_methods(source_code: str, file_path: str) -> list[dict]:
tree = parser.parse(bytes(source_code, "utf8"))
root = tree.root_node
methods = []
# 遍历所有方法声明
for node in root.children:
if node.type == "method_declaration":
method = {
"file": file_path,
"name": "",
"signature": "",
"javadoc": "",
"external_calls": [],
"field_dependencies": []
}
for child in node.children:
if child.type == "identifier":
method["name"] = child.text.decode()
elif child.type == "formal_parameters":
method["signature"] = child.text.decode()
elif child.type == "block_comment":
# 简单的javadoc提取
method["javadoc"] = child.text.decode()
elif child.type == "method_invocation":
# 递归提取调用，这里简化
callee = child.child_by_field_name("name")
if callee:
method["external_calls"].append(callee.text.decode())
# 从类层面提取字段依赖（需要向上查找class_body）
# 此处省略详细实现
methods.append(method)
return methods
这个提取器会在每次CI构建时对变更的Java文件执行，生成一个依赖清单。然后送到LLM的system prompt里去。
让LLM先写测试大纲，再填代码
直接让LLM吐JUnit代码很容易跑偏——它会写一堆看似合理但根本无关的断言，或者漏掉关键分支。我改成两阶段：第一轮只要求LLM输出一个测试大纲，用自然语言列出需要覆盖的场景（正常路径、边界值、异常情况、并发考虑等），并标注每个场景需要的Mock设置。我人工快速review一遍大纲，确保业务理解正确，然后第二轮让它根据大纲和代码上下文生成具体的JUnit 5代码。（延伸阅读：从850ms到110ms：我把CodeBERT塞进GitHub Actions的SQL注入猎杀实录）
这里的提示词非常关键。我试过几十次才定型。最终版本长这样（省略具体内容，展示结构）：
System prompt:
You are a senior Java engineer expert in writing unit tests.
Given the method signature, its Javadoc, and its external dependencies,
produce a TEST OUTLINE ONLY, listing all scenarios to achieve >80% branch coverage.
For each scenario, specify:
- What input values to use
- What the expected outcome/exception is
- Which dependencies need to be mocked and how they should behave
Do not write code yet.
User message (example):
Method: public RefundResult refund(RefundRequest request) throws PaymentException
Javadoc: Processes a refund for the given request. Verifies payment status, reverses inventory,
triggers notification. Throws PaymentException if payment gateway fails or refund already processed.
Dependencies: PaymentGateway paymentGateway, InventoryService inventory, NotificationService notifier
Output: (LLM generates bullet points)
- Scenario 1: successful refund of a completed payment - mock gateway returns success, inventory.reverse() succeeds, notifier sends email
- Scenario 2: payment status is REFUNDED already - should throw PaymentException with message "Already refunded", no inventory/notifier calls
- Scenario 3: payment gateway throws TimeoutException - should throw PaymentException wrapping it, verify inventory never called
...
等大纲确认后，第二个prompt是：“根据以下大纲和原代码，生成完整的JUnit 5测试类，使用Mockito进行mock，确保所有依赖都被mock，不启动Spring容器。”
Mock的生成是真正的地狱，我烧了半边身子
第一次生成的Mock直接连了生产数据库
大纲搞定之后，我以为最难的过了。结果LLM生成的第一个测试类就闯祸了。它在一个@Mock标注的InventoryService字段上，没有用when(...).thenReturn(...)打桩，而是直接在测试方法里调用了一个真实实现的InventoryClient——这个客户端读取了项目的默认配置文件，里面指向的是生产环境的数据库连接地址。
测试在CI的Docker容器里跑，恰好那个容器所在的VPC子网可以直连生产数据库（这是之前网络设计的遗留债）。于是跑UT的时候直接往生产库的inventory表里插了几十条测试数据。幸亏DBA在凌晨的数据质量监控发现了异常，我们紧急回滚，没有造成线上影响。否则第二天客服会被“我的库存变成负数了”的投诉打爆。
这件事让我意识到：AI生成的Mock不能直接信任，必须强制施加沙盒策略。我做了三件事：
- 所有生成的测试必须在独立容器里运行，并且这个容器的网络策略只允许访问
localhost，禁止任何对外部IP的请求。Kubernetes的NetworkPolicy救了我：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-runner-deny-external
spec:
podSelector:
matchLabels:
app: unit-test-runner
policyTypes:
- Egress
egress:
- to:
- podSelector:
matchLabels:
app: test-dependencies # 允许访问mock的容器如WireMock
- to:
- ipBlock:
cidr: 0.0.0.0/0
except:
- 10.0.0.0/8 # 禁止内网
- 172.16.0.0/12
- 192.168.0.0/16
有了这个策略之后，任何真实外部调用都会直接连接拒绝，测试失败。
2. 在生成环节加入Mock护栏规则：在发给LLM的提示词里硬性规定——所有外部依赖必须通过Mockito的@Mock字段注入，且必须在每个测试方法内明确打桩。不允许使用@SpringBootTest，不允许@Autowired。我甚至在Python脚本里加了一个简单的静态检查器：扫描生成的测试文件，如果发现@Autowired或@SpringBootTest注解，直接拒绝合并到repo，并打印告警。
3. 所有生成的测试代码必须先人工review一轮才能进入主分支。这听起来反自动化，但在我完全信任AI之前，这是必须的安全阀。（延伸阅读：在Jetson Orin上跑金丝雀发布：100次抓取任务A/B测试，仿真99%置信自动止损，但真实传感器延迟让贝叶斯提前关停）
AI对真实Bean的Mock策略经常猜错
另一个常见问题：LLM经常搞混哪些依赖需要Mock，哪些应该是工具类可以直接用。比如我们的OrderService里用了一个MoneyUtils来格式化金额，它是一个纯静态工具类，不需要Mock。但LLM却生成了@Mock MoneyUtils moneyUtils，然后在测试里用when(moneyUtils.format(...)).thenReturn(...)，导致测试根本没法覆盖真实的格式化逻辑。后来我在提示词里明确加入了依赖分类规则：“纯静态工具类且无副作用的方法不需要Mock；需要访问网络、数据库、文件系统或第三方服务的依赖必须Mock。”这个规则一加，Mock的准确率从60%提升到了90%以上。
覆盖率驱动的迭代：让AI自己看JaCoCo报告，补刀缺失分支
JaCoCo报告解析 + LLM补充生成
第一版生成的测试跑完以后，分支覆盖率通常只有50%-60%。关键是要让LLM读取JaCoCo的HTML或CSV报告，识别哪些分支没覆盖到，然后自动补充。我写了一个Python模块，它会解析JaCoCo的CSV报告，按类、方法、未覆盖分支序号（JaCoCo的“分支覆盖”指标会列出每个if/else、switch的具体遗漏），然后生成新的提示词发给LLM。
JaCoCo CSV报告里一行记录类似这样：
"com.mycompany.service.OrderService","refund","(LRefundRequest;)LRefundResult;",0,0,2,1,...
关键字段是第5列“BRANCHES_MISSED”和第6列“BRANCHES_COVERED”。如果missed > 0，我就提取这个方法，并让tree-sitter把方法体内的条件分支节点找出来，标注哪些分支没被命中。然后构造如下提示词：（延伸阅读：ReAct论文里的Agent推理很美，我在AWS Bedrock上复现时却被动作组和知识库的坑绊倒——单Agent企业自动化实战）
Below is a method and its missed branches. Enhance the existing test class to cover these branches.
Method: ...
Missed branches:
- if (request.getAmount().compareTo(BigDecimal.ZERO) <= 0) -> never false
- catch (TimeoutException) -> never thrown
- else branch of paymentStatus check
Add new test methods or modify existing ones to reach 100% branch coverage.
这个反馈轮次我设了最多5轮。实践中，复杂方法通常在第3轮就能达到85%以上的分支覆盖，到第5轮能逼到90%以上。
真实项目：支付退款模块的覆盖率跃升
我把这套循环应用在支付模块的RefundService和相关的PaymentValidator、RiskAssessor等15个类上。初始的测试只有12%分支覆盖。经过第一轮生成（大纲+实例化），覆盖率跳到了54%。然后第一轮反馈补充后到了72%，第二轮后81%，第三轮87%。我们停止了迭代，因为剩下的13%是涉及老旧框架的定时器回调，需要大量重构才能测，暂时放弃。
覆盖率的提升直接转化为信心。我们通过新补的测试发现了两个真实bug：一是当退款金额为负时（系统接收的外部请求未校验），refund方法会抛出非受检异常导致事务没有回滚，留下了脏数据；二是当第三方支付网关返回“PARTIAL_REFUND”状态时，我们的代码没有正确处理，误认为退款失败重新发起退款，导致客户被两次扣款。这两个缺陷在代码里躺了4年，如果不是AI系统补了边界值测试，可能永远发现不了。
把AI测试生成塞进CI，然后配上监控告警
CI流水线配置：只有覆盖率达标才能合并
我不能让这套脚本只在我本地跑。我必须让它成为CI的一道门禁。我们的项目用GitLab CI，我增加了一个阶段ai-test-generation，在每次Merge Request的时候触发。流程：
- 检出代码，识别变更的Java文件（用
git diff）。 - 对每个变更文件提取方法并生成初始测试。
- 运行现有测试+新测试，并生成JaCoCo报告。
- 检查目标类的分支覆盖率是否≥80%，如果不达标则进入迭代生成循环（最多5轮）。
- 循环结束后如果仍不达标，流水线失败，MR被阻止合并——除非有明确的“跳过”标签。
对应的.gitlab-ci.yml片段：
ai-test-gen:
stage: test
image: myregistry/test-gen-runner:v2 # 包含Python+tree-sitter+maven
script:
- python /scripts/generate_tests.py --changed-files $(git diff --name-only $CI_MERGE_REQUEST_DIFF_BASE_SHA...HEAD)
- mvn clean test jacoco:report
- python /scripts/check_coverage.py --threshold 80 --report target/site/jacoco/csv
artifacts:
paths:
- target/site/jacoco/
- test-gen-output/
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
必须上的监控：覆盖率下降就报警，测试时间爆炸也报警
吃过前几次亏后，我给这套系统加了完整的可观测性。首先是Prometheus + Grafana的指标暴露。我用JaCoCo的Maven插件配合Micrometer把每一次构建的分支覆盖率推到Pushgateway，然后在Grafana里设置面板：当主干分支的全局分支覆盖率下降超过5个百分点时，触发PagerDuty告警（因为这意味着有人合了降低覆盖率的代码，或者AI生成的测试被删了）。
另外，测试运行时间也是关键指标。AI生成的测试有时候会出现死循环，或者因为Mock设置不当导致超时等待。第一次上线时我没监控这个，结果某天中午CI队列全部堵死，每个作业跑了30分钟还没结束。查了一下，是LLM在一个方法里生成了100多个测试用例，每个都调了一个sleep的模拟代码，导致总时间暴涨。后来我加了一条规则：单个测试类运行时间超过10秒，脚本就中止并丢弃该类，同时触发Slack通知。配置在check_coverage.py里：
def check_test_timeout(test_file: str, timeout_sec: int = 10):
result = subprocess.run(["mvn", "test", "-Dtest=" + test_file, "-DfailIfNoTests=false"],
capture_output=True, timeout=timeout_sec)
if result.returncode == -9: # timeout
notify_slack(f"Test class {test_file} exceeded time limit, discarded.")
# 删除生成的测试文件
os.remove(test_file)
我还给AI生成的总测试用例数设了上限：每个类最多生成25个测试方法，超过就截断，避免资源滥用。
现在，这套系统在我们的CI里跑了4个月，稳定地将变更类的覆盖率控制在80%以上。半夜报警的次数从每月3次降到了0。当然，这不代表可以高枕无忧——AI仍然会写出古怪的断言，仍然需要人工review。但它把补测试这事儿从“没人愿意干的苦活”变成了“机器干，我检查”的模式，对于老旧系统的稳定性提升是实打实的。
如果你也想在自己项目里搞，建议先把沙盒网络和Mock护栏做好，再让AI开火。别像我一样，第一次就让Mock捅穿了生产库。
