/catalog/8c20a890c29547bb9d2b11c1e90556f9//catalog/a84bd1ce15ce477988eb1f186af1c5a6//Document/269499107774533.html/catalog/b4ab5bd4dfc943d5a3936e0b59fd3cd1//Document/287564821766213.html/Document/287211232673861.html/Document/286932191875141.html/Document/286475571720261.html/Document/285370483953733.html/Document/285096802934853.html/Document/282332783972421.html/Document/281913457070149.html/catalog/e13529ce4d89402683b7df8ee1f2b24e/

全链路测试场景分析

前面的文章我们为大家介绍了全链路测试要测哪些内容,与传统压力测试有什么不同?接下来我们一起来看一下全链路测试的场景分析怎么做。首先我们需要对全链路的环境进行分析。像我们前面说的,需要什么样的服务器,硬盘空间要多大,在环境分析这个环节要分析清楚。

压力测试业务链分析

压测业务链分析,就像前面说的,不管是电商平台也好,或者说我们的打车系统也好,整个业务流是怎么样划分的。拿一个最简单的打车的例子来讲,我们平时打车的业务流有下单、呼叫、呼叫的过程中对方接单成功。上车后整个过程JDBC连接数、线程数都不能断。


因为有时候我们打长途车会有1、2个小时都在车上,在性能测试过程中,JDBC不能断开,连接一旦断开,就有问题了,这笔交易就算是失败了。


上车属于交易成功了,但是在接下来的行程过程中,还没下车,这个交易场景一直存在,服务器不能把这个线程中断,这种长期链接会导致对象的链接已释放,但是大对象没有释放,就会导致内存的泄漏溢出。这种情况我们只要通过token产生链接就好,不会出现数据占用。


如果在呼叫的过程中,我再重新呼叫一次,就会产生服务器繁忙。接单成功后,乘客上车,堵车的情况下,整个业务链的时间短,但是交易的时间长,这些情况我们都要模拟出来。


打车成功后,接下来是下车过程中的结算,模拟高并发就可以了。


接下来是复杂度分析,要跟我们的架构师去分析。分析的过程中可能会出现容量估算分析,我们在高并发的时候需要模拟这些内容去测。数据库里有些已经交易完成了,有些是未交易的,各种状态类型的数据在容量估算分析的过程中都要分析进去。


场景分析把硬件、业务、容量和技术的复杂度都要罗列出来考虑清楚。