性能测试基础知识
目标
1. 理解什么是性能测试
2. 掌握性能测试基础分类
3. 熟悉性能测试常用指标为什么学习性能测试
业务需求：
1. 登录不得超过3秒钟
2. 开发一款Web电商网站，使用JSP还是PHP呢？
3. OA办公系统-我们公司20000左右员工需要使用此系统；
职场需求：
1. 会性能测试吗？
2. 招聘信息-技能需求：要求会使用性能测试工具LoadRunner、Jmeter业务需求
1. 负载测试-根据客户实际应用场景模拟测试应用软件、服务器是否满足需求，如果不满足，则定位问题问题，
进行调整直到满足需求；
2. 分别使用JSP和PHP写个Demo，根据应用场景进行性能测试，找出最优符合应用场景的开发语言；
3. 根据二八定律统计出单位时间内(秒)最高请求数；以上解决方案都为性能测试方面知识，我们暂无法解决，所以需要学习性能测试。什么是性能测试？ 重要
概念：性能测试是模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
说明：
1). 峰值：客户指定指标数值或场景需求数值，如：CPU80%以内、登录3秒、内存空间40%...
2). 负载：用户(一个、多个)向服务器发送请求... 性能测试与功能测试 焦点
功能测试：验证软件系统操作功能是否符合产品功能需求规格，主要焦点在功能（正向、逆向）；
性能测试：验证软件系统是否满足业务需求场景，主要焦点是业务场景的满足(时间、空间)；
说明：
时间：软件的响应时间...
空间：服务器的磁盘使用率、CPU使用率、内存空闲率...性能测试与功能测试 关系
功能测试和性能测试是相辅相成的，对于一款优秀的软件产品来讲，它们是不可减少的2个重要测试环节；性能测试分类
为什么要学习性能测试分类？
1. 性能测试是个综合的概述
2. 性能测试指的是测试一种分类或多种分类
3. 任何一具体分类，都是性能测试性能测试常用分类
1. 负载测试
2. 压力测试
3. 并发测试
4. 稳定性测试
提示：性能测试分类还有其他类型比如：配置测试、容量测试等，在于前期我们先熟悉以上常用分类负载测试【重点】
说明：通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统的性能指标情况下，系统所能够承受的
最大负载量的测试。
(负载：向服务器发送请求)
提示:负载测试是通过逐步加压的方式来确定系统的处理能力、确定系统能够承受的各项阀值。
例如：逐步加压，
从而得到“响应时间不超过3秒”、“服务器平均CPU利用率低于80%”等指标的阀值。
* 阀值：关注的某一具体数值(比如：登录小于3秒、用户数2000、业务成功率100%时的服务器并发数)压力测试【重点】
说明：
通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于【失效】状态。
提示：
1. 压力测试：是逐步增加负载，使系统某些资源达到饱和甚至失效。
(如：测试系统最多支持同时处理多少请求，超过此数数量系统瘫痪)
2. 负载测试：是逐步增加负载，确定在满足性能指标情况下，系统能承受的最大负载测试。
(如：登录3秒内，最多支持多少用户同时登录；如超出此数量，可能需要5秒钟或更多时间才能登录成功)压力和负载区别：压力是逐步增加系统负载并在什么负载条件下到系统瘫痪，也就是说负载到系统崩溃，
负载是在某个限制条件下（登录3秒内）所能承受的最大负载率，系统不会崩溃，只是超过限制条件。
并发测试【重点】
说明：
1. 概念：并发测试就是【多用户】同时访问【同一个应用】；
2. 目的：测试应用服务器 指定功能 的同时访问数是否达到预期结果；
提示：
1. 并发测试需要配合集合点来使用
2. 集合点：我们在接口阶段已了解，这里做个简单回顾...
集合点作用：集合点用以同步虚拟用户，以便恰好在同一时刻执行任务稳定性测试【理解】
说明：通过给系统加载一定的业务压力（如CPU资源在70%～90%的使用率）的情况下，运行一段时间，
检查系统是否稳定。
提示：
1. 通常稳定性测试，我们测试一段时间即可；
(如：24小时、3×24小时或7×24小时来模拟长时间运行) 性能测试常用指标【重要】
思考
以上性能测试分类都依赖那些指标来衡量相应的数据或峰值？ 什么是指标
说明：一些经过运算得出的结果，来衡量某种操作性能统称；比如：错误率 0.5%这里罗列了性能测试常用指标
1. 吞吐量
2. 并发数
3. 响应时间
4. 点击数
5. 资源利用率
6. 错误率吞吐量
说明：吞吐量（Throughput）：指的是单位时间内处理的客户端请求数量，直接体现软件系统的性能承载能力。
通常情况下，吞吐量用“请求数/秒”或者“页面数/秒”来衡量。
提示：
1. 从业务角度来看，吞吐量也可以用“业务数/小时”、“业务数/天”、“访问人数/天”、“页面访问量/天”来衡量。
2. 从网络角度来看，还可以用“字节数/小时”、“字节数/天”等来衡量网络的流量。并发数
说明：并发（Concurrency）：它最简单的描述就是指多个同时发生的业务操作。
（例如，100个用户同时单击登录页面的“登录”按钮操作。）
提示：并发性测试描述的是多个客户端同时向服务器发出请求，考察服务器端承受能力的一种性能测试方式。响应时间
说明：响应时间指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回结果整个过程所耗费的时间聊聊QPS/TPS/并发量/系统吞吐量
在学习性能测试时，经常会对qps、tps、并发量、系统吞吐量这些抽象概念混淆，故此写下这些，帮助理解：
我们在日常工作中经常会听到QPS/TPS这些名词，也会经常被别人问起说你的系统吞吐量有多大。
这个问题从业务上来讲，可以理解为应用系统每秒钟最大能接受的用户访问量。或者每秒钟最大能处理的请求数；
QPS“每秒查询率”:
每秒钟处理完请求的次数；注意这里是处理完。具体是指发出请求到服务器处理完成功返回结果。
可以理解在server中有个counter，每处理一个请求加1，1秒后counter=QPS。
TPS每秒处理事务数：
每秒钟处理完的事务次数，一般TPS是对整个系统来讲的。
一个应用系统1s能完成多少事务处理，一个事务在分布式处理中，可能会对应多个请求，对于衡量单个接口服务的处理能力，用QPS比较多。
并发量：系统能同时处理的请求数
RT：响应时间，处理一次请求所需要的平均处理时间
计算关系：
QPS = 并发量 / 平均响应时间 （每秒钟能处理完的请求次数）
并发量 = QPS * 平均响应时间一、QPS/TPS
QPS：
Queries Per Second意思：是“每秒查询率”，是一台服务器每秒能够响应的查询次数，
是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
TPS：
是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。
一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，
以此来计算使用的时间和完成的事务个数。
Tps即每秒处理事务数，包括了
1）用户请求服务器
2）服务器自己的内部处理
3）服务器返回给用户
这三个过程，每秒能够完成N个这三个过程，Tps也就是N(这里不是3，看我的csdn收藏原版)；
QPS与TPS区别：
Qps基本类似于Tps，但是不同的是，对于一个页面的一次访问，形成一个Tps；
但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“Qps”之中。
例如：访问一个页面会请求服务器3次，一次产生一个“T”，产生3个“Q” （因为页面中可能会有图片等资源去请求服务器）
二、系统吞吐量
一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。
单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。
系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间
QPS（TPS）：每秒钟request/事务 数量
并发数： 系统同时处理的request/事务数
响应时间： 一般取平均响应时间
理解了上面三个要素的意义之后，就能推算出它们之间的关系：
QPS（TPS）= 并发数/平均响应时间 或者 并发数 = QPS*平均响应时间点击数
说明：点击数是衡量Web服务器处理能力的一个重要指标。它的统计是客户端向Web服务器发了多少次HTTP请求计算的。
提示：
1. 点击数不是通常一般人认为的访问一个页面就是１次点击数，点击数是该页面包含的元素
（访问一个页面并响应，那就是一个事务数了）
（如：图片、链接、框架等）向Web服务器发出的请求数数量。
2. 通常我们也用每秒点击次数（Hits per Second）指标来衡量Web服务器的处理能力。
点击数，查看响应状态码，访问一个页面可能有多个点击数，用F12查看服务器端的响应状态码，就可知道这个页面有多少个点击数。
点击数的统计是在服务器端完成的。
结论：和qps概念类似资源利用率
说明：是指系统各种资源的使用情况，一般用“资源的使用量/总的资源可用量×100%”形成资源利用率的数据。
提示：通常，没有特殊需求的话
1). 建议CPU不高于80%；
2). 内存不高于80%；
3). 磁盘不高于90%；错误率
说明：错误率指系统在负载情况下，失败交易的概率。错误率＝(失败交易数/交易总数)*100%。
提示：
1. 不同系统对错误率要求不同，但一般不超过千分之五；
2. 稳定性较好的系统，其错误率应该由超时引起，即为超时率。性能测试常用工具
1. Jmeter
2. Loadrunner 【本阶段学习】
提示：性能测试工具与很多，目前最常用就是这两款，我们作为性能测试初期入门掌握这两款工具足矣；Jmeter
说明：Apche公司使用Java平台开发的一款测试工具
作用：性能测试、接口测试、Web测试(无Gui)
优点：免费、开源、小巧LoadRunner
说明：HP公司使用C语言开发的一款性能负载测试工具
作用：模拟高并发负载测试、测试场景搭建、运行、监控 、结果分析
优点：支持多协议、自带强大的图表功能、可根据需求合并需要的图表
缺点：收费Jmeter and LoadRunenr
提示：
1. Jmeter： 接口测试及接口性能压测首选
2. LoadRunner： Web性能测试首选(可以对事务进行测试)
说明：
1. Jmeter已学过，本阶段不在介绍
2. LoadRunner本阶段学习使用LoadRunner11安装
1. 了解LoadRunner11的安装
2. 了解LoadRunenr11注册 一、安装步骤
1. 解压 - loadrunner-11.iso
2. 启动安装程序 - setup.exe(提示：鼠标右键-兼容性：xp；权限-以管理员运行)；
3. 根据安装提示进行配置并点击下一步操作,直到安装完成；
注意：
1). 自动安装loadrunner必要依赖文件时，要重启电脑才可安装；
2). 新建文件夹(如：c:loadrunner11)避免安装路径中有中文和空格；
(原因：默认安装路径自带机票网站会出现登录异常；)
4. 修改注册许可证二、安装图解
解压loadrunner-11.iso后文件
运行：setup.exe
点击安装选项
点击：LoadRunner 完整安装程序
确定安装loadrunner依赖程序
点击：确定
异常【重要】
处理：重启电脑
开始安装loadrunner
点击：下一步
许可协议
点击：同意、下一步
客户信息
处理：默认或根据需求填写
点击：下一步
选择安装文件夹【重要】
处理：新建指定文件夹(避免中文及空格、避免默认路径)
点击：下一步
确认安装
点击：下一步
安装中
安装完成
查看-安装完成文件
点击：开始菜单-HP LoadRunner注册许可证-使用图
修改前
说明：使用用户类型：临时
修改后
说明：使用用户类型：永久
1. 下载lf_file.rar文件
2. 将 lm70.dll、mlr5lprg.dll 两个文件复制并替换到LR11安装目录下的bin文件夹下
3. 运行 lr删除注册表.exe 文件
4. 输入注册信息(New License)
1). 首先输入globa-100的注册码:AEACFSJI-YJKJKJJKEJIJD-BCLBR
2). 其次输入web-10000的注册码：AEABEXFR-YTIEKEKJJMFKEKEKWBRAUNQJU-KBYGB 1) lf_file.rar文件
2) 复制替换 lm70.dll、mlr5lprg.dll(位置：lr安装目录下bin目录)
3) 运行 lr删除注册表.exe 文件
4) 输入注册信息(New License)
思考
性能分类、指标、工具我们都以介绍完成，那么性能测试流程或步骤是什么呢？性能测试流程概述
为什么要掌握性能测试流程
1. 功能测试需要按照流程来推进，性能测试也同样，一套完整的测试流程是一次成功性能测试的基石；
2. 【面试】简述下性能测试过程...性能测试步骤
1. 性能测试需求分析
2. 性能测试计划
3. 性能测试用例
4. 测试脚本编写
5. 测试场景设计
6. 测试场景运行
7. 场景运行监控
8. 运行结果分析
9. 系统性能调优
10. 性能测试总结 需求分析
说明：需求分析就是把真正需求搞清楚；
例如：
1). 我们需要贵单位对所有的功能都进行性能测试;
2). 系统用户登录响应时间小于3秒钟;
3). 系统支持20万用户并发访问; 性能测试计划
说明：
1). 性能测试计划是对性能测试的重要过程。
2). 在对需求文档经过认真分析后，作为性能测试管理人员，需要编写的第一份文档就是性能测试计划;
3). 性能测试计划中，需要阐述产品、项目的背景，将前期的需要测试性能需求明确，并落实到文档中。性能测试用例
说明：性能测试需求最终要体现在性能测试用例设计中，性能测试用例应结合用户应用系统的场景，设计出相应的性能
测试用例，用例应能覆盖到测试需求。
提示：
1). 明确那些业务功能使用频繁；
2). 明确系统预期的用户规模、并发用户数、在线用户数；
3). 明确系统业务的处理能力要求，如：TPS、响应时间、系统资源利用率等；
TPS ：(Transaction per second)事务数/秒脚本编写
说明：性能测试用例编写完成以后，接下来就需要结合用例的需要，进行测试脚本的编写工作。
提示：
1). 协议的正确选用;
2). 脚本保证其正确性，去除冗余代码;
3). 注重编码的规范和代码的编写质量；场景设计
说明：测试场景的设计一个重要的原则就是依据测试用例，把测试用例设计的场景展现出来。
提示：
1). 虚拟用户数量及启动虚拟用户方式
2). 场景的相关设置(如：集合点)
3). 脚本是否存在依赖关系(登录与注册)场景运行
说明：测试场景运行是关系到测试结果是否准确的一个重要过程。
注意事项：
1). 负载的测试机不能够运行设定的虚拟用户数；
2). 没有“预热”过程；（预热：先将系统跑一遍）
3). 没有模拟用户的真实环境；
4). 性能用例运行次数过少。场景运行监控
说明：场景运行监控，可以在场景运行时决定要监控那些数据，便于后期分析性能测试结果。
提示：
1). 应用性能测试工具的重要目的就是可以提取到本次测试关心的数据指标内容;
2). 性能测试工具利用应用服务器取得在负载过程中相关计数器的性能指标。
(计数器：计算、统计性能指标的工具)
注意：
1). 负载机的时钟要一致，保证在监控过程中的数据是同步的；
2). 尽量搜集与系统测试目标相关信息，无关内容不必进行监控；
3). 要以管理员的身份登录后运行结果分析
说明：性能测试执行过程中，性能测试工具搜集相关性能测试数据，待执行完成后，这些数据会存储到数据表或者其他
文件中,为了定位系统性能问题，我们需要系统分析这些性能测试结果。
提示：
1). 一般使用“拐点分析”方法，利用性能计数器曲线图上的拐点进行分析的方法。
（基本思想就是性能产生瓶颈的主要原因就是因为某个资源的使用达到了极限，此时表现为随着压力的增大，
系统性能却出现急剧下降，就产生了“拐点”现象。）系统调优
说明：性能测试分析人员经过对结果的分析以后，有可能提出系统存在性能瓶颈。
提示：
1). 调优人员(开发人员、数据库管理员、系统管理员、网络管理员、性能测试分析人员)相关人员对系统进行调整;
2). 验证-性能测试人员继续进行第二轮、第三轮……的测试，与以前的测试结果进行对比，从而确定经过调整以后
系统的性能是否有提升。
注意:
系统调优由易到难的先后顺序如下：
1. 硬件问题；
2. 网络问题；
3. 应用服务器、数据库等配置问题；
4. 源代码、数据库脚本问题；
5. 系统构架问题。