提测时间被压缩，你怎么取舍？

时间不够时我按风险排优先级：先测核心链路——用户进得来、钱不出错、数据不丢；再测本次变更相关——改动点与影响面分析；然后是历史缺陷密集区；界面体验类最后或下版本补。同时把风险透明化：哪些没测到、可能的后果，邮件同步干系人，让决策有依据。

我处理过一次提测压缩到一天的版本：先做变更影响分析——改动集中在支付回调，于是 P0 锁定支付全链路加对账；P1 覆盖回调涉及的状态机流转；P2 用自动化回归兜住非相关模块主流程。手工聚焦新逻辑、自动化覆盖旧风险。上线后零故障，复盘时我把『变更影响分析』固化成了提测单必填项。

时间压力下的取舍我讲机制而不是英雄主义：事前——需求阶段就介入把可测性提上来，把大需求拆小降低单次回归面；事中——分级用例库常备，P0 冒烟 30 分钟可跑完，变更关联分析半自动生成回归范围；事后——风险登记与线上监控加密观察期。目标不是每次都赌赢，而是让『压缩』变成可管理的过程。

追问『上线后出问题谁负责』：质量是团队决策的结果，测试提供风险信息，坚持上线是共同决定——但前提是测试确实把风险讲清楚了；『怎么快速判断影响面』：代码 diff 加调用链分析加需求关联映射；『自动化这时候的作用』：非变更区的自动化释放手工全部投入新逻辑。