标签：时间 功能 回归 接受 技术分享 不能 代码 bug 穷举
组内有一位成员发现线上缺陷非常高兴，指着其他组员说，你们怎么测试的，这么简单的问题都漏了。（声明这位组员不是leader，即便是也有问题，原则上来说用“你们”已经划清了界线。）然后让这位组员参与排查问题，得到的答复是：我只参与提问，你们去查。
测试环境认真走查过没问题，到了预发布时，耗时跟进一个严重bug，导致时间不足以回归其他用例，所以这个功能没有覆盖，到了线上就出问题。
经过日志排查，发现测试环境的日志显示正常，到了预发布环境，少了一些参数，可以推断是由于代码不一致导致的。代码不一致的话，那肯定是修改了代码，研发同学不会偷偷提交无效代码的，要有这个基本信任，拿到版本库日志对比就水落石出了。
测试用例不可能穷举，在有限的时间内完成关键用例的测试，则质量程度在研发、测试认可接受范围内。
研发测试过程中反复测试一轮是没有问题的，bug修复后，在预发布环境，需要将核心用例都走一遍，这个是保本所需，不能放松，测试同学也有责任，在这个环节是否严格遵守，排除测试组里面的害群之马去认真面对、分析，对测试、研发提出质疑，上线发布环境，不容许半点质量的放松，回归用例的集合是一根救命稻草，要狠狠抓住，如果错过了，更多是测试没有坚持质量原则。
另外，即将上线发布前的封包时间也很关键，团队究竟认可什么时候封包，封包之后的致命bug修复，如何再次合并代码，这些代码是否经过严格代码审查以及说明影响范围，否则还是会被一个魔咒困扰：修复bug的同时会引入新问题。
一边吐槽坑爹之人，一边还是要接受事实：这锅还是要背。的确在预发布环节，用例回归上掉以轻心了，不可否认。另外，要能够快速定位问题和取证，通过日志、版本信息，回放当时问题所在，让开发、测试同学活的明明白白。
标签：时间 功能 回归 接受 技术分享 不能 代码 bug 穷举
原文地址：http://blog.51cto.com/jooben/2153413
