性能测试之技术指南

Posted 2021-10-11 半醉半醒半浮生

　　本文从技术角度制定性能测试实施过程中关键的技术规范。这些规范可以帮助PTS的用户更好地从技术上来

规避系统上线后的风险、评估线上系统的真实能力、根据业务模型摸底线上能力以提前应对。

适用范围

　　适用于所有需要性能测试的项目。 对性能测试实施过程中非常重要、关键的相关技术进行分析，主要包括：

系统环境、测试指标、业务模型、数据量、测试模型、测试类型、脚本（API）、场景、监控、瓶颈分析、调优

和性能测试分布式云化压测工具。

系统环境

分析

　　系统环境分为生产环境、测试环境等。两个环境的方案各有其优缺点，生产环境衡量的精准度较高，参考效

果更好，但是需要清理相关的测试数据（同时要保证数据删除的完整性，基础数据的构造参考后续数据量部分）

或者BI统计的时候过滤，或者更彻底的方案是参考阿里首创的全链路压测方式，生产环境的压测尽量挑选在低峰

期进行，避免对生产业务造成影响；单独的测试环境风险可控，难点在环境的构建上，规模和生产一致的成本

也是最高的，所以一般而言有通过等比构建（1/2，1/4，1/8等），甚至是生产环境中部分应用独立部署测试集

群，数据库共用的方式，此外测试环境需要从生产环境中导入脱敏的基础数据，例如至少是最近半年或者1年的，

保持其整体的数据关联性，这个对于压测的准确度和参考性也很重要。 

风险

　　测试环境的风险主要体现在跟生产的差异度，测试结果的参考价值会打一定程度的折扣，可以视自身情况

选择合理的方式，例如看重入口网络的检验的，可以测试环境和生产环境共享入口。 对测试环境系统平台、中

间件、数据库等不熟悉和不了解，也会导致瓶颈不易分析、不易调优。

规范

1. 1. 测试环境搭建

      在熟知以上问题的前提下，测试环境搭建应尽量满足如下规范：

      • 测试环境架构与生产环境架构完全相同。
      • 测试环境机型与生产环境机型尽量相同，云化的资源确保是同规格ECS或者容器。
      • 测试环境软件版本与生产环境软件版本完全相同，版本主要包括：操作系统、中间件相关、数据库、应用等。
      • 测试环境参数配置与生产环境完全相同，参数主要包括：操作系统参数、中间件参数、数据库参数、应用参数。
      • 测试环境基础数据量与生产环境基础数据量需在同一个数量级上。
      • 只能减少测试环境机器台数，并且需要同比例缩小，而不能只减少某一层的机器台数。
      • 理想的测试环境配置是生产环境的1/2，1/4。
   2. 测试环境调研

      测试环境调研，需要调研如下内容：

      • 系统架构：系统如何组成的，每一层功能是做什么的，与生产环境有多大差异，主要为后面进行瓶颈分析服务和生产环境性能评估，这个很重要。
      • 操作系统平台：操作系统是哪种平台，进行工具监控。
      • 中间件：哪种中间件，进行工具监控和瓶颈定位。
      • 数据库：哪种数据库，进行工具监控和瓶颈定位。
      • 应用：启动多少个实例，启动参数是多少，进行问题查找和瓶颈定位。

      可以配合APM工具（如ARMS）进行中间件、数据库、应用层面的问题定位。

测试指标

分析

　　测试指标一般分为业务指标、资源指标、应用指标、前端指标。

• 业务指标：如并发用户数、TPS（系统每秒处理事务数）、成功率、响应时间。
• 资源指标：如CPU资源利用率、内存利用率、I/O、内核参数（信号量、打开文件数）等。
• 应用指标：如空闲线程数、数据库连接数、GC/FULL GC次数、函数耗时等。
• 前端指标：如页面加载时间、网络时间（DNS、连接时间、传输时间等）。

风险

　　不同用户对指标类型和期望值是不一样的，需要提前针对不同角色的人员进行指标调研、设定阈值，测试

