什么是性能:就是软件质量属性中的“效率”特性。
效率的特性:
时间特性:指系统处理用户请求的响应时间。
资源特性:指系统在运行过程中,系统资源的消耗情况。
什么是性能测试?
性能测试是指通过自动化测试工具模拟正常、峰值以及异常的负载条件,来对系统的各项性能指标进行测试和评估的过程。
评估当前系统能力。
基于性能需求目标的测试验证。
精准容量规划,并验证系统容量的可扩展性。
主要分为:
狭义:也就是单用户测试。在测试环境确定以后,对业务模型中的重要业务做单独的测试,获取单用户运行时的各项性能指标,以进行基础的数据采集。
广义:是一种测量和评估软件性能指标的活动。你可以在某个时刻通过基准测试建立一个已知的性能水平(称为基准线),当系统的软硬件环境发生变化之后再进行一次基准测试以确定那些变化对性能的影响。
基准测试数据的用途:
含义:负载测试是指获取各个事务在不同负载条件下的性能表现。通过逐步增加系统负载量
,测试系统性能的变化,并最终确定在满足系统的性能指标情况下,系统所能够承受的最大负载量的测试。
示例:健身举哑铃
含义:稳定性测试是指在服务器稳定运行(用户正常的业务负载下)的情况下进行长时间测试,并最终保证服务器能满足线上业务需求。时长一般为一天、一周等。
并发测试
广义:在极短的时间内发送多个请求,来验证服务器对并发的处理能力。如:抢红包、抢购、秒杀活动等。
狭义:模拟多用户在同一时间访问同一应用(进行同一具体操作)的测试,用于发现并发问题,例如线程锁、资源争用、数据库死锁等。
容量测试
关注软件在极限压力下的各个参数值。例如:最大 TPS、最大连接数、最大并发数、最大数据条数等。
压力测试
压力测试是在强负载(大数据量、大量并发用户等)下的测试,查看应用系统在峰值使用情况下操作行为,从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。
压力测试分为高负载下的长时间(如 24 小时以上)的稳定性压力测试,和极限负载情况下导致系统崩溃的破坏性压力测试。
稳定性压力测试:在系统高负载的情况下(下图中接近 C 点),长时间运行(24 小时),查看系统的处理能力。
破坏性压力测试:在系统极限负载的情况下(下图中 C-D 点),对系统进行压力测试,查看系统容错能力和错误恢复能力。
性能指标:在性能测试的过程中,记录一系列的测试数据值,用这些实际记录的数据值与需求中的性能要求做对比,达标则表示性能测试通过;未达标则可能是性能 Bug。
不同人群关注的性能指标各有侧重。前台服务接口的调用者一般只关心吞吐量、响应时间等外部指标。后台服务的所有者则不仅仅关注外部指标,还会关注 CPU、内存、负载等内部指标。
拿某打车平台来说,用户所关心的是智能提示服务的外部指标能不能抗住因大波优惠所导致的流量激增;而对于智能提示服务的开发、运维、测试人员,不仅仅关注外部指标,还会关注 CPU、内存、IO 等内部指标,以及部署方式、服务器软硬件配置等运维相关事项。
常见的性能指标:响应时间、并发数、吞吐量、错误率、点击数、PV/UV、系统资源利用率等。
3 个关键的业务指标:
系统资源指标:
含义:系统处理一个请求或一个事务的耗时(客户端从发起请求到获取响应)。
响应时间是终端用户对系统性能的最直观印象,包括了系统响应时间和前端展现时间。
因此,性能测试又分为后端(服务器端)的性能测试和前端(通常是浏览器端)的性能测试。
系统响应时间 = 应用程序处理时间(A1+A2+A3) + 网络传输时间(N1+N2+N3+N4)
响应时间的指标取决于具体的服务类型。
对于响应时间的统计,应从均值、.90、.99 等多个分布的角度统计,而不仅仅是给出均值。
50 th(60/70/80/90/95 th):如果把响应时间从小到大顺序排序,那么 50% 的请求的响应时间在这个范围之内。后面的 60/70/80/90/95 th 也是同样的含义。
常见瓶颈:同一请求/事务的响应时间忽大忽小。
在正常吞吐量下发生此问题,可能的原因有两方面:
含义:在同一时刻与服务器正常进行交互的用户数量。
含义:吞吐量(Throughput)是指在单位时间内,系统处理客户端请求的数量。
吞吐量 = 并发数 / 响应时间
从不同维度来描述:
吞吐量是衡量服务器性能好坏的直接指标,通常表现如下:
在系统处于轻压力区(未饱和)时,并发用户数上升,平均响应时间(基本不变),系统吞吐量(上升)。
在系统处于重压力区(基本饱和)时,并发用户数上升,平均响应时间(上升),系统吞吐量(基本不变)。
在系统处于崩溃区(压力过载)时,并发用户数上升,平均响应时间(上升),系统吞吐量(下降)。
QPS
含义:服务器每秒钟处理的接口请求数量(一个服务器中有多个接口,QPS 指的是所有接口在同一个单位时间内的被处理数量之和)。
TPS
含义:服务器每秒钟处理的事务请求数量。
一个事务通常指的是界面上的一个业务场景操作。一个事务可以包含一个或者多个接口请求。
一个业务请求发送给服务器后,最终会定位到服务器对应的业务请求的代码,既有可能是一段代码也有可能是多段代码。
示例:
结论:
吞吐量计算方法
1)均值计算
TPS = 总的请求数 / 总的时间
问题:对于同一天的时间内,不同的时间段,请求速率会有波动,这样计算会被平均掉,法测试负载高的情况。
2)二八原则
含义:80% 的请求数会集中在 20% 的时间内完成。
TPS = 总的请求数 * 80% / 总的时间 * 20%
通常二八原则的计算方法会比平均的计算方式更具代表性和准确。
3)按照每天的具体业务数据进行计算(稳定性测试 TPS)
当获取每天的具体业务统计数据时,就可以统计出业务请求集中的时间段作为有效业务时间;并统计有效业务时间内的总请求数
TPS = 有效业务时间的总请求数 * 80% / 有效业务时间 * 20%
4)模拟用户峰值业务操作的并发量:(压力测试 TPS)
获取每天的交易峰值的时间段,及这个时间段内的所有请求的数量。
TPS = 峰值时间内的请求数 / 峰值时间段 * 系数(倍数)
系数可以是 2、3、6、10,根据要达成的性能指标而定。
案例
某购物商城,经过运营统计,正常一天成交额为 100 亿,客单价平均为 300 元,交易时间主要为 10:00-14:00 以及 17:00-24:00,其中 19:00-20:00 的成交量最大,大约成交 20 亿。
现升级系统,需要进行性能测试,保证软件在上线后能稳定运行。
请计算出系统稳定性测试时的并发(负载)量,及保证系统峰值业务时的并发(负载)量。
稳定性分析
压力分析
含义:指系统各种资源的使用情况。一般用“资源的使用量/总的资源可用量×100%”形成资源利用率的数据。
建议:没有特殊需求时,通常要求如下:
点击数
点击数是衡量 Web 服务器处理能力的一个重要指标。
错误率
含义:指系统在负载情况下,失败业务(取决于断言结果)的占比。
错误率=(失败业务数/业务总数)*100%
性能需求分析是整个性能测试工作开展的基础,性能需求分析做的好不好直接影响到性能测试的结果。
性能需求分析通常包含的内容如下:
熟悉被测系统
确定性能测试指标
明确性能测试内容
确定性能测试策略
性能测试指标要可测量,如定量指标给出具体数值,定性指标要给出具体描述。
性能测试指标的来源一般如下:
1)需求文档
客户明确需求:通常情况,客户有明确的需求,提出一些性能测试指标。例如:每秒登录用户量多少,用户在线总量多少等。
客户隐形需求:基于客户明确指标下,会有一些隐性指标,例:100 万在线用户的查询在 5 秒响应,我们也许纳入性能测试指标内。
用户模型确定:有了上述性能测试指标后,就可以创建我们的用户模型了。如下:
2)运营数据
根据历史运营数据收集、分析业务数据,如:
测试范围
关注重点
针对新增或重构模块:进行全面的测试,优先覆盖典型场景。典型场景如下示例:
针对继承模块:进行回归验证即可,不做探索性的性能测试。
分析步骤:
案例:
期望的 TPS 和最大响应时间,如下:
在实际工作中,通常有性能测试的计划模板,对照模板进行编写即可。
通常包含内容如下:
案例如下:
1)测试背景
轻商城是公司新开发的一个电商项目,为了保证项目上线后能够稳定的运行,且在后期推广中能够承受用户的增长,需要对项目进行性能测试。
2)测试目的
对新电商项目进行性能测试的核心目的包括:
3)测试范围
通过对性能测试需求的调研和分析,确定被测系统的测试范围如下:
4)测试策略
1. 基准测试
2. 负载测试
通过逐步增加系统负载,测试系统性能的变化,并最终确定在满足系统的性能指标情况下,系统所能够承受的最大负载量的测试。
分别模拟 5、10、30、50、100 个用户对系统进行负载测试,查看不同并发时系统软件各项指标是否符合需求。
3. 稳定性测试
用 200 个用户对系统进行 7*24 小时不间断的稳定性测试,验证系统在长时间的正常负载下的表现是否正常。
5)风险控制
风险类型 | 风险描述 | 风险级别 | 应对方案 |
---|---|---|---|
环境风险 | 找不到合适的软硬件等资源 | 高 | 测试前期阶段识别,并使用相近配置进行验证,后期需在测试报告中提出 |
环境风险 | 部署出现问题,联调进度缓慢 | 高 | 更换环境;增加资源配置 |
人力风险 | 测试周期紧张,需要多名测试人员同时进行测试,但具备性能测试能力的人员不足 | 高 | 延长测试周期,或在前期培训相应人员 |
数据风险 | 构造测试数据时间较长 | 高 | 开发人员协助 |
交付风险 | 发现比较严重的 Bug | 高 | 延长测试时间,增加对应人员 |
6)交付清单
性能测试计划、性能测试脚本、性能缺陷统计和性能测试报告等。
7)进度与分工
可参考如下性能测试用例的模板来编写:
示例:使用 JMeter 编写测试脚本并调试,常用测试元件如下:
基础结构如下:
Jmeter 详细使用说明可参见系列博文《https://i.cnblogs.com/posts?cateId=1938518》
在进行性能则试之前,需要先完成性能测试环境的搭建工作,测试环境一般包括硬件环境、软件环境及网络环境。
性能测试环境的特点
尽量保持性能测试环境与真实生产环境的一致性
性能测试环境的建模
主要分为网络拓扑图、硬件、软件、参数配置、测试数据等。描述清楚几个要点:
建模思路
思考:低配测试环境的性能测试意义
即使测试环境较 low,但性能测试还是能起到意义的,至少能够:
构造方法:
压测环境中的数据量尽量与生产环境中的数据量一致。为了快速创建大量数据,通常使用如下方法:
数据量:
数据库中该有多少测试数据才是合理的呢?
需要考虑、中长期系统运营的数据出现的可能性
和性能测试干系人讨论,讨论得出数据
需要考虑数据库配置文件、缓存参数的设置情况
明确 Cache 预 load 的数据说明
缓存数据:
业务正确性:如 HTTP 请求中的 cookies 贯穿整个业务交互过程,在测试脚本中应该缓存 cookies,保证业务正常,同时考虑后台对 cookies 的存取方式,保证大并发下不会出现 cookies 丢失或者写满的情况。
性能表现:关注冷启动和热启动这两种场景下的性能表现。
现象:
原因:
为此,在做性能基准测试的时候,有经验的工程师通常都会先用性能场景对系统进行一下“预热”,然后再真正开始测试。
测试桩作用:用于性能瓶颈定位时,规避测试中一些非主要的流程,通常由研发人员提供。
模块之间的测试桩:流程中包含 AB 模块,性能定位 AB 模块性能瓶颈时,需在 AB 模块之间做桩,让其支持单压 A,或者单压 B 模块。
辅助测试桩:测试流程中的一些非主要流程,且测试脚本不易实现。例:登录时安全校验输入验证,可适当地让研发人员进行前段安全校验的屏蔽。
先保证脚本调试通过之后,才能进入正式压测阶段。
正式执行性能测试前,需要根据要模拟的业务负载量来选择适当的测试机。
压测机
通常会选择 Windows 或者 Linux 环境来执行脚本:
分布式执行
如果单台压测机的并发量不能够满足负载要求,则可以通过分布式压测来提高并发量。如 JMeter 工具支持分布式压测,即多台机器同时执行同一个脚本,然后统计结果。
注意事项
性能测试环境一定要是干净的:后台服务器除了自己没有其他人在用;测试元素不能有其他;本机一切影响网络的都要关掉。
如果是在生产环境压测,则注意是否有脏数据,以及测试后的数据清理机制。
最好每轮性能测试都重启机器,这样垃圾回收和缓存的影响能降到最小。
业务指标:并发数、响应时间、吞吐量等
系统资源指标:
Java 应用:JVM 监控、JVM 内存(堆区)、Full GC 频率等
数据库:慢查询、连接数、锁、缓存命中率
压测机资源:CPU 使用率、内存使用率、磁盘空间使用率(测试日志的产生)、网络带宽使用率
一般情况下,测试人员只需要关注 1、2、5,来判断系统是否存在性能问题。
而开发人员要定位性能问题时,一般会再次复现场景,并监控所有的性能指标,来进行分析并调优。
要对性能测试指标进行监控,可以使用系统自带的监控工具,也可以使用第三方监控工具或者监控平台。
业务指标
系统资源指标
Java 应用
数据库
压测机资源
nmon 是一款快速获取 linux 系统资源的小工具。
下载与安装
前台运行使用
很多情况下,都会出现 dump 这个字眼,jvm 中也不例外,其中主要包括内存 dump、线程 dump。
首先,内存dump是指通过 jmap -dump
当发现应用内存溢出或长时间使用内存很高的情况下,通过内存 dump 进行分析可找到原因。
当发现 cpu 使用率很高时,通过线程 dump 定位具体哪个线程在做哪个工作占用了过多的资源。
获取及分析方法详见《性能测试瓶颈调优》JVM dump 内容部分。
使用本地 jvisualvm 远程监控服务器的步骤如下:
-Dcom.sun.management.jmxremote
-Djava.rmi.server.hostname=182.92.91.137
-Dcom.sun.management.jmxremote.port=10086
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
进入本地 jdk 安装目录的 bin 目录,找到 jvisualvm.exe 并启动。
右键“远程”选择“添加远程主机”,并输入步骤 1 配置的远程服务器 IP。
性能调优的步骤:
确定问题:根据性能监控的数据和性能分析的结果,确定性能存在的问题。
确定原因:确定问题之后,对问题进行分析,找出问题的原因。
确定解决方案(改服务器参数配置/增加硬件资源配置/修改代码)。
验证解决方案,分析调优结果。
注意:性能测试调优并不是一次完成的过程,针对同一个性能问题,上面的步骤可能要经过多次循环才能最终完成性能调优的目标(即:测试发现问题 -> 找原因 -> 调整 -> 验证 -> 分析 -> 再测试 ...)
具体的性能瓶颈调优分析可参考《性能测试瓶颈调优》。
按照测试报告模板来进行编写。通常包含内容如下:
自动化测试相关教程推荐:
2023最新自动化测试自学教程新手小白26天入门最详细教程,目前已有300多人通过学习这套教程入职大厂!!_哔哩哔哩_bilibili
2023最新合集Python自动化测试开发框架【全栈/实战/教程】合集精华,学完年薪40W+_哔哩哔哩_bilibili
测试开发相关教程推荐
2023全网最牛,字节测试开发大佬现场教学,从零开始教你成为年薪百万的测试开发工程师_哔哩哔哩_bilibili
postman/jmeter/fiddler测试工具类教程推荐
讲的最详细JMeter接口测试/接口自动化测试项目实战合集教程,学jmeter接口测试一套教程就够了!!_哔哩哔哩_bilibili
2023自学fiddler抓包,请一定要看完【如何1天学会fiddler抓包】的全网最详细视频教程!!_哔哩哔哩_bilibili
2023全网封神,B站讲的最详细的Postman接口测试实战教学,小白都能学会_哔哩哔哩_bilibili
如果对你有帮助的话,点个赞收个藏,给作者一个鼓励。也方便你下次能够快速查找。
如有不懂还要咨询下方小卡片,博主也希望和志同道合的测试人员一起学习进步
在适当的年龄,选择适当的岗位,尽量去发挥好自己的优势。
我的自动化测试开发之路,一路走来都离不每个阶段的计划,因为自己喜欢规划和总结,
测试开发视频教程、学习笔记领取传送门!!