| name | product-qa |
| description | QA 证据链方法论。把测试请求（自测、回归、Bug 复核、发布判断）转成可复核的证据链：事实与判断分离、零证据禁终审、失败先归因再定性、go/no-go 四态结论。在用户要求测试/验收/质量报告/发布评估，或改动完成后需要自测收口时使用。 |
| trigger | ["测试","QA","回归","自测","验收","bug 归因","发布判断","收口","质量报告"] |
QA 证据链
把测试请求转成一条可复核的证据链。判断以业务风险、证据等级和真实执行为准，不以用例数、截图数或"自动化变绿"代替质量。
不可绕过的规则
- 先锁请求，再做 QA。 明确测试对象、范围、载体和输出格式（用户指定的范围高于默认）。范围外的发现单独标注，不混入本轮结论。
- 分开事实与判断。 事实引来源（命令输出、日志、复现步骤），推断写依据，缺口记「待确认」。计划、口述、代码注释不得冒充执行证据。
- 零证据禁终审。 缺少决定性执行证据时，结论只能是
undetermined，不能建议上线也不能否定上线。
- 失败不等于 Bug。 先归因再定性：产品行为如此 / 需求如此 / 环境·数据问题 / 测试脚本自身问题 / 待确认。保留首败现场（完整命令、输出、时间）。
- 预跑不等于正式结论。 单次小样本、孤立现象、临时环境的失败保持「待确认」，不得直接升级为正式 Bug。
- 有未执行就有未验证范围。 存在未执行或被阻塞的用例时，结论必须列出
unverified 清单，不得用通过率掩盖。
- P0 就是阻断项。 标为 P0 的 Bug 必须出现在发布阻塞清单里，两个集合完全相等；不允许「标 P0 但照常发」。
- 副作用先授权。 删除、写入生产、群发、付费类测试先确认授权与回滚方式，再执行。
执行路径
| 请求类型 | 最小路径 |
|---|
| 改动后自测 | 列改动面 → 按风险选最小验证集 → 真实执行 → 结论 + unverified 清单 |
| 测试方案/用例设计 | 拆需求（前置→触发→规则→结果→副作用）→ 风险排序 → 用例 + 可观察预期 |
| 回归/验收执行 | 方案 → 真实执行（记录证据）→ 失败归因 → 报告 |
| Bug 复核 | 复现 → 单一假设归因 → 影响范围 → 定级（S1 严重/S2 高/S3 中/S4 低） |
| 发布判断 | 汇总证据 → 四态结论 |
失败归因五分类
记录每次失败时必须先回答：这是哪一类？
- 产品缺陷：代码行为与需求不符 → 转 Bug，定级。
- 需求歧义：行为符合代码但需求本身没说清 → 记「待确认」，问清预期。
- 环境/数据：换环境或修数据后消失 → 记录环境差异，不算 Bug。
- 测试自身：脚本/命令/断言写错 → 修测试，不算 Bug。
- 待确认：证据不足无法归因 → 保持开放，列出解锁所需的下一步。
发布结论四态
go：计划内 P0/P1 有正式执行证据且通过，无开放 S1/S2。conditional_go：证据足够，条件、责任人、时限、回滚明确。no_go：执行证据证实阻断失败，或准出条件被证实不满足。undetermined：缺少决定性输入或执行证据（这是诚实态，不是失败态）。
只跑冒烟时必须限定结论范围为「冒烟内」；通过率不得掩盖 P0、待确认和未覆盖项。
报告结构（用户可见）
结论先行 → 覆盖范围（含 unverified）→ 执行证据（真实命令与输出摘要）→ Bug 清单（现象/归因/定级/证据）→ 待确认清单 → 建议。正文不暴露内部过程旁白（跑了什么脚本、改了什么状态机），读者要的是业务结论。
自测场景的最小闭环
改动完成后：跑通关键路径 → 边界/异常各抽一个 → 输出一句话结论（通过什么、没验什么）。三个环节缺一不可——只报「通过」不列「没验什么」等于没自测。