出系统在阈值下的性能，瓶颈定位及调优。若您未提前关注测试指标，将会导致测试结果不是相关人员需要的，

结果是无效的。

规范

1. 1. 业务指标
      • 业务响应时间（Response Time）：这个指标所有相关人员都明白其含义，业务部门更需要此指标的具体值，一般情况下，不同系统的业务响应时间期望值是不同的，建议１秒以内。像淘宝系统业务RT基本在几十毫秒以内。
      • 业务处理能力（Transaction Per Second）：具体指标为TPS（Transaction Per Second，即系统每秒处理事务数），这个指标是衡量系统的处理能力的一个非常重要的指标。TPS可以参照同行业系统和结合具体业务，中小企业TPS值为50~1000笔/秒，银行TPS值为1000~50000笔/秒，淘宝TPS值为30000~300000笔/秒。
      • 成功率：这个指标是衡量系统处于压力下，业务的成功率，一般业界成功率要大于99.6%。
   2. 资源指标

      一般情况下，系统资源指标也不能超过瓶颈值，例如CPU资源利用率≤75%，内存无SWAP，磁盘和网络I/O不能自动处理。理想的情况下，当系统压力上不去的时候，资源成为瓶颈（正常情况下，非其他瓶颈情况下导致），这样的话加资源，系统处理能力还会上升的，但是遗憾的是，很多系统性能测试资源都没达到瓶颈的时候，压力就上不去了。

业务模型

分析

　　系统有很多业务，每种业务逻辑和业务量是不一样的，消耗系统的资源也不一样，因此业务种类、业务

占比决定了系统的处理能力，业务模型在性能测试中起着关键性的作用。以电商场景为例，不同的促销形式

和主推的类目决定了不同的容量整体配比，那么精准地将流量落地在PTS上进行压测拿到系统的木桶最短板

可以更好的利用机器资源达到业务目的。

风险

　　业务模型中业务和占比选取不对，跟生产差异非常大，直接导致测试结果没有任何参考价值，并且容易

误导对系统处理能力的判断。 有些业务的业务量虽然占比很低，但一旦突变，对系统也是致命的，这些业务

在性能测试中也需要关注。

规范

　　系统中的典型业务如何选取一般情况下遵循的规则是选取业务量高的、经常使用的、有风险的、未来有

增长趋势的业务作为系统的典型业务。已经上线的系统可以通过高峰时段历史业务量和生产问题性能来评估，

对于即将上线的系统可以通过调研和单交易资源消耗的结果来评估。

1. 1. 已上线系统
      • 搜集生产上不同高峰时间段的业务种类和业务量，每个时间段的业务种类和业务量是否有很大的差异，如有的话，必须有多个业务模型，差异不大的，可以只用一个业务模型。
      • 搜集生产上高峰时间段资源消耗和资源异常的时间点，从中捕获资源消耗高和异常的原因，可能是由于某种”不起眼”的业务导致。
      • 搜集生产问题，进行分析，如果是由于某种业务导致而且以前性能测试的时候忽略此笔业务，那么这笔业务的风险是非常大的，需要后续性能测试将此业务加入到业务模型中。
   2. 未上线系统
      • 通过调研，确定业务种类和业务占比。
      • 通过调研，确定是否在业务促销等活动中，某些业务有突变的可能。
      • 通过测试结果，确定每笔业务的资源消耗，如果某些业务虽然占比低，但资源消耗非常大，那么需要适当的调整此业务占比。

数据量

分析

　　数据量主要包括基础数据量（或者叫历史数据量、垫底数据量、数据库中已有的数据量）和参数化数据

量，数据量在性能测试中起到非常重要的作用。 对于在数据库中只有几条记录和有几亿条记录里面查询信息，

那么结果肯定相差非常大的。随着业务量的增长，记录也越来越多，因此使用性能测试环境时，需要保持跟

生产上相同级别的数据量。如果采用在生产环境中插入测试账户的方式，可以一定程度解决环境真实性和基

础数据量同量级的问题。 阿里全链路压测的方式对于基础数据量的要求和上述类似。 然后，我们在测试的时

