如果你是一名测试老人,全链路测试这个名词你一定不会陌生,特别是近年在大厂特别火的全链路压测。 其实,对于非TOP企业和中小企业,做全链路压测的成本特别高,并且没有必要(个人观点,不喜可以交流)。 但是全链路测试并不只有全链路压测,还有全链路功能测试。 今天,就我司最近的一个线上bug,同大家分享一个细节点——在全链路功能测试中,极容易忽略的超时时间问题。 老规矩,先讲问题。 我简单讲讲业务链路(涉及公司项目,已略作修改): 业务网关(内部)->会员系统(内部)->中间层(内部)->第三方系统(外部) 业务上,我们需要拿到合作的第三方系统的某些数据。 请求上,先走业务网关,由业务网关调我司内部的会员系统,再调我司内部与外部机构对接的中间层系统,中间层系统再调第三方。 项目上线后,出现什么问题了呢? 业务上拿不到第三方系统的数据。 (在该条业务上来说并不算特别严重,因为是特殊接口的超时时间,况且我们做了降级方案,即使拿不到三方系统的数据,也不会影响业务闭环) 问题原因:这条业务线上,各系统设置的特殊接口的超时时间不一样。 网关(内部)->会员系统(内部):超时时间10s 会员系统(内部)->中间层(内部):超时时间300ms 中间层(内部)->第三方系统(外部):超时时间500ms 因此,当中间层(内部)->第三方系统(外部),在300ms-500ms之间才返回结果时,会员系统早已当成超时处理。 在测试环境,很难模拟到这种场景,并且测试人员只会关注当前待测系统和下一个系统的业务流程,并不会站在整条链路上思考。 这是客观原因。 而我们要做的是从一次次问题中反思。 01 降级方案一定要做好 这次问题没有大范围出现,是因为有降级方案。即,倘若真出现这种异常场景,不能过分影响用户的体验,不能影响业务,同时,需要给产研测及时告警。 当然,身为测试的我们,在需求评审阶段,也应当思考类似的问题,问题抛出得越早,修复的成本越低。 02 梳理业务调用链,安排专项测试 因此,具体场景具体计划,我们组的计划是,在不耽搁其他项目的进度下,合力开展全链路超时时间的梳理,制定测试方案,输出测试用例。先解决当前问题,再进一步思考针对全链路的专项测试。 03 利用外部工具测试 如果是调用链很长的后端服务,要模拟各个系统之间的超时和异常比较困难,并且了解其他系统的接口、服务,还会涉及到人力成本、时间成本、沟通成本等。 这时,我们会考虑使用一些外部工具来模拟异常。阿里的混沌工程是一个不错的选择,感兴趣的小伙伴可以先了解了解,后面我也会出一些实战案例同大家分享这个工具。 01 系统异常的降级方案要考虑好; 02 做专项测试、异常测试,可以助你快速了解系统和业务的细节点; 03 根据公司实际情况,安排全链路测试,不能为了做而做。问题
反思
实际工作中,因为项目时间和人力成本的预算,要在短期内做一次完整的全链路测试,不太现实。要知道,单就梳理调用链路和调用接口,不仅耗时,还对测试人员的业务水平、技术能力有较高的要求。一如既往,做个总结
最后
联系客服