负载测试实例（负载测试实例分析）

本文目录一览：

• 1、性能测试包含了哪些测试

• 2、压力测试的测试案例

• 3、变频器假负载试验

• 4、软件压力测试的目的

• 5、要用loadrunner做一个B/S结构软件的登录功能的测试，负载测试和压力测试的场景分别怎么设计？请详述！

• 6、测试开发技术(二)——压力测试

性能测试包含了哪些测试

性能测试类型包括负载测试，强度测试，容量测试。

负载测试- 核实在保持配置不变的情况下，测试对象在不同操作条件（如不同用户数、事务数等）下性能行为的可接受性。

强度测试- 核实测试对象性能行为在异常或极端条件（如资源减少或用户数过多）之下的可接受性。

容量测试- 核实测试用户同时使用软件程序的最大数量。

扩展资料：

性能评价通常是和用户代表一起协作并且以多级方法执行的。

性能分析的第一级涉及单一主角/用例实例的结果评价和多个测试执行的结果比较。例如，在测试对象上没有其他活动的情况下，记录单一主角执行单一用例的性能行为，并将结果与相同主角/用例的其他几个测试执行进行比较。

第一级分析有助于确定可以表明系统资源中存在争用的趋势，该趋势将影响从其他性能测试结果所得出的结论的有效性。

分析的第二级检查特定主角/用例执行的摘要统计信息和实际数据值，以及测试对象的性能行为。摘要统计信息包括响应时间的标准偏差和百分位分布，这些信息显示了系统响应的变动情况，正如每个主角所见到的一样。

分析的第三级有助于理解性能问题的起因和加权值。该详细分析采用低级数据并且使用统计方法，帮助测试员从数据中得出正确的结论。详细分析为决策提供客观和定量的标准，但是它耗时较长，并且要求对统计学有基本的理解。

参考资料来源：百度百科-性能测试

压力测试的测试案例

案例：HKMA于2006年对香港零售银行业面临宏观经济冲击时的信用风险暴露进行压力测试 。分析结果表明，银行贷款违约率与关键宏观经济因素（包括香港GDP、利率、房价以及内地 GDP）之间有明显的相关性。

测试的结果是以VaR计，在90%的置信水平上，银行能继续盈利，说明信用风险较小。在极端情况下，以VaR计，在99%的置信水平上，有些银行会面临损失，不过这种极端情况发生的概率非常低。这只是一个预警。

测试过程分成以下几个步骤：

步骤一：定义模型

步骤二：估计模型

步骤三：模型估计结果分析

步骤四：设计冲击场景

步骤五：构造频率分布

步骤六：计算均值和VaR

步骤七：测算银行盈利能力所受影响

把它的过程归纳成七个步骤，包括后面计算盈利能力的方面。首先是定义一下这个模型，在模型有自变量和应变量，它定义了4个应变量。应变量是它需要考察信用违约率，它违约率的定义是这样的，逾期3个月以上的贷款和贷款总额，不知道银行是不是用违约率这么一个数据。这个数据算出来也挺难的，平时公布的数据，还是不良贷款率公布得比较多，关于违约率的定义没有比较准确的，有的是定义上一期能够正常还款下一期不能正常还款的，所以看到违约率的定义也有几种。不良贷款毕竟前几年商业银行剥离的政策原因太大了，可能这个时间序列有一定的不可抵因素，就是歧义点太多。

看一下这个估计模型，这是94年4月到06年1月的零售银行的数据。前面是自变量，这是用历史数据估算出来的结果，包括了参数变量也体现出来了。最下面是观测值，还有测试的个数。

可以看得出来，它的符号还是一致的，因为前面是违约率用Log这个函数给它导了一下，所以经济环境越好的话，资产的质量会越高，这样的话，VaR的数值应该越低。可以看得出来，这跟经济增长和房地产的价格，跟利率是呈正相关的。