候需要考虑参数数据量的大小和数据分布的问题。

风险

　　如果基础数据量跟生产环境的基础数据量不在同一个数量级上，将会导致相关指标例如响应时间比生产上

快很多，不真实，甚至导致测试结果没有参考意义。 如果参数化数据量过少、未考虑数据分布的情况，将会导

致测试结果不真实，甚至测试结果没有参考意义。 生产环境中插入测试账户的方式，需要考虑数据准备的完整

性问题，还有清理的逻辑需要完整。 全链路压测的方式需要投入较大的改造成本，同时包括后续的持续迭代维护。

规范

1. 1. 基础数据量

      如果是测试环境，基础数据量需要跟生产环境基础数据量保持在同一个数据量级上，一般情况下需要考虑未来三年数据量增长趋势，如果增长过快需要在测试环境造非常多的数据。

   2. 参数化数据量
      • 参数化数据量尽可能的多，必要的情况下，可以清除缓存或者用写代码的方式提供参数化。
      • 参数化数据分布，如果业务有明显的地域等分布的特征，需要考虑数据分布的情况。

测试模型

分析

　　测试模型是在业务模型的基础上演变而来的，一般情况测试模型和业务模型是相同的，但是由于某种业

务无法模拟或者安全原因，需要去掉此笔业务，重新计算占比得出。

风险

1. • 参照上述业务模型风险。
   • 去掉的业务如果有风险，那么需评估此笔业务的风险，风险大的情况下，需采取其他解决方案。

规范

　　参照上述业务模型规范。

测试类型

分析

　　测试类型主要分为负载测试、压力测试，其中包括单交易基准测试、负载测试、压力测试、混合交易

负载测试（容量测试）、业务突变测试、混合交易稳定性测试、混合交易可靠性测试、批量测试、批量测

试对混合交易影响测试等。 每种测试类型针对不同的目的，可以根据生产系统现实情况进行选择。

风险

　　缺少某种测试类型，将会导致现实生产系统某种场景没有测到，发生风险，例如：系统崩溃、响应时

间慢等。

规范

　　如果时间充足，建议大部分测试类型都需要测试一下，也可以参考以下规范：

1. • 单交易基准测试：可选
   • 单交易负载测试：可选，未上线系统建议做负载，看资源消耗
   • 混合交易负载测试（容量测试）：必须
   • 混合交易压力测试：可选
   • 业务突变测试：可选
   • 混合交易稳定性测试：必须
   • 混合交易可靠性测试：可选
   • 批量测试：可选
   • 批量测试对混合交易影响测试：可选

串联链路

分析

　　串联链路是指一组含有某种业务含义的压测API的有序集合（类似事务），串联链路是用来模拟用户

侧的业务操作，模拟的正确与否直接影响着系统的性能，模拟业务操作的时候，需要参数化数据。

风险

　　业务没有做成功或业务逻辑与实际生产环境差距太大将会导致测试结果没有参考价值。

规范

1. • 跟生产上业务规则一致编排串联链路。
   • 在关键地方校验服务器返回值，为压测API（指一条由用户行为触发的端上请求）添加检查点即断言。
   • 数据尽量参数化、数据量尽可能的多。

场景

分析

　　（压测）场景是若干个基于HTTP/HTTPS的URL/API的组合，用于模拟现实生产环境中业务场景，包

括施压模式、压力递增方式、运行时间等。 场景模拟需要跟生产上场景相一致，特别是在一段时间内，测

试出来的各业务TPS占比跟生产上高峰时候业务占比一致。

风险

　　场景的风险主要体现在测试出来的业务TPS占比需跟生产上业务占比一致，在业务比例偏离严重的情

况下，将会导致测试结果不真实或者无效，不能反映生产上的业务场景。

规范

　　测试结果中各业务TPS占比需跟生产上业务占比（业务模型）相一致，可以使用PTS特有的RPS模式

（Request Per Second，直接测试吞吐能力）来保证一致。 例如：A和B两笔业务，占比为1：4，响应时

