最近有一些接入第三方sdk和第三方页面的项目,这种情况普遍都会有一些坑,相信接触过的小伙伴们都深有体会。
其中的问题千奇百怪,比如下面这几种,还比较常见:
第三方产品的质量要求与我们的不一致,比如功耗要求不同、比如支持的系统范围差异等等。
第三方产品的排期与我们的排期步调不一致;又或者是项目进展不顺利导致无法按时交付。
第三方产品的提测质量不高,导致集成测试不顺利。比如经常崩溃、比如接口跑不通。
双方信息不同步,出现意外问题,引发bug甚至返工,比如需求或接口变化双方没有及时同步。
第三方产品的单方面升级,导致原有功能失效。
为了能够提升产品质量,降低风险,我们可以从以下几个方面做一些事情:
首先,要求对方提供相关结论性的文档,比如测试结论,根据结论来评估第三方产品对我们的影响。
需要第三方提供的结论包含但不限于以下内容:
第三方产品存在哪些风险及其影响范围。我们需要评估这些风险和影响,能否接受。
第三方产品存在哪些遗留问题。我们需要评估这些遗留问题,能否接受。
第三方产品会需要哪些额外的系统权限。我们需要评估这些权限是否敏感,能否接受。
第三方产品的一些关键性能指标,比如内存占用、cpu、耗电量、流量消耗等。需要对方提供核心功能或常见操作路径的相关性能指标,以评估对我们产品本身的综合影响,以免影响用户口碑。
第三方产品支持的系统版本范围。如果支持的版本少于我们产品的范围,那么需要进行相应的策略调整,比如在不支持的系统上禁用相关功能。
第三方产品的适配测试范围。需要评估对方选择的机型和系统适配范围是否充分,能够满足要求。
第三方产品的体量。需要评估对方的产品的大小是否符合我方的要求,毕竟接入后会增加我们产品的大小,需要有一定的限制。
第三方产品服务端相关接口的性能指标。根据我们自身的实际情况(用户使用量),评估对方的服务端性能是否能够满足预期。
其次,提前做好多方沟通,并将信息及时同步这件事情贯穿于整个项目期间。以从以下几个方面考虑:
项目管理角度:
明确对接人,遇到问题明确协调和解决问题的对象。
项目进度公示时,相互同步,进度和风险共知。
项目排期预留提前量,避免进度风险导致项目delay。比如期望第三方提供最终版的时间点,比自己上线的deadline早几天,用作风险缓冲。
第三方产品,单方面版本迭代时,需要提前周知,并给出相关影响范围。
产品角度:
涉及双方的需求和需变,需要同步,组织双方集中评审和讨论,不能单独形成结论。万一牵扯到其他方,或者其他方无法按预期实现呢。
开发角度:
开发提供的接口文档要明确、详细,并且统一确认。
开发过程中,涉及接口的变化要及时同步。
测试角度:
测试同学需要集中沟通,明确双方的测试范围。可以参考以下思路作为依据,划分测试范围:
根据双方开发负责的范围,划定测试范围。
外围接口调用自己负责,第三方内部功能逻辑第三方同学负责。
双方涉及接口交互的部分,如果很难划分,建议同步关注。
此处是重点:
不管采用什么沟通方式,最终的结论一定要:邮件公示!重要的事情再说三遍:邮件!邮件!邮件!
最后,不管第三方产品情况如何,从测试角度我们都应该做好基础的防护措施。毕竟真出了问题,挨骂的可能是你的产品,而不是人家。
具体方式,包括但不限于以下几种:
约束开发的自测。包括明确涉及第三方产品时,自测的开发负责人(一般是己方涉及的开发同学),提供自测case,规范的自测流程等等
第三方产品进行集成测试后的预测试,开发自测靠谱吗?不靠谱吗?总之自己过一下,安全系数会高不少。
针对第三方产品的相关功能进行随机测试,看看有没有什么遗漏掉的,也检查一些对方的稳定性。
建立第三方产品迭代时的验收流程,每次第三方产品改动时,需要进行相关的回归测试。当然自己产品迭代,有相关风险时,也需要进行相关的回归测试。
做好线上监控,比如线上崩溃的手机,把自己和第三方产品的崩溃信息区分开,出现问题后,能够明确问题的来源。
本文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理