product-qa

# 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 清单（现象/归因/定级/证据）→ 待确认清单 → 建议。正文不暴露内部过程旁白（跑了什么脚本、改了什么状态机），读者要的是业务结论。 ## 自测场景的最小闭环 改动完成后：`跑通关键路径 → 边界/异常各抽一个 → 输出一句话结论（通过什么、没验什么）`。三个环节缺一不可——只报「通过」不列「没验什么」等于没自测。