<一>Windows性能计数器分析
对象 计数器 分析
processor %processor time 建议阈值85%
memory Available bytes 建议阈值少于4MB需要添加内存；
另外，又建议至少要有10%的物理内存值
Pages reads/sec Page Reads/sec 是指为解析硬页错误而读取磁盘的次数，如果该值一直持续较大，表明可能内存不足
建议阈值30（5？），大数值表示磁盘读而不是缓存读
Pages writes/sec Page Writes/sec 是指为了释放物理内存空间而将页写入磁盘的次数
Pages Input/sec Pages Input/sec 指为解决页错误从磁盘上读取的页数
Pages Output/sec Pages Output/sec 是指为了释放物理内存空间而写入磁盘的页数
如果该值远远大于Pages Input/sec,可能有内存泄露
Pages/sec Pages/sec 是指为解析硬页错误从磁盘读取或写入磁盘的页数
建议阈值20
Network interface
（对于TCP/IP） Bytes received/sec 该数据结合Bytes total/sec看
Bytes sent/sec 该数据结合Bytes total/sec看
Bytes total/sec 推荐不要超过带宽的50%
Packets/sec 根据实际数据量大小，无建议阈值，该数据结合Bytes total/sec看
Physical disk Disk reads/sec 取决于硬盘制造商的规格，检查磁盘的指定传送速度，以验证此速度没有超出规格
Disk writes/sec 取决于硬盘制造商的规格，检查磁盘的指定传送速度，以验证此速度没有超出规格
又：上两值相加，应小于磁盘设备的最大容量
%Disk Time 建议阈值90%
Current disk queue length
Avg. disk queue length(如果使用RAID设备，%Disk Time计数器显示的值可以大于100%。如果大于100%，则使用Avg. disk queue length计数器决定正在等待磁盘访问的系统请求的平均数) 不超过磁盘数的1.5~2倍
如果上两值始终较高,可以考虑升级磁盘驱动器或将某些文件移动到其他磁盘或服务器

一些注意事项
1. 如果监视不超过4个小时，则每15秒更新一次比较合理；如果将监视系统8个小时或更长时间，则设置的间隔不要小于300秒
2. 个人认为测试报告结果同时还要附上图参考，因为单靠最小、最大和平均值还不能说明问题
3. 与物理磁盘计数器的数据不同，逻辑磁盘计数器的数据默认情况下不是由操作系统搜集。要获得逻辑驱动器或存储卷的性能计数器数据，必须在命令提示符下键入diskperf –yv。默认情况下，操作系统使用diskperf –yd命令包含物理驱动器数据。使用命令diskperf的详细信息，请在命令提示符下键入diskperf -？。
4. 通常，决定性能是否可以接受是一种主观判断，随用户环境的变化而明显地变化。
5. 内存不足是计算机系统中的严重性能问题最常见的原因。工作站响应速度很慢最有可能是内存和处理器问题造成的；服务器更容易受到磁盘和网络问题的影响。
6. 在程序启动时，每个程序的Process\%Processor Time值迅速攀升、降低，然后稳定。注意程序启动时处理器的峰值非常重要；你可能要暂时忽略监视数据中高的启动值，以获得典型程序使用处理器情况的更精确的图片。
7. 当内存减少时，操作系统开始通过从活动较少的程序的工作集(working set)中获得内存来补充，因此，将看到一个程序工作集的增大，而其他程序的值减少。如果系统中没有足够的内存来满足所有活动程序的要求，将发生内存页交换，程序性能将受到影响。
8. 如果发生了内存泄漏，Process\Private Bytes计数器和Process\Working set 计数器的值往往会升高，同时Available bytes会降低。
9. 如果Process不见了,修改注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PerfProc\Performance 下的Disable Performance Counters值为0.
<二>性能分析
1。内存分析方法

  内存分析用于判断系统有无内存瓶颈，是否需要通过增加内存等手段提高系统性能表现。

  内存分析需要使用的计数器：Memory类别和Physical Disk类别的计数器。内存分析的主要方法和步骤：

 （1）首先查看Memory\Available Mbytes指标

  如果该指标的数据比较小，系统可能出现了内存方面的问题，需要继续下面步骤进一步分析。

