性能测试的关键是什么 一般性能测试的关键是什么 是什么意思

博客访问: 1181508
博文数量: 378
博客积分: 10161
博客等级: 上将
技术积分: 5117
注册时间:
IT168企业级官微
微信号:IT168qiye
系统架构师大会
微信号:SACC2013
分类: LINUX
性能(或称多用户并发性能测试)、负载测试、强度测试、容量测试是性能测试领域里的几个方 面性能测试(Performance&Test):通常收集所有和测试有关的所有性能,通常被不同人在不同场合下进行使用。测试软件在系统中的运行性能,度量系统与预定义目标的差距。关注点:how much和how fast负载测试(Load Test):负载测试是一种性能测试,指数据在超负荷环境中运行,程序是否能够承担。通 过逐步增加系统负载,确定在满足性能指标的情况下,系统所能承受的最大负载量。关注点:how much强度测试(Stress Test): 强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况,目的是找到系统在哪里失效以及如何失效的地方。包括Spike&testing:短时间的极端负载测试Extreme testing:在过量用户下的负载测试Hammer testing:连续执行所有能做的操作压力测试:通过逐步增加系统 负载,确定在什么负载条件下系统处于失效状态,以此来获得系统能提供的最大服务级别。容量测试(Volume Test):确定系统可处理同时在线的最大用户数,使系统承受超额的数据容量来发 现它是否能够正确处理。关注点:how much(而不是how fast)容量测试,通常和数据 库有关,容量和负 载的区别在于:容量关注的是大容量,而不需要表现实际的使用。其中,容量测试、负载测试、强度测试的英文解释为:Volume Testing = Large amounts of dataLoad Testing = Large amount of usersStress Testing = Too many users, too much data, too little time and too little room举例:一个人背X斤负载测试:200斤情况下,是否能坚持5分钟。压力测试:200,300,400...斤情况下,他的表现,什么时候失败,失败之后什么表现,重新扛200是否正常。容量测试:在坚持5分钟的情况下,他一次最多能扛多少斤。& &负载测试[/url]:负载测试是 一种性能测试[/url],指数据在超负 荷环境中运行,程序是否能够承担。 强度测试:强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况。容量测试:确定系统可处理同时在线的最大用户数。1.强度测试或压力测试:强度或压力测试是在一种需要异常数量、频率或资源的方式下,执行可重复的负载测试,以检查程序对异常情况的抵抗能力,找出性能瓶 颈。异常情况,主要指那些峰值、极限值、大量数据的长时间处理等,包括:连接或模拟了最大(实际或实际允许)数量的客户机; 所有客户机在长时间内执行相同的、性能可能最不稳定的重要业务功能;已达到最大的数 据库[/url]大小,而且同时执行多个查询或报表事务当中断的正常频率为每秒一至两个时,运行每秒产生十个中 断的测试;运行可能导致虚存操作系统[/url]崩溃或大量数据对磁盘进行存取操作的测试用例等。压力 测试可以分为稳定性测试和破坏性测试:稳定性压力测试。在选定的压力值下,持续运行24小时以上的测试。通过压力测试,可以考察各项性能指标是否在指定范围内,有无内存泄漏、有无功能性故障 等。 破坏性压力测试。在压力稳定性测试中可能会出现一些问题,如系统性能明显降低,但很难暴露出其真实的原因。通过破坏性不断加压的手段,往往能快速造成系统 的崩溃或让问题明显的暴露出来。&在压力测试中,会给程序加上一些跟踪机制(如log日志[/url] 等),然后查看监视系统、服务器等性能的日志文件是必要的,找出问题出现的关键时间或检查测试运行参数,通过分析问题或参数从而有目的地调整测试策略或测 试环境,使压力测试结果真实地反映出软件的性能。2.性能测试系统的性能指标,一般赢在产品需求文档中有明确定义,有三种形式描述软件系统的性能指标:给出产品性能的主要指标,如在100000记录中查询一个特定数据的时间为0.5秒。以某个已发布的版本为基线,如比上一个版本的性能提高30-50%。 和竞争对手的同类产品比较。&性能测试,根据其目的分为:产品性能质量测试,通过测试,决定产品是否达到产品规格书所要求的性能指标(非功能性需求)基准值测试,通过对当前产品的性能 测试,确定产品具体的性能指标,建立性能指标基准。基准值,作为后继产品发布的性能参考(在新版本中,性能指标要求只升不降)或和竞争对手产品比较的参 考。&性能规划测试,通过不断的测试,确定所需要的硬件配置(内存、CPU、网络等)、软件配置,以满足实现定义的性能指标要求。这种测试,对于软件系统的部署 是非常有意义的。同时,也可以进一步了解硬件参数、软件参数对系统性能的影响程度,从而保证系统具有很好的扩充性或事先制定较好的系统增容的计划。&性能测试的方法,主要有:稳定压力加载,一次性将负载加到某个水平,持续一段时间,也称为flat测试。 逐渐加载或交替加载到某个负载水平,也称为“ramp-up”测试。 峰谷测试,确定从系统高峰时间的负载转为几乎空闲、再攀升到高负载这样峰值交替情况下的系统性能状态/指标。这种测试兼有容量测试的特点或属于容量测试的 一部分。&性能测试,一般都通过测试[/url] 来模拟人为的操作而进行。性能测试的重点在于测试环境的建立、前期数据的与后期数据的分析。因为性能测试需要获得一定特定条 件下(如100、200、500、1000个实时的连接)的系统占用资源(CPU、内存等)数据或系统行为表现,而且还要依靠测试工具或软件系统记录下这 些指标变化的数据结果。例如,如果对一个Browser/Server结构的网络实时在线的培训系统软件进行测试,系统性能焦点是在不同数量的并发连接 下,服务器的CPU、内存的占用率、客户端的响应时间等。测试过程中,并发连接的不断增加(负载的增加)在系统性能上的表现越来越明显。在系统性能测试 时,加载过程中,每到一个测试点时须让系统平稳运行一段时间后再获取数据,以消除不同测试点的相互影响。从表中可以看出,同样是300个用户,1?00与 60?的性能表现差别很大,加载的方式对系统性能影响也较大,所以,尽量模拟不同的加载方式来进行系统的性能测试。除此之外,还可以测试TCP、 HTTPS等不同连接方式下的数据,进行比较。通过比较和分析,可以清楚知道系统的性能状况,以及什么样的条件下系统性能达到最佳状况、什么地方是性能的 瓶颈。性能测试要求测试环境应尽量与产品运行环境保持一致,应单独运行,尽量避免与其 他[/url]软件同时使用。3.容量测试通过 性能测试,如果找到了系统的极限或苛刻的环境中系统的性能表现,在一定的程度上,我们完成了负载测试和容量测试。容量可以看作系统性能指标中一个特定环境 下的一个特定性能指标,即设定的界限或极限值。容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值(如最大并发用户数、数据库记录 数等),系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作[/url]量。对软件容量的测试,能让软件开发商或用户了解该软件系 统的承载能力或提供服务的能力,如某个电子商务网站所能承受的、同时进行交易或结算的在线用户数。知道了系统的实际容量,如果不能满足设计要求,就应该寻 求新的技术[/url]解决方案,以提高 系统的容量。有了对软件负载的准确预测,不仅能对软件系统在实际使用中的性能状况充满信心,同时也可以帮助用户经济地规划应用系统,优化系统的部署。& &压力测试、容量测试和性能测试的关系:压力测试可以看作是容量测试、性能测试和可靠性测试的一种手段,不是直接的测试目标。压力测试的重点在于发现功能 性测试所不易发现的系统方面的缺陷。而容量测试和性能测试是系统测试的主要目标内容,也就是确定软件产品或系统的非功能性方面的质量特征,包括具体的特征 值。容量测试和性能测试更着力于提供性能与容量方面的数据,为软件系统部署、维护、质量改进服务,并可以帮助市场定位、销售人员对客户的解释、广告宣传等 服务。压力测试、容量测试、性能测试,测试的方法相似、相通,在实际测试工作中,往往结合起来进行,以提高测试效率。一般会设置专门的性能测试实验室,完 成这些工作。即使用虚拟的手段模拟实际操作,所需要的客户端有时还是很大的,所以性能测试实验室的投资较大。
阅读(8731) | 评论(0) | 转发(1) |
相关热门文章
给主人留下些什么吧!~~
请登录后评论。软件测试一般都用到哪些工具_百度知道
软件测试一般都用到哪些工具
常用的软件测试工具一般是:QTP+LoadRunner+QC软件测试中还需的工具如下:功能测试工具:QTP(HP),WinRunner(MI),Robort(IBM),QARun(Compuware)性能测试工具:LoadRunner(HP),WAS(MS),Robort(IBM)【必须下载相应的插件才支持性能方面的测试】,QALoad(Compuware)测试管理工具:TestDirector/Quarlity Center【这两个工具一个横版一个竖版,功能完全一样】,Rational TestManager缺陷跟踪工具:Bugzilla、Mantis其他:Rational Purify、Rational PureCoverager一般测试流程:需求分析阶段:只要就是对业务的学习,分析需求点。测试计划阶段:测试组长就要根据SOW开始编写《测试计划》,其中包括人员,软件硬件资源,测试点,集成顺序,进度安排和风险识别等内容。测试设计阶段:测试方案一般由对需求很熟的高资深的测试工程师设计,测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介,测试思路和详细测试方法三部分的方案。《测试方案》编写完成后也需要进行评审。测试方案阶段:主要是对测试用例和规程的设计。测试用例是根据《测试方案》来编写的,通过《测试方案》阶段,测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项,用例级别,预置条件,操作步骤和预期结果。其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案,而测试方案又覆盖了测试需求点,这样才能保证客户需求不遗漏。同样,测试用例也需要评审。测试执行阶段:执行测试用例,及时提交有质量的Bug和测试日报,测试报告等相关文档
其他类似问题
为您推荐:
提问者采纳
Purify Plus安全测试,RFP:测试管理工具,WAS:变更管理工具功能测试自动化,devpartner,Jprobe,Robot:QTP,主要如下,Silk 性能测试工具测试工具分为很多种,QACenter,QAload:Loadrunner、白盒测试工具,其中缺陷跟踪还可以使用:MQC,Jmeter: Appscan,TestManager,QARun,Silk Performance单元:Junit
提问者评价
其他4条回答
Tbrule等,还有一些开源的、testbed、Cantata++ for C。不过感觉最好的还是C++test、TBrun,像C++test、Jtest,还有IBM公司的RTRT等如果是代码级别的测试的话,挺多的,像功能测试的QTP,挺多的、Insure++、Jtest。还有一些其它方面的测试软件、性能测试的Loadrunner这主要是HP公司的
有挺多的啊,性能测试的话就用LoadRunner,功能测试的话就用QTP
很多工具,有性能的,功能的,管理的,白盒的等等
看了其他人的回答,比我知道的多多了。不回答了。
您可能关注的推广
软件测试的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁2425262728293017810141521222728291234
随笔 - 3936
文章 - 404
评论 - 182
留言簿(51)
阅读排行榜
评论排行榜性能测试的艺术 - 文章 - 伯乐在线
& 性能测试的艺术
为什么要进行性能测试?
什么是好的与坏的性能?为什么性能测试在软件开发生命周期(SDLC software development life cycle)中很重要?
性能不佳的应用通常无法实现企业预期利益,花费了大量时间和金钱,但是却在用户中失去了信誉。
相比功能测试和验收测试(OAT operational acceptance testing),性能测试容易被忽略,往往在发布之后碰到性能和扩展性问题才意识到重要性。
最终用户眼中的性能
性能”是用户最终的感受。性能优异的应用在最终用户执行某项任务时不会产生过度的延迟而引起用户的不满。好的应用不会在登录时显示空屏,不会让用户走神。比如偶然的用户在购物网站上寻找和购买他们所需要的东西时,客户中心不会收到差性能的投诉。
多数应用系统在峰值时性能表现不佳。从高层看,应用由客户端软件和基础设施组成,后者包括了运行软件所需的服务器硬件和网络基础设施。另外有些应用还有第3 方服务。任何一个组成部分中出现问题,整个系统的性能就将面临灾难。您可能会简单地认为,为了保证应用性能,观察应用每个部分在负载压力下的运行状况并且 解决所出现的问题即可。这种做法往往“太少”和“太迟”了,因此只能是治标不治本。
关键业绩指标(KPIs key performance indicators)有服务和效率两种。
基于服务的:衡量应用系统为用户服务的好坏。
可用性(Availability): 终端用户可以使用的应用的总时间。可用性很重要,小小的故障也会导致大量的商务上的花费。用户无法有效地使用该应用系统,比如应用不响应或者响应慢到无法接受。)
响应时间(response time):一般指系统响应时间。即用户发起请求到收到结果的时间。响应有异步和同步两种。
基于效率的:衡量应用对基础设施的利用。
吞吐量(Throughput):应用处理速度,比如一定时间内某个页面的点击数。
利用率(Utilization):理论资源的使用率。当1000个用户同时在线时,应用消耗了多少网络带宽及在服务器内存和cpu等使用情况。
没有正式的行业标准,但是有许多非正式的标准,试图对系统的性能好坏做出评价,尤其是B/S应用。比如“页面最小刷新时间”从20秒到8秒,现在是2秒最佳。用户和企业都希望系统能够“即时响应”,但现在这样的性能很难达到的。
(Martin et al.,1988)的研究表明:
超过15 秒:基本上不适合交互。某些特定的应用,一些用户可能坐在终端等待超过15秒的时间去等待查询结果的返回, 比如公安局的网上预约系统。然而繁忙的呼叫中心运营商或期货交易商,超过15 秒无法容忍的。如果真的发系统就应该设计成可以让用户转向其他的操作,后面异步响应。
超过4秒:对于要求用户保存短暂记忆里的会话来说太长,当然交易完成之后,4-15秒的延迟是可以忍受的。
2-4 秒:超过2秒很难引起用户的高度关注。买家在输入了她的地址和信用卡号码后等待2-4秒的时间可以接受。然而如果是在早先的阶段,当她正在比较不同产品的差异时,却又是不可容忍的。
低于2 秒: 用户需要记住几个响应信息时,响应时间必须很短,如果要记住更为详细的信息,则要求就更高了。
亚秒: 思想密集型的工作来说(比如写一本书),尤其是一个图形应用程序,响应时间要非常短才能够保持用户的兴趣和长时间的关注。当艺术家将图片拖曳到另一个位置时,程序必须能够立即响应。
马上响应:按键并在屏幕上出现相应的字符,或者用鼠标点击,这种响应必须几乎是瞬时的。比如游戏。
由此可见,响应时间临界点是2秒。
糟糕的性能:为何如此普遍?
IT 商业价值曲线
性能问题通常会比较晚才发现,而且越晚发现,解决成本就越高。
实线(计划)表示预期结果。方块表示部署。虚线(实际)表示实际结果,延迟上线,上线后因为性能问题产生负面效果。
性能测试成熟度
Forrester在 2006年对典型应用系统上线后发现的性能缺陷进行了调查:
图中定义了三种性能测试。
第一种是救火(Firefighting),发布前很少或从来没有性能测试。所有性能缺陷在生产环境上发现解决。这是最不可取的,却依然比较普遍。
第二种是性能验证(performance validation)。公司为性能测试在产品的后期安排了时间,生产环境会发现30%左右的性能bug。这个当前绝大多数公司的做法。
第三种是性能驱动(performance driven),生命周期中的每一阶段都考虑了性能, 生产环境会发现5%左右的性能bug。
系统设计阶段缺少性能方面的考虑
设计的时候考虑性能有望产出好性能的应用,至少也能使应用在出现意想不到的性能问题时灵活地能进行修改或重新配置。设计相关的性能问题后期才发现就很难解决,有时候甚至需要重新开发。
多数的应用基于可独立测试的组件进行开发的,组件在单独执行的时候性能可能都不错,切记必须从整体来考虑。这些组件之间的交互必须高效且扩展性好,集成后才会有好的性能。
直到最后一刻才进行性能测试
性能验证模式下,性能测试直到系统发布前才会进行,并且很少考虑到性能测试所需的时间及失败后所造成的后果。可能无法发现一些严重的性能缺陷或发现了性能问题但却没有时间解决。
可能忽略了用户的地理分布和规模等。需要考虑如下问题:
有多少终端用户会实际使用?
用户位于何处?
多少用户会同时使用?
用户如何连接到应用?
后期有多少额外的用户需要访问应用?
应用的服务器数量及网络拓扑?
将应用对网络容量产生什么影响?
了解流行度
很多公司低估其应用的人气,人是好奇的,系统发布的第一天,你估计1万次点击,结果却是100万次点击,您的应用系统就这样崩溃了!需要考虑高峰访问。
令人震惊的失败:一个真实的例子
在很多年以前,英国政府决定在互联网上公布1901年人口普查的结果。这涉及到大量的将旧文档转换成现代的数字格式文档的工作,并且还需要创建一个应用以供公众访问。
很多希望了解家族历史,24小时之后网站崩溃了。在之后的几个星期里始终无法访问,直到最后重新发布。
性能测试还不规范
目前性能调优的书籍很多,但是对医生而言,最重要的是识别病情,识别性能瓶颈比解决问题有时更难。
不使用自动化的测试工具
不使用自动化的测试工具和自动化:单单使用手工是很难完成性能测试的。
应用程序使用技术的影响
应用程序使用技术的影响:某些新技术不太方便进行测试。
如何选择性能测试工具?
web方面的测试工具比较多。但是非web的,尤其是涉及到加密和压缩的,就很少了,甚至是https,很多工具都处理不好。
性能测试工具架构
常见的性能测试工具架构:
脚本:描述用户的活动,支持不同协议。
测试管理模块: 创建并执行性能测试会话或场景。
负载生成器: 生成负载。
分析模块: 分析数据,有些还有自动分析的专家模式。
其他模块: 监控服务器和网络性能的同时,与其他软件集成。
选择性能测试工具
选择性能测试工具:
除了HTTP/S支持比较广泛,JavaScript, JSON和 Microsoft Silverlight就不一样了。
授权:比如最大虚拟用户数;能支持的额外协议;附加插件集成和特定的技术栈监控,比如Oracle, Python等,)可以与APM(application performance monitoring)与CI(continuous integration)集成。
脚本支持:稍微复杂一点的测试就需要深入脚本。考虑脚本修改的难度;考虑测试团队的技术水平,比如团队如果有python高手,直接用python功能会比具体的工具要强大得多。
解决方案与负载测试工具: 有些厂商只提供个负载测试工具,而有些提供性能测试解决方案。解决方案产花费更多,但通常功能更强大,可能包括自动需求管理,自动数据创建和管理,预性能 测试的应用程序调试和优化,响应时间预测和容量建模,APM提供类和方法层面的分析,集成用户体验(EYE)监控,管理测试结果和测试资产等。
外包:可以免去工具选型等。但是次数太多的成本太高。
其他:基于云平台的测试。节约硬件成本。缺点:次数太多的成本太高,性能指标监控未必方便。程序不稳定时代价很高。
备注:Loadrunner之类的性能测试工具,中文化和文档都做得不错,对于通用的http协议效果也可以。但是扩展性差、效率低下、价格极其昂贵。所以一般认为一谈性能就谈Loadrunner的人没有真正入门性能测试。功能测试的QTP也和Loadrunner类似。
性能测试工具集:概念验证(POC Proof of Concept)
POC至少要有两个用例:读数据和写数据。目的如下:
对性能测试工具是否适合目标应用进行技术评估。
识别脚本数据要求
评估脚本需要的编写和修改时间
展示测试工具的容量。
一般不建议超过2天。
成功或退出标准,客户已经签字。
工具的软硬件准备ok。
安装任何需要监控软件的权限。
理想情况下保证环境专有性
应用技术支持:产品专家。
应用技术支持:技术专家(比如开发)可以咨询或者应用中间件级别的架构宣讲。
用户帐户:可以安装访问
至少两套凭据登录目标应用程序。因为需要并发执行等。
两个用例,简单的读和复杂的写。
录制用例并比较异同,注意运行时和会话数据等。
修改脚本,确认用户和多用户模式都可以执行,结果正确。确保脚本无内存泄露等不良行为。
通过或者不通过
生成了数据需求。
脚本开发时间
如果是售前,要能说服客户
有效应用性能测试的基础
需要考虑的问题:
发布时要支持多少用户?6个月,12个月,2年后呢?
用户分布及如何将它们连接到应用?
发布时用户的并发? 6个月后,12个月,2年后呢?
回答会引出一些问题, 比如:
每个应用层需要的服务器规格及数量是什么?
服务器的位置?
网络基础设施的类型?
回答不出来没有关系,但是你已经开始考虑容量和扩展性了。从广义上讲,功能需求定义系统是应该做什么,非功能需求定义系统是什么样子(来自维基百科)。在软件测试中,性能测试基于基准衡量系统对性能和容量质量,包括以下内容:
应用够稳定
足够的时间
基本的非功能需求
设计合适的性能测试环境
设置现实合适的性能目标
确定并脚本化的关键use case
精确的性能测试设计
KPI(Key Performance Indicator)
应用准备OK
功能要运行稳定,不能10次运行,2次失败。避免性能测试成为频繁的bug修改实践。功能等问题会掩盖性能问题。要有严格的单元和功能测试保证。衡量标准如下:
大量数据(High data presentation):比如大量图片和冗余会话。
低效SQL(Poorly performing SQL): 比如下图:
大量应用的网络来回:容易导致延迟、带宽限制和网络拥塞等。
应用错误:比如HTTP 404,500等。
足够的时间
以下工作需要时间:
准备测试环境
配置负载注射器
识别user case(数天到数周)和脚本化
确定和创建测试数据(数天到数周)
测试环境安装配置
不冻结可能会导致脚本失效或不能代表用户行为等。
设计性能测试环境
理论上要与生产环境完全一致,但是很多原因导致不太可能,下面列出部分原因:
服务器的数量和规格: 服务器内容和架构难以复制,尽量保持规格一致,以方便提供基准。
带宽和网络基础设施:地理位置难以复制。
部署层次:建议完全一致。
数据库大小:建议完全一致。
也有公司直接在生产环境同时部署测试环境或者直接拿生产环境做性能测试,后者注意不要影响用户,包含数据和服务等。
性能测试的环境类型有:
生产环境非常接近的副本:通常不太现实。
生产环境的子集,层次一致,服务器规格一致,但是数量有所减少:建议达到的方案。
生产环境的子集,层次有缩减,服务器规格一致,但是数量有所减少:最常见的方案。
虚拟机管理程序层有管理开销
总线和网络的通信方式不同。前者没有带宽和延迟限制。在网络跨地理位置的情况尤其需要注意。建议虚拟化与生产环境一致。特别注意不要跨层虚拟化在同一机器。
物理与虚拟NIC:后者的开销更大。
可以简单理解云计算为商品化的虚拟主机,它便宜,容易部署。
可以生成大量负载注射器。
不及时关闭很贵
有时不可靠,比如配置的机器无法启动,IP被墙等。
负载注入容量
单机能模拟的虚拟用户是有限的,特别注意测试机的CPU和内存等使用率不要过载,尽量使用多的机器机进行测试。注意以下几点:
负载均衡:一些基于IP分配服务器。所以必要的时候需要使用IP欺骗。
用户会话限制:比如一个IP只能一个会话。
其他问题:
有些中间件不能用脚本表示。解决办法,从表示层入手;改用瘦客户端;自行开发工具。
衡量表示层性能:性能测试通常工作在中间件层。比如想计算用户点击复选框的时间,建议使用前端测试工具。
网络部署模式
广域网的速度通常只有256 Kb左右,网络延迟也比较大。延迟的产生基于光速:1ms/130公里以及交换机、路由器等网络设备和服务器的时延。
如果有必要,可以:1,从WAN进行性能测试;2,测试工具模拟;3,网络模拟。
环境检查表
服务器数:物理或虚拟服务器的数量。
负载均衡策略:负载均衡机制的类型。
硬件清单:CPU的类型和数目,内存,网卡的类型和数量。
软件清单:标准版本的软件清单(不包括中间件)。
中间件清单。
内部和外部链接
软件安装约束
比如安全考虑。
务实的性能目标
目标部分来自服务级别协议(SLA service-level agreement)。无论如何目标必须明确。
一致且尽早介入。
C级管理负责预算和策略决定:
o首席信息官(CIO Chief information officer)
o首席技术官(CTO Chief technology officer)
o首席财务官(CFO Chief financial officer (CFO))
o部门负责人
o服务提供者(内部和外部)
性能目标定义
主要包含可用性、响应时间、吞吐量、并发、网络利用率和服务器利用率。
在性能测试中并发是同时在线的用户。要注意并发虚拟用户和并发实际用户不一定是同一回事。估算时需要基于二八原理和峰值等。
吞吐量通常更适合衡量无状态的行为。比如浏览购物时通常不会登录,看中之后才会登录,浏览购物可以认为是无状态的。
响应时间不要随着并发的增加而大幅度增加,可以基于单个用户做基准测试。
网络利用率需要关注数据量、数据吞吐量(可能会导致吞吐量突然下降是容量问题)和数据错误率。
服务器利用率主要关注CPU、内存和I/O(磁盘和网络等)
确定和脚本化关键业务user case
关键的user case一般不会超过10个。
Use-Case检查表
记录每个步骤
输入数据和期望的响应
用户类型:新的或老用户,超级用户,客户,客服等类型。
网络:LAN或WAN
主动还是被动
基于抓包工具或录制工具书写脚本,然后单用户到多用户调通。注意脚本不要影响到并发的执行,尽量使用不同的用户等。
业务较复杂时尤其重要。
是否需要登入登出
尽量符合实际情况。
注意共存的应用和网络共享
用户凭据:比如用户名和密码。
查找规则:通过客户的姓名和详细地址,发票号和产品码甚至是通配符进行查询。
相关文件:比如图片。
需要考虑数据容量是否符合规格的大小,数据回滚等。
比如token。
数据要保密,同时性能测试工具要实现与服务器端通信的加密方式。
性能测试设计
性能测试的类型
1.pipe-clean测试。
2.容量测试。尽量接近用户实际使用。
3.隔离测试。
4.压力测试。退出标准:没有更多的用户可以登录,响应时间难以接受,或应用程序变得不可用。
5.浸泡测试,又叫稳定测试。发现内存泄漏等问题。
6.冒烟测试,只测试修改的部分。注意和其他地方的概念不一样。
pipe-clean, volume, stress和soak test通常都需要进行。
负载模型定义了user case的负载分布及并发和吞吐量的目标。通常先基于容量测试,再扩展到其他类型。注意测试数据、思考时间和步长的影响。比如搜索数据分类:
小数据模型:具体的产品名称或ID。
中数据模型:局部产品名称。
大数据模型: 通配符或最小的产品名称的内容。
需要模拟真实情况下各种user case的分布:
吞吐量模型对于已有一个用需要参考Google Analytics或WebTrends,新应用的需要估计。
思考时间代表着延迟和暂停。
步长是循环之间的间隔。
负载注入方式有:Big Bang、Ramp-up、Ramp-up (with step)、Ramp up (with step), ramp down (with step)、Delayed start。注意”with step”主要是为了方便观察。
Windows 性能工具。Linux有monitor、top,、vmstat、sar等工具。监控分为业务层、中间件层和系统层等。
通用模板如下:
o Total processor utilization %
o Processor queue length
o Context switches/second
o Available memory in bytes
o Memory pages faults/second
o Memory cache faults/second
o Memory page reads/second
o Page file usage %
o Top 10 processes in terms of the previous counters
o Free disk space %
o Physical disk: average disk queue length
o Physical disk: % disk time
o Network interface: Packets Received errors
o Network interface: Packets Outbound errors
Web和应用服务器层:比如nginx、WebLogic、WebSphere、Apache、JBOSS等。
数据库层:比如MYSQL、Oracle等。MongoDB, Cassandra和DynamoDB可以视为应用设计的一部分。
大型主机层:比如Strobe、Candle
主机层:比如亚马逊的CloudWatch。
网络层:网络错误、延迟、带宽。
性能测试过程
性能测试的方法
范围和非功能需求捕捉:通常需要几天。
性能测试环境准备
user case脚本化:一个user case通常需要半天。
创建和验证性能测试场景。1-2天。前提是创建了精确的负载模型,定义每个性能测试的结构和内容。
执行性能测试。通常需要5天左右。如果频繁重测,耗时更多。
收集数据和卸载软件。通常需要1天左右。
最后分析和报告。通常需要2-3天左右。
非功能需求分析
先决条件如下:
性能测试的截止期限
内部或外部资源OK。
测试环境的设计。尽量接近真实环境。
代码冻结。
专有的测试环境,
关键用例。识别、记录并准备脚本。
用例中的检查点。
选择的use case的输入、目标和会话数据。同时还需要考虑数据安全。
负载模型OK。
性能测试场景的数量、类型、use-case内容和虚拟用户的部署已经确定。还可能需要考虑时间,步长,注入细节等。
识别和记录应用、服务器和网络的KPI。注意需要关注基础设施。
性能测试的输出。
bug提交方式。涉及测试团队成员和报告结构。工具、资源、技术和授权。另外还有培训,在外包的时候尤其重要。常见的架构如下:
基于上述信息,可以输出:
1.制定包括资源,时间线和里程碑的高层计划
2.包括所有的依赖、相关时间线、详细的场景和use case,负荷模型和环境信息的性能测试计划。
3.风险评估。
另外还需要注意迭代。
性能测试环境准备
步骤如下:
1.足够的时间来采购设备,配置和构建环境。
2.考所有部署模型要在LAN和WAN环境实验。
3.考虑外部链接。
4.提供足够的负荷注入容量。比如云主机。
5.确保应用正确部署到测试环境。
6.软件授权。
7.部署和配置性能测试工具。
8.部署和配置KPI监控。
Use-Case脚本
针对每个user case:
o确定会话数据的要求。其中一些可能来自概念验证(POC)。
o确认并应用输入数据的要求。
o脚本单用户和多用户都可以执行。
性能测试场景构建
o 测试类型是什么(pipe-clean, volume, soak, or stress?),通常是针对user case进行单个用户(pipe-clean)测试,产生基线数据。然后加大并发和吞吐量。之后进行混合user case的容量测试。然后可能有soak和stress测试,最后还可能结合负载均衡和容灾等测试。
o思考时间和步长(尤其是压力测试)。
o负载注射器和虚拟用户的数量。
o注入方式:Big Bang, ramp-up, ramp-up/ramp-down with step, or delayed start。注意这几种方式可能是连接的。比如下图:
o测试执行控制:执行一段时间段、到达一定界限或测试数据耗尽停止或是用户介入。
o是否需要IP欺骗?
o您是否需要模拟不同的波特率?
o监控需求。
oWeb的性能测试需要考虑浏览器缓存。还需要考虑新用户,活跃用户,回归用户等。
o技术影响,比如SAP比较消耗资源。
性能测试执行
1.pipe-clean测试。
2.容量测试。
3.隔离测试
4.压力测试。
5.浸泡测试,发现内存泄漏等问题
6.其他测试,比如负载均衡,容灾等。
性能测试分析和报告
o进行最后的数据收集(可能有软件卸载)。数据要有备份。
o比较试验结果与目标,决定是否通过。
o测试报告。
性能测试分析
平均值和中值
标准偏差和正态分布: 高标准偏差表示用户体验不好。
响应时间分布
吞吐量不能增加,一般有瓶颈存在:
远程监控:Windows注册表、Web-Based Enterprise Management (WBEM)、Simple Network Monitoring Protocol (SNMP)、Java Monitoring Interface (JMX)、Rstatd(传统的基于RPC的监控工具)
客户端需要关注:CPU百分比、内存使用、页利用率、磁盘时间、磁盘空间。
好的扩展性与响应时间:
差的扩展性与响应时间:
特别注意值的突然跳跃,一般是有瓶颈存在。另外服务器的基线数据也可供参考。
性能测试与移动端
移动端的类型
混合移动应用
m. site: 很少用,IOS中用来避免Apple App Store,像移动应用,但是实质是移动网站。
运行一定时间,观察耗电量;
与其他应用同时使用,观察耗电量排行。
兼容性:系统、浏览器等组合。
移动测试设计
移动网站:考虑浏览器。可以参考Google Analytics。
移动应用:考虑API。
混合移动应用
m. site: 很少用,IOS中用来避免Apple App Store,像移动应用,但是实质是移动网站。
终端用户体验监控与性能
测试需要考虑:
参考网络图如下:
主动监控主要关注:可用性和响应时间。
Multi-Mechanize简介
Multi-Mechanize 是一个开源的性能和负载测试框架,它并发运行多个 Python 脚本对网站或者服务生成负载(组合事务)。测试输出报告保存为HTML或JMeter的兼容的XML。Multi-Mechanize最常用于web性能 和可扩展性(scalability)测试,也适用于任何python可以访问的API。尤其适合后台性能测试。稍微懂点编程的话,这个工具会远强过商业 的性能测试工具。
主要特性:
支持各种 HTTP methods
高级超链接和HTML表单支持
自动处理 Cookies
可设置HTTP头
自动处理重定向
支持 HTTP 认证
使 用标准的python安装方式。注意,需要安装matplotlib以支持作图,在centos6下面可以这样安装yum -y install python27-matplotlib。multi-mechanize采用标准的python安装方式pip install multi-mechanize或者easy_install multi-mechanize这里都以linux(centos)为例。
centos 5 安装注意:
注意安装依赖: python26 python26-devel python26-numpy* python26-tornado
要EPEL支持: http://dl.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm
# multimech-newproject my_project
# multimech-newproject my_project
# multimech-run my_project
user_groups:
threads: 6
[================100%==================]
transactions: 119
timers: 119
waiting for all requests to finish...
analyzing results...
transactions: 125
test start:
test finish:
created: ./my_project/results/results__11.47.46/results.html
12345678910111213141516171819
# multimech-run my_project&
user_groups:
threads: 6&[================100%==================]
transactions: 119
timers: 119
errors: 0waiting for all requests to finish...&analyzing results...&transactions: 125errors: 0&test start: 2013-09-13 11:47:47test finish: 2013-09-13 11:48:16&created: ./my_project/results/results_2013.09.13_11.47.46/results.html&done.
如果有出现figure没有定义,请在相关文件的头部从matplotlib导入。
测试结果参见:
每个测试项目包含以下内容:
config.cfg的配置文件。用于设定测试选项。
test_scripts/虚拟用户脚本的目录。在这里添加您的测试脚本。
results/:结果存储目录。对于每个测试都声称一个时间戳目录,里面包含结果的报告。
multimech-newproject,默认生成一个随机数的脚本。脚本v_user.py如下:
import randomimport timeclass Transaction(object):
def __init__(self):
def run(self):
r = random.uniform(1, 2)
time.sleep(r)
self.custom_timers['Example_Timer'] = rif __name__ == '__main__':
trans = Transaction()
trans.run()
print trans.custom_timers
1234567891011
import randomimport timeclass Transaction(object):
def __init__(self):
def run(self):
r = random.uniform(1, 2)
time.sleep(r)
self.custom_timers['Example_Timer'] = rif __name__ == '__main__':
trans = Transaction()
trans.run()
print trans.custom_timers
配置参数的含义如下:
run_time: duration of test (seconds) 测试的执行时间
rampup: duration of user rampup (seconds) 多少秒内发完请求
results_ts_interval: time series interval for results analysis (seconds) 结果分析时间
progress_bar: turn on/off console progress bar during test run 是否显示进度条
console_logging: turn on/off logging to stdout 是否输出到stdout
xml_report: turn on/off xml/jtl report 是否生成xml报告。
results_database: database connection string (optional) 保存结果的数据库连接字符串(可选)
post_run_script: hook to call a script at test completion (optional) 调用的善后脚本(可选)
用Python书写,测试脚本模拟虚拟用户对网站/服务/ API的请求,脚本定义了用户事务。
每个脚本必须实现一个Transaction()类。这个类必须实现一个run()方法。基本的测试脚本结构如下:
class Transaction(object):
def run(self):
# do something here
class Transaction(object):
def run(self):
# do something here
运行期间,Transaction()实例化一次,run()方法则反复调用:
class Transaction(object):
def __init__(self):
# do per-user user setup here
# this gets called once on user creation
def run(self):
# do user actions here
# this gets called repeatedly
1234567891011
class Transaction(object):&
def __init__(self):
# do per-user user setup here
# this gets called once on user creation
def run(self):
# do user actions here
# this gets called repeatedly
从结构上看,如果每次run如果需要setup和teardown,时间也会计算在run里面,会显得事务处理的时间更长。这个就需要使用定时器来精确计时。
另外脚本建议先调试之后在运行,因为Multi-Mechanize有可能报错不够精准。可以这样运行:# python v_suds.py。v_suds.py是你实际使用的脚本名。另外suds这个库好像实现时性能一般,并发200时,客户端cpu占用率经常会100%,为此web service如果要上大量用户的话,建议用其他库替代,比如soapPy。进一步提升效率可以试用python的ctypes模块,或者cython(性能接近c语言)。不过Multi-Mechanize的多进程是基于python的,实在对性能有相当高的要求,就只能全部用c书写了。
下例使用mechanize进行web测试。
class Transaction(object):
def __init__(self):
def run(self):
br = mechanize.Browser()
br.set_handle_robots(False)
resp = br.open('http://192.168.4.13/env.htm')
assert (resp.code == 200), 'Bad Response: HTTP %s' % resp.codes
assert ('service name' in resp.get_data())
class Transaction(object):
def __init__(self):
def run(self):
br = mechanize.Browser()
br.set_handle_robots(False)
resp = br.open('http://192.168.4.13/env.htm')
assert (resp.code == 200), 'Bad Response: HTTP %s' % resp.codes
assert ('service name' in resp.get_data())
下面用httplib库重写脚本,并增加定时器。通过定时器,可以分析各个步骤的耗时。
import httplibimport timeclass Transaction(object):
def run(self):
conn = httplib.HTTPConnection('192.168.4.13')
start = time.time()
conn.request('GET', '/env.htm')
request_time = time.time()
resp = conn.getresponse()
response_time = time.time()
conn.close()
transfer_time = time.time()
self.custom_timers['request sent'] = request_time - start
self.custom_timers['response received'] = response_time - start
self.custom_timers['content transferred'] = transfer_time - start
assert (resp.status == 200), 'Bad Response: HTTP %s' % resp.statusif __name__ == '__main__':
trans = Transaction()
trans.run()
for timer in ('request sent', 'response received', 'content transferred'):
print '%s: %.5f secs' % (timer, trans.custom_timers[timer])
1234567891011121314151617
import httplibimport timeclass Transaction(object):
def run(self):
conn = httplib.HTTPConnection('192.168.4.13')
start = time.time()
conn.request('GET', '/env.htm')
request_time = time.time()
resp = conn.getresponse()
response_time = time.time()
conn.close()
transfer_time = time.time()&
self.custom_timers['request sent'] = request_time - start
self.custom_timers['response received'] = response_time - start
self.custom_timers['content transferred'] = transfer_time - start
assert (resp.status == 200), 'Bad Response: HTTP %s' % resp.statusif __name__ == '__main__':
trans = Transaction()
trans.run()&
for timer in ('request sent', 'response received', 'content transferred'):
print '%s: %.5f secs' % (timer, trans.custom_timers[timer])
boom:类似ab(ApacheBench)的性能测试工具
我们先对ApacheBench做个简介,再介绍boom。
ApacheBench
ApacheBench简介
ApacheBench 是一个用来衡量http服务器性能的单线程命令行工具。原本针对Apache http服务器,但是也适用于其他http服务器。
ab工具与标准 Apache源码一起发布,免费,开源,基于Apache License。
ApacheBench安装
ubuntu 14.04 执行“apt-get install apache2-utils“即可。
ApacheBench快速入门
发送1000个http get请求到http://192.168.10.232:8000/blog,并发为10:
# ab -n1000 -c10 http://192.168.10.232:8000/blogThis is ApacheBench, Version 2.3 Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/Licensed to The Apache Software Foundation, http://www.apache.org/Benchmarking 192.168.10.232 (be patient)Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software:
tracd/1.0.1Server Hostname:
192.168.10.232Server Port:
8000Document Path:
Document Length:
330918 bytesConcurrency Level:
10Time taken for tests:
Complete requests:
1000Failed requests:
0Total transferred:
bytesHTML transferred:
bytesRequests per second:
0.74 [#/sec] (mean)Time per request:
[ms] (mean)Time per request:
[ms] (mean, across all concurrent requests)Transfer rate:
238.97 [Kbytes/sec] received
Connection Times (ms)
mean[+/-sd] median
maxConnect:
17Processing:
15076Waiting:
14957Total:
15079Percentage of the requests served within a certain time (ms)
15079 (longest request)
123456789101112131415161718192021222324252627
# ab -n1000 -c10 http://192.168.10.232:8000/blogThis is ApacheBench, Version 2.3 Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/Licensed to The Apache Software Foundation, http://www.apache.org/Benchmarking 192.168.10.232 (be patient)Completed 100 requestsCompleted 200 requestsCompleted 300 requestsCompleted 400 requestsCompleted 500 requestsCompleted 600 requestsCompleted 700 requestsCompleted 800 requestsCompleted 900 requestsCompleted 1000 requestsFinished 1000 requests&Server Software:
tracd/1.0.1Server Hostname:
192.168.10.232Server Port:
8000Document Path:
/blogDocument Length:
330918 bytesConcurrency Level:
10Time taken for tests:
1353.994 secondsComplete requests:
1000Failed requests:
0Total transferred:
bytesHTML transferred:
bytesRequests per second:
0.74 [#/sec] (mean)Time per request:
13539.943 [ms] (mean)Time per request:
1353.994 [ms] (mean, across all concurrent requests)Transfer rate:
238.97 [Kbytes/sec] received&Connection Times (ms)
mean[+/-sd] median
maxConnect:
17Processing:
15076Waiting:
14957Total:
15079Percentage of the requests served within a certain time (ms)
14618 100%
15079 (longest request)
注意Time per request:
[ms] (mean)是平均每批请求的完成时间,这里时10个请求完成的时间。Time per request:
[ms] (mean, across all concurrent requests)是平均每个请求的完成时间。
ApacheBench将只使用一个操作系统线程。很多情况下ApacheBench本身是瓶颈。当在硬件具有多个处理器核心使用ApacheBench,建议一个cpu核执行一个ab线程,但是现在cpu核数很多的情况下,比如48核,手工执行48个命令也是个体力活。
整体来说ab因为不能利用到多核、不能进行参数化、不支持http和https以外的协议等原因,只适合单个组件的粗略测试,比如Apache http。不合适业务级别的测试,如一旦后台有数据库等,ab的测试是几乎没有意义的。
ApacheBench参考
命令行帮助
Usage: ab [options] [http[s]://]hostname[:port]/path
Options are:
-n requests
Number of requests to perform
-c concurrency
Number of multiple requests to make at a time
-t timelimit
Seconds to max. to spend on benchmarking
This implies -n 50000
-s timeout
Seconds to max. wait for each response
Default is 30 seconds
-b windowsize
Size of TCP send/receive buffer, in bytes
-B address
Address to bind to when making outgoing connections
-p postfile
File containing data to POST. Remember also to set -T
-u putfile
File containing data to PUT. Remember also to set -T
-T content-type Content-type header to use for POST/PUT data, eg.
'application/x-www-form-urlencoded'
Default is 'text/plain'
-v verbosity
How much troubleshooting info to print
Print out results in HTML tables
Use HEAD instead of GET
-x attributes
String to insert as table attributes
-y attributes
String to insert as tr attributes
-z attributes
String to insert as td or th attributes
-C attribute
Add cookie, eg. 'Apache=1234'. (repeatable)
-H attribute
Add Arbitrary header line, eg. 'Accept-Encoding: gzip'
Inserted after all normal header lines. (repeatable)
-A attribute
Add Basic WWW Authentication, the attributes
are a colon separated username and password.
-P attribute
Add Basic Proxy Authentication, the attributes
are a colon separated username and password.
-X proxy:port
Proxyserver and port number to use
Print version number and exit
Use HTTP KeepAlive feature
Do not show percentiles served table.
Do not show confidence estimators and warnings.
Do not show progress when doing more than 150 requests
Accept variable document length (use this for dynamic pages)
-g filename
Output collected data to gnuplot format file.
-e filename
Output CSV file with percentages served
Don't exit on socket receive errors.
Display usage information (this message)
-Z ciphersuite
Specify SSL/TLS cipher suite (See openssl ciphers)
-f protocol
Specify SSL/TLS protocol
(SSL3, TLS1, TLS1.1, TLS1.2 or ALL)
123456789101112131415161718192021222324252627
$ ab -hUsage: ab [options] [http[s]://]hostname[:port]/pathOptions are:
-n requests
Number of requests to perform
-c concurrency
Number of multiple requests to make at a time
-t timelimit
Seconds to max. to spend on benchmarking
This implies -n 50000
-s timeout
Seconds to max. wait for each response
Default is 30 seconds
-b windowsize
Size of TCP send/receive buffer, in bytes
-B address
Address to bind to when making outgoing connections
-p postfile
File containing data to POST. Remember also to set -T
-u putfile
File containing data to PUT. Remember also to set -T
-T content-type Content-type header to use for POST/PUT data, eg.
'application/x-www-form-urlencoded'
Default is 'text/plain'
-v verbosity
How much troubleshooting info to print
Print out results in HTML tables
Use HEAD instead of GET
-x attributes
String to insert as table attributes
-y attributes
String to insert as tr attributes
-z attributes
String to insert as td or th attributes
-C attribute
Add cookie, eg. 'Apache=1234'. (repeatable)
-H attribute
Add Arbitrary header line, eg. 'Accept-Encoding: gzip'
Inserted after all normal header lines. (repeatable)
-A attribute
Add Basic WWW Authentication, the attributes
are a colon separated username and password.
-P attribute
Add Basic Proxy Authentication, the attributes
are a colon separated username and password.
-X proxy:port
Proxyserver and port number to use
Print version number and exit
Use HTTP KeepAlive feature
Do not show percentiles served table.
Do not show confidence estimators and warnings.
Do not show progress when doing more than 150 requests
Accept variable document length (use this for dynamic pages)
-g filename
Output collected data to gnuplot format file.
-e filename
Output CSV file with percentages served
Don't exit on socket receive errors.
Display usage information (this message)
-Z ciphersuite
Specify SSL/TLS cipher suite (See openssl ciphers)
-f protocol
Specify SSL/TLS protocol
(SSL3, TLS1, TLS1.1, TLS1.2 or ALL)
ab [ -A auth-username:password ] [ -b windowsize ] [ -c concurrency ] [ -C cookie-name=value ] [ -d ] [ -e csv-file ] [ -f protocol ] [ -g gnuplot-file ] [ -h ] [ -H custom-header ] [ -i ] [ -k ] [ -n requests ] [ -p POST-file ] [ -P proxy-auth-username:password ] [ -q ] [ -r ] [ -s ] [ -S ] [ -t timelimit ] [ -T content-type ] [ -u PUT-file ] [ -v verbosity] [ -V ] [ -w ] [ -x -attributes ] [ -X proxy[:port] ] [ -y-attributes ] [ -z -attributes ] [ -Z ciphersuite ] [http[s]://]hostname[:port]/path
ab [ -A auth-username:password ] [ -b windowsize ] [ -c concurrency ] [ -C cookie-name=value ] [ -d ] [ -e csv-file ] [ -f protocol ] [ -g gnuplot-file ] [ -h ] [ -H custom-header ] [ -i ] [ -k ] [ -n requests ] [ -p POST-file ] [ -P proxy-auth-username:password ] [ -q ] [ -r ] [ -s ] [ -S ] [ -t timelimit ] [ -T content-type ] [ -u PUT-file ] [ -v verbosity] [ -V ] [ -w ] [ -x -attributes ] [ -X proxy[:port] ] [ -y-attributes ] [ -z -attributes ] [ -Z ciphersuite ] [http[s]://]hostname[:port]/path
命令行选项
-A auth-username:password
向服务器提供基本认证信息。用户名和密码之间":"分割,以base64编码形式发送。无论服务器是否需要(即是否发送了401)都发送。
-b windowsize
TCP发送/接收缓冲区大小,以字节为单位。
-c concurrency
并发数,默认为1。
-C cookie-name=value
添加Cookie。典型形式是name=value对。name参数可以重复。
不显示"percentage served within XX [ms] table"消息(兼容以前的版本)。
-e csv-file
输出百分率和对应的时间,格式为逗号份额的csv。由于这种格式已经"二进制化",所以比"gnuplot"格式更有用。
-f protocol
SSL/TLS protocol (SSL2, SSL3, TLS1, 或ALL).
-g gnuplot-file
把所有测试结果写入"gnuplot"或者TSV(以Tab分隔)文件。该文件可以方便地导入到Gnuplot, IDL, Mathematica甚至Excel中,第一行为标题。
显示使用方法。
-H custom-header
附加额外头信息。典型形式有效的头信息行,包含冒号分隔的字段和值(如:"Accept-Encoding: zip/8bit")。
执行HEAD请求,而不是GET 。
启用KeepAlive功能,即在HTTP会话中执行多个请求。默认关闭。
-n requests
会话执行的请求数。默认为1。
-p POST-file
附加包含POST数据的文件。注意和-T一起使用。
-P proxy-auth-username:password
代理认证。用户名和密码之间":"分割,以base64编码形式发送。无论服务器是否需要(即是否发送了407)都发送。
quiet,静默模式。不在stderr输出进度条。
套接字接收错误时不退出。
-s timeout
超时,默认为30秒。
不显示中值和标准偏差值,而且在均值和中值为标准偏差值的1到2倍时,也不显示警告或出错信息。默认显示最小值/均值/最大值。(兼容以前的版本)-t timelimit
测试进行的最大秒数。内部隐含值是"-n 50000"。默认没有时间限制。
-T content-type
POST/PUT的"Content-type"头信息。比如“application/x-www-form-urlencoded”,默认“text/plain”。
-v verbosity
详细模式,4以上会显示头信息,3以上显示响应代码(404,200等),2以上显示告警和info。
显示版本号并退出。
以HTML表格形式输出。默认是白色背景的两列。
-x -attributes
设置属性。此属性填入
-X proxy[:port]
使用代理服务器。
-y -attributes
设置属性。
-z -attributes
设置属性。
-Z ciphersuite
设置SSL/TLS加密
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384
-A auth-username:password
向服务器提供基本认证信息。用户名和密码之间":"分割,以base64编码形式发送。无论服务器是否需要(即是否发送了401)都发送。 &-b windowsize
TCP发送/接收缓冲区大小,以字节为单位。&-c concurrency
并发数,默认为1。&-C cookie-name=value
添加Cookie。典型形式是name=value对。name参数可以重复。 &-d不显示"percentage served within XX [ms] table"消息(兼容以前的版本)。 &-e csv-file
输出百分率和对应的时间,格式为逗号份额的csv。由于这种格式已经"二进制化",所以比"gnuplot"格式更有用。&-f protocol
SSL/TLS protocol (SSL2, SSL3, TLS1, 或ALL).&-g gnuplot-file
把所有测试结果写入"gnuplot"或者TSV(以Tab分隔)文件。该文件可以方便地导入到Gnuplot, IDL, Mathematica甚至Excel中,第一行为标题。&-h
显示使用方法。&-H custom-header
附加额外头信息。典型形式有效的头信息行,包含冒号分隔的字段和值(如:"Accept-Encoding: zip/8bit")。&-i
执行HEAD请求,而不是GET 。&-k
启用KeepAlive功能,即在HTTP会话中执行多个请求。默认关闭。&-n requests
会话执行的请求数。默认为1。 &-p POST-file
附加包含POST数据的文件。注意和-T一起使用。&-P proxy-auth-username:password
代理认证。用户名和密码之间":"分割,以base64编码形式发送。无论服务器是否需要(即是否发送了407)都发送。&-q
quiet,静默模式。不在stderr输出进度条。&-r
套接字接收错误时不退出。&-s timeout
超时,默认为30秒。&-S
不显示中值和标准偏差值,而且在均值和中值为标准偏差值的1到2倍时,也不显示警告或出错信息。默认显示最小值/均值/最大值。(兼容以前的版本)-t timelimit
测试进行的最大秒数。内部隐含值是"-n 50000"。默认没有时间限制。&-T content-type
POST/PUT的"Content-type"头信息。比如“application/x-www-form-urlencoded”,默认“text/plain”。&-v verbosity
详细模式,4以上会显示头信息,3以上显示响应代码(404,200等),2以上显示告警和info。&-V
显示版本号并退出。&-w
以HTML表格形式输出。默认是白色背景的两列。&-x -attributes设置属性。此属性填入&-X proxy[:port]使用代理服务器。&-y -attributes设置属性。&-z -attributes设置属性。&-Z ciphersuite设置SSL/TLS加密
结果分析字段
Server Software
返回的第一次成功的服务器响应的HTTP头。
Server Hostname
命令行中给出的域名或IP地址
Server Port
命令行中给出端口。如果没有80(HTTP)和443(HTTPS)。
SSL/TLS Protocol
使用SSL打印。
Document Path
命令行请求的路径。
Document Length
第一次成功地返回文档的字节大小。后面接受的文档长度变化时,会认为是错误。
Concurrency Level
Time taken for tests
Complete requests
收到成功响应数
Failed requests
失败请求数。如果有会打印错误原因
Write errors
写错误数 (broken pipe)Non-2xx responses
非2**响应数量。如果有打印。
Keep-Alive requests
Keep-Alive请求的连接数
Total body sent:
传输的body的数据量,比如POST的数据。
Total transferred:
总传输数据量
HTML transferred:
累计html传输数据量
Time per request:
每批平均请求时间
Time per request:
每次平均请求时间。计算公式:Time per request/Concurrency Level。
Transfer rate
数据传输速率。计算公式:otalread / 1024 / timetaken。
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354
Server Software
返回的第一次成功的服务器响应的HTTP头。&Server Hostname
命令行中给出的域名或IP地址&Server Port
命令行中给出端口。如果没有80(HTTP)和443(HTTPS)。&SSL/TLS Protocol
使用SSL打印。&Document Path
命令行请求的路径。&Document Length
第一次成功地返回文档的字节大小。后面接受的文档长度变化时,会认为是错误。&Concurrency Level
并发数&Time taken for tests
测试耗时&Complete requests
收到成功响应数&Failed requests
失败请求数。如果有会打印错误原因&Write errors
写错误数 (broken pipe)Non-2xx responses
非2**响应数量。如果有打印。&Keep-Alive requests
Keep-Alive请求的连接数&Total body sent:
传输的body的数据量,比如POST的数据。&Total transferred:
总传输数据量&HTML transferred:
累计html传输数据量&Time per request:
每批平均请求时间&Time per request:
每次平均请求时间。计算公式:Time per request/Concurrency Level。&Transfer rate
数据传输速率。计算公式:otalread / 1024 / timetaken。
boom是python替代ab的模块,并增加了部分功能。
ubuntu 14.04 执行“pip install boom“即可,注意可能需要先执行”apt-get install libevent python-dev”。它使用Gevent创建虚拟用户,使用Requests发送请求。
boom快速入门
# boom -n1000 -c10 http://192.168.10.232:8000/blogServer Software: tracd/1.0.1 Python/2.7.3Running GET http://192.168.10.232:8000/blog
Running 1000 times per 10 workers.[================================================================&.] 99% Done-------- Results --------Successful calls
1000Total time
Hahahaha-------- Status codes --------Code 200
1000 times.-------- Legend --------RPS: Request Per Second
BSI: Boom Speed Index
# boom -n1000 -c10 http://192.168.10.232:8000/blogServer Software: tracd/1.0.1 Python/2.7.3Running GET http://192.168.10.232:8000/blogRunning 1000 times per 10 workers.[================================================================&.] 99% Done-------- Results --------Successful calls
1000Total time
1355.1412 sAverage
13.5156 sFastest
8.2434 sSlowest
15.3094 sAmplitude
7.0660 sRPS
Hahahaha-------- Status codes --------Code 200
1000 times.-------- Legend --------RPS: Request Per SecondBSI: Boom Speed Index
Average:每批请求的平均处理时间。 Fastest:每批请求的最快处理时间。 Slowest:每批请求的最慢处理时间。 Amplitude:振幅,即最慢与最忙批次处理时间差。
usage: boom [-h] [--version] [-m {GET,POST,DELETE,PUT,HEAD,OPTIONS}]
[--content-type CONTENT_TYPE] [-D DATA] [-c CONCURRENCY] [-a AUTH]
[--header HEADER] [--hook HOOK] [--json-output]
[-n REQUESTS | -d DURATION]
[url]Simple HTTP Load runner.positional arguments:
URL to hit
optional arguments:
-h, --help
show this help message and exit
Displays version and exits.
-m {GET,POST,DELETE,PUT,HEAD,OPTIONS}, --method {GET,POST,DELETE,PUT,HEAD,OPTIONS}
HTTP Method
--content-type CONTENT_TYPE
Content-Type
-D DATA, --data DATA
Data. Prefixed by "py:" to point a python callable.
-c CONCURRENCY, --concurrency CONCURRENCY
Concurrency
-a AUTH, --auth AUTH
Basic authentication user:password
--header HEADER
Custom header. name:value
--hook HOOK
Python callable that'll be used on every requests call
--json-output
Prints the results in JSON instead of the default
-n REQUESTS, --requests REQUESTS
Number of requests
-d DURATION, --duration DURATION
Duration in seconds
1234567891011121314151617181920
$ boom -husage: boom [-h] [--version] [-m {GET,POST,DELETE,PUT,HEAD,OPTIONS}]
[--content-type CONTENT_TYPE] [-D DATA] [-c CONCURRENCY] [-a AUTH]
[--header HEADER] [--hook HOOK] [--json-output]
[-n REQUESTS | -d DURATION]
[url]Simple HTTP Load runner.positional arguments:
URL to hit&optional arguments:
-h, --help
show this help message and exit
Displays version and exits.
-m {GET,POST,DELETE,PUT,HEAD,OPTIONS}, --method {GET,POST,DELETE,PUT,HEAD,OPTIONS}
HTTP Method
--content-type CONTENT_TYPE
Content-Type
-D DATA, --data DATA
Data. Prefixed by "py:" to point a python callable.
-c CONCURRENCY, --concurrency CONCURRENCY
Concurrency
-a AUTH, --auth AUTH
Basic authentication user:password
--header HEADER
Custom header. name:value
--hook HOOK
Python callable that'll be used on every requests call
--json-output
Prints the results in JSON instead of the default
-n REQUESTS, --requests REQUESTS
Number of requests
-d DURATION, --duration DURATION
Duration in seconds
ab和boom在功能上远不及multi-mechanize和Grinder等主力python性能测试工具,甚至还比不上庞大且扩能能力差的loadrunner。只建议在对单个中间件的基准测试时使用。
什么是locustio?
Locust是易于使用、分布式的用户负载测试工具。用于网站(或其他系统)的负载测试,计算出系统可以处理并发用户数。
测试时大量蝗虫会攻击你的网站。每只蝗虫(或叫测试用户)可以自定义、测试过程由web界面实时监控。这能帮助测试并确定瓶颈。
Locust 完全基于的事件,单机可以支持数千用户。它不使用回调,而是基于轻量进程gevent, 能简单地实线各种场景。
Python书写场景
无需笨重的UI或XML。仅仅是代码,协程而不是回调。
分布式,可扩展和,支持成千上万的用户
基于Web的用户界面
Locust有整洁HTML + JS用户界面,实时展示测试细节,跨平台和易于扩展。
可以测试任何系统
事件完全由gevent处理。
我们研究了现有的解决方案,都不符合要求。比如Apache JMeter和Tsung。JMeter基于UI操作,容易上手,但基本上不具备编程能力。其次JMeter基于线程,要模拟数千用户几乎不可能。 Tsung基于Erlang,能模拟上千用户并易于扩展,但它它基于XML的DSL,描述场景能力弱,且需要大量的数据处理才知道测试结果。
无论如何,我们试图解决创建蝗虫,当这些问题。希望以上都不是painpoints应该存在。
我想你可以说我们真的只是想在这里从头开始自己的痒。我们希望其他人会发现,因为我们做的是有益的。
Jonatan Heyman (@jonatanheyman on Twitter)
Carl Bystr?m (@cgbystrom on Twitter)
Joakim Hamrén (@Jahaaja on Twitter)
Hugo Heyman (@hugoheyman on Twitter)
License: MIT
安装:”pip install locustio”或者”easy_install locustio”
执行”locust –help”能看到如下信息表示安装成功:
# locust --help
Usage: locust [options] [LocustClass [LocustClass2 ... ]]
-h, --help
show this help message and exit
# locust --helpUsage: locust [options] [LocustClass [LocustClass2 ... ]]&Options:
-h, --help
show this help message and exit...
主要需要 Python 2.6+,不支持python3。分布式测试还需要安装pyzmq。尽管locustio可以在Windows运行,但是考虑效率不推荐
下面我们访问/的首页和about页面。
#!/usr/bin/env python# coding=utf-8"""
Locust quickstart!
Rongzhong.Xu
"""from locust import HttpLocust, TaskSet, taskclass UserBehavior(TaskSet):
Locust test class
def on_start(self):
""" called when a Locust start before any task is scheduled """
self.login()
def login(self):
def index(self):
self.client.get("/")
def about(self):
self.client.get("/about")class WebsiteUser(HttpLocust):
The HttpLocust class inherits from the Locust class, and it adds
a client attribute which is an instance of HttpSession,
that can be used to make HTTP requests.
task_set = UserBehavior
min_wait = 5000
max_wait = 9000
123456789101112131415161718192021222324252627282930313233343536
#!/usr/bin/env python# coding=utf-8"""Locust quickstart!Copyright
Rongzhong.Xu """from locust import HttpLocust, TaskSet, taskclass UserBehavior(TaskSet):&
Locust test class
def on_start(self):
""" called when a Locust start before any task is scheduled """
self.login()&
def login(self):
def index(self):
self.client.get("/")&
def about(self):
self.client.get("/about")class WebsiteUser(HttpLocust):&
The HttpLocust class inherits from the Locust class, and it adds
a client attribute which is an instance of HttpSession,
that can be used to make HTTP requests.
task_set = UserBehavior
min_wait = 5000
max_wait = 9000
HttpLocust继承自Locust,添加了client属性。client属性是HttpSession实例,可以用于生成HTTP请求。
on_start为client初始化时执行的步骤。
task表示下面方法是测试内容,里面的数字执行比例,这里about页面占三分之一,主页占三分之二。
task_set指定client执行的类。min_wait和max_wait为两次执行之间的最小和最长等待时间。
启动locust后台
# locust --host=
[ 16:33:49,166] andrew-Hi-Fi-A88S2/INFO/locust.main: Starting web monitor at *:8089
[ 16:33:49,167] andrew-Hi-Fi-A88S2/INFO/locust.main: Starting Locust 0.7.2
# locust --host=http://automationtesting.sinaapp.com[2015-05-08 16:33:49,166] andrew-Hi-Fi-A88S2/INFO/locust.main: Starting web monitor at *:8089[2015-05-08 16:33:49,167] andrew-Hi-Fi-A88S2/INFO/locust.main: Starting Locust 0.7.2
在浏览器启动locust
打开http://127.0.0.1:8089/,配置模拟的用户数”Number of users to simulate”和每秒发起的用户数”Hatch rate”,提交执行测试。
这时在浏览器就可以看到实时的测试结果。点击浏览器上方的”stop”即可停止测试。
查看报告:
命令行按Ctrl + c , 可以显示一些摘要
# locust --host=
[ 16:33:49,166] andrew-Hi-Fi-A88S2/INFO/locust.main: Starting web monitor at *:8089
[ 16:33:49,167] andrew-Hi-Fi-A88S2/INFO/locust.main: Starting Locust 0.7.2
[ 16:42:18,656] andrew-Hi-Fi-A88S2/INFO/locust.runners: Hatching and swarming 8 clients at the rate 2 clients/s...
[ 16:42:22,663] andrew-Hi-Fi-A88S2/INFO/locust.runners: All locusts hatched: WebsiteUser: 8
[ 16:42:22,663] andrew-Hi-Fi-A88S2/INFO/locust.runners: Resetting stats
^C[ 16:48:19,884] andrew-Hi-Fi-A88S2/ERROR/stderr: KeyboardInterrupt
[ 16:48:19,884] andrew-Hi-Fi-A88S2/INFO/locust.main: Shutting down (exit code 0), bye.
--------------------------------------------------------------------------------------------------------------------------------------------
GET /about
--------------------------------------------------------------------------------------------------------------------------------------------
Percentage of the requests completed within given times
--------------------------------------------------------------------------------------------------------------------------------------------
GET /about
--------------------------------------------------------------------------------------------------------------------------------------------
12345678910111213141516171819202122
# locust --host=http://automationtesting.sinaapp.com[2015-05-08 16:33:49,166] andrew-Hi-Fi-A88S2/INFO/locust.main: Starting web monitor at *:8089[2015-05-08 16:33:49,167] andrew-Hi-Fi-A88S2/INFO/locust.main: Starting Locust 0.7.2[2015-05-08 16:42:18,656] andrew-Hi-Fi-A88S2/INFO/locust.runners: Hatching and swarming 8 clients at the rate 2 clients/s...[2015-05-08 16:42:22,663] andrew-Hi-Fi-A88S2/INFO/locust.runners: All locusts hatched: WebsiteUser: 8[2015-05-08 16:42:22,663] andrew-Hi-Fi-A88S2/INFO/locust.runners: Resetting stats&^C[2015-05-08 16:48:19,884] andrew-Hi-Fi-A88S2/ERROR/stderr: KeyboardInterrupt[2015-05-08 16:48:19,884] andrew-Hi-Fi-A88S2/INFO/locust.main: Shutting down (exit code 0), bye. Name
req/s-------------------------------------------------------------------------------------------------------------------------------------------- GET /
0.90 GET /about
0.10-------------------------------------------------------------------------------------------------------------------------------------------- Total
1.00&Percentage of the requests completed within given times Name
100%-------------------------------------------------------------------------------------------------------------------------------------------- GET /
411 GET /about
519--------------------------------------------------------------------------------------------------------------------------------------------
网页上可以下载csv文件,一个是调配记录,一个是请求记录。
# cat distribution_.45.csv
"Name","# requests","50%","66%","75%","80%","90%","95%","98%","99%","100%"
"GET /",36,250,260,260,270,370,400,410,410,411
"GET /about",17,170,180,180,200,290,520,520,520,519
"None Total",53,250,250,260,260,310,400,410,520,519
# cat requests_.05.csv
"Method","Name","# requests","# failures","Median response time","Average response time","Min response time","Max response time","Average Content Size","Requests/s"
"GET","/",36,0,250,260,206,411,
"GET","/about",17,0,170,199,146,519,
"None","Total",53,0,250,241,146,519,
1234567891011
# cat distribution_.45.csv "Name","# requests","50%","66%","75%","80%","90%","95%","98%","99%","100%""GET /",36,250,260,260,270,370,400,410,410,411"GET /about",17,170,180,180,200,290,520,520,520,519"None Total",53,250,250,260,260,310,400,410,520,519&# cat requests_.05.csv "Method","Name","# requests","# failures","Median response time","Average response time","Min response time","Max response time","Average Content Size","Requests/s""GET","/",36,0,250,260,206,411,9055,0.76"GET","/about",17,0,170,199,146,519,4456,0.36"None","Total",53,0,250,241,146,519,7579,1.12
指定测试文件启动:locust -f ../locust_files/my_locust_file.py –host=
分布式测试时作为主测试机:locust -f ../locust_files/my_locust_file.py –master –host=
分布式测试时作为从测试机:locust -f ../locust_files/my_locust_file.py –slave –master-host=192.168.0.100 –host=。master-host的默认值是127.0.0.1。
locustfile
locustfile需要定义至少一个locust类。
locust类代表用户。属性如下:
task_set属性
task_set属性指向定义了用户的行为的TaskSet类。
min_wait和max_wait属性
两次执行之间的最小和最长等待时间,单位:毫秒,即执行各任务之间等待时间。默认为1000,并且因此蝗虫永远等待1秒各任务之间如果min_wait和MAX_WAIT未声明。
用下面locustfile,每个用户将等待任务之间5到15秒:
weight属性
可以同时执行同一文件的多个locust:
# locust -f locust_file.py WebUserLocust MobileUserLocust
# locust -f locust_file.py WebUserLocust MobileUserLocust
weight标识执行比例,这里WebUserLocust的执行次数3倍于MobileUserLocust:
class WebUserLocust(Locust):
weight = 3
....class MobileUserLocust(Locust):
weight = 1
class WebUserLocust(Locust):
weight = 3
....class MobileUserLocust(Locust):
weight = 1
URL的前缀(如””)。通常在命令行使用–host选项指定。也可以设置host属性,在命令行没有指定时作为默认值。
TaskSet表示任务的集合。任务可以嵌套,比如:
Main user behaviour
Watch movie
Filter movies
Read thread
New thread
View next page
Index page
Forum page
Browse categories
About page
嵌套的python代码示例:
class ForumPage(TaskSet):
def read_thread(self):
def new_thread(self):
def stop(self):
self.interrupt()class UserBehaviour(TaskSet):
tasks = {ForumPage:10}
def index(self):
1234567891011121314151617
class ForumPage(TaskSet):
def read_thread(self):
def new_thread(self):
def stop(self):
self.interrupt()class UserBehaviour(TaskSet):
tasks = {ForumPage:10}&
def index(self):
类嵌套示例:
class MyTaskSet(TaskSet):
class SubTaskSet(TaskSet):
def my_task(self):
class MyTaskSet(TaskSet):
class SubTaskSet(TaskSet):
def my_task(self):
HttpLocust继承自Locust,添加了client属性。client属性是HttpSession实例,调用了requests,可以用于生成HTTP请求。 self.client设置了属性指向 self.locust.client。
get 和post示例:
response = self.client.get("/about")
print "Response status code:", response.status_code
print "Response content:", response.content
response = self.client.post("/login", {"username":"testuser", "password":"secret"})
# getresponse = self.client.get("/about")print "Response status code:", response.status_codeprint "Response content:", response.content# postresponse = self.client.post("/login", {"username":"testuser", "password":"secret"})
注意失败的任何请求如连接错误,超时等不产生异常,而是返回None,status_code是0。
默认只要返回的不是2都是失败。也可以设置失败和成功:
with client.get("/", catch_response=True) as response:
if response.content != "Success":
response.failure("Got wrong response")
with client.get("/does_not_exist/", catch_response=True) as response:
if response.status_code == 404:
response.success()
with client.get("/", catch_response=True) as response:
if response.content != "Success":
response.failure("Got wrong response")&with client.get("/does_not_exist/", catch_response=True) as response:
if response.status_code == 404:
response.success()
动态参数:
# Statistics for these requests will be grouped under: /blog/?id=[id]
for i in range(10):
client.get("/blog?id=%i" % i, name="/blog?id=[id]")
# Statistics for these requests will be grouped under: /blog/?id=[id]for i in range(10):
client.get("/blog?id=%i" % i, name="/blog?id=[id]")
分布式测试
主机使用–master,它不会模拟任何用户。实际测试机需要–slave和–master-host参数。通常一个cpu核可以执行一个从机。
master的参数还有: “–master-bind-host=X.X.X.X”和–master-bind-host=X.X.X.X。
从机的参数有:”–master-port=;。
可能感兴趣的话题
关于伯乐在线博客
在这个信息爆炸的时代,人们已然被大量、快速并且简短的信息所包围。然而,我们相信:过多“快餐”式的阅读只会令人“虚胖”,缺乏实质的内涵。伯乐在线内容团队正试图以我们微薄的力量,把优秀的原创文章和译文分享给读者,为“快餐”添加一些“营养”元素。
新浪微博:
推荐微信号
(加好友请注明来意)
– 好的话题、有启发的回复、值得信赖的圈子
– 分享和发现有价值的内容与观点
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 翻译传播优秀的外文文章
– 国内外的精选文章
– UI,网页,交互和用户体验
– 专注iOS技术分享
– 专注Android技术分享
– JavaScript, HTML5, CSS
– 专注Java技术分享
– 专注Python技术分享
& 2016 伯乐在线}

我要回帖

更多关于 性能测试的目的是什么 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信