knowledge-kit/Chapter1 - iOS/1.99.md

#  客户端质量把控

> 笔者结合中台经验，本文重点谈谈 App 的质量稳定性该如何做。业务作为 App 的核心服务之一，业务异常监控当然也很重要，这不是本文重点。

## 质量问题的现状

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

1. 技术方案阶体现测试用例
对于业务项目来说，会存在测试资源、冒烟用例、精准测试、QA 新业务的业务回归、核心业务的 UI 自动化、高铁阶段的 QA 人工回归等。这里简单讲讲这些词语，对于新的业务项目，一定会有测试资源，简单说就是 QA，新项目在经过 PRD、MRD、需求讨论会、Kick-off 之后，技术方案评审后，会经过测试用例评审，产出的结果就是用例指南，到时候 QA 会在用例平台指配给对应的开发。
敏捷开发思想下，业务需求跟车，而不是针对业务项目开车，每周一创建本周高铁，需求买票跟着上车。上车之前针对你的开发分支，会走精准测试，产出精准测试报告，分析测试报告，如果覆盖率比较低，需要分析是兜底代码太多，还是 QA 没有执行完全，针对后者你可以结合用例，是否有遗漏，然后去 push QA 再去回归。
针对不变的业务，沉淀出的自动化用例，会走 UI 自动化测试。期间线下性能监控会发现一些性能问题。每周值班 QA 会无差别回归业务。

但是啊，这些大多是针对业务，如果是基础 SDK 的能力和性能，大多是无法定位到问题的，所以针对技术 SDK 可能没有测试资源，需要中台开发者在 SDK 阶段，去思考基础 SDK 本身的核心用例，用例需要思考功能用例和性能用例，还需要思考一些开关情况、版本升级等问题。
所以第一个话题，主要是针对基础 SDK 来说的，不过业务项目，在技术方案阶段思考的不是测试用例，而是天网报警（业务异常埋点上报）、业埋点（核心数据）等

2. 官方组件引入 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 效果；

3. 业务 SDK 接入精准测试，产出报告必须分析
业务项目我在第一部分说明了会针对业务做哪些测试动作，在中台角度出发，思考业务中台（比如商品、消息）如何保证质量，也可以参考业务项目，接入精准测试，针对每一份测试报告，做进一步的分析，如果覆盖率比较低，需要分析是兜底代码太多，还是 QA 没有执行完全，针对后者你可以结合用例，是否有遗漏，然后去 push QA 再去回归。

技术中台负责的业务中台项目，也就是业务 SDK 也需要严格管控，否则就是业务异常，从而产生线上问题或者线上资损。

4. 业务项目一定接入天网报警，基础 SDK 关键流程接入天网报警
App 质量与稳定性划分为：性能与质量稳定性、业务稳定性。业务不稳定了就很容易产生线上问题或者资损。针对业务异常，我们对线上问题归因做了一些梳理，一般可以分为：
方法或接口的参数数据类型不对、参数值不在合法区间、边界 case 没有覆盖、其他（历史遗留 bug、三方 SDK 升级导致、2端沟通不足需求没对齐）；
假如我们将第一二类问题解决好，线上问题将会显著改善。这正好就是天网报警的设计初衷，天网报警用于业务异常监控并报警。天网报警监控并不像 APM 一样是 SDK 去主动监控的，而是需要开发者自己在当前负责的模块、当前开发的项目、当前开发的日常迭代中去梳理关键业务流程和业务场景，对于一些可能存在的异常 case，去埋点上报。

所以制定规范：业务项目一定要接入天网报警，基础 SDK 比如 IM、商品，Socket 链接有问题，那么就是线上问题，肯定是业务异常。所以这样的关键环节一定要梳理并上报

5. 新 SDK UT 覆盖率90%以上，老 SDK 基于 BDD 通过
基于资源有限的情况下，历史遗留的 SDK 可能无法去梳理并编写单测，那老的 SDK 可以去给予行为去编写 BDD 测试用例，这里不展开描述什么是 BDD 和怎么实践。针对新的 SDK 在技术方案阶段就需要思考好测试用例并体现出来，开发阶段 UT 覆盖率须大于90%。

6. SDK 一定要 Lint 通过
这里的 lint 并不是针对语法、锁进等的 OCLint，而是 pod lint。因为发生过一些情况，就是 MR 提交后，去打包系统打包阶段， 因为 pod SDK 的问题导致的打包失败，所以 pod 的 lint 一定要通过，将问题提前解决掉。

7. SDK Warning 清理
SDK 内部的 warning 尽量清理掉，比如 UIWebView 或者某个使用的 API 苹果标记为待废弃，假如你不按时修改掉，万一上线后用户使用的某个功能异常，那就 GG 了

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

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

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

