性能测试基础知识
1、基础知识
1.1 并发用户数
定义：N数值的用户同时访问系统。
用于估算并发用户数的公式（仅供参考）
平均用户并发数：C=n*L/T
峰值并发用户数：C›≈C+3√C
其中，C是平均并发数，n是用户从登陆到退出系统的时间段，L是系统使用时间段的平均值，T是使用系统的时间段数值，C›指并发用户数的峰值
对于企业内部使用的web系统，还有精度更小的一种公式
平均用户并发数：C=n/10
峰值用户并发数：C›≈r*C
其中，r值一般取2—3.这种方法要求不太严格，只有很少数据支持分析的性能测试中使用
1.2 吞吐量
定义：单位时间内系统处理客户请求的数量。
对于交互式应用，吞吐量指标反映服务器承受的压力，在容量规划测试中，吞吐量是个很重要的指标，因为它能说明系统级别的负载能力。
Web系统的性能测试中，吞吐量指标可以在两个方面发挥作用
- 协助设计性能测试场景，以及衡量性能测试场景是否达到预期的设计目标
- 协助分析性能瓶颈
没有遇到瓶颈之前，吞吐量和并发用户之间存在的关系可以用下面的公式表达：
F=N（vu）*R/T
F表示吞吐量，N表示VU的个数，R表示每个VU发送的请求（点击）数量，T表示性能测试所用的时间
不同并发用户数量情况下，对同一系统施加相同的吞吐量，很可能得到不同结果
2、性能测试类型
1.1 负载测试
定义：在被测系统上不断增加压力，直到性能指标（如响应时间）超过预期指标或者某种资源使用已经达到饱和状态。可以找到系统的处理极限，为系统调优提供数据。
特点：
- 该方法主要目的是找到系统处理能力的极限
- 该方法在给定的测试环境下进行，通常需要考虑被测系统的业务压力量和典型场景
- 该方法一般用来了解系统的性能容量，或者是配合性能调优来使用
性能容量：系统在保证一定响应时间的情况下能够允许多少并发用户的访问
2.2 压力测试
定义：系统在一定饱和状态下，例如CPU、内存等饱和情况下，系统能够处理的会话能力，以及系统是否会出现错误。
特点：
- 该方法的主要目的是检查系统处于压力情况下应用的性能表现，该方法通过增加访问压力，使系统资源保持在一定水平，检验此时应用的表现，重点在于有无出错信息产生，系统对应用的响应时间等。
- 该方法一般通过模拟负载等方法，使得系统的资源达到较高的水平
2.3 并发测试
定义：模拟多用户并发访问同一个应用、模块或者数据记录时是否存在死锁或者其他性能问题。
特点：
- 该方法主要目的是发现系统中可能存在的并发访问时的问题。
- 该方法主要关注系统中可能存在的并发问题。比如：内存泄漏、线程锁和资源争用等问题。
- 该方法可以在开发的各个阶段使用，需要相关的测试工具的配合和支持。
- 常用工具：商业软件loadrunner：功能完整强大，内存占用大，需要收费。开源工具jmeter：开源免费，自由，操作较简单，能辅助完成日常的一些测试工作
2.4 可靠性测试
定义：给系统施加一定的业务压力，让其持续运行一段时间，测试系统能否稳定运行。
特点：
- 该方法的主要目的是验证系统是否支持长期稳定的运行。
- 该方法需要在压力下持续一段时间的运行。
- 测试过程中需要关注系统的运行情况，比如：内存使用或者其他资源的使用以及响应时间有无明显变化
3、常用术语
3.1 负载
对被测系统不断施加压力，直到性能指标超过预期或某项资源使用达到饱和，以验证系统的处理极限，为系统性能调优提供依据。
3.2 并发
狭义上的并发：所有用户在同一时间点进行同样的操作，一般指同一类型的业务场景，比如1000个用户同时登陆系统；
广义上的并发：多个用户与系统发生了交互，这些业务场景可以是相同的也可以是不同的，交叉请求和处理较多；
3.3 压力
系统在一定饱和状态下，例如CPU、内存等饱和情况下，系统能够处理的会话能力，以及系统是否会出现错误。
特点：主要目的是检查系统处于压力情况下应用的性能表现，重点在于有无出错信息产生，系统对应用的响应时间等
3.4 事务
性能测试中，事务指的是从端到端，一个完整的操作过程，比如一次登录、一次筛选条件查询，一次支付等。
3.5 吞吐量
指在一次性能测试过程中网络上传输的数据量的总和，也可以这样说在单次业务中，客户端与服务器端进行的数据交互总量；
对交互式应用来说，吞吐量指标反映服务器承受的压力，容量规划的测试中，吞吐量是重点关注的指标，它能够说明系统级别的负载能力，另外，在性能调优过程中，吞吐量指标也有重要的价值；
吞吐量和负载之间的关系：
- 上升阶段：吞吐量随着负载的增加而增加，吞吐量和负载成正比；
- 平稳阶段：吞吐量随着负载的增加而保持稳定，无太大变化或波动；
- 下降阶段：吞吐量随着负载的增加而下降，吞吐量和负载成反比；
如下图所示：
a1面积越大，说明系统的性能能力越强；a2面积越大，说明系统稳定性越好；a3面积越大，说明系统的容错能力越好。
3.6 吞吐率
吞吐量/传输时间，即单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量，它是衡量网络性能的重要指标。
通常情况下，吞吐率用“字节数/秒”来衡量，当然，也可以用“请求数/秒”和“页面数/秒”来衡量；
3.7 TPS
Transaction Per Second：每秒事务数，指服务器在单位时间内（秒）可以处理的事务数量，一般以request/second为单位；
PS：看到很多博客或性能测试人员将QPS和TPS混为一谈，个人认为，他们是以测试结果的统计得到该结论的；
QPS是查询，而TPS是事务，事务是查询的入口，也包含其他类型的业务场景，因此QPS应该是TPS的子集！
3.8 QPS
Query Per Second：每秒查询率，指服务器在单位时间内（秒）处理的查询请求速率；
PS：TPS和QPS都是衡量系统处理能力的重要指标，一般和并发结合起来判断系统的处理能力；
3.9 PV
Page View：页面浏览量，通常是衡量一个页面甚至网站流量的重要指标；
细分的话，有独立访问者数量、重复访问者数量、单独页面访问数量、用户停留时间等类型；
3.10 RT/ART
Response Time/average Response Time：响应时间/平均响应时间，指一个事务花费多长时间完成；
一般来说，性能测试中平均响应时间更有代表意义。细分的话，还有最小最大响应时间、平均响应、90%响应时间、95%响应时间等；
注意：90%（或者 95%，99%）响应时间不是一个平均值，而是排序后一个点的值。比如：响应时间分布为：1,2,1,2,1,1,1,2,1,90，那90%的响应时间为2。
通过 平均响应时间、90%、95%、99%的响应时间，可以大概看出系统的偏差率。
关于稳定性，比如有两组响应时间数据 3,4,7,9,10 平均值 6.6，6.3，6.4, 6.6, 6.8, 6.9 平均值也是 6.6，但是通过方差和标准差分析出实际上后面的系统肯定更稳定些，前面大概方差是 7 左右，标准差 2.x，后面 0.2 左右，标准差差不多 0.4 左右，波动小。也可通过响应时间表的打点离散分布情况分析系统的稳定性。
3.11 资源使用率
如下图所示，资源指标与硬件资源消耗直接相关，而系统指标则与用户场景及需求直接相关：
3.12 资源指标
CPU使用率：指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%；
内存利用率：内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%；
磁盘I/O: 磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用% Disk Time（磁盘用于读写操作所占用的时间百分比）度量磁盘读写性能；
网络带宽：一般使用计数器Bytes Total/sec来度量，其表示为发送和接收字节的速率，包括帧字符在内；判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较；
3.13 系统指标
并发用户数：单位时间内与系统发生交互的用户数；
在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求；
平均响应时间：系统处理事务的响应时间的平均值；事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间；
事务成功率：性能测试中，定义事务用于度量一个或者多个业务流程的性能指标，如用户登录、保存订单、提交订单操作均可定义为事务，单位时间内系统可以成功完成多少个定义的事务， 在一定程度上反应了系统的处理能力，一般以事务成功率来度量；
超时错误率：主要指事务由于超时或系统内部其它错误导致失败占总事务的比率；
4、性能测试流程
大体来说，性能测试的流程可分为如上四个阶段，分别是需求阶段、准备阶段、实施阶段以及结束。
4.1 需求阶段
①、提出需求
性能测试一定是先有需求，才可以决定要不要继续执行。而性能需求的提出方，可以是开发（觉得某个接口慢）、可以是运维（对某个系统的服务能力进行容量评估）；
也可以是测试人员（从需求评审中分析出某个需求需要进行性能测试来规避风险）、更可以是产品（线上问题直接表现&用户反馈）。
②、需求评审
不经过评审的需求往往有很多坑！！！只有相关人员参与评审，从各自的角度给出意见，沟通达成一致，才能决定后续的要不要做？怎么做？以及谁来做什么事情！
③、测试方案编写与评审
根据已确认需求，编写测试方案，并邀请相关人员参与评审，大家对方案无异议，后续可依据方案开展测试工作。
4.2 准备阶段
①、环境准备
无论是功能测试还是自动化或者性能测试，总是需要一个合适的环境来进行。
对性能测试来说，无论是环境选择（生产or性能测试环境）还是申请对应的资源（虚拟机&云服务器&docker），一般都需要运维工程师来进行搭建配置。
②、应用部署
性能测试的被测应用必须是稳定的，没有P2及以上缺陷或通过回归测试的版本包，根据每个公司的职责定位不同，应用部署一般是开发进行部署，或开发提供对应的代码路径，运维进行拉取部署。
③、数据准备
性能测试对数据的要求是很高的，无论是数据量级、精准度抑或是数据的多样性。一般分为如下几种数据类型：
铺底数据：最常见的准备方式为从生产拖库最新的最完整的基础数据来作为性能测试所用；
测试数据：比如性能测试场景需要读写大量的数据，而为了保证测试结果的准确性，一般通过从生产拉取同等量级或者至少未来一年的增长量级的脱敏数据；
参数化数据：不同类型的数据处理逻辑有差异时，需要通过测试数据的多样化来提高性能测试代码的覆盖率，而参数化是最常见的方式；
④、脚本开发
性能测试脚本需要针对业务模型转化后的测试模型以及采用的测试策略进行针对性的开发调试试运行。
4.3 实施阶段
完成准备阶段的工作，就开始开展性能压测了（有时候需要进行压测预热），这也是很多对性能测试不太了解的同学对性能测试的认知（录制脚本→无脑高并发）。
①、压测执行
性能测试执行阶段，是需要执行很多轮次，且测试脚本也需要不断地调整修改，根据测试结果不断改进的，这样才能得到更为准确的测试结果。
②、服务监控
这个阶段称之为APM（Application Performance Management：对应用程序性能和可用性的监控管理）更合适。
狭义上的APM单指应用程序的监控，如应用的各接口性能和错误监控，分布式调用链路跟踪，以及其他各类用于诊断(内存，线程等)的监控信息等。
广义上的APM, 除了应用层的监控意外，还包括App端监控、页面端监控、容器、服务器监控，以及其他平台组件如中间件容器、数据库等层面的监控。
③、瓶颈定位
进行性能测试的目的，就是为了探测系统是否存在影响提供正常服务的性能瓶颈以及为上线提供容量评估。
如果系统性能表现未到达预期指标，则需要对日志、监控数据进行分析，定位其性能瓶颈并针对性的进行优化才可以。
④、优化验证
发现性能瓶颈并修改优化后，需要再次执行压测，以验证问题是否得到解决以及性能的提升能力，衡量的标准是需求评审和调研阶段确定的业务性能指标。
4.4 结束阶段
性能测试结束的标志，一般包括如下如下几点：
涉及的测试场景均已测试完毕、测试过程中发现的问题已全部修复验证、测试结果达到了预期的性能指标、满足上线要求。
①、测试报告
在满足上面4个条件后，最好是出具一份简洁但是明确的测试报告，说明本次性能测试的目的、范围、环境信息、测试结果、问题，并给出测试结论。
测试报告的方式可以是文档、邮件、一个HTML页面等方式，但这个环节一定不能省略！！！
②、报告评审
最好是让参与本次性能测试各环节工作的各个角色都参与进行评审，大家对结果无异议，即可视为本次性能测试结束。
以上即为性能测试从零开始实施的个人总结，如有更好的建议，请及时指出，内容仅供参考。。。
转载：
性能测试基础知识：https://www.cnblogs.com/imyalost/p/5640818.html
性能测试类型：https://www.cnblogs.com/imyalost/p/5653342.html
性能测试常见术语浅析：https://www.cnblogs.com/imyalost/p/7117320.html
性能测试从零开始实施指南——测试流程篇：https://www.cnblogs.com/imyalost/p/10753280.html
