docs: 移动端质量保障

Chapter1 - iOS/1.99.md

@@ -1,4 +1,4 @@
-#  App 质量把控
+#  客户端质量把控
 
 > 笔者结合中台经验，本文重点谈谈 App 的质量稳定性该如何做。业务作为 App 的核心服务之一，业务异常监控当然也很重要，这不是本文重点。
 
@@ -86,3 +86,108 @@ QA 指派的测试用例一定要冒烟通过，冒烟打回很严重的，这
 
 
 
+## 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、基于代码的单元测试
+单元测试是为开发代码质量保驾护航的一个重要环节，在测试左移推进的道路上，大家越来越意识到单元测试的重要价值。特别是在一些核心业务上，值得开发同学投入精力去做。
+
+其他测试类型的展开，跟应用层测试类似，就不再重复了。