性能测试如何入门？熬夜7天整理出这一份3000字超全学习指南

赶鸭子上架要我搞性能测试，怎么办？

我第一次真正意义上搞性能测试是在2014年。项目组要求搞性能测试，我之前也没搞过，对服务端也不熟悉。就那么一脸懵逼地开始搞性能。当时我连linux上有哪些能看系统资源的命令都不知道。稀里糊涂地进行了好几轮地性能测试之后，我最大的感受是：对于非专家的测试人员来说，搞性能测试是一个团队活动，而非个人活动。整个过程中，我更多地是借助团队地力量来搞。系统监控不会，找运维帮忙，软件架构不懂，找架构师帮忙，服务器参数不会调，开发替我调。而在这次做完这一波性能测试之后，我下决心要搞懂性能测试到底是怎么搞的。毕竟，刚毕业的时候就听说了，自动化测试和性能测试这俩方向好，但我从来没听谁把“性能测试到底是怎么回事”讲清楚过。我自己在后面的工作中琢磨了很多年，直到最近这两年才琢磨得差不多了，很想跟大家分享一下。

想搞性能测试，要学什么东西？

2006年我还在读书的时候，学校里的软件质量课程里，老师跟我们讲“用win runner做性能测试”。2008年我毕业进第一家公司的时候，公司里的培训老师跟我讲，“用load runner做性能测试“。2011年，我在另一家公司做接口测试的时候，我们用soapUI做功能测试，soapUI的公司的网站上跟我讲，“用loadUI做性能测试”。2012年，我在自学的时候又网上看到了“用jmeter做性能测试”。而后来，gatling，grinder，locust，tsung，工具多得数不胜数。那么，我早就想问了，性能测试就是使用这些测试工具吗？

搞性能测试，并不只是搞搞工具

性能测试最需要的东西，不在于工具，而在于对整个待测系统的理解。首先要理解整个待测系统它的软件架构，硬件架构，网络架构，理解它是如何运行的。它由哪些部分组成，各个部分之间是怎样交互的。用户怎样使用这个系统。在理解系统的基础上，我们可以得出系统的各个部分的性能要求是怎样。也就是性能需求。

而测试的过程也就是验证和探索这些性能需求。

为各种性能需求设计测试场景，再编写测试脚本，执行测试脚本，汇总测试结果，再分析测试结果，进行调优，再重复测试与调优，最后产出测试报告。指明系统是否符合性能需求，哪里还达不到要求。

这其中，跟性能测试工具有关的，只有“编写测试脚本，执行测试脚本”。其他的所有步骤需要的是：计算机科学与技术的各方面综合知识、对业务的理解、对待测系统技术实现的理解。至于性能测试的工具，我们可以选用开源工具，也可以选择自己开发工具。当我们全盘理解性能测试之后，就可以针对具体的需求开发性能测试工具来解决各种实际问题。注意自己开发的性能测试工具与开源工具的区别：自己开发的工具可以很有针对性，而开源工具需要考虑兼容性与普适性。两者的开发重点完全不同。开源工具以推广这个工具为目标，而自己写的工具以最快/最经济解决实际问题为目标。

搞性能测试，如何入门

说了这么多，性能测试到底要如何入门呢。

一方面，工具仍旧是要的，建议使用jmeter等开源工具作为入门学习的工具。照着用户手册操作一遍，花个几天时间就能上手。

更重要的另一方面，我们需要理解性能测试的原理，做性能测试的基本步骤，场景设计的基本策略。不知道这些，光拿个工具，有什么用呢。现实业务千变万化，往往需要测的东西，并不是那么简单拿个工具随便搞搞就能搞好的东西。

一、什么是性能测试
二、性能测试的目的
三、如何做性能测试
四、性能测试关注的指标
五、性能结果分析

六、性能测试资源分享

一、什么是性能测试

是不断的通过不同场景的系统表现去探究系统设计与资源消耗之间的平衡。

我们可以认为性能测试是：通过在测试环境下对系统或构件的性能进行探测，用以验证在生产环境下系统性能是否达到预估的性能需求，发现系统可能存在的性能瓶颈，进而改善优化并系统的性能，提高系统的可扩展性、稳定性。

