性能测试知多少----性能测试分类之我见

  从这一篇开始,虫师向性能方面发力。翻看自己的博客,最早的时候热衷于jmeter,于是写了几篇图文并茂的文章(其实,主要是操作截图加文字
描述),之后,由于看到好多朋友关于性能的知识什么都不知道,下载个loadrunner
就说要做性能测试,结果可想而知,遇到各种概念与使用问题。于是写了《在做性能测试之前需要知道什么》《在做性能测试之后需要知道什么》,关于loadrunner的我没有写一篇博客,因为介绍loadrunner的网站、资料、书籍和视频太多了。我想这个系列我也会把关注点放在思想上。

 

 

 

 

性能测试常见分类                                                                     

  

  常会别人说到性能测试、负载测试、压力测试、并发测试,很多人都是混合使用,或者一会叫压力测试,一会叫并发测试。这些概念除了非测试人员分不
清楚,甚至许多专业测试人员也对这些名词也很模糊。关于这个分类我翻阅了几个本比较好的书籍,他们讲的也比较模糊,没有给出本质上的区别。只是从不同角度
和关
注点来解释。好吧我们先来看他们之间比较普遍的解释。

 

性能测试(狭义)

  性能测试方法是通过模拟生产运行的业务压力量和使用场景组合,测试系统的性能是否满足生产性能要求。通俗地说,这种方法就是要在特定的运行条件下验证系统的能力状态。

特点:

1、这种方法的主要目的是验证系统是否有系统宣称具有的能力。
2、这种方法要事先了解被测试系统经典场景,并具有确定的性能目标。
3、这种方法要求在已经确定的环境下运行。

也就是说,这种方法是对系统性能已经有了解的前提,并对需求有明确的目标,并在已经确定的环境下进行的。

负载测试

通过在被测系统上不断加压,直到性能指标达到极限,例如“响应时间”超过预定指标或都某种资源已经达到饱和状态。

特点:

1、这种性能测试方法的主要目的是找到系统处理能力的极限。
2、这种性能测试方法需要在给定的测试环境下进行,通常也需要考虑被测试系统的业务压力量和典型场景、使得测试结果具有业务上的意义。
3、这种性能测试方法一般用来了解系统的性能容量,或是配合性能调优来使用。

也就是说,这种方法是对一个系统持续不段的加压,看你在什么时候已经超出“我的要求”或系统崩溃。

压力测试(强度测试)

压力测试方法测试系统在一定饱和状态下,例如cpu、内存在饱和使用情况下,系统能够处理的会话能力,以及系统是否会出现错误

 

特点:

1、这种性能测试方法的主要目的是检查系统处于压力性能下时,应用的表现。
2、这种性能测试一般通过模拟负载等方法,使得系统的资源使用达到较高的水平。
3、这种性能测试方法一般用于测试系统的稳定性。

也就是说,这种测试是让系统处在很大强度的压力之下,看系统是否稳定,哪里会出问题。

 

并发测试

并发测试方法通过模拟用户并发访问,测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或其者他性能问题。

特点:

1、这种性能测试方法的主要目的是发现系统中可能隐藏的并发访问时的问题。
2、这种性能测试方法主要关注系统可能存在的并发问题,例如系统中的内存泄漏、线程锁和资源争用方面的问题。
3、这种性能测试方法可以在开发的各个阶段使用需要相关的测试工具的配合和支持。

也就是说,这种测试关注点是多个用户同时(并发)对一个模块或操作进行加压。

配置测试

配置测试方法通过对被测系统的软\硬件环境的调整,了解各种不同对系统的性能影响的程度,从而找到系统各项资源的最优分配原则。

特点:

1、这种性能测试方法的主要目的是了解各种不同因素对系统性能影响的程度,从而判断出最值得进行的调优操作。
2、这种性能测试方法一般在对系统性能状况有初步了解后进行。
3、这种性能测试方法一般用于性能调优和规划能力。

也就是说,这种测试关注点是“微调”,通过对软硬件的不段调整,找出这他们的最佳状态,使系统达到一个最强的状态。

可靠性测试

在给系统加载一定业务压力的情况下,使系统运行一段时间,以此检测系统是否稳定。

特点:

1、这种性能测试方法的主要目的是验证是否支持长期稳定的运行。
2、这种性能测试方法需要在压力下持续一段时间的运行。(2~3天)
3、测试过程中需要关注系统的运行状况。

也就是说,这种测试的关注点是“稳定”,不需要给系统太大的压力,只要系统能够长期处于一个稳定的状态。

上面的分类绝非全面,还有失效性测试,就是系统局部发生问题时,其它模块是否可以正常的运行。这个在极少数情况下进行,这里就不介绍了。

 

 

