通过分解页面可以得到：比较大的响应时间到底是页面的哪个组件引起的？问题出在服
务器上还是网络传输上。
这里为了解说各个时间（比如：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)”

 

判断应用程序是否存在处理器瓶颈的方法：如果Processor Queue Length 显示的队列长度保持不变（>=2）个并且处理器的利用率%Processor Time 超过90%，那么很有可能存在处理器瓶颈。
如果发现Processor Queue Length 显示的队列长度超过2，而　处理器的利用率却一直很低，那么或许更应该去解决处理器阻塞问题，这里处理器一般不是瓶颈。
如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换（Context Switches/sec 显示的上下文切换次数比较大），那么就会占用大量的系统资源。
如果系统的吞吐量降低并且CPU 的使用率很高，并且此现象发生时切换水平在15000 以上，那么意味着上下文切换次数过高同时还可以比较Context Switches/sec 和%Privileged Time 来判断上下文切换是否过量。　
如果后者的值超过40%，且上下文切换的速率也很高，那么应该检查为什么会产生这样高的上下文切换。

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 :每秒钟检索的页数。该数字应少于每秒一页。

如果控制机（Controller machine）和Load Generators 计算机运行的都是Windows2000，
那么下面两个简单的技巧可以提高性能
l 在Load Generators 计算机上，依次进入“控制面板”——“系统”——选择“高级”
标签页，点“性能选项”按钮，选择优化“后台服务”选项，这样可以提高性能，从而
可以在每个Load Generators 上运行更多的虚拟用户
l 在Controller 计算机上，按照以上的步骤，进入“性能选项”窗口，不过这里选择优化
“应用程序”

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（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.测试分析

性能分析的通用方法之一是“拐点分析”的方法。“拐点分析”方法是一种利用性能计数器曲线图上的拐点进行性能分析的方法，只要关注性能表现上的“拐点”，获得“拐点”附近的资源使用情况，就能够定位出穖的性能瓶颈。

 

 

1.首先查看System\%Total Processor Time性能计数器的计数值

用于体现服务器整体的处理器利用率，对多处理器的系统而言，体现的是所有ＣＰＵ的平均利用率。

2.其次查看每个ＣＰＵ的Processor\%Processor Time和Processor\%User Time和Processor \%Privileged Time

Processor\%User Time是指系统的非核心操作消耗的ＣＰＵ时间，如果值大，可以考虑是否能通过算法优化等方法降低这个值。如果该服务器是数据库服务器，Processor\%User Time值大的原因很可能是数据库的排序或是函数操作消耗了过多的ＣＰＵ时间，可考虑优化数据。

3.研究系统处理器瓶颈

查看System\Processor Queue Length的值，若其大于ＣＰＵ数据的总数+１，说明産了处理器阻塞。在处理器的Processor \%ProcessorTime很高时，一般都伴随着处理器阻塞。

%DPC Time，越低越好。在多处理器系统中，如果这个值大于50%，并且Processor \%ProcessorTime非常高，加入一个网卡可能会提高性能。

1.　首先查看Memory\Available Mbytes指标

该计数值是描述穖可用内存的直接指标，在对系统进行操作系统级别的内存分析时，首先通过该指标建立一个初步的印象，了解性能测试过程中，系统是否仍然有足够的内存可用。

2.注意Page/sec、Pages Read/sec和Page Faults/sec的值

OS经常会利用磁盘交换的方式提高系统可用的内存量或是提高内存的使用效率。而这３个指标直接反映了ＯＳ进行磁盘交换的频度。

若Page/sec的计数持续高于几百，很可能会有内在方面的问题产生，但Page/sec的值很大不一定表现内存有问题，而可能是运行使用内存映射文件的程序所致。Page Faults/sec，页面失效次数越多，说明ＯＳ向内存中读取的次数越多。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并未降低，则是由于内存不足。

 

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个步骤。

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思考时间。

 

 

用户视角的软件性能

从用户的角度来说，软件性能就是软件对用户操作的响应时间。从客观的角度来说，事务的结束应该是系统返回所有的数据，响应时间应该是从用户操作开始到所有数据返回完成的整个耗时；但从用户的主观感知来说，如果采用一种优化的数据呈现策略，当少部分数据返回之后就立刻将数据呈现在用户面前，则用户感受到的响应时间就会远远小于实际的事务响应时间（这也是C/S结构的管理系统中开发人员常用的一种技巧）。

---

管理员视角的软件性能

管理员关心的问题	软件性能描述
服务器的资源使用状况合理吗	资源利用率
应用服务器和数据库的资源使用善合理吗	资源利用率
系统是否能够实现扩展	系统可扩展性
系统最多能支持多少用户的访问？系统最大的业务处理量是多少	系统容量
系统性能可能的瓶颈在哪里	系统可扩展性
更换哪些设备能够提高系统性能	系统可扩展性
系统能否支持7*24小时的业务访问	系统稳定性

---

开发人员视角的软件性能

开发人员关心的问题	软件性能描述
架构设计是否合理	系统架构
数据库设计是否存在问题	数据库设计
代码是否存在性能方面的问题	代码
系统中是否有不合理的内在使用方式	代码
系统中是否存在不合理的线程同步方式	设计与代码
系统中是否存在不合理的资源竞争	设计与代码

 