间分别为1ms、100ms，那么只需要通过PTS给A和B两个接口按照1：4比例设置请求数（TPS）施压即可。

如果使用传统的并发模式，A和B的并发需要经过换算确保比例是1：400，使得最终与生产上保持一致的

业务模型。

监控

分析

　　监控的目的主要是为进行性能测试分析服务的，完善的对系统进行监控，针对瓶颈定位起到”事半功倍”

的效果。 一般来说，需要针对操作系统、中间件、数据库、应用等进行监控，每种类型的监控尽量指标全面。

风险

　　没有完善的系统监控，将会导致性能分析无从下手，定位不出系统瓶颈，根本不知道从哪进行调优。

规范

1. • 操作系统：CPU（User、Sys、Wait、Idle）利用率、内存利用率（包括Swap）、磁盘I/O、网络I/O、内核参数等。
   • 中间件：线程池、JDBC连接池、JVM（GC/FULL GC/堆大小）。
   • 数据库：效率低下SQL、锁、缓存、会话、进程数等。
   • 应用：方法耗时、同步与异步、缓冲、缓存。

瓶颈分析

分析

　　瓶颈定位的目的是对系统中存在的瓶颈点进行分析，为调优做准备，系统的性能瓶颈点主要分布在操

作系统资源、中间件参数配置、数据库问题以及应用算法上，对于有针对性的进行调优，有利于系统性能

的提升。

风险

　　当系统的瓶颈点不能被分析出来以后，新业务上线或者核心业务就存在风险，这种风险有可能导致业

务高峰的时候，系统性能体验差，甚至“崩溃”。

规范

　　分析系统的瓶颈点遵循的规则如下：

1. • 操作系统资源消耗：CPU、Memory、Disk I/O、Network I/O。
   • 中间件指标：线程池（Thread Pool）、数据库连接池（JDBC）、JVM（GC/FULL GC/堆大小）。
   • 数据库指标：效率低下SQL、锁等待/死锁、缓存命中率、会话、进程等。
   • 应用：方法耗时、算法、同步和异步、缓存、缓冲。
   • 压力机：压力机资源消耗，一般情况下，压力机成为瓶颈的可能性非常低。PTS压力机有保护和调度机制不用单独关注。

调优

分析

　　调优的目的是提升系统的性能，针对系统的“瓶颈点”对症“下药”，通过测试验证系统的性能有多大的提升。

风险

　　未进行调优的系统，系统上线后，可能会出现客户体验差的效果，甚至导致系统“崩溃”的风险。

规范

　　系统调优遵循的规则如下：

1. • 中间件调优：线程池、数据库连接池、JVM。
   • 数据库调优：效率低下SQL、死锁和锁等待、缓存命中率，进程和会话参数。
   • 应用调优：方法耗时、算法、同步和异步、缓存、缓冲。
   • 系统资源：一般情况下，系统资源（例如CPU等）大部分是由应用和参数设置不合理导致的，并非系统资源真的不够”用”。

作者：Sweettesting —— 半醉半醒半浮生

出处：http://www.cnblogs.com/Sweettesting/

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

「 性能测试技术笔记系列」之性能测试工具选型

一、浅谈为什么需要工具

我们来看下工具的定义：它原指工作时所需用的器具，后引申为为达到、完成或促进某一事物的手段。（---来自百度的解释） 

1、从人类进化的角度来看，会制造并使用工具是人和猿人最根本的区别，因为工具可以帮助我们提高生产力和效率。

2、想象下如果不使用工具进行性能测试会怎么样？

我们可以从性能测试的定义的角度来分析 ， 性能测试是指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。如果不使用工具，仅靠人工进行性能测试会存在以下的弊端：

a）测试需要投入大量的资源：

为了模拟多种负载、并发的场景需要多人协同工作，通常测试没有很多的资源，而且就算有资源人工的效果也会大打折扣，甚至于某些场景仅凭人工是无法完成的。

b）可重复性非常差：

性能测试经常需要反复调优和测试执行，如果没有工具的帮助，全靠人工实在不敢想象。

c）测试准确性较差：

