App质量把控：简述质量问题现状及解决方案

lsekfe

       对于质量问题，直接以小故事的形式展开，下面是针对质量复盘的一些思考。

　   技术方案阶体现测试用例
　　对于业务项目来说，会存在测试资源、冒烟用例、精准测试、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 [url=]苹果[/url]标记为待废弃，假如你不按时修改掉，万一上线后用户使用的某个功能异常，那就没救了。

　　SDK 核心用例梳理
　　确保接入 App 集成测试，老的 SDK 梳理核心用例，便于 BDD 测试。SDK 的所有功能需要接入至少2个业务线 App 去验证功能和性能是否符合预期。

　　SDK Demo 必须体现开发能力
　　多端 Demo 对齐 SDK 的功能设计、类的 API 多端对齐，能力一致。且在 Demo 上可以体现出核心功能。

　　脏乱差治理并优化
　　年底统计线上问题原因，经常会发现不管是业务线还是中台，都有一些遗留或者接手的线上问题，所以不管何种原因，都需要 Owner 意识，脏乱差梳理去修复问题。

　　确保测试用例冒烟通过
　　QA 指派的测试用例一定要冒烟通过，冒烟打回很严重的，这是对质量的不认真，也是对 QA 工作的不尊重。
　　另外，关键功能限老司机操刀开发，避免形成卡点（进度）或者影响质量，太忙的情况下至少老带新。
　　核心业务功能，新人很难评估到所有影响面和边缘 case，所以优先老司机操刀开发，或者新人梳理评估出方案，老司机 review 把关，避免因为不熟悉造成进度落后或者线上质量问题。

　　基础 SDK 交叉测试
　　业务项目有 QA 资源，基础 SDK 不一定有测试资源，需要开发者本身去思考测试用例，包括功能和性能方面，最后可以交叉测试，Android、iOS 互测，确保质量。