最近跳到了新东家之后，忙于学习各种技能和业务流程好久没更新学习总结了，新的环境的确扩充了自己的知识面，也对之前混淆的概念有了些更深的认识，今天就来聊聊bug与故障的区别，以及对应的防范措施，聊之前我先申明一下，这些只是我个人的理解，不是真理，也不是定律，有不同观点的同学可以尽情的提出来，只有充分的讨论才有可能产生“爱情的结晶”：），好了废话不多说直接上主菜。
我理解的bug是指程序的运行结果与需求期望的值不一致， 而故障是指对公司有形或者无形的资产造成了影响；或许只是宏观的一说有些同学还是不能深刻的理解里面的含义，那我再举例说明吧：比如我们产品发布前发现了很多问题，这些问题再大只要没有对公司的资产没有造成影响都可以认为是bug的范畴；再比如我们的机房的网络断了，对公司造成的直接经济损失为xxx万元，虽然这个问题不是程序bug引起的，但是却算是一个很严重的故障。
从这两个例子可以看出两者的区别是：故障只发生在生产环境，而bug是任何环境都是存在的，引起故障的原因很多，不只是程序bug引起的，再来说说弄清这两者概念的区别，对我们的工作有什么指导意义，我相信很多大公司都是有自己独立的质量部门的，有些公司的质量部门只是做着测试的工作，然后衡量一个测试工程师是否合格的的标准就是线上是否有漏测的bug，但是我们都知道一个真理：再完美的系统也是有bug存在的，既然如此，那么是不是说所有的测试工程师都会漏测呢，都不合格呢？我也是一名测试工程师，这样的观点我当然不能苟同，我认为不应该单一的以bug的漏测来作为衡量的标准，而应该以故障的严重程度来衡量一个工程师是否合格的标准；虽说bug是不可避免的，但故障的影响却是可以避免的或者降低的，在生产环境上，只要我们能尽早的发现bug就能最大限度的降低bug带来的影响。
那么如何才能尽早的发现bug呢？先来说说bug产生的源头，一般业务系统的bug包含这两大类：
1.是因为程序异常导致业务流程阻塞或者中断，此类的bug大都会输出erro 级别的日志，所以只要监控好此类日志，在捕获异常后第一时间做好应对措施，就能避免或者减少故障所带来的影响，此类异常监控是需要开发同学一起协助完成的；
2.业务规则或者其他原因导致数据沉淀有问题，此类问题单从日志层面不好捕获，很多时候需要用户来投诉或者资金结算的时候才能发现，此类bug就需要通过核对的方式来提前暴露问题并给出相应的措施，那么如何核对呢？这个就需要对业务系统比较熟悉的同学自己去总结了，比如电信行业中的开户操作，如果开户完成后需要在a,b,c表中落下实例数据，那就需要根据一个主键去检查这些值是否有落下来， 比如电商行业中的订单系统，用户下单成功后支付的金额是否与产品规定的金额一致等等。
总结一下，聊了这么多只想表达一个观点：在产品未上线之前我们要想尽一切办法寻找bug。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
