如何将bug扼杀在摇篮里

关于bug,我想大家都不陌生,就像是产品世界里的‘恐怖分子’ 也是最不招人喜欢的家伙,主要是因为bug经常潜藏于无形之中,而一旦发作轻则影响用户体验,重则造成经济损失,我们来看一组兑吧近半年的bug数据。



通过bug统计数据图可以看出,线上bug逐月再下降 。那么问题来了:

有人会问:怎么做到bug每月都是递减的呢?

通过对历史bug数据的分析,有关产生bug的原因,得出结论如下:

  • 需求快速迭代的模式下,发布频繁造成了一定比例的线上bug;

  • 开发修改代码后未经过测试环节,直接发布至生产环境,导致线上bug;

  • 测试同学在用例设计及执行阶段因测试覆盖度不够导致漏侧;

针对以上出现的问题和原因,我们做了哪些预防措施呢?

总体采用 “事前预防”,“事中控制”,“事后总结改进”的思想:




事先预防

主要做的3件事


交付流程规范


(1) 开发在新增/变更中提交代码后,触发单元测试,检查代码中基本的逻辑问题,实践中单测的覆盖率和维护由开发同学自己保证,目前jenkins核心应用的覆盖率在50%左右。

(2) 部署开发环境,开发进行联调自测,主要对新的功能进行基本的验证。

(3) 自测完成后发布测试环境,由测试同学进行集成测试,包括回归测试和新功能的验证,以及对核心接口的小压测。

(4)测试完成后发布预发环境,由测试同学进行回归测试,预发环境与生产环境在同一个网络中,共享同一个数据库,但是它具有一个独立的依赖环境,如独立的上下游和中间件。

(5) 预发测试完成后,正式发布生产环境并对生产环境执行冒烟测试。

以上是一个变更的生命周期,也是一次完整的持续交付流程,我们可以在持续交付的流程中实现测试的卡点,测试不通过,无法进入下一个阶段的发布。

发布周期控制

从每周不限次数的发布到规范后每周的周二/周四的发布,控制由发布频繁造成的线上问题,我们通过‘火车模型’来讲述现在的发布流程,火车通常都是提前售票,固定时间点发车,到点发车,错过只能搭下趟车。


分支管理


曾经因分支絮乱,争抢测试环境,一方面导致需求delay;另一方面,测试质量不能把控,通过规范分支管理流程,极大提高研发效率和代码质量。


线上质量监控

在正式发布生产环境时或周末无人值守时,通过cat工具对线上质量进行监控,一旦有问题通过告警就能及时发现解决,避免问题的大面积扩大。主要包括:

  • 系统日志监控报警:监控各个系统的异常日志及告警;

  • 业务数据监控:监控各个业务点的历史及当前值;

  • 数据库及缓存监控:监控数据库和缓存的运行情况;

  • 系统间依赖及调用情况:提供系统间依赖调用和接口访问数据的分析;



提前暴露问题(发布生产环境前)

主要采用分层的测试模型



  • 需求测试:在需求评审期间,对需求文档进行业务逻辑测试,提前规避业务逻辑上的bug。

  • 单元测试:在开发阶段一旦有代码变动,能快速最低成本发现问题,最重要的是:单元测试是验证业务流程的第一道防线。

  • 集成测试:是验证业务流程第二道防线,也是重中之重的一道防线,通过人工手动进行新功能验证+自动化进行地毯式的回归测试,测试覆盖度 达100%,从某种程度来说,解决了因测试同学覆盖度不够导致漏测的问题

  • UI测试:是验证业务流程的最后一道防线,采用静态测试+动态测试的方法,验证其正确性。

通过以上每道防线的验证,可以事先预防80%的bug的产生,有人又会问:为什么是80%而不是100%呢?因为剩下20%可能来自于外部因素引起,而这些外部因素又是人为不可控制的,举个例子:停电了,服务器停止运行,所有依赖服务器上的应用都会停止运行。

事中控制

通过下面的内容来聊聊,遇到问题我们是怎么处理的呢?。

快速处理

产生bug后,第一时间复现和定位问题,遵循‘今日事今日毕’的原则,倘若遇到难以定位和难以解决的问题,首先会给出预估的修复bug的时间节点,其次若因外部原因阻碍了bug修复,2天内给予答复。

研发质量规范和提升

研发质量的提升目前主要包括代码审核、代码质量检查

  • 代码审核:提测时开发owner对组内开发同学请求合入分支的代码进行审核,通过code review提高代码质量和代码规范,减少较低级的错误。

  • 代码扫描:使用sonar进行代码质量管理, 通过sonar可以监控代码的bug,覆盖率,坏味道,复杂度等代码指标。

事后总结与改进

当出现bug后,不要怕,要对它深入分析,我们可以明白这个bug的机制:为什么会产生?如何去预防它?下一次我们如何更容易地发现它?只要花一点时间去理解我们的 bug,而不是仅仅是尽快修正它,我们就可以从中得到经验。这样,因为一个缺陷所浪费的时间也可以转化为投入。在很大程度上可以提前预防bug的产生,确保类似的错误永远不会再发生,就可以将bug扼杀在摇篮里。

感谢来自兑吧技术团队Ms. Zhang的投递


  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值