QA 如何借助 AI：从传统测试到智能质量工程

从需求分析到回归验证，了解 AI 如何帮助 QA 整理信息、发现风险、生成测试资产和分析结果，同时保留人工判断与可核验的证据。

AI 可以扩大 QA 的分析和执行能力，但质量判断仍需要清晰的预期、可信的证据和人的审核。本文把 AI 放回软件质量保障的真实工作链路：从读需求、识别风险、设计测试，到自动化执行、缺陷分析、回归和 Agent 评估。

这篇文章讨论什么

本文面向有手工测试、接口测试或自动化测试经验的 QA，以及正在测试 LLM 应用、Copilot 或 Agent 的质量工程师。重点不是把 AI 描述成可以独立承担质量责任的“自动 QA”，也不是把 Prompt、RAG、MCP 或 Agent 当作目标本身，而是看它们如何进入已有流程。

AI 适合协助处理重复、信息密集的工作；QA 仍然负责提供上下文、核验结果、补足业务判断和做发布决策。生成的测试用例、代码或结论都不能默认无需审核。

从传统 QA 到 AI 增强工作流

传统 QA 流程通常是：

需求与变更 → 需求分析 → 风险识别与测试计划 → 场景 / 用例设计
→ 手工或自动化执行 → 缺陷报告与分诊 → 回归验证 → 发布质量评估

AI 增强后的流程可以是：

需求、接口文档、代码变更、历史缺陷、测试数据
→ 提供受控上下文 → AI 分析 / 提议 / 生成 → QA 审核和补充
→ 人或受控工具执行 → 收集日志、响应、截图等证据
→ AI 辅助归纳和定位线索 → QA 判断 → 回归 / CI / 持续评估

能力可以逐步递进：

LLM 对话 → 加入文件和历史数据 → 生成结构化产物
→ 连接 API、浏览器、代码仓库或 CI → 固化 Workflow / Skill
→ 受控地连续执行任务 → 用评估集和运行证据持续验证

这是一条演进路径，不代表每个团队都必须走到 Agent。很多 QA 任务使用“文件 + 一次分析 + 人工复核”就已经有价值。

八个 QA 环节内容地图

不用一开始就做 Agent

可以从以下层级逐步开始：

AI 助手：让 AI 总结需求、整理日志或提出测试场景。
AI + 标准模板：固定输入字段、输出格式和人工检查点。
AI + 知识上下文：加入接口文档、历史缺陷、术语表和版本范围。
AI + 工具执行：在受控权限下连接 API、浏览器、代码仓库或 CI。
Workflow / Agent + Evaluation：让稳定流程可重复运行，并用评估集验证结果。

一个适合的首个练习是：选一份脱敏的需求文档，要求 AI 提取可测试需求、风险和澄清问题；由 QA 对照原文审核，再把确认后的结果转成测试场景。这个练习能验证上下文、输出格式和审核流程，不需要先搭建完整 Agent。

01 — Requirement Analysis（需求分析）

目标： 从 PRD、用户故事、API Spec、原型和变更说明中提炼可测试的需求、规则、假设、歧义和待澄清问题。

传统工作： 阅读文档、开评审会、拆流程、整理规则和问题，再把分析结果放进 XMind、表格或测试管理工具。

AI 可协助：

汇总多个需求文件并对齐术语。
提取角色、前置条件、主流程、异常流程和业务规则。
找出缺失定义、相互矛盾的规则、边界条件和依赖项。
将需求映射到待测行为，输出澄清问题清单。

推荐输入： PRD / User Story、接口文档、原型说明、相关历史 Bug、术语表、明确的版本范围。先做脱敏，不输入不应外传的个人或商业敏感数据。

工作流：

需求资料 → AI 摘要与结构化提取 → QA 核对原文 → 标注未知项 / 冲突 → 与产品确认 → 冻结测试基线

输出建议： 需求点 ID、用户/角色、条件、业务规则、预期行为、异常/边界、依赖、歧义、来源位置、需确认的问题。

人工检查： 每个结论都能追溯回原文；AI 不得把猜测补成产品规则；对关键金额、权限、状态转换和时间条件逐条确认。