注：  在UNIX/LINUX中，对应指标是FREE(KB)

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

 操作系统回利用磁盘较好的方式提高系统可用内存量或者提高内存的使用效率。这三个指标直接反应了操作系统进行磁盘交换的频度。

  如果Pages/sec的技术持续高于几百，可能有内存问题。Pages/sec值不一定大九表明有内存问题，可能是运行使用内存映射文件的程序所致。Page Faults/sec说明每秒发生页面失效次数，页面失效次数越多，说明操作系统向内存读取的次数越多。此事需要查看Pages Read/sec的计数值，该计数器的阀值为5，如果计数值超过5(有点问题,路过者知道的可说下...)，则可以判断存在内存方面的问题。

  注：在UNIX/LINUX系统中，对于指标是(page)si和(page)so.

  (3)根据Physical Disk计数器的值分析性能瓶颈

  对Physical Disk计数器的分析包括对Page Reads/sec和%Disk Time及Aerage Disk Queue Length的分析。如果Pages Read/sec很低，同时%Disk Time和Average Disk Queue Length的值很高，则可能有磁盘瓶颈。但是，如果队列长度增加的同时Pages Read/sec并未降低，则是内存不足。

 注：在UNIX/LINUX系统中，对应的指标是Reads(Writes)per sec、Percent of time the disk is busy和Average number of transactions waiting for service.

  2.处理器分析法

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

   该计数器的值体现服务器整体处理器利用率，对多处理器的系统而言，该计数器提醒所有CPU的平均利用率。如果该值持续超过90％，则说明整个系统面临着处理器方面的瓶颈，需要通过增加处理器来提高性能。

  注：多处理器系统中，该数据本身不大，但PUT直接负载状况极不均衡，也应该视作系统产生处理器方面瓶颈。

（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时，说明产生了处理器阻塞。在处理器的%Process Time很高时，一般都随处理器阻塞，但产生处理器阻塞时，Processor\%Process Time 计数器的值并不一定很大，此时就必须查找处理器阻塞的原因。

 %DOC Time 是另一个需要关注的内容，该计数器越低越好。在多处理器系统中，如果这个值大于50％，并且Processor\%Precessor Time非常高，加入一个网卡可能回提高性能。

3。磁盘I/O分析方法

（1）计算梅磁盘的I/O数

  梅磁盘的I/O数可用来与磁盘的I/O能力进行对比，如果经过计算得到的每磁盘I/O数超过了磁盘标称的I/O能力，则说明确实存在磁盘的性能瓶颈。

  每磁盘I/O计算方法

 RAID0计算方法：（Reads +Writes)/Number of Disks

 RAID0计算方法：（Reads +2*Writes)/2

 RAID0计算方法：[Reads +(4*Writes)]/Number of Disks

 RAID0计算方法：[Reads +(2*Writes)]/Number of Disks

  (2)与Processor\Privileged Time 合并进行分析

  如果在Physical Disk 计数器中，只有％Disk Time 比较大，其他值都比较适中，硬盘可能会是瓶颈。若几个值都比较大，且数值持续超过80％，则可能是内存泄漏。

  （3）根据Disk sec/Transfer进行分析

    一般来说，定义该数值小于15ms为Excellent，介于15～30ms之间为良好，30～60ms之间为可以接受，超过60ms则需要考虑更换硬盘或是硬盘的RAID方式了。

 4。进程分析方法

（1）查看进程的％Processor Time值

  每个进程的％Processor Time反映进程所消耗的处理器时间。用不同进程所消耗的处理器时间进行对比，可以看出具体哪个进程在性能测试过程中消耗了最多的处理器时间，从而可以据此针对应用进行优化。

