-
LR分析——分解页面
2009-04-29 13:54:51
通过分解页面可以得到:比较大的响应时间到底是页面的哪个组件引起的?问题出在服
务器上还是网络传输上。
这里为了解说各个时间(比如:DNS 解析时间、连接时间、接受时间等),简单说一下浏览器从发送一个请求到最后显示的全过程。1. 浏览器向Web Server 发送请求,一般情况下,该请求首先发送到DNS Server 把DNS名字解析成IP 地址。解析的过程的时间就是DNS Resolution。这个度量时间可以
确定DNS 服务器或者DNS 服务器的配置是否有问题。如果DNS Server 运行情况比较好,该值会比较小。
2. 解析出Web Server 的IP 地址后,请求被送到了Web Server,然后浏览器和Web Server 之间需要建立一个初始化连接,建立该连接的过程就是Connection。这个度量时间可以简单的判断网络情况,也可以判断Web Server 是否能够响应这个请求。如果正常,该值会比较小。
3. 建立连接后,从Web Server 发出第一个数据包,经过网络传输到客户端,浏览器成功接受到第一字节的时间就是First Buffer。这个度量时间不仅可以表示Web Server 的延迟时间,还可以表示出网络的反应时间。从浏览器接受到第一个字节起,直到成功收到最后一个字节,下载完成止,这段时间就是Recieve。这个度量时间可以判断网络的质量(可以用size/time 比来计算接受速率)。
其他的时间还有SSL Handshaking(SSL 握手协议,用到该协议的页面比较少)、client Time(请求在客户端浏览器延迟的时间,可能是由于客户端浏览器的think time 或者客户端其他方面引起的延迟)、Error Time(从发送了一个HTTP 请求,到Web Server 发送回一个HTTP 错误信息,需要的时间)。熟悉了以上各个时间的含义后,我们开始看分解页面的图形。
首先看“Downlaod Time Breakdown”,可以看出login 事务分解的各个组件的大小,以及各个组件的下载时间。
从下图可以看出,login 页面有5 个组件组成,其中next.gif 下载用的时间最长,并且几乎所有的时间都用在了First Buffer 上,而其大小为1.256KB,并不是很大。上图提供的组件大小的信息比较简单,更详细的信息参考“Download Component SizeGraph”。利用该图可以看出该页面各种组件的大小所占的比例关系。
同样,要看各个组件下载时间的更详细的信息,可以参考“Page Component Breakdown”。利用该图可以看出该页面各种组件下载时间的比例关系。
选择“Component Breakdown(Over Time)”,可以以图形曲线的形式看出各个组件在场景运行中的每秒钟的下载时间,比较具体。要看到具体的值,可以参考Page Component Breakdown(Over Time)
然后再选择“Download Time BreakDown(Over Time)”,从中可以看出在场景运行中的每一秒钟,组件用在传输的各部分的时间。要看到具体的值,可以参考Page Download Time Breakdown(Over Time)
为了确认问题缘由到底是服务器还是网络,选择“Time to First Buffer Breakdown”,可以看出Server 时间比network 时间要高的多,从而确定问题是服务器引起的。然后我们就可以参考Web Server 的相关图表,来确定问题是由服务器的哪个部分引起。遵从这样的步骤,可以一步步的接近问题源;如果问题由网络引起,可以参考NetWork 相关的图表,确定什么样的网络问题是性能的瓶颈。同时可以参考“Time To First Buffer BreakDown(Over Time)”
-
(LR)判断应用程序是否存在处理器瓶颈的方法
2009-04-29 13:49:30
判断应用程序是否存在处理器瓶颈的方法:如果Processor Queue Length 显示的队列长度保持不变(>=2)个并且处理器的利用率%Processor Time 超过90%,那么很有可能存在处理器瓶颈。
如果发现Processor Queue Length 显示的队列长度超过2,而 处理器的利用率却一直很低,那么或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈。
如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换(Context Switches/sec 显示的上下文切换次数比较大),那么就会占用大量的系统资源。
如果系统的吞吐量降低并且CPU 的使用率很高,并且此现象发生时切换水平在15000 以上,那么意味着上下文切换次数过高同时还可以比较Context Switches/sec 和%Privileged Time 来判断上下文切换是否过量。
如果后者的值超过40%,且上下文切换的速率也很高,那么应该检查为什么会产生这样高的上下文切换。 -
LoadRunner性能指标分析(转)
2009-04-29 11:49:47
Memory:
内存使用情况可能是系统性能中最重要的因素。如果系统“页交换”频繁,说明内存不足。“页交换”是使用称为“页面”的单位,将固定大小的代码和数据块从 RAM 移动到磁盘的过程,其目的是为了释放内存空间。尽管某些页交换使 Windows 2000 能够使用比实际更多的内存,也是可以接受的,但频繁的页交换将降低系统性能。减少页交换将显著提高系统响应速度。要监视内存不足的状况,请从以下的对象计数器开始:
Available Mbytes:可用物理内存数. 如果Available Mbytes的值很小(4 MB 或更小),则说明计算机上总的内存可能不足,或某程序没有释放内存。参考值:至少要有10% 的物理内存值。
page/sec: 表明由于硬件页面错误而从磁盘取出的页面数,或由于页面错误而写入磁盘以释放工作集空间的页面数。一般如果pages/sec持续高于几百,那么您应该进一步研究页交换活动。有可能需要增加内存,以减少换页的需求(你可以把这个数字乘以4k就得到由此引起的硬盘数据流量)。Pages/sec 的值很大不一定表明内存有问题,而可能是运行使用内存映射文件的程序所致。Page/sec 推荐00-20(如果服务器没有足够的内存处理其工作负荷,此数值将一直很高。如果大于80,表示有问题)。这些计数器的值比较低,说明Web 服务器响应请求比较快,否则可能是服务器系统内存短缺引起( 也可能是缓存太大,导致系统内存太少)。PageInput/sec 的值可以衡量出硬错误页发生的速率,通常它的值会大于或者等于PageReads/sec。page read/sec:页的硬故障,page/sec的子集,为了解析对内存的引用,必须读取页文件的次数。阈值为>5. 越低越好。大数值表示磁盘读而不是缓存读。
由于过多的页交换要使用大量的硬盘空间,因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶径混淆。因此,在研究内存不足不太明显的页交换的原因时,您必须跟踪如下的磁盘使用情况计数器和内存计数器:
Physical Disk\ % Disk Time
Physical Disk\ Avg.Disk Queue Length
例如,包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低,同时 % Disk Time 和 Avg.Disk Queue Length的值很高,则可能有磁盘瓶径。但是,如果队列长度增加的同时页面读取速率并未降低,则内存不足。
要确定过多的页交换对磁盘活动的影响,请将 Physical Disk\ Avg.Disk sec/Transfer 和 Memory\ Pages/sec 计数器的值增大数倍。如果这些计数器的计数结果超过了 0.1,那么页交换将花费百分之十以上的磁盘访问时间。如果长时间发生这种情况,那么您可能需要更多的内存。
Page Faults/sec:每秒软性页面失效的数目(包括有些可以直接在内存中满足而有些需要从硬盘读取)较page/sec只表明数据不能在内存的指定工作集中立即使用。
Cache Bytes:文件系统缓存(File System Cache),默认情况下为50%的可用物理内存。如IIS5.0 运行内存不够时,它会自动整理缓存。需要关注该计数器的趋势变化
如果您怀疑有内存泄露,请监视 Memory\ Available Bytes 和 Memory\ Committed Bytes,以观察内存行为,并监视您认为可能在泄露内存的进程的 Process\Private Bytes、Process\Working Set 和Process\Handle Count。如果您怀疑是内核模式进程导致了泄露,则还应该监视 Memory\Pool Nonpaged Bytes、Memory\ Pool Nonpaged Allocs 和 Process(process_name)\ Pool Nonpaged Bytes。如果发生了内存泄漏,Process\Private Bytes计数器和Process\Working Set 计数器的值往往会升高,同时Available Bytes 的值会降低。内存泄漏应该通过一个长时间的,用来研究分析当所有内存都耗尽时,应用程序反应情况的测试来检验。
Pages per second :每秒钟检索的页数。该数字应少于每秒一页。Process:
%Processor Time: 被处理器消耗的处理器时间数量。如果服务器专用于sql server,可接受的最大上限是80-85%。参考值:小于75%。排除内存因素,如果该计数器的值比较大,而同时网卡和硬盘的值比较低,那么可以确定CPU 瓶颈。
%User Time:表示耗费CPU的数据库操作,如排序,执行aggregate functions等。如果该值很高,可考虑增加索引,尽量使用简单的表联接,水平分割大表格等方法来降低该值。
%Privileged Time:(CPU内核时间)是在特权模式下处理线程执行代码所花时间的百分比。如果该参数值和"Physical Disk"参数值一直很高,表明I/O有问题。可考虑更换更快的硬盘系统。另外设置Tempdb in RAM,减低"max async IO","max lazy writer IO"等措施都会降低该值。
此外,跟踪计算机的服务器工作队列当前长度的 Server Work Queues\ Queue Length 计数器会显示出处理器瓶颈。队列长度持续大于 4 则表示可能出现处理器拥塞。此计数器是特定时间的值,而不是一段时间的平均值。
% DPC Time:越低越好。在多处理器系统中,如果这个值大于50%并且Processor:% Processor Time非常高,加入一个网卡可能会提高性能,提供的网络已经不饱和。Thread
ContextSwitches/sec: (实例化inetinfo 和dllhost 进程) 如果你决定要增加线程字节池的大小,你应该监视这三个计数器(包括上面的一个)。增加线程数可能会增加上下文切换次数,这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高,就应该减小线程字节池的大小。Physical Disk:
%Disk Time %:指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大,那么硬盘不是瓶颈。如果只有%Disk Time比较大,另外两个都比较适中,硬盘可能会是瓶颈。在记录该计数器之前,请在Windows 2000 的命令行窗口中运行diskperf -yD。若数值持续超过80%,则可能是内存泄漏。
Avg.Disk Queue Length:指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能,可增加磁盘。注意:一个Raid Disk实际有多个磁盘。
Average Disk Read/Write Queue Length:指读取(写入)请求(列队)的平均数。
Disk Reads(Writes)/s: 物理磁盘上每秒钟磁盘读、写的次数。两者相加,应小于磁盘设备最大容量。
Average Disksec/Read: 指以秒计算的在此盘上读取数据的所需平均时间。
Average Disk sec/Transfer:指以秒计算的在此盘上写入数据的所需平均时间。
Network Interface:
Bytes Total/sec :为发送和接收字节的速率,包括帧字符在内。判断网络连接速度是否是瓶颈,可以用该计数器的值和目前网络的带宽比较SQLServer性能计数器:
Access Methods(访问方法) 用于监视访问数据库中的逻辑页的方法。
. Full Scans/sec(全表扫描/秒) 每秒不受限的完全扫描数。可以是基本表扫描或全索引扫描。如果这个计数器显示的值比1或2高,应该分析你的查询以确定是否确实需要全表扫描,以及S Q L查询是否可以被优化。
. Page splits/sec(页分割/秒)由于数据更新操作引起的每秒页分割的数量。
Buffer Manager(缓冲器管理器):监视 Microsoft® SQL Server™ 如何使用: 内存存储数据页、内部数据结构和过程高速缓存;计数器在 SQL Server 从磁盘读取数据库页和将数据库页写入磁盘时监视物理 I/O。 监视 SQL Server 所使用的内存和计数器有助于确定: 是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样,SQL Server 必须从磁盘检索数据。 是否可通过添加更多内存或使更多内存可用于数据高速缓存或 SQL Server 内部结构来提高查询性能。
SQL Server 需要从磁盘读取数据的频率。与其它操作相比,例如内存访问,物理 I/O 会耗费大量时间。尽可能减少物理 I/O 可以提高查询性能。
.Page Reads/sec:每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据库间的物理页读取总数。由于物理 I/O 的开销大,可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法,使开销减到最小。
.Page Writes/sec (.写的页/秒) 每秒执行的物理数据库写的页数。
.Buffer Cache Hit Ratio. 在“缓冲池”(Buffer Cache/Buffer Pool)中没有被读过的页占整个缓冲池中所有页的比率。可在高速缓存中找到而不需要从磁盘中读取的页的百分比。这一比率是高速缓存命中总数除以自 SQL Server 实例启动后对高速缓存的查找总数。经过很长时间后,这一比率的变化很小。由于从高速缓存中读数据比从磁盘中读数据的开销要小得多,一般希望这一数值高一些。通常,可以通过增加 SQL Server 可用的内存数量来提高高速缓存命中率。计数器值依应用程序而定,但比率最好为90% 或更高。增加内存直到这一数值持续高于90%,表示90% 以上的数据请求可以从数据缓冲区中获得所需数据。
. Lazy Writes/sec(惰性写/秒)惰性写进程每秒写的缓冲区的数量。值最好为0。
Cache Manager(高速缓存管理器) 对象提供计数器,用于监视 Microsoft® SQL Server™ 如何使用内存存储对象,如存储过程、特殊和准备好的 Transact-SQL 语句以及触发器。
. Cache Hit Ratio(高速缓存命中率,所有Cache”的命中率。在SQL Server中,Cache可以包括Log Cache,Buffer Cache以及Procedure Cache,是一个总体的比率。) 高速缓存命中次数和查找次数的比率。对于查看SQL Server高速缓存对于你的系统如何有效,这是一个非常好的计数器。如果这个值很低,持续低于80%,就需要增加更多的内存。
Latches(闩) 用于监视称为闩锁的内部 SQL Server 资源锁。监视闩锁以明确用户活动和资源使用情况,有助于查明性能瓶颈。
. Average Latch Wait Ti m e ( m s ) (平均闩等待时间(毫秒)) 一个SQL Server线程必须等待一个闩的平均时间,以毫秒为单位。如果这个值很高,你可能正经历严重的竞争问题。
. Latch Waits/sec (闩等待/秒) 在闩上每秒的等待数量。如果这个值很高,表明你正经历对资源的大量竞争。
Locks(锁) 提供有关个别资源类型上的 SQL Server 锁的信息。锁加在 SQL Server 资源上(如在一个事务中进行的行读取或修改),以防止多个事务并发使用资源。例如,如果一个排它 (X) 锁被一个事务加在某一表的某一行上,在这个锁被释放前,其它事务都不可以修改这一行。尽可能少使用锁可提高并发性,从而改善性能。可以同时监视 Locks 对象的多个实例,每个实例代表一个资源类型上的一个锁。
. Number of Deadlocks/sec(死锁的数量/秒) 导致死锁的锁请求的数量
. Average Wait Time(ms) (平均等待时间(毫秒)) 线程等待某种类型的锁的平均等待时间
. Lock Requests/sec(锁请求/秒) 每秒钟某种类型的锁请求的数量。
Memory manager:用于监视总体的服务器内存使用情况,以估计用户活动和资源使用,有助于查明性能瓶颈。监视 SQL Server 实例所使用的内存有助于确定:
是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样,SQL Server 必须从磁盘检索数据。
是否可以通过添加更多内存或使更多内存可用于数据高速缓存或 SQL Server 内部结构来提高查询性能。
Lock blocks:服务器上锁定块的数量,锁是在页、行或者表这样的资源上。不希望看到一个增长的值。
Total server memory:sql server服务器当前正在使用的动态内存总量.监视IIS需要的一些计数器
Internet Information Services Global:
File Cache Hits %、File CacheFlushes、File Cache Hits
File Cache Hits %是全部缓存请求中缓存命中次数所占的比例,反映了IIS 的文件缓存设置的工作情况。对于一个大部分是静态网页组成的网站,该值应该保持在80%左右。而File Cache Hits是文件缓存命中的具体值,File CacheFlushes 是自服务器启动之后文件缓存刷新次数,如果刷新太慢,会浪费内存;如果刷新太快,缓存中的对象会太频繁的丢弃生成,起不到缓存的作用。通过比较File Cache Hits 和File Cache Flushes 可得出缓存命中率对缓存清空率的比率。通过观察它两个的值,可以得到一个适当的刷新值(参考IIS 的设置ObjectTTL 、MemCacheSize 、MaxCacheFileSize)
Web Service:
Bytes Total/sec:显示Web服务器发送和接受的总字节数。低数值表明该IIS正在以较低的速度进行数据传输。
Connection Refused:数值越低越好。高数值表明网络适配器或处理器存在瓶颈。
Not Found Errors:显示由于被请求文件无法找到而无法由服务器满足的请求数(HTTP状态代码404)Web 应用程序Request/Sec,Request Executing:每秒执行的请求数,当前执行的请求数。如果Request/Sec的值比较小,你的Web 程序可能是瓶颈。Request Wait Time,Request Executing Time,Request Queued:最近的请求在队列中等待的毫秒数;执行最近的请求所用的毫秒数;等候处理的请求数;该计数器应保持接近 0。超过 IIS 队列长度会出现“服务器太忙”错误。参考值:Request Wait Time 和Request Queued 在理想状况下应该接近0,如果这两个值太大,那么需要重写代码提高性能。 -
(LR)优化Controller 和Load Generators 计算机
2009-04-29 11:36:08
如果控制机(Controller machine)和Load Generators 计算机运行的都是Windows2000,
那么下面两个简单的技巧可以提高性能
l 在Load Generators 计算机上,依次进入“控制面板”——“系统”——选择“高级”
标签页,点“性能选项”按钮,选择优化“后台服务”选项,这样可以提高性能,从而
可以在每个Load Generators 上运行更多的虚拟用户
l 在Controller 计算机上,按照以上的步骤,进入“性能选项”窗口,不过这里选择优化
“应用程序” -
LR函数
2009-04-29 11:09:12
VuGen 中可以使用C 语言中比较标准的函数和数据类型,语法和C 语言相同。下面简
单介绍一下比较常用的函数和数据类型。
1. 控制脚本流程
if { } else { }
for{ }
while{ }
……………
总之 C 语言的控制流程的语句这里都可以直接使用
2. 字符串函数
由于在VuGen 脚本中使用最多的还是字符串,所以字符串函数在脚本中使用非常
频繁。具体的语法请参考帮助说明。
strcmp 比较两个字符串
strcat 连接两个字符串
strcpy 拷贝字符串
……………..
注意:在VuGen 中,以char*声明的字符串是只读的,如果试图给char*类型的字
符串赋值的话,编译会通过,但在运行时会产生“Access Violation”的错误。解决
这类问题,就是把字符串声明为字符数组,比如char[100]。
3. 输出函数
输出函数在调试脚本时非常有用。
lr_output_message 输出一条消息
………………..
4. LoadRunner 提供的标准函数
lr_eval_string 该函数功能是得到参数(参数化输入中)当前的值
exg: lr_output_message("temp = %s", lr_eval_string("{WCSParam2}"));
lr_save_string 该函数功能是把一个字符串保存到参数中
exg: lr_save_string("439","WCSParam3"); -
《软件性能测试过程详解与案例剖析》——PTGM模型
2009-02-10 15:22:27
性能测试模型PTGM(Performance Testing General Model),将性能测试过程分为测试前期准备、测试工具引入、测试计划、测试设计与开发、测试执行和管理以及测试分析等6个步骤。
1.测试前期准备
在前期准备阶段,至少要完成两个方面的工作:保证系统稳定和建立合适的测试团队。具体来说,测试前期准备包含如下的活动:
(1)系统基础功能的验证
(2)组建测试团队
(3)测试工具需求确认
需考虑如下几个方面:操作系统环境(能运行、支持监控)、应用服务器环境(支持监控)、数据库环境(支持监控)、应用使用的协议(是否支持)、网络环境(防火墙、负载均衡)、测试管理支持(测试结果分析和管理)。
(4)性能预备测试(可选活动)
所谓预备测试,是在正式的测试之前,通过简单的探索性测试或是其他方法,对系统的性能表现进行初步的了解。
2.测试工具引入
(1)工具选择
(2)工具应用技能培训
(3)确定工具应用过程
3.测试计划
(1)性能测试领域分析
应用领域 性能测试目标 性能目标 能力验证 验证系统在给定环境中的性能能力 重点关注的关键业务响应时间、吞吐量 规划能力 验证系统的性能扩展能力,找出系统能力扩充的关键点,给出改善其性能扩展能力的建议 业务的性能瓶颈 性能调优 提高系统的性能表现 重点关注的关键业务响应时间、吞吐量 发现缺陷 发现系统中的缺陷 无 (2)用户活动剖析与业务建模
用来寻找用户的关键性能关注点。
用户活动剖析的方法大体分为两种:系统日志分析和用户调查分析。经过用户活动分析之后,最终形成的结果类似于以下的描述:
用户最关心的业务之一是A业务,该业务具有平均每天3000次业务发生率,业务发生时间集中在9:00~18:00的时间段,业务发生的峰值为每小时1000次。A业务操作路径如下所示:……
业务建模是对业务穖的行为及其襀方式和方法的建模,一般采用流程图的方式描绘出各进程之间的交互关系和数据流向。
(3)确定性能目标
首先从需求和设计中分析出性能测试需求,结合用户活动剖析与业务建模的结果,最终确定性能测试的目标。
(4)制定测试时间计划
4.测试设计与开发
(1)测试环境设计
此处的测试环境设计包括系统的软/硬件环境、数据环境设计、环境的维护方法。
(2)测试场景设计
测试场景模拟的一般是实际业务运行的剖面,其包括业务、业务比例、测试指标的目标以及需要的测试过程中进行监控的性能计数器。
(3)测试用例设计
针对每个测试场景规划出相应的工具部署、应用部署、测试方法和步骤。
(4)脚本和辅助工具开发
测试脚本是对业务操作的体现,一个脚本一般就是一个业务的过程描述。
5.测试执行与管理
(1)建立测试环境
在设计完成用例之后就会开始该活动。建立测试环境一般包括硬件、软件系统环境的搭建,数据库环境建立,应用系统部署,系统设置参数的调整,以及数据环境准备几个方面的工作内容。
(2)部署测试脚本和测试场景
部署测试脚本和测试场景活动通过测试工具本身提供的功能来实现。部署活动最终需要保证场景与设计的一致性,保证需要监控的计数器都已经部署好了相应的监控手段。
(3)执行测试和记录结果
6.测试分析
性能分析的通用方法之一是“拐点分析”的方法。“拐点分析”方法是一种利用性能计数器曲线图上的拐点进行性能分析的方法,只要关注性能表现上的“拐点”,获得“拐点”附近的资源使用情况,就能够定位出穖的性能瓶颈。
-
《软件性能测试过程详解与案例剖析》——性能分析方法之处理器
2009-02-06 18:17:38
1.首先查看System\%Total Processor Time性能计数器的计数值
用于体现服务器整体的处理器利用率,对多处理器的系统而言,体现的是所有CPU的平均利用率。
2.其次查看每个CPU的Processor\%Processor Time和Processor\%User Time和Processor \%Privileged Time
Processor\%User Time是指系统的非核心操作消耗的CPU时间,如果值大,可以考虑是否能通过算法优化等方法降低这个值。如果该服务器是数据库服务器,Processor\%User Time值大的原因很可能是数据库的排序或是函数操作消耗了过多的CPU时间,可考虑优化数据。
3.研究系统处理器瓶颈
查看System\Processor Queue Length的值,若其大于CPU数据的总数+1,说明産了处理器阻塞。在处理器的Processor \%ProcessorTime很高时,一般都伴随着处理器阻塞。
%DPC Time,越低越好。在多处理器系统中,如果这个值大于50%,并且Processor \%ProcessorTime非常高,加入一个网卡可能会提高性能。
-
《软件性能测试过程详解与案例剖析》——性能分析方法之内存
2009-02-06 18:00:09
1. 首先查看Memory\Available Mbytes指标
该计数值是描述穖可用内存的直接指标,在对系统进行操作系统级别的内存分析时,首先通过该指标建立一个初步的印象,了解性能测试过程中,系统是否仍然有足够的内存可用。
2.注意Page/sec、Pages Read/sec和Page Faults/sec的值
OS经常会利用磁盘交换的方式提高系统可用的内存量或是提高内存的使用效率。而这3个指标直接反映了OS进行磁盘交换的频度。
若Page/sec的计数持续高于几百,很可能会有内在方面的问题产生,但Page/sec的值很大不一定表现内存有问题,而可能是运行使用内存映射文件的程序所致。Page Faults/sec,页面失效次数越多,说明OS向内存中读取的次数越多。Pages Read/sec的阈值为5,如果值超过5,则可以判断存在内存方面的问题。
3.根据Physical Disk计数器的值分析性能瓶颈
对Physical Disk的分析包括对Pages Read/sec和%Disk Time及Average Disk Queue Length的分析。如果Pages Read/sec很低,同时%Disk Time和Average Disk Queue Length的值很高,则可能有磁盘瓶颈。但是,如果队列长度增加的同时Pages Read/sec并未降低,则是由于内存不足。
-
《软件性能测试过程详解与案例剖析》——软件性能测试方法论
2009-02-05 11:43:35
1. SEI 负载测试计划过程
SEI 负载测试计划过程(SEI Load Testing Planning Process)是一个关注于负载测试计划的方法,其目标是产生“清晰、易理解、可验证的负载测试计划”。SEI 负载测试计划过程包括6 个关注的区域(Area):目标、用户、用例、生产环境、测试环境和测试场景。
SEI 负载测试计划过程在负载测试需要关注的具体内容上提供了参考,但其并不是一个完整的测试过程。
2. RBI 方法
RBI(Rapid Bottleneck Identify)方法是一种用于快速识别系统
性能瓶颈的方法。该方法基于以下一些事实:
(1)发现的80%系统的性能瓶颈都由吞吐量制约;(2)并发用户数和吞吐量瓶颈之间存在一定的关联;
(3)采用吞吐量测试可以更快速定位问题。
RBI 方法首先访问服务器上的“小页面”和“简单应用”,从应用服务器、网络等基础的层次上了解系统吞吐量表现;其次选择不同的场景,设定不同的并发用户数,使其吞吐量保持基本一致的增长趋势,通过不断增加并发用户数和吞吐量,观察系统的性能表现。
在确定具体的性能瓶颈时,RBI 将性能瓶颈的定位按照一种“自上而下”的分析方式进行分析,首先确定是由并发还是由吞吐量引发的性能表现限制,然后从网络、数据库、应用服务器和代码本身4 个环节确定系统性能具体的瓶颈。
RBI 方法在性能瓶颈的定位过程中能发挥良好的作用,其对性能分析和瓶颈定位的方法值得借鉴,但其也不是完整的性能测试过程。
3.性能下降曲线分析法
目标:性能随着用户数的增加而出现下降趋势的曲线分析、查看性能下降的环境点与上下文。确定性能阀值。
内容:通过单用户区域、性能平坦区域、压力区域、性能拐点进行监控和分析。单用户区域——系统的一个单用户的响应时间。
性能平坦区域——在不进行更多性能调优情况下所能期望达到的最佳性能。这个区域称为基线(Benchmark).
压力区域——应用“轻微下降”的地方。最大的建议用户负载是人压力区域开始的。
性能拐点——性能开始“急剧下降”的点。
4. LoadRunner的性能测试过程
LoadRunner的性能测试过程分为计划测试、测试设计、创建VU脚本、创建测试场景、运行测试场景和分析结果6个步骤。
5. Segue提供的性能测试过程
Segue公司Silk Performer提供的性能测试过程,是一个不断try-check过程。从确定性能基线开始,通过单用户对应用的访问获取性能取值的基线,然后设定可接受的性能目标(响应时间),用不同的并发用户数等重复进行测试。
此种方法非常适合性能调优和性能优化。
6.本书提供的PTGM模型
性能测试模型PTGM(Performance Testing General Model),将性能测试过程分为测试前期准备、测试工具引入、测试计划、测试设计与开发、测试执行和管理以及测试分析等6个步骤。
-
《软件性能测试过程详解与案例剖析》——术语
2009-02-04 18:28:53
1.响应时间
应用系统从发出请求开始到客户端接收到响应所消耗的时间。
2.并发用户数
在实际的性能测试工作中,测试人员常常会关心到并发用户数,也就是从业务角度关注究竟应该设置多少个并发数比较合理,以下是一个估算并发用户数的方法:
(1) 计算平均的并发用户数: C = nL/T
(2) 并发用户数峰值: C’ ≈ C+3根号C
公式(1)中,C是平均的并发用户数;n是login session的数量;L是login session的平均长度;T指考察的时间段长度。
公式(2)则给出了并发用户数峰值的计算方式中,其中,C’指并发用户数的峰值,C就是公式(1)中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。
实例:
假设有一个OA系统,该系统有3000个用户,平均每天大约有400个用户要访问该系统,对一个典型用户来说,一天之内用户从登录到退出该系统的平均时间为4小时,在一天的时间内,用户只在8小时内使用该系统。
则根据公式(1)和公式(2),可以得到:
C = 400*4/8 = 200
C’≈200+3*根号200 = 242
另外,如果能够知道平均每个用户发出的请求数(假设为u),则系统的总吞吐量就可估算为u*C
3. 吞吐量
吞吐量是指“单位时间内系统处理的客户请求的数据,直接体现软件系统的性能承载能力。
吞吐量指标可在两方面发挥作用:
(1)用于协助设计性能测试场景,以及衡量性能测试场景是否达到了预期的设计目标。根据估算的吞吐量数据,可以对应到测试场景的事务发生频率、事务发生次数等;另外,在测试完成后,根据实际的吞吐量可以衡量测试是否达到了预期的目标。
(2)用于协助分析性能瓶颈。
在没有遇到性能瓶颈的时候,F=(Nv*R)/T
其中,F表示吞吐量,Nv表示虚拟用户的个数,R表示每个VU发出的请求(单击)数量,T表示性能测试所用的时间。但如果遇到了性能瓶颈,此时吞吐量和VU数量之间就不再符合公式的关系。
常用于分析吞吐量的图形是“吞吐量——VU数量”的关联图。
4.性能计数器
性能计数器是描述服务器或操作系统性能的一些数据指标。如,内存数(Memory In Usage),进程时间(Total Process Time)等都是常见的计数器。
单一的性能计数器只能体现系统性能的某一个方面,对性能测试结果的分析必须基于多个不同的计数器。
与性能计数器相关的另一术语是“资源利用率”。资源利用率在通常的情况下需要结合响应时间变化曲线、系统负载曲线等各种指标进行分析。
5.思考时间(休眠时间)
在具体的测试实践中,该如何选择合适的思考时间呢? 下面给出一个计算思考时间的一般步骤:
(1)首先计算出系统的并发用户数;
(2)统计出系统平均的吞吐量;
(3)统计出平均每个用户发出的请求数量;
(4)根据公式R=T/Ts计算出思考时间。其中,T=(Nv*R)/F
为了让性能测试场景更加符合实际情况,可以考虑以计算出的思考时间为基准,让实际思考时间在一定幅度内随机变动。
如果测试的目的是为了“验证应用系统具有预期的能力”,就应该尽量模拟用户在使用业务时的真实思考时间;如果是为了“了解系统在压力下的性能水平”或是“了解系统承受压力的能力”,则可以采用0思考时间。
-
《软件性能测试过程详解与案例剖析》——什么是软件性能
2009-02-04 18:07:37
用户视角的软件性能
从用户的角度来说,软件性能就是软件对用户操作的响应时间。从客观的角度来说,事务的结束应该是系统返回所有的数据,响应时间应该是从用户操作开始到所有数据返回完成的整个耗时;但从用户的主观感知来说,如果采用一种优化的数据呈现策略,当少部分数据返回之后就立刻将数据呈现在用户面前,则用户感受到的响应时间就会远远小于实际的事务响应时间(这也是C/S结构的管理系统中开发人员常用的一种技巧)。
管理员视角的软件性能
管理员关心的问题 软件性能描述 服务器的资源使用状况合理吗 资源利用率 应用服务器和数据库的资源使用善合理吗 资源利用率 系统是否能够实现扩展 系统可扩展性 系统最多能支持多少用户的访问?系统最大的业务处理量是多少 系统容量 系统性能可能的瓶颈在哪里 系统可扩展性 更换哪些设备能够提高系统性能 系统可扩展性 系统能否支持7*24小时的业务访问 系统稳定性
开发人员视角的软件性能
开发人员关心的问题 软件性能描述 架构设计是否合理 系统架构 数据库设计是否存在问题 数据库设计 代码是否存在性能方面的问题 代码 系统中是否有不合理的内在使用方式 代码 系统中是否存在不合理的线程同步方式 设计与代码 系统中是否存在不合理的资源竞争 设计与代码 -
应用系统性能测试六大步(转自51)
2008-12-31 11:35:12
性能测试是为了保证产品发布后其性能能够满足用户的需求,本文结合具体案例介绍了应用系统性能测试的六大步骤。在本文介绍的这个案例中,被测应用系统是一家公司的客户信息系统,它主要用来录入、修改以及查询全球客户的信息,并将客户信息转入到业务系统。但是,在应用过程中,客户经常投诉在某个时刻新建或者修改一个客户信息非常慢,正常情况下完成该操作只需要1~5秒,而异常时却需要10分钟左右,而且系统管理员发现系统资源使用率都比较低,这种情况的出现并没有规律性。
在这个案例中我们发现了系统存在性能问题,下一步工作就是要在性能测试过程中查找形成系统瓶颈和故障的根本原因,在此项工作中我们应该按照如下几个步骤进行。
1.确定明确的测试目标
性能调优是是无止境的,所以在测试之前应确定一个明确性能调优目标,这也是后面“评估性能验证”的一个基准,也是测试终止的一个基准。在本案例中目标设定为:在相同系统环境配置下30个并发用户在1~5秒钟内完成各类在线操作。
2.测试需求分析
性能调优的测试分析主要目的是要挖掘出可能造成系统瓶颈的因素,并为后面的测试用例设计提供保证。影响系统性能有很多种原因,在此应关注如下几个关键点:
● 应用配置需求: 例如应用整体框架、涉及到哪些第三方的组件、应用层与数据库层的接口、使用了什么数据库等。
● 系统配置需求: 例如用户客户端配置、客户端与服务器端的网络配置、应用服务器或数据库服务器操作系统等。
● 用户使用情况需求: 例如用户分布情况; 哪些模块用户使用比较频繁; 在用户操作的数据有哪些特点等。
这方面工作是非常繁杂的,而且要求测试人员具有挖掘可能造成系统瓶颈因素的洞察力和敏锐感,但是很多测试人员在接手测试之后,很快进入到测试用例设计阶段。实践证明,这样做往往都适得其反,要么工期延期,要么项目开发失败。这个过程在测试整体过程中是非常关键的一环。性能测试分析有个特点: 它关注的是应用的整体,或者会仔细分析围绕着应用的各种外部因素,比如说它所涉及到的硬件、第三方软件,而不会深入到项目具体的内部。这是因为性能测试关注的是项目整体、是一种黑盒测试方法,我们关心一个项目的整体在运行时所暴露出来的问题。在此案例中我们获取到如表所示需求。
3.测试用例设计
此过程主要目的是设计出一些合理的场景去验证在需求分析阶段获得的可能影响性能的因素是否是造成系统瓶颈的因素。测试用例设计一般包括测试策略、测试案例、测试内容。
测试策略一般包括对比测试环境与真实的业务操作环境,真实业务操作环境又可能涉及局域网测试环境与机房测试环境等
测试案例主要是根据测试需求分析的结果制定出在测试执行时系统的执行方法,比如本案例中“5个人同时录入不同的新客户信息,以及具体的模拟步骤”。在测试案例设计时应注意如下几点:
● 虚拟用户的操作步骤要尽量类似于真实用户的操作。
● 操作的数据要类同于真实用户实际使用数据,例如在案例中用户录入客户信息时,根据需求得到的结果,我们可以设计有3~4个虚拟用户在录入一些小客户的信息,1~2个虚拟用户在录入大客户的信息等。
● 在案例设计时要充分考虑到需求中用户对模块的使用频率。使得在模拟时每个模块使用情况尽量地类似于真实环境。
测试内容一般包括并发性能测试、疲劳强度测试、大数据量测试以及系统资源监控等,我们在做性能调优测试时主要是做并发性能测试以及系统资源监控这些方面的工作。从对系统产生并发性能测试过程中监控系统中各种资源的变化,来判断导致性能瓶颈的原因。
4.脚本开发数据的准备以及测试执行与监控
测试执行与监控的主要目的是根据设计方案去验证系统是否存在瓶颈,给测试分析提供各种分析数据。此过程会与下面的“测试分析”过程不断进行重复执行,直至真正确定出系统瓶颈所在。
笔者认为,在此过程中如果有测试工具能够满足测试要求,那么应尽量使用测试工具,不要手工去开发测试程序,因为做企业项目往往时间紧张,而且测试工具毕竟是一个成熟的产品,在各方面都得到验证。使用工具将会缩短测试周期,而且现在市场上有很多成熟的测试软件。例如: Mercury的LoadRunner、IBM的Robot、Compuware的QALoad等。在这个案例中笔者使用的是Mercury的 LoadRunner。关于一些技术细节笔者就不再赘述了,在这里主要提两点。
一是数据的准备。数据准备一定要关注数据的质量和数量,不要出现一些不符合业务逻辑的废数据,并且数据量要满足测试运行的需要。例如测试需要100组数据,但是实际只准备了50组,从而导致测试执行结果出现大的偏差。
二是测试执行。除了正确按照设计的要求去设置各种参数之外,还要关注系统是否存在功能问题,这往往成为性能测试的“盲点”。原则上性能测试之前必须确保功能测试已经完备,但是任何事情都不绝对,所以一般做性能测试之初,都会模拟一个用户去运行设计的场景,主要是确保“测试脚本正确性”、“在设计的场景中应用系统不存在功能上的问题”。很多性能测试过程往往因为功能问题导致性能测试失败,或者是测试延期的现象。
5.测试分析
测试分析的主要目的是要根据测试执行获取到的数据去判断造成系统出现瓶颈的位置,挖掘造成系统瓶颈的真正原因。这个过程是技术含量最高的一环,因为在测试执行过程获取到的数据会涉及到各个方面,在这个案例中就涵盖了网络方面的知识、系统方面的知识、应用方面的知识等,测试人员需要从这些繁杂的数据中挑出异常,系统越大越复杂在这个方面对测试人员要求会更高。但是这里面也有一些技巧:
● 在做测试分析时人员组成建议为: 开发人员、系统人员、测试人员共同组成。这样会在技术上填补个人技术上的不足。实际每个项目涉及到的技术都可能各有不同,对于个人来说不可能每样都精通。
● 反复比较一个类型的参数在不同时间的跳跃值,或者不同场景下同一个类型参数的变化。
● 在发现参数有异常变化时,不要轻易下结论,而是要尽量挖掘可能影响这个参数的其他参数值。在长期的测试过程中发现往往发现第一个所谓的瓶颈都是因为其他因素造成的。
● 在测试分析时使用较多的一种方式是排除法,根据开始获取到的信息大概能将问题定位在某一层面上。但具体在什么地方,就可以采取排除的方法去定位。
● 尽量使用一些比较成熟的工具协助分析工作,这样将大大减轻工作负担。
● 在确定出真正的性能瓶颈时,可以做一些小的测试模型去做验证,确定分析的正确性。
在本案例中,在测试结果经过各种比对之后,最后确定是数据库层上出现问题。但是问题究竟出现什么地方呢?笔者在分析过程中采用了许多排除法,比如更新索引的统计值、将数据库中的表从页级锁改为行级锁等,但是都效果甚微。
所以,我们回到上面看与数据库层相关的需求:
(1) 因为业务需要,需要使用很多模糊查询。此类操作会进行表扫描。为了防止脏读,会向数据库申请表级意向锁。
(2) 因为客户关系复杂,所以数据库设计的时候,存在多表关联。
(3) 在应用开发时,我们使用了Hiberate这个组件,这些组件对于开发人员来说是一个黑盒,而且存在一些局限性: 在更新记录时会同步更新所有相关联的表,即使关联表不需要更新; 同步更新的记录操作会涵盖一个事物处理过程中,会产生大事务操作; 无法利用SQL优化技术去优化他所产生出来的SQL语句。
研究之后发现: 在进行模糊查询与大客户信息录入与修改的操作时,由hiberate这个组件产生的大事务SQL导致了数据库的互锁,是系统瓶颈所在。为了验证这一判断的正确性,笔者做了一个小的模型去验证。
假设库中有A、B、C三张表,现在有三个虚拟用户同时在上面进行操作: 用户Vuser1需要查询客户信息,他只知道客户的姓氏,所以他采取了模糊查询; 用户Vuser2正在修改一个客户信息,正准备保存; 用户Vuser3正在查询客户办公信息,也需要模糊查询。
Vuser1操作先得到执行,在表扫描中出现表级意向锁; 此时Vuser2进来需要修改A、B、C三张表对应记录,并成功的锁定了B、C两张表对应的行(因为是行级锁),然后进行了修改,但是无法修改表A,所以 Vuser2此时等待Vuser1释放锁; 此时Vuser3进来了,需要查询C表,因为Vuser2并没有释放锁,此时Vuser3也处在等待状态。验证显示,在出现大数量的操作并且在多用户的操作下,此瓶颈将不断地暴露出来。
6.系统调优与验证
将获取的分析数据交付到开发组进行调优,经过调优后一般都需要再次进行验证,验证主要关注调优后的结果是否解决了所发现的系统性能瓶颈和是否产生了新的性能瓶颈。这方面的工作主要由开发人员来完成。在本案例中,去掉了Hiberate组件,改为由应用自身控制,尽量减少了大事物的出现概率,并同业务部门商议,降低了模糊查询操作的次数。在后来再做“性能评测”时确认系统达到了预期目标。
-
如何在 LoadRunner 脚本中做关联 (Correlation)(转)
2008-12-22 16:02:34
当录制脚本时,VuGen会拦截client端(浏览器)与server端(网站服务器)之间的对话,并且通通记录下来,产生脚本。在VuGen的Recording Log中,您可以找到浏览器与服务器之间所有的对话,包含通讯内容、日期、时间、浏览器的请求、服务器的响应内容等等。脚本和Recording Log最大的差别在于,脚本只记录了client端要对server端所说的话,而Recording Log则是完整纪录二者的对话。当执行脚本时,您可以把VuGen想象成是一个演员,它伪装成浏览器,然后根据脚本,把当初真的浏览器所说过的话,再对网站伺服器重新说一遍,VuGen企图骗过服务器,让服务器以为它就是当初的浏览器,然后把网站内容传送给VuGen。
所以纪录在脚本中要跟服务器所说的话,完全与当初录制时所说的一样,是写死的(hard-coded)。这样的作法在遇到有些比较聪明的服务器时,还是会失效。这时就需要透过「关联(correlation)」的做法来让VuGen可以再次成功地骗过服务器。
何谓关联(correlation)?
所谓的关联(correlation)就是把脚本中某些写死的(hard-coded)数据,转变成是撷取自服务器所送的、动态的、每次都不一样的数据。
举一个常见的例子,刚刚提到有些比较聪明的服务器,这些服务器在每个浏览器第一次跟它要数据时,都会在数据中夹带一个唯一的辨识码,接下来就会利用这个辨识码来辨识跟它要数据的是不是同一个浏览器。一般称这个辨识码为Session ID。对于每个新的交易,服务器都会产生新的Session ID给浏览器。这也就是为什么执行脚本会失败的原因,因为VuGen还是用旧的Session ID向服务器要数据,服务器会发现这个Session ID是失效的或是它根本不认识这个Session ID,当然就不会传送正确的网页数据给VuGen了。
下面的图示说明了这样的情形:
当录制脚本时,浏览器送出网页A的请求,服务器将网页A的内容传送给浏览器,并且夹带了一个ID=123的数据,当浏览器再送出网页B的情求时,这时就要用到ID=123的数据,服务器才会认为这是合法的请求,并且把网页B的内容送回给浏览器。
在执行脚本时会发生什么状况?浏览器再送出网页B的请求时,用的还是当初录制的ID=123的数据,而不是用服务器新给的ID=456,整个脚本的执行就会失败。
要对付这种服务器,我们必须想办法找出这个Session ID到底是什么、位于何处,然后把它撷取下来,放到某个参数中,并且取代掉脚本中有用到Session ID的部份,这样就可以成功骗过服务器,正确地完成整个交易了。
哪些错误代表着我应该做关联(correlation)?
假如脚本需要关联(correlation),在还没做之前是不会执行通过的,也就是说会有错误讯息发生。不过,很不幸地,并没有任何特定的错误讯息是和关联(correlation)有关系的。会出现什么错误讯息,与系统实做的错误处理机制有关。错误讯息有可能会提醒您要重新登入,但是也有可能直接就显示HTTP 404的错误讯息。
要如何做关联(correlation)?
关联(correlation)函数
关联(correlation)会用到下列的函数:
• web_reg_save_param:这是最新版,也是最常用来做关联(correlation)的函数。
语法:
web_reg_save_param ( “Parameter Name” , < list of Attributes >, LAST );
• web_create_html_param、web_create_html_param_ex:这二个函数主要是保留作为向前兼容的目的的。建议使用 web_reg_save_param 函数。
详细用法请参考使用手册。在VuGen中点选【Help】>【Function reference】>【Contexts】>【Web and Wireless Vuser Functions】>【Correlation Functions】。
如何找出要关联(correlation)数据
简单的说,每一次执行时都会变动的值,就有可能需要做关联(correlation)。
VuGen提供二种方式帮助您找出需要做关联(correlation)的值:
1. 自动关联
2. 手动关联
自动关联
VuGen内建自动关联引擎(auto-correlation engine),可以自动找出需要关联的值,并且自动使用关联函数建立关联。
自动关联提供下列二种机制:
• Rules Correlation:在录制过程中VuGen会根据订定的规则,实时自动找出要关联的值。规则来源有两种:
o 内建(Built-in Correlation):
VuGen已经针对常用的一些应用系统,如AribaBuyer、BlueMartini、BroadVision、InterStage、mySAP、NetDynamics、Oracle、PeopleSoft、Siebel、SilverJRunner等,内建关联规则,这些应用系统可能会有一种以上的关联规则。您可以在【Recording Options】>【Internet Protocol】>【Correlation】中启用关联规则,则当录制这些应用系统的脚本时,VuGen会在脚本中自动建立关联。
您也可以在【Recording Options】>【Internet Protocol】>【Correlation】检视每个关联规则的定义。
o 使用者自订(User-defined Rules Correlation):
除了内建的关联规则之外,使用者也可以自订关联规则。您可以在【Recording Options】>【Internet Protocol】>【Correlation】建立新的关联规则。
• Correlation Studio:有别于Rules Correlation,Correlation Studio则是在执行脚本后才会建立关联,也就是说当录制完脚本后,脚本至少须被执行过一次,Correlation Studio才会作用。Correlation Studio会尝试找出录制时与执行时,服务器响应内容的差异部分,藉以找出需要关联的数据,并建立关联。
Rule Correlation
请依照以下步骤使用Rule Correlation:
1. 启用auto-correlation
1. 点选VuGen的【Tools】>【Recording Options】,开启【Recording Options】对话窗口,选取【Internet Protocol】>【Correlation】,勾选【Enable correlation during recording】,以启用自动关联。
2. 假如录制的应用系统属于内建关联规则的系统,如AribaBuyer、BlueMartini、BroadVision、InterStage、mySAP、NetDynamics、Oracle、PeopleSoft、Siebel、SilverJRunner等,请勾选相对应的应用系统。
3. 或者也可以针对录制的应用系统加入新的关联规则,此即为使用者自订的关联规则。
4. 设定当VuGen侦测到符合关联规则的数据时,要如何处理:
【Issue a pop-up message and let me decide online】:跳出一个讯息对话窗口,询问您是否要建立关联。
【Perform. correlation in sceipt】:直接自动建立关联
2. 录制脚本
开始录制脚本,在录制过程中,当VuGen侦测到符合关联规则的数据时,会依照设定建立关联,您会在脚本中看到类似以下的脚本,此为BroadVision应用系统建立关联的例子,在脚本批注部分可以看到关联前的数据为何。
3. 执行脚本验证关联是OK的。
Correlation Studio
当录制的应用系统不属于VuGen预设支持的应用系统时,Rule Correlation可能既无法发挥作用,这时可以利用Correlation Studio来做关联。
Correlation Studio会尝试找出录制时与执行时,服务器响应内容的差异部分,藉以找出需要关联的数据,并建立关联。
使用Correlation Studio的步骤如下:
1. 录制脚本并执行
2. 执行完毕后,VuGen会跳出下面的【Scan Action for Correlation】窗口,询问您是否要扫描脚本并建立关联,按下【Yes】按钮。
3. 扫描完后,可以在脚本下方的【Correlation Results】中看到扫描的结果。
4. 检查一下扫瞄的结果后,选择要做关联的数据,然后按下【Correlate】按钮,一笔一笔做,或是按下【Correlate All】让VuGen一次就对所有的数据建立关联。
注意:由于Correlation Studio会找出所有有变动的数据,但是并不是所有的数据都需要做关联,所以不建议您直接用【Correlate All】。
5. 一般来说,您必须一直重复步骤1~4直到所有需要做关联的数据都找出来为止。因为有时前面的关联还没做好之前,将无法执行到后面需要做关联的部份。
有可能有些需要做关联的动态数据,连Correlation Studio都无法侦测出来,这时您就需要自行做手动关联了。
手动关联
手动关联的执行过程大致如下:
1. 使用相同的业务流程与数据,录制二份脚本
2. 使用WinDiff工具协助找出需要关联的数据
3. 使用web_reg_save_param函数手动建立关联
4. 将脚本中有用到关联的数据,以参数取代
接下来将详细的说明如何执行每个步骤
使用相同的业务流程与数据,录制二份脚本
1. 先录制一份脚本并存档。
2. 依照相同的操作步骤与数据录制第二份脚本并存盘。注意,所有的步骤和输入的数据一定都要一样,这样才能找出由服务器端产生的动态数据。
有时候会遇到真的无法使用相同的输入数据,那您也要记住您使用的输入数据,到时才能判断是您输入的数据,还是变动的数据。
使用WinDiff工具协助找出需要关联的数据
1. 在第二份脚本中,点选VuGen的【Tools】>【Compare with Vuser…】,并选择第一份脚本。
2. 接着WinDiff会开启,同时显示二份脚本,并显示有差异的地方。WinDiff会以一整行黄色标示有差异的脚本,并且以红色的字体显示真正差异的文字。(假如没看到红色字体,请点选【Options】>【View】>【Show Inline Differences】)。
3. 逐一检视二份脚本中差异的部份,每一个差异都可能是需要做关联的地方。选取差异的脚本,然后复制。
在复制时,有时并不需要取整行脚本,可能只会选取脚本中的一部分。
注意:请忽略lr_thik_time的差异部份,因为lr_thik_time是用来模拟每个步骤之间使用者思考延迟的时间。
4. 接着要在Recording Log(单一protocol)或是Generation Log(多重protocol)中找这个值。将鼠标光标点到Recording Log的第一行开头,按下Ctrl+F,开启【Find】窗口,贴上刚刚复制的脚本,找出在Recording Log第一次出现的位置。
结果会有二种:
o 在Recording Log中找不到要找的数据,这时请先确认您找对了脚本,毕竟现在开启了二个几乎一样的脚本,很容易弄错。
o 在Recording Log中找到了要找的数据,这时要确认数据是从服务器端传送过来的。首先可以先检查数据的标头,从标头的Receiving response可以知道数据是从服务器端传送到client端的。假如此数据第一次出现是在Sending request中,则表示此数据是由client端产生,不需要做关联,但是有可能需要做参数化(parameterized)。
您要找的标头格式如下:
*** [tid=b9 Action1 2] Receiving response from host astra.merc-int.com:80 ( 25/11/2002 12:04:00 )
5. 现在您已经找到录制二次都不一样,而且是由服务器所产生的动态数据了,而此数据极有可能需要做关联。
使用web_reg_save_param函数手动建立关联
在找到是由服务器所产生的动态数据之后,接下来要做的就是找出适当的位置,使用web_reg_save_param函数,将这个动态数据撷取到某个参数中。
1. 要在哪里使用web_reg_save_param函数?
在之前的步骤,我们已经在Execution Log找到可能需要关联的动态数据。在Execution Log中选取动态数据前的文字然后复制,我们将会利用这段文字,来帮助我们找出要关联的动态数据。
不过在这之前我们要先找出使用web_reg_save_param函数的正确位置,所以我们要再重新执行一遍脚本,而且这次会开启所有的Log。
1. 在VuGen中点选【Vuser】>【Run-Time Settings】。
2. 点选【General】>【Log】。
3. 勾选【Enable logging】、【Always sends messages】、【Extended log】,以及【Extended log】下的所有选项。
4. 按下【OK】就可以执行脚本了。
执行完脚本之后,在Execution Log中搜寻刚刚复制的字符串。找到字符串后,在字符串前面会有A.tion1.c(7),这个7就是到时候要插入web_reg_save_param函数的位置,也就是要插入到脚本的第7行。
在脚本的第7行前插入一行空白行,然后输入
web_reg_save_param(“UserSession”,
“UserSession” 这个 “UserSession” 就是到时要使用的参数名称,建议给个有意义的名字。
注意:到这里整个web_reg_save_param函数还没完成。
2. 找出web_reg_save_param中要用到的边界
web_reg_save_param函数主要是透过动态数据的前面和后面的固定字符串,来辨识要撷取的动态数据的,所以我们还需要找出动态数据的边界字符串。
找出左边界字符串
再回到Execution Log中,选取动态数据前的字符串并且复制它。
这时会有个问题,到底要选取多少字符串才足以唯一识别要找的动态数据呢?建议是越多越好,但是尽量不要包含到特殊字符。
在这边我们选取「input type=hidden name=userSession value=」字符串。选好之后,还要再确认一次这段字符串真的是可以唯一识别的,所以我们在Execution Log中透过Ctrl+F的搜寻,找找看这段字符串是否可以找到要找的动态数据。假如找不到,web_reg_save_param函数还有个ORD参数可以使用,ORD参数可以设定出现在第几次的字符串才是要找的字符串。
将这个边界字符串加到未完成的web_reg_save_param函数中:
web_reg_save_param(“UserSession”, “LB= input type=hidden name=userSession value=”,
找出右边界字符串
接下来要找出动态数据的右边界字符串,这个字符串就比较好找了,从动态数据的最后一个字符开始,通常就是我们要找的右边界字符串了。
以这个例子来看,就是「>」,所以再把右边界字符串加入,web_reg_save_param函数中,这时web_reg_save_param函数已经快完成了。最后再加上「LAST);」就完成整个web_reg_save_param函数了。
web_reg_save_param(“UserSession”, “LB= input type=hidden name=userSession value=”, “RB=>”, LAST);
将脚本中有用到关联的数据,以参数取代
当使用web_reg_save_param建立参数后,接下来就是用“UserSession”参数去取代脚本中写死的(hard-coded)资料。
范例:
将
“Name=userSession”, “Value=75893.0884568651DQADHfApHDHfcDtccpfAttcf”, ENDITEM,
换成
“Name=userSession”, “Value={UserSession}”, ENDITEM,
到这里您已经完成了一个关联了,接下来就是执行脚本,是否能成功运行,假如还是有问题,就要检查看看是否还需要再做另一个关联。
关于 web_reg_save_param 函数
对于关联(correlation)来说,web_reg_save_param是最重要的一个函数,其功能是在下载的网页内容中,透过设定的边界字符串,找出特定的数据并将其储存在一个参数中,以供后续脚本使用。
接下来将针对web_reg_save_param做比较详细的说明。
Service and registration type function
web_reg_save_param是一个Service function。service function主要是用来完成一些特殊的工作的,如关联、设定proxy、提供认证信息等,当其作用时,不会对网页的内容做任何的修改。
web_reg_save_param同时也是一个registration type function (只要函数名称中包含_reg_的字眼,表示其为registration type function)。registration type function意味着其真正作用的时机是在下一个action function完成时执行的。举例来说,当某个web_url执行时所接收到的网页内容中包含了要做关联的动态数据,则必须将web_reg_save_param放在此web_url之前,则web_reg_save_param会在web_url执行完毕后,也就是网页内容都下载完后,再执行web_reg_save_param找寻要做关联的动态数据并建立参数。
所以要记住一点,要使用registration type function时,要注意其放置的位置必须在要作用的action function之前。
语法
int web_reg_save_param(const char *ParamName, <list of Attributes>, LAST);
参数说明
ParamName:存放动态数据的参数名称
list of Attributes:其它属性,包含 Notfound, LB, RB, RelFrameID, Search, ORD, SaveOffset, Convert, 以及 SaveLen。属性值不分大小写,例如 Search=all。以下将详细说明每个属性值的意义:
• Notfound:指定当找不到要找的动态数据时该怎么处置。
o Notfound=error:当找不到动态数据时,发出一个错误讯息。假如没设定此属性,此为LoadRunner的默认值。
o Notfound=warning:当找不到动态数据时,不发出错误讯息,只发出警告,脚本也会继续执行下去不会中断。在对角本除错时,可以使用此属性值。
• LB:动态数据的左边界字符串。此属性质是必须要有的,而且区分大小写。
• RB:动态数据的右边界字符串。此属性质是必须要有的,而且区分大小写。
• RelFrameID:相对于URL而言,欲搜寻的网页的Frame。此属性质可以是All或是数字,而且可有可无。
• Search:搜寻的范围。可以是Headers(只搜寻headers)、Body(只搜寻body部分,不搜寻header)、Noresource(只搜寻body部分,不搜寻header与resource)或是All(搜寻全部范围,此为默认值)。此属性质可有可无。
• ORD:指明从第几次出现的左边界开始才是要撷取的数据。此属性质可有可无,默认值是1。假如值为All,则所有找到符合的数据会储存在数组中。
• SaveOffset:当找到符合的动态数据时,从第几个字符开始才开始储存到参数中。此属性质不可为负数,其默认值为0。
• Convert:可能的值有二种:
o HTML_TO_URL: 将HTML-encoded数据转成URL-encoded数据格式
o HTML_TO_TEXT:将HTML-encoded数据转成纯文字数据格式
• SaveLen:从offect开始算起,到指定的长度内的字符串,才储存到参数中。此参数可有可无,默认值是-1,表示储存到结尾整个字符串。
范例
web_reg_save_param("A", "LB/ic=<a href=", "RB='>", "Ord=All", LAST);nner会搜寻网页中所有以 「<a href=」 开头,且以 「’>」结束,当中包含的字符串,并且储存在「A」参数中。
Tips and Tricks
以下提供一些关联的常见问题:
• 如何打印出参数值?
lr_output_message这二个函数来做到。例如:
lr_output_message(“Value Captured = %s”, lr_eval_string(“{ParameterName}”));
lr_eval_string与lr_output_message函数的使用说明请参考LoadRunner Online Function Reference。
• 在脚本的data目录下找不到路制时的快照(snapshot)
造成在脚本的data目录下找不到路制时的快照(snapshot)的可能原因如下:
o 脚本是由VuGen 6.02或更早的版本所录制的
o 汇入的Action不会包含快照(snapshot)的档案
o 脚本是储存在只读的目录下,早成VuGen无法储存执行时撷取的快照(snapshot)
o 某些步骤并不会产生快照(snapshot),如浏览某个资源
o 快照(snapshot)功能被取消
【Tools】>【General options】>【Correlation】tab >【Save correlation information during replay】
• 开启WinDiff时出现「File no longer available」的错误讯息
WinDiff这个工具有些限制,无法开启包含空格符的目录或是脚本,所以建议命名时不要使用空格符,并且尽可能将名称取短一点。
• 录制时突然跳出【Correlation warning】对话窗口
当你有勾选自动关联的【Issue a popup message and let me decide online】选项,当VuGen发现有可能要做关联的数据时,就会跳出【Correlation warning】的窗口,询问你要做关联(Correlation in scrīpt)还是要忽略(Ignore)。
另外你也可以勾选【Perform. correlation in scrīpt】,让VuGen自动作关联,不会再跳出询问窗口。
或是勾选【Disable correlation engine】,关闭自动关联的功能。
• 如何手动启动「Scan action for correlation」的功能
要手动启动「Scan action for correlation」的功能,请先执行脚本一次后,点选【Vuser】>【Scan Action for Correlation】。
• 执行完脚本后并未出现【Scan Action for Correlation】窗口
要启用【Scan Action for Correlation】功能,请点选【Tools】>【General options】>【Correlation】tab,勾选【Show Scan for correlation popup after replay of Vuser】选项。 -
一个性能测试的案例(转自51)
2008-12-08 17:32:31
利用现代的设计技术和正式的技术复审可以减少代码中存在的初始错误,但是错误总是存在的,如果开发者找不到错误,那么,客户就会找到它们。越来越多的软件组织认识到软件测试是软件质量保证的重要元素之一,很多软件开发组织将30%—40%甚至更多的项目资源用在测试上,软件测试技术和软件测试策略受到了高度的重视和广泛的应用。本文不想就软件测试技术和软件测试策略作深入的理论分析,而是列举一个在软件系统测试阶段进行的压力测试实例,希望能通过这个实例与从事软件测试相关工作的朋友进行交流。
首先介绍一下实例中软件的项目背景,该软件是一个典型的三层C/S架构的MIS系统(客户端/应用服务器/数据库管),中间层是业务逻辑层,应用服务器处理所有的业务逻辑,但应用服务器本身不提供负载均衡的能力,而是利用开发工具提供的ORB(对象请求代理)软件保证多个应用服务器间的负载均衡。本次测试的目的是:进行单个应用服务器的压力测试,找出单个应用服务器能够支持的最大客户端数。测试压力估算的依据是:假定在实际环中,用户只启用一个应用服务器进行所有的业务处理。方法是:按照正常业务压力估算值的1~10倍进行测试,考察应用服务器的运行情况。
压力测试的详细计划如下:
压力测试计划
1、测试计划名称
XXX系统压力测试计划。
2、测试内容
2.1 背景
本次测试中的压力测试是指模拟实际应用的软硬件环境及用户使用过程的系统负荷,长时 间运行测试软件来测试被测系统的可靠性,同时还要测试被测系统的响应时间。
用户的实际使用环境:
◇由两台IBM XSeries250 PC Server组成的Microsoft Cluster;
◇数据库管理系统采用Oracle8.1.6;
◇应用服务器程序和数据库管理系统同时运行在Microsoft Cluster上。
◇有200个用户使用客户端软件进行业务处理,每年通过软件进行处理的总业务量为:150万笔业务/年。
2.2 测试项
应用服务器的压力测试;
2.3 不被测试的特性
◇系统的客户端应用程序的内部功能;
◇数据库中的数据量对程序性能的影响。
3、测试计划
3.1 测试强度估算
测试压力估算时采用如下原则:
◇全年的业务量集中在8个月完成,每个月20个工作日,每个工作日8个小时;
◇采用80—20原理,每个工作日中80%的业务在20%的时间内完成,即每天80%的业务在1.6小时内完成;
测试压力的估算结果:
去年全年处理业务约100万笔,其中15%的业务处理每笔业务需对应用服务器提交7次请求;
70%的业务处理每笔业务需对应用服务器提交5次请求;其余15%的业务每笔业务向应用服务器提交3次请求。根据以往统计结果,每年的业务增量为15%,考虑到今后三年业务发展的需 要,测试需按现有业务量的2倍进行。
每年总的请求数量为:(100*15%*7+100*70%*5+100*15%*3)*2=300万次/年。
每天的请求数量为:300/160=1.875万次/天。
每秒的请求数量为:(18750*80%)/(8*20%*3600)=2.60次/秒。
正常情况下,应用服务器处理请求的能力应达到:3次/秒。
3.2 测试环境准备
3.2.1 基本硬件及软件环境的准备
1) 网络环境:公司内部的以太网,与服务器的连接速率为100M,与客户端的连接速率为10/100M自适应。
2)使用两台IBM XSeries250(1G内存)PC Server作Microsoft Cluster,安装系统软件 Windows 2000 Advance Server及Microsoft Cluster Server(MSCS)。
3) 数据库管理系统的安装及配置:在测试用的IBM XSeries服务器上安装Oracle8.1.6,数据 库采用Oracle Fail Safe(ofs)的Active/Passive配置。 安装数据库管理系统及支撑软件(包括VisiBroker和BDE Administrator)。
4) 安装被测的应用服务器程序。
5) 客户端的PC机:10台(PⅢ600/128M RAM)。
3.2.2 系统客户端测试程序的编写系统客户端测试程序使用Delphi编写,要求测试程序实现如下功能:
1) 模拟一个主要的向应用服务器发送请求并接收响应信息的功能。要求交替模拟两种情况:第一种,发送的请求至少包括10个参数,参数类型涵盖字符、日期、数字种类型;接收的响应信息不少于1个参数;第二种,发送的请求不少于1个参数;接收的响应信息至少包括10个参数,参数类型涵盖字符、日期、数字种类型。
2) 必须能够通过参数设定在每台PC机上运行的客户端测试程序个数、请求的时间间隔(单位:毫秒)、运行时间(单位:小时)。
3) 在数据库中建立测试记录表,生成测试记录,向数据库写入测试记录的功能不通过被测的应用服务器实现。日志内容包括:发送测试请求的机器名、客户端测试程序序号、发出请求时间、收到响应时间、处理是否成功。表名:TEST_LOG,字段名:MACHINE、ID、START_TIME、 END_TIME、FLAG。
3.2.3 系统本底数据的准备
为考察系统运行一段时间后系统的响应性能,参照实际运行情况及发展进行系统的本底数据准备。业务处理中涉及到的业务表中都要求按设计规模进行本底数据的准备。要求准备的数据记录的有效性符合系统要求,数据有效性的具体要求参见数据库设计及系统设计文档。
3.3 破坏性测试
按照设计连接的客户端连接数量进行测试,把应用服务器处理请求的设计频度增加1-10倍,分别测试出现错误的状态和和出现错误的比率,考察是否出现不可恢复错误,系统设计要考 虑出现严重错误情况下负荷减轻错误自动恢复的实现方法。
计划时间:2天;这个时间包括破坏性的修复和自动恢复的实现需要的时间。
在测试过程中每10分钟记录一次IBM Xseries PC Server的内存及CPU使用情况,包括被测程序的内存占用百分比、数据库管理系统的内存占用百分比、操作系统的内存占用百分比。
3.4 强度稳定性测试
选择一种负荷比设计负荷重的情况(应用服务器处理请求的频度为应用服务器处理请求的设计频度的1.5倍),进行24小时稳定性测试。
3.5 测试方法和工具
黑盒测试
测试工具:无外购的测试工具,自己编制的测试工具。
3.6 测试时间计划
3.6.1 环境准备:2天。
其中:基本硬件、软件环境及系统本底数据的准备:1天,
系统客户端测试程序的编写及测试:1天。
3.6.2 破环性测试:2天。
3.6.3 强度稳定性测试:1天。
3.7 测试中的问题及处理
3.7.1 暂停标准和再启动要求
暂停标准:被测试软件在强度稳定性测试中频繁出现异常(每小时出现1次以上)时。用户或公司要求暂停测试时。
再启动要求:通过调试后,预计被测试软件的可靠性有所提高时,可再次启动测试。
3.7.2 不可预见问题
不可预见问题包括:
◇测试环境被破坏而导致测试无法进行;
◇当出现上述不可预见问题时,测试终止,就已完成的测试内容编制测试总结报告,并在报告中说明测试终止的原因。
3.8 测试报告 2002.06.21
测试总结报告提交日期:2002.06.21。
3.8.1 应生成的测试文件
测试记录(测试负责人和参与测试的人员签字);
测试总结报告。
3.8.2 测试总结报告中必须包含的内容
被测试软件名称、测试项、测试环境;
被测试软件的压力测试结论:响应时间、最大/最小并发数、失败的次数、正常连续运行的最长/最短时间,并发数与失败的关系。
4、人员和职责
4.1 职责
测试工程师:负责编写测试计划,组织测试,对测试过程进行记录,收集、整理测试记录数据,对测试结果进行分析,编写测试总结报告。
软件工程师:负责编写、调试客户端测试软件;数据库管理系统的安装、ofs配置及系统的本底数据准备。
系统工程师:负责测试用的硬件维护及操作系统安装、MSCS配置。
总工程师:负责对测试计划及测试总结报告进行批准。
用户:必要时可参加测试,并提出具体的测试要求;可要求暂停测试。
4.2 人员和训练要求
本次测试无特别的人员及培训要求。
5、批准
本测试计划必须经过总工程师批准后才能开始实施。
-
LoadRunner协议选择(转)
2008-12-08 17:23:08
正确选择协议,就要熟悉被测试应用的技术架构。以下列出一些LoadRounner支持的协议:
一般应用:C Vuser、VB Vuser、VB scrīpt Vuser、JAVA Vuser、Javascrīpt Vuser
电子商务:WEB(Http/Html)、FTP、LDAP、Palm、Web/WinsocketDual Protocol
客户端/服务器:MS SQL Server、ODBC、Oracle、DB2、Sybase CTlib、Sybase DBlib、Domain Name Resolution(DNS)、Windows Socket
分布式组件:COM/DCOM、Corba-Java、Rmi_Java
EJB:EJB、Rmi_Java
ERP/CRP: Oracle NCA、SAP-Web、SAPGUI、SAPGUI/SAP-Web Dual Protocol、PropleSoft_Tuxedo、Siebel Web、Siebel-DB2 CLI、Sieble-MSSQL、Sieble Oracle
遗留系统:Terminal Emulation (RTE)
Mail 服务:Internet Messaging(IMAP)、MS Exchange(MAPI)、POP3、SMTP
中间件:Jacada、Tuxedo 6、Tuxedo 7
无线系统:i-mode、voiceXML、WAP
应用部署软件:Citrix_ICA流:Media Plays(MMS)、Real
一段对于loadrunner协议选择的经典解答协议是数据在网络中传输的结构模式。协议不同,其数据报文的结构也有所不同。协议是有层次的,一般我们从ip层开始,往上有TCP协议层,UDP协议层,而TCP和UDP协议层上又有http协议层,ftp协议层,smtp协议层等我们在lr中看到的这些应用层的协议。其实这些高层协议都是对底层协议进行的进一步封装。举个简单例子,本来IP协议的数据报文是无序,不是可靠传输的,在其数据报文外面增加了报文序号,报文状态等数据段就构成了TCP协议层。所以我们很多网络应用,没有找到合适的协议,就用winsock来录制,那是肯定没有问题的。因为几乎所有的网络传输中都是基于tcp 协议或udp协议的,而socket正是这一级上的概念。但是由于socket协议级别太低,你录下来的东西是很难理解的,都是 socket,port,data之类的东西。所以,我们尽量用高层协议来录制,我们就能看懂了。
话要再说回来,解决一下具体的问题。我们看到一个软件体系架构,应该怎样选择录制协议呢?说到这里,我要说一下自己对lr录制机理的理解(我没有接触过lr内核,只是凭猜测和推断)。在录制时,lr应该会对你从本机发出去的数据进行截包,并拆包。因为我们知道协议的不同就是体现在数据包的结构不同,lr应该通过对包结构的分析,判断是不是它支持的协议,对包数据的分析,来获取用户发送的东西。比如你用ftp的协议去录制一个访问网页的IE操作,那肯定是无所收获的。因为lr没有在网络截获到 ftp协议格式的包,都是http协议格式的包,它不认,当然就是一个录制为空的结果了。现在我们弄懂了这个事情,就知道该如何选择协议了。看见很多人关心lr是不是支持mysql协议。我认为要寻找的答案的思路是这样的:
1、首先弄清mysql协议和其他数据库协议的关系,看能不能用其它数据库协议录制。但其实oracle的cs协议是oracle独有自己开发的协议,sqlserver也是一样,而mysql又与这几大产品又不是隶属关系,其脚本录制的可能性很小。
2、mysql协议的底层是基于什么协议的,如果直接构建在tcp协议上,lr又不支持mysql协议,那只能考虑用低一点的协议录录看,即socket。如果mysql协议是构建在odbc协议上的,那么就可能用lr的odbc api来写。
很多时候一提到不是基于浏览器的应用,很多人就会想到用 WinSocket协议来录制,仿佛Form窗体都可以用Winsocket 。从道理上讲网络通讯的底层都是基于Socket的,例如TCP、UPD等,似乎所有的程序都可以用Socket协议来录制。但是事实不是这样的,因为选择的协议决定了LoadRunner如何捕获数据包。否则会多捕获很多无用的数据。因此,不是所有的程序都是适合WinSocket协议的。实际上,那些基于Socket开发的应用才真正适合Socket协议来进行录制。其他的,例如基于数据库的应用,就不太时候Socket协议,甚至可能录制不到脚本。很多C/S程序,一定要选择合适的协议。根据作者的经验,C/S的程序多数需要手工开发很多脚本,因为录制的很多回放时候或多或少都会有些问题,但是可以参考录制的结果。所以测试一个程序,一定要搞清楚开发人员用了什么技术、数据流是什么协议封装的。理论上来说我们在对一个系统做性能测试以前,要先和开发人员了解一下他们在开发过程中都用了些什么技术,数据流是用什么协议封装的,还要了解我们要测试的系统的网络结构,服务器的配置等问题;还有就是要知道系统客户端和第一服务器间的协议,这中间就涉及到一个中间件的问题。另外我们要知道协议的选择直接关系到LR会捕获到什么样的数据包。这些是进行性能测试的基础。 下面说几个测试的原则(都是自己遇到过的,呵呵,没遇到过的就不知道了):
1、一般情况下b/s构架的只要 选择WEB(Http/Html)协议就可以了,如果有中间件的则选择中间件服务器的协议 ;
2、C/S结构,可以根据后端数据库的类型来选择。如SybaseCTLib协议用于测试后台的数据库为Sybase的应用;MS SQL Server协议用与测试后台数据库为 SQL Server的应用;
3、一般不是基于浏览器的,对于一些没有数据库的 Windows应用,我们在测试的过程中都会选择WinSocket协议来录制,理论上来讲我们这样选择是正确的,但我们要知道在录制的时候所选择的协议就决定了LR如何捕获数据包,如果我们选择错误了,将会捕获到一些无用的数据包。cs结构是比较复杂的,在这里我要提醒大家,一定要搞清楚cs是 client-database还是client-server-database结构的,只有这样我们才能够决定是选择WinSocket协议还是 sql协议,或者说选择多个协议;当然协议的选择也是一个探索的过程,只要能够得到我们想要的结果,那就是正确的。还有一点,我们在做性能测试的时候应该是有测试重点的,呵呵。
4、关于单协议和双协议,我只知道IE6内核的浏览器在录制脚本的时候要选择单协议,而IE7内核的浏览器在录制脚本的时候要使用双协议。
-
LoadRunner的脚本回放问题解决
2008-12-08 17:18:09
在运行脚本回放过程中,有时会出现错误,这在实际测试中是不可避免的,毕竟自动录制生成的脚本难免会有问题,需要运行脚本进行验证,把问题都解决后才加入到场景中进行负载测试。下面结合常用的协议(如Web、Web Services协议)录制的脚本进行回放时出现的问题介绍一下解决的方法。需要注意的是,回放脚本时出现的错误有时是程序自身的原因导致的,因此在解决脚本回放问题前必须保证程序录制出的脚本是正确的。
1.LoadRunner超时错误:在录制Web协议脚本回放时超时情况经常出现,产生错误的原因也有很多,解决的方法也不同。
错误现象1:Action.c(16): Error -27728: Step download timeout (120 seconds) has expired when downloading non-resource(s)。
错误分析:对于HTTP协议,默认的超时时间是120秒(可以在LoadRunner中修改),客户端发送一个请求到服务器端,如果超过120秒服务器端还没有返回结果,则出现超时错误。
解决办法:首先在运行环境中对超时进行设置,默认的超时时间可以设置长一些,再设置多次迭代运行,如果还有超时现象,需要在“Runtime Setting”>“Internet Protocol:Preferences”>“Advanced”区域中设置一个“winlnet replay instead of sockets”选项,再回放是否成功。
错误现象2:Action.c(81):Continuing after Error -27498: Timed out while processing URL=http://172.18.20.70:7001/workflow/bjtel/leasedline/ querystat/ subOrderQuery.do
错误分析:这种错误常常是因为并发压力过大,服务器端太繁忙,无法及时响应客户端的请求而造成的,所以这个错误是正常现象,是压力过大造成的。
如果压力很小就出现这个问题,可能是脚本某个地方有错误,要仔细查看脚本,提示的错误信息会定位某个具体问题发生的位置。
解决办法:例如上面的错误现象问题定位在某个URL上,需要再次运行一下场景,同时在其他机器上访问此URL。如果不能访问或时间过长,可能是服务器或者此应用不能支撑如此之大的负载。分析一下服务器,最好对其性能进行优化。
如果再次运行场景后还有超时现象,就要在各种图形中分析一下原因,例如可以查看是否服务器、DNS、网络等方面存在问题。
最后,增加一下运行时的超时设置,在“Run-Time Settings”>“Internet Protocol:Preferences”中,单击“options”,增加“HTTP-request connect timeout” 或者“HTTP-request receive”的值。
2.LoadRunner脚本中出现乱码:在录制Web协议脚本时出现中文乱码,在回放脚本时会使回放停止在乱码位置,脚本无法运行。
错误现象:某个链接或者图片名称为中文乱码,脚本运行无法通过。
错误分析:脚本录制可能采用的是URL-based scrīpt方式,如果程序定义的字符集合采用的是国际标准,脚本就会出现乱码现象。
解决办法:重新录制脚本,在录制脚本前,打开录制选项配置对话框进行设置,在“Recording Options”的“Advanced”选项里先将“Surport Charset”选中,然后选中支持“UTF-8”的选项。
3.LoadRunner HTTP服务器状态代码:在录制Web协议脚本回放脚本的过程中,会出现HTTP服务器状态代码,例如常见的页面-404错误提示、-500错误提示。
错误现象1:-404 Not Found服务器没有找到与请求URI相符的资源,但还可以继续运行直到结束。
错误分析:此处与请求URI相符的资源在录制脚本时已经被提交过一次,回放时不可再重复提交同样的资源,而需要更改提交资源的内容,每次回放一次脚本都要改变提交的数据,保证模拟实际环境,造成一定的负载压力。
解决办法:在出现错误的位置进行脚本关联,在必要时插入相应的函数。
错误现象2:-500 Internal Server Error服务器内部错误,脚本运行停止。
错误分析:服务器碰到了意外情况,使其无法继续回应请求。
解决办法:出现此错误是致命的,说明问题很严重,需要从问题的出现位置进行检查,此时需要此程序的开发人员配合来解决,而且产生的原因根据实际情况来定,测试人员无法单独解决问题,而且应该尽快解决,以便于后面的测试。
4.LoadRunner请求无法找到:在录制Web协议脚本回放脚本的过程中,会出现请求无法找到的现象,而导致脚本运行停止。
错误现象:Action.c(41): Error -27979: Requested form. not found [MsgId: MERR-27979]
Action.c(41): web_submit_form. highest severity level was "ERROR",0 body bytes, 0 header bytes [MsgId: MMSG-27178]"
这时在tree view中看不到此组件的相关URL。
错误分析:所选择的录制脚本模式不正确,通常情况下,基于浏览器的Web应用会使用“HTML-based scrīpt”模式来录制脚本;而没有基于浏览器的Web应用、Web应用中包含了与服务器进行交互的Java Applet、基于浏览器的应用中包含了向服务器进行通信的Javascrīpt/VBscrīpt代码、基于浏览器的应用中使用HTTPS安全协议,这时则使用“URL-based scrīpt”模式进行录制。
解决办法:打开录制选项配置对话框进行设置,在“Recording Options”的“Internet Protocol”选项里的“Recording”中选择“Recording Level”为“HTML-based scrīpt”,单击“HTML Advanced”,选择“scrīpt Type”为“A scrīpt containing explicit”。然后再选择使用“URL-based scrīpt”模式来录制脚本。
5.LoadRunner不执行检查方法:在录制Web协议脚本中添加了检查方法Web_find,但是在脚本回放的过程中并没有执行。
错误现象:在脚本中插入函数Web_find,在脚本中设置文本以及图像的检查点,但是在回放过程中并没有对设置的检查点进行检查,即Web_find失效。
错误分析:由于检查功能会消耗一定的资源,因此LoadRunner默认关闭了对文本以及图像的检查,所以在设置检查点后,需要开启检查功能。
解决办法:打开运行环境设置对话框进行设置,在“Run-time Settings”的“Internet Protocol”选项里的“Perference”中勾选“Check”下的“Enable Image and text check”选项。
6.LoadRunner回放Web Services协议脚本错误:LoadRunner 8.0版本在录制Web Services协议的脚本时正常,但在回放时会出现错误,提示停止脚本运行。
错误现象:利用LoadRunner 8.0版本来录制Web Services协议的脚本没有任何错误提示,回放脚本时会出现如下错误提示“Error:server returned an incorrectly formatted SOAP response”。
错误分析:出现此错误的原因是LoadRunner8.0在录制Web Services协议的脚本时存在一个缺陷:如果服务器的操作系统是中文的,VuGen会自动将WSDL文件的头改为<?xml version="1.0"encoding="zh_cn" ?>,所以才会有此错误提示。
解决办法:下载两个补丁,分别为“LR80WebServicesFPI_setup.exe”和“lrunner_web_ services_patch_1.exe”安装上即可。
-
根据性能需求设计性能测试用例
2008-11-28 13:23:10
本文出自huruihai的51Testing软件测试博客:http://www.51testing.com/?41972某网站提供会员模板下载、上传、购买、支付等功能,目前进入性能测试阶段,通过性能需求可以了解到主要有以下几个性能指标需要进行测试:51Testing软件测试网ED3RW:Nw gN
产品页面刷新性能
x n?j+f+t FJ0产品上传性能
.\C4Uk;q m0D%{(}0产品下载性能51Testing软件测试网FJ^-}tnUom
搜索性能51Testing软件测试网L\ c5_qr K4i
目前给出的指标为:51Testing软件测试网8Ug7P#m8I)~d o4w2Y
延迟:51Testing软件测试网dM5Ec6@F?'S
测试项 响应时间 抖动 备注 51Testing软件测试网 UjP,x{Fp9R
产品页面刷新 <5秒 <2秒 51Testing软件测试网p(j-[K9VU.O|
产品下载相应时间 <4秒 <2秒51Testing软件测试网l&p8T/Q blf)?
吞吐量:51Testing软件测试网8F-v2kNi*HG@j q }+g']
编号 项 吞吐量 51Testing软件测试网j}T| NY0p-k!m!Tu a
Perf.T.1 所有登录用户在线状态更改频率 每10分钟1次 51Testing软件测试网 taA&|J B(f
Perf.T.2 每日页面平均访问量 60000次
$xp0{c^0Perf.T.3 每日下载量 50000
U9d1d%Jz&m0Perf.T.4 平均每日新增会员数量 500
3R|"ttq,| J F0Perf.T.5 高峰同一模板下载量 100用户并发下载
8Ee"l-i/Fc}"G:}0Perf.T.6 高峰不同模板下载量 150用户并发下载
1AYC"I~qPn^0容量:
[+~YetI0编号 项 容量 51Testing软件测试网)BR/x-vKU.M
Perf.C.1 用户数 <=100万
| c7Z v4sp2@0Perf.C.2 活动用户数 10000 51Testing软件测试网Q4KA!nx W;QO7[
Perf.C.3 模板中心总用户数 <=25万51Testing软件测试网wktv6D}gli-`
根据如上性能需求及数据我们该如何设计性能测试用例及场景呢?(可以说给出的性能需求很垃圾,没有丝毫价值,但没办法还是点做啊)
|.L}|u9mS0首先,我不去在乎它要求的性能是什么,我只需要去做在一定的测试环境下对系统进行压力测试,找到各个性能指标的临界点就好了,至于是否达到性能指标,在和性能需求对照编写测试报告即可。51Testing软件测试网2JmZ3d(?GYN|m"|
所以,针对这几个需要进行性能测试的页面,我们做一下分析,如何设计场景才能尽可能准确地体现出系统的性能:
c6z$G6S+X2{3`0先说一下搜索页面
*a;A c^F YA~"p0搜 索页面根据对项目的了解,搜索后,将所有符合条件的结果遍历出来,显示在前台,每页的显示数量是一定的,超出的部分分页显示。根据上面的描述我们可以看出 搜索结果是在将符合条件的所有结果集均发送到前台页面,对于页面显示对性能的消耗我们可以忽略不计,主要的压力来自数据的传输、sql的执行及应用服务器 的处理过程,所以我可以从两个方面设计场景:w7m0z7Dz??*U8x0a、虚拟用户一定,不同数据库数量级的情况下,搜索的性能
W,NtbLT&g%}0如 何确定虚拟用户的数量成为一个关键,我们可以让客户提供一个常规情况下每天访问用户数(如果没有实际数据可参考,可以根据产品方案中期望的用户数来代 替),我们就用这个用户数来进行测试;再来分析一下不同的数据库数量级,如果系统运营1年的产品数据量是5万条,那么我们就根据这个值分别取1W条、3W 条、5W条、10W条、20W条数据量来进行测试(具体的分法可以根据实际情况而定),所以对于这个测试目标,我们可以设计5个场景进行:51Testing软件测试网,}bu%b h1P
51Testing软件测试网x8?0i@i
虚拟用户数 数据库数量级 录制页面 并发用户数 执行时间 思考时间 51Testing软件测试网H.A"p:{@i0v
100 10000 搜索页面 随机产生 30分钟 加入思考时间 51Testing软件测试网 q4j)F6s$h7HL
100 30000 搜索页面 随机产生 30分钟 加入思考时间
z.z![A O_ X9p%Q0100 50000 搜索页面 随机产生 30分钟 加入思考时间
yC gj/B-rV0100 100000 搜索页面 随机产生 30分钟 加入思考时间
Y$i#@9Jnsr0100 200000 搜索页面 随机产生 30分钟 加入思考时间 51Testing软件测试网I2W[PA%k
b、一定数据库数量级,不同量虚拟用户的情况下,搜索的性能
MNx?#w _X0我们定下来一个常规的数据库数据量,在数据量不变的情况下逐步增加虚拟用户数,测试一下不同虚拟用户压力下系统的性能
9Ru*L&p*_$P9_0
6E w9jJe'Vh1oh Y;Z0虚拟用户数 数据库数量级 录制页面 并发用户数 执行时间 思考时间 51Testing软件测试网`9b6X'qa3^gX
50 50000 搜索页面 随机产生 30分钟 加入思考时间 51Testing软件测试网hv6T}y:z9^.b!g
80 50000 搜索页面 随机产生 30分钟 加入思考时间
F9b izn0100 50000 搜索页面 随机产生 30分钟 加入思考时间 51Testing软件测试网V2FZ%tIo {4l#v
120 50000 搜索页面 随机产生 30分钟 加入思考时间
rD/xf8D]0[2l6^(b0150 50000 搜索页面 随机产生 30分钟 加入思考时间产品上传51Testing软件测试网l)M jtJ"e0K]
影响上传性能的主要因素有上传文件的大小和上传的请求数,所以我们就从这两个方面设计用例。51Testing软件测试网0y4r _pRA;F9qn3b-X(Z
a、虚拟用户数一定,上传不同大小的文件
p!xMe$N,p0
v w;\.n-o4B\|0虚拟用户数 上传文件大小 录制页面 并发用户数 执行时间 思考时间
k|*`h&M050 100k 上传页面 随机产生 30分钟 取消思考时间
GduW$Zo1L050 300k 上传页面 随机产生 30分钟 取消思考时间 51Testing软件测试网uC2~!ji8z[
50 500k 上传页面 随机产生 30分钟 取消思考时间
GH2US.e G050 800k 上传页面 随机产生 30分钟 取消思考时间
}HY@ Vd{)LG u,^050 1M 上传页面 随机产生 30分钟 取消思考时间b、上传文件大小一定,不同量的虚拟用户51Testing软件测试网 O*z3L*v|
8rG Mnn5X!Ii0虚拟用户数 上传文件大小 录制页面 并发用户数 执行时间 思考时间
qCO?4x me%DI020 300k 上传页面 随机产生 30分钟 取消思考时间
t;zq6v8zHyA\050 300k 上传页面 随机产生 30分钟 取消思考时间
-G(ec.Z+P:u`)Z080 300k 上传页面 随机产生 30分钟 取消思考时间
*dvO Q&\x6@&aq0100 300k 上传页面 随机产生 30分钟 取消思考时间产品下载51Testing软件测试网x)k+TkUph]W
影响下载性能的主要因素有下载文件的大小和下载的请求数,所以我们就从这两个方面设计用例@~ VP{|L5u'J6Ri0 a、虚拟用户数一定,下载不同大小的文件
b、下载文件大小一定,不同量的虚拟用户51Testing软件测试网2~)W T"hcHQ)w
n-H(TF:X*h8@i6C0
;o v ],R5z%dsK5A5W0虚拟用户数 下载文件大小 录制页面 并发用户数 执行时间 思考时间
R2U+[l r Y@?|;z050 100k 下载页面 随机产生 30分钟 取消思考时间
$JeuZ8kH5|050 300k 下载页面 随机产生 30分钟 取消思考时间
iC]nSB/Gs1gtn050 500k 下载页面 随机产生 30分钟 取消思考时间
f r Mh)m*g L050 800k 下载页面 随机产生 30分钟 取消思考时间 51Testing软件测试网9@$F5nx!eT5dr,A{/N
50 1M 下载页面 随机产生 30分钟 取消思考时间
2F^(i.OCn2Q3@m#m7t[6mx0虚拟用户数 下载文件大小 录制页面 并发用户数 执行时间 思考时间 51Testing软件测试网1i*`eqLXqu"`
20 300k 下载页面 随机产生 30分钟 取消思考时间
v7~E3~5rv?,~3l050 300k 下载页面 随机产生 30分钟 取消思考时间 51Testing软件测试网3T[0i"[9L3d2oPK.U
80 300k 下载页面 随机产生 30分钟 取消思考时间 51Testing软件测试网@6?&G-J"Nm-T
100 300k 下载页面 随机产生 30分钟 取消思考时间 -
性能测试—并发用户数的估算(转)
2008-11-05 09:52:18
在实际的性能测试工作中,测试人员常常会关心到并发用户数,也就是从业务角度关注究竟应该设置多少个并发数比较合理,以下是一个估算并发用户数的方法:(1) 计算平均的并发用户数: C = nL/T
(2) 并发用户数峰值: C’ ≈ C+3根号C
公式(1)中,C是平均的并发用户数;n是login session的数量;L是login session的平均长度;T指考察的时间段长度。
公式(2)则给出了并发用户数峰值的计算方式中,其中,C’指并发用户数的峰值,C就是公式(1)中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。
实例:
假设有一个OA系统,该系统有3000个用户,平均每天大约有400个用户要访问该系统,对一个典型用户来说,一天之内用户从登录到退出该系统的平均时间为4小时,在一天的时间内,用户只在8小时内使用该系统。
则根据公式(1)和公式(2),可以得到:
C = 400*4/8 = 200
C’≈200+3*根号200 = 242
标题搜索
我的存档
数据统计
- 访问量: 68521
- 日志数: 102
- 建立时间: 2008-04-12
- 更新时间: 2011-03-23