对于质量问题，直接以小故事的形式展开，下面是针对质量复盘的一些思考。
对于业务项目来说，会存在测试资源、冒烟用例、精准测试、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 链接有问题，那么就是线上问题，肯定是业务异常。所以这样的关键环节一定要梳理并上报。
覆盖率大于90%
新 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 苹果标记为待废弃，假如你不按时修改掉，万一上线后用户使用的某个功能异常，那就没救了。
SDK 核心用例梳理
确保接入 App 集成测试，老的 SDK 梳理核心用例，便于 BDD 测试。SDK 的所有功能需要接入至少2个业务线 App 去验证功能和性能是否符合预期。
SDK Demo 必须体现开发能力
多端 Demo 对齐 SDK 的功能设计、类的 API 多端对齐，能力一致。且在 Demo 上可以体现出核心功能。
脏乱差治理并优化
年底统计线上问题原因，经常会发现不管是业务线还是中台，都有一些遗留或者接手的线上问题，所以不管何种原因，都需要 Owner 意识，脏乱差梳理去修复问题。
确保测试用例冒烟通过
QA 指派的测试用例一定要冒烟通过，冒烟打回很严重的，这是对质量的不认真，也是对 QA 工作的不尊重。
另外，关键功能限老司机操刀开发，避免形成卡点（进度）或者影响质量，太忙的情况下至少老带新。
核心业务功能，新人很难评估到所有影响面和边缘 case，所以优先老司机操刀开发，或者新人梳理评估出方案，老司机 review 把关，避免因为不熟悉造成进度落后或者线上质量问题。
基础 SDK 交叉测试
业务项目有 QA 资源，基础 SDK 不一定有测试资源，需要开发者本身去思考测试用例，包括功能和性能方面，最后可以交叉测试，Android、iOS 互测，确保质量。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
