product-qa

name	product-qa
description	QA 证据链方法论。把测试请求（自测、回归、Bug 复核、发布判断）转成可复核的证据链：事实与判断分离、零证据禁终审、失败先归因再定性、go/no-go 四态结论。在用户要求测试/验收/质量报告/发布评估，或改动完成后需要自测收口时使用。
trigger	["测试","QA","回归","自测","验收","bug 归因","发布判断","收口","质量报告"]

QA 证据链

把测试请求转成一条可复核的证据链。判断以业务风险、证据等级和真实执行为准，不以用例数、截图数或"自动化变绿"代替质量。

不可绕过的规则

1. 先锁请求，再做 QA。 明确测试对象、范围、载体和输出格式（用户指定的范围高于默认）。范围外的发现单独标注，不混入本轮结论。
2. 分开事实与判断。 事实引来源（命令输出、日志、复现步骤），推断写依据，缺口记「待确认」。计划、口述、代码注释不得冒充执行证据。
3. 零证据禁终审。 缺少决定性执行证据时，结论只能是 undetermined，不能建议上线也不能否定上线。
4. 失败不等于 Bug。 先归因再定性：产品行为如此 / 需求如此 / 环境·数据问题 / 测试脚本自身问题 / 待确认。保留首败现场（完整命令、输出、时间）。
5. 预跑不等于正式结论。 单次小样本、孤立现象、临时环境的失败保持「待确认」，不得直接升级为正式 Bug。
6. 有未执行就有未验证范围。 存在未执行或被阻塞的用例时，结论必须列出 unverified 清单，不得用通过率掩盖。
7. P0 就是阻断项。 标为 P0 的 Bug 必须出现在发布阻塞清单里，两个集合完全相等；不允许「标 P0 但照常发」。
8. 副作用先授权。 删除、写入生产、群发、付费类测试先确认授权与回滚方式，再执行。

执行路径

请求类型	最小路径
改动后自测	列改动面 → 按风险选最小验证集 → 真实执行 → 结论 + unverified 清单
测试方案/用例设计	拆需求（前置→触发→规则→结果→副作用）→ 风险排序 → 用例 + 可观察预期
回归/验收执行	方案 → 真实执行（记录证据）→ 失败归因 → 报告
Bug 复核	复现 → 单一假设归因 → 影响范围 → 定级（S1 严重/S2 高/S3 中/S4 低）
发布判断	汇总证据 → 四态结论

失败归因五分类

记录每次失败时必须先回答：这是哪一类？

1. 产品缺陷：代码行为与需求不符 → 转 Bug，定级。
2. 需求歧义：行为符合代码但需求本身没说清 → 记「待确认」，问清预期。
3. 环境/数据：换环境或修数据后消失 → 记录环境差异，不算 Bug。
4. 测试自身：脚本/命令/断言写错 → 修测试，不算 Bug。
5. 待确认：证据不足无法归因 → 保持开放，列出解锁所需的下一步。

发布结论四态

• go：计划内 P0/P1 有正式执行证据且通过，无开放 S1/S2。
• conditional_go：证据足够，条件、责任人、时限、回滚明确。
• no_go：执行证据证实阻断失败，或准出条件被证实不满足。
• undetermined：缺少决定性输入或执行证据（这是诚实态，不是失败态）。

只跑冒烟时必须限定结论范围为「冒烟内」；通过率不得掩盖 P0、待确认和未覆盖项。

报告结构（用户可见）

结论先行 → 覆盖范围（含 unverified）→ 执行证据（真实命令与输出摘要）→ Bug 清单（现象/归因/定级/证据）→ 待确认清单 → 建议。正文不暴露内部过程旁白（跑了什么脚本、改了什么状态机），读者要的是业务结论。

自测场景的最小闭环

改动完成后：跑通关键路径 → 边界/异常各抽一个 → 输出一句话结论（通过什么、没验什么）。三个环节缺一不可——只报「通过」不列「没验什么」等于没自测。