1. 测试从按次测试改成按轮测试，整轮开始之前记录版本号，整轮结束之前不接受提交代码修改
2. sonar 规则扫描，每次出问题花时间跟到代码层追溯，整理成 sonar 的规则；建议初期用 findbugs 排除低级错误
3. 测试过程数据分析：建议全部测试开始前清理掉数据库和日志，测试过程中全部保留，最后测完之后分析，比如测试环境限制了邮件发送，那么发送记录表里面就不能有成功的记录；再比如主数据与关联数据关系应该是 1:3，做个联表 group 找找有没有关系不对的；日志里面所有的异常必须全部过一遍、另外，对各个流程节点关键日志进行统计，在某一个节点数量大幅增加的可能就是有 bug 的
4. 推动 jenkins 和 docker，部署脚本建议测试维护，确保上线环境与测试环境一致
5. 埋点提前预测线上 bug，这个一两句很难说完，建议自己查资料

说白了就是环境管理和配置管理没做好，不要听人吹自动化测试、回归测试、容器之类的牛逼，做好基础才是王道，没有规则只搞实现啥都解决不了

这个得根据你版本发布的频率和测试资源来说吧，另外你说测试版功能是好的，是不是你和开发的环境是公用的啊。。

去找开发问下具体原因

测试环境和生产环境数据有差异，导致测试场景分类不够；
上线后的缓存／浏览器缓存问题；
代码 merge 出问题了，这够 shit 的

这种情况是常态,习惯就好

大佬没有灰度的说法么

我也想问一下这个问题，最近线上问题很多，系统也很复杂，系统内部逻辑对测试都是不可见的（公司规定），有个部门是开发底层库的，我们是把在底层库上层做开发，底层有两个大模块，分别是两个团队做的，现在现场出现了问题。还是偶现的。C++ 的程序，还没有 java 那种异常的机制。。很难搞啊。。。

正式版本的代码与测试版本的代码混淆了

第一个要做的应该是看看在测试环境能否复现吧，可以复现就是测试方式有问题，存在漏测；不能复现，测试环境是正常，首先需要排除环境差异，版本差异带来的可能性，然后再看问题。