全链路测试：容易忽略的上下游超时时间

如果你是一名测试老人，全链路测试这个名词你一定不会陌生，特别是近年在大厂特别火的全链路压测。

其实，对于非TOP企业和中小企业，做全链路压测的成本特别高，并且没有必要（个人观点，不喜可以交流）。

但是全链路测试并不只有全链路压测，还有全链路功能测试。

今天，就我司最近的一个线上bug，同大家分享一个细节点——在全链路功能测试中，极容易忽略的超时时间问题。

老规矩，先讲问题。

问题

我简单讲讲业务链路（涉及公司项目，已略作修改）：

业务网关(内部)->会员系统(内部)->中间层(内部)->第三方系统(外部)

业务上，我们需要拿到合作的第三方系统的某些数据。

请求上，先走业务网关，由业务网关调我司内部的会员系统，再调我司内部与外部机构对接的中间层系统，中间层系统再调第三方。

项目上线后，出现什么问题了呢？

业务上拿不到第三方系统的数据。

（在该条业务上来说并不算特别严重，因为是特殊接口的超时时间，况且我们做了降级方案，即使拿不到三方系统的数据，也不会影响业务闭环）

问题原因：这条业务线上，各系统设置的特殊接口的超时时间不一样。

网关(内部)->会员系统(内部)：超时时间10s

会员系统(内部)->中间层(内部)：超时时间300ms

中间层(内部)->第三方系统(外部)：超时时间500ms

因此，当中间层(内部)->第三方系统(外部)，在300ms-500ms之间才返回结果时，会员系统早已当成超时处理。

反思

在测试环境，很难模拟到这种场景，并且测试人员只会关注当前待测系统和下一个系统的业务流程，并不会站在整条链路上思考。

这是客观原因。

而我们要做的是从一次次问题中反思。

01 降级方案一定要做好

这次问题没有大范围出现，是因为有降级方案。即，倘若真出现这种异常场景，不能过分影响用户的体验，不能影响业务，同时，需要给产研测及时告警。

当然，身为测试的我们，在需求评审阶段，也应当思考类似的问题，问题抛出得越早，修复的成本越低。

02 梳理业务调用链，安排专项测试
实际工作中，因为项目时间和人力成本的预算，要在短期内做一次完整的全链路测试，不太现实。要知道，单就梳理调用链路和调用接口，不仅耗时，还对测试人员的业务水平、技术能力有较高的要求。

因此，具体场景具体计划，我们组的计划是，在不耽搁其他项目的进度下，合力开展全链路超时时间的梳理，制定测试方案，输出测试用例。先解决当前问题，再进一步思考针对全链路的专项测试。

03 利用外部工具测试

如果是调用链很长的后端服务，要模拟各个系统之间的超时和异常比较困难，并且了解其他系统的接口、服务，还会涉及到人力成本、时间成本、沟通成本等。

这时，我们会考虑使用一些外部工具来模拟异常。阿里的混沌工程是一个不错的选择，感兴趣的小伙伴可以先了解了解，后面我也会出一些实战案例同大家分享这个工具。

一如既往，做个总结

01 系统异常的降级方案要考虑好；

02 做专项测试、异常测试，可以助你快速了解系统和业务的细节点；

03 根据公司实际情况，安排全链路测试，不能为了做而做。

最后