性能测试基础知识及性能指标 | 您所在的位置:网站首页 › 测试稳定性分析 › 性能测试基础知识及性能指标 |
目录 1.1、性能概述: 1.2 、测试目标 1.3 、性能测试方法 2 .1 、需求分析 2.2 、测试对象 2.3 、拆分对象 2.4 、指标分析 3.1 、用例设计 4.1、性能监控关键指标 结尾 🎁更多干货 前言:最近公司接了个项目,领导开会突然来了句,让我出一份性能测试方案,后面性能测试工作交给我!我心里想之前面试没要求会这个啊(最少得加钱才能做吧~,没办法既然下达了指令,那就只能照做了! 硬着头皮开搞了,小菜鸡性能测试之路慢慢进行中 在做性能方案之前,先捋一下流程,出方案给老板看,要显得自己专业,哈哈哈~ 性能流程: 制定性能指标 --> 编写测试方案-->方案评审--> 搭建测试环境--> 脚本编写(准备测试数据)--> 准备测试机器--> 执行测试--> 分析调优 终于费劲九牛二虎之力出了分方案给领导,结果他来了句没有性能指标,让我看着测(~~,没指标玩个毛) 在我一顿输出下领导妥协了,拉着产品,架构师开个会,讨论了下。结果让我先测,给出性能的最大并发和最优性能 (估计大多数小公司都是这样吧,不给性能指标,就是走个过程)那好吧给他出份报告先吧! 在做性能测试之前,我们先了解下性能基础 1.1、性能概述:性能决定了一个系统支撑其业务的能力。可以描述为系统稳定运行,高并发访问服务 不会出现宕机,用户访问页面需要的时间,系统能够支撑多少用户并发访问。也可以 描述为对资源的消耗。报告cpu,磁盘,内存,IO,网络等。 普通用户关心的是响应时间和稳定性 ⚫ 页面还要多久才能加载出来? ⚫ 页面怎么又报502 了? 开发关心的是架构和代码的性能 ⚫ 应用架构是否合理? ⚫ 技术架构是否合理? ⚫ 数据架构是否合理? ⚫ 部署架构是否合理? ⚫ 代码是否存在性能问题? ⚫ Jvm 内存分配是否合理? 运维关心的是系统资源的稳定性 ⚫ 资源使用率在正常范围吗? ⚫ 数据库连接数正常吗? ⚫ 系统有内存泄露吗? ⚫ 一个节点宕机了,剩下的还能用吗? 1.2 、测试目标通过压测来观察系统能承载的并发量,响应时间,与最大TPS 了解系统各项性能指 标,以此来评估系统的各项能力 发现系统存在的性能问题,包括 连接池问题。包括Tomcat 连接池,Jdbc 连接池,Nginx 连接池,Tcp 连接队列 内存泄露问题。内存泄露指的是系统在长时间运行过程中,内存空间得不到释 放,最终导致可用内存空间耗尽,出现内存溢出 线程死锁问题。线程死锁指的是某些线程因为资源问题长期占用线程锁,导致其 它的线程因为无法拿到锁而出现大面积阻塞 负载均衡问题。流量过高的情况下,因为负载均衡策略设置不当导致每台服务器 接受的流量不均匀,部分机器压力过大而性能急剧下降,部分机器流量过小而资 源浪费 硬件参数配置问题。例如网卡中断不均,swapiness 比例设置不当,进程优先级 设置不当导致的一系列硬件资源性能问题 1.3 、性能测试方法1.3.1、并发测试 广义并发:多个用户同时触发某个功能,或者在单位时间内同时向服务器发起多 个请求。此时设置的线程数可以表示为并发的用户数 狭义并发:单位时间内多个业务并行处理(这里强调的是业务流程,比如A-B-C D)。此时设置的线程数可以表示为并行的业务数。 1.3.2、负载测试 持续稳定地增加系统的负载,测试系统性能的变化 找出指标阈值下的系统瓶颈和性能拐点 测试系统所能承受的最大负载量**** 找到处理极限,为调优提供数据 找出系统在稳定情况下的最大压力值 1.3.3、压力测试 对系统持续保持高压运行,时间可以是几小时甚至几天。观察系统在资源饱和状态下 的处理能力。目的是发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患。同 时观察系统在长时间运行下可能出现的故障(例如反应变慢、内存泄漏系统崩溃) 2 .1 、需求分析2.1 .1 、测试目的 为什么测?目的在于测试系统相关性能能否满足业务需求。通常分以下两种情况: 新项目上线 老项目优化 2.2 、测试对象测什么?测试对象可以归结为“业务功能”。测试前需要了解待测试的业务功能(不深入 细节)有哪些,比如“购买商品”、“下单支付”。 有没有必要测?需求来源哪里?有没有数据支撑需求的必要性? 可以从以下几个方面考虑 是否核心功能,是否要求严格的质量 是否常用、高频使用的功能 可能占用系统较多资源的功能 使用人数多还是少 在线人数多还是少 2.3 、拆分对象业务上拆分,业务包含哪些流程、环节 登录->搜索商品->提交订单->支付订单->退出 需要从功能实现上来看是怎么实现的。通常这些业务功能操作都对应着一个或多个可 能是不同类型的请求。我们要做的是找出这些操作对应的请求与请求之间的关联性。 2.4 、指标分析分析性能需求指标(如“支持300 人并发登录”)是否合理?有没有必要测试这个需 求,考虑需求指标是否合理?有没有数据支撑?支撑数据可以从以下方面考虑: 采样时间段内系统使用人数 采样时间段内系统在线人数 采样时间段内系统(页面)访问量 采样时间段内请求数 2/8 法则 80%的业务量在20%的时间里完成。这里,业务量泛指访问量,请求数,数据量等 2-5-8 原则 当响应时间在2 秒以内,用户会感觉系统速度很快; 当响应时间在2-5 秒,用户会感觉系统的响应速度还可以; 当响应时间在5-8 秒以内,用户会感觉系统的速度很慢, 当响应时间超过8 秒后,用户会认为系统已经无法响应,直接离开 3.1 、用例设计4.1.1 、系统指标:系统指标则与用户场景及需求直接相关 并发用户数 平均响应时间 吞吐量 4.2 、服务器资源指标 CPU使用率: 一般可接受上限85% 内存使用率:一般可接受上限85% 磁盘I/O 网络带宽 4.3 、 JVM 应用Java运行内存划分机制: 堆区内存没有被及时释放,则存在内存泄漏 在性能测试过程中关注JVM堆区的内存,如持续在上升没有下降,则可能存在内存泄漏 内存泄漏原理: FULL GC 机制: 垃圾回收:将内存中已申请并使用完成的那部分内存空间回收,供新申请使用 垃圾回收机制针对堆区的内存进行的 JVM(JAVA虚拟机)垃圾回收机制原理: 系统在做垃圾回收时,不能处理任何用户业务,如果垃圾回收太频繁,导致系统处理业务能力下降 FULL GC内存比较大,垃圾回收一次时间较长,这段时间不能处理业务,对系统影响比较大,因此在性能测试过程中需要关注FULL GC的频率 4.4 、数据库指标 慢查询 缓存命中率 数据链接池 Mysql锁 Mysql锁概念: 对比: l 页面锁:处理效率低,但不会出现死锁 l 处理效率高,但是可能出现死锁 监控点: 需要监控在性能测试过程中,是否死锁出现,如果出现需要对代码优化 4.5 、压测机资源: CPU ---不超过80% 内存---不超过80% 网络 磁盘 好了,以上便是性能的一些基础知识,和性能的一些指标 在了解这些性能基础及指标知识后,再进行性能测试便可以更加轻松了,不然照着网上按葫芦画瓢也只是了解皮毛,反而得不出结果,完成不了上级交代的工作 通常在做性能测试的时候,编写脚本和执行只是一部分,在性能测试过程中脚本编写和执行只是占比30%例如功能测试需求分析和用例编写一样,做性能测试也是一样,要先分析,这部分也占比30%,最后再是分析调优了--占比40% 结尾学会了这些,便可以理直气壮的拍老板桌子,提出升值加薪啦! 先了解基础知识和指标,等下个月项目做完,再出一份性能执行和分析调优的分享 🎁更多干货完整版文档下载方式: 这些资料,对于从事【软件测试】等相关工作的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!以上均可以分享。 在评论区和我互动交流或者私❤我【软件测试学习】领取即可,拿走不谢。 如果我的博客对你有帮助、如果你喜欢我的博客内容,请 “👍点赞” “✍️评论” “💙收藏” 一键三连哦! |
CopyRight 2018-2019 实验室设备网 版权所有 |