Prompt 起点：

你是一名资深 QA。请只根据我提供的需求材料做分析，不要自行补充未写明的产品规则。

请输出：
1. 需求范围与不在范围内的内容
2. 用户角色、前置条件、主流程和异常流程
3. 业务规则与状态变化
4. 边界条件、依赖和潜在风险
5. 原文中不明确、冲突或缺失的内容（附原文位置或引用）
6. 需要产品/开发确认的问题

对无法从资料确认的内容标记为“待确认”，并说明原因。

[粘贴需求内容 / 提供文件]

成熟度： 可以从纯对话与文件分析开始；有稳定模板和知识库后，再加入检索历史缺陷的能力。

02 — Risk Analysis & Test Planning（风险分析与测试计划）

目标： 按业务影响、变更范围、故障可能性和检测难度确定测试重点与覆盖策略。

传统工作： QA 根据经验、架构和历史线上问题判断风险，安排测试范围、资源和优先级。

AI 可协助：

根据需求变化与历史 Bug 提出风险候选项。
把风险关联到模块、用户旅程、接口、数据和依赖服务。
生成测试范围、测试层级和优先级建议。
对比计划覆盖与风险清单，提示未覆盖项。

输入： 需求分析结果、代码或接口变更摘要、历史事故 / 缺陷、服务依赖图、发布范围和测试资源约束。

输出： 风险项、影响对象、发生条件、影响程度、可能性、优先级建议、验证方法、责任人 / 依赖、未覆盖风险。

人工检查： 风险分数不能假装是客观概率；由 QA / 产品 / 开发校准高影响场景，尤其是资金、权限、隐私和不可逆操作。

Prompt 起点：

基于以下需求变更、系统依赖和历史缺陷，列出测试风险候选项。

请为每项提供：风险描述、触发条件、影响对象、影响严重度（高/中/低及理由）、建议验证方式、依据来源、置信度、仍需确认的信息。
不要把缺少证据的判断描述为事实。最后给出测试范围建议和明确未覆盖项。

[粘贴资料]

03 — Test Scenario & Case Generation（测试场景与用例设计）

目标： 将已确认的需求和风险转成可执行、可追溯、可评审的测试场景和测试用例。

AI 可协助：

从需求生成正向、反向、边界、状态、权限、兼容性和异常场景候选项。
使用等价类、边界值、决策表、状态迁移等方法扩充覆盖。
将自然语言用例转成团队模板或 CSV / JSON 格式。
检查重复用例、缺少前置条件或预期结果的用例。

输出字段建议： Case ID、需求 ID、场景、优先级、前置条件、测试数据、步骤、预期结果、验证点、自动化适合度、来源。

人工检查： 检查需求覆盖、可执行性、预期结果是否明确、数据是否可构造、场景是否重复；AI 不能凭空创造产品行为。

Prompt 起点：

根据已确认的需求与风险清单，生成测试场景和详细测试用例。

约束：
- 每条用例对应一个明确验证目标；标注关联需求 ID。
- 覆盖正常、异常、边界、权限、状态变化和数据一致性场景；只选择与本需求相关的类别。
- 每条用例写清前置条件、数据、步骤和可观察的预期结果。
- 资料不足时列为“待确认”，不得自行发明预期结果。
- 先输出场景覆盖矩阵，再输出详细用例。

[需求基线]
[风险清单]
[团队用例格式]

04 — Test Automation（测试自动化）

目标： 在人审设计的基础上，辅助编写、维护和诊断自动化测试。

AI 可协助：

根据稳定的测试用例和接口契约生成 Pytest / API 测试初稿。
生成测试数据构造、断言、参数化和清理逻辑建议。
解释失败日志，区分测试脚本问题、环境问题和疑似产品缺陷。
将已有重复脚本抽成公共 fixture 或 helper 的建议。

工作流：

已审核用例 + API 契约 + 项目规范
  → 生成脚本草稿
  → QA / 开发审查
  → 隔离测试环境执行
  → 查看报告与日志
  → 修订并加入 CI（满足稳定性条件后）

