https://testerhome.com/topics/33937

    • 形式：中台方作为基础能力或内容的供应商，以 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. 流程上的保障