本文转载：https://www.jianshu.com/p/c0cfbc1105af
性能测试的概念
定义：软件的性能是软件的非功能特性，关注的是软件完成功能时展现出来的性能。一般性能测试在系统功能趋于完善且稳定时，才会进行性能测试。
通过工具模拟多种正常、峰值、异常负载条件对系统的各项性能指标进行测试。
性能测试的类型
基准测试：在给系统施加压力时，查看系统运行状况并记录相关数据为参考。
负载测试：对系统不断的增加压力或在一定压力下的持续时间，知道系统达到某项性能指标或多项性能指标达到安全的临界值，不断加压使系统达到瓶颈。
压力测试：
（1）稳定性压力测试：在不同的条件下（内存使用、一定时间段内的多少个请求）系统表现出来的反应、处理能力（会考虑系统的容错能力、恢复能力）
（2）破坏性压力测试：不断的加压、直至系统奔溃、挂掉，得出系统的最大承受能力在哪里
稳定性测试：在一定业务压力负载的条件下，系统运行一段时间，以检测系统是否稳定运行。
并发性测试：在多个用户同时访问同一个页面或模块，检测系统是否存在死锁或性能问题。
失效恢复测试：针对有多余备份和负责均衡的系统设计，检测如果系统局部发生故障，系统能否继续执行。
配置测试：通过对被测系统的软硬件调整，了解各种环境下对系统的最优配置
性能测试应用场景：
性能测试应用领域与测试方法关联
性能测试的常用指标
1、响应时间（Response Time）
定义：从用户发送一个请求到用户接收到服务器返回的响应数据这段时间就是响应时间
计算方法：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为单位；
QPS是查询，而TPS是事务，事务是查询的入口，也包含其他类型的业务场景，因此QPS应该是TPS的子集！
QPS
Query Per Second：每秒查询率，指服务器在单位时间内（秒）处理的查询请求速率；
TPS和QPS都是衡量系统处理能力的重要指标，一般和并发结合起来判断系统的处理能力；
Thinking Time
思考时间，在性能测试中，模拟用户的真实操作场景。用户操作的事务与事务之间是有一定间隔的，此时间内是不对服务器产生压力的，引入这个概念是为了并发测试（有交叉业务场景）时，业务场景比率更符合真实业务场景；
PV
Page View：页面浏览量，通常是衡量一个页面甚至网站流量的重要指标；
细分的话，有独立访问者数量、重复访问者数量、单独页面访问数量、用户停留时间等类型；
RT/ART
Response Time/average Response Time：响应时间/平均响应时间，指一个事务花费多长时间完成；
一般来说，性能测试中平均响应时间更有代表意义。细分的话，还有最小最大响应时间，50%、90%用户响应时间等；
性能测试流程
需求分析
需要分析的系统信息
需要分析的业务信息
性能需求评估
在实施性能测试之前，我们需要对系统做性能的评估，评价是否需要做性能测试。如果需要做性能测试，则需要进一步确定测什么范围、性能指标是什么
确定测试药要点
关键业务
确定被测项目是否属于关键业务，有哪些主要的业务逻辑点，特别是跟交易相关的功能点。例如转账，扣款等接口。如果项目（或功能点）不属于关键业务（或关键业务点）
日请求量
确定被测项目各功能点的日请求量（可以统计不同时间粒度下的请求量如：小时，日，周，月）。如果日请求量很高，系统压力很大，而且又是关键业务，该项目需要做性能测试，而且关键业务点，可以被确定为性能点
逻辑复杂度
判定被测项目各功能点的逻辑复杂度。如果一个主要业务的日请求量不高，但是逻辑很复杂，则也需要通过性能测试。原因是，在分布式方式的调用中，当某一个环节响应较慢，就会影响到其它环节，造成雪崩效应。
运营推广活动
根据运营的推广计划来判定待测系统未来的压力。未雨绸缪、防患于未然、降低运营风险是性能测试的主要目标。被测系统的性能不仅能满足当前压力，更需要满足未来一定时间段内的压力。因此，事先了解运营推广计划，对性能点的制定有很大的作用。例如，运营计划做活动，要求系统每天能支撑多少 PV、多少 UV，或者一个季度后，需要能支撑多大的访问量等等数据。当新项目（或功能点）属于运营重点推广计划范畴之内，则该项目（或功能点）也需要做性能测试。
建立性能指标
a.选取核心业务流程（重要程度/频繁）
b.并发用户数
c.事物吞吐需求
d.响应时间需求
e.系统占用资源需求
f.可扩展性需求
建立系统负载模型
业务层面：核心业务流程吞吐率、高峰期业务分布时段
系统负载：高峰/平常场景负载、CPU/IO/NETWORK
数据来源：服务器监控、数据库日志、用户需求
制定测试计划的时间和方案
预测本次性能测试的起止时间和终止时间。测试环境的配置：局域网、虚拟机、操作系统、数据库、中间件。参与人员：测试人员。产出：测试方案、结论。
搭建测试环境
测试机环境
执行机环境：这个是用来执行负载的机器。
负载工具：JDK/Eclipse/LoadRuner or Jmeter或Galting等
监控工具：准备性能测试时的服务器资源、JVM、数据库监控工具、以便日后进行性能测试分析和调优
服务器环境
系统运行环境：这个通常就是我们的测试环境，Linux系统/数据库/应用服务/各种监控工具。
大部分公司的测试环境会低于生产环境，同时还需要考虑到不同的硬件配置是否会是制约系统性能的重要因素！因此在测试环境中，需要部署多个不同的测试环境，在不同的硬件配置上检查应用系统的性能，配置大概是如下几类：
①数据库服务器
②应用服务器
③负载模拟器
④软件运行环境，
平台并对不同配置下系统的测试结果进行分析，得出最优结果（最适合当前系统的配置）
测试场景设计
通过和业务部门沟通以及以往用户操作习惯，确定用户操作习惯模式，以及不同的场景用户数量，操作次数，确定测试指标，以及性能监控等
性能测试结果分析和调优
瓶颈定位分析：
吞吐量二八法则（80%的业务在20%的时间内完成/正太分布）
响应时间：2/5/10原则
内存、磁盘、I/O、进程、网络分析、硬件、操作系统、中间件、应用瓶颈等，具体情况具体分析。
测试报告和跟踪
性能测试报告是性能测试的里程碑，通过报告能展示出性能测试的最终成果，展示系统性能是否符合需求，是否有性能隐患
