​摘自：https://help.aliyun.com/document_detail/29337.html?spm=5176.doc29330.6.608.kVigSz

1 编写目的

制定性能测试实施指南，从技术角度制定性能测试实施过程中关键技术规范，更好的对系统进行性能测试，帮助客户更好地从技术上来规避系统上线后的风险。

2 适用范围

适用于性能测试所有需要性能测试的项目。对性能测试实施过程中非常重要、非常关键的相关技术进行分析；主要包括：系统环境、测试指标、业务模型、数据量、测试模型、测试类型、脚本、场景、监控、瓶颈分析、调优、性能测试分布式压测工具。

3 系统环境

3.1 分析

系统环境分为生产环境、测试环境等，做性能测试之前，肯定需要一套测试环境的，那么如何搭建、配置测试环境，在性能测试前需重点考虑。性能测试结果是要为生产系统服务的，那么理想中的性能测试关键最好就是生产环境，但是由于某种因素，不可能将生产环境完整的再搭建一套，有时必须进行”裁剪”。

3.2 风险

测试环境的风险主要体现在跟生产差异太大，测试结果根本没有参考价值。对测试环境系统平台、中间件、数据库等不熟悉和了解，也会导致瓶颈不易分析、不易调优等。

3.3 规范

3.3.1 测试环境搭建

测试环境搭建需满足如下规范：

测试环境架构与生产环境架构完全相同

测试环境机型与生产环境机型尽量相同

测试环境软件版本与生产环境软件版本完全相同，版本主要包括：操作系统、中间件、数据库、应用等

测试环境参数配置与生产环境完全相同，参数主要包括：操作系统参数、中间件参数、数据库参数、应用参数

测试环境基础数据量与生产环境基础数据量需在同一个数量级上。

只能减少测试环境机器台数，并且需要同比例缩小，而不能只减少某一层的机器台数。

理想的测试环境配置是生产环境的1/2，1/4。

3.3.2 测试环境调研

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

系统架构：系统如何组成的，每一层功能是做什么的，与生产环境有多大差异，主要为后面进行瓶颈分析服务和生产环境性能评估。

操作系统平台：操作系统是哪种平台，进行工具监控。

中间件：哪种中间件，进行工具监控和瓶颈定位。

数据库：哪种数据库，进行工具监控和瓶颈定位。

应用：启动多少个实例，启动参数是多少，进行问题查找和瓶颈定位。

4 测试指标

4.1 分析

测试指标一般分为业务指标、资源指标、应用指标、前端指标：业务指标：从业务人员的角度得出来的，例如：并发用户数、TPS、成功率、响应时间。资源指标：从运维人员的角度得出来的，例如：CPU资源利用率、内存利用率、I/O、内核参数(信号量、打开文件数)等。应用指标：从开发人员的角度得出来的，例如：空闲线程数、数据库连接数、GC/FULL GC次数、函数耗时等。前端指标：从测试人员和开发人员角度得出来的，例如：页面加载时间，网络时间（DNS，连接时间、传输时间等）。

4.2 风险

不同用户对系统的指标类型和期望值是不一样的，需要提前针对不同角色的人员进行指标调研，设定阈值，测试出系统在阈值下的性能，瓶颈定位及调优。未提前关注测试指标，将会导致测试结果不是相关人员需要的，结果是无效的。

4.3 规范

4.3.1 业务指标

业务响应时间(Response Time):这个指标所有相关人员都明白其含义，业务部门更需要此指标的具体值，一般情况下，不同系统的业务响应时间期望值是不同的，１秒以内最佳；像淘宝系统业务ＲＴ基本在几十毫秒以内。

业务处理能力（Transaction Per Second）:这个指标是衡量系统的处理能力的一个非常重要的指标，TPS可以参照同行业系统和结合具体业务，中小企业TPS值为50~1000笔/秒，银行TPS值为1000~10000笔/秒，淘宝TPS值为30000~100000笔/秒。

成功率:这个指标是衡量系统处于压力下，业务的成功率，一般业界成功率要大于99.6%。

4.3.2 资源指标

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

5 业务模型

5.1 分析

系统有很多业务，每笔业务逻辑和业务量是不一样的，消耗系统的资源也是不一样的，因此业务种类、业务占比决定了系统的处理能力，业务模型在性能测试中起着关键性的作用。

5.2 风险

业务模型中业务和占比选取不对，跟生产差异非常大，直接导致测试结果没有任何参考价值，并且容易误导对系统处理能力的判断。有些业务的业务量虽然占比很低，但一旦突变，对系统也是致命的，这些业务在性能测试中也需要关注。