同时，这上面提了一下，其实自变量里面有很多的二级滞后项，这是剔除了一级滞后项以后得出的，原本很多其他的相关变量没有列进来了，所以这是最后模拟出来的结果。模拟出来这个方程以后，下一步是要设定的冲击场景。先要设计模型、估计模型，最后要把新的数据带到我们模型里面去。就是把先的自变量带到模型里面，让它变成新的应变量。那么，新的自变量怎么办呢？比如说我们的经济冲击发生以后，我们的影响是怎么样的。实际上，它和经济危机是差不多的，碰到了4个冲击点。一个是我刚才提到的4个自变量，它对于每个变量都有一个冲击，第一个是香港实际GDP的变化，还有一个是大陆实际GDP的变化，还有利率和房地产。它不是只对当期的自变量发生了变化，它实际上是延长了时间，把这个影响时间变成了2年。所以，在金融危机以后，这个应变量应该发生多大的变化。在97年的四季度利率是306个基点，后面两个季度下降了，第四个季度又上升了314个基点。可以看得出来，一开始是300多个基点，后面两个季度没有变化，第四个季度上升上来了，这跟当时的亚洲金融危机的冲击差不多。

然后，紧接着下来是要模拟了，因为把这个数据输入到模型里面去以后，可以模拟出来的数据以后，可以把新的概率分布算出来了。当然，这还有一个假设，就是在四季度以后不再有冲击了，对每一个基期场景和压力场景对未来违约率路径进行1万次的模拟。有了新的频率分布以后，可以构造我们信用损失百分比的频率分布。刚才模拟的是违约率的频率分布，我们的损失百分比的数据应该是违约率乘上违约损失率。要定义一下违约损失率这个数据，这个数据比较有争议，到底怎么定？如果没有合适的统计量，对于市场的有关信息来赋值，通常定为50%。按照BASELII要求LGD取45%，但这个数字并不十分合理。所以，定义为2%低点的公式。这样，可以用违约损失率乘以我们刚刚计算出的违约率的数，这样可以得出一个信用损失百分比频率分布的数据。冲击发生了以后，实际上我们把频率往右移了，可以看出信用损失百分比的数据，出现高的数据频率增加了，原来是把这个频率往外偏移，所以可以看出较高信用损失百分比出现的频率增加了，较小的信用损失百分比出现的频率减少了。

通过算分布可以算出信用损失百分比的均值，还可以算出遭受损失的概率是多大，可以做这么一个精细的判断。这是计算以后的结果，它的均值是这样的，首先是基期没有发生信贷信用损失百分比，均值是0.34，压力期GDP冲击是1.59，房价冲击是1.21，利率冲击是0.71，大陆经济冲击是0.73。在VaR90%信用损失百分比是这个数据，随着置信区间的增加，损失的百分比也是递增的。最后一个是99.99%，这个时候已经是相当高了，后面两个已经接近10%，前面的已经超过10%了。

在90%的置信水平的情况下，可以看出3%以下还是过得去的。在99%的情况下，数值已经比较高了，这是在3.22，这是最低的值，最高的到了5.56，应该是比较高了。这跟金融危机发生1年以后的情况是比较吻合的，所以做压力测试要考虑一下当期和影响的延长期还是比较符合实际的。这里面的测算是在亚洲金融危机以前，银行用这个测算可以算出银行贷款损失率为1.4%，贷款损失率上升到6.0%，但是这个估计是基于估计LGD为70%。那么，这就给提出一个问题，这是不是合理，这可能是在测试的时候需要考虑的。

最后一步是测算冲击对银行盈利能力的影响。也许银行管理层觉得，这个VaR值或者是概率是多少，可能在90%的置信期间里面有多大的，在99%到底有多大，这对于盈利能力有多少？盈利下降了多少？是不是可以给这么一个数据，那么也可以通过一个测算算得出来。如果认可前面的测算，就是贷款损失百分比，通过这个可以算出来，损失肯定是等于贷款损失百分比乘贷款余额。就是冲击发生以后，银行的盈利能力发生的变化。首先，没有发生违约的情况下，那么它未来冲击发生以后它的盈利应该比当前或者是基期是一样的。如果我盈利是30亿，那么冲击以后属于没有发生违约，那么这个盈利是一样的。如果发生了冲击以后，如果我下降了，下降了多少就是损失。