11. 确保测试用例冒烟通过
QA 指派的测试用例一定要冒烟通过，冒烟打回很严重的，这是对质量的不认真，也是对 QA 工作的不尊重

12. 关键功能有限老司机操刀开发，避免形成卡点（进度）或者影响质量，太忙的情况下至少老带新
核心业务功能，新人很难评估到所有影响面和边缘 case，所以优先老司机操刀开发，或者新人梳理评估出方案，老司机 review 把关。避免因为不熟悉造成进度落后或者线上质量问题

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



## SDK 质量 CheckList

- ChangeLog、Podspec、Readme 完善

- BetterMR +3 机制深入贯彻（一名角色为项目的另一端同学，另一名角色为本技术栈更资深的老司机）

- 冒烟通过率100%（假如技术项目、日常优化可以交叉测试）

- 精准测试，以及精准测试报告分析。代码行覆盖率至少80%

- 高铁包回归阶段：UI 自动化点击页面，发现性能（APM）与稳定性问题（Crash）、业务异常天网报警监控（之前都是忽略未上线前高铁阶段的质量问题的，提前感知问题提前修复，减少线上问题）

- 业务 SDK 正式发布阶段，业务线接入升级时，工程师需充当 QA 角色，评估业务影响面，数据需要全面评估（新老版本兼容性、灰度策略），产出 SDK 性能测试报告和影响面报告

技术 SDK  质量 CheckList

- ChangeLog、Podspec、Readme 完善，SDK 发布必须 Lint 通过

- BetterMR +3 机制深入贯彻（一名角色为项目的另一端同学，另一名角色为本技术栈更资深的老司机）

- 新开的 SDK 必须写单测，覆盖率90%以上

- 对于存量 SDK 可以通过 BDD 补充测试用例，不如 APM 卡顿测试，可以在10s内 Mock 3次卡顿。假设普通卡顿临界值为0.2s，严重卡顿为1s，ANR为5s，手动Mock3次卡顿，分别为0.3s、2s、6s，基于 BDD 我们可以对监控结果进行判断，比如断言抓到3次卡顿，其中2次严重卡顿、1次 ANR

- 开发阶段必须关心性能：内存、电量、卡顿、网络。用 Instrucments 测试

- 冒烟通过率100%（假如技术项目、日常优化可以交叉测试）

- 高铁包回归阶段：UI 自动化点击页面，发现性能（APM）与稳定性问题（Crash）、业务异常天网报警监控（之前都是忽略未上线前高铁阶段的质量问题的，提前感知问题提前修复，减少线上问题）

- 业务 SDK 正式发布阶段，业务线接入升级时，工程师需充当 QA 角色，评估业务影响面，数据需要全面评估（新老版本兼容性、灰度策略），产出 SDK 性能测试报告和影响面报告



## SDK 测试方法

客户端SDK是为第三方开发者提供的软件开发工具包，包括 SDK 接口、开发文档和 Demo 示例等。SDK 和应用之间的关系？以 IM 为例，App 调用 IM SDK 接口。进行客服消息功能模块的接入，也包括消息 PUSH 功能的使用方。包括 Weex、JS 等资源的更新、商品数据更新 PUSH 后端上的感知能力、智能经营消息等。


### 客户端 SDK 测试的对象
客户端 SDK 测试，就是对提供给开发者的工具包里面的内容进行测试

因此测试的主要内容有：
1. SDK 接口和文档
- SDK 接口是测试的主要对象，也是核心的内容

2. SDK 日志
对开发者来说，SDK 接口里面的具体实现是透明的，当上层调用时遇到问题，只能依赖 SDK 打印的日志来定位分析。所以 SDK 日志是否完备，是否有助于解决问题，对应用开发者和 SDK 提供方来说都很重要

3. Demo 或行业解决方案
Demo 测试可以看成是基于行为的测试。Demo 是SDK提供方用来示例如何调用接口实现具体的功能，也可以作为开发者直观感受SDK接入效果。行业解决方案类似 Demo，但是，比 Demo 更加像一个产品，具有比较完整和典型的行业应用场景。可以让行业开发者比较明确知道，接入这个 SDK 做出来的产品效果如何。

4. 其他周边
比如UIkit等，可能只是在SDK开发中的附带输出，但对有的开发者来说能极大降低接入成本

### 客户端SDK接口测试类型
客户端SDK根据需求和开发平台不同，可能需要选择不同的测试类型对SDK接口进行测试

