App|App 质量把控

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

    推荐阅读