性能测试基础性概念
【性能指标】
响应时间:
--------------------------------------------------------------------------------
呈现时间---浏览器接受到响应数据后呈现和执行页面上的脚本所消耗的时间
服务端响应时间---系统从请求发出开始到客户端接收到数据所消耗的时间
响应时间标准:2/5/10
并发用户数：
---------------------------------------------------------------------------------
真正意义上的并发不存在，CPU在一个时间点上只能干一件事。
服务器实际承受得压力不只取决于业务并发用户数，还取决于用户的业务场景。
例子1：一个OA系统，该系统有3000个用户，系统的在线统计功能最高峰值是600，平均每天大约有400个用户访问该系统，对一个典型的用户，一天只有8小时内使用该系
统，且从登陆到退出的平均时间为4小时。
系统用户数：3000
最大在线并发用户数：600
平均并发用户数：C=400*4/8=200（公式：C=nL/T）
并发用户数的峰值：C^约等于C加3部的根号C
例子2：典型的上班签到系统，早上8点上班，7点半到8点的30分钟的时间里用户会登录签到系统进行签到。公司员工为1000人，平均每个员上登录签到系统的时长为5分
钟。可以用下面的方法计算。
平均并发用户数C=1000*5/30=166.7
理解并发：
1、并发在线用户
2、并发交易用户（业务并发）
3、严格并发用户（绝对并发）
吞吐量：
---------------------------------------------------------------------------------
单位时间内系统处理的客户请求的数量，使用请求数/秒和页面数/秒来衡量。也称为TPS。
TPS：每秒钟系统能够处理事务或交易的数量
点击率：每秒钟用户向web服务器提交的HTTP请求数
所有性能问题中80%的问题是因为吞吐量的限制导致的
公式：F=N*R/T
F--吞吐量
N--VU的个数
R--每个VU发出的请求数量
T--测试所用的时间
当遇到性能瓶颈时，吞吐量和虚拟用户数量之间不再符合该式。
【性能需求分析】
性能需求获取方式：
1、客户方提出
2、根据历史数据分析
3、需求分析与定位
4、参考历史项目或其它同行业的项目
5、参考其它资料数据
性能测试点选取：
*发生频率非常高的（例如：某邮箱核心业务系统中的登录、收发邮件等业务，它们在每天的业务总量中占到90%以上）
*关键程度非常高的（产品经理认为绝对不能出现问题的，如登录等）
*资源占用非常严重的（导致磁盘I/O非常大的，例如某个业务进行结果提交时需要向数十个表存取数据，或者一个查询提交请求时会检索出大量的数据记录）
常见性能需求：
1、WEB首页打开速度5s以下，web登陆速度 15s以下。
2、邮件服务支持50万个在线用户
3、计费话单成功率达到99.999%以上。
4、在100个并发用户的高峰期，邮箱的基本功能，处理能力至少达到10TPS
5、系统能在高于实际系统运行压力1倍的情况下，稳定的运行12小时
6、这个系统能否支撑200万的vu（每天登录系统的人次）
【性能测试方法与流程】
性能测试方法常见分类：
性能测试
负载测试
压力测试
配置测试
并发测试
容量测试
可靠性测试（稳定性测试）
失败恢复测试（失败测试）
（1）性能测试是一种“正常”的测试，主要是测试正常使用时，系统是否满足要求。（广义的概念，侧重于性能指标。负载测试、压力测试等都属于性能测试）
（关于负载测试与压力测试的区别和准确定义在业界目前还没有统一的标准，以下是比较认可的观点）
（2）负载测试：负载测试指的是最常见的验证一般性能需求而进行的性能测试，用户最常见的性能需求就是“既要马儿跑，又要马儿少吃草”。因此负载测试主要是考察软件系统在既定负载下长时间运行的性能表现。我们对负载测试可以有如下理解：
a）负载测试是站在用户的角度去观察在一定条件下软件系统的性能表现。
b）负载测试的预期结果是用户的性能需求得到满足。此指标一般体现为响应时间、交易容量、并发容量、资源使用率等。
（3）压力测试：压力测试是为了考察系统在极端条件下不同压力下的表现，极端条件可以是超负荷的交易量和并发用户数。注意，这个极端条件并不一定是用户的性能需求，可能要远远高于用户的性能需求。可以这样理解，压力测试和负载测试不同的是，压力测试的预期结果就是系统出现问题，而我们要考察的是系统处理问题的方式。比如说，我们期待一个系统在面临压力的情况下能够保持稳定，处理速度可以变慢，但不能系统崩溃。因此，压力测试是能让我们识别系统的弱点和在极限负载下程序将如何运行。
（4）配置测试：主要是通过对被测试软件的软、硬件配置的测试，找到系统各项资源的最优分配原则。
（5）并发测试：测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题，几乎所有的性能测试都会涉及一些并发测试。
（6）容量测试：测试系统能够处理的最大会话能力，确定系统可处理同时在线的最大用户数，通常和数据库有关。
（7）可靠性测试：通过给系统加载一定的业务压力（如CPU资源在70%～90%的使用率）的情况下，运行一段时间，检查系统是否稳定。因为运行时间较长，通常可以测试出系统是否有内存泄漏等问题。
（8）失败测试：对于有冗余备份和负载均衡的系统，通过这样的测试来检验如果系统局部发生故障，用户是否能够继续使用系统，用户受到多大的影响，如几台机器做均衡负载，测试一台或几台机器垮掉后，系统能够承受的压力。
其他类型：
基准测试在系统无压力（测试环境独立于外界环境，服务器无额外服务运行，无额外监控进程运行，待测试系统无其他业务在运行）情况下，单用户迭代执行连续时间或次数，取得各种交易运行平均响应时间作为分析衡量指标。验证性能测试环境是否正常。 验证测试脚本及测试参数的正确性。获取系统处理单笔交易性能数据。
混合场景测试是对典型业务脚本按照一定比例组成混合业务脚本，在用户并发情况下运行混合脚本，对服务器进行压力测试，并在后台监控各项资源指标，测试或预测出系统可能存在系统的瓶颈所在，为性能调优或扩容提供依据。混合测试是最接近生产环境的测试。
浪涌测试是采用典型混合业务场景，通过脚本设置，形成高强度和低负载的交叉压力测试，持续进行一段时间验证系统在正常情况下以及峰值情况下系统的稳定性；以及找出增加或减少负载的过程中由于突然的占用或者释放系统资源而引起的问题。
【性能测试应用领域】
能力验证
规划能力
性能调优
缺陷发现
性能基准比较
【常见性能测试过程和方法】
1、SEI负载测试计划过程
2、RBI方法
3、性能下降曲线分析法
4、LoadRunner的性能测试过程
5、silk perfomer性能测试过程
6、敏捷性能测试过程
特点：
每个迭代目标中包含明确的性能目标
建立不同层次的性能测试
完全或接近完全自动化的性能测试
测试驱动开发（TDD）的方法保证性能和优化性能
7、非敏捷过程中的性能模型---PTGM
8、敏捷过程中的性能模型---APTM
PTGM:
1、测试前期准备：系统基础功能验证---组件测试团队---测试工具需求确认---性能预备测试（可选）
2、测试工具引入：选择工具---工具应用的技能培训---确定工具的应用过程（工具应用范围、使用中的问题）
3、测试计划：性能测试领域分析---用户活动剖析与业务建模---确定性能测试目标---制定测试时间计划
4、测试设计与开发：测试环境设计---测试场景设计---测试用例设计---脚本和辅助工具开发
5、测试执行与管理：搭建测试环境---部署测试脚本和测试场景---执行测试和记录结果
6、测试分析
APTM：
1、检查表
2、活动
3、建议工具
【性能分析与调优】
性能瓶颈：
1、硬件上的性能瓶颈：
一般指的是CPU、内存、磁盘I/O 方面的问题
2、应用软件上的性能瓶颈：
一般指的是应用服务器、web 服务器、中间件等应用软件以及数据库系统。
例如：中间件weblogic 平台上配置的JDBC连接池的参数设置不合理，造成的瓶颈。
3、应用程序上的性能瓶颈：
一般指的是开发人员新开发出来的应用程序。
例如，程序架构规划不合理，程序本身设计有问题（串行处理、请求的处理线程不够），造成系统在大量用户方位时性能低下而造成的瓶颈。
4、操作系统上的性能瓶颈：
一般指的是windows、UNIX、Linux等操作系统。
例如，在进行性能测试，出现物理内存不足时，虚拟内存设置也不合理，虚拟内存的交换效率就会大大降低，从而导致行为的响应时间大大增加，这时认为操作系统上出
现性能瓶颈。
5、网络设备上的性能瓶颈：
一般指的是防火墙、动态负载均衡器、交换机等设备。
例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其他负载较轻的
应用服务器上。在测试时发现，动态负载均衡器没有起到相应的作用，这时可以认为网络瓶颈。
查找瓶颈时按以下顺序，由易到难：
服务器硬件瓶颈---〉网络瓶颈（对局域网，可以不考虑）---〉服务器操作系统瓶颈（参数配置）---〉中间件瓶颈（参数配置，数据库，web服务器等）---〉应用瓶颈
（SQL语句、数据库设计、业务逻辑、算法等）
性能测试调优应该注意的要点：
1： 在应用系统的设计开发过程中，应始终把性能放在考虑的范围内。
2： 确定清晰明确的性能目标是关键。
3： 必须保证调优后的程序运行正确。
4： 系统的性能更大程度上取决于良好的设计，调优技巧只是一个辅助手段。
5： 调优过程是迭代渐进的过程，每一次调优的结果都要反馈到后续的代码开发中去。
6： 性能调优不能以牺牲代码的可读性和可维护性为代码。
性能分析方法：1、指标达成法 2、最优化分析法
性能问题调优步骤：
1、确定问题
2、确定原因
3、确定调整目标和解决方案
4、测试解决方案
5、分析调优结果
【性能测试工具】
jmeter
负载生成器---产生负载、以多进程和多线程的方式模拟用户行为
用户运行器---脚本运行引擎，附加在进程或线程上
资源监视器---获取测试过程中服务器和负载机的资源数据
报表生成器---根据获得的测试数据生成报表，可视化显示
测试计划Test plan 描述一个性能测试相关内容
线程组Thread Group 可以看成是一个虚拟用户组，每一个线程可以理解为一个虚拟用户
8类可执行元件包括：
采集器Sampler 向服务器发送请求，并记录响应信息
逻辑控制器Logic Controller 一类用于控制Sampler发送请求的逻辑顺序，一类用于组织和控制Sampler
监听器Listener 处理测试结果数据并进行可视化展示
配置元件Config Element 提供修改Sampler的配置数据
定时器Timer 用于设置等待时间
断言Assertion 用于设置检查点，检查测试中相应数据是否与预期一致
前处理器Pre Processors 对即将发出的请求进行特殊处理，URL重写等
后处理器Post Processors 对发出请求后得到的响应进行处理，提取响应中特殊数据等
LR
工具组成：
--------------------------------------------------------------------------
脚本生成器 Vugen
压力调度器 Controller
结果分析工具 Analysis
录制方式：
--------------------------------------------------------------------------
HTML-BASE Script：高级别录制方式，分为基于用户行为（web_link，web_submit_form）和基于URL(web_url，web_submit_form)
脚本简洁易理解，适用于标准IE，web_link有前后依赖关系而web_url没有。
URL-BASE Script：基于url请求的录制方式，会录制得到所有的http请求
适用于非标准IE，javascript等动态脚本等
事物：
-----------------------------------------------------------------
事物函数：
lr_start_transaction("登陆")
lr_end_transaction("登陆",LR_AUTO);
事务的状态包括：LR_PASS、 LR_FAIL 、 LR_AUTO 、 LR_STOP
设置事务的状态： lr_set_transaction_instance_status(LR_FAIL)
设置事务的状态并输出错误日志：lr_fail_trans_with_error("an error has occurred:%s",my_get_error_string(status));
获取事务的状态： lr_end_transaction("登陆失败",LR_FAIL);
获取事务所消耗的时间:
trans_time=lr_get_transaction_wasted_time("访问注册页"); //获得消耗时间
lr_output_message("The duration up to the submit is %f seconds",trans_time); //打印数输出消耗实时间
IP欺诈：
--------------------------------------------------------------------
其实只要记住两个要素即可使用这个功能：
1、用IP wizard 添加多个IP；
2、在Controller中通过Enable IP Spoofing。
而在使用IP欺骗功能上应该注意三点：
1、虚拟IP是同一个Generator上的多个IP，这种分配过程由Controller自动来进行；
2、对于同一个Generator，你模拟的用户数量多于IP数量时，将会发生IP重复的现象，否则将随机分配不同的IP。
3、对于同一个Generator，以其某一个IP添加到Generator中即可，不需要用不同的IP添加多次。
需要使用ip欺骗的原因：
1、当某个IP的访问过于频繁，或者访问量过大是，服务器会拒绝访问请求，这时候通过IP欺骗可以增加访问频率和访问量，以达到压力测试的效果。
2、某些服务器配置了负载均衡，使用同一个IP不能测出系统的实际性能。LR中的IP欺骗通过调用不同的IP，可很大程度上的模拟实际使用中多IP访问和并测试服务器均
衡处理的能力。
3、有一些网站会限制同一个用户同一个IP 的登陆。为了更加真实的模拟实际情况，LoadRunner允许运行的虚拟用户使用不 同的IP 访问同一网站。
思考时间：
---------------------------------------------------------------------
添加思考时间可以更真实的模拟用户行为，但它同时降低了用户并发。也就是说思考时间越长，对服务器的压力会越小。
设置：lgnore think time :忽视思考时间，也就说勾选这一项的时候 ，你脚本中加入的lr_think_time 函数设置是无效的。
Replay think time：回放思考时间。lr_think_time(20); //设置思考时间
集合点：
---------------------------------------------------------------------
同一时刻一起执行某个任务
lr_rendezvous("集合点"); //添加集合点
设置中三种策略的含义：
Release when ：当所有虚拟用户中的x % 到达集合点进释放，即仅当指定百分比的虚拟用户到达集合点时，才释放虚拟用户。
注意：此选项将会干扰场景的计划。如果选择此选项，场景将不按计划运行。
Release when ：当所有正在运行的虚拟用户中的x %到达集合点时释放，即仅当场景中指定百分比的、正在运行的虚拟用户到达集合点时，才释放虚拟用户。
还有不在运行的虚拟用户？ 假如，设置为1分钟启动一个用户，当然会存在因为用户还没启动，所以无法参与集合点。
Release when ：当x 个虚拟用户到达集合点时释放，即仅当指定数量的虚拟用户到达集合点时，才释放虚拟用户。
这个很好理解，当我用百分比不太好衡量集合点的虚拟用户数，当然可以设置具体的用户数。
Timeout between Vusers （虚拟用户之间的超时）框中输入一个超时值。
假如设置了集合10用户并发，结果9个用户已经集合到位，还剩1个虚拟用户，左等右等就是等不来。那总不能一直等下去吧。设定了个时间，假如30秒还不来，那就
不管它了。超时的时长默认是30秒，我们可以根据具体的被测应用进行调整。
关联：
-------------------------------------------------------------------------
原理：
录制过程：
1、输入用户名密码登录。
2、服务器端返回一个sesiionID@@@12345。
3、客户端拿着获得sesiionID@@@12345进一步请求服务器信息。
4、服务器返回客户端想要的信息。
回放过程：
1、输入用户名密码登录
2、客户端返回新的sesiionID@@@23456
3、因为脚本中的sesiionID@@@12345 是写死的，所以我们会依然拿着老的sesiionID@@@12345去向服务器请求信息
4、服务器你经过验证发现你的sesiionID@@@12345 是错误的。
关联的三种方法：
自动关联
手动关联
一边录制一边关联
web_reg_save_param函数建立关联脚本
检查点：
---------------------------------------------------------------------------
文本检查点：Web_reg_find
图片检查点：web_inage_check
参数化取值方式：
---------------------------------------------------------------------------
怎样取下一行数据？
Sequential：顺序，所有虚拟用户按照顺序读取数据表
Random：随机，所有虚拟用户随机形式读取数据表
Unique：唯一，所有虚拟用户每次各取一值（不重复）
什么时候访问数据表完成数据更新？
Each iteration：每次迭代以后
Each occurrence：每次出现参数
Once：每出现一个虚拟用户
参数和变量：
---------------------------------------------------------------------------
默认使用{}的字符串称之为参数，必须在""中才能应用，而变量如果使用""双引号则变成了字符串
如：web_link(lr_eval_string("{param}","TEXT={param2}",LAST) //web_link函数要求第一个逗号前是字符串
把字符串abcdef保存进参数website中：
lr_save_string("abcdef","website")
另外：参数是全局的，变量一般是局部的（只在所在action中有效）
http://www.cnblogs.com/qmfsun/p/4503271.html
场景运行计划（Schedule By）：
---------------------------------------------------------------------------
group：多个脚本之间按照独立设置模式跑，各个脚本可以单独设置虚拟用户、运行时间等
scenario：多个脚本之间按照相同的模式跑，将总的虚拟用户数按照一定的比例分配给各个脚本
场景运行模式（Run Mode）：
---------------------------------------------------------------------------
Real-world schedule: 真实场景模式 可以通过增加ACTION来增加多个用户
Basic schedule: 以前用的 经典模式 只能设置一次负载的上升和下降
浙公网安备 33010602011771号