　性能测试是为了保证产品发布后其性能能够满足用户的需求，本文结合具体案例介绍了应用系统性能测试的六大步骤。

　　在本文介绍的这个案例中，被测应用系统是一家公司的客户信息系统，它主要用来录入、修改以及查询全球客户的信息，并将客户信息转入到业务系统。但是，在应用过程中，客户经常投诉在某个时刻新建或者修改一个客户信息非常慢，正常情况下完成该操作只需要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组件，改为由应用自身控制，尽量减少了大事物的出现概率，并同业务部门商议，降低了模糊查询操作的次数。在后来再做“性能评测”时确认系统达到了预期目标。

 当录制脚本时，VuGen会拦截client端（浏览器）与server端（网站服务器）之间的对话，并且通通记录下来，产生脚本。在VuGen的Recording Log中，您可以找到浏览器与服务器之间所有的对话，包含通讯内容、日期、时间、浏览器的请求、服务器的响应内容等等。脚本和Recording Log最大的差别在于，脚本只记录了client端要对server端所说的话，而Recording Log则是完整纪录二者的对话。

利用现代的设计技术和正式的技术复审可以减少代码中存在的初始错误，但是错误总是存在的，如果开发者找不到错误，那么，客户就会找到它们。越来越多的软件组织认识到软件测试是软件质量保证的重要元素之一，很多软件开发组织将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、批准

　　本测试计划必须经过总工程师批准后才能开始实施。

正确选择协议，就要熟悉被测试应用的技术架构。以下列出一些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内核的浏览器在录制脚本的时候要使用双协议。

在运行脚本回放过程中，有时会出现错误，这在实际测试中是不可避免的，毕竟自动录制生成的脚本难免会有问题，需要运行脚本进行验证，把问题都解决后才加入到场景中进行负载测试。下面结合常用的协议（如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”安装上即可。

本文出自huruihai的51Testing软件测试博客：http://www.51testing.com/?41972

某网站提供会员模板下载、上传、购买、支付等功能，目前进入性能测试阶段，通过性能需求可以了解到主要有以下几个性能指标需要进行测试：51Testing软件测试网ED3RW:Nw gN
产品页面刷新性能
x n?j+f+t FJ0产品上传性能
.\C4Uk;q m0D%{(}0产品下载性能51Testing软件测试网FJ^-}tnUom
搜索性能51Testing软件测试网L\ c5_�q
r K4i
目前给出的指标为：51Testing软件测试网8Ug7P#m8I)~
d o4w2Y
延迟：51Testing软件测试网dM5Ec6@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| NY0p-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%J�z&m0Perf.T.4 平均每日新增会员数量         500   
3R|"ttq,| J F0Perf.T.5 高峰同一模板下载量           100用户并发下载   
8Ee"l-i/Fc}"G:}0Perf.T.6 高峰不同模板下载量           150用户并发下载 

1AYC"I~qPn^0容量：
[+~Yet�I0编号      项             容量    51Testing软件测试网)BR/x-vKU.M
Perf.C.1 用户数          <=100万   
| c7Z v4sp2@0Perf.C.2 活动用户数       10000    51Testing软件测试网Q4KA!n
x W;QO7[
Perf.C.3 模板中心总用户数  <=25万 

51Testing软件测试网wktv6D�}gli-`
根据如上性能需求及数据我们该如何设计性能测试用例及场景呢？（可以说给出的性能需求很垃圾，没有丝毫价值，但没办法还是点做啊）
|.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软件测试网,}bu%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#@9Jns
r0100      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软件测试网h
v6T�}y:z9^.b!g
80        50000      搜索页面 随机产生   30分钟   加入思考时间   
F9b izn0100       50000      搜索页面 随机产生   30分钟   加入思考时间    51Testing软件测试网V2FZ%t�Io {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$Z�o1L050        300k       上传页面 随机产生   30分钟   取消思考时间    51Testing软件测试网uC2~!ji8z[
50        500k       上传页面 随机产生   30分钟   取消思考时间   
GH2U
S.e G050        800k       上传页面 随机产生   30分钟   取消思考时间   
}HY@ Vd{)LG 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分钟     取消思考时间   
*dv
O Q&\x6@&aq0100      300k        上传页面 随机产生 30分钟     取消思考时间 

产品下载51Testing软件测试网x)k+TkUph]W
影响下载性能的主要因素有下载文件的大小和下载的请求数，所以我们就从这两个方面设计用例

@~ VP{|L5u'J6Ri0   a、虚拟用户数一定，下载不同大小的文件
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分钟 取消思考时间 

   b、下载文件大小一定，不同量的虚拟用户51Testing软件测试网2~)W T"hcHQ)w
 
2F^(i.OCn2Q3@m#m7t[6mx0虚拟用户数 下载文件大小 录制页面 并发用户数 执行时间 思考时间    51Testing软件测试网1i*`eq
LX�qu"`
20         300k      下载页面 随机产生  30分钟    取消思考时间   
v7~E3~5r
v?,~3l050         300k      下载页面 随机产生  30分钟    取消思考时间    51Testing软件测试网3T[0i"[9L3d2oP
K.U
80         300k      下载页面 随机产生  30分钟    取消思考时间    51Testing软件测试网@6?&G-J"Nm-T
100        300k      下载页面 随机产生  30分钟    取消思考时间