持续更新…
标记
系列文章目录-性能测试
性能测试-基础+中级(二)【前端性能测试】
1. 性能测试起步
1.1 性能测试的应用场景
- 选型
系统采用新技术或新架构,但是这种新技术/新架构是否能够满足我们的业务需求尚且未知,如果等待系统开发完毕后再去验证是否满足业务需求,风险较高。所以在选型的时候,就去对采用的新架构或新技术做性能测试,验证是否满足比如大并发这种业务需求,从而更早的规避风险。 - 验收
系统功能测试已经通过,这时候就需要在业务需求的场景下对系统做性能测试,看是否能满足性能的需求。 - 备份
比如系统部署在阿里云服务器上,但为避免挂掉无顶替,就在华为云上再部署一套,这时就需要测试人员检验华为云的环境是否满足系统的性能需求。 - 省钱
比如系统运营的成本,为满足某个时间段的高并发,要做基准测试,以此来评估到底要部署多少台服务器(双十一)。
1.2 不同的角度看性能
- 从黑盒测试的角度
- 数据请求经过网络发送
- 服务器前端接收处理
- 在数据库服务器获取相关数据
- 前端处理后返回数据
- 应用界接收到数据响应
- 从程序员的角度
- 结构合理性
- 数据库设计合理性
- 代码与算法
- 系统中资源的使用方式
- 系统运维角度
- 硬件资源利用率
- 何种硬件可以提高系统性能
- 系统能够支持7*24(一周的时长)的服务
- 扩展性、兼容性、最大容量、可能的瓶颈
1.3 影响性能的因素
- 硬件配置
CPU、内存、网络 - 操作系统
- 开发语言
- 用户量
- 操作方式
- 操作环境
- 使用时间
- 开发者技术水平
…
服务器挂掉的原因:
1.需求分析没到位(没有对并发数做一个相对准确的预估)- 最重要;
2.某关键时间段并发大(造成系统负载高);
3.系统架构不具有扩展性(造成宕机)。
2. 性能测试概述
2.1 性能测试定义和分类
性能测试定义
性能测试在软件的质量保证中起着重要的作用,它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面:应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下,三方面有效、合理的结合,可以达到对系统性能全面的分析和瓶颈的预测。
性能测试:是通过自动化测试工具模拟多种正常、峰值以及异常负载条件来对系统的各种性能指标进行测试。主要包含三层含义:
- 通常,性能测试需要借助工具来实现;
- 性能测试除了关注普通的正常的情况外,还重点关注空间和时间上的很多峰值或异常的系统运行情况;
- 性能测试借助所监控和收集的各项指标来分析系统性能。
性能测试其实就是做评估、优化和预测。
性能测试的分类
- 基准测试:先测一轮作为后面测试或者后面版本测试的基准(一般地,会把第一版第一轮的测试数据作为基准;不同版本做基准,需要进行评估,不能跨度太大)。
- 一般性能测试:验证软件在正常情况和系统条件下能够满足性能指标(基于用户行为情况和用户分布等信息,对系统是否能够达到预期服务能力进行验证)。
- 并发测试:测试多个用户同时访问同一应用,同一个模块或者数据记录时是否存在死锁或者其他问题,所以几乎所有的性能测试都会涉及到一些并发测试(通常并发操作都会加锁,死锁其实就是资源的争用)。
- 负载测试:确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。验证系统在一定压力下延长系统运行时间,直到系统性能出现“拐点”(跨过拐点,系统出现不稳定的情况,比如性能的下降)。
- 压力测试:验证系统在已经处于极限负载下或者某指标已经处于饱和状态下系统性能的表现(系统濒临崩溃,寻找系统极限值的过程),来获得系统能够提供的最大服务级别。
- 疲劳强度测试:对系统进行加压(可以是并发量,也可以是时间),测试系统出现疲劳时候的点(系统逐渐变慢的临界点。如果是时间,一般跑24h以上)。
- 稳定性测试: 验证系统在连续运行的情况下,查看系统的各项性能指标——MTBF(错误发生的平均时间间隔),是否长时间运行会出现内存泄露等问题(一般跑72h以上)。
- 容量测试:预先分析出反映软件系统应用特征的某项指标的极限值(如最大并发用户数、数据库记录数等),系统在其极限状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。
- 大数据量测试:主要针对对数据库有特殊要求的系统进行的测试,验证系统在使用大批量数据对系统产生压力或影响的情况下系统各种指标是否正常。
1)实时大数据量:模拟用户工作时的实时大数据量,主要目的是测试用户较多或者某些业务产生较大数据量时,系统能否稳定地运行。
2)极限状态下的测试:主要是测试系统使用一段时间即系统累积一定量的数据时,能否正常地运行业务。
3)前面两种的结合:测试系统已经累积较大数据量时,一些实时产生较大数据量的模块能否稳定地工作。 - 配置测试:验证系统在不同的软件或硬件配置的情况下,找出系统各项资源的最优分配。
- 恢复性测试(也称作可维护性测试,失效恢复测试):当软件运行故障时的恢复能力。失效恢复测试一般是对具有负载均衡的系统或者是具有备份的系统进行的,主要是为了测试当系统局部发生故障时,是否会对全局产生较大的影响,产生的影响是否在可以接受的范围内,以及用户是否能够继续使用系统(还要关注失效后,系统还能支持多少用户并发操作,以及出现这种情况,可以采用哪些应急方案来快速解决问题。具有主从备份的系统一般要做失效恢复性测试。如主库发生故障,从库自动切换为主库,主库恢复后,是保持两个主库,还是恢复一主一从等等)。
- 现网性能测试:在真实的环境下做性能测试(为了得出最真实的数据,这种类型的测试要注意一些问题对网络性能的影响,比如占用过多的带宽,影响其他业务,垃圾数据的清理等。一般做性能测试是在内网的环境下进行,·比如服务器系统相关的各种配置的测试,基本都是在局域网做,但没有办法评估网络环境的带宽等限制问题,在局域网测试可能没有问题,真实环境下就不一定,可能就会因为带宽网络的限制问题,导致用户无法访问系统,无法满足需求)。
没有必要把所有测试都做一遍,一般就是做基准测试,一般性能测试,稳定性测试;如果是负载均衡的系统或有备份的系统,就要做失效恢复性测试;如果要评估网路带宽,需要做现网性能测试。按需进行测试。
2.2 常用性能测试术语、性能测试指标
- 虚拟用户(Virtual User,简称vu):在测试环境中,Loadrunner和一些性能测试工具在物理计算机上使用Vuser来“虚拟”实际用户的操作行为。
- 并发和并发用户数:
- 并发:强调“大量用户”的“同时性”操作,该操作要求对服务器(不是客户端)产生压力;
- 并发用户数:指的是在某一时刻同时进行了对服务器产生影响的操作的用户数量(并发用户数<在线用户数<系统用户数)。注意:“系统用户数”与“在线用户数”之间的差异,“系统用户数”指的是某一个特定的系统的用户总量;“在线用户数”指的是登陆了系统或正在使用系统的用户人数。
- 响应时间:包含“请求响应时间”和“事务响应时间”。
- 请求响应时间:服务器收到用户请求到把响应内容发送出去,这段时间(运维考虑);
- 事务响应时间:处理请求对应事务的时间(开发考虑);
- 如果从用户的角度来说,响应的时间为:从请求发出到看到响应结果。这个响应时间的影响因素有很多,比如:用户的带宽,运营商,服务器,服务器的数据处理,返回的运营商,用户电脑的处理速度等;
- 响应时间=网络传输请求的时间(浏览器到服务器)+服务器处理(一层或多层)时间(比如:nginx-tomcat-redis-mysql)+网络传输响应的时间(服务器到浏览器)+页面前端解析渲染时间;
- 对外告知响应时间时,要带上TPS,即要指明在多少TPS下的响应时间(因为响应时间随访问人数变动,所以只告知响应时间是不正确的)。
- 思考时间:模拟真实用户操作而停顿的时间间隔。
- 两次请求之间的间隔时间(loadrunner中默认情况下,思考时间是0);
- 思考时间会影响到TPS。
- 点击率:一般指每秒钟用户向服务器提交的请求数(Web测试中特指HTTP请求数)。
- 每秒事务数(Transaction Per Second,TPS):指每秒钟系统能够处理的事务数量(评判系统的处理能力)。
- 一个事务里可以有一个或多个请求,比如测登录,一个事务里可能就会有多个请求;如果是测一个接口的性能,那么一个事务里就可能只有一条请求);
- TPS就是站在客户端的角度衡量服务器处理能力。
- TPS=并发用户数/响应时间。
- 吞吐量与吞吐率:用于反应客户端和服务器之间网络状态的一个指标,其能间接反应服务器承受的系统压力
- 吞吐量:在单次业务中,客户端和服务器进行的数据交互总量,