接入第三方的产品时，我们不需要做点什么吗？

最近小编手里有一些接入第三方sdk和第三方页面的项目，这种情况普遍都会有一些坑，相信接触过的小伙伴们都深有体会。

其中的问题千奇百怪，比如下面这几种，还比较常见：

• 第三方产品的质量要求与我们的不一致，比如功耗要求不同、比如支持的系统范围差异等等。
• 第三方产品的排期与我们的排期步调不一致；又或者是项目进展不顺利导致无法按时交付。
• 第三方产品的提测质量不高，导致集成测试不顺利。比如经常崩溃、比如接口跑不通。
• 双方信息不同步，出现意外问题，引发bug甚至返工，比如需求或接口变化双方没有及时同步。
• 第三方产品的单方面升级，导致原有功能失效。

为了能够提升产品质量，降低风险，我们可以从以下几个方面做一些事情： 首先，要求对方提供相关结论性的文档，比如测试结论，根据结论来评估第三方产品对我们的影响。 需要第三方提供的结论包含但不限于以下内容：

1. 第三方产品存在哪些风险及其影响范围。我们需要评估这些风险和影响，能否接受。
2. 第三方产品存在哪些遗留问题。我们需要评估这些遗留问题，能否接受。
3. 第三方产品会需要哪些额外的系统权限。我们需要评估这些权限是否敏感，能否接受。
4. 第三方产品的一些关键性能指标，比如内存占用、cpu、耗电量、流量消耗等。需要对方提供核心功能或常见操作路径的相关性能指标，以评估对我们产品本身的综合影响，以免影响用户口碑。
5. 第三方产品支持的系统版本范围。如果支持的版本少于我们产品的范围，那么需要进行相应的策略调整，比如在不支持的系统上禁用相关功能。
6. 第三方产品的适配测试范围。需要评估对方选择的机型和系统适配范围是否充分，能够满足要求。
7. 第三方产品的体量。需要评估对方的产品的大小是否符合我方的要求，毕竟接入后会增加我们产品的大小，需要有一定的限制。
8. 第三方产品服务端相关接口的性能指标。根据我们自身的实际情况（用户使用量），评估对方的服务端性能是否能够满足预期。

其次，提前做好多方沟通，并将信息及时同步这件事情贯穿于整个项目期间。以从以下几个方面考虑：

• 项目管理角度：
  1. 明确对接人，遇到问题明确协调和解决问题的对象。
  2. 项目进度公示时，相互同步，进度和风险共知。
  3. 项目排期预留提前量，避免进度风险导致项目delay。比如期望第三方提供最终版的时间点，比自己上线的deadline早几天，用作风险缓冲。
  4. 第三方产品，单方面版本迭代时，需要提前周知，并给出相关影响范围。
• 产品角度：
  1. 涉及双方的需求和需变，需要同步，组织双方集中评审和讨论，不能单独形成结论。万一牵扯到其他方，或者其他方无法按预期实现呢。
• 开发角度：
  1. 开发提供的接口文档要明确、详细，并且统一确认。
  2. 开发过程中，涉及接口的变化要及时同步。
• 测试角度：

测试同学需要集中沟通，明确双方的测试范围。可以参考以下思路作为依据，划分测试范围：

1. 根据双方开发负责的范围，划定测试范围。
2. 外围接口调用自己负责，第三方内部功能逻辑第三方同学负责。
3. 双方涉及接口交互的部分，如果很难划分，建议同步关注。

此处是重点：

不管采用什么沟通方式，最终的结论一定要：邮件公示！重要的事情再说三遍：邮件！邮件！邮件！

最后，不管第三方产品情况如何，从测试角度我们都应该做好基础的防护措施。毕竟真出了问题，挨骂的可能是你的产品，而不是人家。 具体方式，包括但不限于以下几种：

1. 约束开发的自测。包括明确涉及第三方产品时，自测的开发负责人（一般是己方涉及的开发同学），提供自测case，规范的自测流程等等
2. 第三方产品进行集成测试后的预测试，开发自测靠谱吗？不靠谱吗？总之自己过一下，安全系数会高不少。
3. 针对第三方产品的相关功能进行随机测试，看看有没有什么遗漏掉的，也检查一些对方的稳定性。
4. 建立第三方产品迭代时的验收流程，每次第三方产品改动时，需要进行相关的回归测试。当然自己产品迭代，有相关风险时，也需要进行相关的回归测试。
5. 做好线上监控，比如线上崩溃的手机，把自己和第三方产品的崩溃信息区分开，出现问题后，能够明确问题的来源。