5.3 规范

系统中的典型业务如何选取一般情况下遵循的规则是选取业务量高的、经常使用的、有风险的、未来有增长趋势的业务作为系统的典型业务。已经上线的系统可以通过高峰时段历史业务量和生产问题性能来评估，对于即将上线的系统可以通过调研和单交易资源消耗的结果来评估。

5.3.1 已上线系统

搜集生产上不同高峰时间段的业务种类和业务量，每个时间段的业务种类和业务量是否有很大的差异，如有的话，必须有多个业务模型；差异不大的，可以只用一个业务模型。

搜集生产上高峰时间段资源消耗和资源异常的时间点，从中捕获资源消耗高和异常的原因，可能是由于某种”不起眼”的业务导致。

搜集生产问题，进行分析，如果是由于某种业务导致而且以前性能测试的时候忽略此笔业务，那么这笔业务的风险是非常大的，需要后续性能测试将此业务加入到业务模型中。

5.3.2 未上线系统

通过调研，确定业务种类和业务占比

通过调研，确定是否在业务促销等活动中，某些业务有突变的可能。

通过测试结果，确定每笔业务的资源消耗，如果某些业务虽然占比低，但资源消耗非常大，那么需要适当的调整此业务占比。

6 数据量

6.1 分析

数据量主要包括基础数据量（或者叫历史数据量、垫底数据量、数据库中已有的数据量）和参数化数据量，数据量在性能测试中起到非常重要的作用。对于在数据库中只有几条记录和有几亿条记录里面查询信息，那么结果肯定相差非常大的，随着业务量的增长，记录也越来越多，因此在性能测试过程中，需要保持跟生产上相同级别的数据量。生产系统中业务中使用不同的数据、那么我们在测试的时候需要考虑参数数据量的大小和数据分布的问题。

6.2 风险

如果基础数据量跟生产环境的基础数据量不在同一个数量级上，将会导致相关指标例如响应时间比生产上快很多，不真实，甚至导致测试结果没有参考意义。如果参数化数据量过少、未考虑数据分布的情况，将会导致测试结果不真实，甚至测试结果没有参考意义。

6.3 规范

6.3.1 基础数据量

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

6.3.2 参数化数据量

参数化数据量尽可能的多，必要的情况下，可以清除缓存或者用写代码的方式提供参数化。

参数化数据分布，如果业务有明显的地域等分布的特征，需要考虑数据分布的情况。

7 测试模型

7.1 分析

测试模型是在业务模型的基础上演变而来的，一般情况测试模型和业务模型是相同的，但是由于某种业务无法模拟或者安全原因，需要去掉此笔业务，重新计算占比得出。

7.2 风险

参照５业务模型风险

去掉的业务如果有风险，那么需评估此笔业务的风险，风险大的情况下，需采取其他解决方案。

7.3 规范

参照５业务模型规范。

8 测试类型

8.1 分析

测试类型主要分为负载测试、压力测试；其中单交易基准测试、负载测试、压力测试；混合交易负载测试（容量测试）、压力测试；业务突变测试；混合交易稳定性测试；混合交易可靠性测试；批量测试、批量测试对混合交易影响测试等是常见的测试类型。每种测试类型针对不同的目的，可以根据生产系统现实情况进行选择。

8.2 风险

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

8.3 规范

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

单交易基准测试：可选

单交易负载测试：可选，未上线系统建议做负载，看资源消耗

混合交易负载测试（容量测试）：必须

混合交易压力测试：可选

业务突变测试：可选

混合交易稳定性测试：必须

混合交易可靠性测试：可选

批量测试：可选

批量测试对混合交易影响测试：可选

9 脚本

9.1 分析

脚本是用来模拟生产环境系统的业务操作，脚本模拟的正确与否直接影响着系统的性能，模拟业务操作的时候，需要参数化数据，参数化数据分布及数据量在６数据量章节已经分析过了。

9.2 风险

脚本“空转”（业务没有做成功）或业务逻辑与实际生产环境差距太大将会导致测试结果没有参考价值，甚至系统上线后，系统“宕机”的生产事故。

9.3 规范

跟生产上业务规则一致编写脚本。

在关键地方校验服务器返回值。

数据尽量参数化、数据量尽可能的多。

10 场景

10.1 分析

