高效的技术团队-测试发布

前言

从有了高效的技术团队的序的架构以后，每天促使着我去思考每章节如何快去完善。虽然文章的阅读量始终上不去，还是需要逃离，里面都是一些吸引眼球的标题和内容，回归到技术的论坛。上就适合一些成长或大众化的文字。虽然文章层次结构都十分分明，但是对于受众本来就小的文章怎么可能有高的访问量。以后还是写的有趣一些，帮大家对整体有一个深入的理解。测试发布阶段开始体现出来真正跨职能、跨团队的协助。还是原来的风格列出几点：0 BUG提测、代码讲解、Bug日清、发布站会、线上日志监控（30分钟）、监控报警设置。这6个步骤都需要我们细致的去完成。但是每个步骤所能做到的程度也又不相同，接下来再一一讲解。

0 Bug 提测

提高代码的提测质量这个是QA和DEV永恒的话题。每次线上问题处理听到最多的是，
DEV_A:“这个问题为什么没有测试到”
QA_B：“这个逻辑开发怎么没有覆盖到。” 进行线上故障review的时候最不可取的就是单点思考。如果每次能都能确定只是某一个环节出了问题，咱们的团队协作和相互监督、相互check的价值在哪里呢？所以任何线上问题一定是项目组的问题。团队的问题。不能一开始就定位到具体的职位和人员身上。从流程出发怎么去check。这里有点发散，还是想一下怎么做到0 bug 提测。这里涉及到的CC case，QA 通常在提测前会准备提测验收的case（此处有些团队是pm准备），这是一个非常重要的一关，开发在进行开发和自测时候，思考更多是如果实现此功能，边界问题当然会考虑，这就涉及到边界遗漏或功能点遗漏。开发一定要从另外一个人的角度对咱们自己的代码进行一次审视，这相当开发自测重要的一环。已经有完整的CC case ，咱们按照case 走通流程，实现意义上的0 bug 提测。

代码讲解

这步骤分两个点看，第一：必须要性 第二：颗粒度的把控。首先必要性，这个是非常有必要的。开发自己写出来的代码必须能清晰讲解，每行代码需要做什么事情，为什么这么做。解释清楚证明咱们是经过合理的逻辑思考，不是纯的代码堆砌。所以此环节非常必要。颗粒度就涉及到一个大的业务迭代代码可能上万行，我们如何去细化在效率和效果达到一个平衡点。a、改动点分类 xml、配置文件、新增代码、历史逻辑兼容、格式化代码这些事常用的细分逻辑。咱们更多的需要注意的是历史逻辑的兼容。

bug 日清

这个看似很严格也是导致程序员加班的重要规定。其实是有一定的工程管理学意义的，程序的修改经常会有连带效应，尽管会有反复的思考和自测的过程，但是尽早发现和解决问题对后续的项目推进和防止delay非常有意义。

发布站会

发布站会是微服务架构上线步骤中非常重要的一个环节。这个环节相关的leader尽量都参入，毕竟这是上线前最后一个check环节。相关的流程和影响的业务点，哪一步需要做什么都必须有清晰的文本输出。注意几点：1、上线脚本（sql是上线之前执行、还是上线后执行）2、工程依赖3、任务配置4、消息队列5、服务配置。这些都不能有模棱两可的答案，一就是一，大家需要统一思想，最忌讳是这也行那也行，最后就成为这也没有考虑全面，那也没有考虑全面。发布站会输出稳定。有所有人提供补助，QA 负责输出文档，监督执行。

发布日志监控

发布站会是预防的最后一道防线，发布日志监控就是将影响范围控制到最小的一步，我们在发布第一服务器时，通过错误日志的监控，能及时发现如何的业务异常。这个环节对我们平时线上服务的异常日志要求就比较严格，如果线上日志经常各种Exception和Error 会带咱们工程的发布会有很大的干扰。所以我们团队在日常工作中还有多一个线上日志巡检的工作。只要是工程就有遗漏。进程的日志巡检能降低业务影响，排查遗漏。工程只会越来越稳定。发布日志的观察我们还得有一个时间段，有些业务场景可能比较个性，短时间无法触及，观察半小时以上对系统的稳定性帮助更大。

监控报警设置

这一步最为容易遗漏。项目都发完了，PM线上验收也成功了，万事大吉，明天再看业务影响。这种就可能导致很多问题是通过业务暴露出来的。review 的时候开发说这个其实有监控但是没有设置阀值，这种跟没有添加监控有什么区别。所以我们在上线之后。对一些Exception 的地方先加上报警阀值。当然有一些业务数据监控需要第二天或更长时间的业务指标才能确定，我们就只能往后推一下。但是尽可能的第一时间完成监控指标的设置。预估也是一种方式。

总结

又到总结的时候了，测试发布是我们对项目交互的最后一个环节，前面做的各种业务熟悉、业务建模、数据建模、业务架构、编码规范最终的落实都是需要去交互。所以在这个环节咱们还是不能放松，必须提高警惕。做好每一个细节的check。这样子会对咱们项目有一个整体的好的交付。