（2）查看每个进程产生的页面失效

   可以用每个进程产生的页面失效（通过PRCESS\PAGE FAILURES/SEC计数器获得）和系统页面失效(可以通过MEMORY\PAGE FAILURES/SEC计数器获得)的比值，来判断哪个进程产生了最多的页面失效，这个进程要么是需要大量内存的进程，要么是非常活跃的进程，可以对其进行重点分析。

  （3）了解进程的Process/Private Bytes

    Process/Private Bytes是指进程所分配的无法与其他进程共享的当前字节数量。该计数器主要用来判断进程在性能测试过程中有无内存泄漏。例如：对于一个IIS之上的WEB应用，我们可以重点监控inetinfo进程的Private Bytes，如果在性能测试过程中，该进程的Private Bytes计数器值不断增加，或是性能测试停止后一段时间，该进程的Private Bytes仍然持续在高水平，则说明应用存在内存泄漏。

  注：在UNIX/LINUX系统中，对应的指标是Resident Size

  5。网络分析方法

  Network Interface\Bytes Total/sec为发送和接收字节的速率，可以通过该计数器值来判断网络链接速度是否是瓶颈，具体操作方法是用该计数器的值和目前网络的带宽进行比较。

 RAID0计算方法：[Reads +(2*Writes)]/Number of Disks

  (2)与Processor\Privileged Time 合并进行分析

  如果在Physical Disk 计数器中，只有％Disk Time 比较大，其他值都比较适中，硬盘可能会是瓶颈。若几个值都比较大，且数值持续超过80％，则可能是内存泄漏。

  （3）根据Disk sec/Transfer进行分析

    一般来说，定义该数值小于15ms为Excellent，介于15～30ms之间为良好，30～60ms之间为可以接受，超过60ms则需要考虑更换硬盘或是硬盘的RAID方式了。

Transactions（用户事务分析）
　　用户事务分析是站在用户角度进行的基础性能分析。
1、Transation Sunmmary（事务综述）
　　对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。
2、Average Transaciton Response Time（事务平均响应时间）
　　“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。
　　例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
3、Transactions per Second（每秒通过事务数/TPS）
　　“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。
　　将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。
　　例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。
4、Total Transactions per Second（每秒通过事务总数）
　　“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。
5、Transaction Performance Sunmmary（事务性能摘要）
　　“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。
　　重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。
6、Transaction Response Time Under Load（事务响应时间与负载）
　　“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在　　用户并发方面的性能数据，为扩展用户系统提供参考。此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。
7、Transaction Response Time(Percentile)（事务响应时间(百分比)）
　　“事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。
8、Transaction Response Time(Distribution)（事务响应时间(分布)）
　　“事务响应时间(分布)”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。如果系统预先定义了相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。
　　Web Resources（Web资源分析）
　　Web资源分析是从服务器入手对Web服务器的性能分析。
1、Hits per Second（每秒点击次数）
　　“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。
　　通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
2、Throughput（吞吐率）
　　“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。
　　可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
　　“吞吐率”图和“点击率”图的区别：
　　“吞吐率”图，是每秒服务器处理的HTTP申请数。
　　“点击率”图，是客户端每秒从服务器获得的总数据量。
3、HTTP Status Code Summary（HTTP状态代码概要）
　　“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数，该图按照代码分组。HTTP状态代码表示HTTP请求的状态。
4、HTTP Responses per Second（每秒HTTP响应数）
　　“每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其它各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。
5、Pages Downloader per Second（每秒下载页面数）
　　“每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。使用此图可依据下载的页数来计算Vuser生成的负载量。
　　和吞吐量图一样，每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。但是吞吐量考虑的各个资源极其大小（例，每个GIF文件的大小、每个网页的大小）。而每秒下载页面数只考虑页面数。
　　注：要查看每秒下载页数图，必须在R-T-S那里设置“每秒页面数(仅HTML模式)”。
6、Retries per Second（每秒重试次数）
　　“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。
　　在下列情况将重试服务器连接：
　　A、初始连接未经授权
　　B、要求代理服务器身份验证
　　C、服务器关闭了初始连接
　　D、初始连接无法连接到服务器
　　E、服务器最初无法解析负载生成器的IP地址
7、Retries Summary（重试次数概要）
　　“重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数，它按照重试原因分组。将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务器在哪个时间点进行了重试。
8、Connections（连接数）
　　“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。
　　借助此图，可以知道何时需要添加其他连接。
　　例：当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）。
9、Connections Per Second（每秒连接数）
　　“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。
　　理想情况下，很多HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。通过每秒连接数图可以看出服务器的处理情况，就表明服务器的性能在逐渐下降。
10、SSLs Per Second（每秒SSL连接数）
　　“每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL连接数。当对安全服务器打开TCP/IP连接后，浏览器将打开SSL连接。
　　Web Page Breakdown（网页元素细分）
　　“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的
元素。
1、Web Page Breakdown（页面分解总图）
　　“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。
　　“页面分解”图可以按下面四种方式进行进一步细分：
1)、Download Time Breaddown（下载时间细分）
　　“下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。
2)、Component Breakdown(Over Time)（组件细分(随时间变化)）
　　“组件细分”图显示选定网页的页面组件随时间变化的细分图。通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。