由于需要模拟多种负载和并发场景，如果由人工来操作，难免会存在误差，而且相对工具或程序来说这种误差会更大，对测试结果影响也非常大。

d）结果的收集、整理和呈现形式差：

如果没有工具，全凭人工采集数据相对工具来说也会存在较大的误差。

二、性能测试与性能测试工具的关系

1、性能测试从测试阶段来划分属于系统测试，其和具体使用什么工具并没有直接的关系。使用工具只是为了提高性能测试效率和准确性的一种方法和手段。从本质上来看，同做其它事情时使用工具没有什么实质性的区别。

2、性能测试不等于Loadrunner，LR只是性能测试工具其中的一种，而且它也不是万能的，在某些情况下它也并不能派上用场。

3、自动化测试工具与性能测试工具的区别：性能测试工具一般是基于通信协议的（客户器与服务器交换信息所遵守的约定），它可以不关心系统的UI，而自动化使用的是对象识别技术，关注UI界面。自动化无法或很难造成负载，但是通过协议很容易。

三、性能测试工具选型参考：

通常在公司或项目中，我们选择任何工具时都会做一些调研，目的就是为了选择适合公司或项目的工具。那么性能测试工具也不例外，通常可以从以下几个方面进行考虑：

1、成本方面：

a）工具成本：工具通常分为商业闭(shou)源(fei)和非商业开(mian)源(fei)两种，商业工具通常功能比较强大，收费，由于收费所以可提供售后服务，如果出了问题有专业人士帮忙处理。而开源工具通常是免费的，功能有限，维护工具的组织也是自发的，所以如果碰到问题需要自行解决，没有专人提供服务。具体选择商业还是开源的工具，需要根据公司的情况，比如公司规模、愿意承担的成本、项目综合情况等方面考虑。一般来看大公司通常可以承担的起工具的费用，会考虑购买商业工具。而小公司由于资金压力，可能会选择开源的工具。

b）学习成本：使用任何工具都需要进行学习，这样一来就会产生学习成本（比如：时间），因此我们在选择工具时也需要考虑到项目组成员的学习成本。如果有两种工具A和B都能满足项目组测试的需求，如果A工具大部分人都会使用，而B工具只有极少部分人会使用，那么建议优先考虑A工具。通常，对于测试人员最好熟悉一款流程的商业（性能）工具，一款开源免费（性能）工具，还需要熟悉常见的（性能）脚本开发语言等，这是基本要求。

2、支持的协议：

性能测试通常跟协议联系非常紧密，比如B/S的系统通常使用http协议进行客户端和服务器商的信息交换，C/S的系统通常使用socket协议进行信息交换。在选择工具时，需要考虑项目使用的协议。一个测试工具能否满足测试需求，能否达到令人满意的测试结果，是选择测试工具要考虑的最基本的问题。

3、生命力：

现在的性能测试工具非常多，比如LR，jmeter这类较大众的工具网上相关的资料非常多，但一些小众工具可能网上资料比较少。如果在工具使用过程中碰到了比较极手的问题，在录求解决方案或帮助时，大众的的工具相对来说会比较有优势一点，毕竟使用的人越多，资料越多，那么自己碰到的问题也许别人早就碰到并解决了，即时之前没有人碰到过，由于使用研究的人多，通过社区或论坛的帮助相信总会有高手能协助解决的。

4、跨平台：

这一点自不必多说，看看JAVA为什么一直在流行就知道了。

5、二次开发的能力

工具支持二次开发，能够更好地契合测试需求，更方面地统计结果数据，并能很好地与公司现有系统做集成。

四、常见性能测试工具：

性能测试工具，从理论上来讲在性能测试过程中使用到的所有工具都可以称其为性能测试工具，通常分为以下几类：

说明：

• 服务器端性能测试工具：需要支持产生压力和负载，录制和生成脚本，设置和部署场景，产生并发用户和向系统施加持续的压力。
• web前端性能测试工具：需要关于心浏览器等客户端工具对具体需要展现的页面的处理过程。
• 移动端性能测试工具：同web端性能测试工具也需要关心页面的处理过程，另外还要具体数据采集的功能，比如：手机CPU、内存、电量，启动时间等数据的记录。
• 资源监控工具：这个主要是能够收集性能测试过程中的数据以及良好的结果展现方式。

