一、性能测试概述

1、关于性能测试目标：

①TPS

②一定并发用户数下功能点的响应时间

③一定响应时间内功能点的并发用户数

性能测试不是达到既定目标即可，还要测试软件功能能够达到的极限值。

2、关于性能测试的场景：

在脚本录制调试完成后，需要进行场景的设置，进而对脚本进行压测，分析压测的结果。

性能测试场景：

　　单场景 → 单独某个功能、接口，测试目标是多少(一般10--15分钟)

　　混合场景 → 发现线程死锁和数据库死锁(一般10--15分钟)

　　稳定性场景 → 系统是否稳定运行，发现系统是否有内存泄漏(过程)、内存溢出(结果，系统崩溃)(一般N*12小时)

在进行场景的压测时，相当重要的一点是要保证数据库表中有足够的数据量。

3、loadrunner负载机

用其它机子做负载机为"分布式负载"，这时候在用作负载的机子上，只需要安装loadrunner Agent这个模块就可以了，在进行分布式负载时，可能出现连接不上负载机的情况，检查网络及防火墙的状况。

二、Controller的场景概述

三、手工性能测试场景

1、为什么要使用分布式负载：

在进行并发的时候，一台PC机能够发送的并发数，可能达不到测试的要求，那么就需要用多台机子进行并发，每台机子分担一定的并发数。

Controller应与Load Generator分开。若测试需要的vu数，超过单负载机所能产生的vu数，则负载机本身将成为性能瓶颈，这是不合理的。

例如，负载机内存512M，一个vu占2.5M，则单台负载机只能产生200vu，若需测试500vu，一台controller调用多台Generator，要考虑负载均衡问题，带宽问题。

2、Controller的场景设置：

①Controller中负载机的设置如下图：

 在进行脚本压测时候，可以如下图进行快速的操作：

上边我们已经描述了在Scenario Groups中，如何进行脚本的选择及负载机是如何进行设置的，接下来要对脚本的并发数及运行时间进行设置：

②脚本虚拟用户初始化：

一般在进行虚拟用户设置的时候，选择弹出框Edit Action中的第一个或者第三个选项

③虚拟用户并发数及加载方式的设置：

注意：在此次设置了多少个虚拟用户进行并发，并不表示在进行压测时，就有设置的并发用户数运行，实际的并发数，取决于服务器的处理能力及代码，TPS/RPS(每秒通过的事务/每秒通过的请求数)

• 思考：

压测时2000个用户并发，每秒加载2个用户，并发15分钟，问在15分钟里，用户数能够加载完吗

进行如下设置：

由上图可知，用户的加载时间，不包含用户的并发时间

同理用户的退出时间，也不包含在用户的并发时间内，所以说以上"压测时2000个用户并发，每秒加载2个用户，并发15分钟，问在15分钟里，用户数能够加载完吗"的描述是错误的。

 如下图设置：

loadrunner的运行方式有两种：进程方式、线程方式

默认情况下以线程方式运行

在脚本运行前，加载2000个并发用户，这时服务器会启动40个(2000/50=40)mmdrv进程(1个mmdrv进程默认有50（可修改）个线程。也就是说如果是50个进程并发的话，系统会启动一个mmdrv的进程(负载机进程)，如果多于50个线程，就对应启动x个mmdrv进程。如果是以进程方式运行的话，一个并发就是一个mmdrv进程。进程比较耗内存资源，线程比较耗CPU可以这么理解。)

产生的影响：

对负载机来说，开始压力会大一些

对服务器来说，服务器没有任何缓存时间，一下子来2000个并发，可能导致服务器崩溃

热负载：一点一点的加并发

冷负载：所有并发一次性向服务器发送

loadrunner支持压测的同时，增加并发用户数，如下图：

在压测时候对比上图①运行的虚拟用户数②请求的响应时间③tps 进行分析

④脚本的串联运行：

方式一、

方式二、lr和QC进行集成

方式三、定时任务

四、面向目标的性能测试场景

五、Analysis：

1、新增监控视图：

2、Analysis报告的简单分析：

上图中，如果标准方差在5以内取Average做作为平均相应时间，如果标准方差大于5取90 Percent作为响应时间。

3、Analysis中，进行视图的合并操作，如下图：

一般合并并发用户数和响应时间或者并发用户数和tps，可以看到不同并发用户数下的响应时间或者tps值的变化情况。

 并发用户数下的响应时间不包含失败事务或者请求的响应时间。

六、测试目标对应测试场景的设置实战

实战1、测试响应时间：测试网易体育20个并发的响应时间如何设置？(测试某个功能/接口的响应时间，前提条件是多少个并发)

直接加载需要的用户数去测试某个功能/接口，并发15分钟，得出平均时间即可

在手工场景下进行如下设置：

脚本运行完后，根据标准方差的大小，取平均响应时间或者百分之90的响应时间

实战2、测试最大tps 需要知道测试哪个接口或者功能(包含条件是1秒)

直接从1个用户开始测试，通过不断的加压(加用户)去测试最大tps，最大tps的标识是随着用户的不断增加，tps不再增加或者tps反而减小，那么那个不再增加的tps或者出现拐点的tps就是最大的tps

在手工测试场景下，进行如下设置：

扩展：

项目的某一功能的tps如何评估：

①tps是开发、项目经理或者产品经理制定的。分析线上日志，1s最大有多少个用户或请求通过

②只知道在线用户数，如何去衡量系统某个功能的tps是合理的

测试人员心里预估值来源：

最精确来源，线上日志分析(可用awk命令统计日志每分钟通过的请求数，进而得到tps)；

其次可以用28(百分之80的用户会在百分之20的时间段内同时做一件事情)原则，前提知道在线用户数，和用户的访问习惯，譬如有100个用户，在预定的某个10分钟内，要做某件事，那么 100个用户*80%=80个用户，10分钟*20%=2分钟  tps=80/(2*60)

实战3：测试最大并发用户数：测试某个功能/接口，响应时间在多少秒以内

用户直接从1开始测试，逐渐加大并发用户数，观察响应时间，直到响应时间达到需要的秒数，再继续观察响应时间是否稳定，如果稳定，那么这个并发数就是最大并发，如果不稳定，那么就需要增加或减少用户

四、其它的一些问题：

这里描述一些问题，表述其思考方式，以便举一反三：

1、发送的请求大于处理请求，出现排队的情况，响应时间会越来越长。

2、在允许同一个用户多点登录的情况下，在进行压测的时，不需要进行登录用户的参数化操作；如若不允许同一个用户进行多点登录的话，就需要进行参数化。

3、性能测试压测对象是action中的事务，在init中不影响，参数化的时候，用once的时候，不需要做参数化。

4、lr的循环嵌套：

cotroller里的运行时间 - while(endtime>0) → action的迭代 - while(迭代次数>0) → 脚本里的循环

故在脚本中，设置迭代的次数并不影响压测时，controller的显示。

5、loadrunner测试手机app:app和web一样，app本身就相当于web浏览器，后台调的都是服务，对server有并发对app本身没有并发，测试app分为两部分：后台的服务器的性能(接口),接口不需要录制，只需要知道app接口的说明文档，自己手写脚本；app本身，相当于web前端性能测试，需要用到其它前端性能测试工具。

6、IP欺骗：模拟本机局域网段内的大量IP来进行操作。服务器识别的是网卡IP，单网卡一个IP，双网卡俩IP。

---------

释然、感恩，感恩遇到她，感恩曾经一起的美好... ...

越努力越精彩，加油！！！

--------------

Controller及结果分析