软件性能测试包括哪些方面
如今的软件性能测试技术发展越来越快,包括的内容越来越多样化和全面性。性能测试是通过性能自动化测试工具(主流Jmeter、LoadRunner)模拟生产实际用户的并发请求,以及在异常压力时获取系统性能表现,用来测评软件产品的性能效率特性。在某些行业,比如银行,性能测试的概念得到了扩展,不仅仅停留在性能效率特性,而且涵盖了系统高可用性、可靠性等特性,称为“非功能测试”。我们将性能测试主要概括为前端性能和后端性能,而我们一般在内网1G带宽下进行性能测试,而网络性能显得就没有那么重要了,我们平时说的性能测试一般指的是对系统后端进行测试。
01非功能测试
广义的非功能测试,泛指除功能测试以外的软件测试工作,对通过功能测试无法测试的内容进行测试工作。比如:单元测试、负载测试、压力测试、高可用测试、安全测试等。
狭义的非功能测试,强调对系统效率、高可用、可靠性等系统特性进行的测试工作。由于单元测试和安全测试专业性较强,可以单独由开发人员或者专业的厂商进行测试。
02性能测试分类
负载测试:是在一定约束条件下测试系统所能承受的并发用户量、运行时间、数据量,以确定系统在给定约束条件下的服务能力。
压力测试:通过逐步增加系统负载,测试系统性能的变化,并最终确定在什么负载条件下系统性能处于失效状态,并以此来获得系统能提供的最大服务级别的测试。
强度测试:采用系统稳定运行情况下能够支持的最大并发用户数或者日常运行用户数,在一定时间段内持续执行业务,通过综合分析交易执行指标和监控资源指标来确定系统处理最大工作量强度性能的过程。
同时在线用户测试:举例说明,通过3000虚拟用户或者4000虚拟用户同时访问被测系统,要求后台应用中存在3000个session或者4000个session同时在线,查看应用、以及应用服务器的性能表现,为被测系统提供性能保障。
可恢复性测试:也叫异常测试(各家公司叫法不统一,但测试方法类似),针对负载均衡、应用集群、数据库RAC等架构,通过可恢复测试,对系统架构的容灾并恢复能力进行考验。
还有其他小众的分类,就不一一例举了。
03性能指标
性能测试相关的技术指标看重的是“时间”和“效率”,即在一定单位时间内(一般为一秒内),相同并发数条件下完成的交易数量越多越好,这就提到并发数、响应时间、处理能力等关键指标,通过这些技术指标能够更好的识别系统性能瓶颈。
响应时间:指从客户端发起一个请求开始,到客户端接收到从服务器端返回的响应结束,整个过程所耗费的时间,一般单位为毫秒。该指标越低越好。
处理能力(吞吐量):系统每秒处理事务数,单位是笔/秒,该指标越高越好。
交易成功率:在系统性能压力下,交易成功概率,公式为(失败成功数/交易总数)×100%,交易成功率越高越好。
CPU利用率:反映后台服务器CPU利用率情况,包括用户态(user)、系统态(sys)、等待态(wait)、空闲态(idle)。
内存利用率:反映后台服务器内存利用率情况,值得注意的是内存利用率99%并不代表内存就存在性能瓶颈,这还要结合SWAP交换空间内存使用情况综合分析内存问题。
磁盘:反映后台服务器的磁盘读写使用情况,即每秒读写多少兆。
网络I/O:反映后台服务器的磁盘读写使用情况,即每秒读写传输多少兆,一般情况下不能超过设备或链路最大传输能力的70%。
04测试模型
好的测试模型可以更好的指导我们测试人员完成性能测试,使并发压力合理的分配到不同的测试业务。业务模型转换成测试模型是根据测试目的/重点,对业务模型的交易配比进行微调,或者对模型中的交易进行删减、合并,总交易占比不变。
05性能测试场景
按照测试需求和测试模型设计测试场景,对被测试系统的测试,应该采取基准测试、单交易负载测试、混合负载测试的顺序来执行。这样做的好处,在单交易负载测试时就可以发现系统本身的性能缺陷,而混合测试负责测试时将重点检查各个业务相互影响导致的性能缺陷。
基准测试场景:在系统无压力时,连续执行测试脚本100次或者5分钟,获得平均交易响应时间。
单交易负载测试场景:单交易负载测试是逐一对业务模型中的典型交易进行单交易并发测试,目的是考察系统交易功能编码是否存在性能隐患。
混合压力场景:目的是考察混合典型交易的情况下系统最大承载能力,以及交易间的资源争用情况。
稳定性测试场景:按照业务模型的约定,在一定负载压力下,长时间稳定运行测试场景,查看服务器状态。
高可用性测试场景:灾备/主从切换可恢复性场景、集群可恢复场景、同城/异地双活可恢复场景
其他场景:限流机制、数据库重连、熔断机制、超时机制、队列堵塞机制、加密机白名单验证
06性能监控及瓶颈识别
性能测试中最具技术含量,考察一名测试人员能力的就是要看是否能够通过性能监控识别其中的性能瓶颈和性能风险。性能监控是整个性能测试工作的重中之重,是有效测试的关键所在,性能测试人员通过监控数据识别和挖掘性能问题,对问题做“鱼骨图”根本原因分析。相关领域性能专家根据实际项目情况以及自己的专业经验,梳理了未达标项并做了原因分析,主要从应用系统、数据库、中间件、硬件资源、人员水平、测试工具等方面进行梳理,逐步细化分析进行性能瓶颈识别。性能监控不仅是怎么监控的事情,监控的是不是到位,是不是全面,更要是怎么分析的事情。
07总结
以上从性能测试分类、技术指标、模型、场景、性能监控和性能瓶颈分析等方面做了说明,除此以外性能测试还要做好性能数据准备、性能脚本的编写、了解被测系统架构和相关系统机制等工作,对需求和系统了解的越透彻越有利于性能工作的开展,并且有利于识别性能瓶颈。
本文系作者 @河马 原创发布在河马博客站点。未经许可,禁止转载。
暂无评论数据