笔者结合中台经验，本文重点谈谈 App 的质量稳定性该如何做。业务作为 App 的核心服务之一，业务异常监控当然也很重要，这不是本文重点。
质量问题的现状
对于质量问题，直接以小故事的形式展开。下面是移动中台年度针对质量复盘的一些思考
- 技术方案阶体现测试用例 对于业务项目来说，会存在测试资源、冒烟用例、精准测试、QA 新业务的业务回归、核心业务的 UI 自动化、高铁阶段的 QA 人工回归等。这里简单讲讲这些词语，对于新的业务项目，一定会有测试资源，简单说就是 QA，新项目在经过 PRD、MRD、需求讨论会、Kick-off 之后，技术方案评审后，会经过测试用例评审，产出的结果就是用例指南，到时候 QA 会在用例平台指配给对应的开发。 敏捷开发思想下，业务需求跟车，而不是针对业务项目开车，每周一创建本周高铁，需求买票跟着上车。上车之前针对你的开发分支，会走精准测试，产出精准测试报告，分析测试报告，如果覆盖率比较低，需要分析是兜底代码太多，还是 QA 没有执行完全，针对后者你可以结合用例，是否有遗漏，然后去 push QA 再去回归。 针对不变的业务，沉淀出的自动化用例，会走 UI 自动化测试。期间线下性能监控会发现一些性能问题。每周值班 QA 会无差别回归业务。
但是啊，这些大多是针对业务，如果是基础 SDK 的能力和性能，大多是无法定位到问题的，所以针对技术 SDK 可能没有测试资源，需要中台开发者在 SDK 阶段，去思考基础 SDK 本身的核心用例，用例需要思考功能用例和性能用例，还需要思考一些开关情况、版本升级等问题。 所以第一个话题，主要是针对基础 SDK 来说的，不过业务项目，在技术方案阶段思考的不是测试用例，而是天网报警（业务异常埋点上报）、业埋点（核心数据）等
- 官方组件引入 BetterMR 经过约定：业务代码经过测试之后，才可以从个人分支合并到 dev 分支（注意 dev 分支不是市场分支，release 分支是市场分支）。提交的 MR 必须至少 +2 后才可以合并。其中1个人是同技术栈的老司机，另一个人是同项目的业务开发，做到对齐。
代码质量直接关系到产品质量，Code Review 是保证代码质量一个最显著可行的措施之一，而 BetterMR 是我们探索最佳 Code Review 的方式之一。
约定与建议 【约定】后续所有项目与日常均默认走 betterMR 流程，如果相对简单，可以申请不走 betterMR 流程； 【约定】MR 分级，默认为普通 MR，在 24H 内完成 review；提交者可选择为紧急 MR，在 2H 内要完成 review； 【约定】在后续规划中，架构师在工作分配上预留一定时间到 CR 上； 【约定】被 @ 的 reviewer 当自己手头忙碌无法 review 的情况下，可以选择在评论中 @ 一位 backup 替自己 review； 【建议】紧急MR发出后，请提 MR 的同学主动口头或企业微信联系和催促 reviewer 快速响应； 【建议】reviewer 手头忙碌时，可以先 +1 merge，后续再 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 没有执行完全，针对后者你可以结合用例，是否有遗漏，然后去 push QA 再去回归。
技术中台负责的业务中台项目，也就是业务 SDK 也需要严格管控，否则就是业务异常，从而产生线上问题或者线上资损。
- 业务项目一定接入天网报警，基础 SDK 关键流程接入天网报警 App 质量与稳定性划分为：性能与质量稳定性、业务稳定性。业务不稳定了就很容易产生线上问题或者资损。针对业务异常，我们对线上问题归因做了一些梳理，一般可以分为： 方法或接口的参数数据类型不对、参数值不在合法区间、边界 case 没有覆盖、其他（历史遗留 bug、三方 SDK 升级导致、2端沟通不足需求没对齐）； 假如我们将第一二类问题解决好，线上问题将会显著改善。这正好就是天网报警的设计初衷，天网报警用于业务异常监控并报警。天网报警监控并不像 APM 一样是 SDK 去主动监控的，而是需要开发者自己在当前负责的模块、当前开发的项目、当前开发的日常迭代中去梳理关键业务流程和业务场景，对于一些可能存在的异常 case，去埋点上报。
所以制定规范：业务项目一定要接入天网报警，基础 SDK 比如 IM、商品，Socket 链接有问题，那么就是线上问题，肯定是业务异常。所以这样的关键环节一定要梳理并上报
- 新 SDK UT 覆盖率90%以上，老 SDK 基于 BDD 通过 基于资源有限的情况下，历史遗留的 SDK 可能无法去梳理并编写单测，那老的 SDK 可以去给予行为去编写 BDD 测试用例，这里不展开描述什么是 BDD 和怎么实践。针对新的 SDK 在技术方案阶段就需要思考好测试用例并体现出来，开发阶段 UT 覆盖率须大于90%。
- SDK 一定要 Lint 通过 这里的 lint 并不是针对语法、锁进等的 OCLint，而是 pod lint。因为发生过一些情况，就是 MR 提交后，去打包系统打包阶段， 因为 pod SDK 的问题导致的打包失败，所以 pod 的 lint 一定要通过，将问题提前解决掉。
- SDK Warning 清理 SDK 内部的 warning 尽量清理掉，比如 UIWebView 或者某个使用的 API 苹果标记为待废弃，假如你不按时修改掉，万一上线后用户使用的某个功能异常，那就 GG 了
- SDK 核心用例梳理，确保接入 App 集成测试 老的 SDK 梳理核心用例，便于 BDD 测试。SDK 的所有功能需要接入至少2个业务线 App 去验证功能和性能是否符合预期
- SDK Demo 必须体现开发能力，多端 Demo 对齐 SDK 的功能设计、类的 API 多端对齐，能力一致。且在 Demo 上可以体现出核心功能
- 脏乱差治理并优化 年底统计线上问题原因，经常会发现不管是业务线还是中台，都有一些遗留或者接手的线上问题，所以不管何种原因，都需要 Owner 意识，脏乱差梳理去修复问题
- 确保测试用例冒烟通过 QA 指派的测试用例一定要冒烟通过，冒烟打回很严重的，这是对质量的不认真，也是对 QA 工作的不尊重
- 关键功能有限老司机操刀开发，避免形成卡点（进度）或者影响质量，太忙的情况下至少老带新 核心业务功能，新人很难评估到所有影响面和边缘 case，所以优先老司机操刀开发，或者新人梳理评估出方案，老司机 review 把关。避免因为不熟悉造成进度落后或者线上质量问题
- 基础 SDK 交叉测试 业务项目有 QA 资源，基础 SDK 不一定有测试资源，需要开发者本身去思考测试用例，包括功能和性能方面，最后可以交叉测试，Android、iOS 互测，确保质量。