1. 如何写性能测试用例

由于性能测试与功能测试有很大的区别，所以讨论出的结果可能与预先的设想有一定的区别

。
性能测试的目的：
为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系

统的目的。

性能测试指标的来源：
用户对各项指标提出的明确需求；如果用户没有提出性能指标则根据用户需求、测试设计人

员的经验来设计各项测试指标。（需求+经验）

主要的性能指标：
服务器的各项指标（CPU、内存占用率等）、后台数据库的各项指标、网络流量、响应时间

。

BUG观点：
1、性能测试就象人在无风情况下跑步（正常情况下的性能指标）；
2、压力测试就象人在微风中跑步（在正常的基础上加大多少百分比压力的性能指标）；
3、负载测试就象人在强风中跑步（不断加压，直到系统崩溃）。

HTTP观点：
1、 负载测试是正常情况下持续的加压；
2、 压力测试是直接加压达到一个极限值。

大家统一的观点：
性能测试、压力测试、负载测试密不可分，可统称为性能测试。

性能测试要点：
1、 性能测试是在功能测试完成之后进行。
2、 性能测试计划、方案一般与测试用例统一在一个文档里。
3、 测试环境应尽量与用户环境保持一致。
4、 性能测试一般使用测试工具和测试人员编制测试脚本来完成，性能测试的环境应单独运

行尽量避免与其他软件同时使用。
5、 性能测试的重点在于前期数据的设计与后期数据的分析。
6、 性能测试的用例主要涉及到整个系统架构的问题，所以测试用例一旦生成，改动一般不

大，所以做性能测试的重复使用率一般比较高。（说明：当系统中出现的某个功能点需要修

改，它一般只会影响到功能测试的设计用例，而对于性能测试，很少影响到性能测试的设计

用例。但是如果某个功能有较大的修改，性能测试也应该进行重新测试。）

 

2. Loadrunner性能测试一个实例 （经典）

　　随着测试越来越重要，其中的性能测试也受到越来越多的关注。比较普遍的性能测试工

具是Loadrunner7.51，但是很多人对此性能工具不是很熟悉。本人也是总结心得体会，将做

过的性能测试实例以饷大家，希望对各位做测试的朋友有所帮助。
该方案是针对某公司试题库的性能测试。该试题库是用来对公司内部员工培训结果的一个考

核。试题库在公司内部web服务器上，假设开设50个账号和密码可供50个考生同时参加考试

。要求，每台机器只能由一个用户使用，每个用户只能使用各自不同的账号登录考试系统，

做完题目后，要求提交考试结果，若在制定的时间内不提交，则系统强制提交考试结果。
但是，一般测试部门不可能有50台机器同时进行测试的。所以，可以借Loadrunner7.51模拟

IP地址，修改脚本来协助测试。但是，为了保证测试结果，建议搜罗公司中所有可用的机器

进行复测，因为有时候是不可以完全信赖工具的。
现场测试环境
硬件：50台PC机，Web服务器
软件：Loadrunner7.0，Win2000，IE5.0和IE6.0
人员：质控部2人，执行现场测试
项目部22人，提供现场环境
技术部各1人，提供技术支持
测试要求
50个用户拥有独立IP地址，不同的用户及密码登录，试题完成后各自同时提交。
测试内容
50个用户以不同的用户名和密码登录试题库。试题完成后，提交考试结果。测试考试结果是

否能正常提交以及正确评分。
测试方案
1、 完全20台实际的PC机进行现场测试。
（1） 准备工作，并做计划。第一轮测试执行三遍，设定用户考试内容全部同时提交，第一

遍全部使用IE5.0，第二遍10台使用IE5.0，10台使用IE6.0，第三遍全部使用IE6.0
（2） At 9：00 ，20个用户同时登录系统
（3） At 9：05 ，20个用户同时全部提交
（4） 分别记录第一轮测试（三遍）的结果
（5） 第二轮测试准备工作，设定15个用户考试内容同时提交，另外5个用户延时5分钟提交

，全部使用IE5.0
（6） At 9：15 ，20个用户同时登录系统
（7） At 9：20 ，15个用户同时提交
（8） At 9：25 ，剩余5个用户同时提交
（9） 记录第二轮测试结果
（10） 第三轮测试准备工作，设定15个用户考试内容同时提交，另外5个用户延时5分钟提