性能测试分类之我见                                                                  

上面的类分完了,似乎得到不少专家的认同,并无不妥。但我们在性能测试过程中真的能把它们区别分的很清楚么?你能严格区分出你这次的测试到底并发测试还是压力测试。

笔者第一点不太赞同的是对“性能测试”的定义。笔者认为性能测式测试包含了上面的所有分类。而这种性能测试的定义只是一种狭义上的“性能测试”,属于性能测试的一种。
性能测试是相对功能测试来说的。他们之间最本质的区别就是对系统有处理能力是否够成压力。如果一个用户的一个操作(比如超大数据量的查询)对系统够成了压力,我也可以视其为性能测试。

 

 

其实,可以这样来划分性能测试

  上面定交了那么多分类,是不是有点晕了。其实,以笔者认为我们进行性能测试时关注的就两点。耐力和爆发力。

  初高中时练过几年体育,最好时代表学校参加县体育比赛,不过是去垫底的。哈哈!哈一个体育运动员来说,那么多的体育项目,其实,考核他的就两方面。一是爆发力。二是耐力。

爆发力:拿一个举重选手来说,他的重点在重量上,因为你只要能举起三秒就算你成功了。关键是看你能举起一个什么样的重量。

耐力:拿一个马拉松运动员来说,你百米速度跑得再快没用。关键是这40公里路程中,最先跑到终点的人才是赢家。

整体协调性
当然,身为一个教练员,我在选拔选手的时候,除了看这个运动员的耐力和爆发力,身体的整体协调性也是我考核的一个很重要的指标。比如一个运行员身体各位部
位练得非常强壮,但右臂先天性萎缩。他的跑步成绩虽然不错。但他在跑的过程中,身体有各个部分都在分担右臂的不足。右臂影响了整个体能的发挥。

  再到系统的性能上说,爆发力就是这个系统能承受的最大压力,没准这个系统承受的压力很大。但过半个小时之间就挂掉了。耐力就是这个每系统长时间处于压
力下的稳定性,这系统超级稳定,跑个几十年都不用重启服务器。那么整体协调性就是看系统有没系统瓶颈,需不需要进行系统调优。

在做性能测试时请忘掉分类

这里只是告诉在做性能测试时不要想这个测试是属于性能测试的哪一类呢?是并发性测呢?还是压力测试?

我们还拿上面的教练员选拔选手做例子。
记得我进校体队的时候,教练说让我跑两圈。然后,我就开始围绕着操场跑起来。你说教练让我跑两圈是想看我的什么能力?
1、双腿的考核,一个是步幅,就是步与步之间的距离。一个是频率,两腿交替的频率。如果你一步拉得很大的话,那么频率一定会下降。如果想提高频率的话,那么一定会影响到步幅的大小。
2、双臂的考核,肩膀是否放松,摆臂是否有力,双臂的摆动与双腿的摆动是否协调。
3、呼吸是否匀称,目前的速度可以跑几圈。

我只做了一项体育运行,就考核了我这么多内容。我们在做一个性能测试时也不局限在某一分类上,也可能我们的一个测试包含多个分类。

《web性能测试实战》:
么多类型的性能测试看起来很吓人,实际上它他们大多是密切相关的。例如,运行8个小时来测试
系统是否可靠,而这个测试极有可能包含了可靠性能测、强度测试、并发测试、负载测试,等等。因此,在实施性能测试时决不能割裂它们的内部联系去进行,而应
该分析它们之间的关系,以一种高效率的方式来设计性能测试。

 

时间: 2024-09-19 03:40:45

性能测试知多少----性能测试分类之我见的相关文章

性能测试知多少---性能测试流程

性能测试知多少---性能测试流程 看到好多新手,在性能需求模糊的情况下,随便找一个性能测试工具,然后就开始进行性能测试了,在这种情况下得到的性能测试结果很难体现系统真实的能力,或者可能与系统真实的性能相距甚远. 与功能测试相比,性能测试在技术层面具有更大的复杂性.在以往的测试流程中,性能测试只是测试流程的一部分,是系统或验收测试的一个可选项.但随着测试技术的发展.许多公司也单独把性能测试独立出来,建立专门的性能测试小组或团队.那么性能测试在实施的过程中也需要建立独立的流程与规范. 虫师提出了自己

性能测试知多少---性能测试工具原理与架构

