qa-expert

QA 专家

使用 AAA 测试结构和 OWASP 安全类别，设置测试用例、执行跟踪、缺陷报告和 QA 交接。

何时使用此技能

在以下情况下触发此技能：

• 为新项目或现有项目搭建 QA 基础设施
• 编写标准化测试用例（符合 AAA 模式）
• 执行全面的测试计划并跟踪进度
• 实施安全测试（OWASP Top 10）
• 按正确的严重性级别（P0-P4）提交缺陷
• 生成 QA 报告（每日摘要、每周进度）
• 计算质量指标（通过率、覆盖率、门槛）
• 为第三方团队交接准备 QA 文档
• 启用由大模型驱动的自主测试执行

快速开始

一条命令即可初始化：

uv run "<qa-expert-dir>/scripts/init_qa_project.py" "<project-name>" "<project-root>"

创建的内容：

• 目录结构（tests/docs/、tests/e2e/、tests/fixtures/）
• 跟踪 CSV（TEST-EXECUTION-TRACKING.csv、BUG-TRACKING-TEMPLATE.csv）
• 文档模板（BASELINE-METRICS.md、WEEKLY-PROGRESS-REPORT.md）
• 用于自主执行的 QA 主提示词
• 包含准备步骤和生成文件链接的 README

输出目录为项目根目录；脚本会在其中附加 tests/。请使用一个全新的 目标目录：初始化会覆盖其中的模板文件。替换 CSV 示例行、编写测试规范， 并在执行前绑定项目测试框架。 从此 Skill 的目录（而非目标项目）解析 <qa-expert-dir>。

用于自主执行：按照主提示词进行准备、限定范围的执行和中断恢复。初始化 会创建模板，但不会运行测试或安装调度程序。

核心功能

1. QA 项目初始化

初始化 QA 目录和模板：

uv run "<qa-expert-dir>/scripts/init_qa_project.py" "<project-name>" "<project-root>"

创建目录结构、跟踪 CSV、文档模板，以及用于自主执行的主提示词。

适用场景：从零开始开展 QA，或迁移到结构化 QA 流程。

2. 编写测试用例

按照 AAA 模式（Arrange-Act-Assert）编写标准化且可复现的测试用例：

1. 阅读模板：assets/templates/TEST-CASE-TEMPLATE.md
2. 遵循结构：前置条件（Arrange）→ 测试步骤（Act）→ 预期结果（Assert）
3. 指定优先级：P0（阻断级）→ P4（低）
4. 包含边界情况和潜在缺陷

测试用例格式：TC-[CATEGORY]-[NUMBER]（例如，TC-CLI-001、TC-WEB-042、TC-SEC-007）

参考：请参阅 references/google_testing_standards.md，了解 AAA 指南，以及针对项目的覆盖率和发布验收要求。

对于跨平台适配器，或与其他运行时／实现的兼容性，在选择模拟对象、预期结果或受支持版本的用例前，先加载运行时兼容性验收。

对于支付、采购、履约或退款恢复，在选择用例前，先加载事务恢复验收。对于架构升级、会计视图或集成测试夹具，加载迁移与测试夹具验收。 对于基于文件的状态、快照依赖检查、恢复，或 CLI 参数、包装器、兼容性别名、输出或读取成本变更，加载文件持久化与 CLI 验收。 对于可能授权某项操作的准入决策、账户／资源绑定或恢复，在选择故障时机或副作用断言前，加载准入与恢复验收。 对于可能与用户更改发生竞态的响应、规范化或建议编辑，在选择时机、会话和相关对象用例前，加载异步编辑与冲突验收。 将这些方案与应用现有的契约和测试框架绑定； 保留通用的 AAA、跟踪和报告工作流。

3. 测试执行与跟踪

真实依据原则（至关重要）：

• 测试用例文档（例如 02-CLI-TEST-CASES.md）= 测试步骤的权威来源
• 跟踪 CSV = 仅记录执行状态（不要将 CSV 作为测试规范的依据）
• 参见 references/ground_truth_principle.md，了解如何避免文档与 CSV 不一致的问题