从上面的描述可以看出，性能测试的主要工作包括：获得预估的性能需求、搭建测试环境、执行测试、分析测试结果。其中，最为重要两个工作是确定测试的目的、方案，并对结果进行分析。

二、性能测试的目的

(1)验证系统是否满足预期需求;

(2)验证系统在高压下的表现;

(3)验证系统是否能持续稳定的运行;

(4)探测系统的瓶颈和产生瓶颈的原因;

(5)探测系统设计与资源之间的最佳平衡，改善并优化系统的性能。

三、如何做性能测试

1. 负载测试： 找到系统稳定时（或满足性能需求下）的最大吞吐量；（要有响应时间、成功率的限制，比如定义：99.9%的响应时间必需在1ms之内，平均响应时间在1ms以内，100%的请求成功）

2. 稳定性（通过浸泡测试soak test）： 以系统稳定时的最大吞吐量（或满足性能需求时的最大吞吐量），长时间对系统进行测试，已检查系统是否稳定

3. 压力测试： 找到系统极限值，系统瓶颈（系统崩溃临界值）（要求：响应时间可以变慢，但系统不能崩溃；）（根据测试目的，选择是进行负载、压力、稳定性还是几种测试；）

4. 并发有两个概念：

多个用户同时进行相同操作，访问同一接口——单个业务接口并发；

多个用户同时访问系统，但进行不同的操作，访问不同的接口——系统级并发；（在性能测试过程中，根据 具体场景和业务 选择合适的方案，一般第2种更符合实际场景。以上2种都需要进行测试；）

5. 测试流程： 确定测试目的与需求——根据需求与场景，梳理测试要点——根据测试目的，制定测试方案——准备测试环境与数据——测试执行（脚本或工具）——统计测试结果——分析结果——测试报告

PS：

1 .测试执行时，执行多次，取平均结果更为准确。

2. 单机并发不够时，采用多机分布式并发；

3. 测试过程，一定要尽可能模拟实际应用场景；

四、性能测试关注的指标

测试人员关注（单次业务相关指标）：

并发用户数

响应时间：TP（百分比分布统计）

吞吐量：tps/qps

成功率

失败率

开发人员关注（系统层面指标）：

1. Tomcat、数据库等；

2. 容量：系统能承载的最大访问量是多少？系统最大的业务处理量是多少？

3. 稳定性：是否支持7*24小时（一周）的业务访问？

运维人员关注（硬件资源相关指标 ）：

硬件资源消耗情况：CPU、内存、I/O读写速度、网络带宽等

五、性能结果分析

以下相关指标分析时需注意：

1.响应时间不要光看平均值，平均值不靠谱。要求最好定成：99.9%请求必须<1s，所有的平均响应时间必须<1s，这两个条件限制；

2.响应时间要和吞吐量TPS/QPS挂钩；

系统的性能如果只看吞吐量，不看响应时间是没有意义的。我的系统可以顶10万请求，但是响应时间已经到了5秒钟，这样的系统已经不可用了，这样的吞吐量也是没有意义的。

我们知道，当并发量（吞吐量）上涨的时候，系统会变得越来越不稳定，响应时间的波动也会越来越大，响应时间也会变得越来越慢，而吞吐率也越来越上不去（如上图所示），包括CPU的使用率情况也会如此。所以，当系统变得不稳定的时候，吞吐量已经没有意义了。吞吐量有意义的时候仅当系统稳定的时候。

所以，吞吐量的值必须有响应时间来卡。比如：TP99小于100ms的时候，系统可以承载的最大并发数是1000qps。这意味着，我们要不断的在不同的并发数上测试，以找到软件的最稳定时的最大吞吐量。

3. 响应时间吞吐量要和成功率挂钩 ；

不难理解，如果请求可以并发10w，但是成功率只有40%，那也没什么用。

性能测试的失败率的容忍应该是非常低的。对于一些关键系统，成功请求数必须在100%，一点都不能含糊。

4. CPU、内存等硬件资源占比持续超过90%，说明性能存在瓶颈；

5. 带宽波动起伏很大，说明带宽受限；

六、性能测试资源分享

下面是配套资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！【保证100%免费】

凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助……