性能测试概念相关

引子：

　　在以前和别的测试交流过程中，不少人认为lr和jmeter就是性能测试。我认为性能测试更多的是一种概念，，而工具只是实现你的测试过程得到结果的一个工具。我认为性能测试的关键在于场景的设计和策略，不同的场景应该采用不同的测试方法。而你的场景设计来源于现存的数据(当然如果是新上线的系统，你要想办法间接的获得数据，比如对竞品的分析)，所以要先对你现有的数据进行分析，才能设计出合适的场景以及策略，这样得出的性能指标才是准确的。不然你的性能测试报告会直接误导你的团队。

为什么要进行性能测试;:

　　1 基于网络的分布式应用

　　2 用户数量的不断攀升，对系统负载的挑战。比如带宽是否够用，cpu是否够用以及高负荷情况下系统的稳定性，一旦出现性能拐点，系统能否自我恢复。

性能测试的概念：

　　1 性能测试分类：

　　　　1 负载测试：

　　　　　　持续不断的给被测系统加压，直到某一项或多项指标超过预先设定的指标，或者某种资源达到了饱和。主要侧重系统在不同负载下的性能表现，通过该项测试可以得到不同负载下的性能变化曲线，同时根据配合各项资源的占有率变化得到最佳用户数和最大用户数。看中的是并发量。

　　　　2 压力测试：

　　　　　　有的叫强度测试的。使被测系统处于或超过预期的负载时系统的运行情况，主要为了寻求系统能够承受的最大负载以及此时系统的吞吐率，并且观察系统在超高负载下是否回出现崩溃无法访问以及在系统负载减小后自我的回复能力。也可以用来测试系统的稳定性，简单的就是看系统是怎么死的。看中的是并发时间。如果超长时间测试就变成了疲劳测试。

　　　　3 并发测试：

　　　　　　可以看成压力测试的子集，在这里可以使用集合点，不考虑真实的场景，不设置运行时间。测试多用户并发访问同一个应用或更小的模块时，是否会出现死锁现象或其他问题。所以可以先对单接口进行并发测试，在对系统进行压力测试。

　　　　4 配置测试：

　　　　　　每次只更换单一的软硬件资源，当然压力的强度是一致的，根据结果找出最优的分配原则。

　　　　5 可靠性测试：

　　　　　　给系统适于正常负载或者高于正常负载来对系统进行长时间测试，比如采用最佳用户数量和最大用户数量之间的用户量，一般1*24,3*24,7*24可以根据实际的业务场景灵活配置。

　　　　6 扩展性测试：

　　　　　　适用于新上线系统或新的系统环境。先测单台服务器的性能，在逐步的增加服务器的数量，测试集群环境下单台服务器的处理能力损耗情况，集群环境下性能处理能力能否稳定的增加

　　　　7 容量测试：

　　　　　　在模拟生产环境的软硬件条件下，在数据库中增加不同量级的数据，运行单个或多个业务场景，给定固定虚拟用户数量的情况下，获取不同量级数据的性能指标，能够得到数据库能够处理的最大容量或最大会话能力。因为系统能够处理的最大用户数量通常和数据库相匹配，比如系统开了500个线程，那么对应的数据库也应该开500个线程来处理数据。

　　　　8 基准测试：

　　　　　　以正常载荷短时间测试被测系统。采集各项性能指标作为后期版本性能的对比。通过定期的基准测试可以得到一个一直的性能水平也成为基准线。当软硬件发生变化后，在进行一次基准测试以确定那些变化对性能的影响。

 　　　　总的来说，性能则是分为两个维度，即访问量和并发时间。压力测试就属于并发时间维度，看中的是稳定性。负载测试属于访问量维度，看中的是不同负载量下系统的表现。

 　　2 性能关注的点：

　　　　我们先从其他角色看看什么是性能。

　　　　1 用户视角：

　　　　　　从用户的角度来看，它们眼中的性能直白的将就是速度快不快，是否会出错。所以用户的角度比较偏向于主观，所以后期要做好用户反馈收集并持续反馈，比如windows系统就是一个持续的迭代优化过程。

　　　　　　1 响应时间。速度快不快。

　　　　　　2 稳定性。是否经常出现链接失败的情况。

　　　　

　　　　2 开发视角：

　　　　　　1 代码算法是否合理，能否进一步提升。

　　　　　　2 数据库设计是否合理，比如索引是否合理。

　　　　　　3 架构设计是否合理

　　　　　　4 是否有不合理的线程同步，多线程

　　　　　　5 代码本身是否存在性能问题

　　　　　　6 是否存在不合理的资源竞争

