爆肝整理,性能测试-测试工具选型(各个对比)卷起来...


前言

性能测试和功能测试不同,性能测试的执行是基本功能的重复和并发,需要模拟多用户,在性能测试执行时需要监控指标参数,同时性能测试的结果不是那么显而易见,需要对数据进行分析。这些特点决定了性能测试更适合通过工具来完成。

从性能测试的定义的角度来分析,性能测试是指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

如果不使用工具,仅靠人工进行性能测试会存在以下的弊端:

测试需要投入大量的资源:
为了模拟多种负载、并发的场景需要多人协同工作,通常测试没有很多的资源,而且就算有资源人工的效果也会大打折扣,甚至于某些场景仅凭人工是无法完成的。

可重复性非常差:
性能测试经常需要反复调优和测试执行,如果没有工具的帮助,全靠人工实在不敢想象。

测试准确性较差:
由于需要模拟多种负载和并发场景,如果由人工来操作,难免会存在误差,而且相对工具或程序来说这种误差会更大,对测试结果影响也非常大。

结果的收集、整理和呈现形式差:
如果没有工具,全凭人工采集数据相对工具来说也会存在较大的误差。

性能测试与性能测试工具的关系

1、性能测试从测试阶段来划分属于系统测试,其和具体使用什么工具并没有直接的关系。使用工具只是为了提高性能测试效率和准确性的一种方法和手段。从本质上来看,同做其它事情时使用工具没有什么实质性的区别。

2、性能测试不等于Loadrunner,LR只是性能测试工具其中的一种,而且它也不是万能的,在某些情况下它也并不能派上用场。

3、自动化测试工具与性能测试工具的区别:性能测试工具一般是基于通信协议的(客户器与服务器交换信息所遵守的约定),它可以不关心系统的UI,而自动化使用的是对象识别技术,关注UI界面。自动化无法或很难造成负载,但是通过协议很容易。

性能测试工具选型

通常在公司或项目中,我们选择任何工具时都会做一些调研,目的就是为了选择适合公司或项目的工具。那么性能测试工具也不例外,通常可以从以下几个方面进行考虑:

1、成本方面
工具成本:工具通常分为商业闭(shou)源(fei)和非商业开(mian)源(fei)两种,商业工具通常功能比较强大,收费,由于收费所以可提供售后服务,如果出了问题有专业人士帮忙处理。

而开源工具通常是免费的,功能有限,维护工具的组织也是自发的,所以如果碰到问题需要自行解决,没有专人提供服务。具体选择商业还是开源的工具,需要根据公司的情况,比如公司规模、愿意承担的成本、项目综合情况等方面考虑。

一般来看大公司通常可以承担的起工具的费用,会考虑购买商业工具。而小公司由于资金压力,可能会选择开源的工具。

学习成本:使用任何工具都需要进行学习,这样一来就会产生学习成本(比如:时间),因此我们在选择工具时也需要考虑到项目组成员的学习成本。

如果有两种工具A和B都能满足项目组测试的需求,如果A工具大部分人都会使用,而B工具只有极少部分人会使用,那么建议优先考虑A工具。

通常,对于测试人员最好熟悉一款流程的商业(性能)工具,一款开源免费(性能)工具,还需要熟悉常见的(性能)脚本开发语言等,这是基本要求。

2、支持的协议
性能测试通常跟协议联系非常紧密,比如B/S的系统通常使用http协议进行客户端和服务器商的信息交换,C/S的系统通常使用socket协议进行信息交换。在选择工具时,需要考虑项目使用的协议。一个测试工具能否满足测试需求,能否达到令人满意的测试结果,是选择测试工具要考虑的最基本的问题。

3、生命力
现在的性能测试工具非常多,比如LR,jmeter这类较大众的工具网上相关的资料非常多,但一些小众工具可能网上资料比较少。

如果在工具使用过程中碰到了比较极手的问题,在录求解决方案或帮助时,大众的的工具相对来说会比较有优势一点,毕竟使用的人越多,资料越多,那么自己碰到的问题也许别人早就碰到并解决了,即时之前没有人碰到过,由于使用研究的人多,通过社区或论坛的帮助相信总会有高手能协助解决的。

