先说一下，回答频率最高的答案，就说“测试都通过了，没有遗留bug了”。
确实，发布前我们要确保没有遗留的bug，但是我们还要有过测试回归，那通常测试回归有几轮呢？每个公司和自己的标准不一样，于我而言：
●一轮回归测试环境主功能，确保bug修复后的版本能正常运行；
●二轮回归预发布环境（较稳定版环境，一般预发布环境的数据和线上是一致的）；
●三轮回归生产环境，确保发布的内容对主功能没有影响。
线上的回归可以依靠自动化来辅助测试。
看日志
那除了测试通过之外，我们还需要考虑什么呢？
个人觉得最重要的是看日志，在日志中能够体现出很多我们在Postman、Jmeter中无法发现的错误，如空指针、连接超时等。而我们在工具中只能看到返回的值为空，不能确定是否存在异常。
那日志该怎么看呢？如果公司有日志平台的话，就很简单了，可以指定分支和机器号，查询在测试阶段的所有error日志。
那没有日志平台的呢？我们可以在Linux平台中，进入对应机器下的日志目录下，cat xxx.log|grep ERROR查找打印error的日志，查看是否存在问题。
分支版本号
还有个要注意的是分支版本号。每次发布的时候，开发都会告诉我们对应服务分支名，但是我们发布的时候千万要注意以下几点：
●本次发布的分支名是否正确；
●本次发布分支是否包含线上最新的内容；
●本次发布的内容是否是提测的内容，是否存在未提测或者其他开发的提测内容。
那该怎么去看发布内容呢？
首先，我们可以在git中找到对应的分支，一般开发提交代码都会有标识，我们可以通过提交的备注和提交的作者，来判断是否包含未提测的内容。
那怎么去看是否包含最新的代码呢？很简单，我们先找到上一次的发布分支，找到当时最新提交的commitid，然后在本次的发布分支中搜索是否存在该id，如果没有找到的话，那我们就要注意了，是不是开发没有最新的代码，千万要小心。
代码覆盖率
最后一点，对于看得懂代码的测试同学很有益，就是代码覆盖率。现在流行的框架就是JaCoCo，这个框架能够识别我们的对应分支的测试覆盖率，生成对应的测试报告。
通过报告我们可以看到有没有开发提测的代码没有覆盖的，具体是什么场景，对于防止漏测场景非常有帮助。
一般覆盖率都是精确到类下面的所有方法，这样就能检测出本次影响的这个类的所有方法是否测试过，当然这样会导致测试场景会很多，所以我们可以借助自动化，把平时需要回归的用例全都跑一遍，一般上线要求覆盖率90%以上。
到这里，系统发布时候的坑基本能够杜绝80%以上，希望各位同学每次发布都能顺顺利利，！
