linux下的测试流程，发布前要做哪些准备？

前段时间面试的时候，问到他们公司的测试流程时，很多同学都只说到从需求到发布的一个过程，当问到发布前要做哪些准备，很多都回答的不是很全面。下面给大家分享一下，可以从以下几点入手。加我VX：atstudy-js 回复“测试”，进入 自动化测试学习交流群~~​

先说一下，回答频率最高的答案，就说“测试都通过了，没有遗留bug了”。确实，发布前我们要确保没有遗留的bug，但是我们还要保证有过测试回归，那通常测试回归有几轮呢？每个公司和自己的标准不一样，于我而言，一轮回归测试环境主功能，确保bug修复后的版本能正常运行；二轮回归预发布环境（较稳定版环境，一般预发布环境的数据和线上是一致的）；三轮回归生产环境，确保发布的内容对主功能没有影响。线上的回归可以依靠自动化来辅助测试。

那除了测试通过之外，我们还需要考虑什么呢？

个人觉得最重要的是看日志，在日志中能够体现除很多我们在Postman、Jmeter中无法发现的错误，如空指针、连接超时等。而我们在工具中只能看到返回的值为空，不能确定是否存在异常。那日志该怎么看呢？如果公司有日志平台的话，就很简单了，可以指定分支和机器号，查询在测试阶段的所有error日志。那没有日志平台的呢？我们可以在linux平台中，进入对应机器下的日志目录下，cat xxx.log | grep ERROR 查找打印error的日志，查看是否存在问题。

还有个要注意的是分支版本号。每次发布的时候，开发都会告诉我们对应服务分支名，但是我们发布的时候千万要注意以下几点，

1、本次发布的分支名是否正确

2、本次发布分支是否包含线上最新的内容，

3、本次发布的内容是否是提测的内容，是否存在未提测或者其他开发的提测内容。

那该怎么去看发布内容呢？

首先，我们可以在git中找到对应的分支，一般开发提交代码都会有标识，我们可以通过提交的备注和提交的作者，来判断是否包含未提测的内容。那怎么去看是否包含最新的代码呢？很简单，我们先找到上一次的发布分支，找到当时最新提交的 commitid，然后在本次的发布分支中搜索是否存在该id，如果没有找到的话，那我们就要注意了，是不是开发没有和最新的代码，千万要小心。

最后一点，对于看的懂代码的测试同学很有益，就是代码覆盖率。现在流行的框架就是JaCoCo，这个框架能够识别我们的对应分支的测试覆盖率，生成对应的测试报告。通过报告我们可以看到有没有开发提测的代码没有覆盖的，具体是什么场景，对于防止漏测场景非常有帮助。一般覆盖率都是精确到类下面的所有方法，这样就能检测出本次影响的这个类的所有方法是否测试过，当然这样会导致测试场景会很多，所以我们可以借助自动化，把平时需要回归的用例全都跑一遍。一般上线要求覆盖率90%以上。

到这里，系统发布时候的坑基本能够杜绝80%以上，希望各位同学每次发布都能顺顺利利，一次通过！

添加微信：atstudy-js  或者扫描下方二维码，备注“博客”邀请你进入Python自动化测试学习交流群~