假设有一家银行，这家银行拨备前利润是30亿，贷款余额是1300亿港币。假设有一家银行规模是这么大，可以用上面的贷款损失百分比来测算，这家银行在发生了冲击以后，在不同的置信区间里面它的盈利能力会受到多大的影响，这是得出的结果。

单位用百万来表示，正的数据是表示盈利，负的就表示已经损失了，管理层看到这张表可能就比较清楚了银行可能发生多大的损失。

比如说在90%的区间里面，香港的GDP冲击情况下这家银行要亏损8.82万亿港币。那么，这个是99.99%，就是这个事情发生的概率非常强了，因为置信区间在99.99%，是0.001%的可能性，这个损失已经是到了133亿了。在不同的置信区间里面，它的损失是不一样的。回想一下，如果没有模拟，就是一个假设，假设GDP是多少，刚才已经提出来了，从前面可以看到，GDP的数据是多少，在每一个季度是多少，如果没有模拟，直接把这个数据带回到模型里面，只算出一个贷款百分比的数据。有了模拟以后，就知道它的均值是多少，在不同的置信区间里面是多少。这样，管理层可能会感觉清醒一点。比如说基期在没有违约的情况下，是2554百万，还是挺好的。如果做压力测试把这张表给管理层，就很清晰地知道损失有多大了。

最后有一个表述，在90%的置信水平下，VaR值是882万，如果在99%的水平下，VaR值是比较大的，导致这样的VaR的极端场景发生的概率是1%。

变频器假负载试验

变频器假负载试验？英威腾 GD200A-132G/160P 变频器，在办公室接单相电(变压器升压到额定电压)，屏蔽缺相报警后，用三相灯泡 (3*2*220V/40W) 做假负载开机，运行正常无报警，但是低转速时一相灯泡比另两相亮好多，有没有问题？是不是因为负载太小引起？

以下通过一个使用实例来说明变频器假负载的用法：

变频器假负载如何连接：假负载连接在直流储能电容与三相IGBT之间，在电路中一般为连接铜排或快熔，有快熔的直接连接即可，无快熔拆去一段连接铜排即可，实际上就是将三相逆变IGBT正电源与直流储能电容之间断开。必须在电容后面，如在充电接触器之间，直流电容储能的电量，在逆变电路出现问题时足以将IGBT炸掉。 在断开点加入两只25w 220V供电的灯泡，采用两只的目的为直流回路电压为540V左右，单只灯泡的。

变频器假负载如何连接：假负载连接在直流储能电容与三相IGBT之间，在电路中一般为连接铜排或快熔，有快熔的直接连接即可，无快熔拆去一段连接铜排即可，实际上就是将三相逆变IGBT正电源与直流储能电容之间断开。必须在电容后面，如在充电接触器之间，直流电容储能的电量，在逆变电路出现问题时足以将IGBT炸掉。

在断开点加入两只25w 220V供电的灯泡，采用两只的目的为直流回路电压为540V左右，单只灯泡的耐压不够。当逆变电路出现问题的时候，灯泡有限流的作用，保护逆变模块。

上电过程：

空载： 输出不接负载，如上电后出现以下几种情况

A：变频器不运行，一上电灯泡就亮，说明三只逆变模块中至少有一只上下桥IGBT 漏电，这种问题，有些时候低电压的时候不会表征出来，但接上直流540V高压时，出现了较大的漏电流，说明模块内部绝缘有问题。出现此种问题可以单只IGBT拆除，如拆掉U相灯泡不亮了，那就说明U相坏了。

