08｜偶现的、复现不了的 bug 怎么处理？

开场先给态度定调：偶现 bug 不等于不存在，不能复现不等于不报。这句话先立住，面试官就放心了。

回答思路

第一步：第一时间保现场

截图、录屏、抓包、日志、设备型号、操作路径、时间点——能抓的全抓。偶现 bug 的生命线是现场，现场没了线索就断了。

第二步：提高复现概率的手段

• 放大操作频次：循环执行、自动化脚本重跑上千次
• 构造类似条件：并发、低电量、弱网、内存高压
• 换设备换账号换数据再试

把「偶现」逼成「高概率」。

第三步：找开发协同

提供时间点和请求特征，让开发从日志和代码路径反推——很多偶现 bug 是开发看代码定位的，测试的输入质量决定这条路的效率。

第四步：复现不了的处理

报 bug 时标注「偶现、概率多少、已保留证据」，和开发约定观察级别，不因为复现不了就默默吞掉；上线后关联线上监控，同类问题再出现能对上号。

收尾：补一句根因方向

偶现 bug 常见根因是并发竞态、资源竞争、缓存不一致、时序依赖——能说出这几类词，说明你思考过偶现背后的规律。

考察重点

维度	说明
企业动机	偶现 bug 是线上事故的重要来源，也是测试和开发扯皮的重灾区。企业要的是有证据意识、会科学提高复现概率的人，不是一句「复现不了」就把风险埋掉的人
过线标准	保现场 + 尝试提高复现概率 + 报单标注偶现，三步讲全
区分度	讲自动化脚本重跑上千次、讲根因方向分类的，是真啃过硬骨头的
加分项	主动提「和开发约定观察级别」「关联线上监控」，风险闭环意识
减分项	说「复现不了就算了」——风险意识为零，这题直接挂

来源

整理自知识星球帖《面试情报 02｜软件测试必备 20 题》，返回题库。