个人介绍:大家好,我是大猫,2015年加入百度质量部,负责百度前端展现架构测试工具开发。曾负责并开发基于spark的阿拉丁模板召回查询系统与搜索前端阿拉丁模板页面diff工具,均取得良好效果。2018年加入贝壳质量部,全程参与贝壳网小程序接入微信支付与贝壳春晚全链路压测,并作为租赁压测负责人。
全链路压测
全链路压测一直是测试领域的一顶皇冠。
全链路压测对测试人员要求极高,不仅需要有性能测试知识,还要有一定的组织能力与工程能力。全链路压测不仅是一个测试任务,而是一个公司级别的超大型项目,全链路压测涉及到公司所有技术人员与职能部门,从压测准备到实施,直至压测完成后的改进与优化,通常需要涉及公司开发、测试、运维等多个部门协同合作,因此全链路压测更合理的组织方式是以项目形式展开,协同部门负责人进行牵头,集全公司之力以线上性能最优为目标进行的一次技术改进过程。
通常情况下项目上线前我们会对单一接口进行压测,此时我们可以获得单一接口性能的极限QPS数据,不过线上流量成分相当复杂,单一接口的性能数据并不能体现线上服务的真实情况。因此,我们还需要进行场景化的多接口性能压测。
假设我们的服务有100个接口,我们通过线上服务日志分析100个接口一天时间内的请求比例,我们根据请求流量配比可以很好地模拟线上流量,如果我们的压测工具支持日志回放,那么我们可以直接回放接入层日志进行本次压测,会更接近真实情况。
至此,我们已经较为完美的解决了压测流量构造的问题,但似乎事情并不像我们想象的那样简单,经过几次离线性能测试验证,你惊奇的发现我们的压测结果和线上的真实情况还存在较大差异,而造成这种差异出现的原因是压测环境与线上环境多方面不同的直接结果。
不幸的是通常情况下公司并不可能按照线上环境架构与性能要求1比1的搭建一套离线环境,因此生产环境的全链路压测就成为很多公司的必然选择,一旦决定在生产环境进行全链路压测,你会发现更加棘手的问题都排在后面,一个接着