背景

楼主在一个中台质量团队，这几年一直是接触整 App（宿主包）的质量保障工作。由于最近工作和 SDK 有所打交道，但是在这一块的经验很少，网上的方案也不全面，故开个帖子看看有没有兄弟姐妹们在这块上有些实践经验和心得的。

我的思考

先把我和同事最近思考和实践过的东西掰出来，抛砖引玉~

宿主（App）视角

• 形式：很多宿主都是平台类型的 App（业务爸爸），上面有很多第三方业务团队提供技术，这个时候宿主相当于一套复杂的业务框架，第三方提供自己的 SDK，宿主集成过来后，利用 SDK 的能力获取内容和对应的形式，呈现在自身的内容容器上。
• 质量痛点：随着集成的第三方 SDK 数量越来越多，有不少 SDK 迭代很频繁，随之而来的就是 SDK 自身的各种质量问题，功能、性能、稳定性、兼容等都会影响宿主，对用户体验影响比较明显的就是 crash 等稳定性问题（当然其他问题或多或少都会有影响，资损更严重，但是这里不展开讨论）
• 方案：
  1. 对第三方的 SDK 提出质量要求，在合入到宿主前，需要提供完整的测试报告 —— 治标不治本，或许能缓解问题但是不能解决问题，尤其是部分 SDK 根本没有测试团队，怎么办？
  2. 宿主自己出人兜底测试 —— 这是很常见的搞法，但是随着 SDK 集成的数量增多与复杂度的提升，成本是非线性增加的，不可持续。
  3. 宿主和 SDK 合作共建，一同建设 —— 这个或许才是正道吧，也就是特别想和大家讨论的点！目前看过的一些实践案例中，比较多都是一同梳理测试场景和 case，一同建设功能自动化在合入时做回归，这样的做法能兜住比较多问题，但是依然有各种潜在的增量风险是覆盖不到的，如 SDK 新功能引入的新风险，宿主方很难主动感知到。

SDK 视角

• 形式：中台方作为基础能力或内容的供应商，以 SDK 的形式嵌入到各个宿主 App 上，典型的中台 SDK 举几个例子，基础能力如播放器、RTC、投屏、跨端框架类似 Weex；内容供应如直播、电商等。
• 质量痛点：这里暂时只探讨有测试团队的 SDK 方，当 SDK 要发版时，关键问题有几个。一方面是 SDK 往往会集成在多个宿主上，需要在多个宿主上出包测试，宿主太多难以都顾及测试上，所以一般只挑几个复杂的大宿主去做测试，其他小宿主就比较惨了；另一方面 SDK 本身只希望关注自己的问题，宿主上崩溃很多，也还要进一步区分是否 SDK 自身引入的崩溃
• 方案：
  1. SDK 自建宿主 demo 做常规测试 —— 常见做法，也可以搞成 SDK Api 测试，偏白盒，也经常做成单元测试
  2. SDK 服务端接口测试 —— 常见做法，不过这里是针对 SDK 服务端做测试
  3. SDK 自行在多个宿主上建设功能自动化 —— 常见做法，看 SDK 团队的精力和对质量的重视程度
  4. SDK 代码扫描 —— 测试左移吧，常规做法
  5. SDK 出包，自动触发多个宿主打包，在各个宿主上以 scheme 跳转的形式做 SDK 的场景定向测试，宿主上发现的崩溃通过堆栈识别是否 SDK 相关崩溃 —— 目前我和同事们在建设的思路，出发点是为 SDK 做测试提效，不一定准确，但是应该有些实际意义
  6. …… 兄弟姐妹们共享一下 idea

一些其他还没仔细思考过的点：

1. 基于数据埋点、日志的问题识别断言
2. 其他的测试方式和测试能力（主要探讨稳定性、兼容性）
3. 流程上的保障