首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

一款类似loadRunner的优秀国产性能测试工具——kylinTOP测试与监控平台

市面上流行的压力/负载/性能测试工具多是来自国外,近年来国内的性能测试工具也如雨后春笋般崛起,但大部分产品是基于Jmeter开源内核包装起来的性能测试工具,其中也不乏佼佼者,如:kylinTOP测试与监控平台,它是一款集性能测试、自动化测试、业务监控于一体的B/S架构的测试平台,支持跨平台(WINDOWS/LINUX/SOLARIS/麒麟/MAC)运行。该工具没有基于任何开源免费组件,是一款完全国产化的性能测试工具,是目前国内一款非常难得好用的性能测试工具,可以完全替代国外的同类产品。目前在军工领域、测评检测机构、国有企业、银行体系、大型企业有着广泛的应用。支持的协议较多,尤其在视频领域支持的协议非常多,具有独特的优势。

01

基于性能测试工具kylinTOP构建虚拟用户自身请求的并发模型

在对于WEB系统进行性能测试时,第一时间想到的是测试出WEB系统能够承受的最大并发虚拟用户(VU)用户数,因为系统的最大VU并发数可以直接反应系统的承载能力。但是人们往往忽略了VU的并发模型。什么是VU的并发模型呢?如下图所示,我们使用浏览器访问一个页面,浏览器会有多个HTTP请求发向服务端,这些请求有串行的也有并行的(water中有时间重叠的请求属于并行请求。串行请求是指:前一请求结束,后一请求才下发请求)。如果性能测试工具提供WEB录制功能并能按照浏览器的行为模型模拟VU行为,那是最好的了(如果你使用Jmeter或LoadRunner 11那么工具是无法做到的,详见:《性能测试工具Jmeter你所不知道的内幕》、《性能测试工具LoadRunner你所不知道的内幕》)。截止目前我了解到的性能测试工具:kylinTOP可以实现(Jmeter,CPTS(华为),PTS(阿里)均无法实现),但本文并是不讨论如何使用kylinTOP来录制脚本并模拟浏览器的行为,而是如何利用kylinTOP手工构建这样的场景。为什么要手工构建呢,主要是有些web系统对外提供的服务不是WEB页面,而是HTTP接口功能,对这种场景就需要我们手工来构建。

01

性能测试工具Jmeter你所不知道的内幕

谈到性能测试,大家一定会联想到Jmeter和LoadRunner,这两款工具目前在国内使用的相当广泛,主要原因是Jmeter是开源免费,LoadRunner 11在现网中存在破解版本。商用型性能测试工具对于中小型企业很难承担相关的费用。国内的性能测试工具有:CPTS(华为)、kylinTOP(奇林)、PTS(阿里)、WebTest(腾讯)等,国外的性能测试工具LoadRunner相对比较出名。Loadrunner在国内出名的原因主要还是因为LoadRunner 进入中国的市场比较早,而且网上还存在破解版本。现在我们主要研究一下Jmeter工具。网络上经常看到网友们抱怨Jmeter工具测试的结果不准,而为什么不准都是丈二的和尚摸不着头脑。那么今天我就和网友们分享一下Jmeter工具在使用上到底有什么限制,以期对网友们有帮助,提高对Jmeter工具的认知。

00

性能测试方案阐述

很多人会问,性能测试需要设计方案吗?需要测试用例(性能场景)吗?拿一个性能测试工具,比如loadrunner,对被测系统进行压测,不就是性能测试了吗?是的,这种拿性能测试工具来进行压测,就以为是做性能测试的思维,仍然存在很大一部分的人心里。 我可以大声的告诉你:不是!性能测试是一门系统性的工作,包括:测试方案的设计、性能环境的搭建,编写性能脚本进行压测,分析测试结果,调优&回归,出性能报告。针对每一个步骤,我都尽量写一篇文章来描述。如果你拿性能测试工具进行压测,那么只是其中的一小步而已。本文先重点描述如何设计性能测试方案。 首先要确认性能测试的目的是什么?有个成语叫:有的放矢。这是我们做事的原则。我遇到很多开发,他们很喜欢说一句话就是:“这个帮我压下,看下性能如何?”当然这也是目的。那我们性能测试工程师的价值体现在哪里?每天屁颠屁颠跟在开发后面,帮他压一下这个项目,帮她压一下这个页面,帮TA压一下。。。。。? 我觉得作为性能测试工程师,要从系统的性能角度出发,从用户的角度出发,如何更好的模拟用户行为?找出系统的性能瓶颈所在,预估系统的容量。性能测试方案的设计也是基于这几点出发。 为了更好的理解,举个例子,就拿www.juhuasuan.com聚划算来说明。

01

关于性能测试的这点事,干货来袭「建议收藏」

答:有些同事在测试几轮之后,功能稳定了开始介入性能测试,这时才发现性能根本支撑不了预期值。这个时候开发再回头进行系统调优,如果事先选的架构能支撑就好,如果不能达不到预期值,后面讨论或者请教高手发现原先的架构缺陷,再调整架构代价就非常大。基本导致前期的功能测试成果作废。其实各个阶段都有事情做。需求阶段可以整理,评审出性能需求,评审需求可行性时就考虑好数据量和用户量。设计阶段–对预估的需求做设计,举个例子。背景:我们现在使用的是mysql数据库(公司去oracle化),我们要从一个5000W的一个数据表的6个不同查询维度查询数据,比如说城市、行业、地址类型、爱好、性别、时间范围。这样对于mysql的查询常见的优化设计可能是分表、建立索引,但,对于这个场景就不好处理了。数据耦合强,没有办法分表。索引,组合索引太多。后面的处理办法是用mongodb、nosql的方法解决。对于编码和测试阶段可以这样去分不同阶段做不同事情。

02
领券