AI驱动QA重构方案

1. 背景

当前 QA 工作在很多团队中仍以以下模式为主：

• 需求评审后，测试人员手工拆解测试点并编写测试用例
• 大量时间投入在端到端点点点验证、重复回归和结果确认
• 白盒测试主要依赖研发自测，测试阶段介入有限
• 自动化回归以全量执行为主，针对变更范围的精准回归能力不足
• 上线前缺少系统化的变更影响分析，容易出现“当前需求通过，但历史功能受损”

这一模式的核心问题不是测试不努力，而是 QA 产能被大量低价值重复劳动占用，导致：

• 需求分析和测试策略投入不足
• 测试阶段对白盒逻辑的覆盖不足
• 回归测试投入大，但收益不稳定
• 质量决策依赖经验，缺少结构化支持

AI 的价值不应停留在“帮忙写几个用例”或“帮忙生成脚本”，而应推动 QA 工作从执行驱动转向策略驱动、从人工展开转向 AI 展开、从点点点验证转向基于代码和变更影响的精准验证。

2. 方案定位

本方案的目标不是替代测试人员，而是重构 QA 工作方式。

核心定位如下：

• 人主导需求分析、风险识别、测试策略和质量决策
• AI 主导测试资产展开、代码走查辅助、变更影响分析和回归建议生成
• 通过提升白盒测试占比，降低低收益端到端测试占比
• 通过上线前质量门禁和 diff 分析，降低低收益、无差别自动化回归占比

一句话概括：

人主导策略，AI主导展开；人主导判断，AI主导覆盖。

3. 总体目标

3.1 业务目标

• 提升测试阶段对需求实现正确性的识别能力
• 提前发现逻辑缺陷、边界缺陷和回归风险
• 降低低效重复验证投入
• 提升上线前质量判断的准确度

3.2 QA 目标

• 提升需求分析和测试策略工作的占比
• 提升白盒测试在测试阶段的占比
• 降低低价值端到端测试占比
• 降低低收益、无差别自动化回归测试占比
• 建立基于变更影响的质量门禁机制

4. 核心原则

4.1 人不退出，角色上移

测试人员不再把主要精力放在机械写用例和机械点点点上，而是重点投入：

• 需求建模
• 风险识别
• 测试策略设计
• 问题识别与定级
• 上线质量决策

4.2 AI 不替代判断，负责展开和放大覆盖

AI 主要承担：

• 需求材料归纳
• 测试点展开
• AI 友好型测试资产生成
• 基于测试资产的代码走查
• 基于 diff 的影响分析
• 定向回归建议生成

4.3 测试资产必须结构化

如果测试知识只存在于自然语言文档和个人经验中，AI 每次都要重新理解，结果不稳定。

因此必须建设 AI 可消费的结构化测试资产，包括：

• 需求摘要
• 风险点
• 规则约束
• 用例矩阵
• 白盒关注点
• 回归范围

4.4 优先提升白盒验证，而非堆叠 E2E

端到端测试仍有价值，但只应保留在高价值主链路和关键冒烟场景。

更高收益的方向是：

• 白盒逻辑验证
• 接口契约验证
• 变更影响分析
• 风险定向回归

5. QA 工作模式重构

5.1 阶段一：需求分析与测试策略由人主导

测试人员在需求阶段完成以下工作：

• 识别业务目标和用户路径
• 划定变更范围和非变更范围
• 提取核心风险点
• 确定验证重点
• 确定应保留的 E2E 链路
• 确定应重点展开的白盒逻辑

该阶段的产物不是大量细碎自然语言用例，而是一份高质量测试策略输入。

5.2 阶段二：AI 生成完整测试用例和 AI 友好型用例

在策略确定后，由 AI 负责将策略展开为：

• 完整测试用例
• AI 友好型测试用例
• 规则矩阵
• 边界与异常场景补充

其中“AI 友好型用例”是后续代码走查、影响分析和回归裁剪的核心输入。

AI 友好型用例不要求测试人员人工定义固定字段或固定模板，而是由 AI 根据测试策略、风险点、变更范围和白盒关注点自动生成。

测试人员的重点不在于编排 AI 友好型用例的表达结构，而在于提供高质量的策略输入，确保 AI 生成结果围绕真实风险展开。

因此，这一阶段的关键不是让人工维护一套字段规范，而是让 AI 能稳定地将以下内容转化为可供后续走查和分析使用的测试资产：

• 需求目标
• 变更范围
• 风险点
• 核心场景
• 白盒关注点
• 回归关注范围

