Git 合并后代码审查（测试视角）
面向软件测试工程师的 Git 变更审查技能，用于在开发合并代码后对整体变更执行结构化审查，产出缺陷风险清单与测试计划输入。
适用场景
- 开发完成代码合并后，测试工程师对整体变更进行审查
- 识别缺陷风险、确定测试范围和优先级
- 适用于 Agents 对话框或 CLI 环境
使用前提
- 已明确本次变更的 diff 范围（如
git diff <旧基线>..<新基线>） - 已了解需求背景和业务约束
- 输入缺失时按"步骤二"的规则先向用户确认
模板文件说明
| 文件 | 用途 |
|---|---|
templates/main-full-review.txt |
主流程：合并后整体审查（六维度全覆盖） |
templates/test-impact-analysis.txt |
变体一：测试影响分析（快速划定回归范围） |
templates/defect-hunting.txt |
变体二：缺陷挖掘（重点找可复现 Bug） |
templates/merge-completeness-check.txt |
变体三：合并完整性核对（确认交付完整性） |
工作流程
步骤一：确认审查模式
根据用户目标选择执行路径：
- 首次全面审查 → 执行主流程（六维度全覆盖）
- 时间紧、需快速划定测试范围 → 执行测试影响分析
- 核心链路、深度挖掘缺陷 → 执行缺陷挖掘
- 冒烟测试前核对交付完整性 → 执行合并完整性核对
用户未明确指定时，默认执行主流程，并在报告开头注明所选模式。
步骤二：收集审查输入
执行前必须确认以下输入，缺失时先向用户询问，禁止臆测：
- diff 范围：具体的对比命令、提交区间或 PR/MR 链接，禁止接受"最近的改动"等模糊描述
- 需求背景：一句话说明变更目的与业务约束（如幂等要求、兼容性要求）
- 补充材料（可选）：需求文档、设计文档、团队历史高频缺陷记录
需求背景缺失且用户无法提供时仍可继续审查，但须在报告中标注"背景缺失"，并下调风险结论的置信度。
步骤三：执行审查
按所选模式加载对应模板文件并执行。主流程须逐一检查以下六个维度：
- 逻辑正确性：核心流程是否有漏洞，边界条件（空值、零值、极值、并发冲突）是否处理完备
- 异常处理：异常分支是否吞掉错误，是否缺少回滚或补偿逻辑
- 并发与幂等：是否存在竞态条件、重复请求下的数据一致性问题
- 兼容性：接口出入参是否变更、数据库字段变更是否影响存量数据、配置项是否遗漏
- 安全性：是否引入注入、越权、敏感信息日志泄露等风险
- 回归影响：改动可能波及哪些现有功能，哪些调用方会受影响
步骤四：输出审查报告
按"输出格式约定"生成结构化报告，确保每项结论可直接转化为测试用例设计或回归计划。
最佳实践规则
规则一：显式指定 diff 范围
禁止笼统接受"审查最近改动"，必须给出具体对比命令或提交范围。
示例：git diff release-v2.3.0..origin/develop
规则二：大变更分轮审查
当 diff 超过 500 行时：
1. 第一轮：执行主流程做整体审查
2. 第二轮：针对高风险文件发起深入分析
3. 整体与局部结合，比一次性分析全部代码质量更高
规则三：补充需求上下文
至少确认一句变更目的和业务约束，可显著降低误报率。
示例："本次变更是为了订单模块新增超时自动取消功能，业务约束是取消操作必须幂等。"
规则四：结论需人工校验
- 审查结论作为测试设计输入，而非最终结论
- 风险等级需结合发布窗口、下游依赖等工程因素综合判断
- 技能负责扫描广度，测试工程师负责判断深度
规则五：持续迭代审查维度
将团队历史高频缺陷模式补充进主流程的"审查维度"，使每次审查角度稳定收敛，结论可在多次变更间横向比较。
输出格式约定
所有模式统一按以下结构输出：
1. 变更概览（3-5句话）
2. 问题清单（严重/一般/建议 三级）
- 位置（文件+函数）
- 问题描述
- 潜在后果
- 修复建议
3. 测试要点（含边界值和异常场景）
4. 回归测试范围（模块+优先级排序）
5. 风险结论（高/中/低 + 理由）