交，全部使用IE6.0
（11） At 9：15 ，20个用户同时登录系统
（12） At 9：20 ，15个用户同时提交
（13） At 9：25 ，剩余5个用户同时提交
（14） 记录第三轮测试结果
（15） 第四轮测试准备工作，设定15个用户考试内容同时提交，另外5个用户延时5分钟提

交，正常提交用户使用IE5.0，延时提交用户使用IE6.0
（16） At 9：15 ，20个用户同时登录系统
（17） At 9：20 ，15个用户同时提交
（18） At 9：25 ，剩余5个用户同时提交
（19） 记录第四轮测试结果
（20） 第五轮测试准备工作，设定15个用户考试内容同时提交，另外5个用户延时5分钟提

交，正常提交用户使用IE6.0，延时提交用户使用IE5.0
（21） At 9：15 ，20个用户同时登录系统
（22） At 9：20 ，15个用户同时提交
（23） At 9：25 ，剩余5个用户同时提交
（24） 记录第五轮测试结果
（25） 第六轮测试准备工作，设定15个用户考试内容同时提交，另外5个用户延时5分钟提

交，正常提交用户其中10个使用IE5.0，5个使用IE6.0，延时提交用户使用IE5.0
（26） At 9：15 ，20个用户同时登录系统
（27） At 9：20 ，15个用户同时提交
（28） At 9：25 ，剩余5个用户同时提交
（29） 记录第六轮测试结果
（30） 第七轮测试准备工作，设定10个用户考试内容同时提交，另外10个用户分两次分别

延时5分钟、15提交
（31） At 9：35 ，20个用户同时登录系统
（32） At 9：40 ，10个用户同时提交
（33） At 9：45 ，剩余的其中5个用户同时提交
（34） At 9：55 ，剩余的5个用户同时提交
（35） 记录第七轮测试结果，参见第二轮测试－第六轮测试过程分别对IE5.0和IE6.0的情

况进行测试
（36） 第八轮测试准备工作，设定其中10个用户不提交，由系统强行提交
（37） At 10：10 ，20个用户同时登录系统
（38） At 10：15 ，10个用户同时提交
（39） 其余用户的内容由系统强行提交
（40） 记录第八轮测试结果，参见第二轮测试－第六轮测试过程分别对IE5.0和IE6.0的情

况进行测试
（41） 第九轮测试准备工作，设定其中10个用户同时提交，5个用户延时5分钟提交，其余

用户由系统强行提交
（42） At 10：25 ，20个用户同时登录系统
（43） At 10：30 ，10个用户同时提交
（44） At 10：35 ，剩余的其中5个用户同时提交
（45） 剩余5个用户系统强制提交
（46） 记录第九轮测试结果，参见第二轮测试－第六轮测试过程分别对IE5.0和IE6.0的情

况进行测试
2、 模拟20个用户进行测试。其中，10台是PC机，另外10台机器的IP地址是Loadrunner模拟

出来的。
（1） 在10台实际的PC机中抽取其中一台虚拟10个IP地址，包括自身的IP地址，该机器上共

11个IP地址，这11个IP地址只能全部使用IE5.0或者全部使用IE6.0
（2） 其余9台实际的PC机分别由9个人操作，另外一台机器由一位质控部人员操作
（3） 对于异常情况，延时提交和强制提交全部由实际的机器来模拟
（4） 其余过程参见1
3、 模拟20个用户进行测试。其中，5台是PC机，另外15台机器的IP地址是用Loadrunner模

拟出来的。
（1） 在5台实际的PC机中抽取其中一台虚拟15个IP地址，包括自身的IP地址，该机器上共

16个IP地址，这16个IP地址只能全部使用IE5.0或者全部使用IE6.0
（2） 其余4台实际的PC机分别由4个人操作，另外一台机器由一位质控部人员操作
（3） 对于异常情况，延时提交和强制提交全部由实际的机器来模拟
（4） 其余过程参见1
4、 模拟35个用户进行测试。其中，20台是PC机，另外15台机器的IP地址是用Loadrunner模

拟出来的。
（1） 在20台实际的PC机中抽取其中两台分别虚拟7个、8个IP地址，这17个IP地址只能全部