手动执行：

1. 从类别文档中读取测试用例（例如 02-CLI-TEST-CASES.md）← 始终从这里开始
2. 严格按照文档记录的步骤执行测试
3. 每次测试后立即更新 TEST-EXECUTION-TRACKING.csv（绝不要批量更新）
4. 如果测试失败，在 BUG-TRACKING-TEMPLATE.csv 中提交缺陷

自主执行（推荐）：

1. 从 references/master_qa_prompt.md 复制主提示词
2. 粘贴到大模型会话中
3. 执行已授权的批次，跟踪每项结果，提交已复现的缺陷并报告证据

中断后，读取检查点并核对不确定的副作用， 然后再选择首个未完成的测试。未来的执行需要有可用且 经过授权的主机运行器；仅有提示词无法让会话持续运行。

4. 缺陷报告

按照正确的严重程度分类提交缺陷：

必填字段：

• 缺陷 ID：按顺序编号（BUG-001、BUG-002……）
• 严重程度：P0（24 小时内修复）→ P4（可选）
• 复现步骤：编号列出，内容具体
• 环境：操作系统、版本、配置

严重程度分类：

• P0（阻断级）：安全漏洞、核心功能故障、数据丢失
• P1（严重）：主要功能故障，但有解决方法
• P2（高）：次要功能问题、边缘情况
• P3（中）：外观问题
• P4（低）：文档拼写错误

参考：初始化会创建 tests/docs/templates/BUG-TRACKING-TEMPLATE.csv。

5. 质量指标计算

根据当前跟踪行计算指标：

uv run "<qa-expert-dir>/scripts/calculate_metrics.py" "<project-root>/tests/docs/templates/TEST-EXECUTION-TRACKING.csv"

指标仪表板包括：

• 测试执行进度（X/Y 个测试，完成 Z%）
• 通过率（已通过/已执行 %）
• 唯一关联的缺陷 ID 和测试优先级明细
• 质量门禁状态（每项门禁标记 ✅/❌）

scripts/calculate_metrics.py 负责内置检查和 CSV 字段解析。将结果记录为 ✅ PASSED 或 ❌ FAILED，将已完成状态记录为 Completed。其 P0 检查仅读取关联的缺陷 ID 和跟踪备注中的 P0；不会从缺陷日志读取缺陷严重程度。覆盖率、OWASP 缓解措施和发布验收需要各自的项目证据。 CLI 会输出未通过的检查，但仍以 0 退出；它是报告工具，不是发布门禁。请遵循发布验收。按需计算当前总数，不要维护另一张汇总表。

6. 进度报告

为利益相关方生成 QA 报告：

每日摘要（每天结束时）：

• 已执行的测试、通过率、已提交的缺陷
• 阻碍事项（或无）
• 明日计划

每周报告（每周五）：

• 使用模板：WEEKLY-PROGRESS-REPORT.md（由初始化脚本创建）
• 与基线对比：BASELINE-METRICS.md
• 评估质量门禁和趋势

参考：针对具体任务的报告提示词，请参见 references/llm_prompts_library.md。

7. 安全测试（OWASP）

实施 OWASP Top 10 安全测试：

覆盖目标：

1. A01：访问控制失效 - RLS 绕过、权限提升
2. A02：加密失效 - 令牌加密、密码哈希
3. A03：注入 - SQL 注入、XSS、命令注入
4. A04：不安全设计 - 速率限制、异常检测
5. A05：安全配置错误 - 过于详细的错误信息、默认凭据
6. A07：身份验证失效 - 会话劫持、CSRF
7. 其他：数据完整性、日志记录、SSRF

从目标项目的权威发布政策中选择安全验收标准。

每项安全测试都遵循 AAA 模式，并记录具体攻击向量。

第 1 天入职

新 QA 工程师请遵循 第 1 天入职指南， 了解流程、检查点和项目设置示例。

