-
第三方产品的质量要求与我们的不一致，比如功耗要求不同、比如支持的系统范围差异等等。 -
第三方产品的排期与我们的排期步调不一致；又或者是项目进展不顺利导致无法按时交付。 -
第三方产品的提测质量不高，导致集成测试不顺利。比如经常崩溃、比如接口跑不通。 -
双方信息不同步，出现意外问题，引发bug 甚至返工，比如需求或接口变化双方没有及时同步。 -
第三方产品的单方面升级，导致原有功能失效。
首先，要求对方提供相关结论性的文档，比如测试结论，根据结论来评估第三方产品对我们的影响。
需要第三方提供的结论包含但不限于以下内容：
-
第三方产品存在哪些风险及其影响范围。 我们需要评估这些风险和影响，能否接受。 -
第三方产品存在哪些遗留问题。 我们需要评估这些遗留问题，能否接受。 -
第三方产品会需要哪些额外的系统权限。 我们需要评估这些权限是否敏感，能否接受。 -
第三方产品的一些关键性能指标， 比如内存占用、cpu、耗电量、流量消耗等。需要对方提供核心功能或常见操作路径的相关性能指标，以评估对我们产品本身的综合影响，以免影响用户口碑。 -
第三方产品支持的系统版本范围。 如果支持的版本少于我们产品的范围，那么需要进行相应的策略调整，比如在不支持的系统上禁用相关功能。 -
第三方产品的适配测试范围。 需要评估对方选择的机型和系统适配范围是否充分，能够满足要求。 -
第三方产品的体量。 需要评估对方的产品的大小是否符合我方的要求，毕竟接入后会增加我们产品的大小，需要有一定的限制。 -
第三方产品服务端相关接口的性能指标。 根据我们自身的实际情况（用户使用量），评估对方的服务端性能是否能够满足预期。
-
项目管理角度：
-
明确对接人，遇到问题明确协调和解决问题的对象。 -
项目进度公示时，相互同步，进度和风险共知。 -
项目排期预留提前量，避免进度风险导致项目delay 。比如期望第三方提供最终版的时间点，比自己上线的deadline 早几天，用作风险缓冲。 -
第三方产品，单方面版本迭代时，需要提前周知，并给出相关影响范围。
-
产品角度：
-
涉及双方的需求和需变，需要同步，组织双方集中评审和讨论，不能单独形成结论。万一牵扯到其他方，或者其他方无法按预期实现呢。
-
开发角度：
-
开发提供的接口文档要明确、详细，并且统一确认。 -
开发过程中，涉及 接口的变化要及时同步。
-
测试角度：
-
根据双方开发负责的范围，划定测试范围。 -
外围接口调用自己负责，第三方内部功能逻辑第三方同学负责。 -
双方涉及接口交互的部分，如果很难划分，建议同步关注。
具体方式，包括但不限于以下几种：
-
约束开发的自测。包括明确涉及第三方产品时，自测的开发负责人（一般是己方涉及的开发同学），提供自测case ，规范的自测流程等等 -
第三方产品进行集成测试后的预测试，开发自测靠谱吗？不靠谱吗？总之自己过一下，安全系数会高不少。 -
针对第三方产品的相关功能进行随机测试，看看有没有什么遗漏掉的，也检查一些对方的稳定性。 -
建立第三方产品迭代时的验收流程，每次第三方产品改动时，需要进行相关的回归测试。当然自己产品迭代，有相关风险时，也需要进行相关的回归测试。 -
做好线上监控，比如线上崩溃的手机，把自己和第三方产品的崩溃信息区分开，出现问题后，能够明确问题的来源。
本文分享自微信公众号 - 搜狗测试（SogouQA）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