　　　　　　7 是否有不合理的内存使用，比如线程资源能否正常回收。

　　　　3 系统管理员视角：

　　　　　　1 服务器资源使用合理 软硬件资源利用率，偏重于硬件。

　　　　　　2 系统能否支持扩展

　　　　　　3 最多支撑多少用户访问  从系统的容量角度。通常在性能测试中，数据库的最大链接数限制系统的最大用户数

　　　　　　4 最大的业务处理量，特别是核心的业务处理数量。比如电商的交易环节。

　　　　　　5 系统的瓶颈，从可扩展的角度

　　　　　　6 更换那些设备或软件，可以提高系统的性能，比如集群，云计算，虚拟化。

　　　　　　7 在高负荷下能否支持不间断的业务访问。从稳定性的角度

　　　　4 产品角度：

　　　　　　功能完善，稳定可靠

　　　　　　而测试作为系统的整体系统的质量的把控者，需用从各个角色的视角去看待系统。除了关注表面的现象比如响应时间，也需要关注本质，比如服务器资源利用率等。

 

 

 

性能测试过程：

　　总体流程;

　　　　设计方案---------开发脚本---------执行场景---------结果分析------------性能测试报告

 

　　　　1 设计方案：

　　　　　　1 测试目标

　　　　　　2 测试过程

　　　　　　3 测试对象

　　　　　　4 测试平台

　　　　　　5 被测模块

　　　　　　6 性能测试脚本开发方案：

　　　　　　　　总体方案

　　　　　　　　分支方案

　　　　　　7 性能测试场景设计方案

　　　　　　8 重要指标分析

　　　　　　9 其他考虑

　　　　2 性能测试报告：

　　　　　　1 总体概述

　　　　　　2 总体性能

　　　　　　3 不同虚拟用户数下相关性能指标

　　　　　　4 各个指标结果：

　　　　　　　　例如响应时间：分别在50用户数和100用户数下的相应时间

　　　　　　5 总结

性能测试的核心原理：

　　　　1 基于协议，前后端交互机制，性能核心。基于界面决定和前端用户交互，基于代码决定了后端。

　　　　　　1 网络分布式架构。

　　　　　　2 单机应用，比如安安兔，鲁大师。主要判断io读写，以及对资源的消耗。

　　　　2 多线程，模拟多个虚拟用户量同时访问系统。

　　　　3 模拟真实的场景。场景的设计合理直接决定了你得出的性能数据，从而影响你对系统的性能判断。　

核心指标：

　　　　1 响应时间：

　　　　　　前端发送请求，到后端返回的时间，从测试角度看，不包含前端对响应的渲染时间。

　　　　　　响应时间=发送网络延时+应用程序处理的时间（包含应用程序和数据库处理时间）

　　　　　　一般遵循3,5,8原则。取决于用户带宽，服务器带宽，服务器处理时间。

　　　　2 事务处理能力(TPS)：

　　　　　　TPS标识单位时间内能够完成事务数量，也成为每秒事务数TPS。每个系统的TPS都有上限，并不随着用户的增加而增加。

　　　　　　泛指的概念：比如打开一个页面-----登录----挑选商品-----网购支付，这每一个步骤都是可以理解成一个事务，甚至整个流程都可以理解成一个事务。每一个事务都有开始和结束，比如lr中要用lr_start_transaction("start_xiaohua")标识事务开始，lr_end_transaction("start_xiaohua", LR_AUTO)标识事务结束，所以TPS是软件测试结果的测量单位

　　　　　　对于已经上线的系统，可以选取高峰时刻，在5分钟内，获取系统每笔交易的业务量和总业务量推算出TPS。

　　　　　　TPS=请求数/时间

　　　　3 每秒查询率(QPS):

　　　　　　QPS标识一个特定的查询服务器在规定时间内处理流量多少。QPS类似于TPS。假如一个TPS中只有一个接口且接口内部没有向服务器再请求资源，那么此时TPS=QPS，否则不等。比如打开一个页面，就可以认为是一个TPS，但是一个页面的请求可能回像服务端再次请求多次请求，服务器对着这些请求，就可以计算计入QPS。例 每秒能进行N个事务的请求，假设一个TPS内包含4个QPS，那么就是N*4，通常QPS用来衡量单接口，TPS用来衡量多接口的混合场景，当然你把单个接口当做一个事务也可以。

　　　　　　一个系统的吞吐量通常有QPS(TPS)并发数来决定，这两个值都有一个相对的极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去，如果压力持续增大，系统的吞吐量反而回下降，因为系统超负荷工作，频繁的上下文借还，内存等其他小号导致性能下降。

