-
LoadRunner组成及其工作原理简介
2012-06-07 11:57:16
一、 LoadRunner工具组成
1、虚拟用户脚本生成器:捕获最终用户业务流程和创建自动性能测试脚本,即我们在以后说的产生测试脚本;
2、压力产生器:通过运行虚拟用户产生实际的负载;
3、用户代理:协调不同负载机上虚拟用户,产生步调一致的虚拟用户;
4、压力调度:根据用户对场景的设置,设置不同脚本的虚拟用户数量;
5、监视系统:监控主要的性能计数器;
6、压力结果分析工具:本身不能代替分析人员,但是可以辅助测试结果的分析。
二、 LoadRunner工具原理
代理(Proxy)是客户端和服务器端之间的中介人,LoadRunner就是通过代理方式截获客户端和服务器之间交互的数据流。
1、虚拟用户脚本生成器通过代理方式接收客户端发送的数据包,记录并将其转发给服务器端;接收到从服务器端返回的数据流,记录并返回给客户端。
这样服务器端和客户端都以为在一个真实运行环境中,虚拟脚本生成器能通过这种方式截获数据流;虚拟用户脚本生成器在截获数据流后对其进行了协议层上的处理,最终用脚本函数将数据流交互过程体现为我们容易看懂的脚本语句。
2、压力生成器则是根据脚本内容,产生实际的负载,扮演产生负载的角色。
3、用户代理是运行在负载机上的进程,该进程与产生负载压力的进程或是线程协作,接受调度系统的命令,调度产生负载压力的进程或线程。
4、压力调度是根据用户的场景要求,设置各种不同脚本的虚拟用户数量,设置同步点等。
5、监控系统则可以对数据库、应用服务器、服务器的主要性能计数器进行监控。
6、压力结果分析工具是辅助测试结果分析。
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/artoksxb/archive/2009/09/21/4576939.aspx内容来自《LoadRunner性能测试实战》一书。
LoadRunner由以下部分组成:- 虚拟用户发生器: Vuser Generator
- 压力调度和监控中心: Controller
- 压力产生器:Load Generator
- 压力结果分析工具: Analysis
Vuser Generator是一个集成开发环境,用于录制回放修改Vuser脚本.Controller是一个框架程序和监控程序,负责讲Vuser脚本以多进程/多线程方式在Load Generator机器上运行.Analysis是一个数据分析工具,可以安装在任何Windows平台机器上.
Loadrunner进行测试的一般步骤:
1.用户确定进行测试的业务或者交易,录制并生成脚本
2.手工修改脚本,确定脚本能回放成功
3.在Controller中对场景进行配置,启动测试,Controller控制Load Generator对被测系统的加压方式和行为
4.Controller负责搜集被测系统各个环节的性能数据.各个Load Generator会记录最终用户相应时间和脚本执行的日志
5.压力测试运行结束以后, Load Generator将数据传送到Controller中,由Controller对测试数据进行汇总
6.用Analysis对数据进行分析
7.对系统进行调优,重复进行压力测试,确定性能是否有所提高 -
【转】在做性能测试之后需要知道些什么
2012-03-14 17:55:23
之前写过一篇《在做性能测试之前应该知道什么》有博文,自我感觉讲的不好,举了两个例子,和做性能测试之前需要知道的一些要点。离我的题目有差距。二则觉得讲的不全。其实,要做性能测试需要知道的东西太多了。岂是一篇博文都能说全的。在这里表示一下愧疚之情。好多测试新手,在做完性能测试之后,不知如何对测试数据进行分析。在这里我想谈谈一些性能测试参数的相关知识。当然,也不是一篇博文就能说清道明的。只希望在你的测试道路上能给你一丝帮助。
不怕啰嗦的再次忠告,那想成为测试高手的新人,多学学基础知识。别把过多的时间放在研究新工具的使用上。工具何其多,原理差不多。不要本末倒置了。也算是自我提醒吧!
性能测试常见指标
性能测试说白了就是通过工具模拟多个用户对被测系统进行访问。然后查看系统对于多个用户发来请求的处理能力。
左边的两个小人表示两个用户,向右边服务器发送请求,然后得到服务器的响应信息。
首先,我们要保证向服务器发送的请求的正确性,当然用户向服务器发送错误的请求,服务器也会个客户端响应信息,但响应的是报错信息;所以,为了保证测试数据的有效性,我们的要保证发送请求的正确性。
为什么一般的性能测试要在局域进行?
一般我们的性能测试都是在局域网中进行的。为什么一定要在局域网中进行呢?因为局域网中不受网络限制。这个说法不能绝对。但是一般测试工具的用户并发量是不会受到局域网带宽的限制,除非你做的是十万,百万级别的用户并发。相信懂一点网络知识的人都知道,当你上网很慢的时候,比如打开某某网站很慢,你肯定会骂电信的网络不给力,而不会骂这个网站响应速度不给力。因为,请求信息的耗时大部耗在传输过程中。
所以,刚做测试时,我们群里热议论,如果我们每个人都开一个压力工具对百度网站进行加压。百度,服务器会不会挂掉。有测友说这样是不道德人。呵呵!其实,完全不必有这个担心。就一般人家用的带宽,我确保,你向百度服务器发送的请求大部分都死在半路上,就算不死到了百度服务器已经不能叫并发了。何况百度服务器的集群技术以及其他各种分压技术。所以,做性能测试不了解被测系统的架构,以及各种技术的性能。很难做出有效的测试报告。
下面我们看看性能测试的一些技术指标。
Work Load = Virtual Users
工作负荷 = 虚拟用户数
对服务器产生多大压力,可以由多少用户同时对服务器发送请求来衡量。也就是服务器的性能可以看它同时处理多少用户发送来的请求来衡量。
虚拟用户数可以用进程或线程的方式进行模拟。
response time 响应时间
从客户端将数据包发出,到接收到服务器端发来的请求。这个过程的总体时间叫response time
这个时间用来衡量的处理请求的速度(抛出网速限制的前提下)
throughput ~Ti & To
这个表示,吞吐量,吞吐量越大表示系统性能越强。1个用户跑100天和10个用户跑1分钟。当然是1个用户跑100天的吞吐量大。所以,我们要想看系统的性能应该用“吞吐率”,就是单位时间的吞吐量,比如吞吐量/秒。
站在服务器端,T-in表示“吞”;T-out表求“吐”
Ti:T-in 主要衡量客户端的能力,看客户端往服务器发送的请求数据包的吞吐率。
To: T-out 主要衡量的服务器端的能力,看服务器处理返回请求数据包的吞吐率。
Hits/Request
网页点击数/请求
Response/Successful Response
响应/成功的响应
Request与Response是对应,一个请求对应一个响应。但当客户端对服务器的压力达到一直程度后,不是每一请求都能得到响应的。去年末火了个最牛B的“电子商务”网站。12306(铁路网上订票系统),虽然有很差的用户体验,但每天还是大把的人拼命的登录(过年回家的人伤不起),甚至用外挂登录。见有网友云云点击(请求)了几十几百次才订票(响应)成功。所以,成功响应率也是很重要的一个指标。客户端发送一千个请求的成功得到响应的几率。
Hits Per Second
每秒中点击次数
和吞吐量一样,单单用点击数(hits)来衡量系统也是不合理的。所以,用每秒钟的点击数才能衡量出服务器的处理能力。
响应时间图分析
横坐标表示用户数
纵坐标表示时间
红色虚线,表求的是一种系统的理想状态。
当服务器处理10个用户请求时所用的时间是2秒(假设),当服务器处理200用户请求时所用的时间也是2秒。所以说这种状态是一种理想的状态。现实中,不管是如何超级强的服务器当用户数达到一定数量时,响应时间必会变慢。
蓝色斜线,是服务器常见的一种曲线状态。
服务器的响应时间虽然用户数量的增加逐渐变慢。
当系统出现这种斜线,应该说系统性能是相当健壮的。随着用户的增长响应时间逐渐变长。
黑色曲线,个人觉得是服务器处理能力的真实曲线状态。
为什么说黑线才是真实服务器处理能力的曲线呢?当用户处理一个用户请求是2秒(假设),当处两个用户请求是马上变成3秒(假设),当处理3个用户请求时变成4秒(假设)。再差的服务器也有个处理范围,比如是,100用户同时并发,服务器可以轻松应对,不管是10个用户还是80个用户同时请求,服务器都可以即可响应(请参考理发店模式)。只有当用户数量达到某个数量点后,服务器性能急剧下降。如上图黑色十字星处就是系统的拐角点。
我们假设有一个门,在一个时间点上可同时过10个人,不管你是同时来3个还是10个都可以在同一时间点过门,假如来了11个人,必然有一个人要等10个人过门之后才能过。那么当超过10人来过门时,过门的速度就开始变慢。那么10就是服务器性能的拐角点。我们通常做压力测试找服务器的拐角点是很重要的任务之一。
关蓝色曲线与黑色区线只是我们常见两种曲线。现实的测试中可能出现各种样式的曲线。当然还要看你做测试的细度,比如,10个用户是系统的拐点,如果你做完5个用户的一轮测试后,就是20用户的测试。那么画出来的曲线就变成斜线,拐点将被护忽略掉。
吞吐率图分析
横坐标虚拟用户数
纵坐标有吞吐率(服务器端)
红色虚线,表示一种理想的状态。
随着用户数量的增加吞吐率也在持续增加。
黑色曲线,表示现实系统的吞吐率状态。
刚开始吞吐率随着用户数量的增加逐渐变大,当大到一定程度时,逐渐平缓直到变成一条平线。
如果用户还在持续增加中,那么吞吐率有可能下降,直到系统挂掉。
为什么会是这样呢?我们通过另一个例子来说,大家都在城市生活,相信上下班高峰期都会遇到堵车。在比较重要的红绿灯路口常会见到堵车现象。假如每个绿灯可以通过10辆,前期来三五辆车,遇到绿灯,一次都过去了。到了下班高峰期,车子变多,一下来了20辆,但这个路口的绿灯每天只能通过10辆,所以,这个时候,路口的通过率不会根据车辆的增加而继续增加。
好的系统好像好有个好的交警在位置秩序,虽然车辆还在增加,但每个车辆都有条不紊等待通过路口。
不好的系统如路口赶上交警拉肚子,车辆在增加,后面车辆等得不耐烦就往前挤,结果稿得互不相让。好嘛!之后还每个绿灯可通过10辆,现在只能有一辆车从夹缝中脱离苦海了。
响应时间图与吞吐率图并不是我们一轮性能测试下来就能得到结果。需要经过多轮测试才能得到。设置不同的用户数量,得到每次的测试数据,将每次数据连接,从而得到最终系统性能曲线。关于用户数量每次增加的数量自己把握。如果,想精确,可以每次增加1个用户的方式来做,不过这样势必加大工作量,也没必要。这个需要每做完一轮测试后对数据进行分析,然后确定下轮测试所要设置的虚拟用户数。
关于,性能指标的分析,就先谈到这里。关于内容,我反复经过思考,但难免有理解有误之处。还望高手点拨。共同进步。
-
【转】《零基础学习软件测试》之LoadRunner从入门到精通*(视频)
2012-02-05 16:15:12
转自:http://www.51testing.com/?uid-116228-action-viewspace-itemid-249236
文章来源
- 文章来源:【转载】
:《零基础学习软件测试》之LoadRunner从入门到精通
0性能测试常见用语
http://www.boobooke.com/v/bbk1577
lr目录分析
http://www.boobooke.com/v/bbk1574
2.1 lr界面分析
http://www.boobooke.com/v/bbk1735
2.2 lr界面分析
http://www.boobooke.com/v/bbk17362.3 lr界面分析
http://www.boobooke.com/v/bbk1737
3 lr常用术语
http://www.boobooke.com/v/bbk1620
4 hp web tours 分析5 lr录制测试脚本
http://www.boobooke.com/v/bbk1763
6 lr回放测试脚本
http://www.boobooke.com/v/bbk1764
7 HTML和URL比较
http://www.boobooke.com/v/bbk1771
8 lr自动关联
http://www.boobooke.com/v/bbk1778
9 lr测试脚本的增强方法
http://www.boobooke.com/v/bbk1772
10 run time settings
http://www.boobooke.com/v/bbk1782
11 lr脚本编写实践过程http://www.boobooke.com/v/bbk1781
12 错误处理
http://www.boobooke.com/v/bbk1776
13 脚本调试
http://www.boobooke.com/v/bbk1777
14 java虚拟用户17 创建负载测试场景
http://www.boobooke.com/v/bbk2145
18 面向目标的场景
http://www.boobooke.com/v/bbk2168
19 分析场景
http://www.boobooke.com/v/bbk214422 性能分析基础知识
http://www.boobooke.com/v/bbk2162
23 Load Runner 8.0 Student Workbook介绍
http://www.boobooke.com/v/bbk2991
24 性能测试与调优概览
http://www.boobooke.com/v/bbk3511
25 Loadrunner再谈小布老师视频:
测试工具概述,兼LoadRunner介绍 -1-4
http://www.boobooke.com/v/bbk1046
http://www.boobooke.com/v/bbk1046.zip
http://www.boobooke.com/v/bbk1047
http://www.boobooke.com/v/bbk1047.zip
http://www.boobooke.com/v/bbk1048
http://www.boobooke.com/v/bbk1048.zip
http://www.boobooke.com/v/bbk1055
http://www.boobooke.com/v/bbk1055.zip
LR系列培训视频 - LoadRunner概述(上下)
http://www.boobooke.com/v/bbk1059
http://www.boobooke.com/v/bbk1059.zip
http://www.boobooke.com/v/bbk1060
http://www.boobooke.com/v/bbk1060.zip
LR系列培训视频 - LoadRunner安装
http://www.boobooke.com/v/bbk1061
http://www.boobooke.com/v/bbk1061.zip
LR系列培训视频 - 录制和回放测试脚本(1-3)
http://www.boobooke.com/v/bbk1063
http://www.boobooke.com/v/bbk1063.zip
http://www.boobooke.com/v/bbk1064
http://www.boobooke.com/v/bbk1064.zip
http://www.boobooke.com/v/bbk1065
http://www.boobooke.com/v/bbk1065.zip
LR系列培训视频 - LoadRunner测试Tuxedo应用系统 1-4
http://www.boobooke.com/v/bbk1067
http://www.boobooke.com/v/bbk1067.zip
http://www.boobooke.com/v/bbk1068
http://www.boobooke.com/v/bbk1068.zip
http://www.boobooke.com/v/bbk1071
http://www.boobooke.com/v/bbk1071.zip
http://www.boobooke.com/v/bbk1072
http://www.boobooke.com/v/bbk1072.zip
开源性能测试工具Curl-Loader快速实战 - 1
http://www.boobooke.com/v/bbk1808
http://www.boobooke.com/v/bbk1808.zip
开源性能测试工具Curl-Loader快速实战 - 2
http://www.boobooke.com/v/bbk1809
http://www.boobooke.com/v/bbk1809.zip
开源性能测试工具Curl-Loader快速实战 - 3
http://www.boobooke.com/v/bbk1835
http://www.boobooke.com/v/bbk1835.zip
开源性能测试工具Curl-Loader快速实战 - 4
http://www.boobooke.com/v/bbk1836
http://www.boobooke.com/v/bbk1836.zip
使用LoadRunner测试Oracle实例研究 - 1
http://www.boobooke.com/v/bbk2159
http://www.boobooke.com/v/bbk2159.zip
使用LoadRunner测试Oracle实例研究 - 2
http://www.boobooke.com/v/bbk2170
http://www.boobooke.com/v/bbk2170.zip
使用LoadRunner测试Oracle实例研究 - 3
http://www.boobooke.com/v/bbk2171
http://www.boobooke.com/v/bbk2171.zip -
【转】监控Tomcat服务器性能
2012-01-04 15:16:55
转自:http://www.51testing.com/?uid-217803-action-viewspace-itemid-805600
在进行性能测试时,一般都需要对应用服务器进行监控,监控的指标包括应用服务器的JVM使用状况、可用连接数、队列长度等信息。商业的应用服务器如WebLogic、WebSphere等都提供了Console对这些指标进行监控,在性能测试时可以很容易观察这些指标的情况。
Tomcat作为在国内得到广泛应用的J2EE服务器,在不少项目中都得到了使用。Tomcat小巧灵活、配置简单,非常适合小的WEB应用使用。但在对使用Tomcat的应用系统进行性能测试时,最头疼的问题就是不能获得应用服务器的相关性能指标数据。
其实,从Tomcat 5.0开始,Tomcat就已经为自己提供了一个用于监控应用服务器性能指标的servelet —— status servelet。安装完Tomcat 5之后,通过访问http://yourhost:port/manager/status就可以获得当时的应用服务器监控数据。
当然,为了安全起见,Tomcat 5在缺省安装时是不允许用户直接访问http://yourhost:port/manager/status的,访问的时候会给出一个403(forbidden)的错误信息。在Tomcat的Manual里说明了允许用户访问的方法:
1. 转到Tomcat的安装目录下;
2. 修改conf/tomcat-users.xml文件,在其中加入一行 <user username="servermon" password="passwd" roles="manager"/>这样就可以在访问http://yourhost:port/manager/status时给出 servermon 的用户名与口令,查看到应用服务器的相关性能指标数据。
-
【转】在做性能测试之前需要知道什么
2012-01-04 15:06:58
转自:http://www.51testing.com/html/61/n-249061.html
最近群里来了很多新朋友,大都是新做测试或准备做测试工作的,见好多新手上来就问关于LoadRunner的使用上的问题。对性能测试的理解也不是太清楚。公司说让他们对系统做个性能测试,他们听说LoadRunner是做性能测试的,在网上找了点LoadRunner的使用说明就开始对系统下刀了。对于一些大公司的专业性能测试人员来说,这个很可笑,但是这种情况是存在的,我当初刚到公司时也这么干的。
那时还真把性能测报告给整出来了,现在看来那报告没有任何意义。虽然对现在的我来说性能测试也只是只懂皮毛。但还是希望通过我这篇文章能让那些新手们对于性能测试有个入门的了解。
----//理发店模式
关于理解性能,记得我那时是看了“《LoadRunner没有告诉你的》之三---理发店模式”不管你有没有看过,我这重提一下理发店模式。
前提:
1、一个理发店有三位理发师傅
2、每位理发师傅理一个发需要一小时
3、顾客都很忙,从进理发店起最多只等三小时(等待时间+理发时间),如果三小时后还没轮到自己理发,立马走人。
思考:
这里我们来理解“最佳用户数”和“最大用户数”。
最佳用户数:
理发店的最佳状态,理发店收入最多(理发师傅没有休息时间,一直在理发),顾客满意度最高(顾客随时到随时理,无需要等待)。在一个时间点来说,三个理发师傅服务于三位顾客,那么这个最佳用户数是三。
最大用户数:
理发店的最大承受状态,理发店收入最多(理发师傅没有休息时间,一直在理发),顾客的最大忍耐度(来的顾客等待+理发需要等上三个小时)。
假如理发店生意非常好,早上一开门一下子来了一群顾客(很多),A、B、C三位顾客先理,D、E、F顾客需要等待一小时才能得到理发师傅的服务,G、H、I三位顾客等待了两小时才得到服务,后面排队的J、K、L.....等顾客,已经等了三小时还没得到服务,因为这已经得达到了他们等待的极限,所以后他们气愤和无奈离开。
当然,理发店还会不断的来新的顾客,不断有等了三小时而没有得到服务的顾客离开,但对于理发店而言,他们在一个时间点上,能服务的最大用户数是九(三位正在接受服务、三位已经等待一小时,三们已经等待两小时)。
对于最大用户数,需要注意的两点:
1、在理发店里很大,可以容纳很多位顾客(大于9),总有一部分在这里等待了三小时而没有得到服务离开,不要把等待了三小而没有得到服务的顾客纳入最大用户数里。
2、假如理发店很小,最多只能容纳六位顾客,当第七个顾客来时,虽然,我们知道他只需要等待两小时就可得到服务(这个时间是他可以接受的等待时间),但由于理发店容量有量,这第七个顾客只有改天再来了。
关于理发店原理,详细请浏览http://www.51testing.com/html/58/n-10558.html
不知道通过上面对理发店的分析,你对性能有了一些眉目。假如理发店相当于我们的系统的话,顾客就我们向服务器所发送的请求,最佳用户数和最大用户数是我们衡量一个系统的处理能力的一种方法。
----//要帐的模式
注:上图是自己找来修改的,凑合着看吧!呵呵
这个是我在给一朋友说浏览器与服务器之间交流时用到的例子,感觉比容易理解,所以拿来分享一下。
假设:
1)A、B、C三个人。
2)C欠A钱(这里不考虑多少)
3)B是专门要账
思考:
浏览器与服务器的信息传递次数:
A对B说,C欠我钱,你帮我去要。B接到指令后就去找C要钱。
B对C说,给我20块钱。
C说,没有。
B对C说,给我10块钱。
C说,没有。
B对C说,给我5块钱。
.........
最后,B回来对A说,哎呀妈呀,C那丫的忒抠门了,一分钱没有。
对于A来讲,只是来说,它只是让B问C要钱,具体的B与C之间交互了几次,A是不知道的,它所知道的就是B返回给它的结果,C一分钱没有。
浏览器与服务器传递数据的大小:
还是上面的过程,A对B说,C欠我钱,你帮我去要。B接到指令后就去找C要钱。
B对C说,给我20万块钱。
C说,没问题,没支票,只有1元硬币。
..........
B终于把钱拿回来给A。A很纳闷,怎么去了那么久,B委屈的说,丫的,C给我整了一堆硬币,太重了,路上走的慢,都快累死我了。
对于A来讲,只是来说,它只是让B问C要钱,谁知道C给的是支票还是硬币。所以,B去要钱消耗的时间就很长。
所以,要想提高浏览器对服务器的访问速度,应该减少数据传递次数与数据传递的大小。
这样就很自然的引出了浏览器的cookie
A在C哪里存了5毛钱。
A对B说,我在C哪里存了5毛钱,你去拿来我看看。B跑去问C要了5毛钱回来给A看。
过了一会,A又对B说,我在C哪里存了5毛钱,你去拿来我看看。B跑去问C要了5毛钱回来给A看。
过了一会,A又对B说,我在C哪里存了5毛钱,你去拿来我看看。这次C烦了,对B说,你把钱放自己口袋里吧,等A要的时候,你来问我5毛的人民币有没有改版,没有改版的话,你就直接把口袋里的5毛钱给A看就行了。
在这里A就相当于我们用户,B相当于浏览器,C是服务器。而cookie就是B的口袋,当然了cookie的用处还很多。比如我们登陆一个系统,提示我们是否保存密码(有的还有期限比如,一个星期或一个月),如果我们保存了,下次再访问登陆时,浏览器就已经帮我们填写好了账户密码或直接帮我们登陆。那这个账户密码就放在我们浏览器的cookie中。
为什么要说上面的例子呢?因为我们大部分的一部分性能测试是基于B/S架构系统的,理解了浏览器与服务器之间的数据传递,有助于我们理解性能测试。
----//在开始性能测试之前,我们需要知道什么?
当客户或老板把你叫来,对你说,去给我们系统做个性能测试,千万别傻傻的说“好!”然后,就走了,我以前这么干过(那时不懂,打肿了脸充胖子),回到座位后,不知从何下手了。
那么,我们需要知道什么呢?
1、性能测试的目的
首先要知道客户的要求。
我把性能测试按目的分以下几种
1)客户有明确要求
这是一个好的结果,这说明客户对性能测试有一定的了解,知道他们需要的系统要达到一个什么样的标准。如:系统要求同时满足100用户登陆,平均每个用户登陆时间不能超过5秒。这个需求很明确,当然也不排除一些不懂装懂的用户,提一些不现实的要求。
不管怎么说,用户提要求了,这个比较容易,你可以对现系统做一次性能测试,至于,是通过优化系统还是增加硬件设备才能达到要求。就不是我们考虑的问题了。
2)只是想知道目前系统性能(容量测试)
可以把我们的目的就是求得最大用户数和最佳用户数。但是,这仍然是比较含糊的一个需求,我们需要对系统做出分析,找出系统的压力点。
3)找出系统性能瓶颈
这个同样需要分析可能对系统造成瓶颈的逻辑业务,然后才能进行性能测试。
4)了系统在长时间的压力下性能状况(强度测试)
这个一般验证系统的稳定性,因为系统一旦上线,就有可能会长期处在大用户的访问状态,可能以前没发现的一些问题就会暴漏出来。比较典型的就是内存溢出。
2、性能测试的环境
确定了我们的测试目的,当然需要测试环境。这里的环境,我们需要考虑一下几点
1)硬件环境
我们需要了解被测服务器硬件配置,用于加压客户端的机子配置,CPU 内存 等
2)软件环境
我们需要了解被测系统的架构,前端、中间件、服务器(这里指运行系统软件服务器,如tomcat)、数据库,以及他们的部署位置。
用于加压的客户端采用什么性能测试工具进行加压。
3)网络环境
网络环境很重要。在上面的几个目的中,除了找出系统性能瓶颈可以在广域网进行,因为这个目的可以不用设置太多的虚拟用户,只要找出系统哪个地方影响了整个系统的性能就行。
其他目的的测试都需要在,局域网进行,不然你压力工具所发送的请求都会卡死在网络的传输过程中。
3、寻找系统的压力点
我们需要对系统的哪个页面或业务进行加压。这个不是自己想出来的,需要与开发人员的沟通。系统的首页?系统的登录?还是系统的交易过程?各个业务的用户比例是多少?
只有获得有效的性能需求,才容易寻找和定位压力点。
获得有效的需求:http://www.51testing.com/html/68/n-10568.html
如果上面的几点,你都很清晰了,那么打开你的性能测试工具开始录制(或编写)你的性能测试脚本吧!
注:以上个人观点,如有错误的之处,请高手指证,以免误导别人。
-
【转】软件性能测试总结
2012-01-04 15:04:28
转自:http://www.51testing.com/html/42/n-805042.html
为什么要做性能测试?
性能测试前几年被关注的较少,近几年备受重视,那为什么要做性能测试呢?有很多种说法,个人比较认可下面这个,分享给大家:
1、评估系统的能力
2、识别体系中的弱点
3、系统调优
4、验证稳定性(resilience)可靠性(reliability)
针对上面这几种目的,针对不同的结果,给出不同的应对方案和措施,这才是性能测试的最终目标:
1、测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力,并帮助作出决策。
2、受控的负荷可以被增加到一个极端的水平,并突破它,从而修复体系的瓶颈或薄弱的地方。
3、重复运行测试,验证调整系统的活动得到了预期的结果,从而改进性能。
4、检测软件中的问题:长时间的测试执行可导致程序发生由于内存泄露引起的失败,揭示程序中的隐含的问题或冲突。
5、在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法
如何提炼性能测试点?
没有接触过性能测试的同学会觉得性能测试很深奥,很神秘,提到性能测试让人无从下手的感觉,其实,性能测试没想象中那么复杂,简单的说,性能测试就是功能测试量变达到质变的一个过程。简言之,哪些功能可能被大量用户访问的点,就是性能测试的重点之一。
之前做过一些小项目的性能测试,经常容易出现问题的点做了一个分类,之后我们在提炼性能测试点的时候会关注这些方面:
● 前端页面上
1、页面上本身有计算内容的地方 减少运算次数
2、通过接口取其他系统数据的地方
3、页面展现内容较多时是否翻页
4、iframe. 静态文件和缓存
5、页面上的静态文件,如JS,更新频率
6、读取排行榜如果不是从数据库读取可能会有性能问题● 数据库上的
1、读取数据库
2、写入数据库
3、存储过程
4、数据库之间同步
5、数据库检索、查询
6、索引
7、sql语句
8、数据类型● 程序本身上的
1、程序与其他系统交互的
2、代码效率业务功能,数据库及程序本身涉及到上面这些内容的,都需要注意性能问题,可以结合业务和项目实际情况,考虑把这些点作为性能测试的一个关注点。当然,性能测试上手容易,做好难,想做好性能测试,还是需要慢慢不断深入和积累的
我的栏目
标题搜索
我的存档
数据统计
- 访问量: 146030
- 日志数: 249
- 书签数: 41
- 建立时间: 2007-08-11
- 更新时间: 2013-03-28