笔者结合中台经验，本文重点谈谈App的质量稳定性该如何做。业务作为App的核心服务之一，业务异常监控当然也很重要，这不是本文重点。
对于质量问题，直接以小故事的形式展开，下面是移动中台年度针对质量复盘的一些思考。
对于业务项目来说，会存在测试资源、冒烟用例、精准测试、QA新业务的业务回归、核心业务的UI自动化、高铁阶段的QA人工回归等。
这里简单讲讲这些词语，对于新的业务项目，一定会有测试资源，简单说就是QA，新项目在经过PRD、MRD、需求讨论会、Kick-off之后，技术方案评审后，会经过测试用例评审，产出的结果就是用例指南，到时候QA会在用例平台指配给对应的开发。
敏捷开发思想下，业务需求跟车，而不是针对业务项目开车，每周一创建本周高铁，需求买票跟着上车。
上车之前针对你的开发分支，会走精准测试，产出精准测试报告，分析测试报告，如果覆盖率比较低，需要分析是兜底代码太多，还是QA没有执行完全，针对后者你可以结合用例，是否有遗漏，然后去pushQA再去回归。
针对不变的业务，沉淀出的自动化用例，会走UI自动化测试，期间线下性能监控会发现一些性能问题，每周值班QA会无差别回归业务。
但是大多是针对业务，如果是基础SDK的能力和性能，大多是无法定位到问题的，所以针对技术SDK可能没有测试资源，需要中台开发者在SDK阶段，去思考基础SDK本身的核心用例，用例需要思考功能用例和性能用例，还需要思考一些开关情况、版本升级等问题。
所以第一个话题，主要是针对基础SDK来说的，不过业务项目，在技术方案阶段思考的不是测试用例，而是天网报警（业务异常埋点上报）、业埋点（核心数据）等。
官方组件引入
BetterMR经过约定：业务代码经过测试之后，才可以从个人分支合并到dev分支（注意dev分支不是市场分支，release分支是市场分支）。
提交的MR必须至少+2后才可以合并。其中1个人是同技术栈的老司机，另一个人是同项目的业务开发，做到对齐。
代码质量直接关系到产品质量，CodeReview是保证代码质量一个最显著可行的措施之一，而BetterMR是我们探索最佳CodeReview的方式之一。
约定与建议
【约定】后续所有项目与日常均默认走betterMR流程，如果相对简单，可以申请不走betterMR流程。
【约定】MR分级，默认为普通MR，在24H内完成review；提交者可选择为紧急MR，在2H内要完成review；【约定】在后续规划中，架构师在工作分配上预留一定时间到CR上。
【约定】被@的reviewer当自己手头忙碌无法review的情况下，可以选择在评论中@一位backup替自己review。
【建议】紧急MR发出后，请提MR的同学主动口头或企业微信联系和催促reviewer快速响应；【建议】reviewer手头忙碌时，可以先+1merge，后续再review建议。
reviewer数量与选择
约定与建议【约定】每个MR@到两位同学，其中包含该业务域的owner，以及另一位适合的同学（熟悉业务或者熟悉代码），【约定】MR不要@超过两位同学。
另外，小MR流程上是否可以更快一些？约定与建议【约定】质量是核心问题，因此暂时所有走betterMR的项目和日常都坚持走+2的逻辑，直至我们的质量数据有显著好转，代表我们的质量意识有明显提升，再考虑轻量化。
【建议】提MR的同学和reviewer可以通过更有效的描述、注释、沟通来加速review流程，如UI部分更快速review，逻辑部分重点review等。
MR的代码量与有效拆分
约定与建议【约定】在技术评审与kick-off阶段对工作量进行MR任务的逻辑拆分，业务域owner在这两个阶段进行把关，拆分的任务尽量粒度细化。
【约定】在一个MR中尽量将相关逻辑完整提交，有利于代码的整体review；【约定】在技术评审阶段，业务域owner对技术方案与拆分做内审，提前熟悉改动面和设计细节，避免在MR提交的代码之外存在逻辑遗漏；【建议】在保证子任务MR逻辑完整的前提下，尽量约束每个MR的代码量，保证review效果。
分析产出报告
业务SDK接入精准测试，产出报告必须分析。
业务项目我在第一部分说明了会针对业务做哪些测试动作，在中台角度出发，思考业务中台（比如商品、消息）如何保证质量，也可以参考业务项目，接入精准测试，针对每一份测试报告，做进一步的分析。
如果覆盖率比较低，需要分析是兜底代码太多，还是QA没有执行完全，针对后者你可以结合用例，是否有遗漏，然后去pushQA再去回归。
技术中台负责的业务中台项目，也就是业务SDK也需要严格管控，否则就是业务异常，从而产生线上问题或者线上资损。
业务项目一定接入天网报警
基础SDK关键流程接入天网报警App质量与稳定性划分为：性能与质量稳定性、业务稳定性，业务不稳定了就很容易产生线上问题或者资损。
针对业务异常，我们对线上问题归因做了一些梳理，一般可以分为：方法或接口的参数数据类型不对、参数值不在合法区间、边界case没有覆盖、其他（历史遗留bug、三方SDK升级导致、2端沟通不足需求没对齐）。
假如我们将第一二类问题解决好，线上问题将会显著改善。这正好就是天网报警的设计初衷，天网报警用于业务异常监控并报警。
天网报警监控并不像APM一样是SDK去主动监控的，而是需要开发者自己在当前负责的模块、当前开发的项目、当前开发的日常迭代中去梳理关键业务流程和业务场景，对于一些可能存在的异常case，去埋点上报。
所以制定规范
业务项目一定要接入天网报警，基础SDK比如IM、商品，Socket链接有问题，那么就是线上问题，肯定是业务异常，所以这样的关键环节一定要梳理并上报。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