人工检查： 校验断言真实有效；避免只断言 HTTP 200；检查清理和幂等；不可让生成脚本直接连生产环境、使用真实账户或执行破坏性操作。

Prompt 起点：

请根据以下已审核 API 测试用例和本项目现有测试风格，生成 Pytest 测试草稿。

要求：使用明确断言、可重复测试数据、必要的清理步骤；不要在代码中写入密钥；不调用生产环境；对未明确的接口行为使用 TODO 注释并列出问题。先说明拟新增/修改的文件，再给出代码。

[测试用例]
[API Spec]
[项目现有测试代码 / 规范]

工具层级： 代码助手生成初稿 → 本地运行和审查 → CI 执行。生成代码不是通过测试的证据，实际执行结果才是。

05 — UI / End-to-End Testing（界面与端到端测试）

官方案例： QA your app with Computer Use。官方案例建议指定测试环境和核心流程，并将问题整理为复现步骤、预期结果、实际结果与严重程度；也提醒提供账号状态、测试数据、Feature Flag 等前置条件。

AI 可协助： 在可访问的测试环境中操作页面、覆盖真实用户旅程、观察界面和流程问题，整理结构化缺陷草稿。

工作流：

指定环境 / 账号 / 数据 / 关键流程
  → AI 操作界面并观察
  → 收集截图 / 状态 / 步骤等证据
  → QA 重现并验证
  → 创建缺陷草稿 / 扩展测试

Prompt 起点：

请在 [环境名称 / URL] 验证以下用户流程：[流程 1]、[流程 2]。

测试准备：账号状态 [说明]；测试数据 [说明]；功能开关 [说明]。
关注问题类型：[功能 / 布局 / 文案 / 视觉回归]。
每个发现请提供：标题、复现步骤、预期结果、实际结果、严重程度建议、证据位置。
遇到阻塞时按以下规则处理：[停止 / 继续其他流程]。结束时总结覆盖范围、未完成项和需要人工确认的发现。

人工检查： 复现问题；确认环境和账号状态；区分系统缺陷、测试数据问题、网络/环境问题；检查截图或日志；未经审核不直接提交高影响缺陷或修改生产数据。

适用限制： 页面变化、登录验证、动态内容、权限、CAPTCHA、多因素认证和网络状态可能影响自动操作。结果应视为一次测试运行的证据，不等同于完整覆盖。

06 — Bug Analysis & Triage（缺陷分析与分诊）

官方案例： Automate bug triage 的相关链接指向 Automate bug triage；Use Cases 将其标记为 Automation / Quality。案例思路是从近期告警、问题、失败检查、日志和聊天报告汇总信号并辅助分诊。

AI 可协助：

汇总分散在工单、日志、监控和沟通记录中的相关信息。
对缺陷做候选分类、重复项聚类、影响模块建议。
提取复现步骤、环境信息、错误堆栈和缺失信息。
给出可能关联的近期变更或历史相似缺陷线索。

输出： 缺陷摘要、类别候选、影响面、复现信息完整度、相似项、证据链接、建议优先级及理由、需要 QA 确认的问题。

人工检查： 不能只依据语气或出现频次判优先级；核实实际影响和复现证据；相似缺陷合并前确认不是不同根因；最终严重性和优先级由团队流程决定。

Prompt 起点：

请基于下面的工单、日志和历史问题做缺陷分诊建议，不要修改或关闭工单。

请输出：摘要、候选类别、影响模块、复现信息缺口、可能重复项（说明相似证据）、可能关联的变更、建议优先级及理由、QA 必须确认的问题。
每个判断标注来源；证据不足时写“无法判断”。

[工单 / 日志 / 历史问题]

07 — Regression & CI（回归与持续集成）

目标： 根据变更风险选择有价值的回归范围，并让检查在一致的条件下重复运行。

AI 可协助：

阅读 PR 描述、代码 diff、依赖关系和历史失败，提出受影响模块。
将变更映射到回归测试候选集，并解释选择依据与遗漏风险。
汇总 CI 失败原因、测试不稳定信号和最近变更。
为测试报告生成便于评审的摘要和证据索引。

