8年测试总结,性能测试-全链路压测核心链路详解,一点通透...

目录:导读

    • 前言
    • 一、Python编程入门到精通
    • 二、接口自动化项目实战
    • 三、Web自动化项目实战
    • 四、App自动化项目实战
    • 五、一线大厂简历
    • 六、测试开发DevOps体系
    • 七、常用自动化测试工具
    • 八、JMeter性能测试
    • 九、总结(尾部小惊喜)


前言

抛出一个问题:什么是核心链路?

很多企业都会有自己核心的业务范围,这些核心业务也往往是主要的企业利润来源。

以电商企业为例,为用户提供商品的购买服务,为商家提供商品的管理和上架及定价展示,利润大多为撮合用户和商家交易所来带的服务费以及广告等相关费用。

所谓的核心链路,从技术角度来说可以这么理解:
核心业务对应的核心应用中,保证达成企业利润实现的最主要请求流量经过的路径,即是核心链路。

这么说比较拗口,再直白一些就是:哪些接口会影响用户下单支付,哪些就是核心链路。

下面附一个常见的电商企业核心链路流程图:

8年测试总结,性能测试-全链路压测核心链路详解,一点通透..._第1张图片

为什么要确定核心链路?

做测试的同学对这一点很熟悉,无论是需求评审的优先级,还是写测试case时候为开发提供的冒烟case,甚至提交BUG时候对BUG进行优先级划分,都会进行优先级划分,什么原因呢?

因为我们大多数时候面临的情况,是要在有限的时间和人力资源范围内,即保证交付的质量,又要尽可能多的完成更多工作任务和需求。

特别是对于类似电商双11大促这种很复杂的项目,要做的事情太多,时间和人力资源有限,涉及到的业务范围应用范围又很多,这个时候需要做一个取舍。

可能部分未在覆盖范围内的业务和应用会出现一些问题,但如果保障核心业务和应用的稳定性,可以使企业的业务目标更好的达成,那这些损失还是可以接受的。

而且并不是说非核心的业务和应用稳定性我们就不关注了,而是通过其他技术手段如限流、降级、熔断或者业务入口关闭来解决这个问题。

如何进行核心链路梳理?

8年测试总结,性能测试-全链路压测核心链路详解,一点通透..._第2张图片

上图是以电商企业订单应用为例子,进行了一个简单的业务调用链路的梳理,这里做一个拆解性的讲解。

确定核心业务范围为交易业务;
确定核心应用其中有订单应用;
订单服务中流量请求占比最高的接口为订单确认、订单创建、订单列表和订单详情;
通过链路追踪的手段确定这四个接口的下游依赖调用都是哪些服务和接口或者中间件;
确定这些下游依赖的关系是强依赖还是弱依赖,以及是否有外部三方服务的调用关系;
强依赖熔断,弱依赖降级,订单服务的接口本身做限流,外部三方服务依赖进行mock;

梳理核心链路的目的是什么?

示意图如下:

8年测试总结,性能测试-全链路压测核心链路详解,一点通透..._第3张图片

梳理核心链路的主要目的,主要有获取流量模型、知道强弱依赖、制定稳定性预案。

流量模型

一个案例,这里再次回顾下:

客单价为500,单日GMV为10亿,那么支付订单量为10亿/500=200W;

假设日常支付订单量为50W,支付转化率为40%,订单支付QPS峰值为200。预估大促时的支付转化率为60%,则可得:大促峰值订单支付QPS为(200/40%)60%(200W/50W)=1200QPS。这个1200QPS是个保底数值,一般为了留有一定冗余空间,会上浮30%,即订单支付的QPS预估为1500;

电商的导购浏览下单支付转化链路一般为:首页→商品详情→创建订单→订单支付→支付成功,这个过程是类似漏斗的一个转化逻辑。

假设首页→商品详情转化率为40%,商品详情→创建订单转化率为40%,创建订单→订单支付转化率为40%,那么可得:创建订单QPS为1500/40%=3750,商品详情QPS为3750/40%=9375,首页QPS为9375/40%=23437;

确定了核心链路的预期流量指标后,可以通过链路间的依赖关系不断的扩大评估范围,直到形成一个流量模型。

流量模型是个类似漏斗状的转化过程,从流量入口到最底层的DB是有不同的转化率的。链路越向下,QPS越低。

通过转化率来评估预期的流量然后通过链路依赖梳理,来形成一个流量模型。

这里需要注意的是,用户日常和大促时候的流量模型是不一样的,因为大促时候用户的目标更明确,因此转化率较高。从业务指标转化为技术指标,需要你对业务很熟悉,不要只盯着技术。

强弱依赖

通过流量模型以及梳理得到强弱依赖关系后,接下来就是根据依赖的关系设定各种稳定性预案了。

这里要注意的一点是,很多的预案需要和业务或者产品做提前沟通,比如主动降级或者业务入口关闭,因为这些降级动作是需要业务方知晓并且配合来操作的,而不仅仅是一个技术上的动作。

稳定性预案

稳定性预案,主要目的是保障线上应用在类似电商双11期间的流量峰值冲击下能保证服务的稳定性,为业务目标的达成提供良好的保障。

稳定性预案也分不同的类型,或者说不同情况下要设定不同的预案,而不是一个通用的东西,需要根据企业的技术设施建设以及技术团队具体的情况来评估。

最常见的稳定性预案就是我们上面提到的限流熔断降级,再高大上点就是容灾恢复、主备切换、业务入口关闭甚至什么断电保护之类的种种。

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

8年测试总结,性能测试-全链路压测核心链路详解,一点通透..._第4张图片

二、接口自动化项目实战

8年测试总结,性能测试-全链路压测核心链路详解,一点通透..._第5张图片

三、Web自动化项目实战

8年测试总结,性能测试-全链路压测核心链路详解,一点通透..._第6张图片

四、App自动化项目实战

8年测试总结,性能测试-全链路压测核心链路详解,一点通透..._第7张图片

五、一线大厂简历

8年测试总结,性能测试-全链路压测核心链路详解,一点通透..._第8张图片

六、测试开发DevOps体系

8年测试总结,性能测试-全链路压测核心链路详解,一点通透..._第9张图片

七、常用自动化测试工具

8年测试总结,性能测试-全链路压测核心链路详解,一点通透..._第10张图片

八、JMeter性能测试

8年测试总结,性能测试-全链路压测核心链路详解,一点通透..._第11张图片

九、总结(尾部小惊喜)

成功来自于自己的努力和付出,而不是依赖他人或偶然性的运气。只要心怀信念和热情,坚持努力,勇往直前,相信自己,就一定能在未来取得更大的成就。

一份耕耘一份收获,努力就一定会有回报。挫折与失败只是暂时的,不要放弃自己的梦想。唯有怀揣着坚定的信念,不断追求卓越,才能实现美好的人生。

每个人都有自己的梦想和目标,但只有那些不怕失败、继续奋斗的人才能最终实现它们。坚持不懈、勇往直前,成功就在不远处!

你可能感兴趣的:(性能测试,软件测试,压力测试,软件测试,性能测试,压力测试,软件测试工程师,jmeter性能测试)