背景
楼主在一个中台质量团队，这几年一直是接触整 App（宿主包）的质量保障工作。由于最近工作和 SDK 有所打交道，但是在这一块的经验很少，网上的方案也不全面，故开个帖子看看有没有兄弟姐妹们在这块上有些实践经验和心得的。
我的思考
先把我和同事最近思考和实践过的东西掰出来，抛砖引玉~文章源自玩技e族-https://www.playezu.com/189754.html
宿主（App）视角
- 形式：很多宿主都是平台类型的 App（业务爸爸），上面有很多第三方业务团队提供技术，这个时候宿主相当于一套复杂的业务框架，第三方提供自己的 SDK，宿主集成过来后，利用 SDK 的能力获取内容和对应的形式，呈现在自身的内容容器上。
- 质量痛点：随着集成的第三方 SDK 数量越来越多，有不少 SDK 迭代很频繁，随之而来的就是 SDK 自身的各种质量问题，功能、性能、稳定性、兼容等都会影响宿主，对用户体验影响比较明显的就是 crash 等稳定性问题（当然其他问题或多或少都会有影响，资损更严重，但是这里不展开讨论）
- 方案：
- 对第三方的 SDK 提出质量要求，在合入到宿主前，需要提供完整的测试报告 —— 治标不治本，或许能缓解问题但是不能解决问题，尤其是部分 SDK 根本没有测试团队，怎么办？
- 宿主自己出人兜底测试 —— 这是很常见的搞法，但是随着 SDK 集成的数量增多与复杂度的提升，成本是非线性增加的，不可持续。
- 宿主和 SDK 合作共建，一同建设 —— 这个或许才是正道吧，也就是特别想和大家讨论的点！目前看过的一些实践案例中，比较多都是一同梳理测试场景和 case，一同建设功能自动化在合入时做回归，这样的做法能兜住比较多问题，但是依然有各种潜在的增量风险是覆盖不到的，如 SDK 新功能引入的新风险，宿主方很难主动感知到。
SDK 视角
- 形式：中台方作为基础能力或内容的供应商，以 SDK 的形式嵌入到各个宿主 App 上，典型的中台 SDK 举几个例子，基础能力如播放器、RTC、投屏、跨端框架类似 Weex；内容供应如直播、电商等。
- 质量痛点：这里暂时只探讨有测试团队的 SDK 方，当 SDK 要发版时，关键问题有几个。一方面是 SDK 往往会集成在多个宿主上，需要在多个宿主上出包测试，宿主太多难以都顾及测试上，所以一般只挑几个复杂的大宿主去做测试，其他小宿主就比较惨了；另一方面 SDK 本身只希望关注自己的问题，宿主上崩溃很多，也还要进一步区分是否 SDK 自身引入的崩溃
- 方案：
- SDK 自建宿主 demo 做常规测试 —— 常见做法，也可以搞成 SDK Api 测试，偏白盒，也经常做成单元测试
- SDK 服务端接口测试 —— 常见做法，不过这里是针对 SDK 服务端做测试
- SDK 自行在多个宿主上建设功能自动化 —— 常见做法，看 SDK 团队的精力和对质量的重视程度
- SDK 代码扫描 —— 测试左移吧，常规做法
- SDK 出包，自动触发多个宿主打包，在各个宿主上以 scheme 跳转的形式做 SDK 的场景定向测试，宿主上发现的崩溃通过堆栈识别是否 SDK 相关崩溃 —— 目前我和同事们在建设的思路，出发点是为 SDK 做测试提效，不一定准确，但是应该有些实际意义
- …… 兄弟姐妹们共享一下 idea
一些其他还没仔细思考过的点：文章源自玩技e族-https://www.playezu.com/189754.html
- 基于数据埋点、日志的问题识别断言
- 其他的测试方式和测试能力（主要探讨稳定性、兼容性）
- 流程上的保障
软件测试自学文章源自玩技e族-https://www.playezu.com/189754.html 文章源自玩技e族-https://www.playezu.com/189754.html