性能测试基础知识
目录
第一章 性能测试类型
1.1 基准测试
1.2 负载测试
1.3 压力测试
1.3.1 稳定性压力测试（可靠性测试）
1.3.2 破坏性压力测试
1.4 Spike测试
1.5 并发测试
1.6 失效恢复测试
第二章 性能指标
2.1 业务指标
2.2 资源指标
2.3 应用指标
2.4 前端指标
第三章 性能测试流程
3.1 需求阶段
3.1.1提出需求
3.1.2需求评审
3.1.3需求调研
3.2 准备阶段
3.2.1 环境准备
3.2.2 应用部署
3.2.3 数据准备
3.2.4 脚本开发
3.3 实施阶段
3.3.1 压测执行
3.3.2 服务监控
3.3.3 瓶颈定位
3.3.4 优化验证
3.4 结束阶段
3.4.1 测试报告
3.4.2 报告评审
第四章 监控
4.1目的
4.2 参数
第五章 关于我们目前
第一章 性能测试类型
性能测试类型主要分为：基准测试、负载测试、压力测试、稳定性压力测试（可靠性测试）、破坏性压力测试、Spike测试、并发测试、失效恢复测试，每种测试类型针对不同的目的，可以根据生产系统实际情况进行选择，基准测试和稳定性测试一般情况必须做
1.1 基准测试
1.1.1 概念
1) 每次对外发布产品版本前必须要完成的测试类型
2) 执行固定的性能测试场景得到系统的性能测试报告
3) 与上一版本发布时的基准测试结果进行对比，优化 or 恶化 ?
1.1.2 测试目的
1) 获取系统性能基准作为参照物
2) 识别系统或环境的配置变更对性能带来的影响
3) 给系统优化前后的性能提升/下降提供参考标准
4) 观察系统的整体性能趋势与性能拐点，识别系统性能风险
1.2 负载测试
1.2.1测试目的
1) 持续稳定地增加系统的负载，测试系统性能的变化
2) 找出指标阈值下的系统瓶颈和性能拐点
3) 测试系统所能承受的最大负载量
4) 找出内存管理错误，内存泄漏，缓冲区溢出的问题
5) 找到处理极限，为调优提供数据
6) 找出系统在稳定情况下的最大压力值
1.2.2测试意义
通过改变负载方式、增加负载，发现系统中所存在的性能问题
1.3 压力测试
测试目的
1) 测试系统的资源在饱和状态下的应用的处理会话能力
2) 持续稳定的增加系统压力，测试系统性能的变化
3) 破坏性测试，确保系统失败并能正常恢复
4) 发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患
5) 关注大业务下系统的长时间运行状态（例如反应变慢、内存泄漏、系统崩溃、失效 恢复）
6) 找出系统在可控错误率下的最大压力值
1.3.1 稳定性压力测试（可靠性测试）
(1)长时间运行（7*24 小时）模拟被测系统的测试负载
(2)观察系统在长期运行过程中是否有潜在的问题
(3)对系统指标进行监控,发现长期运行时的内存泄漏、资源非法占用等问题
1.3.2 破坏性压力测试
1)不断加压，直至系统崩溃
2)测试系统的最大承受能力
3)通过破坏性加压的手段，快速造成系统的崩溃或让问题明显的暴露出来
1.4 Spike测试
尖峰测试（Spike testing）在性能测试中属于压力测试的一个子集。指的是在某一瞬间或者多个频次下用户数和压力陡然增加的场景。为了验证我们的网站在访问用户急剧增加的情况下，或者短时间内反复急剧增加工作负载时能否正常工作；以及程序能否从高负荷中恢复并正常工作时常常用到这种测试手法。Spike 在英文中是钉子的意思，或者我们可以将其称之为冲击测试，反复冲击服务器。
常见场景
12306 开始售票时访问用户急剧增加
网站公布高考成绩、录取分数时，访问用户急剧增加
网站投放商业促销广告和促销活动，如双 11 和 618 等活动开始时，访问用户急剧增加等等。。。。
1.5 并发测试
在高并发情况下验证单一业务的功能正确性以及性能问题
使用思考时间为零的虚拟用户来发起具有“集合点”的测试
用于发现诸如线程死锁、资源竞争、资源死锁之类的错误
1.6 失效恢复测试
针对有多余备份和负载均衡的系统设计
定义：检测如果系统局部发生故障，系统能否继续使用
特点：
1）该方法主要目的是验证局部故障下系统能否继续使用
2）该方法需要指出：问题发生时“能支持多少用户访问”和“采取何种应急措施”
一般只有对系统持续运行能力有明确指标的系统才需要该类型测试
第二章 性能指标
2.1 业务指标
Error：应用层的指标优先关注”error”，也就是错误率。反过来说就是要优先保证“正确率”。但是错误率的准入标准可以适当的放宽。但是涉及到金融的项目，错误率一定会被严格控制，甚至于不会允许有错误出现。
RPS： RPS 全称是 request persecond(每秒请求数)，它描述了施压引擎向服务器实际发出 的压力大小。
TPS: TPS 全称是 transaction persecond(每秒处理完成的请求数), TPS反应的其实是cpu 的处理能力。但是 cpu 的处理能力是有上限的，也就是我们说的性能瓶颈点。因此我们做压力测试就是通过设计 RPS（压力值）施压服务器，来找到 tps 的瓶颈点。
一般参考：中小型企业50-1000笔/秒，银行1000-50000笔/秒，淘宝30000-300000笔/秒
平均响应时间：系统处理事务的响应时间的平均值；事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间。
并发用户数：单位时间内与系统发生交互的用户数。
2.2 资源指标
CPU使用率：指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%；
内存利用率：内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%；
磁盘I/O: 磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用% Disk Time（磁盘用于读写操作所占用的时间百分比）度量磁盘读写性能；
网络带宽：一般使用计数器Bytes Total/sec来度量，其表示为发送和接收字节的速率，包括帧字符在内；判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较；
2.3 应用指标
空闲线程数、数据库连接数、函数耗时等
2.4 前端指标
页面加载时间、网络时间（连接时间、传输时间等）
第三章 性能测试流程
按照业内目前的最佳实践，精简后的性能测试流程以及对应阶段的岗位职责，如下图：
3.1 需求阶段
3.1.1提出需求
1、有效的性能需求：
1) 明确的数据
2) 有凭有据，合理，有实际意义
3) 相关人员达成一致
2、如何获取有效的性能需求：
1) 客户方提出
2) 跟进历史数据来分析
3) 参考历史项目的数据
4) 参考其他类似行业应用的数据
5) 参考新闻或其他资料的数据
3、需求内容信息：
项目名称（立项留档、提高重视）
测试背景（为什么？充足的理由）
测试目的（容量评估、调优验证）
测试范围（什么业务？对应服务）
接口文档（哪些接口？对应地址）
调用关系（业务/系统/关系拓扑）
关键参数（线程池/连接数/JVM）
预期指标（性能指标、资源指标）
数据量级（线上数据、访问频次）
4、关于需求搜索的一些资料，仅供参考
业务选取：
系统中有很多业务，每种业务逻辑和业务量是不一样的，消耗的系统资源也不一样，因此业务种类、业务占比决定了系统的处理能力。
业务模型中的业务和占比选取不对，跟生产差异非常大，直接导致测试结果没有任何参考价值，并且容易误导对系统处理能力的判断，有些业务的业务量虽然占比很低，但一旦突变，对系统也是致命的。
所以系统中的典型业务选取一般情况下遵循的规则是选取业务量高的、经常使用的、有风险的、未来有增长趋势的业务作为系统的典型业务，已经上线的系统可以通过高峰时段历史业务量和生产问题性能来评估，对于即将上线的系统可以通过调研和单交易资源消耗的结果来评估
数据量：
数据量主要包括基础数据量（或者叫历史数据量、垫底数据量、数据库中已有的数据量）和参数化数据量，对于数据库中只有几条记录和有几亿记录里面查询，结果肯定相差非常大。
输入数据量不太同一数量级上，将会导致相关指标不真实，甚至导致测试结果没参考意义，如果参数化数据量过少，未考虑数据分布的情况的，测试结果会不太真实，没有参考意义，需要考虑数据准备的完整性，还有清理的逻辑需要完整。
如果测试环境和生产环境在同一数据量级上，那需要考虑未来三年的数据量增长趋势，如果增长过快需要在测试环境造非常多的数据；参数化数据量尽可能的多，参数化数据分布，如果业务有明显的地域分布特征，需要考虑数据分布的情况
测试结果中各业务TPS占比需跟生产上业务占比（业务模型）相一致，可以使用PTS特有的RPS模式（Request Per Second，直接测试吞吐能力）来保证一致。 例如：A和B两笔业务，占比为1：4，响应时间分别为1ms、100ms，那么只需要通过PTS给A和B两个接口按照1：4比例设置请求数（TPS）施压即可。如果使用传统的并发模式，A和B的并发需要经过换算确保比例是1：400，使得最终与生产上保持一致的业务模型
3.1.2需求评审
需要多方相关人员参与评审，从各自的角度给出意见，沟通达成一致，决定后续的要不要做？怎么做？以及谁来做什么事情！
3.1.3需求调研
需求调研阶段主要是对后续性能测试实施的一些必要信息进行更细致的沟通和确认，以及在职责、工时、排期、交付时间这几点上寻求平衡的可接受的点，并在各项信息确定后输入测试计划文档。
3.2 准备阶段
3.2.1 环境准备
压测环境需要尽量和生产环境配置一致，且尽量有一套独立的压测环境。当测试环境与实际生产环境差异较大时，性能测试结果往往不被接受，如果在性能测试实施过程中，无法搭建相对真实的测试环境，即可认为被测对象不具备性能的可测性。
测试环境搭建：
1) 测试环境与线上环境架构要相同
2) 机型尽量相同，云化的资源确保是同规格ECS或者容器
3) 软件版本相同：操作系统、中间件相关、数据库、应用等
4) 参数配置相同：操作系统参数、中间件参数、数据库参数、应用参数
5) 数据量需要在同一数量级上
6) 测试环境机器台数需要同比例缩小，而不能只减少某一层的机器台数
7) 测试环境等比配置是生产环境的1/2 、1/4
测试环境调研：
1) 系统架构：系统如何组成的，每一层功能是做什么的，与生产环境有多大差异，主 要为后面进行瓶颈分析服务和生产环境性能评估，这个很重要
2) 操作系统平台：操作系统是哪种平台，进行工具监控
3) 中间件：哪种中间件，进行工具监控和瓶颈定位
4) 数据库：哪种数据库，进行工具监控和瓶颈定位
5) 应用：启动多少个实例，启动参数是多少，进行问题查找和瓶颈定位
6) 可以配合APM工具进行中间件、数据库、应用层面的问题定位
3.2.2 应用部署
性能测试的被测应用必须是稳定的，需要是没有P2及以上缺陷或通过回归测试的版本包
3.2.3 数据准备
性能测试对数据的要求是很高的，无论是数据量级、精准度抑或是数据的多样性。一般分为如下几种数据类型：
铺底数据：最常见的准备方式为从生产拖库最新的最完整的基础数据来作为性能测试所用；
测试数据：比如性能测试场景需要读写大量的数据，而为了保证测试结果的准确性，一般通过从生产拉取同等量级或者至少未来一年的增长量级的脱敏数据；
参数化数据：不同类型的数据处理逻辑有差异时，需要通过测试数据的多样化来提高性能测试代码的覆盖率，而参数化是最常见的方式；
3.2.4 脚本开发
性能测试脚本需要针对业务模型转化后的测试模型以及采用的测试策略进行针对性的开发调试试运行。
3.3 实施阶段
3.3.1 压测执行
性能测试执行阶段，是需要执行很多轮次，且测试脚本也需要不断地调整修改，根据测试结果不断改进的，这样才能得到更为准确的测试结果。
3.3.2 服务监控
这个阶段称之为APM（Application Performance Management：对应用程序性能和可用性的监控管理）更合适。
狭义上的APM单指应用程序的监控，如应用的各接口性能和错误监控，分布式调用链路跟踪，以及其他各类用于诊断(内存，线程等)的监控信息等。
广义上的APM, 除了应用层的监控意外，还包括App端监控、页面端监控、容器、服务器监控，以及其他平台组件如中间件容器、数据库等层面的监控。
3.3.3 瓶颈定位
进行性能测试的目的，就是为了探测系统是否存在影响提供正常服务的性能瓶颈以及为上线提供容量评估。
如果系统性能表现未到达预期指标，则需要对日志、监控数据进行分析，定位其性能瓶颈并针对性的进行优化才可以。
3.3.4 优化验证
发现性能瓶颈并修改优化后，需要再次执行压测，以验证问题是否得到解决以及性能的提升能力，衡量的标准是需求评审和调研阶段确定的业务性能指标。
3.4 结束阶段
性能测试结束的标志，一般包括如下几点：涉及的测试场景均已测试完毕、测试过程中发现的问题已全部修复验证、测试结果达到了预期的性能指标、满足上线要求。
3.4.1 测试报告
在满足上面4个条件后，测试人员出具一份简洁但是明确的测试报告，说明本次性能测试的目的、范围、环境信息、测试结果、问题，并给出测试结论。
3.4.2 报告评审
参与本次性能测试各环节工作的各个角色都参与进行评审，大家对结果无异议，即可视为本次性能测试结束。
第四章 监控
4.1目的
监控的目的主要是为进行性能测试分析服务，完善会系统进行监控，针对瓶颈定位起到事半功倍的效果，一般需要针对操作系统、中间件、数据库、应用等进行监控，每种类型的监控尽量指标全面。
4.2 参数
操作系统：CPU（user、sys、wait、idle）利用率、内存利用率（包括SWAP）、磁盘I/O、网络I/O、内核参数等
中间件：线程池、JDBC连接池、JVM（GC/FULLGC/堆大小）
数据库：效率低下的SQL、锁、缓存、会话、进程数等
应用：方法耗时、同步与异步、缓冲、缓存
第五章 关于我们目前
1、测试性能的电脑，配置不能太低，可以分布式压测
2、我们目前测试环境，一台服务器上部署多个项目，做性能测试项目会有影响，压测的意义不大
3、我们目前最大的压力应该在MQTT上，主要是设备访问，是否可控制每秒的设备接入量，如，这一秒接入100请求，下一秒在接入100，就不用同秒去处理1000或更多，产生压力
查的资料：MQTT通讯使用TLS证书：性能上TCP 1G内存可维持5W的连接数，使用TLS 1G内存大约维持1.5W左右的连接数，
查询的他人结果：12W连接8G内存消耗
15W连接CPU维持利用率在100%--150%
25W连接12G内存消耗
每秒连接速度3000/S 4核剩余20%空闲