4、跨平台:
这一点自不必多说,看看JAVA为什么一直这流行就知道了。

常见性能测试工具

性能测试工具,从理论上来讲在性能测试过程中使用到的所有工具都可以称其为性能测试工具,通常分为以下几类:

请添加图片描述

说明:
服务器端性能测试工具:需要支持产生压力和负载,录制和生成脚本,设置和部署场景,产生并发用户和向系统施加持续的压力。

web前端性能测试工具:需要关于心浏览器等客户端工具对具体需要展现的页面的处理过程。

移动端性能测试工具:同web端性能测试工具也需要关心页面的处理过程,另外还要具体数据采集的功能,比如:手机CPU、内存、电量,启动时间等数据的记录。

资源监控工具:这个主要是能够收集性能测试过程中的数据以及良好的结果展现方式。

常见性能测试工具特点

JMeter:采用的是多线程模型,扩展性很强,不过制造压力没有那么高。它很适合用来压一些Tomcat服务,或者一些后端接口。JMeter的缺点是压力值不能精确控制,难以适应高并发的情况,而且由于是JAVA编写的,本身比较消耗资源。

LoadRunner:更像是一个模拟器,它比较适用于前端构造较复杂场景的情况,比如模拟100个用户登录的场景,LoadRunner对非技术人员提供了很好的支持。LoadRunner不适用后端接口。

JMeter和LoadRunner对比表:

描述 JMeter LoadRunner
架构原理 通过中间代理,监控和收集并发客户端的指令,把他们生成脚本,再发送的应用服务器,再监控应用服务器反馈的过程 同JMeter
安装 简单,解压即可,比较灵活 LoadRunner安装包比较大,安装比较麻烦,工具本身相对比较笨重
支持的协议 支持多种协议:HTTP、HTTPS、SOAP、FTP、Database via JDBC、JMS等,但相对LR还是不够全面,由于此原因相对来说jemter比较灵活,轻便 支持的协议非常多,比较全面,但正因此显得工具本身比较笨重,不够灵活
脚本录制 提供了一个利用本地ProxyServer(代理服务器)来录制生成测试脚本的功能,也支持badboy录制再生成JMeter脚本 自带录制功能强大,可直接录制回放
并发模型 通过增加线程组的数目,或者是设置循环次数来增加并发用户 支持多种并发模型,通过在场景中选择要设置什么样的场景,然后选择虚拟用户数
分布式测试 支持,可设置多台代理,通过远程控制实现多台机器并发压力 同JMeter
资源监控 通过JMeterPlugins插件和ServerAgent实现 自带资源监控功能
报告分析 通过与Ant集成,生成HTML报告 自身支持生成HTML、Word报告
虚拟IP 不支持 支持
网速模拟 不支持 支持
扩展性 开源,可根据需求修改源码 通过扩展函数库实现
学习成本 主要是自学官网上的资料 网上资料和相关培训很多,购买正版的话,还有技术支持
下面是我整理的2023年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

请添加图片描述

二、接口自动化项目实战

请添加图片描述

三、Web自动化项目实战

请添加图片描述

四、App自动化项目实战

请添加图片描述

五、一线大厂简历

请添加图片描述

六、测试开发DevOps体系

请添加图片描述

七、常用自动化测试工具

请添加图片描述

八、JMeter性能测试

请添加图片描述

九、总结(尾部小惊喜)

每一次的努力,都离成功更近一步;每一次的挫折,都是成长的催化剂。不要怕失败,勇敢面对困难,坚持不懈追逐梦想,只有这样,你才能成为自己渴望成为的人。相信自己,奋斗不止!

只有努力拼搏,才能收获辉煌;只有坚持奋斗,才能追逐梦想;只有勇往直前,才能走向成功的彼岸。不忘初心,砥砺前行,你定能创造属于自己的辉煌人生!

只有拼尽全力,才能让梦想绽放光芒;只有坚持不懈,才能跨越人生的高峰;唯有永不放弃,才能成就辉煌的未来。奋斗吧,向着成功的方向,勇往直前!

猜你喜欢

转载自blog.csdn.net/csdnchengxi/article/details/131501814
今日推荐