测试背黑锅姿势

朋友讲了个案例

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

现象：测试环境没问题，生产就出问题了。

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

本质：为什么同一套代码，两个环境不一致？

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

教训是什么？

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

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

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

再想想

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