性能测试基本测试概念.docx
《性能测试基本测试概念.docx》由会员分享，可在线阅读，更多相关《性能测试基本测试概念.docx（20页珍藏版）》请在冰豆网上搜索。
性能测试基本测试概念
一、性能测试的目的
1、评估当前系统
2、寻找瓶颈
3、预测未来性能
二、性能测试的前提：
接口稳定/接口确定
三、性能术语与指标详解：
1.并发：
（1）一种为所有用户在同一时刻做同一操作，主要是为了验证程序或数据库对并发处理能力
（2）另一种为多个用户对被测系统发起了多个请求，这些请求可以是同一种操作，也可以是不同操作，类似于混合场景的概念
2.响应时间：
响应时间反应完成某个业务所需的时间
响应时间=网络传输时间（请求）+服务器处理（一层或多层）时间+网络传输时间（响应时间）+页面前端解析渲染时间
3.每秒通过事务数（TPS）：
指每秒通过的事务数，是直接反映系统性能的指标，该值大时，系统性能比较好，当然每个系统都有他的上限，不可能无限大
将他以平均事务响应时间进行对比，可以分析事务数量对以响应时间的影响
4.事务：
用户一个或一系列的操作，代表一定的功能，在程序上变现为一段代码区块，所有性能测试其实最终都是围绕着事务展开的，事务代表用户的使用方法和结果，不同的操作组合成不同的事务，不同的事务又能组合成不同的场景
（LR必须至少有一个事务，LR监控事务）
（事务不能超过接口的上限）
事务Transactions
5.事务请求时间：
从这个事务发起到最终处理完毕的所有时间。
一个事物包括一个或多个事务，每个任务包含一个或多个请求。
6.每秒点击数：
每秒点击数代表用户每秒向外部服务器提交的http请求，但这里需要注意是提交一个登陆请求对于后端服务器来说，也许是多个请求，所以点击一次不代表就是一个请求。
7.吞吐量/吞吐率（I/O）（Input/Output）（反应服务器处理能力）
吞吐量：
指单位时间系统处理的请求数量
吞吐率：
一般指用户在给定的一秒从服务器获取的数据量，简而言之就是服务器返回的数据量
8.思考时间：
指用户进行操作时每个请求或操作之间的间隔时间，是为了更加真实的模拟用户的操作场景。
9.资源利用率（服务器）
CPU：
一般分为系统CPU和用户CPU
系统CPU：
是处理系统本身占用的资源
用户CPU：
是处理程序所占用的资源
LoadAverage：
指一段时间CPU正在处理和等待CPU处理的任务，也就是CPU使用队列的长度的统计信息
缓存（比CPU运行速度慢）：
他就像大脑的记忆区域，将各种信息收集起来存放，数据从存中读取要比硬盘上读取速度快，存会有泄露和溢出现象。
队列：
可以理解成地铁进站的排队现象，队列长，说明处理能力可能达到了极限或者遇到的阻塞
I/O（硬盘）：
与磁盘的交互，重点关注交换频率和磁盘队列长度
网络：
重点关注网络的流量，看是否存在网络带宽的瓶颈
四、性能测试分类
1.基准测试：
可以在制定的标准下通过测试建立一个性能基准，这样以后当系统的环境参数发生变化后，在进行一次相同标准下的测试，即可看出变化对性能的影响。
系统进行基准测试可以在较早的阶段发现性能问题。
2.并发测试：
可以理解为很多的用户按照预定的场景并发请求某个业务或功能时是否出现并发问题。
并发测试的算法：
（1）并发数=PV/PVTime*页面连接次数*HTTP响应时间*因数/web服务器数量
解释：
PV：
即页面浏览量，一个用户可能创造十几个甚至更多的PV。
他是目前判断访问流量最常用的计算方法，也是反映受欢迎程度的重要指标。
PVTime：
是PV的统计时间，换算成秒，一天就是86400秒
页面连接次数包括外部的JS，CSS，图片等，一般为10
HTTP响应时间一般为1秒或更少
因数一般为5
（2）C=nL/T（段念【软件性能测试过程详解与案例剖析】）
解释：
C是平均的并发用户数
n是平均每天访问用户数
L是一天用户从登录到退出的平均时间（操作时间）
T是考察时间长度
C’≈C+3*√c
解释：
C’是最大并发数
3.负载测试：
可以理解为确定所要测试的业务或系统的负载围，然后对其进行测试，他的主要目的验证业务或者系统在给定负载条件下的处理能力。
此外，还要关注响应时间、每秒通过事务数和其他相关指标。
负载测试是为了发现性能问题。
而性能测试是为了获取性能指标。
4.压力测试：
可以理解为没有预期的性能指标，不断加压，看系统什么时候崩溃，以此来确定系统的瓶颈不能接受的性能拐点，以获取系统的最佳并发数，最大并发数
压力测试也可以看作负载测试的一种，即高负载下的负载测试。
负载测试与压力测试的概念并非完全独立，在实际应用中一般二者都是相互结合，相互补充的。
5.稳定性测试（小公司不测）：
需要长时间运行，在这段时间观察系统的出错几率、性能变化趋势等。
进而大大减少系统上线后的崩溃的现象。
一般都会进行所谓的7*24小时的稳定性测试
1）一般稳定性测试需要在系统成型后进行，并且没有严重的BUG存在
2）场景的设计以模拟真实用户的实际操作为最佳。
6.失效恢复测试（小公司不测）：
重在关注系统出现问题后能否根据预先制定的策略回恢复，且恢复后能否正常运行。
失效恢复测试一般是对其具有负载均衡的系统进行的，主要是为了测试当前系统发生故障时，是否会对全局产生大的影响，产生的影响在是否可以接受的围，以及用户能否继续使用系统。
在实际应用过程中，可以模拟一台或者几台负载均衡出现故障来进行失效恢复测试，但需要注意的是，不仅要关心失效后，用户是否可以正常访问或者恢复后系统是否可以正常工作，也要关注失效后，系统还能支持多少并发用户，以及采用那些备选方案来响应。
7.现网性能测试（小公司不测）：
就是实际网络，实际环境中进行测试，完全和真实用户一样，当然这样的测试有一定的风险，需要注意以下几点：
（1）时间段的选择，非高峰时间段，选择都为半夜或者凌晨来进行
（2）垃圾数据处理。
测试数据后期一定要清理，为了清理方便、前期数据的设计要有规律可循
（3）网络限制，压力机需要和被测试服务器部署在同一个网段机房，这样可以避免网络限制，最后远程收集数据即可。
*如果没有特殊情况，尽量不要进行现网的性能测试，风险比较大，如果非要进行，一定要事先充分评估风险以及应对的解决方案。
LR的三大模块
VirtualuserGeneratorLR8（虚拟用户生成器）
Create/EditScriptsLR11
创建/编辑脚本
LR进行操作的第一步，制造基本性能脚本
性能测试前的准备
Controller（控制器）
RunLoadTests
运行负载测试
在脚本写完的基础下，对其设置不同的场景，进行测试
性能测试执行
Analysis（分析）
AnalyzeLoadTests
分析测试结果
参看性能测试的结果数据，并进行适当的分析
预期结果与实际结果的对比，并查找问题根源
模块间的关系
LR8VirtualUserGenerator-Controller-Analysis
LR11Create/EditScripts-RunLoadTests-AnalyzeLoadTests
创建脚本-运行测试（创建场景并执行脚本）-分析结果得到报告
LR录制流程
1.选择协议：
web类型：
协议HTTP/HTML、Web协议
FTP服务器：
选择FTP
服务器：
协议选择IMAP（同步电子）、POP3（接收电子）、SMTP（发送电子）
ADO、OLEDB方法连接后台数据库的C/S客户端：
选择协议MSSQLServier、Oracle、Sybase、DB2
以ODBC方法连接后台数据库的C/S客户端：
协议选用ODBC
没有后台数据库的C/S客户端：
协议选择Socket
B/S网络客户端---服务器端（中间件，数据库，缓存）客户端作用显示
C/S单机客户端（中间件，数据库，缓存）
LR11支持浏览器IE6IE9
IE8
自带火狐
新版火狐
谷歌
要录制的程序：
浏览器
工作目录：
浏览器所在目录
LR录制前的设置
应用程序类型：
Internet-网页
Win32-window下运行的程序
要录制的路径：
自动打开的软件路径和程序
URL地址：
自动连接的接口地址
工作目录：
浏览器/被测试软件的路径
录制到操作：
init—脚本开始
Action—脚本的运行主体
End—脚本的结束
一、脚本的调试
1.回放：
确认之前的脚本能够正常运行
2.保存/另存为：
保存当前脚本
3.树：
可以看到页面的截图
4.设置事务：
事务函数：
lr_start_tarnsaction（“事物的名字”）
lr_end_transaction（“事务的名字”，“事务的状态”）
解释：
事务状态：
AUTO：
自动，一般为默认
PASS：
不管事务怎样都算通过
FALL:
不管事务怎样都不算通过
STOP：
不管事务怎样都要停止
注意
（1）一个脚本起码要有一个事务，不然毫无意义
（2）事务只能出现在Action部分
（3）事务有起始必须有结束，且名字必须对应
（4）事务开始必须在接口方法前
5.集合点：
让虚拟用户在指定的地址集合，先到的人在这边进行等待，直到最后一个人到达在一起执行，通过集合点可以模拟一定意义上的用户并发
设置集合点函数：
lr_rendezvous（“集合点的名字”）；
注意：
（1）集合点必须在事务开始之前进行，从而保证事务在之后的性能测试中能并发一起执行
（2）设置集合点将增加对服务器的压力
（3）只应在action部分出现
6.思考时间
思考时间函数：
lr_think_time（秒）；
注意：
LR初次使用对于思考时间是默认不参与，需要进行一定的设置更改
方法：
Vuser-运行时设置（F4）-思考时间（按照设置要求，定值，给予百分比，围值）
思考时间越大，对服务的压力会变向的越小
7.迭代
（往往和参数化一起进行）
注意：
只有Action部分才能进行迭代操作
方法：
Vuser-运行时设置（F4）-运行逻辑-迭代次数（修改）
迭代越多对服务器的压力越大
8.参数化：
LR的参数化有两种，一种是俗称文件形式的参数化，一种是数据库形式的参数化。
一般参数化的应用场景有如下几种：
（1）真实的模拟用户操作
（2）系统不允许同一个用户频繁的进行相同操作
（3）系统对数据的唯一性有要求
设置参数化的一般步骤为：
分析需要参数化的数据--设计数据分配方法--查找替换对象。
1.文件参数化：
（1）依次点击菜单中Inset-NewParameter命令。
点击new按钮，并重命名为username
（2）点击CreateTable-EditwithNotepad在弹出的文本中输入参数化的值，每个值占据一行，保留一个空行，保存关闭
（3）回到脚本中，找到要参数化的用户名，选中，单击右键，选择UseExistingParameter-username
（4）最终完成参数化后，参数username被{}包围，这是LR中的规则
（5）点击菜单Vuser-Run-timeSetting-RunLogic,设置迭代次数为3，这样才能让脚本跑三次来验证是否正确
2.1多数列对应参数化
（1）新建参数Pwd，并选择File为username.dat
（2）添加列：
点击AddColumn按钮，查看弹出框，点击ok按钮
（3）添加密码：
点击EditwithNotepad按钮，输入用户名对应的密码，比如username，pwd
（4）回到脚本中替换掉密码值即可，方法与用户名的替换相同
2.数据库参数：
使用数据库参数化首先要安装ODBC。
数据库为mysql的话，下载mysqlODBC安装到本地，之后配置即可
（1）在脚本里新建一个参数，多为usernamedb
（2）单击datawizard按钮，在弹出的对话框中选择specifySqlstatementmenu并单击“下一步按钮”
（3）单击create按钮，在弹出的对话框中选择“机器数据源”后，单击“新建”按钮
（4）选择系统数据源并单击“下一步”按钮
（5）选择“mysqlODBCx.xxDriver”并单击下一步
DataSourceName和Description可随意填写
TCP/IPServer：
是Mysql所在服务器的IP地址
Port：
mysql使用的端口号
user：
mysql使用的用户名
password：
mysql账号的密码，如果为空则不填
database：
是可以连接的数据库列表
Test：
可以测试是否连接成功
（6）完成上述填写并确定后，在列表中看到新建的数据源
（7）双击要参数化的值后，可以把此数据源配置到DataWizard中
（8）在SQL处输入想要查询的sql语句后，完成数据的参数化
3.参数化设置：
参数时间或者一个随机值，可以在参数化对话框的parametertype下拉列表中选择
file和Table类型：
文本类型
data/time:
可以在需要参数化日期的地方使用此类型
groupname：
使用该虚拟用户所在的Vusergroup名称来代替参数化
iterationnumber：
使用脚本执行的当前次数来代替参数化
loadgeneratorname：
使用生产vusers负载的机器名来代替参数化
randomnumber：
使用唯一随机数来代替参数化
uniquenumber：
使用一个唯一的整数来代替参数化
vuserID：
使用虚拟用户的ID来代替参数化
userDefinedFunctions：
扩展接口，可从用户开发的DLL文件中提取数据
XML：
提供对xml格式数据的支持。
可从xml中读取数据进行参数化
4.参数化数据分配方式：
分配值得方式，一共9种组合，理解意思即可
（1）selectnextrow:
选择下一行的策略
Sequential:
顺序取行
random：
随机取行
（2）updatevalueon:
更新值的策略
Eachiteration:
每次迭代都要取新值
Eachoccurrence:
只要发现该参数取过就会重新取值
Once:
在所有的反复中都使用同一个值
9.关联：
关联其实就是动态的获取服务器的某些值，即使不动态的值，也完全可以用关联
一般出现以下几种情况需要考虑是否使用关联
1）服务器返回值中存在动态变化的值，一般就是类似session的无规则数据
2）运行后没有报错，但是也没有产生记录
3）后续的操作要使用到之前的数据。
例如：
回帖操作要知道之前发帖子的ID才行
F1所有函数脚本
接口引用代码JS
举例：
如果HTML中标签如下
手动编写关联：
web_reg_save_param（“快递单号关联”，
“LB=value=A”，
“RB=B”，LAST）；
将代码中的value={快递单号关联}
录制两次
问开发：
那些是自动排列的
Web的值传输
自动关联：
（Ctrl+F8）自动跑一次进行对比记录
手动关联：
web_reg_save_param（“名”，
“LB=name=”
“RB=value>”，LAST）；
配合HTML
Cookie:
Session:
自动关联的操作：
1）回访F5
2）点击correationresults
3）ctrl+F8
4）选择需要关联的项，点击correlate
10.检查点
前提：
（1）检查点一定要放到事务的上面
（2）检查点检查的一定是系统的信息，而不是自己输入的
1）文本检查点：
用于HTML页面检查是否有用户指定的文字
//文本检查点，检查jixu
Web_reg_find（“Text=jixu”,LAST）
2）图片检查点，用于在HTML页面检查是否有用户指定的图片
Web_image_check（“退出”,//图片名称，随意“Src=/webtours/image/signoff.gif”,//图片的src属性LAST）；
二、设置并执行脚本
1.选择场景
手动场景：
（大多数选择的模式）
设置场景-查看执行结果
使用百分比-按照人数分配的百分比执行（往往只适合超大型的项目）
不适用百分比-按照虚拟用户数执行（默认）
自动场景（面向目标场景）
设置执行结果-自动生成场景
2.载入脚本
双击脚本，或者点击>,脚本在右侧显示即可
3.设置场景
（1）确定场景组
确定此次性能测试执行时用到的脚本数量和运行方式
（2）全局计划
初始化：
每一个虚拟用户的初始准备时间
启动vuser：
设置脚本总计运行人数，以及启动时间
持续时间：
性能测试的执行时间
完成前一直执行：
遵循脚本的迭代设置（脚本在制作时的要求，迭代几次，就运行几次）
运行时间：
根据运行时间来进行N次迭代，直到时间结束
停止Vuser：
停止脚本所用的时间和方法
4.集合点策略
前提：
脚本中必须先有集合点：
lr_rendezvous（“名称”）
在场景中，菜单栏Scenario-Rendezvous，打开集合点设置界面
设置：
（1）rendezvous：
集合点的列表，可通过下面的disablerendezvous按钮启动或关闭
（2）
（3）vusers：
当前设置的并发用户数，可通过下方的disableVuser按钮来启动或关闭虚拟用户
（4）-policy（集合点策略）：
单击后进入策略设置对话框
策略的设置：
1）当所有用户的X%到达集合点时释放
2）当所有正在运行的用户的X%到达集合点时释放
3）当X个用户到达集合点时释放
4）超时设置：
表示等待用户超时规定的时间，如果在X秒没有满足要求的用户到达，则释放集合点。
5.IP欺骗
对一般系统而言，是否使用IP欺骗并不会影响性能测试，只有在特殊的要求下才会使用。
如：
1.某系统限制同一个IP用户在短时间对系统进行恶意或大量的请求访问
2.负载均衡策略根据IP规则分配
前提：
本地的IP地址不能设置为“自动获取”，必须指定一个静态的IP地址，否则报错。
添加步骤：
1.开始-程序-HPLR-tools-IPwizard
选项：
新增
选择保存的文件
释放还原
2.选Createnewsetting点击下一步
3.输入服务器的IP地址或者留空也可以，点击下一步
4.点击Add按钮，弹出添加IP的对话框
5.修改fromIP为xxxx.xxx.xx.xx或者numbertoadd直接加上要模拟的人数，点击OK
6.点击完成
7.保存：
点击“saveas”按钮，可以将本次文件保存为“.ips”文件，点击OK
8.进入LP的场景设置controller中，菜单选择Scenario-EnableIPSpoofer完成
释放还原：
1.重复上面的第一步，选择释放还原
2.移除，点击完成
3.重启计算机
6.压力机
（添加windows压力机）
1.保证要添加的压力机安装了LoadRunnerAgent（小卫星）
2.添加的压力机与Controller的所有机子要在同一个网段，并且要关闭所有的防火墙
3.本地系统的RPC服务要开启（“控制面板”-“管理工具”-“服务”中开启）
4.之后在Controller所在的机器上登录到压力机（远程连接），验证是否可以连通。
单击Windows系统的“开始”-“运行”在弹出的对话框中输入“\\机器名”，不报错则成功。
5.进入Controller，依次点击Scenario-LoadGenerators菜单项，默认会有一台压力机
6.点击add
Name：
这里填写是IP地址
Platform：
默认为机子系统
7.点击“ok”，点击Connect，可以测试通不通过，通过为Rendy
8.最后可以把压力机分到对应的脚本中。
7.监控服务器的设置
（windows添加监控对象）
右键点选系统资源图----添加度量----设置监控器服务器的名称-----最基本的监控容
%ProcessorTime（CPU的占有率）
AvaliableMBytes（memory可用的存）
8.执行
点击执行模块中的开始即可
三、分析结果
1.方法
1.运行后直接点击分析模块的图标
2.保存执行文件，点击分析模块（analysis），导入文件
3.直接点击分析图标
2.添加新项
1.右键点击报告—添加新项—windows资源图
2.新建后右侧图框中点击右键设置颗粒度
四、分析
（初步分析）
1.事务摘要描述（transactionsammary）
显示事物的通过数量和失败数量
成功率=成功数/（成功数+失败数）
失败率=失败率/（成功数+失败数）
2.平均事务响应时间（AverageTransactionResponseTime）
显示所有场景中出现的事务在执行时的响应时间的情况
随着测试时间的加长，系统处理事务的能力就会开始逐渐下降，总体的事务时间情况应该是缓步进行变更的，如果出现大起大落的现象，则为缺陷，说明该事务不稳定
3.每秒点击数（HistperSecond）
每秒发送服务器的请求数
这个数值反应出服务器承受压力的能力
4.吞吐量（Throughput）
服务器每秒处理的数据量
这个数值反应出服务器的处理能力
5.每秒通过的事务数（TimesuctionsperSecond）
反应出不同事务在执行时竞争服务器资源的情况
五、初步判定
1.当服务器处理能力远大于服务器受压情况时，这种性能测试无意义
2.当服务器处理能力小于服务器受压情况时，能容忍一定的事务数报错
3.随着压力的增大，事务报错数逐渐增加
4.在压力一定的情况下，查看失败率和需求做对比确认，以验证此次性能测试通过与否
一般性能测试的结束基本的通过以下容进行判定
1.成功率
2.事务平均时间
3.并发用户数
六、收集
Average：
事务的平均响应时间
Min：
事务最少响应时间
Max：
事务最大响应时间
90%Line：
90%的响应时间
Std.Deviation：
标准差
Fail：
错误的事务
Pass：
通过
Error：
错误
Throughput/sec：
吞吐量
KB/sec：
服务器数据流量
项目性能分析
用户数
100
200
300
平均响应时间
10
10
5
吞吐量
1000
500
300
KB
10
5
3
总计需求数
10000
1000
1000
用户数与服务器处理请求的平均时间关系图
1.本图表示服务器处理请求的平均响应时间
2.最佳性能是随着并发用户数的增加，平均事务响应时间比较平稳
3.本图可以清晰看到，对着并发用户的增加事务的响应不平稳
用户数与服务器处理请求关系图
1.表示服务器每秒处理请求个数
2.最佳性能服务器处理请求数是随着用户的增加而增加
3.本图可以清晰看到，XXX
用户数与服务器
升级会员 