在性能测试的学习过程中,坚持思想与工具(分开)并行,当前面世面上的性能测试书籍大多把理论与loadrunner融为一体讲解,这样做是正确的,因为有一些性能名词概念也源于工具.但是,性能测试不是loadrunner,所有的作者也是这么认为的.但他们在讲性能测试的时候讲的就是loadrunner有,只是讲的多少不同罢啦. 你是否觉得我对loadrunner有仇?我之所以将其分开来学,只是希望自己在学习性能测试的时候不要被loadrunner局限了而已.只是觉得在做性能测试时不要带loadrunner

性能测试知多少---系统架构分析

有些事儿一旦放一放就难再拾起来,突然发现<性能测试知多少>这个系列两月没更新,关键时我都不知道啥时候放下的,总容易被各种技术所吸引走,如饥似渴的想学更多的东西,这几天一直有朋友问我为啥不写了,我才意识,事情要一样一样做,我现在要把这个系列完成.   之前有对性能需求进行过分析,那篇主要从项目业务.背景等角度如何抽丝剥茧的将项目的需求抽离出来.在我们进行需求的时候也需要对被测项目的架构有一定的认识,如果不了解被测系统的架构,那么在后期的性能分析与调优阶段将无从下手.   简单系统架构介绍    

性能测试知多少---性能分析与调优的原理

最近一直纠结性能分析与调优如何下手,先从硬件开始,还是先从代码或数据库.从操作系统(CPU调度,内存管理,进程调度,磁盘I/O).网络.协议(HTTP, TCP/IP ),还是从应用程序代码,数据库调优,中间件配置等方面入手. 单一个中间件又分web中间件(apache .IIS),应用中间件(tomcat .weblogic .webSphere )等,虽然都是中间件,每一样拎出来往深了学都不是一朝一夕之功.但调优对于每一项的要求又不仅仅是"知道"或"会使用"这么

性能测试知多少---测试工具介绍

继续这个系列的学习,这一节重点介绍目前流行的性能测试工具以及如何选择适合项目的工具.在此之前,我已经对性能测试工具的原理与架构做了分析. http://www.cnblogs.com/fnng/archive/2012/07/31/2617546.html      性能测试工具的选择与评估                                                 在性能工具原理与架构一章中,我们了解到性能测试工具的原理通常是:通过录制.回放脚本,模拟多用户同时访问被测试系

性能测试知多少---性能需求分析

需求分析是个繁杂过程,它并非我们想象的那么简单,而性能测试需求除了要对系统的业务非常了解,还需要有深厚性能测试知识.才能够挖掘分析出真正的性能需求.   如何获得有效的需求   1.客户方提出 客户方能提出明确的性能需求,说明对方很重视性能测试,这样的企业一般是金融.电信.银行.医疗器械等:他们一般对系统的性能要求非常高,对性能也非常了解.提出需求也比较明确. 曾经有一个银行项目,已经到最后的性能测试极端,因为数据库设计不合理,导致性能出现很大的问题,最终不得不把整合项目 作废,对于这样的项目,

性能测试知多少---并发用户

在做性能测试的时候,我们常常听到并发用户.响应时间.吞吐量专业术语,也许大家都理解,这里有一个理解的层次与深度概 念.最近有看断念<软件性能详解与案例分析>一书,看了他的讲解,原来我对这些术语的理解还是比较肤浅,其实,这里也主要受制于自己的知识面.所以,再拿 出来与大家重温一下.  ps:按照惯例先上个图,因为看纯文字的文章比较累!^_^     并发用户数 大家都知道我们的性能测试就通过工具模拟多用户对系统进行操作,对系统造成压力,来验证系统的性能(不太标准的解释). 好多人也简单的把性能测

性能测试知多少---测试环境搭建

在进行性能则试前,需要完成性能测试的搭建工作,一般包括硬件环境.软件环境及网络环境,可以要求配置和开发工程师协助完成,但是作为一个优秀性能测试工程师,这也是你的必备技能之一.   性能测试环境与功能测试环境的区别                                                  那么性能测试环境与功能测试环境有什么不同呢?性能测试对测试环境的干净.独立性要求更高,更为严格.对于一个相对较规范的公司,都会建立其独立的研发环境.测试环境.线网环境(最终运行软件的环境)

性能测试知多少---响应时间

在上一节中,我们讲到吞吐量,做为一个用户你可以对吞吐量毫不关心,但响应时间却是用户感受系统性能的主要体现. 从用户角度来说,软件性能就是软件对用户操作的响应时间.说得更明确一点,对用户来说,当用户单击一个按钮,发出一条指令或在web页面上单击一个链接,从用户单击开始到应用系统把本次操作的结果以用户能察觉的方式展示出来,这个过程所消耗的时间就是用户对软件性能的直观印象.     响应时间过程分析 我们需要对这个过程进行分解,才能得到你真正想要的响应时间.我把整个过程分三个部分,呈现时间,数据传输时