| 编辑推荐: |
本文主要介绍性能测试中的指标,性能测试中的模型、方案、监控、场景、分析调优以及性能测试中的结果报告，希望对您的学习有所收获。
本文来自于CSDN，由Alice编辑、推荐。 |
|
性能测试针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定监控策略，在场景条件之下执行性能场景，分析判断性能瓶颈并调优，最终得出性能结果来评估系统的性能指标是否满足既定值。
一、性能测试中的指标
所有的技术指标都是在有业务场景的前提下制定的。
技术指标和业务指标之间也要有详细的换算过程。
举个例子：
论坛主要有以下几个功能点：注册、登录、发贴、浏览贴子、管理员可以单个或者多个的删除帖子，部分用户发贴需要经过审核才能在前台展现；
我们10万的活跃用户，每天线在用户数约为1W， 75%的用户浏览帖子(平均5个帖子)并回复（2次），20%的用户会发贴（1个帖子）；并且以每个月5%的速度在增长；
我们有30个各版块的管理员，每天80%的管理员负责审核贴子（平均每天20个），15%的管理员负责册除不符合要求或者过时的帖子（平均每人删除3个）
；
用户发贴的思考时间在5S~60S之间浮动，审核帖子的思考时间在 5S~20S之间浮动；每天晚上8时至12时是用户使用高峰期，早上9时
至10时是管理员审贴的高峰；
换算如下
1.1 业务指标
所有的技术指标都是在有业务场景的前提下制定的
性能指标表示法
1.2 技术指标
1.2.1 时间指标
RT-响应时间：
接口/业务响应时间-从发起请求到接收到响应的时间。
1.2.2 容量指标
接口容量
接口的容量通常使用TPS/RPS来描述。
业务容量
业务量通常由TPS指标来描述，即系统每秒能够处理的业务量。
1.2.3 资源利用率指标
1.2.3.1 操作系统
CPU
IO
Mem
Disk
NetWork
1.2.3.2 JVM
GC
Classes
。。。
二、性能测试中的模型
在性能测试中，模型是对真实业务测试场景的抽象，用来描绘应用系统真实业务模型的样子。
举个例子，系统有 10 种业务场景，但并不是每个业务都需要有并发量，可能只有 5 个业务有，那就要把这些有并发的业务统计出来，哪个业务并发多，哪个业务并发少，做压力时就要控制好这样的比例。
获取用户行为模式的方法：
1、如果系统已经上线运行，则采用系统日志分析法获取用户行为统计和峰值并发量等重要信息；
2、对于一个全新系统来说，通常是参考行业中类似系统的统计信息进行分析和建模。
三、性能测试中的方案
方案规定的内容中有几个关键点，分别是测试环境、测试数据、测试模型、性能指标、压力策略、准入准出和进度风险。
测试环境：
1、测试环境需要尽量做到与线上环境配置保持一致，否则测试没有实际意义（不能反馈线上问题）
2、在大规模分布式系统中如果无法做到以生产一致，则需要分析线上环境与测试环境的差异，通过计算得到相关的比值
测试数据：
测试数据需要根据用户行为模型以及当前系统的数据总量及分布批量生成
测试模型：
测试模型即相关的测试场景
性能指标：
响应时间
并发用户数
吞吐量
压力策略：
测试中用户的添加策略（如每隔1秒添加20个用户）
准入准出标准：
即系统需要通过功能测试之后才能做压力测试
压力测试系统相关的指标达到需求标准后即可完成测试
进度风险：
反馈测试过程中发现的潜在系统风险，如压测环境与线上环境差别较大、某一项系统指标出现异常
四、性能测试中的监控
性能测试中需要有系统监控，系统监控要有分层、分段的能力，既要有全局监控也要有定向监控的能力。
性能测试分析的能力阶梯视图：
1、工具操作：包括压力工具、监控工具、剖析工具、调试工具。
2、数值理解：包括上面工具中所有输出的数据。
3、趋势分析、相关性分析、证据链分析：就是理解了工具产生的数值之后，还要把它们的逻辑关系想明白。这才是性能测试分析中最重要的一环。
4、最后才是调优：有了第 3 步之后，调优的方案策略就有很多种了，具体选择取决于调优成本和产生的效果
性能分析思路：
1、瓶颈的精准判断
1.1 TPS曲线
当增加压力tps的递增比之前要小，响应时间却在增加的时候，瓶颈可能就出现了。
通过TPS曲线可以判断系统是否存在瓶颈，瓶颈是否和严厉有关系，若通过不断增加压力 tps都会出现相同的趋势时，瓶颈就和压力无关，否则就是有关系。
1.2 响应时间曲线
ttps曲线才是用来判断系统是否有瓶颈的，响应时间只是用来描述业务的快慢。
2、线程递增的策略
压力的递增策略必须符合实际业务场景，即使是在秒杀场景中压力也是递增的不会一开始就上全部并发线程。
在做系统压力测试中，仅在改变压力策略（其他的条件比如环境、数据、软硬件配置等都不变）的情况下，系统的最大
TPS 上限一般来时是固定的。
在递增策略测试过程中，若每次增加压力tps都会出现抖动的情况，则有可能是以下两种可能：1、资源的动态分配不合理，如后端线程池、内存、缓存等；2、测试没有进行数据预热。
3、性能衰减的过程
当每一线程每秒的 TPS 开始变少时（总的tps还在增加），说明性能瓶颈已经出现了
当系统瓶颈出现后，系统的处理能力（TPS）并不会马上下降，TPS依旧会缓慢增加，此时系统性能正在衰减，tps最终达到上限。
4、响应时间的拆分
在系统压力测试过程中，当系统达到了瓶颈，再持续增加压力，响应时间就一定会上升，直到超时为止。
拆分响应时间是为了进一步确认时间主要消耗在哪个模块。
在分布式应用系统中建议使用链路的监控工具来拆分时间。
5、构建分析决策树
构建分析决策树是对系统架构的梳理，是对系统的梳理，是对问题的梳理，是对查找证据链过程的梳理，是分析思路的梳理。
分析决策树起到的是纵观全局，高屋建瓴的指导作用。
其中RDBMS 中的 MySQL的决策树如下：
操作系统的分析决策树如下：
分析决策树的目的是为了找出系统出现系统瓶颈的最终原因。
分析决策树帮助我们在分析系统瓶颈时提供证据链查找思路。
性能测试的最终目的是发现造成系统瓶颈的问题点，并能通过各种手段进行优化是系统处于最优状态。
6、场景的比对。
当你觉得系统中哪个环节不行的时候， 又没能力分析它，你可以直接做该环节的增加。
可以通过增加其中一台应用服务器或者增加压力机的方式，通过对比测试结果定位问题。
五、性能测试中的场景
基准性能场景：这里要做的是单交易的容量，为混合容量做准备。
容量性能场景：确定系统可处理同时在线的最大用户数，使系统承受超额的数据容量来发现它是否能够正确处理。
稳定性性能场景：稳定性测试必然是性能场景的一个分类。在稳定性测试中，显然最核心的元素是时间（业务模型已经在容量场景中确定了），而时间的设置应该来自于运维周期，而不是来自于老板、产品和架构等这些人的心理安全感。
异常性能场景：要做异常性能场景，前提就是要有压力。在压力流量之下，模拟异常。
六、性能测试中的分析调优
性能项目分类
新系统性能测试类：
新的项目经常需要测试出系统的最大容量，系统上线能抗住多少并发访问，上线前还需要将系统调至最优状态。
对与已经在线运行的系统：一般都是和旧版本做性能对比，保证新版班性能不会低于历史版本，对调优要求一般都不大。
七、性能测试中的结果报告
在性能测试报告中应该着重体现一下两点：
1、性能测试的结果（是否存在瓶颈，如果存在导致存在的瓶颈的问题是什么）、是否满足发版需求
2、调优前后的 TPS、响应时间以及资源对比图。
八、总结
|