自主执行（⭐ 推荐）

使用单条主提示词启用由 LLM 驱动的自主 QA 测试：

阅读：references/master_qa_prompt.md

功能：

• 在检查点和副作用核对后，从第一个尚未完成的测试继续
• 执行项目批准的测试计划和日程
• 自动跟踪结果（每次测试后更新 CSV）
• 自动提交 Bug（为失败项创建 Bug 报告）
• 自动生成报告（每日摘要、每周报告）
• 遇到 P0 Bug 时停止，并在当前对话中报告；外部升级需要授权

优点：

• Bug 文档记录一致
• 即时查看进度

用法：复制主提示词，将其绑定到实际项目，并执行已获授权的批次。重新调用即可继续；无人值守执行时，使用宿主已授权的运行器，并单独验证其活动。

针对你的项目进行调整

小型项目（50 个测试）

• 时间安排：2 周
• 类别：2-3 个（例如，前端、后端）
• 每日：5-7 个测试
• 报告：仅每日摘要

中型项目（200 个测试）

• 时间安排：4 周
• 类别：4-5 个（CLI、Web、API、DB、安全）
• 每日：10-12 个测试
• 报告：每日 + 每周

大型项目（500+ 个测试）

• 时间安排：8-10 周
• 类别：6-8 个（多个组件）
• 每日：10-15 个测试
• 报告：每日 + 每周 + 双周利益相关方报告

参考文档

通过随附的参考资料查看详细指南：

• references/day1_onboarding.md - 新 QA 工程师入职指南
• references/master_qa_prompt.md - 准备、执行、恢复和报告 SOP
• references/llm_prompts_library.md - 特定 QA 任务的提示词
• references/google_testing_standards.md - AAA 模式、覆盖率规划、发布验收和快速失败验证
• references/ground_truth_principle.md - 防止文档/CSV 同步问题（对测试套件完整性至关重要）

资源与模板

测试用例模板和 Bug 报告格式：

• assets/templates/TEST-CASE-TEMPLATE.md - 完整模板，含 CLI 和安全示例

脚本

用于 QA 基础设施的自动化脚本：

• scripts/init_qa_project.py - 初始化 QA 基础设施（单命令设置）
• scripts/calculate_metrics.py - 生成质量指标仪表板

常见模式

模式 1：从零开始 QA

1. uv run "<qa-expert-dir>/scripts/init_qa_project.py" my-app "<fresh-project-root>"
2. Fill in BASELINE-METRICS.md (document current state)
3. Write test cases using assets/templates/TEST-CASE-TEMPLATE.md
4. Copy master prompt from references/master_qa_prompt.md
5. Verify the project harness and authorization, then execute the approved batch

模式 2：LLM 驱动的测试（自主）

1. Read references/master_qa_prompt.md
2. Copy the master prompt and bind the project paths
3. Paste to LLM conversation
4. LLM executes the approved batch using project test specifications
5. LLM updates tracking CSVs automatically
6. LLM generates weekly reports automatically

模式 3：添加安全测试

1. Read references/google_testing_standards.md (OWASP section)
2. Write TC-SEC-XXX test cases for each OWASP threat
3. Apply the project's approved security acceptance
4. Document mitigations in test cases

模式 4：第三方 QA 交接

1. Ensure all templates populated
2. Verify BASELINE-METRICS.md complete
3. Package tests/docs/ folder
4. Include references/master_qa_prompt.md for autonomous execution
5. QA team verifies prerequisites, completes the applicable onboarding and follows the project schedule

成功标准

在满足以下条件时，此技能即可发挥作用：

• ✅ 任何工程师都能复现测试用例
• ✅ 客观衡量质量门槛
• ✅ 完整记录 Bug 及其复现步骤
• ✅ 实时查看进度（CSV 跟踪）
• ✅ 启用自主执行（LLM 可执行完整计划）
• ✅ 第三方 QA 团队能够找到测试工具集，并从已验证的前置条件处继续