B:上电后无问题，但是一运行就亮，灯泡的亮度随频率的变化而变化。说明三相模块中出线了一相上桥或下桥损坏的情况。举例说明，假设U相上桥V1收到触发激励信号而饱和导通，已经损坏的U相下桥V2与已经饱和导通的V1就形成了电源的短路，故而发光。

C：上电后与运行都不亮，此时可以使用指针表的交流档测量三相输出电压，是否随频率增长均匀增长而且三相平衡。此时说明模块基本问题不大，可以带上负荷实验了。

D：上电与运行灯泡都不亮，测量三相输出的电压不平衡，那就说明某相IGBT内部开路，造成导通内阻增大，接近开路状态。

出现此种问题如何测量：

1、使用指针万用表的直流档测量三相输出与地或进线零线间的电压，正常情况下直流成分几乎为零，如果出现直流电压说明其中某相上下桥的一个桥导通不良，导致输出的正负半波不对称。

2、测量三项输出与直流母线电压的正负端，正常情况下均分直流母线电压，如果出现某相测量的时候大于母线电压的二分之一或直接接近母线电压说明此相IGBT半桥导通不良。

希望以上的实验能帮助到，如果你还有其他问题可以继续提问，很乐意解答~~

软件压力测试的目的

在最近的一次测试中定义了测试的目的是：需要了解AUT(被测应用程序)一般能够承受的压力，同时能够承受的用户访问量(容量)，最多支持有多少用户同时访问某个功能。在AUT中选择了用户最常用的五个功能作为本次测试的内容，包括登录。大概的需求就是这样。

接下来AUT的登录说一说怎么用LoadRunner和Jmeter来实现场景的设置达到测试的目的。(注：对服务器的检测不是本次测试的重点，本次测试主要收集并发访问用户数和发生错误用户数)。 首先是对脚本的要求：

1、录制脚本(注意所有的脚本都应录制到Action中)，自定义事务，事务从提交用户名和口令的脚本之前开始;

2、在定义事务开始的脚本前加入集合点;

3、在脚本中加入检查点，以登录成功的页面出现登录用户的ID即可;

4、参数化登录用户的身份;

其次是对场景设置的要求：

1、因为事先我们不知道将有多少用户访问是临界点，所以在测试过程中需要多次改变用户数来确定;

2、建议修改运行时设置，优化对服务器的访问; [Page]

3、计划的设置，每x时间后加载10用户(根据总用户数设置)，完全加载后持续运行不超过5分钟(根据需要设置);

4、集合策略，当运行中的用户数100%达到集合点时释放;

5、注意事项，需要注意几个时间：1)服务器响应超时时间;2)登录事务迭代一次所使用的时间;3)集合点等待超时时间;4)计划中设置的间隔时间。在我的测试中事务运行一次的时间不超过30秒，通过修改脚本使它的运行时间达到一分钟左右， 服务器响应超时时间、结合点等待超时时间、计划中设置的间隔时间都设置为了2分钟。

这样场景开始运行后运行用户数呈阶梯增长，另外在每个上升点新增的用户都会随原来已经运行的用户并发访问服务器。

通过多次的运行和对测试结果中正在运行用户数与错误用户的对比，然后根据定义可接受错误率就可得到该功能的最大并发访问的用户数。

以上测试中排除了对网络、客户端等的要求。在实际测试中首先要保证这些资源是足够的。

使用Jmeter也能够达到上述描述的场景的测试，并且更加的便捷。 利用现代的设计技术和正式的技术复审可以减少代码中存在的初始错误，但是错误总是存在的，如果开发者找不到错误，那么，客户就会找到它们。越来越多的软件组织认识到软件测试是软件质量保证的重要元素之一，很多软件开发组织将30%—40%甚至更多的项目资源用在测试上，软件测试技术和软件测试策略受到了高度的重视和广泛的应用。

本文不想就软件测试技术和软件测试策略作深入的理论分析，而是列举一个在软件系统测试阶段进行的软件压力测试实例，希望能通过这个实例与从事软件测试相关工作的朋友进行交流。

