Web App 上线前冒烟测试清单：覆盖关键路径，不追求全量测试

1. 先定义冒烟测试不做什么

冒烟测试验证的是构建是否基本可用、核心流程是否被阻断，以及版本是否值得进入更深层测试。它通常不覆盖所有边界条件、性能压测、完整兼容矩阵或系统性的安全评估。

把这些边界写进任务，可以避免“测了几个页面”被误解为“产品已被全面验证”。上线决定仍要结合自动化测试、监控、变更风险和团队自己的发布标准。

2. 用业务风险选择关键路径

优先级来自失败影响与变化概率。登录、注册、下单、支付回调、核心创建流程、权限切换和关键数据保存，通常比低频设置页更值得进入冒烟范围。刚修改的模块、外部依赖和历史脆弱点也应加权。

每条路径应写成可执行步骤，并包含预期结果。不要用“检查工作台”这样的模糊描述；应写成“使用指定账号登录，打开工作台，确认订单列表加载，并进入一条订单查看状态与证据”。

3. 冻结版本与环境矩阵

同一套步骤在不同版本、域名、浏览器、设备尺寸或账号状态下可能产生完全不同的结果。报告必须记录测试 URL、构建或提交标识、执行时间、浏览器版本、视口、操作系统和账号前置状态。

浏览器矩阵不需要为了显得完整而无限扩大。根据真实用户分布和变更风险选择 1 至 3 个关键组合，并在合同里明确。若移动端是核心入口，至少覆盖一个真实移动视口；若功能依赖特定权限，还要覆盖允许与拒绝状态。

• 测试环境与精确 URL。
• 构建号、版本号或提交标识。
• 浏览器、操作系统与视口。
• 账号角色、数据前置条件与登录状态。
• 会导致立即停止测试的阻断条件。

4. 每个结果都交付可复现证据

通过项至少要说明执行了什么与实际结果；关键节点可以附截图。失败项需要更完整：最短复现步骤、预期结果、实际结果、环境、截图或录屏、控制台或网络线索，以及失败是否稳定复现。

自动化工具的通过日志不等于用户可见结果。对于购买、保存、权限与状态变化，应检查页面反馈和后端可观察结果。证据应服务于复查，而不是堆叠大量无法定位的截图。

5. 用清楚状态表达结果

建议至少区分通过、失败、阻断与未执行。阻断表示前置条件或更早故障让后续步骤无法继续；它不等于后续步骤通过。未执行项也不能被空白吞掉。

上线建议可以是通过、条件通过或不建议上线，但必须绑定明确门槛。例如任何 P0 失败即不建议上线；P1 失败需要风险接受人和回滚方案；被阻断的关键路径按未验证风险处理。

• PASS：实际结果与冻结预期一致。
• FAIL：可执行但结果不符合预期。
• BLOCKED：前置条件或更早故障阻止执行。
• NOT RUN：明确不在本次执行或因时间未执行。

6. 发布前的最终清单

冒烟报告的目标是让发布负责人快速判断，而不是展示测试过程有多复杂。首页应该给出范围、版本、总体结果、阻断项、未覆盖风险与建议。

• 关键路径与风险优先级已确认。
• 测试版本、环境和账号状态可追踪。
• 每条路径有步骤、预期与实际结果。
• 失败项有最短复现路径与对应证据。
• 阻断项和未执行项没有被算作通过。
• 浏览器与视口覆盖符合真实风险。
• 上线门槛、风险接受人与回滚条件明确。
• 报告说明冒烟测试未覆盖的范围。