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

2021-02-04  测试奇谭 

大家好,我是测试奇谭的作者谭叔,这是我在testwo发表的第3篇我文章。

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

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

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

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

老规矩,先讲问题。

问题

我简单讲讲业务链路(涉及公司项目,已略作修改):

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

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

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

项目上线后,出现什么问题了呢?

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

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

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

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

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

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

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

反思

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

这是客观原因。

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

01 降级方案一定要做好

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

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

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

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

03 利用外部工具测试

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

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


一如既往,做个总结

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

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

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

67°|675 人阅读|0 条评论
登录 后发表评论