首先介绍一下实例中软件的项目背景，该软件是一个典型的三层C/S架构的MIS系统(客户端/应用服务器/数据库管)，中间层是业务逻辑层，应用服务器处理所有的业务逻辑，但应用服务器本身不提供负载均衡的能力，而是利用开发工具提供的ORB(对象请求代理)软件保证多个应用服务器间的负载均衡。本次测试的目的是：进行单个应用服务器的软件压力测试，找出单个应用服务器能够支持的最大客户端数。测试压力估算的依据是：假定在实际环中，用户只启用一个应用服务器进行所有的业务处理。方法是：按照正常业务压力估算值的1~10倍进行测试，考察应用服务器的运行情况。

要用loadrunner做一个B/S结构软件的登录功能的测试，负载测试和压力测试的场景分别怎么设计？请详述！

其它如响应时间，吞吐率没测过不知道值，一般情况下会是多少呢？

响应时间得看客户那边的要求，一般是3秒。吞吐率看项目的具体情况。

Q1：负载测试怎么设计场景？如何监控应用服务器和数据库服务器？要装监控进程吗?

负载测试怎么设计场景：你的思路是对的，但是不够具体，太泛泛了。我给你举个例子

：先利用你可以获得的数据信息分析，并发数是300，然后分析这个网站登录（如果客户

那边可以提供最好了）的峰值时间，比如说是 11:30-12:00的30分钟，设置60秒110虚拟

用户，根据你已知的并发数300，算出总用户数，300X30/3=3000，如果可以从客户的数

据里能分析出来用户数就是最好了，结束的设置看自己情况，影响不大，关注下是否有内存泄露就可以。.所以得：

用户总数：3000，增加速度：60秒110虚拟用户，运行时：30分钟，并发数：300.

运行完毕后，对结果进行分析，关注事务平均响应时间、事务请求数。

如何监控应用服务器和数据库服务器:LR里有对服务器和数据库监控的设置，添加就可以

了，如何操作可以参考LR使用手册，网上也有很多资料，不过你的oracle是在Uuix上，

LR不能监控，可以自己下载专门监控unix的工具，可以网络上搜。

要装监控进程吗：这个看你的具体情况，如果有异常需要这方面的分析的话，可以装起

来呢。

Q2：压力测试怎么设计场景？如何监控应用服务器和数据库服务器？要装监控进程吗？

压力测试怎么设计场景：测试环境一定要确定，压力测试一般要求环境配置较高，最好

与生产环境一致或者接近。

我一般是每个并发数跑一个场景，在登录那设置集合点，然后所有用户达到集合点释放.

每个场景跑3次。比如说针对你的：

场景1: 200个Vuser start all Vusers simultaneously(所有用户同时上) 所有用户达

到集合点释放，

场景2: 300个Vuser start all Vusers simultaneously(所有用户同时上) 所有用户达

到集合点释放

场景3: 400个Vuser start all Vusers simultaneously(所有用户同时上) 所有用户达

到集合点释放

场景4: 600个Vuser start all Vusers simultaneously(所有用户同时上) 所有用户达

到集合点释放

场景5: 800个Vuser start all Vusers simultaneously(所有用户同时上) 所有用户达

到集合点释放

如何监控应用服务器和数据库服务器:LR里有对服务器和数据库监控的设置，添加就可以

了，如何操作可以参考LR使用手册，网上也有很多资料，不过你的oracle是在Uuix上，

LR不能监控，可以自己下载专门监控unix的工具，可以网络上搜。

要装监控进程吗：这个看你的具体情况，如果有异常需要这方面的分析的话，可以装起

来呢。

Q3：如果用户名和密码框下还有验证码框，即带验证码的登录又怎么做性能测试？

验证码问题一般有2种方便的解决方式：

1）屏蔽；让开发把这验证码功能屏蔽了。

2）万能验证码；让开发给你设计个万能验证码，比如是aaaa，都是可以通过验证的

你自己根据你那边的具体情况选择解决。

