码迷,mamicode.com
首页 > 其他好文 > 详细

测试背黑锅姿势

时间:2018-08-02 10:23:43      阅读:154      评论:0      收藏:0      [点我收藏+]

标签:时间   功能   回归   接受   技术分享   不能   代码   bug   穷举   

技术分享图片
朋友讲了个案例

组内有一位成员发现线上缺陷非常高兴,指着其他组员说,你们怎么测试的,这么简单的问题都漏了。(声明这位组员不是leader,即便是也有问题,原则上来说用“你们”已经划清了界线。)然后让这位组员参与排查问题,得到的答复是:我只参与提问,你们去查。

现象:测试环境没问题,生产就出问题了。

测试环境认真走查过没问题,到了预发布时,耗时跟进一个严重bug,导致时间不足以回归其他用例,所以这个功能没有覆盖,到了线上就出问题。

本质:为什么同一套代码,两个环境不一致?

经过日志排查,发现测试环境的日志显示正常,到了预发布环境,少了一些参数,可以推断是由于代码不一致导致的。代码不一致的话,那肯定是修改了代码,研发同学不会偷偷提交无效代码的,要有这个基本信任,拿到版本库日志对比就水落石出了。

教训是什么?

测试用例不可能穷举,在有限的时间内完成关键用例的测试,则质量程度在研发、测试认可接受范围内。

研发测试过程中反复测试一轮是没有问题的,bug修复后,在预发布环境,需要将核心用例都走一遍,这个是保本所需,不能放松,测试同学也有责任,在这个环节是否严格遵守,排除测试组里面的害群之马去认真面对、分析,对测试、研发提出质疑,上线发布环境,不容许半点质量的放松,回归用例的集合是一根救命稻草,要狠狠抓住,如果错过了,更多是测试没有坚持质量原则。

另外,即将上线发布前的封包时间也很关键,团队究竟认可什么时候封包,封包之后的致命bug修复,如何再次合并代码,这些代码是否经过严格代码审查以及说明影响范围,否则还是会被一个魔咒困扰:修复bug的同时会引入新问题。

再想想

一边吐槽坑爹之人,一边还是要接受事实:这锅还是要背。的确在预发布环节,用例回归上掉以轻心了,不可否认。另外,要能够快速定位问题和取证,通过日志、版本信息,回放当时问题所在,让开发、测试同学活的明明白白。


测试背黑锅姿势

标签:时间   功能   回归   接受   技术分享   不能   代码   bug   穷举   

原文地址:http://blog.51cto.com/jooben/2153413

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!