PS：本篇文章主要总结下服务器端性能测试工具LR和Jmeter、kylinTOP，后面也会对这三个工具进行简单的对分。

五、常见性能测试工具特点

• JMeter：采用的是多线程模型，扩展性很强，不过制造压力没有那么高。它很适合用来压一些Tomcat服务，或者一些后端接口。JMeter的缺点是压力值不能精确控制，难以适应高并发的情况，而且由于是JAVA编写的，本身比较消耗资源。
• LoadRunner：更像是一个模拟器，它比较适用于前端构造较复杂场景的情况，比如模拟100个用户登录的场景，LoadRunner对非技术人员提供了很好的支持。LoadRunner不适用后端接口。
• kylinTOP：是一款国产的集性能测试、自动化测试（UI、接口、APP）、业务&接口监控于一体的测试平台，支持跨平台（WINDOWS/LINUX/SOLARIS/麒麟/MAC等）运行。

下面为JMeter和LoadRunner、kylinTOP对比表：

描述	JMeter	LoadRunner	kylinTOP
架构原理	通过中间代理，监控和收集并发客户端的指令，把他们生成脚本，再发送的应用服务器，再监控应用服务器反馈的过程	同JMeter	BS架构，企业级平台，支持多人同时操作；支持项目管理、模块管理、用户管理、脚本用例管理、参数文件管理；支持多次运行报告历史对比、单个接口多次运行历史对比
安装	简单，解压即可，比较灵活	LoadRunner安装包比较大，安装比较麻烦，工具本身相对比较笨重	一路傻瓜式安装，记住安装目录位置
支持的协议	支持多种协议：HTTP、HTTPS、SOAP、FTP、Database via JDBC、JMS等，但相对LR还是不够全面，由于此原因相对来说jemter比较灵活，轻便	支持的协议非常多，比较全面，但正因此显得工具本身比较笨重，不够灵活	支持多种协议，支持HTTP/HTTP2、RTSP、RTMP、Socket、JAVA自定义等
脚本录制	提供了一个利用本地ProxyServer（代理服务器）来录制生成测试脚本的功能，也支持badboy录制再生成JMeter脚本	自带录制功能强大，可直接录制回放	支持浏览器代理录制、抓包文件录制
并发模型	通过增加线程组的数目，或者是设置循环次数来增加并发用户	支持多种并发模型，通过在场景中选择要设置什么样的场景，然后选择虚拟用户数	强大且灵活的并发模型，包括用户数/秒、CAPS/秒、目标模型，详细请点击链接
分布式测试	支持，可设置多台代理，通过远程控制实现多台机器并发压力	同JMeter	支持控制多个压测机实现分布式并发测试
资源监控	通过JMeterPlugins插件和ServerAgent实现	自带资源监控功能	提供Monitor代理器，支持CPU、内存、I/O、交换区、磁盘读写数、吞吐量等资源指标
报告分析	通过与Ant集成，生成HTML报告	自身支持生成HTML、Word报告	支持合并指标曲线、曲线过滤、曲线放大缩小、比较不同测试结果、日志分析，生成HTML报告
虚拟IP	不支持	支持	支持系统虚拟IP与工具虚拟IP（支持更多IP占用资源更低）
网速模拟	不支持	支持	支持限制每个用户上传/下载带宽
扩展性	开源，可根据需求修改源码	通过扩展函数库实现	支持JAVA语言扩展，解决私有算法或业务处理，如加解密，JavaScript计算
学习成本	主要是自学官网上的资料	网上资料和相关培训很多，购买正版的话，还有技术支持	部分功能付费的，大家判断是否可用，可以去看看价格

六、总结：

商用性能工具在易用性（脚本生成）、并发模型、统计指标上要比开源免费软件要好很多，可以大大提高工作效率，降低使用难度，在统计指标上要丰富的多。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取