性能测试的概念
定义：软件的性能是软件的⼀种⾮功能特性，它关注的不是软件是否能够完成特定的功能，⽽是在完成该功能时展⽰出来的及时性。
由定义可知性能关注的是软件的⾮功能特性，所以⼀般来说性能测试介⼊的时机是在功能测试完成之后。在系统基础功能测试验证完成、系统趋于稳定的情况下，才会进⾏性能测试，否则性能测试是⽆意义的。另外，由定义中的及时性可知性能也是⼀种指标，可以⽤时间或其它指标来衡量，通常我们会使⽤某些⼯具或⼿段来检测软件的某些指标是否达到了要求，这就是性能测试。 性能测试定义：指通过⾃动化的测试⼯具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进⾏测试。
性能测试类型
基准测试：在给系统施加较低压⼒时，查看系统的运⾏状况并记录相关数做为基础参考
负载测试：是指对系统不断地增加压⼒或增加⼀定压⼒下的持续时间，直到-
平移天窗系统的某项或多项性能指标达到安全临界值，不断加压使系统达到瓶颈，为调优提供参考数据。
压⼒测试：
（1）稳定性压⼒测试：在不同的给定的条件下（⽐如内存的使⽤，⼀定时间段内有多少请求等），系统表现出来的处理，
反应能⼒（这⾥会考虑系统的容错能⼒，恢复能⼒）
（2）破坏性压⼒测试：不断加压，直⾄系统崩溃，挂掉，来得出系统的最⼤承受能⼒在哪⼉
稳定性测试：在给系统加载⼀定业务压⼒的情况下，使系统运⾏⼀段时间，以此检测系统是否稳定。
并发测试：测试多个⽤户同时访问同⼀个应⽤、同⼀个模块或者数据记录时是否存在死锁或者其他性能问题，
失效恢复测试：针对有多余备份和负载均衡的系统设计，检测如果系统局部发⽣故障，系统能否继续使⽤
配置测试：通过对被测系统软硬件环境的调整，了解各种不同环境对系统性能影响的程度，从⽽到系统各项资源的最优
分配原则
image.png
性能测试应⽤场景（领域）
性能测试应⽤场景（领域）主要有：
能⼒验证、规划能⼒、性能调优、缺陷发现、性能基准⽐较，
下表简单介绍和对⽐了这⼏个场景的各⾃⽤途和特点：
image.png
eeg平台
下表为性能测试应⽤领域与测试⽅法关联：
image.png
性能测试常⽤的指标
定义：从⽤户发送⼀个请求到⽤户接收到服务器返回的响应数据这段时间就是响应时间
计算⽅法：Response time = （⽹络时间 + 应⽤程序处理时间）
合理的响应时间 2/5/10 （2秒之内给客户响应被⽤户认为是⾮常有吸引⼒的，5秒之内，⽐较糟糕，10秒之内，糟糕的⽤户体验，超过10秒，请求失败）
响应时间-负载对应关系：
image.png
图中拐点说明：
1、响应时间突然增加
2、意味着系统的⼀种或多种资源利⽤达到的极限
3、通常可以利⽤拐点来进⾏性能测试分析与定位
2、吞吐量
定义：单位时间内系统处理的客户端请求的数量
计算⽅法：Throughput = (number of requests) / (total time)
吞吐量-负载对应关系：
①上升阶段：吞吐量随着负载的增加⽽增加，吞吐量和负载成正⽐；
②平稳阶段：吞吐量随着负载的增加⽽保持稳定，⽆太⼤变化或波动；
③下降阶段：吞吐量随着负载的增加⽽下降，吞吐量和负载成反⽐；
image.png
a1⾯积越⼤，说明系统的性能能⼒越强，a2⾯积越⼤，说明系统稳定性越好，a3⾯积越⼤，说明系统的容错能⼒越好
吞吐率
吞吐量/传输时间，即单位时间内⽹络上传输的数据量，也可以指单位时间内处理客户请求数量，它是衡量⽹络性能的重要指标。
通常情况下，吞吐率⽤“字节数/秒”来衡量，当然，也可以⽤“请求数/秒”和“页⾯数/秒”来衡量；
3、并发数
①狭义上的并发：所有⽤户在同⼀时间点进⾏同样的操作，⼀般指同⼀类型的业务场景，⽐如1000个⽤户同时登陆系统；
②⼴义上的并发：多个⽤户与系统发⽣了交互，这些业务场景可以是相同的也可以是不同的，交叉请求和处理较多；
4、资源利⽤率
资源指标与硬件资源消耗直接相关，⽽系统指标则与⽤户场景及需求直接相关：
image.png
资源指标：
CPU使⽤率：指⽤户进程与系统进程消耗的CPU时间百分⽐，长时间情况下，⼀般可接受上限不超过85%；
内存利⽤率：内存利⽤率=（1-空闲内存/总内存⼤⼩）*100%，⼀般⾄少有10%可⽤内存，内存使⽤率可接受上限为85%；
磁盘I/O: 磁盘主要⽤于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，⼀般使⽤% Disk Time（磁盘⽤于读写操作所占⽤的时间百分⽐）度量磁盘读写性能；
⽹络带宽：⼀般使⽤计数器Bytes Total/sec来度量，其表⽰为发送和接收字节的速率，包括帧字符在内；判断⽹络连接速度是否是瓶颈，可以⽤该计数器的值和⽬前⽹络的带宽⽐较；
系统指标：
并发⽤户数：单位时间内与系统发⽣交互的⽤户数；
在线⽤户数：某段时间内访问系统的⽤户数，这些⽤户并不⼀定同时向系统提交请求；
平均响应时间：系统处理事务的响应时间的平均值；事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间；
事务成功率：性能测试中，定义事务⽤于度量⼀个或者多个业务流程的性能指标，如⽤户登录、保存订单、提交订单操作均可定义为事务，单位时间内系统可以成功完成多少个定义的事务，在⼀定程度上反应了系统的处理能⼒，⼀般以事务成功率来度量；
超时错误率：主要指事务由于超时或系统内部其它错误导致失败占总事务的⽐率；
资源利⽤-负载对应关系：
image.png
图中拐点说明：
1、服务器某件资源使⽤逐渐达到饱和
2、通常可以利⽤拐点来进⾏性能测试分析与定位
5、其它常⽤概念：
TPS
Transaction Per Second：每秒事务数，指服务器在单位时间内（秒）可以处理的事务数量，⼀般以request/second为单位；
gpu虚拟化QPS是查询，⽽TPS是事务，事务是查询的⼊⼝，也包含其他类型的业务场景，因此QPS应该是TPS的⼦集！
QPS
Query Per Second：每秒查询率，指服务器在单位时间内（秒）处理的查询请求速率；
TPS和QPS都是衡量系统处理能⼒的重要指标，⼀般和并发结合起来判断系统的处理能⼒；
Thinking Time
思考时间，在性能测试中，模拟⽤户的真实操作场景。⽤户操作的事务与事务之间是有⼀定间隔的，此时间内是不对服务器产⽣压⼒的，引⼊这个概念是为了并发测试（有交叉业务场景）时，业务场景⽐率更符合真实业务场景；
PV
Page View：页⾯浏览量，通常是衡量⼀个页⾯甚⾄⽹站流量的重要指标；
细分的话，有独⽴访问者数量、重复访问者数量、单独页⾯访问数量、⽤户停留时间等类型；
RT/ART
Response Time/average Response Time：响应时间/平均响应时间，指⼀个事务花费多长时间完成；
⼀般来说，性能测试中平均响应时间更有代表意义。细分的话，还有最⼩最⼤响应时间，50%、90%
⽤户响应时间等；
性能测试流程
需求分析
需要分析的系统信息
image.png
需要分析的业务信息
image.png
翻罐笼性能需求评估
在实施性能测试之前，我们需要对被测系统做相应的评估，主要⽬的是明确是否需要做性能测试。如果确定需要做性能测试，需要进⼀步确⽴性能测试点和指标，明确该测什么、性能指标是多少，测试通过or不通过的标准？性能指标也会根据情况评估，要求被测系统能满⾜将来⼀定时间段的业务压⼒。
业务⾓度:
系统是公司内部 or 对外？系统使⽤的⼈数的多少？
系统⾓度：
a）系统架构：b）数据库要求：c）系统特殊要求：
确定性能测试点：
关键业务：
确定被测项⽬是否属于关键业务，有哪些主要的业务逻辑点，特别是跟交易相关的功能点。例如转账，扣款等接⼝。如果项⽬（或功能点）不属于关键业务（或关键业务点）
⽇请求量：
确定被测项⽬各功能点的⽇请求量（可以统计不同时间粒度下的请求量如：⼩时，⽇，周，⽉）。如果⽇请求量很⾼，系统压⼒很⼤，⽽且⼜是关键业务，该项⽬需要做性能测试，⽽且关键业务点，可以被确定为性能点
逻辑复杂度：
判定被测项⽬各功能点的逻辑复杂度。如果⼀个主要业务的⽇请求量不⾼，但是逻辑很复杂，则也需要通过性能测试。原因是，在分布式⽅式的调⽤中，当某⼀个环节响应较慢，就会影响到其它环节，造成雪崩效应。
运营推⼴活动：
根据运营的推⼴计划来判定待测系统未来的压⼒。未⾬绸缪、防患于未然、降低运营风险是性能测试的主要⽬标。被测系统的性能不仅能满⾜当前压⼒，更需要满⾜未来⼀定时间段内的压⼒。因此，事先了解运营推⼴计划，对性能点的制定有很⼤的作⽤。例如，运营计划做活动，要求系统每天能⽀撑多少 PV、多少 UV，或者⼀个季度后，需要能⽀撑多⼤的访问量等等数据。当新项⽬（或功能点）属于运营重点推⼴计划范畴之内，则该项⽬（或功能点）也需要做性能测试。
建⽴性能指标
a.选取核⼼业务流程（重要程度/频繁）
b.并发⽤户数
c.事物吞吐需求
d.响应时间需求
e.系统占⽤资源需求
f.可扩展性需求
建⽴系统负载模型
业务层⾯：
（a）核⼼业务流程吞吐率
（b）⾼峰期业务分布时段
系统负载：
（a）⾼峰/平常场景吞吐率
（b）CPU/IO/MEM/NETWORK
牙模
数据来源：
（a）服务器端监控
（b）数据库⽇志
（c）⽤户提出需求
制定测试计划的实施时间和⽅案
预设本次性能测试各⼦模块的起⽌时间和结束时间
测试环境的配置：局域⽹，虚拟机，操纵系统，数据库，中间件
参与⼈员：谁负责哪些任务，测试策略。
产出：测试⽅案，分析结果
搭建测试环境
测试机环境
执⾏机环境：这个就是⽤来⽣成负载的执⾏机，通常需要在物理机上运⾏。
负载⼯具：JDK/Eclipse/LoadRuner or Jmeter或Galting等
监控⼯具：准备性能测试时的服务器资源、JVM、数据库监控⼯具，以便进⾏后续的性能测试分析与调优
服务器环境
系统运⾏环境：这个通常就是我们的测试环境，Linux系统/数据库/应⽤服务/各种监控⼯具。
⼤部分公司的测试环境会低于⽣产环境，同时还需要考虑到不同的硬件配置是否会是制约系统性能的重要因素！因此在测试环境中，需要部署多个不同的测试环境，在不同的硬件配置上检查应⽤系统的性能，配置⼤概是如下⼏类：
①数据库服务器
②应⽤服务器
③负载模拟器
④软件运⾏环境，
平台并对不同配置下系统的测试结果进⾏分析，得出最优结果（最适合当前系统的配置）
测试场景设计
通过和业务部门沟通以及以往⽤户操作习惯，确定⽤户操作习惯模式，以及不同的场景⽤户数量，操作次数，确定测试指标，以及性能监控等
测试⽤例设计和脚本开发
选择LoadRuner或者Jmeter，我使⽤的是Jmeter。
我使⽤Jmeter的⼯具进⾏录制，
(PS：能直接写脚本就⾃⼰写尽量少录制，录制有时候会有⼲扰)
对脚本进⾏修改，增强脚本，让脚本更符合业务逻辑，可⽤性更强。
（1）参数化⽤户输⼊
（2）关联数据
（3）增加事物
（4增加检查点）
调试脚本
（1）Vugen单次回放
（2）Vugen多次回放
（3）Controller单脚本多⽤户
（4）Controller多脚本多⽤户
（5）查看回放⽇志
验证脚本
（1）通过检查点验证
（2）通过查看后台服务器⽇志验证
（3）通过测试系统查看运⾏后台变化
（4）利⽤SQL语句查询/插⼊/更新/修改，查看效果
测试数据准备
获取数据有两种⽅式：
（1）拉取⽣产数据，尽量保持数据⼀致以及量级⾜够
（2）利⽤脚本⾃动⽣成数据或者利⽤测试⼯具⽣成数据，（如：利⽤JDBC预埋数据）
a）负载测试数据：并发测试时需要多少数据？⽐如登录场景？
b）DB数据量⼤⼩：为了尽量符合⽣产场景，需要模拟线上⼤量数据情况，那么要往数据库⾥提前插⼊⼀定的数据量。
刮膜棒
性能测试执⾏和管理
执⾏测试脚本
在已部署好的测试环境中，按照业务场景和编号，按顺序执⾏我们已经设计好的测试脚本
测试结果记录
根据测试采⽤的⼯具不同，结果的记录也有不同的形式；展现⽅式：折线图，统计图，表格等，现在⼤多的性能测试⼯具都提供⽐较完整的界⾯图形化的测试结果，当然，对于服务器的资源使⽤等情况，可以利⽤⼀些计数器或第三⽅监控⼯具来对其进⾏记录，执⾏完测试后，对结果进⾏整理分析，
image.png
性能测试结果分析与调优
测试环境的系统性能分析
根据之前记录得到的测试结果，经过计算，与预定的性能指标进⾏对⽐，确定是否达到了我们需要的结果；如未达到，查看具体的瓶颈点，然后根据瓶颈点的具体数据，
瓶颈定位分析
吞吐量：⼆⼋原则（即：80%的业务在20%的时间内完成/正太分布）
响应时间：2/5/10原则
内存，磁盘，IO，进程，⽹络分析
硬件，操作系统，中间件，应⽤瓶颈
进⾏具体情况具体分析
性能调优
时间资源，⼈⼒资源
硬件资源，扩展性，影响
硬件设备对系统性能表现的影响分析
配置⼏个不同的测试环境，故可以根据不同测试环境的硬件资源使⽤状况图进⾏分析，确定瓶颈是再数据库服务器、应⽤服务器抑或其他⽅⾯，然后针对性的进⾏优化等操作
其他影响因素分析
影响系统性能的因素很多，可以从⽤户能感受到的场景分析，哪⾥⽐较慢，哪⾥速度尚可，这⾥可以根据2\5\8原则对其进⾏分析；
⾄于其他诸如⽹络带宽、操作动作、存储池、线程实现、服务器处理机制等⼀系列的影响因素，具体
问题具体分析，
测试中发现的问题
在性能测试执⾏过程中，可能会发现某些功能上的不⾜或存在的缺陷，以及需要优化的地⽅，需要多次执⾏测试。
测试报告和跟踪
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议