常见的测试类型有：
1. 功能测试
保证 SDK 接口功能正确性和完备性。客户端 SDK 接口测试跟服务端接口测试类似，包括场景覆盖和接口参数覆盖
主要测试各种参数组合下的返回值，考虑数据是否缓存与存储，是否有回调，对于请求成功或失败都能按预期进行处理

2. 性能测试
保证 SDK 接口满足特定的性能需求，比如资源占用、移动设备耗电量等。比如 APM 在卡顿定制抓取堆栈的时候会对设备有内存和 CPU 的影响，如果全量抓取一次堆栈会更加耗时，如果异步抓取主线程堆栈。实现不好，很有可能在发生卡顿的时候，由于 APM 实现不好，导致本来的卡顿变成了 OOM。所以测试时就需要考虑这个场景的性能

3. 兼容性测试
保证 SDK 兼容特定的设备平台，并与其他软件兼容。兼容设备平台的工作量通常是比较大的，先根据产品需求和市场现状对需要适配的设备平台做分析，再根据需要覆盖的机型、系统版本、分辨率等进行优先覆盖排序
移动端 SDK 兼容性测试需要考虑下对模拟器的支持，因为很多开发者可能就是先在模拟器上开发。客户端 SDK 覆盖多平台设备的，还要考虑多端消息数据包的互通

4. 稳定性测试
考察业务场景在一定压力下，持续运行一段时间，接口功能和设备资源占用有无异常。比如早期做 APM 时候，参考腾讯 Matrix 的代码，居然线上发生了 OOM，最后二分法排查代码改动，居然定位到了 CPU 利用率获取代码中，有 c 对象没有 free，所以代码的稳定性也是需要测试去考虑和关注的。


5. 网络相关测试
保证在不同网络类型，不同网络环境下，SDK 接口都能较好的处理。在涉及到多媒体资源或音视频通信，弱网下测试的需求较多，并且弱网下的处理通常需要反复优化和对比，不仅是新老版本效果对比，还包括竞品的效果对比测试

6. 安全性测试
对隐私数据保护，访问权限的控制，用户服务鉴权等，SDK 接口的安全性问题也是比较突出。安全性很多是在架构设计和开发设计中就考虑进去，但是最好还是有专门的安全性测试

上述诸多测试类型中，功能测试先行。在进行客户端SDK测试前，需要全面的了解测试对象的细节：
- 了解业务流程，结合API接口文档和开发指南，理顺接口的使用场景和调用关系；
- 了解 SDK 协议，理解协议中字段的意义以及服务器端的处理逻辑；
- 了解各接口或协议返回码，分析对应的场景；
- 了解开发实现细节，可以绘制成图，便于测试分析和分层验证。

对客户端 SDK 进行测试，可以采用的分层测试方式由上至下依次有：基于 Demo 和解决方案->基于接口调用->基于代码。

1、基于 Demo 和解决方案的测试
大多客户端SDK在提测时，都会有对应的Demo或者解决方案提交给测试，因此可以覆盖到该Demo或解决方案对应的接口或业务场景。而且测试人员可以比较直观的看到界面表现，上手快，所以在客户端SDK测试中比较常用，也是比较有效的。

但这种测试方式的缺点也很多，Demo对接口和业务场景覆盖比较有限，对接口的输入输出参数不能全覆盖，发现问题时定位复杂度增加。精心设计的Demo以及多解决方案的形式或许可以最大程度满足测试需要，但是需要较大的Demo开发测试投入，也使得问题暴露的时间大大滞后。基于Demo和解决方案的测试，可以是手工的也可以是UI层自动化测试。

2、基于接口调用的自动化测试
基于接口调用的测试，包括对单个接口的测试，也包括业务场景的覆盖。这种测试方式直接有效，需要一定开发基础

比如 SDK Repo（功能实现代码 + XCTest Case 代码），通过脚本同步 SDK 代码到测试 Repo，主要包括：SDK 功能实现代码 + XCTest Case 代码 + QA 的 XCTest 代码（Special TestCase + Normal TestCase）
其中，开发的测试 Case 走基础单元测试。QA 的 Special Test Case，专项测试的测试 Case（最小回归集等），日常测试的测试 Case

基于接口调用的自动化测试，需要有产品的思路、开发的知识和测试的思维，做起来有难度。但是因为SDK接口通常比较稳定，所以一旦实现并投入使用，测试效率和质量的收益都很大，值得拥有。

3、基于代码的单元测试
单元测试是为开发代码质量保驾护航的一个重要环节，在测试左移推进的道路上，大家越来越意识到单元测试的重要价值。特别是在一些核心业务上，值得开发同学投入精力去做。

其他测试类型的展开，跟应用层测试类似，就不再重复了。