个人介绍：大家好，我是大猫，2015年加入百度质量部，负责百度前端展现架构测试工具开发。曾负责并开发基于spark的阿拉丁模板召回查询系统与搜索前端阿拉丁模板页面diff工具，均取得良好效果。2018年加入贝壳质量部，全程参与贝壳网小程序接入微信支付与贝壳春晚全链路压测，并作为租赁压测负责人。

全链路压测

全链路压测一直是测试领域的一顶皇冠。

全链路压测对测试人员要求极高，不仅需要有性能测试知识，还要有一定的组织能力与工程能力。全链路压测不仅是一个测试任务，而是一个公司级别的超大型项目，全链路压测涉及到公司所有技术人员与职能部门，从压测准备到实施，直至压测完成后的改进与优化，通常需要涉及公司开发、测试、运维等多个部门协同合作，因此全链路压测更合理的组织方式是以项目形式展开，协同部门负责人进行牵头，集全公司之力以线上性能最优为目标进行的一次技术改进过程。
通常情况下项目上线前我们会对单一接口进行压测，此时我们可以获得单一接口性能的极限QPS数据，不过线上流量成分相当复杂，单一接口的性能数据并不能体现线上服务的真实情况。因此，我们还需要进行场景化的多接口性能压测。

假设我们的服务有100个接口，我们通过线上服务日志分析100个接口一天时间内的请求比例，我们根据请求流量配比可以很好地模拟线上流量，如果我们的压测工具支持日志回放，那么我们可以直接回放接入层日志进行本次压测，会更接近真实情况。

至此，我们已经较为完美的解决了压测流量构造的问题，但似乎事情并不像我们想象的那样简单，经过几次离线性能测试验证，你惊奇的发现我们的压测结果和线上的真实情况还存在较大差异，而造成这种差异出现的原因是压测环境与线上环境多方面不同的直接结果。

不幸的是通常情况下公司并不可能按照线上环境架构与性能要求1比1的搭建一套离线环境，因此生产环境的全链路压测就成为很多公司的必然选择，一旦决定在生产环境进行全链路压测，你会发现更加棘手的问题都排在后面，一个接着一个。

数据加载

进行全链路压测前我们必须要进行的第一件事情就是准备压测数据。压测数据可以从线上请求日志里提取，也可以从线上数据库查询，当然很多情况下也可以使用脚本进行数据构造。这似乎并不是一件困难的事情，但在考虑服务存在缓存的情况下通常我们需要大量的测试数据，不同服务的请求要准备不同类型的数据，这些数据累加起来甚至能达到上百G，然而很多性能测试工具将数据存储在内存中，使用64G内存的发压机都是极其奢华的一件事情，可想而知这个问题对于我们有多棘手。

数据污染

对于读接口我们可以直接请求生产环境，这并不是一个大问题，但是对于写接口我们直接请求生产环境一定会在生产环境造成脏数据，这些数据甚至会直接暴露给用户，显然这不是我们希望发生的事情。除此之外，这些高并发性能工具生成的测试数据也会抢占缓存、消息队列与数据库等公共资源，从而直接影响到线上基础服务。

流量区分

压测流量对于数据分析人员造成更大的困扰。你在夜里加班加点的进行压测，早晨数据分析师来到公司看数据实时大盘，oh my god！产品的PV与UV以页面暴增了百分之三百，GMV增加五倍！

外部依赖

当然，以上几点都不是最为头疼的问题，如果你的系统有外部依赖，特别是涉及安全或财产的外部系统，那么问题会显得更为复杂。如洪峰一般的压测流量同样会传导给外部系统，在你辛辛苦苦压测时合作放的运维人员业务被刺耳的短信铃声叫醒。

当然，这些仅是全链路压测的一部分痛点，全链路压测的痛点远不止于此！

后面的文章我会逐步介绍全链路压测的相关解决方案，对关键技术进行解析。

作　　者：Testfan 大猫
出　　处：微信公众号：自动化软件测试平台
版权说明：欢迎转载，但必须注明出处，并在文章页面明显位置给出文章链接