官方相邻案例： Review GitHub pull requests、Fix a finding from your security scan、Run security scans in CI。这些案例展示代码变更评审、修复验证和 CI 扫描的模式；页面应明确它们是相邻案例，不能替代业务回归策略。

人工检查： 不要让 AI 单独决定发布；区分 flaky test、环境故障和产品回归；检查“未运行”的测试和变更关联；关键路径需有明确的发布标准。

Prompt 起点：

基于 PR 描述、代码变更摘要、模块依赖和现有测试清单，提出本次回归测试建议。

请分为：必须执行、建议执行、可暂缓三组。每项包含关联变更、覆盖风险、选择理由、依赖环境和未覆盖风险。不要声称未运行的测试已经通过，也不要做发布结论。

[PR / diff 摘要]
[模块依赖]
[测试清单与历史结果]

08 — Agent / LLM Evaluation（Agent 与 LLM 评估）

目标： 把 AI 应用的预期行为转成可重复运行、可比较的评估集。

与传统测试的联系： 传统测试也需要输入、预期和断言；LLM/Agent 测试的挑战是输出可能有合理变化，且需要评估语义质量、工具使用、拒答、安全边界和多步任务完成情况。不能只用单条 Prompt 的主观体验判断质量。

推荐评估闭环：

产品预期 / 风险
  → 代表性数据集与边界样例
  → 确定性检查 + 语义评分 + 人工抽检
  → 多版本、多模型、多次运行对比
  → 分析失败类型与回归
  → 更新提示、检索、工具或策略
  → 再跑评估集

首版术语说明： Eval 是对模型/Agent 行为的系统化评估；Eval set 是输入样例及预期或评分规则的集合；Grader / Evaluator 是按规则检查输出的评估器。Promptfoo 是一个可用于构建模型评估测试集的工具示例，不是唯一选择。

官方案例： Add evals to your AI application 展示使用 Codex 将 expected behavior 转成 Promptfoo eval suite。

测试维度建议：

任务正确性：是否达成用户目标？
指令遵循：是否符合格式、范围和约束？
检索质量：引用的知识是否相关、准确、不过期？
工具使用：是否调用正确工具、参数是否安全、是否处理失败？
稳健性：改写、边界输入、缺失信息和对抗输入下表现如何？
安全性：是否拒绝越权或不允许的操作，是否泄漏敏感信息？
可观测性：是否记录足以解释结果的输入、工具和错误信息？

输出字段建议： Case ID、输入、场景类别、预期行为、检查方法、实际输出、工具调用轨迹、评分、失败原因、版本信息。

人工检查： 评估标准是否代表真实用户需求；评分器是否和人工判断一致；语义评分是否可解释；不要只看总分，要分错误类型、关键业务场景和安全风险分析。

Prompt 起点：

根据下面的 Agent 规格和预期行为，设计一组可重复的 Eval cases。

覆盖：正常任务、边界输入、缺失信息、工具失败、越权请求、安全约束和关键业务风险。每条包含输入、预期行为、明确的通过/失败判据、评分方式、风险等级和设计理由。对无法自动判定的语义要求标记为“人工评审”。避免只写 happy path。

[Agent 规格]
[预期行为]
[安全与业务约束]

人工审核与质量边界

所有关键结论都应有来源或运行证据。
不要把 AI 的猜测写成产品规则、根因或通过结论。
对权限、隐私、资金、状态转换和不可逆操作设置人工检查点。
记录模型、提示词、输入版本、工具版本和运行环境，保证结果可比较。
发现误报、漏报或无法执行的建议时，回到需求和测试基线修订，而不是只追求更长的输出。

官方案例与来源

以下链接是本文选取案例时参考的官方页面。它们展示的是特定工具和任务的工作方式，不代表所有版本、套餐或本地环境都具备相同能力：

QA your app with Computer Use：用于 UI / 端到端测试和缺陷记录。
Automate bug triage：用于多来源信号汇总和分诊辅助。
Add evals to your AI application：用于把预期行为整理为可编辑、可复跑的评估集。
Review GitHub pull requests：用于变更风险分析和回归线索补充。

页面内容和工具能力可能更新。发布或复用这些案例时，应重新检查官方页面、环境限制和适用边界。