测试背黑锅姿式

朋友讲了个案例

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

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

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

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

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

教训是什么？

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

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

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

再想一想

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