那些难改的 Bug，最后都怎样了？
终极 Bug 的 4 个走向
多年的测试经验中，经常发现有这么一种现象：总有些提了的 bug 不能顺利的被修复。这些 bug 往往有 4 个走向 ：
1.在被发现的版本中最终被解决，但中途花费较多周折。
2.有计划的在后续的版本中被解决。
3.决定永远不修复，却变成潜在的炸弹，在后续版本中被迫修复。
4.决定永远不修复，至今为止也一直没有被修复。
我们做过的项目做过一次较大的统计，主要统计严重程度中等及以上的缺陷，这 四种 bug 走向 ：第一种占到了 50% 左右，第二、三种各占
20%，最后一种约占了 10%。
没被修复的 Bug 带来的负面影响
1.大部分时候最终还得改了，是 被迫改 ，项目组疲惫，在领导和客户那里都落不了好。
2.这些 bug 积累到一定数量，发现系统快不能要了，得大规模重构，重构的过程不要太痛苦，最后没准就 推倒重来了 （见过 n 个这样这样的案例了）。
- 拖得越久改起来越难 。
最近的一个案例是：某项目为了赶进度，使用了一个较低版本的底层组件，当时识别出低版本的底层组件特性有缺失，测试人员提出了功能 bug，项目组决定忍了。一拖就是
2 年。
结果项目很成功，越来越重要，与之交互的其它系统越来越多，但这个底层组件缺失特性的短板就越来越痛。
最后， 不得不进行修复工作（高版本组件替换），但发现由于代码耦合太紧，已经不是一个月两个月能搞定的事情了 。大规模重构还是推到重来现在成了一个难题。
4.每天与带着太多毛病的系统朝夕相对，是 杀死团队士气的慢性毒药 。当你的潜意识认为自己在做的东西是一团 shit，还谈何激情？想一想 “
破窗效应 ”，马上就能理解了。
如何减少大量 Bug 长期遗留现象？
有如下的一些建议：
1.提升内建质量
这句话高大上，内涵也很丰富，从软件架构，开发过程，各种技术应用等各方面都能够找到无数的提升点避免系统存在太多遗留
bug，展开说真的要一本书了。从里边抽取出最重要的一条精神：bug 被发现的越早，修改遇到的阻力越小。
2.定期 bug 扫除
这其实是测试应该主动提出来的事情，并且应该让这件事儿变成项目组的例行活动。其实如果做好了，乐趣还是很多的，效果也非常好。
3.完善的组织机制
如果是大型系统，或者项目群，很多 bug 是跨项目组的，这时候组织级的机制就要建立起来了，必要的时候需要跟考核制度挂钩。这样有一些三不管的重要 bug
才能被最终解决。
4.对终极 Bug 构建警示围栏
有些 bug 还真得睁一只眼闭一只眼了，约有 10% 的顽疾会这样。难改，且影响范围有限。对这类 bug
最有效的办法是：挖雷难，我给它上边插个旗子，让使用者离他远点儿好不好？有时候处理这些 bug 挺艺术的，运维，客服，售前，售后，都得长点儿心眼。
「Reference」：https://www.cnblogs.com/skytraveler/p/3698151.html， 略有删改。
**
**
-END-
**
**
** **好评福利 ：****测试工程师为 Bug 而来，与 Bug 相伴 996，相爱相杀，纠缠到底，看谁坚持不住先走一步！
请在评论区回复你与 Bug 的精彩故事，精选评论将有机会获赠霍格沃兹测试学院精美礼物（定制卫衣，经典好书等）。小编等你哦！
· · · ** 推荐阅读 ** · · ·
**
**
在霍格沃兹测试学院
与最优秀的测试开发工程师并肩
点一下好看，就少一个 Bug
来霍格沃兹测试开发学社，学习更多软件测试与测试开发的进阶技术，知识点涵盖web自动化测试 app自动化测试、接口自动化测试、测试框架、性能测试、安全测试、持续集成/持续交付/DevOps，测试左移、测试右移、精准测试、测试平台开发、测试管理等内容，课程技术涵盖bash、pytest、junit、selenium、appium、postman、requests、httprunner、jmeter、jenkins、docker、k8s、elk、sonarqube、jacoco、jvm-sandbox等相关技术，全面提升测试开发工程师的技术实力
QQ交流群：484590337
公众号 TestingStudio
点击获取更多信息