　　　　　　原理：每天80%的访问集中在20%时间内，即根据二八原则，这20%时间叫做峰值时间

　　　　4 思考时间：

　　　　　　用户打开一个页面之后，回浏览该页面，此时并不向服务器发送请求，以8秒为基数，进行50%---200%的随机取值。以便更好的模拟用户请求的时间。

　　　　5 每秒点击数(HPS)：

　　　　　　html中的一个img src就可以理解成一个HPS，，应该尽量较少HTTP请求，这取决于用户的数量。常见问题图片过大，连接数过多，该压缩的压缩，该合并的合并。

　　　　　　和tps qps的区别，个人认为 tps>qps>hps

　　　　6 最大连接数;

　　　　　　系统的最大连接数通常受制于容器例如tomcat，apache等以及数据库的最大连接数。当tps出现瓶颈的时候，但是资源没有到达瓶颈，那么很大可能就是此类的性能问题。

　　　　7 系统资源：

　　　　　　1 cpu：

　　　　　　　　1 %Processor Time cpu使用率。70%--80%一般视为最大值，当然cpu使用率达到100%也不代表系统会崩溃，加入cpu等待队列不超过4的化。

　　　　　　　　2 %Processor Queue Length cpu等待队列长度。一般控制在2*内核数

　　　　　　2 内存：

　　　　　　　　1 总体可用数

　　　　　　　　2 虚拟内存交换率 page/sec。

　　　　　　　　　　虚拟内存，通常内存会将一部分数据放入到硬盘缓存中去，使用的时候再读回来，这种来回的数据交换就叫做内存的交换律，交换的单位是页page，所以也叫做内存的也交换率。

　　　　　　　　3 缓存：

　　　　　　　　　　分配给一个应用程序使用的内存。

　　　　　　　　进行系统级优化的时候，重点利用好缓存机制。代码层面算法 sql语句等，减少内存，减少运算次数，预算次数决定cpu消耗，内存决定了资源占用。

　　　　　　3 磁盘io

　　　　　　　　应用程序存在硬盘谁给你，但是使用的时候，需要加载在内存上。

　　　　　　　　1 硬盘使用率 %diskTime

　　　　　　　　2 硬盘使用队列长度

　　　　　　4 网络带宽（Bytes Total/sec）:

　　　　　　　　上相和下行相对而言

　　　　　　　　1 每秒接受的数据量，低于下行带宽/8

　　　　　　　　2 每秒发送的数据量，低于上行带宽/8

　　　　　　　　Bytes Total/sec 用来描述发送和接受字节的速度，一次来判断网络带宽是否存在性能瓶颈。

　　　　　　5 线程：

　　　　　　　　进程是资源单位，线程是执行单位，在cpu三状态轮换图中，实际执行的是线程。

 

性能指标分析：

　　获取数据:

　　　　1 合理设定场景

　　　　2 在设计ramp up/down越慢越好，否则图表跳动太大，因为性能测试工具并不是实时监控，也不是从全量的指标数据中获取数据描绘图表，例如lr就是每5秒获取一次，并且从获得的结果中随机抽样10%作为标的数据来描绘图表

　　　　3 越慢越好的前提下，平衡好每秒增加的虚拟用户量，以及运行时间，例如3000user，每秒增加50

　　分析数据：

　　　　1 单个查看某个指标绘制的图表是没有多大意义的，所以要将多张图表关联起来，那么更容易从整体查看系统在不同阶段负载下的表现

　　　　2 划分出系统的轻负载区，重负载区，性能拐点区。求出最佳用户数和最大用户数。

　　　　3 查看性能拐点区域，服务器的资源情况，得出测试结论。

性能瓶颈总结:

　　　　1 硬件性能瓶颈：

　　　　　　一般指的是cpu，内存，磁盘io等瓶颈，常用来衡量服务器硬件瓶颈

　　　　2 应用软件性能瓶颈：

　　　　　　比如服务器操作系统的参数配置，数据库瓶颈（比如最大连接数），web服务器瓶颈（比如apache默认最大连接数250个），中间键参数配置瓶颈。等

　　　　3 应用程序上的性能瓶颈：

　　　　　　比如代码算法，业务逻辑，数据库设计，sql语句性能等

　　　　4 操作系统上性能瓶颈;

　　　　　　例如windows，linux等操作系统。例如虚拟内存设置不合理，从而导致虚拟内存交换率大大降低

　　　　5 网络性能瓶颈：

　　　　　　1 网络带宽不能满足要求

　　　　　　2 网络设备。比如交换机和路由器上的防火墙，以及负载均衡等