回答。

在发布阶段组织手动测试是为了快速有效地查找准备发布版本中的缺陷，重点关注最关键和常用的功能。

问题背景： 过去，发布往往伴随着“夜间赶工”：测试人员急于检查所有内容，导致测试质量受损，bug进入生产环境，资源使用效率低下。逐渐发现，通过明确系统化的优先级，可以在更短的时间内取得更好的结果。

问题： 发布前的测试时间有限，无法验证所有内容，此外人因因素增加——疲劳、匆忙、压力。经常有关键bug在发布后才出现，损害产品声誉，导致团队混乱。

解决方案：

• 与业务、分析师、开发人员一起评估关键和具有商业价值的场景。
• 制定发布检查清单，列出所谓的“关键”场景——这些场景使用频率高或风险大。
• 进行最终的手动烟雾测试和健全性测试：检查系统启动、登录流程、订单处理、支付等。
• 明确划分责任区域：谁负责测试数据，谁负责缺陷报告，谁负责与开发团队的沟通。

关键特点：

• bug优先级：首先找到并升级关键缺陷。
• 使用简短、快速执行的测试用例和检查清单。
• 与开发团队进行及时沟通，以快速修复问题。

设陷问题。

在发布前是否可以“多保险”手动检查整个应用程序？

不可以，通常没有时间进行全面手动测试——专注于关键场景的有序方法能获得更好的结果。

在发布前是否应该公开“轻微”bug，以便团队提前了解？

不应该，在发布模式下，只应升级关键和阻塞缺陷，而将较小的问题记录为已知问题，并在发布后处理。

发布阶段是否必须手动编写详细的测试用例？

不需要，通常使用检查清单或从测试用例中提取的迷你脚本来工作更简单、更快，可以迅速覆盖相关场景。

常见错误和反模式

• 将测试推迟到最后几小时——导致一切都在匆忙中完成，质量下降。
• 在以关键场景为代价而检查不常用或不重要的场景。
• 在发布前缺少最终的烟雾/健全性测试。

生活中的例子

负面案例

发布测试在晚上进行，顺便粗略检查文件，忘记了关键的支付流程。第二天用户普遍无法支付订单。

优点：

• 检查速度快。

缺点：

• 关键bug未被发现。
• 半夜的压力风险，与开发团队的沟通失误。

正面案例

在发布前只关注关键场景（登录、支付、订单保存、与合作伙伴的集成）。通过检查清单总结结果，bug立即升级。

优点：

• 降低发布缺陷数量。
• 团队协作顺畅，重要任务的执行速度快。

缺点：

• 少量小bug可能会遗留，但作为已知问题推进，不会阻止发布。