背景
楼主在一个中台质量团队，这几年一直是接触整 App（宿主包）的质量保障工作。由于最近工作和 SDK 有所打交道，但是在这一块的经验很少，网上的方案也不全面，故开个帖子看看有没有兄弟姐妹们在这块上有些实践经验和心得的。
我的思考
先把我和同事最近思考和实践过的东西掰出来，抛砖引玉~
宿主（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
一些其他还没仔细思考过的点：
- 基于数据埋点、日志的问题识别断言
- 其他的测试方式和测试能力（主要探讨稳定性、兼容性）
- 流程上的保障
刚好在测 SDK，感觉楼主有几处说到我的痛点了...
先说结论：很难。
SDK 作为通用组件，对于业务方来说只是组成部分，对于 SDK 来说，你业务通常只是调用 SDK 的一个应用。
通常的做法都是业务去适配 SDK。
适配 SDK 的主要在于适配的成本，兼容性影响，SDK 的兼容性设计会成为瓶颈。
SDK 适配，对开发来说都是拉扯扯皮的麻烦事，沟通成本不会太低，对于更下游的测试，想测试 SDK 只会更加困难。
通过一些应用场景去覆盖 SDK 的功能，这可能是比较容易落地的。想根本改善 SDK 适配现状，这不是测试能解决的。
magicyang
回复
确实是这么个理，但是在质量视角，该兜底的还是得有自动手段去兜底，总不能一直归因到人的质量意识层面，因为这个很难去把控和改变。所以也挺没办法的，只能穷极各种不一定高效的手段去做质量守门员
到目前为止十年的职场生涯都在和 SDK 打交道，从 SDK 开发到 SDK 接入【即楼主说的宿主 APP，有本公司的也有第三方公司的】再到现在的 SDK 质量保障及公司平台 APP 的质量保障。总结下来有几点比较实用的方法供参考
1、宿主 APP 以组件化的方式构建，可以按需构建 DEMO【即主 APP 及包含 1 个待测 SDK】供 SDK 的 QA 进行测试，包括人工功能及非功能【兼容、稳定、性能】
2、约定接入标准，及包体积增量、对兼容、稳定、性能的影响，需 SDK 方给出测试报告，及版本基线比较。在接入后由宿主包侧给出自己 QA 的功能测试及非功能测试报告【double check 尽可能保证 SDK 的接入质量】
3、针对 ANR、CRASH 等问题，接入数据埋点统计，收集问题并做缺陷归类与分析。我们现在也有引入精准测试及覆盖率统计，来确定变更及影响范围，及测试后的覆盖情况，来辅助接入及发版决策。同步在推进开发侧完成相关 SDK 的代码单侧，基于代码调用的频次与风险等级来决定单测代码的编写优先级
上述：是在实践过程中一些比较好用且有效的方法，供参考。
1、宿主 APP 与 SDK 之间属于不同代表方（前端应用与中台），相互之间的边界（如 APP 与 SDK 之间的接口）是否清楚，例如，作为中台的 SDK，应提供接口给其他调用者使用，理论上 SDK 方需出具接口测试报告，以示提供的中台软件是有质量保障的
2、当 APP 与 SDK 集成后再验证，是偏业务场景的验证，放在 APP 端会更合适；
3、SDK 频繁升级，升级的内容 APP 是否需要？如果否，与 APP 一起集成的中台 SDK 可以指定版本进行构建，让 SDK 稳定下来
imath60
回复
同意，我们的思路有一部分就是打算提供一些标准给 SDK 方，告诉他们在什么环节应该要具备什么能力完成很么事情，会包含 imath60 所提及的这些内容~
不过标准归标准，当 SDK 越来越多，不同 SDK 的团队配置都不一样，就不能一概这样要求（也不实际，因为执行不下去），所以在宿主上还是有挺大的痛点解决不了（质量 与 效率）。
简11
回复
表达一下我的观点：
1、理论上，确实这么做是正确的，但是 SDK 团队有质量保障上的局限性和客观困难 —— 一方面 SDK 自身质量好，不等于集成在复杂的宿主上呈现出来的质量一定好；另一方面 SDK 客观不一定有测试团队，SDK 研发自己测试在宿主业务视角看来局限很大。
2、这么说理论上合理，但是当宿主集成的 SDK 越来越多，SDK 寄宿的宿主也越来越多，双方都无法顾得来。
3、在实际场景下可能更多的是这样：App 和 SDK 是一同升级的，经常是 SDK 的研发给 App 提接入代码，需要 SDK 的研发熟悉 App 的业务和技术框架，这个就很硬性要求了（尤其是平台型的 App，上面会集成很多集团的其他业务，如 淘宝）
其实有一个死结很难解（或者解不了，只能去缓和）：SDK 变更升级，宿主和 SDK 都有质量风险，在复杂的合作中，各自的边界划分好没问题，但是暂时找不到合适的手段将测试成本降低，以及提升效率。
王稀饭
回复
是的 平台侧【负责宿主 App】QA，组件侧【负责 SDK】QA 及业务侧【负责各业务方向内容】QA 的协同。是个值得讨论与持续跟踪的议题。在流程规范、技术应用、组织人员不同维度的协同。最终形成一套标准作业化体系及通用能力标准。
王稀饭
回复
1、首先，不知理解是否正确，应属于 APP 与 SDK 之间交互如何解藕的问题，其实站在任何一方而言，都想在主干上一直往前跑，然后随时可 release 版本。但对于宿主 APP 方，是否清楚 SDK 频繁变更的所有信息，及对自己的影响。如果不清楚，那么肯定被动。此时，看是否自动化一些用到 SDK 调用的场景用例，采用 2-8 原则，把风险业务优先保证，从而提升测试的效率。
2、其次，SDK 的质量，建议组织相关人员一起讨论，总会有一些办法的
imath60
回复
是的，老哥很有经验，这个是我们在做的一个事情，不过感觉这个事情在不久后就会遇到瓶颈。核心问题可能会转化为：
- 宿主 App 视角：我怎么把合到我身上来的 SDK 的质量把关兜底好，有无比较通用的测试方案
- SDK 视角：如何解决 SDK 发版多宿主测试的效率问题，如何有利用有限的人力来支撑不停增加的待测宿主
王稀饭
回复
宿主 APP 视角：做好 SDK 升级的版本频率控制。SDK 越多，升级后的风险越大，一般核心 SDK 的重点版本升级分散到不同的宿主 APP 版本迭代中，小流量 APP 先升级看效果，核心 APP 后升级保稳定
SDK 视角：矩阵宿主 APP，优先针对核心宿主 APP 及组件化框架的 DEMO 做人工适配，然后将这部分的工作以自动化脚本的形式落地下来，交给云测平台做多机型多 APP 的自动化回归，再人工审核结果及校验
来，说说看，楼主是字节哪个部门的