使用IE5.0或者全部使用IE6.0
（2） 其余18台实际的PC机分别由18个人操作，另外两台机器由两位质控部人员操作
（3） 对于异常情况，延时提交和强制提交全部由实际的机器来模拟
（4） 其余过程参见1
5、 模拟50台用户进行测试。其中，20台是PC机，另外30台机器的IP地址是用分别用两台实

际的PC机模拟出来的。记录测试结果。
（1） 在20台实际的PC机中抽取其中两台分别虚拟15个IP地址，这32个IP地址只能全部使用

IE5.0或者全部使用IE6.0
（2） 其余18台实际的PC机分别由18个人操作，另外两台机器由两位质控部人员操作
（3） 对于异常情况，延时提交和强制提交全部由实际的机器来模拟
（4） 其余过程参见1
6、 对5中所述情况重复测试两次。
7、 为了保证结果的正确性，完全50台实际的PC机进行现场测试。过程参见1
测试过程
注：该测试过程针对虚拟IP地址情况。
1、 一台PC机上创建15个虚拟的IP地址。首先，启动IP Wizard，如下：开始程序－

>Loadrunner－>Tools－>IP Wizard
点击“Add”，添加你计划虚拟的IP地址。但是注意不能添加已经被占用的IP地址。
2、 启动Virtual User Generator，并录制脚本，由于50个用户的账号和密码各不相同，所

以，要修改脚本，设置参数。我是录制了一个脚本，复制了49份，在每个脚本中手工修改了

各自不同的地方。
3、 启动Loadrunner Controller，先将刚才保存的脚本添加进来。然后点击“Scenario”

菜单，激活其中的“Enable IP Spoofer”。
4、 点击屏幕右方的“Generators”，添加已经建立的IP，然后connect建立连接。
5、对连接起来的不同用户（IP地址）分配不同的脚本，在Controller中的“design”中，

点击“Load Generators”其中，每个脚本有一个用户执行。
6、 执行Scenario

1.什么是负载测试？什么是性能测试？

 

2.性能测试包含了哪些测试（至少举出3种）

 

3.简述性能测试的步骤

 

4.简述使用Loadrunner的步骤

 

5.什么时候可以开始执行性能测试？

 

6.LoadRunner由哪些部件组成？

 

7.你使用LoadRunner的哪个部件来录制脚本？

 

8.LoadRunner的哪个部件可以模拟多用户并发下回放脚本？

 

9.什么是集合点？设置集合点有什么意义?Loadrunner中设置集合点的函数是哪个?

 

10.什么是场景？场景的重要性有哪些?如何设置场景?

 

11.请解释一下如何录制web脚本？

 

12.为什么要创建参数?如何创建参数?

 

13.什么是关联？请解释一下自动关联和手动关联的不同。

 

14.你如何找出哪里需要关联？请给一些你所在项目的实例。

 

15.你在哪里设置自动关联选项？

 

16.哪个函数是用来截取虚拟用户脚本中的动态值？（手工管联）

 

17.你在VUGen中何时选择关闭日志？何时选择标准和扩展日志？

 

18.你如何调试LoadRunner脚本？

 

19你在LR中如何编写自定义函数？请给出一些你在以前进行的项目中编写的函数。

 

20.在运行设置下你能更改那些设置？

 

21.你在不同的环境下如何设置迭代？

 

22.你如何在负载测试模式下执行功能测试？

 

23.什么是逐步递增？你如何来设置？

 

24.以线程方式运行的虚拟用户有哪些优点？

 

25.当你需要在出错时停止执行脚本，你怎么做？

 

26.响应时间和吞吐量之间的关系是什么？

 

27.说明一下如何在LR中配置系统计数器？

 

28.你如何识别性能瓶颈？

 

29.如果web服务器、数据库以及网络都正常，问题会出在哪里？

 

30.如何发现web服务器的相关问题？

 

31.如何发现数据库的相关问题？

 

32.解释所有web录制配置？

 

33.解释一下覆盖图和关联图的区别？

 

34.你如何设计负载？标准是什么？

 

35.Vuser_init中包括什么内容？

 

36. Vuser_end中包括什么内容？

 

37.什么是think time？think_time有什么用？

 

38.标准日志和扩展日志的区别是什么？

 

39.解释以下函数及他们的不同之处。

Lr_debug_message

Lr_output_message

Lr_error_message

Lrd_stmt

Lrd_fetch

 

40.什么是吞吐量？

 

41.场景设置有哪几种方法？