场景是模拟现实生产环境中业务场景的，包括并发用户数、加减压策略、运行时间等。场景模拟需要跟生产上场景相一致，特别是在一段时间内，测试出来的各业务TPS占比跟生产上高峰时候业务占比一致。

10.2 风险

场景的风险主要体现在测试出来的业务TPS占比需跟生产上业务占比一致，在业务比例偏离严重的情况下，将会导致测试结果不真实或者无效，不能反映生产上的业务场景。

10.3 规范

测试结果中各业务TPS占比需跟生产上业务占比（业务模型）相一致，如何才能保证一致呢？需要设置步调时间（PacingTime）：例如：A和B两笔业务，占比为1：4，响应时间分别为1ms,100ms,总的用户数为50，那么A和B按照业务比例并发用户数分别为10和40，测试出来的TPS分别为10000(10个用户/0.001秒)笔/秒和400笔/秒，那么TPS比例为25:1,跟生产上差距非常大，严重偏离生产上业务模型，此时我们设置A和B的PacingTime都为200ms,那么测试出来的TPS分别为50（10个用户/0.2秒）笔/秒和200笔/秒，A和B业务TPS比例50:200=1:4,与生产上保持一致了，没有偏离生产上业务模型。

11 监控

11.1 分析

监控的目的主要是为进行性能测试分析服务的，完善的对系统进行监控，针对瓶颈定位起到”事半功倍”的效果。一般来说，需要针对操作系统、中间件、数据库、应用等进行监控，每种类型的监控尽量指标全面。

11.2 风险

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

11.3 规范

操作系统：CPU(User,Sys,Wait,Idle)利用率，内存利用率(包括Swap),磁盘I/O,网络I/O，内核参数等

中间件：线程池、JDBC连接池、JVM（GC/FULL GC/堆大小）

数据库: 效率低下SQL、锁、缓存、会话、进程数等

应用：方法耗时、同步与异步、缓冲、缓存

12 瓶颈分析

12.1 分析

瓶颈定位的目的是对系统中存在的瓶颈点进行分析，为调优做准备，系统的性能瓶颈点主要分布在操作系统系统资源、中间件参数配置、数据库问题以及应用算法上，对于有针对性的进行调优，有利于系统性能的提升。

12.2 风险

当系统的瓶颈点不能被分析出来以后，系统上线就存在风险，这种风险有可能导致业务高峰的时候，系统性能体验差，甚至“崩溃”。

12.3 规范

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

操作系统资源消耗：CPU、Memory、Disk I/O、Network I/O

中间件指标：线程池(Thread Pool)、数据库连接池(JDBC)、JVM(GC/FULL GC/堆大小)

数据库指标：效率低下SQL、锁等待/死锁、缓存命中率、会话、进程等

应用：方法耗时、算法、同步和异步、缓存、缓冲

压力机：压力机资源消耗，一般情况下，压力机成为瓶颈的可能性非常低。

13 调优

13.1 分析

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

13.2 风险

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

13.3 规范

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

中间件调优：线程池、数据库连接池、JVM。

数据库调优：效率低下SQL、死锁和锁等待、缓存命中率，进程和会话参数。

应用调优：方法耗时、算法、同步和异步、缓存、缓冲。

系统资源：一般情况下，系统资源(CPU\大部分是由应用和参数设置不合理导致的，并非系统资源真的不够”用”。

14 性能测试分布式压测工具

14.1 简介

性能测试（Performance Testing）是集测试机管理、测试脚本管理、测试场景管理、测试任务管理、测试结果管理为一体的性能云测试平台，可以帮助您全方位的评估云上系统性能。

14.2 功能

测试机管理：被测系统机器管理，将当前阿里云ID名下的机器添加到环境当中。

测试脚本管理：模拟现实环境中业务操作，设置事务、自定义Cookie、Header、Body以及参数化。

测试场景管理：设置并发用户数、加减压方式、步调时间。

测试任务管理：设置测试场景、运行时间以及需要监控的机器。

测试结果管理：查看运行的结果。

14.3 优势

14.3.1 易用

性能测试分布式压测工具易学、易用、易操作，无论初学者还是有一定经验的客户都能很快利用此工具进行性能测试。

14.3.2 无维护成本

性能测试分布式压测工具部署在云上的平台，客户无需进行压测环境的维护。

14.3.3 分布式

性能测试分布式压测压力无上限,无论中小企业客户还是大型企业客户，都能满足要求。

14.3.4 历史数据对比分析

性能测试可以将测试过的场景相关指标进行对比，有利于调优前后的性能分析。