genapohub 测试 / QA 工程师方案产出指南
Overview
本技能将测试/QA 领域的方法论转化为可执行的工作流。当用户提出质量保障相关需求时，先识别该需求属于 5 类场景中的哪一类，再按对应场景的产出清单生成完整方案——从测试体系建设到性能压测，覆盖质量保障的全生命周期。
详细的方法论、各场景产出清单、测试金字塔规范、Bug管理规范、性能测试场景模板、质量检查清单均存放在 references/QA测试方法论.md，在执行前必须读取对应章节。
触发条件
- 用户需要搭建测试体系或制定测试策略
- 用户需要设计自动化测试框架或方案
- 用户需要性能压测方案
- 用户需要设计测试用例、Bug管理流程
- 用户提到"测试""QA""自动化测试""性能测试""压测""单元测试""E2E测试""缺陷管理""质量保障"等关键词
记忆系统
本技能的完整记忆管理规则（写日志/轮转归档/自清理）定义在 references/记忆规则.md，执行前必须读取。
- 执行前（必须）：读取
references/记忆规则.md中的 Step 0 加载规范 +.skills-memory/MEMORY.md本技能对应分段 +.skills-memory/YYYY-MM-DD.md（今日日志，如存在） - 执行后（硬性要求，不可跳过）：追加
[qa-testing-guide] 场景描述 → 关键决策到.skills-memory/YYYY-MM-DD.md；如有可复用决策，去重后追加到 MEMORY.md 对应分段。记忆写入是交付物的一部分——如果因环境限制无法写入，必须在最终回复中明确告知用户「记忆未写入」及原因，不得静默跳过 - 轮转检查：
- 独立使用：按
references/记忆规则.md中的触发条件和完整轮转算法执行归档 - 被 team-orchestrator 调度时：跳过全部记忆操作（写入 + 轮转），由调度官 Step 6（写日志）/ Step 7（轮转归档）统一处理
- 独立使用：按
执行流程
按以下 5 步顺序执行，不可跳步。
Step 1: 需求理解
- 解析用户输入的测试需求
- 提取关键信息：项目技术栈、测试现状、测试类型需求（功能/性能/安全/兼容）、团队规模、质量目标
- 主动提问补全缺失信息（一次最多 2-3 个问题）
Step 2: 场景识别
读取 references/QA测试方法论.md 的"一、场景识别"章节：
| 场景 | 名称 | 判断条件 | 产出量 |
|---|---|---|---|
| 场景一 | 0→1 测试体系建设 | 全新项目、无测试基础设施 | 10-12类 |
| 场景二 | 中大型测试需求 | 新增模块全面测试、新增测试类型 | 6-8类 |
| 场景三 | 单功能测试/Bug验证 | 单个功能测试、Bug回归 | 2-3类 |
| 场景四 | 大版本测试策略升级 | 框架迁移、覆盖率大幅提升 | 8-10类 |
| 场景五 | 测试技术预研 | 新工具评估、技术探索 | 3-4类 |
Step 3: 与用户确认场景
输出场景判断、判断依据、产出清单、预估周期，确认后进入产出。
Step 4: 按清单产出方案
读取 references/QA测试方法论.md 对应场景章节。
专家蒸馏增量（2026-09-06 并入）：涉及 AI 生成代码的测试门禁（先写测试 / 测试完整性反作弊门 / 回归率=0 / 改动影响分析 / 视觉合规扫描）时，读取
references/expert-distill/mvp-qa-蒸馏.md——QA 先写测试、开发按测试实现、交付前跑反作弊 5 类检测与生产就绪 7×3 评级，杜绝"AI 自己写实现又自己写测试"的同义绿灯。交付前人工评审阶段，另读取references/expert-distill/code-review-蒸馏.md（火眼眼：评审五维焦点 / 🔴🟡💭 三级问题分级 / 评论三要素格式 / 当导师不当门卫）——机器门禁过后，需要判断力的部分按本文档走。
产出要求：
- 测试策略遵循金字塔模型（单元60% / 集成30% / E2E 10%）
- 测试用例覆盖：正常路径 + 异常路径 + 边界值 + 权限场景
- 性能测试含5种场景：基准/负载/压力/稳定性/尖峰
- Bug管理含完整的生命周期和优先级/严重性定义
- CI/CD集成质量门禁（覆盖率/通过率/安全扫描）
- 必须读取并应用"十一、超越AI味"章节：产出方案时融入真实岗位经验，拒绝模板化输出
- 优先使用可填空模板：方法论通用规范章节末尾的「### XX模板（可填空）」，直接按占位符填充（无对应模板则按清单产出）
- 产出后保存为 Markdown 文件
Step 5: 质量检查
读取 references/QA测试方法论.md 的"十、产出质量检查清单"：
测试策略覆盖金字塔三层
测试类型覆盖充分（功能/性能/安全/兼容）
测试用例含正常+异常+边界+权限
覆盖率目标明确
性能测试场景完整
CI/CD质量门禁定义清晰
缺陷管理规范完整
去AI味：对照"十一、超越AI味"逐条自检，拒绝模板化产出
记忆已写入（
.skills-memory/YYYY-MM-DD.md有本次会话条目，无则立即补写）
资源说明
references/QA测试方法论.md
完整的方法论文档，包含：5个场景产出清单、测试金字塔规范、用例编写规范、Bug管理规范、性能测试场景模板、质量检查清单。
注意事项
- 不要跳过 Step 3 的用户确认
- 测试金字塔比例不是教条，根据项目类型调整（后端重单元、前端重E2E、移动端重兼容）
- 自动化不是越多越好——UI自动化成本高、维护贵，优先API层自动化
- 性能测试必须规定明确的通过标准（P95<Xms、错误率<X%），不能只说"测一下"
- 安全测试（SAST/DAST/依赖扫描）是底线，不是可选项
岗位职责与产出标准（业界锚点 · 2026-08 学习）
现实岗位职责：①需求评审——从可测性角度提出建议；②测试计划制定——范围/策略/进度/资源；③测试用例设计——等价类/边界值/因果图/状态迁移/场景法；④测试执行——功能/性能/兼容/安全测试；⑤缺陷管理闭环——记录/分级/跟踪/回归；⑥自动化测试建设——Selenium/Appium/Pytest；⑦质量度量与报告——缺陷密度/用例执行率/逃逸率。
业界产出标准：《测试计划》（含准入准出标准）《测试用例规格说明书》（TCID/前置条件/输入/步骤/预期结果）《缺陷报告》（5W1H：What现象/When复现时机/Where模块/Why根因/Who触发/How步骤 + 严重级与优先级，遵循 IEEE 829）《测试执行报告》（通过率/缺陷密度/逃逸率/平均修复时长）《测试总结报告》（质量评估/风险预警/改进建议）。
交付衔接：测试方案交付给开发（Bug/修复指导）+ DevOps（上线检查清单）+ 项目管理（质量报告）