在传统的软件测试体系中，QA人员主要采用接口测试、ui/功能测试、兼容/易用性测试、性能测试等黑/灰盒测试技术手段来保障软件项目质量，涉及代码层面的质量检查包括单元测试、代码Review环节主要由开发人员负责，QA涉及较少或者基本不参与，因此，针对质量至少存在以下局限性：
1、QA重心在于关注功能实现，对内在的代码质量可能存在盲区
一些隐形bug，对常见的代码错误和安全漏洞，如入参为空导致数据库全表扫描、特定数据返回空导致空指针异常、异常处理、线程安全、资源泄露、代码健壮性、SQL注入/XSS漏洞等问题难以被传统测试手段发现；
2、人工Review代码成本较高，执行过程中落地难度大
由于人工Review代码，需要耗费大量的时间精力，效率比较低，很多团队因为项目开发任务重、时间紧，往往得不到执行，或者执行大打折扣，这些因素都会导致代码Review落地困难，从而影响质量。
以上对于测试团队的工作效率以及产品质量的保障都会有很大的影响。
基于AI大模型的能力，搭建一套能够实现对增量代码自动Review的代码质量检测工具，通过该工具实现自动扫描识别代码的逻辑错误、安全漏洞、代码健壮性等问题，并生成详尽的审查报告和优化建议，从而提升代码Review效率和质量，实现对现有的质量体系进行增强和改进的目标，与QA人员形成互补能力，但是并不能替代QA。
三、解决方案 经过反复调研和测试，我们利用git diff 提取被检测项目的目标分支增量代码片段，调用本地api提取该增量代码完整方法体，最后调用AI大模型对进行扫描，生成CodeRview报告。
整体技术方案一共包括4层：业务接入层、jenkins调度层、API服务层、底层模型层，具体如下：
3.1、模型选取
前提条件：
1.硬件资源条件：公司采用阿里云托管，目前有1块闲置的英伟达V100 32G 显卡
2.数据安全要求：基于公司对数据安全的要求，需要保证模型能支持私有化部署
基于以上要求，我们在选择用于代码审查(Code Review) 的 AI 大模型时，需要考虑模型是否支持本地化部署、模型能力偏向和审查效果。目前，常见的选择包括 OpenAI 的 GPT 系列、智谱 AI、以及 DeepSeek 等。这些模型具备强大的自然语言处理能力，可分析代码变更并生成审查建议。
我们对Qwen2.5-Coder、DeepSeek-Coder-V2和智谱CodeGeeX4三大模型的代码审查(Code Review)能力进行了全面的调研和测试，他们的主要特性比较如下：
综合来看，Qwen2.5-Coder、DeepSeek-Coder、CodeGeeX4 都具备较强的代码识别和审查能力，且都支持本地部署和具有较高的数据安全性。
结合调研结果加上本地硬件资源(V100 32G)，分别对 Qwen2.5-Coder（7B、14B、32B）、DeepSeek-Coder（6.7B、V2 16B）、CodeGeeX4(9B) 在代码审查(Code Review)结果与响应速度上做了验证与对比：
基于模型调研和实际验证结果，目前我们选择智普CodeGeeX4 9B模型作为主要模型，Qwen2.5-Coder 14B和DeepSeek-Coder 16B模型作为备选模型，支持随时切换。
3.2、核心功能详细介绍
核心功能的实现思路如下图，大致分为五步：
1、拉取目标分支增量代码，通过git diff获取差异文件
2、提取识别增量方法、解析变更类全量代码和匹配增量方法体
3、以Class、Method为单位循环调用本地大模型API接口获取结果
4、结果存储与报告生成
5、发送钉钉通知审查结果
整体流程如下:
以下对每个步骤进行详细介绍：
1、拉取代码库与git diff生成差异文件
Jenkins 任务配置：
定时任务或触发式拉取：配置 Jenkins 任务，定时或通过其他触发方式拉取指定 Git 仓库中的代码，支持 GitHub、GitLab 等代码托管平台。
Git 配置：
指定分支、版本、提交信息等，通过配置 Jenkins job 来自动拉取最新的代码。
Shell 脚本执行：
使用 shell 脚本执行 Git 拉取操作，可以配置参数如 git pull 或 git checkout 来确保拉取正确版本的代码。
Git Diff 对比：
使用 git diff <commit_base_branch> <commit_target_branch> 比较开发分支与基线分支的差异，提取增量代码。git diff 可以高效地找到相对较小的代码变更，避免全量扫描带来的性能开销。生成 diff 文件，标记出新增或修改的代码行，这些变更即为增量代码。
增量代码识别与存储：
提取出来的增量代码所在方法会存储在一个专门的临时文件夹中，等待后续步骤进一步处理。增量代码可以根据修改的内容分类（如新增、修改、删除），以便后续审查更具针对性。
2、 提取识别增量方法、解析变更类全量代码和匹配增量方法体
Python 逻辑处理：
解析 git diff 输出，分析出增量代码中的类、方法、函数等模块。通过 Python 脚本解析差异文件，提取新增或修改的函数、类，将识别出的方法和类将被归类，存储为一个 JSON 格式的结构，包含方法名称、类名等信息。
全量代码解析：
使用 JavaParser 解析整个代码库（包括新增和历史版本的代码），通过解析构建方法体的映射表。JavaParser 可以生成抽象语法树（AST），帮助更准确地理解方法和类的结构。
通过解析后的 AST，提取出代码中的方法名、类名及其对应的实现。这一过程为后续增量代码与全量代码的匹配提供了基础数据。
方法体匹配与上下文提取：
将增量代码中的方法名与全量代码中的方法体进行匹配，找出增量代码的完整上下文（如方法的调用和逻辑实现）。通过这种方式，可以确保审查的是完整的业务逻辑而不仅仅是部分代码。
增量方法和上下文通过映射关系进行归档，便于后续审查模块访问。
3、 调用本地大模型接口
Ollama 模型微调：
使用 Ollama 作为基础的 AI 模型，进行微调，能显著提高模型的审查准确度，实现输出样式最优化。
建议修改：
提供针对问题的修复建议，帮助开发人员理解和修复问题。
智能审查扩展：
可以根据具体需求调整模型，增加或修改审查的规则，比如在模型的输入中加入更多的上下文信息，或者使用外部工具提供的静态分析结果进行补充。
4、 结果存储与报告生成
MySQL 数据库：
审查结果存储在 MySQL 数据库中，设计审查结果表来保存以下信息：
报告id：查询唯一值
文件路径：类所在文件路径
方法名：增量代码方法名称
代码片段：问题所在的代码行及相关代码。
修复建议：基于模型输出的修复建议，帮助开发人员快速定位问题并解决。
fastjson 报告生成：
利用 fastjson实现，将数据库中存储的审查结果提取出来，生成 HTML 格式的报告。
以Class为单位输出报告，示例如下：
5. 钉钉通知审查结果
钉钉机器人 API：
使用钉钉机器人的 Webhook 接口，将审查报告和关键问题摘要自动推送到指定的钉钉群。
消息内容包括：
**审查报告链接：**提供报告的下载链接，供开发人员查看详细的审查内容。
被测分支：方便查阅
配置灵活性：
可以根据需要配置不同的通知频率和内容摘要，例如仅推送高危漏洞，或者根据问题的严重性级别推送不同的通知。
3.3、使用场景
包括提测前、bug fixed后、代码合并后等场景，支持手工和自动运行，目前大部分由QA手动触发执行。
四、实践结果
4.1、使用情况及效率提升
目前已接入4条业务线，接入服务20+，试用近一个月，累计发现的有效问题40+（包括空指针校验、入参为空导致数据库查全表、线程安全、异常处理不规范、资源泄露、代码安全漏洞等问题），单次生成Review报告的时间基本控制在5-10min以内。
4.2、应用案例
案例1：入参未校验，导致查全表，已修复
优化前后代码对比：
案例2：缺少对参数的判空 存在潜在的空指针异常：
优化前后代码对比：
自动代码Review工具虽然可以帮助我们发现问题，是否要修复，还要结合具体的业务场景、上下文进行判断，不能一概而论，做到具体问题具体分析，确保每一个可疑问题都能得到恰当的评估与处理。
五、后续规划
目前主要实现对java工程相关代码的自动化Review，取得一定的效果，后续计划包括：
1、接入更多项目
A、支持android、ios客户端代码接入，实现自动Review
B、支持前端vue、js、css代码接入，实现自动Review
2、报告生成与结果展示优化
A、提供易于理解，问题更加精准的审查报告，帮助开发人员快速识别和修复问题
B、增量代码标识精确到行，方便快速判断是新增代码问题，还是历史问题
六、总结
在当前竞争日益激烈的软件领域，降本、增效、提质一直是各团队不懈追求的目标，如何站在巨人的肩膀，利用好AI的能力帮我们实现这一目标显得尤为重要，基于AI大模型的增量代码自动Review工具，正是顺应这一趋势做出的尝试。
通过该工具可以帮助QA团队增强和改进质量，但仍存在较大的优化空间，后续将持续改进优化，争取使该工具成为我们的得力助手，在质量保障提升的道路上注入更多活力与价值。
