本文为 TesterHome 社区测试大咖，霍格沃兹测试学院特邀嘉宾 @sktraveler 反思质量管理的一篇经典旧文，供参考学习。
终极 Bug 的 4 个走向
多年的测试经验中，经常发现有这么一种现象：总有些提了的 bug 不能顺利的被修复。这些 bug 往往有 4 个走向：
1.在被发现的版本中最终被解决，但中途花费较多周折。
2.有计划的在后续的版本中被解决。
3.决定永远不修复，却变成潜在的**，在后续版本中被迫修复。
4.决定永远不修复，至今为止也一直没有被修复。
我们做过的项目做过一次较大的统计，主要统计严重程度中等及以上的缺陷，这四种 bug 走向：第一种占到了 50% 左右，第二、三种各占 20%，最后一种约占了 10%。
没被修复的 Bug 带来的负面影响
1.大部分时候最终还得改了，是被迫改，项目组疲惫，在领导和客户那里都落不了好。
2.这些 bug 积累到一定数量，发现系统快不能要了，得大规模重构，重构的过程不要太痛苦，最后没准就推倒重来了（见过 n 个这样这样的案例了）。
3.拖得越久改起来越难。
最近的一个案例是：某项目为了赶进度，使用了一个较低版本的底层组件，当时识别出低版本的底层组件特性有缺失，测试人员提出了功能 bug，项目组决定忍了。一拖就是 2 年。
结果项目很成功，越来越重要，与之交互的其它系统越来越多，但这个底层组件缺失特性的短板就越来越痛。
最后，不得不进行修复工作（高版本组件替换），但发现由于代码耦合太紧，已经不是一个月两个月能搞定的事情了。大规模重构还是推到重来现在成了一个难题。
4.每天与带着太多毛病的系统朝夕相对，是杀死团队士气的慢性**。当你的潜意识认为自己在做的东西是一团 shit，还谈何激情？想一想 “破窗效应”，马上就能理解了。
如何减少大量 Bug 长期遗留现象？
有如下的一些建议：
1.提升内建质量
这句话高大上，内涵也很丰富，从软件架构，开发过程，各种技术应用等各方面都能够找到无数的提升点避免系统存在太多遗留 bug，展开说真的要一本书了。从里边抽取出最重要的一条精神：bug 被发现的越早，修改遇到的阻力越小。
2.定期 bug 扫除
这其实是测试应该主动提出来的事情，并且应该让这件事儿变成项目组的例行活动。其实如果做好了，乐趣还是很多的，效果也非常好。
3.完善的组织机制
如果是大型系统，或者项目群，很多 bug 是跨项目组的，这时候组织级的机制就要建立起来了，必要的时候需要跟考核制度挂钩。这样有一些三不管的重要 bug 才能被最终解决。
4.对终极 Bug 构建警示围栏
有些 bug 还真得睁一只眼闭一只眼了，约有 10% 的顽疾会这样。难改，且影响范围有限。对这类 bug 最有效的办法是：挖雷难，我给它上边插个旗子，让使用者离他远点儿好不好？有时候处理这些 bug 挺艺术的，运维，客服，售前，售后，都得长点儿心眼。
「Reference」：https://www.cnblogs.com/sktraveler/p/3698151.html，略有删改。