回调测试需要注意什么，你都清楚吗？

最近接手了一个通过API+H5的方式和其它公司合作的引流项目，涉及几个节点数据的回调。因为用户是在我们H5页面操作，但对第三方来说都是未知的，我们需要把结果实时回调过去，他们在APP上才能展示相关状态。如果回调错了或者回调不及时，虽然在我们这边流程是正常的，但是会影响交互的准确性和实时性。

什么是回调测试

我们知道，在理解功能的时候，需要了解系统间、模块间的交互及时序：这个事件的触发点是什么，前提条件是什么，之后会有什么动作，然后从中找出测试点。

还要考虑这些事务（通过HTTP/MQ交互或者直接查数据库）的先后顺序会不会有异常情况，失败了如何处理、会不会重试都需要考虑。

回调测试要注意什么

这个项目中发现了两个因为事务的先后顺序及失败对回调造成影响的问题。一个是前一个事务未处理完成，就触发了回调，但是这时候查询结果为空，导致回调了错误的数据。

另一个是触发回调时，前面已经进行的另一步操作导致回调时查询的结果错误，所以也是回调了错误的结果。

前一种是异常才会出现的情况，第二种是有限定条件会触发的情况。针对这样的问题需要慎重考虑回调的时机在哪里触发合适，在满足一致性和准确性中找到稍微平衡的点。

还有一个可以解决部分异常的方式，也是必须要考虑的回调处理方式，就是重试机制。

当回调第三方时由于我方或者第三方的网络、服务宕机等原因导致未回调成功，需要将任务标记成未回调成功状态（这就需要每次对回调任务进行入库处理），并且有定时任务重新发起回调。

同时，在回调前组装数据时发现数据库记录为空、记录异常等情况，也需要将任务置为其它状态，待定时任务重新发起查询之后再回调。

其实回调应该有两种方式：同步回调和异步回调。为了确保准确性，大都会选择做异步回调，或者同时设计同步和异步回调。如果对实时性要求比较高，只做实时回调，就需要像前面说的一样，注意交互的异常和时序问题。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取