一、项目背景
在 Java 项目中，大模型可以根据目标方法生成单元测试，但生成的代码并不一定能够直接使用。测试用例可能无法编译、执行失败，也可能虽然执行通过，却没有覆盖关键代码路径，甚至存在冗余断言和无效测试。
针对这些问题，我正在开发一个基于多维质量感知的 Java 测试用例生成与优化项目。项目从编译、执行、代码覆盖率、缺陷检出和代码冗余等维度评估初始测试，再将评估结果反馈给 Refine 模块，指导模型进一步修改测试用例。
与一次性生成测试相比，这种从生成到评估再到优化的流程能够利用实际执行结果识别生成代码中的问题，逐步提升测试用例的可用性。但与此同时，每轮优化都可能引入额外的编译、执行和覆盖率分析开销。当目标方法数量增加、每个方法生成多个测试文件时，这些开销也会逐步累积。
因此，本次实践主要关注两个方面：
- 测试质量优化： 利用多维质量反馈，识别并改善测试用例中的问题。
- 云端部署与效率分析： 将测试评估流程部署到阿里云 ECS，验证项目能否在云端稳定运行，并分析实际运行中的时间与资源开销。
二、核心方案
项目主要由测试生成、多维质量评估、Refine 迭代优化和批量评测与结果记录四个部分组成。
2.1 测试生成
系统以待测 Java 方法及其必要上下文作为输入，调用大模型生成初始单元测试。生成的测试会进入后续评估流程，而不是直接被视为最终结果。
2.2 多维质量评估
系统从以下五个维度收集测试质量反馈：
- 编译状态： 检查测试代码能否通过编译，并保留具体编译错误。
- 执行状态： 判断测试能否正常运行，识别执行失败、超时等问题。
- 代码覆盖率： 利用 JaCoCo 收集行覆盖率和分支覆盖率，分析测试是否触及目标代码路径。
- 缺陷检出能力： 在具备 buggy/fixed 版本对照的项目中，检查测试能否区分存在缺陷与修复后的代码。
- 代码冗余： 分析测试之间的相似性，识别可能重复表达相同测试意图的用例。
这些指标分别反映测试的可执行性、覆盖能力、缺陷检测价值和冗余程度。综合分析这些指标，可以更具体地判断测试需要改进的方向。
2.3 Refine 迭代优化
系统将评估结果及相应错误信息反馈给 Refine 模块，由模型根据当前问题修改测试用例。
例如，编译错误可以为语法或类型修正提供依据；覆盖率反馈可以帮助识别尚未覆盖的代码路径；冗余分析则可以为减少重复测试提供参考。
通过这一过程，系统能够根据实际评估结果进行多轮优化，而不是仅依赖模型首次生成的结果。
2.4 批量评测与结果记录
为便于比较不同迭代策略，系统记录每轮测试的编译状态、执行结果、覆盖率信息、优化日志和运行耗时，并汇总形成可供分析的实验结果。
这一设计使测试生成与质量验证形成闭环，也为后续分析不同 Refine 轮次带来的质量收益与时间成本提供了数据基础。
三、实验结果与耗时分析
3.1 整批任务耗时对比
在相同的 Defects4j数据集的Csv的16个版本上，系统为每个目标方法生成 3 个测试用例，并进行两轮 Refine 迭代。两种运行环境的整批测试评估耗时如下：
| 指标 | 原运行环境 | 阿里云 ECS |
|---|---|---|
| 目标方法数量 | 16 | 16 |
| 每个方法生成的测试用例数 | 3 | 3 |
| Refine 迭代轮数 | 2 | 2 |
| 整批评估耗时 | 954 分钟 | 901 分钟 |
根据实测数据，ECS 环境的整批评估耗时减少了 53 分钟，降幅约为 5.56%。
3.2结果分析与限制
不过，整批任务的总耗时不仅包括 Java 测试执行，还可能包含模型接口响应、JVM 启动、依赖加载、覆盖率采集和其他编排开销。