6. 基于 AI 友好型用例的代码走查

6.1 目标

AI 读取 AI 友好型用例后，不只是做普通代码 review，而是做面向测试目标的白盒走查。

其核心任务包括：

• 检查需求是否被完整实现
• 检查内部逻辑分支是否覆盖到位
• 检查边界条件是否被正确处理
• 检查是否影响历史功能约束
• 检查是否存在遗漏测试点

6.2 AI 走查输出维度

建议要求 AI 走查必须输出以下内容：

• 需求映射
• 逻辑分支映射
• 风险点映射
• 疑似问题列表
• 缺失测试点列表
• 建议补充的白盒验证点

6.3 测试人员的职责

测试人员不应被动接受 AI 输出，而应重点参与：

• 判断问题是否成立
• 判断问题优先级和影响面
• 区分实现差异与真实缺陷
• 判断是否需要阻断上线
• 判断是否需要补充用例或补充门禁

这一模式会显著提升测试阶段白盒测试占比，并把测试人员的价值从“执行者”转向“分析者和决策者”。

7. 降低端到端测试占比

7.1 调整原则

不是取消 E2E，而是压缩其使用范围。

E2E 应只保留在以下场景：

• 关键交易主链路
• 多系统协同关键链路
• 上线前核心 smoke
• 历史高风险故障场景

7.2 应优先替代的内容

原先通过点点点验证的大量内容，可以转移到：

• 白盒代码走查
• 规则级测试
• 接口契约测试
• 变更影响分析
• 定向回归验证

7.3 预期收益

• 缩短测试执行时间
• 降低环境依赖和脚本脆弱性
• 提高问题发现前置程度
• 让 E2E 回归到“最终确认”而不是“主要发现问题手段”

8. 质量门禁机制

8.1 核心思想

上线前必须建立基于变更影响的质量门禁，而不是只依赖主观经验或全量回归结果。

质量门禁应基于需求分支代码与线上分支代码的 diff 进行分析。

8.2 门禁输入

质量门禁至少应关注以下 4 类 diff：

• 代码 diff
• 接口契约 diff
• 配置 diff
• 数据结构 diff

8.3 门禁分析目标

AI 结合 diff 和 AI 友好型用例，分析：

• 修改了哪些模块
• 命中了哪些核心业务规则
• 会影响哪些历史功能
• 哪些非本次需求范围可能被波及
• 应执行哪些定向回归
• 是否命中强制门禁项

8.4 建议门禁规则

可建立如下门禁维度：

• 是否命中核心域逻辑
• 是否命中公共组件或基础能力
• 是否修改接口入参或出参
• 是否修改排序、计费、状态机、权限等高风险逻辑
• 是否存在与 AI 友好型用例预期冲突的实现
• 是否存在缺失白盒验证点

8.5 质量门禁结论

门禁结论建议输出为：

• PASS
• PASS_WITH_RISK
• BLOCK

并附带：

• 风险描述
• 影响范围
• 建议回归集
• 建议补充验证项

9. 基于 diff 的定向回归

9.1 核心思想

第四步的目标不是单纯“看代码差异”，而是建立“变更到风险到回归”的映射。

回归测试应从全量执行转向定向执行。

传统上，自动化测试中有相当一部分投入被用于大范围回归，其根本原因在于团队难以准确判断需求改动是否会波及关联模块或非关联模块，因此只能通过较大范围的自动化执行来兜底。

当上线前已经引入 AI 驱动的 diff 分析后，团队可以在更大程度上提前识别：

• 当前需求实际修改了哪些模块
• 修改点可能影响哪些共享逻辑和历史功能
• 哪些区域属于高风险波及范围
• 哪些区域与本次变更关系较弱

这意味着自动化测试不再需要承担大量“因为不确定所以全跑一遍”的兜底职能，而可以转向更精准的风险验证。

因此，本方案主张降低的不是自动化测试本身的价值，而是降低因变更影响不清晰而产生的低收益、无差别回归自动化占比。

9.2 回归裁剪逻辑

基于 diff、模块映射、历史缺陷和 AI 友好型用例，输出：

• 必跑回归集
• 条件回归集
• 可跳过回归集

9.3 应保留的自动化

在 AI diff 帮助识别变更边界后，自动化回归占比可以适度降低，但以下部分不应削弱：

• 核心 smoke
• 高风险主链路自动化
• 历史缺陷防回归集
• 关键契约自动化
• 关键质量门禁校验

9.4 应压缩的自动化

可以逐步压缩的是：