Q4：如果我要一部分人同时登录，一部分人做查询，剩下的人翻页，又怎么设计？这种测试其目的是什么？

我的想法是录三个脚本，放到一个场景中，用百分比模式分配Vuser和load generator，这样可以吗？你的想法是对的。可以这么执行！

测试开发技术(二)——压力测试

        上一篇文章里说过，目前互联网公司的测试开发岗位分两类。多数的一类是既要负责业务测试、自动化测试，同时也要去开发测试框架、效率工具来辅助业务测试。这类测试开发的岗位（主要指后端的岗位）一般多少都要接触压力测试。

        压力测试、性能测试、负载测试、稳定性测试在网络上有很多文章介绍概念和区别，通常在项目过程中不会区分那么多，实际项目中都是以目标为导向，通常实际项目中都会说，压测一下看下性能，所以这里就不管详细的概念和区别了。为了好理解，我们这里统一叫压测，并以得到性能数据为性能测试，以观察稳定性为稳定性测试。

        性能测试和稳定性测试的相同之处在于都是使用压测工具来进行。但目标不同，性能测试是通过压力测试得到系统的极限性能或者和上一版本的性能对比数据。而稳定性测试则是通过压力测试提供稳定或者变化的持续流量，来观察系统持续运行的情况下是否存在异常。

        正常情况下，一般系统先做性能测试，拿到极限性能或者性能对比数据（对于非1.0项目，性能数据一般需要和上一个版本对比）之后，再通过安全的流量持续压测更长时间，来完成稳定性的验证。

        下面我们就具体介绍一下怎么做性能测试和稳定性测试。

        性能测试的第一步要确定目标，就是为什么要做性能测试，要达到什么样的目标或者效果。比如某个首次上线的系统，性能测试主要是为了得到系统的极限性能数据；再比如，系统优化，更换了RPC协议或者消息队列，性能测试就是为了量化此次系统优化在性能上优化的效果。另外，也不是所有的项目都需要性能测试，比如一个内部系统，用户数和流量本身就很少，而且在未来一段时间也不会有增量，这就基本不需要性能测试。

        如果是从无到有的1.0项目，因为项目还没有上线，所以只能评经验来预估线上的流量数据；但如果是非1.0项目，就可以收集当前的线上数据。具体收集的数据如下（仅供参考，要按照实际情况来调整）：1）被测系统或模块各类请求流量比例；2）系统或模块目前平均、峰值、最小 qps；3）线上部署方式和规模；4）被测系统或模块依赖能承受的QPS或者容量。

        确定目标和收集完线上现有数据之后，需要根据目标和现有数据确定压测方案，比如，每个阶段通过多大并发或者流量来压测、分几个阶段、每个阶段多长时间、以及压测过程中需要观察和记录哪些数据等。

        同时，也要准备压测环境，压测的环境要尽可能的和线上一致，如果达不到，就做等比缩放。比如，一个系统有A、B两个模块组成，线上A部署了20台机器，B部署了5台机器，那么压测就可以A部署4台，B部署1台。机器和实例的数量只是一个方面，同时也要考虑机器的性能（CPU盒数、内存、磁盘、网卡等），还要考虑依赖方（如DB、缓存、消息队列等）的部署。部署压测环境的核心思路就是要用这套环境反应出线上环境的真实情况。

        要进行压力测试就一定要有压测工具，一般来说压测http或者其他开源协议可以在网上找到现成的工具，比如jmater之类的。但如果场景比较特殊，或者使用的是公司或项目的私有协议，就只能使用公司内部的工具或者自己动手开发了。

        选择好压测工具就要构造压测数据了。构造压测数据主要分两点：

        第一点是要构造压测环境系统中的数据。因为线上系统内部一定是有一定数据的，我们要尽量模拟线上就要在系统中添加相应的数据。

        另一点就是要准备压测的请求数据。这点跟选择的压测工具有关，一般来说分2种：

        1）数据词典， 压测的请求提前准备好，存入文件、DB或缓存里，数据量较大的时候一般需要写程序生成。

        2）实时生成，这种是压测工具在压测的时候根据配置规则来实时随机生成请求。

        准备工作一切就绪，下一步就开始做压测的执行。这时候主要就是根据压测方案的从低到高去调整压测工具的并发数或请求数，来对目标系统或模块进行压测。

        压测时，要观察CPU、内存、网络IO、磁盘空间、被压目标日志、依赖系统或者模块的状态等数，也要记录不同并发下目标系统或者模块处理请求的QPS和响应时间。同时也要注意有没有内存泄漏、句柄泄漏、系统崩溃等问题。

        实际上部分数据在记录的过程中就可以初步整理出来。这里要针对上一步记录的数据，进行汇总，主要要产出在不同并发下，上面提到的数据都是什么情况。需要根据数据判断出极限性能，找到这种部署情况下瓶颈在哪，以及是什么原因造成的，为后续扩容提供依据。有些情况还需要跟以前的数据做对比，看性能提升或者下降的程度是不是符合预期。最后，把这些信息综合汇总、分析之后，产出性能测试的报告。

        通常性能测试之后拿到了性能数据之后，都会在安全的并发或者流量下持续压测更长的时间来确保服务的稳定性。比如，笔者通常测试性能的时候，每轮可能压测半小时到一小时（在刚开始并发或者流量较小的时候可能会更短），在得到期限性能之后，会控制极限性能时80%-%90的流量或者并发去压测更长的时间，这个时间一般会比较长，而且多数情况下会在晚上下班前启动，然后第二天到公司来看结果。

        除了长时间通过安全流量来验证外，有些时候在特殊场景下，也需要验证在安全流量范围内，流量急曾或者急降的情况下，稳定性是否有影响。或者，验证在一定流量下，模拟某个依赖或者系统内部的模块出现问题，执行相应预案时，对系统整体的影响是否符合预期。

        当然，稳定性很多情况是异常，但更多的异常会在异常测试里去做，这里的稳定性测试是指在一定流量压力下的稳定性测试，其他的就不做讨论了。

        上面介绍了压力测试里，性能测试和稳定性测试要做什么，那具体怎么做呢？下面我们就通过一个实例来简单介绍一下。

      一个消息推送的系统，推送的消息就是我们日常手机APP的通知消息。这个消息通知的系统有三个接口，分别是单播（指定推送给某个人）、组播（推送给一个组，组里可能有多个人）、广播（推送给APP所有用户）。现在这个系统做了一个重构，更新了内部交互的RPC协议，所以要压一下，跟之前的性能数据做个对比。另外，系统重构前，线上集群极限性能为30000 QPS。

        下面，我们就按照前面的步骤，来简单介绍一下具体怎么做。

      目标就是要得到重构后的系统性能数据，并和原有的做对比，原有的极限性能已知，大概在30000 QPS左右。

        收集线上数据，比如说我们收集到单播、组播、广播的请求比例为5：78：1；组内人数大概在300-1000；发送的消息字符数在30-100这个区间。

        压测方案要先确定部署方案，比如这个系统向上是20台机器（或者实例），压测采用2台机器（等比缩放）。压测机器是线上的1/10，所以我们的目标性能就是3000qps。那么我们压测的方案就可以如下设置：

        第一轮，2个并发，5-10分钟，主要目的是为了先验证环境和压测工具没有问题；

        第二轮，根据上一轮并发数和机器资源（CPU、内存、IO）的情况，调整并发到极限的一半多一些（比如，之前是2个并发，CPU占用10%左右，内存、IO占用都很小，那么就以CPU的占用作为参考来计算，1个并发大概占用5%，那我们就可以吧并发调到10-12，目标CPU占用是50-60%）。这其实才真正开始压测，如果没问题，就开始逐步加压；

        第三轮，开始逐步增加，按照实际情况一次增加2-5个并发，直到性能达到瓶颈。

        这里是假设压测工具通过调整并发数来操作压力，主要需要看下并发对系统CPU、内存、IO的影响，根据压测时机器的资源占用信息来判断增加多少并发。

        确定好方案，就需要部署压测环境了，这里要注意，尽量使用跟线上一致配置的机器。

        压测工具要根据实际业务做选择，必要的时候需要自己开发，工具开发后面如果有机会在其他的文章里介绍，这里就不多介绍了。我们这个例子因为是系统更换内部协议，对外接口不变，所以可以使用原有压测工具。

        下面就是要构造数据：

        首先，要构造系统内部的数据，比如用户信息、设备信息、组信息，这里既要根据线上的收集到的信息来构造，比如用户数、组的数量、组内用户数等。这类如果方便的话可以直接在DB里插入，或者掉相应的系统API来准备。

        然后就是压测的请求数据，比如说压测工具是用数据词典来压测，那么这里我们就通过脚本，来生成压测请求数据。这里要注意线上收集到的各个接口的占比，即5：78：1。压测的时候按照这个比例来提供流量。

        准备工作完成，开始做压测。

        这时候要先吧各类数据观察准备好，一般现在的互联网大厂都有图形化的工具来看，如果没有也可以通过linux的一些命令来看。常用的命令有top\ps\vmstat， 这里推荐使用top来查看实时的资源情况，使用vmstat的来定时输出当资源情况（vmstat -t 1 就是每秒输出一次）。

        准备好了观测，那就启动压测工具，按照方案压测。压测方案上面已经介绍，这里就不重复了。

        假如我们并发加到20个的时候，CPU占用达到85%左右，处理请求达到3600qps，其他资源占用都不足机器的一半；并发加到22个的时候，CPU占用达到95-100，处理请求是3700qps；并发加到24，CPU打满，处理请求3800QPS，并且出现错误日志。这时候就可以停止压测了。

      数据整理，我们首先要整理一个表格或者图标，我们这里用表格：

       这个表格就是压测产出的最核心的数据，由于CPU是明显的性能瓶颈，表格里就不体现其他资源了，如果其他资源使用率也比较高，也要放到这个表格里，又或者瓶颈在外部依赖，也要体现出来。通过这个数据可以看出，3700QPS就是系统处理的极限，安全的流量在3600QPS。这时候就可以用17-20的并发数，长时间压测压测一下，看看系统整体的稳定性。

      那么性能报告怎么写呢？下面就给出一个比较简单的性能报告样例。

        标题：消息推送RPC协议升级性能测试报告

        一、项目背景

                这里写项目背景和目标

        二、压测环境

                线上20台物理机，压测环境使用2台物理机，配置与线上一致，具体如下：

                XX核，XXG内存，万兆网卡，硬盘 400G * 6 SSD

                DB：XX主XX从XX备

        三、压测方案和数据

1. 请求比例

      单播：组播：广播 =  5：78：1

2. 压测过程数据

      3.  资源占用图

    可以把QPS和CPU占用使用工具（比如excel）生成一个折线图，另外，可以把其他资源数占用的数据图片贴一下。

        四、结论

        压测过程中，压力达到3700qp时，内存与IO正常，CPU占用达到98%，无错误日志。压力达到3800qps时CPU打满，且5分钟后开始出现错误日志。因此系统在2台物理机部署极限性能为3700qps，性能瓶颈在CPU，预计线上20台机器极限性能为37000qps.

        系统RPC协议升级前20台机器30000qps，升级后预计能达到37000qps，性能整体提升23%，符合预期。

        上面就是一个比较简单的报告，真实项目中瓶颈不一定是CPU，可能是其他资源，也可能是依赖的系统或者模块，这些都需要观察和分析压测中的数据来得出。

        压力测试是后端测试和测试开发人员的必备技能，这篇文章只是根据笔者的经验针对压力测试进行的总结，不能覆盖所有压测场景，仅给大家做个参考。更多的是需要我们根据系统的实际情况去探索和实践。