自动化性能测试的理解误区

技术交流群有同学问了一个问题：性能测试手动执行效率太低，能否通过自动化来快速执行，提前发现潜在的性能问题。有没有什么工具或者方法可以提高压测的执行效率，或者落地过程要注意的事项。正好之前工作中有过这方面的实践，这篇文章聊聊这个话题。

性能测试实施流程

先聊聊正常的性能测试实施流程。一般情况下性能测试实施的流程是这样的：

• 需求分析：什么业务/场景/问题，预期目标；
• 构建模型：业务模型、流量模型、数据模型；
• 压测准备：环境准备、脚本开发调试、监控检查；
• 压测实施：按照case执行脚本，监控指标，定位分析；
• 压测报告：场景覆盖度，结果是否达标，对线上的容量规划建议(结论)；

当然，在实际的工作场景中，出于时间/资源/团队规模和技术建设等各方面的因素，会有会多或少的改变。但性能测试相比于自动化测试来说，有一点很大的区别在于：自动化测试是单一场景，每条case的执行结果原则上不会影响自动化测试最终的结果(整体覆盖率/成功or失败)；但性能测试如果用自动化的方式来执行，就存在case之间互相影响的情况，原因是什么呢？

性能测试理解误区

部分同学会认为，性能测试和自动化测试很类似，都是用工具模拟请求响应，但性能测试在实施时存在每个case互相影响的情况，主要原因有这几点。

首先是系统架构，以现在流行的微服务架构来说，每个服务或者组件之间的调用关系是很复杂的，如果多个性能case同时执行，就可能存在某个模块在同一时间被多次调用，产生资源竞争的问题。

其次是调用链路，自动化测试只需要关注结果是成功或者失败，而影响性能的因素是很多的，在请求链路上每个环节都可能存在影响性能的因素，比如发现一条慢SQL，但实际上是其他因素导致出现了慢SQL，并不是正在执行的这条性能case本身存在性能问题。

还有就是环境资源和数据方面的问题，性能测试一般建议在单独的不受其他因素影响的独立环境开展，且要求服务配置和生产环境保持一致或者某种可换算的比例。测试所涉及到的铺底数据和测试数据也需要专门准备，并且要根据场景和压测目标准备一定量级的数据(最起码10W起步，也可能百万千万级别的数据量)。

因此性能测试工作如果想要长期稳定流畅的开展，就需要搞定这几方面：

• 独立等配或等比例的性能测试环境；
• 符合业务场景和测试要求的数据量；
• 清晰的业务模型、流量模型、数据模型；
• 完善的监控覆盖、及时的变更响应、明确的变更范围；

自动化执行性能测试

最后，聊聊本文的主题：自动化执行性能测试。

我在之前的工作实践中，将其称之为性能基线，而自动化执行只是性能基线的一种实现手段，而不是目的。要实现自动化执行性能测试，在我看来需要满足如下几个前置条件：

• 稳定的性能测试环境(数据铺底/数据预热/服务发布/版本控制/完善的监控/硬件资源等比同配置)；
• 测试场景覆盖率足够高(P0/P1场景全覆盖，P2场景部分覆盖)，这样才能建立起业务模型和流量模型；
• 按照业务域对测试场景(脚本)进行划分，划分的原则是该场景不存在重叠的调用关系(服务调用层)；
• 每个脚本定义好执行时间，通过任务调度的方式将存在重叠调用关系的场景间隔开，错峰执行，自动记录结果；
• 设定好每个场景的基准参考值，然后对未通过的场景进行人工执行确认，排查可能存在的性能问题；
• 合理的流程机制(融入日常研发交付流程)，明确的团队内职责范围划分；

最后，这种自动化执行性能测试的方式，或者说性能基线，只是性能测试体系的一部分，它的作用就是查漏补缺，让工程师可以将精力尽可能专注于日常的迭代变更带来的性能风险控制方面，而且前提一定是性能测试的case覆盖率要达到一定程度，否则只会事倍功半。

文中提到的性能基线，基准测试，三大模型和常态化方案，请参考文末推荐。

性能测试的理解误区

如何分析性能测试需求？

性能测试知识科普(一)

性能测试知识科普(二)

性能测试知识科普(三)

全链路压测常态化方案

聊聊性能测试中的基准测试

聊聊基准测试的可行性方案

性能测试知识科普(四)：分析需求

性能测试知识科普(五)：能力分层

性能测试知识科普(六)：三大模型

性能测试知识科普(七)：监控能给你带来什么