• 与本次变更无关的全量低收益回归
• 高维护成本、低缺陷发现率的 UI 自动化
• 与白盒或契约测试重复覆盖的脚本
• 仅因不清楚影响范围而保留的大范围兜底式自动化
• 仅因“怕漏”而保留的低收益回归集

需要强调的是，AI diff 主要解决的是“变更影响不清楚”这一问题，并不能完全替代运行时验证、契约验证和核心链路验证。

因此，第五步本质不是“少跑自动化”，而是通过 AI 驱动的 diff 分析与影响识别，减少低收益自动化回归，把自动化测试从全量兜底式回归转为基于风险和变更的定向回归。

10. 人与 AI 的职责分工

10.1 人负责

• 需求理解
• 风险识别
• 测试策略制定
• 质量判断
• 缺陷定级
• 上线决策

10.2 AI 负责

• 材料归纳和结构化提炼
• 测试用例展开
• AI 友好型测试用例生成
• 基于用例的代码走查
• 基于 diff 的影响分析
• 定向回归建议生成

10.3 协作原则

• 人不给 AI 模糊任务
• AI 不输出不可验证结论
• 关键质量结论必须由人确认
• 所有 AI 输出尽量结构化、可追溯、可复核

11. 推荐产出物

为支撑该方案，建议逐步建立以下资产：

• 需求策略卡
• AI友好型测试用例库
• 白盒关注点库
• 模块-风险-回归映射表
• 历史缺陷防回归库
• 质量门禁规则库

建议这些资产具备统一字段和统一模板，以便 AI 稳定读取和复用。

12. 实施路径

12.1 第一阶段：建立输入标准

• 统一需求策略模板
• 统一 AI 友好型用例模板
• 统一代码走查输入模板
• 统一质量门禁输入模板

12.2 第二阶段：建立 AI 走查闭环

• 用 AI 友好型用例驱动代码走查
• 测试人员对 AI 输出进行判定和反馈
• 形成问题识别标准和复盘机制

12.3 第三阶段：建立质量门禁

• 接入分支 diff
• 建立模块映射和风险识别规则
• 形成上线前门禁输出

12.4 第四阶段：缩减低收益回归

• 基于门禁结果裁剪回归集
• 压缩低收益 UI 自动化
• 强化高收益白盒和契约验证

13. 衡量指标

可通过以下指标衡量方案效果：

• 需求阶段测试策略完成率
• AI 友好型用例覆盖率
• 测试阶段白盒问题发现占比
• E2E 测试执行时长占比
• 定向回归替代全量回归比例
• 上线前门禁命中风险数
• 历史功能回归事故数
• 自动化脚本维护成本变化

14. 风险与边界

14.1 风险

• 输入文档不规范会导致 AI 输出波动
• 用例结构不统一会降低复用价值
• 如果缺少人工判断，AI 可能产生伪问题或漏判
• 只做工具接入、不做流程重构，最终仍会退化成“多一个 AI 工具”

14.2 边界

• AI 不能替代质量决策
• AI 不能替代对业务上下文的最终理解
• AI 输出必须接受人工复核
• 并非所有场景都应减少 E2E，核心链路仍需保留

15. 结论

AI 驱动 QA 重构的本质，不是让测试工作更快一点，而是重构 QA 的工作重心。

其核心价值也不只是效率提升，而是实现：

• 问题发现前移
• 回归验证精准化
• 低收益测试投入下降
• 白盒分析能力增强
• 上线质量判断更有依据
• QA 角色从执行者转向质量分析者和风险控制者

重构后的 QA 模式应是：

• 人把重点放在需求分析和测试策略上
• AI 基于策略生成完整测试用例和 AI 友好型用例
• AI 读取 AI 友好型用例进行代码走查
• 测试人员参与问题识别、风险判断和质量决策
• 白盒测试在测试阶段的占比显著提升
• 端到端点点点测试占比显著下降****
• 上线前基于 diff 建立质量门禁
• 基于变更影响执行定向回归，从而降低低收益自动化回归占比

最终目标不是“让 AI 帮 QA 干活”，而是把 QA 从重复执行中释放出来，转向更高价值的质量分析、风险识别和上线决策。

实践案例:

AI友好型测试用例:

购物车凑单推荐_AI测试用例.json

AI输出代码走查报告:

claude-code服务端购物车凑单推荐_代码走查报告.md

Android-GLM-购物车凑单推荐代码走查报告.md

个人分析总结:

1.因为走查的测试用例主要还是AI生成的,覆盖不足

2.测试用例缺少详细的接口信息

后续若改善这两点,效果应该会更明显