使用LR8.1中文版，遇到如下问题：

LR8.1中文版监测UNIX资源出现以下错误提示

1 测算系统的性能指标
 1.1 综述
  测算系统的性能指标是其它性能测试的基础，因为无论任何测试目的，都必须通过某些性能指标来说明问题。
 1.2 测试方法
  测算系统的性能指标在做法上比较简单，关键是找到相应的计算公式，并根据这些公式确定所需要的原始数据，然后在测试实施中获得这些原始数据。
 1.3 术语
  测试时间：一轮测试从开始到结束所使用的时间
  并发线程数：测试时同时访问被测系统的线程数。注意，由于测试过程中，每个线程都是以尽可能快的速度发请求，与实际用户的使用有极大差别，所以，此数据不等同于实际使用时的并发用户数。
  每次时间间隔：测试线程发出一个请求，并得到被测系统的响应后，间隔多少时间发出下一次请求。
  平均响应时间：测试线程向被测系统发请求，所有请求的响应时间的平均值。
  处理能力：在某一特定环境下，系统处理请求的速度。
  cache影响系数：测试数据未必如实际使用时分散，cache在测试过程中会比实际使用时发挥更大作用，从而使测试出的最高处理能力偏高，考虑到这个因素而引入的系数。
  用户习惯操作频率：根据用户使用习惯估算出来的，单个用户在一段时间内，使用此类功能的次数。通常以一天内某段固定的高峰使用时间来统计，如果一天内没有哪段时间是固定的高峰使用时间，则以一天的工作时间来统计。
  预期平均响应时间：用户实际使用时，系统将在多长时间内响应。注意，这个值并不是某一次访问的时间，而是一段时间多次访问后的平均值。
  最大并发用户数：在给定的预期平均响应时间下，系统最多能支持多少个并发用户。这个数据就是实际可以同时使用系统的用户数。
 1.4 计算公式
  成功率＝成功次数÷（成功次数＋失败次数）
  处理能力＝成功次数÷测试时间
  最短平均响应时间＝MIN（平均响应时间）
  最高处理能力＝MAX（处理能力）×（1－cache影响系数）
  最大并发用户数＝（最高处理能力－1÷（预期平均响应时间－最短平均响应时间＋（1÷最高处理能力）））÷用户习惯操作频率，此公式要注意各时间单位的不同和转换
 1.5 测试过程
  1 设计方案
   见范例《范例1（web系统性能测试报告）.doc》。关键点是术语、计算公式、需收集的原始数据三部分
  2 测试实施
   根据成功、失败次数确定本组数据是否有效（成功率大于95%，成功次数大于20）
   根据成功、失败次数确定是否需要调整一组数据的测试时长
   根据数据的发散情况确定本组数据是否有效
   根据前后数据的对比确定本组数据是否有效（10%以内）
   根据前后数据的对比确定是否需要在同样情况下再次测试
   根据CPU占用率确定下一步的负荷
   ……
  3 数据分析
   基本上不需要分析，因为根据计算公式和测试实施中得到的原始数据，就可以直接得出所需要的性能指标
  4 测试报告
   见范例《范例1（web系统性能测试报告）.doc》。一般情况下，测试报告与测试方案基本一样，只是把测试出的原始数据和计算出的性能指标添加进去
 1.6 注意事项
  预期平均响应时间与最大并发用户数之间存在公式计算的关系，只有预先确定了其中之一，才能计算出另外一个
  除非在测试脚本中使用随机函数来模拟用户的访问，否则，测试脚本对被测系统的访问将存在一定的规律，从而导致平均响应时间与用户使用时出现较大差异。因此，一般都不可以把测试出的平均响应时间作为用户使用时的预期平均响应时间来对待

2 检验硬件配置能否满足客户要求
 2.1 综述
  客户在购买机器的前后，往往需要确定该机器是否满足其性能要求，这就需要进行这种目的的性能测试。由于提供给客户的配置方案基本上都是经过验证，或者根据以往经验能确定是没有问题的，所以要做的更多只是重复测算系统的性能指标，并形成一份测试报告交给客户。
 2.2 测试方法
  与测算系统的性能指标一样
 2.3 测试过程
  1 设计方案
   与测算系统的性能指标一样
  2 测试实施
   与测算系统的性能指标一样
  3 数据分析
   与测算系统的性能指标一样
  4 测试报告
   见范例《范例2（检验硬件配置能否满足客户要求）.doc》。报告的重点是说明系统在怎样的配置下能满足客户的要求，且给出数据来证明。由于测试报告是要交给客户看的，所以，测试报告的内容只需说明系统能满足客户要求即可，不需要写其它更多的东西。
 2.4 注意事项
  这里的整个过程和做法都类似于测算系统的性能指标，不同的只是最后形成的报告。

3 查找系统的性能瓶颈
 3.1 综述
  通常来说，在测算系统的性能指标之后，发现某些指标不满足要求，于是就要进一步去查找系统的哪部分是性能瓶颈，作为之后进行系统调优的基础。
  查找系统的性能瓶颈，一定是首先发现了系统存在性能问题，如果不能确定系统是否存在性能问题，那就应该只是测算系统的性能指标。
 3.2 测试方法
  由于已经确定了系统存在性能问题，所以，只需重复相同的软硬件配置，重复测试不能满足要求的性能指标，并在此过程中记录系统各部分的CPU占用率、物理内存、虚拟内存、磁盘IO等信息，有条件的还可以使用测试工具去统计各函数和方法的执行时间，综合分析出性能瓶颈的位置。
 3.3 测试过程
  1 设计方案
   见范例《范例3（查找系统的性能瓶颈）.doc》。
  2 测试实施
   与测算系统的性能指标的测试实施一样
  3 数据分析
   CPU占用率远大于其它部分的就是瓶颈，占用物理内存、虚拟内存远大于其它部分的可能是瓶颈，磁盘IO远多于其它部分的可能是瓶颈
   执行时间（不包含调用函数的时间）远多于其它部分的就是瓶颈
  4 测试报告
   见范例《范例3（查找系统的性能瓶颈）.doc》。报告的重点是判断性能瓶颈的依据和说明。
 3.4 注意事项
  如果没有发现明显的性能瓶颈，而系统的响应又经常超时，有可能是系统的并发处理机制出现问题，例如死锁

4 系统调优
 4.1 综述
  查找出系统的性能瓶颈后，下一步的工作就是系统调优（性能调优）。由于系统的性能是由软件和硬件两方面共同决定的，所以，系统调优分为软件调优和硬件调优。
  软件调优通常由开发人员完成，一般包括程序调优和数据库调优两方面。程序调优就是修改性能瓶颈部分的程序，提高其运行效率。数据库调优通常是增加或减少索引、增加cache等等，对数据库的各种参数进行调整。
  硬件调优通常由测试人员完成，一般是调整系统各部分的分布、增加机器、增加物理内存、调整虚拟内存、更换硬盘等等。
 4.2 测试方法
  系统调优是查找系统的性能瓶颈的延续，所以，前半部分的工作就是查找系统的性能瓶颈。之后，针对发现的瓶颈，与开发人员交流协商调优的方法，调整后再重复前面的工作。
 4.3 测试过程
  1 设计方案
   见范例《范例4（系统调优）.doc》。
  2 测试实施与数据分析
   查找出系统的性能瓶颈
   与开发人员交流协商系统调优的方法
   调整系统后再次测试
  3 测试报告
   见范例《范例4（系统调优）.doc》。报告的重点是系统的调整方法，以及在各种状态下的性能。
 4.4 系统调优结束的判定
  系统通过一定的调整，能达到各方都满意的性能
  项目经理以及高层确定系统不需要达到如此高的性能，从而修改需求
 4.5 注意事项
  需要经过各方的认同，系统调优才能结束

5 给出较适合的软硬件配置方案
 5.1 综述
  系统的性能与软硬件配置相关，不同的配置之下，系统将表现出不同的性能。性能要求较高的客户，需要较高的配置方案；性能要求较低的客户，需要较低的配置方案。什么样的配置能达到什么样的性能，从而能满足什么样的客户，这信息对于售前人员非常重要。
  通常，做这种目的的性能测试基本上能确定软件方面的系统调优不需要再进行，接下来做的只是，确定系统在不同档次的硬件上面所表现出的性能差异。
 5.2 测试方法
  首先需要确定判断是否“较适合”的标准，通常就是确定某些性能指标及其相应的数值范围，当这些性能指标在该范围之内时，就是“较适合”。通常都是取系统的处理能力作为标准。
  然后，选择不同的软硬件配置，在这些配置下测算那些性能指标。
  最后把各个结果汇总，确定几种较适合的方案。
 5.3 测试过程
  1 设计方案
   见范例《范例5（给出较适合的软硬件配置方案）.doc》。
  2 测试实施与数据分析
   把硬件进行不同的搭配，测算系统的性能指标
   筛选出一系列满足“较适合”标准的配置方案
  3 测试报告
   见范例《范例5（给出较适合的软硬件配置方案）.doc》。测试报告需要把测试过的软硬件配置及其相应的性能指标列出来，并列出推荐使用的若干种配置方案
 5.4 注意事项
  对于每种配置方案，都需要经过实际测试才能说那是较适合的配置方案，不可以通过类似的配置来推测

按进程运行VUSER难道没有意义？

 

在被监视windows机器上安装，Remote Service，仅安装这一个组件就行。到程序里启动，然后在控制台Coller中增加就成了...

要不windows加个服务端口也行

 

 

性能测试（并发负载压力）测试分析－简要篇
在论坛混了多日，发现越来越多的性能测试工程师基本上都能够掌握利用测试工具来作负载压力测试，但多数人对怎样去分析工具收集到的测试结果感到无从下手，下面我就把个人工作中的体会和收集到的有关资料整理出来，希望能对大家分析测试结果有所帮助。

分析原则：
    • 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）
    • 查找瓶颈时按以下顺序，由易到难。
    服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
    注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。
    • 分段排除法 很有效

分析的信息来源：
    •1 根据场景运行过程中的错误提示信息
    •2 根据测试结果收集到的监控指标数据

一．错误提示分析
分析实例：
1 •Error: Failed to connect to server "10.10.10.30:8080": [10060] Connection
  •Error: timed out Error: Server "10.10.10.30" has shut down the connection prematurely

  分析：
•A、应用服务死掉。
   （小用户时：程序上的问题。程序上处理数据库的问题）
•B、应用服务没有死
   （应用服务参数设置问题）
    例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％
•C、数据库的连接
   (1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)

2  Error: Page download timeout (120 seconds) has expired

分析：可能是以下原因造成
•A、应用服务参数设置太大导致服务器的瓶颈
•B、页面中图片太多
•C、在程序处理表的时候检查字段太大多

二．监控指标数据分析
1．最大并发用户数：
应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

2．业务操作响应时间：
• 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
• 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
• 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题
3．服务器资源监控指标：
内存：
    1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

    2 Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。

内存资源成为系统性能的瓶颈的征兆:
    很高的换页率(high pageout rate);
    进程进入不活动状态;
    交换区所有磁盘的活动次数可高;
    可高的全局系统CPU利用率;
    内存不够出错(out of memory errors)

处理器：
    1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85%
    合理使用的范围在60%至70%。
    2 Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。

CPU资源成为系统性能的瓶颈的征兆:   
     很慢的响应时间(slow response time)
     CPU空闲时间为零(zero percent idle CPU)
     过高的用户占用CPU时间(high percent user CPU)
     过高的系统占用CPU时间(high percent system CPU)
    长时间的有很长的运行进程队列(large run queue size sustained over time)

磁盘I/O：
    1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。
    2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

I/O资源成为系统性能的瓶颈的征兆 :
     过高的磁盘利用率(high disk utilization)
    太长的磁盘等待队列(large disk queue length)
    等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)
    太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
    过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
    太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)

4．数据库服务器：
SQL Server数据库：
    1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。
    2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。
    3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。
   4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

Oracle数据库：
  1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。
    快存（共享SQL区）和数据字典快存的命中率：
   select(sum(pins-reloads))/sum(pins) from v$librarycache;
    select(sum(gets-getmisses))/sum(gets) from v$rowcache;
    自由内存：    select * from v$sgastat where name=’free memory’;
2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。
  缓冲区高速缓存命中率：
    select name,value from v$sysstat where name in ('db block gets’,
    'consistent gets','physical reads') ;
   
    Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))
3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。
    日志缓冲区的申请情况 ：
     select name,value from v$sysstat where name = 'redo log space requests' ;
4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。
   内存排序命中率 ：
     select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name='sorts (disk)' and b.name='sorts (memory)'
   
    注：上述SQL Server和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。

说明：
    以上只是个人的体会和部分资料的整理，并不代表专家之言。算抛砖引玉，有不同看法和更深入的分析的，希望大家勇要发言，以推动我们国内的性能测试工作。

今天来说说ＬＲ里的组和用户的问题。
　　前几天看到一个帖子问：一个组里１０个用户和１０个组每个组一个用户有什么区别？
　　我们先看一下ＬＲ的官方帮助：
 
Multithreading
Vusers support multithread environments. The primary advantage of a multithread environment is the ability to run more Vusers per load generator. Only threadsafe protocols should be run as threads. (not applicable to Mercury Business Availability Center)
Note: The following protocols are not threadsafe: Sybase-Ctlib, Sybase-Dblib, Informix, Tuxedo, and PeopleSoft-Tuxedo.
o      To enable multithreading, click Run Vuser as a thread.
o      To disable multithreading and run each Vuser as a separate process, click Run Vuser as a process.
The Controller and Tuning Console use a driver program (such as mdrv.exe or r3vuser.exe) to run your Vusers. If you run each Vuser as a process, then the same driver program is launched (and loaded) into the memory again and again for every instance of the Vuser. Loading the same driver program into memory uses up large amounts of RAM (random access memory) and other system resources. This limits the numbers of Vusers that can be run on any load generator.
Alternatively, if you run each Vuser as a thread, the Controller or Tuning Console launches only one instance of the driver program (such as mdrv.exe), for every 50 Vusers (by default). This driver process/program launches several Vusers, each Vuser running as a thread. These threaded Vusers share segments of the memory of the parent driver process. This eliminates the need for multiple re-loading of the driver program/process saves much memory space, thereby enabling more Vusers to be run on a single load generator.
 
 
　　从上面的描述可以看到，
　　如果是线程安全的协议，在一个组（进程）里并发多个vusers，可以不用开那么进程。这可以减少系统的开销。
　　如果不是线程安全的协议，我们需要开多个进程来处理Ｖusers。这样势必增加系统的开销。
　　其实对现在的硬件来说，基本上客户端成为瓶颈的机会不是很大。（除非这公司太穷了）
^_^
 
 
　　这里我做了个实验，画了一张表，来形象的说明一下组/vusers/线程／进程的关系。
注：这里，我假定的是１０vsuers：

设置vusers按进程还是线程运行	Vusers(个／组)	组（个）	mmdrv.exe中的线程数（个／组）	Mmdrv.exe进程（个）	平均每个进程占的内存（k）	Mmdrv.exe占有内存总数（k）
线程	１０	１	１２	１	７，５００	７，５００
线程	１	１０	３	１０	５，１５０	５１，５００
进程	１０	１	１	１０	４，６７６	４６，７６０
进程	１	１０	１	１０	５，１５０	５１，５００

　　我这里脚本都是一样的。
　　大家如果自己做实验，内存可能会不一样。
　　在表里，我们可以很清楚的看到，进程多的时候，占用内存肯定是多的。
　　如果在同一组里开多个线程，占用内存就少得多。
　　我们还要注意一个细节就是在用线程来运行vusers的时候，每个进程中会多出几个线程来。
　　这多出来的很个进程在做什么，我没有查它的ＡＰＩ，我想可能是维护进程之间的运行。
 
　　很显然的，还有个问题，就是哪个压力更大。
　　这个问题也有些人在问，我想这个应该是很明显的吧。
　　其实对服务器来说，只要是１０个用户都在正常工作，而速度不会受到本地硬件的影响。
　　对服务器的压力是一样的。
　　这么来思考：
　　假设来说。
　　我们是从客户端来发数据库的，１０个用户，如果一秒钟发２０个数据包。
　　那对服务器来说，收到的数据包都是一样多的。所以压力也会是一样的。
　　那会不会存在在同一个进程里开１０个线程速度更慢呢。
　　这个，我以为不会的。
 
　　所以我认为压力是一样的。
 

我觉得Vuser用户在客户端无论进程还是线程来并发，只能影响到客户端，至于服务器段呢？接受到的并发用户数都一样，所以给服务器承受的压力都是一样的。

一般情况下，我会把应用服务器和数据库服务器搭建在同一机器上。

    几天前的测试环境搭建也不例外。

   
    快下班的时候，老板说要做一下性能测试。

  
   
    当时我只注意的环境是：

    服务器：tomcat-6.0.13

    数据库：mysql5.0

    操作系统：CentOS 4

   所知道的要素：

      1：tomcat的优化：将maxThreads设置成100

    然后将数据库的maxActive分别设置：15，20，25 。

      2：需要测试的有三个地方：首页、电影分类、单个电影

      3：测试持续时间为5分钟，虚拟用户为100个

   期望结果：
    
      根据不同的数据库maxActive值，在条件3相同的情况下，对比哪种的测试结果的性能比较好。

 
   这个相对来说比较简单，在很快的时间我就录制好了三个需要测试的脚本， 在运行脚本的时候，

   遇到的问题：LoadRunner的关联

   解决方法：http://www.51testing.com/?58025/action_viewspace_itemid_44330.html

   得到的结果是：

    在数据库maxActive值为20时，首页、电影分类、单个电影等测试结果的性能最好。

   判断的要素：

   吞吐量、点击量、平均响应时间

   分析的方法：

     在测试持续时间和虚拟用户都相同的情况下，比较不同maxActive值时，所得到的吞吐量、点击量、平均响应时间，

   如果吞吐量和点击量都比其他两种情况下要大，而且平均响应时间比其他两种情况下要低，则其性能比较好！

  做到这里，我已经很明确在哪种配置下得到的性能比较好，下一步要做的是，就是弄清楚到底是什么影响了性能？

  是应用服务器，还是数据库服务器，还是操作系统呢？

  接下来我想先对应用服务器进行优化，

   具体情况请查看：http://www.51testing.com/?58025/action_viewspace_itemid_61154.html

 然后在：

   所知道的要素：

    1：tomcat的优化：将maxThreads设置成100
       数据库的maxActive设置：20

    2：需要测试的有三个地方：首页、电影分类、单个电影

    3：测试持续时间为5分钟，虚拟用户为100个

   期望结果：
    
      对比在没有安装apr之前的测试结果和已安装了apr之后，对比哪种的测试结果的性能比较好。

  得到的结果：
   
      在安装apr之前和安装apr之后，没有明显的变化，所以排除应用服务器的问题。（虽然比较粗，但目前水平有限也只能做到这样了）

 接下来就要找出是数据库服务器，还是操作系统的性能有问题了。

   第一步：将应用服务器和数据库服务器分开

    我把数据库服务器从CentOS 4 移到了WINDOWS XP 下。

   第二步：分别监控两台机器
   
    遇到的问题：如何监控呢？
   
    解决方法：http://www.51testing.com/?58025/action_viewspace_itemid_44676.html
              http://www.51testing.com/?58025/action_viewspace_itemid_44562.html

   第三部：确定在运行脚本，需要监控哪些计数器

   1: 监控两台机器的CPU使用情况
   2：吞吐量、点击量、平均响应时间和成功率

  期望结果：
     对比应用服务器和数据库服务器没有分开之前的测试结果和分开之后的测试结果哪种性能比较好。

  得到的结果：
    1：CentOS 4 这台机器的CPU使用率在两次运行中一直居高不下。
    2：首页在应用服务器和数据服务器分开之后，吞吐量和点击量高了很多，并且平均响应时间也少了很多
    3：单个电影的吞吐量和点击量都比以前有所提高，但平均响应时间却没有降低。
    4：电影分类的吞吐率，点击率和平均响应时间都没有什么变化。

  分析结果：
    1： 根据两次性能测试结果：CentOS 4 这台机器的处理器存在着瓶颈，需要增加处理器来提高性能

    2： 首页没有使用到数据库的查询，而电影分类中使用到数据库查询比较多，所以初步分析数据库的性能存在着问题，需要做进一步的优化。
        由于MYSQL5.1版本中支持了分区，建议开发人员使用分区技术。
   

 参考指标：  
 度量 指标    问题
 cpu 95%以上  瓶颈
 80－85％ 最大上限
 70％以下 正常

    本次测试中欠缺的是：对数据库服务器的监控。

    期望提高的是：对操作系统的监控，进一步分析出问题所在，
                 对数据库服务器的监控，给出明确点优化意见

   写在这里，不知道我这样做性能测试的方法对不对，还希望看过此文章的朋友给出意见和建议。

同一场景
1.小用户量的情况下测试
2.大用户量情况下的测试

分析的方法：
整个系统架构分析，系统响应时间消耗，利用图表分析
查看事务响应时间，通过事务摘要图分析事务响应时间，那个消耗最大（通过小用户量和大用户量的响应时间分析，查看那个事务响应时间最高），确定哪部分功能是性能的瓶颈，分析window resource图表，查看cpu

使用下列计数器标识cpu瓶颈
Processor\ Interrupts/sec
Processor\ % Processor Time
Process(process)\ % Processor Time
System\ Processor Queue Length

通过它来确定是否硬件本身出现瓶颈，或者进一步确定应该怎么去判断性能产生瓶颈的地方！
下一步去判断进程，那个进程消耗cpu最高
下边就有很多种情况需要你自己去判断，有可能是进程调用了的函数消耗了系统资源形成上边的问题，也有可能是后台数据库出现的问题（这个就要看你的系统配置是什么样的，比如你的db服务器和应用服务器都配置在一台机器上）

性能产生瓶颈有很多地方，所以需要进一判断，是否是后台数据库的问题还有待分析，是那条语句导致的问题需要进一步分析判断。

分析原则：
    • 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）
    • 查找瓶颈时按以下顺序，由易到难。
    服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
    注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。
    • 分段排除法 很有效

分析的信息来源：
    •1 根据场景运行过程中的错误提示信息
    •2 根据测试结果收集到的监控指标数据

一．错误提示分析
分析实例：
1 •Error: Failed to connect to server "10.10.10.30:8080": [10060] Connection
  •Error: timed out Error: Server "10.10.10.30" has shut down the connection prematurely

  分析：
•A、应用服务死掉。
  （小用户时：程序上的问题。程序上处理数据库的问题）
•B、应用服务没有死
  （应用服务参数设置问题）
    例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％
•C、数据库的连接
  (1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)

2  Error: Page download timeout (120 seconds) has expired

分析：可能是以下原因造成
•A、应用服务参数设置太大导致服务器的瓶颈
•B、页面中图片太多
•C、在程序处理表的时候检查字段太大多

二．监控指标数据分析
1．最大并发用户数：
应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

2．业务操作响应时间：
• 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
• 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
• 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题
3．服务器资源监控指标：
内存：
    1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

    2 Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。

内存资源成为系统性能的瓶颈的征兆:
    很高的换页率(high pageout rate);
    进程进入不活动状态;
    交换区所有磁盘的活动次数可高;
    可高的全局系统CPU利用率;
    内存不够出错(out of memory errors)

处理器：
    1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85%
    合理使用的范围在60%至70%。
    2 Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。

CPU资源成为系统性能的瓶颈的征兆: 
    很慢的响应时间(slow response time)
    CPU空闲时间为零(zero percent idle CPU)
    过高的用户占用CPU时间(high percent user CPU)
    过高的系统占用CPU时间(high percent system CPU)
    长时间的有很长的运行进程队列(large run queue size sustained over time)

磁盘I/O：
    1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。
    2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

I/O资源成为系统性能的瓶颈的征兆 :
    过高的磁盘利用率(high disk utilization)
    太长的磁盘等待队列(large disk queue length)
    等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)
    太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
    过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
    太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)

4．数据库服务器：
SQL Server数据库：
    1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。
    2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。
    3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。
  4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

Oracle数据库：
  1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。
    快存（共享SQL区）和数据字典快存的命中率：
  select(sum(pins-reloads))/sum(pins) from v$librarycache;
    select(sum(gets-getmisses))/sum(gets) from v$rowcache;
    自由内存：    select * from v$sgastat where name=’free memory’;
2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。
  缓冲区高速缓存命中率：
    select name,value from v$sysstat where name in ('db block gets’,
    'consistent gets','physical reads') ;
   
    Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))
3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。
    日志缓冲区的申请情况 ：
    select name,value from v$sysstat where name = 'redo log space requests' ;
4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。
  内存排序命中率 ：
    select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name='sorts (disk)' and b.name='sorts (memory)'

 

简介

Iperf 是一个 TCP/IP 和 UDP/IP 的性能测量工具，能够提供网络吞吐率信息，以及抖动、丢包率、最大段和最大传输单元大小等统计信息，从而能够帮助我们测试网络性能，定位网络瓶颈。其设计 从根本上克服了原来的一些工具，如 ttcp 和 nettest 等的固有的缺陷。

下载:

Offical Site: http://dast.nlanr.net/Projects/Iperf2.0/iperf-2.0.2.tar.gz

安装:

在指定目录下，按老三步进行：(1)./configure (2)make (3)make install

功能介绍

• TCP

测量网络带宽

报告MSS/MTU（最大传输单元）值的大小和观测值

支持TCP窗口值通过套接字缓冲

当P线程或Win32线程可用时，支持多线程。客户端与服务端支持同时多重连接

• UDP

客户端可以创建指定带宽的UDP流

测量丢包

测量延迟

支持多播

当P线程可用时，支持多线程。客户端与服务端支持同时多重连接（不支持Windows）

• 在适当的地方，选项中可以使用K（kilo-）和M（mega-）。例如131072字节可以用128K代替。
• 可以指定运行的总时间，甚至可以设置传输的数据总量。
• 在报告中，为数据选用最合适的单位。
• 服务器支持多重连接，而不是等待一个单线程测试。
• 在指定时间间隔重复显示网络带宽，波动和丢包情况。
• 服务器端可作为后台程序运行。
• 服务器端可作为Windows 服务运行。 使用典型数据流来测试链接层压缩对于可用带宽的影响。

参数与说明

命令行选项	环境变量选项	描述
客户端与服务器端选项
-f, --format	$IPERF_FORMAT	格式化带宽数输出。支持的格式有： 'b'=bits/sec  'B'=Bytes/sec  \)GF1zZxD65703'k'=Kbits/sec 'K'=KBytes/sec  (?:Dm1^]eb65703'm'=Mbits/sec 'M'=MBytes/sec 51Testing软件测试网8t&}9O1e'h]b 'g'=Gbits/sec 'G'=GBytes/sec 51Testing软件测试网:VvHm R H 'a'=adaptive bits/sec 'A'=adaptive Bytes/sec51Testing软件测试网o l3M.\HM%v 自适应格式是kilo-和mega-二者之一。除了带宽之外的字段都输出为字     节，除非指定输出的格式，默认的参数是a。 51Testing软件测试网(p5w.T'M [ 注意：在计算字节byte时，Kilo=1024， Mega=1024^2，Giga= 1024^3。通常，在网络中，Kilo=1000， Mega=1000^2， and Giga=1000^3，所以，Iperf也按此来计算比特（位）。
-i, --interval	$IPERF_INTERVAL	设置每次报告之间的时间间隔，单位为秒。如果设置为非零值，就会按照此时间间隔输出测试报告。默认值为零。
-l, --len	$IPERF_LEN	设置读写缓冲区的长度。TCP方式默认为8KB，UDP方式默认为1470字节。
-m, --print_mss	$IPERF_PRINT_MSS	输出TCP MSS值（通过TCP_MAXSEG支持）。MSS值一般比MTU值小40字节。
-p, --port	$IPERF_PORT	设置端口，与服务器端的监听端口一致。默认是5001端口，与ttcp的一样。
-u, --udp	$IPERF_UDP	使用UDP方式而不是TCP方式。参看-b选项。
-w, --window	$TCP_WINDOW_SIZE	设置套接字缓冲区为指定大小。对于TCP方式，此设置为TCP窗口大小。对于UDP方式，此设置为接受UDP数据包的缓冲区大小，限制可以接受数据包的最大值。
-B, --bind host	$IPERF_BIND	绑定到主机的多个地址中的一个。对于客户端来说，这个参数设置了出栈接口。对于服务器端来说，这个参数设置入栈接口。这个参数只用于具有多网络接口的主机。在Iperf的UDP模式下，此参数用于绑定和加入一个多播组。使用范围在224.0.0.0至239.255.255.255的多播地址。参考-T参数。
-C, --compatibility	$IPERF_COMPAT	与低版本的Iperf使用时，可以使用兼容模式。不需要两端同时使用兼容模式，但是强烈推荐两端同时使用兼容模式。某些情况下，使用某些数据流可以引起1.7版本的服务器端崩溃或引起非预期的连接尝试。
-M, --mss	$IPERF_MSS	通过TCP_MAXSEG选项尝试设置TCP最大信息段的值。MSS值的大小通常是TCP/IP头减去40字节。在以太网中，MSS值 为1460字节（MTU1500字节）。许多操作系统不支持此选项。
-N, --nodelay	$IPERF_NODELAY	设置TCP无延迟选项，禁用Nagle's运算法则。通常情况此选项对于交互程序，例如telnet，是禁用的。
-V		绑定一个IPv6地址 服务端：$ iperf -s –V 51Testing软件测试网P/r+R@e;rD"|2| 客户端：$ iperf -c <Server IPv6 Address> -V 51Testing软件测试网#{ P{H#H9i-i p6pm 注意：在1.6.3或更高版本中，指定IPv6地址不需要使用-B参数绑定，在 1.6之前的版本则需要。在大多数操作系统中，将响应IPv4客户端映射的IPv4地址。
服务器端专用选项
-s, --server	$IPERF_SERVER	Iperf服务器模式
-D		(仅用于Windows)Unix平台下Iperf作为后台守护进程运行。在Win32平台下，Iperf将作为服务运行。
-R		(仅用于Windows)卸载Iperf服务（如果它在运行）。
-o		(仅用于Windows)重定向输出到指定文件
-c, --client host	$IPERF_CLIENT	如果Iperf运行在服务器模式，并且用-c参数指定一个主机，那么Iperf将只接受指定主机的连接。此参数不能工作于UDP模式。
-P, --parallel	$IPERF_PARALLEL	服务器关闭之前保持的连接数。默认是0，这意味着永远接受连接。
客户端专用选项
-b, --bandwidth	$IPERF_BANDWIDTH	UDP模式使用的带宽，单位bits/sec。此选项与-u选项相关。默认值是1 Mbit/sec。
-c, --client host	$IPERF_CLIENT	运行Iperf的客户端模式，连接到指定的Iperf服务器端。
-d, --dualtest	$IPERF_DUALTEST	运行双测试模式。这将使服务器端反向连接到客户端，使用-L 参数中指定的端口（或默认使用客户端连接到服务器端的端口）。这些在操作的同时就立即完成了。如果你想要一个交互的测试，请尝试-r参数。
-n, --num	$IPERF_NUM	传送的缓冲器数量。通常情况，Iperf按照10秒钟发送数据。-n参数跨越此限制，按照指定次数发送指定长度的数据，而不论该操作耗费多少时间。参考-l与-t选项。
-r, --tradeoff	$IPERF_TRADEOFF	往复测试模式。当客户端到服务器端的测试结束时，服务器端通过-l选项指定的端口（或默认为客户端连接到服务器端的端口），反向连接至客户端。当客户端连接终止时，反向连接随即开始。如果需要同时进行双向测试，请尝试-d参数。
-t, --time	$IPERF_TIME	设置传输的总时间。Iperf在指定的时间内，重复的发送指定长度的数据包。默认是10秒钟。参考-l与-n选项。
-L, --listenport	$IPERF_LISTENPORT	指定服务端反向连接到客户端时使用的端口。默认使用客户端连接至服务端的端口。
-P, --parallel	$IPERF_PARALLEL	指定服务端反向连接到客户端时使用的端口。默认使用客户端连接至服务端的端口。
-S, --tos	$IPERF_TOS	出栈数据包的服务类型。许多路由器忽略TOS字段。你可以指定这个值，使用以“0x”开始的16进制数，或以“0”开始的8进制数或10进制数。例如，16进制'0x10' = 8进制'020' = 十进制'16'。TOS值1349就是：  1d PaV"T9@ y65703IPTOS_LOWDELAY     minimize delay        0x1051Testing软件测试网+`DxWZ'R(i)QG%?!V S IPTOS_THROUGHPUT   maximize throughput   0x0851Testing软件测试网%o3dD0W oWR#X IPTOS_RELIABILITY  maximize reliability  0x04 !g"?3@Zf s0l65703IPTOS_LOWCOST      minimize cost
-T, --ttl	$IPERF_TTL	出栈多播数据包的TTL值。这本质上就是数据通过路由器的跳数。默认是1，链接本地。
-F		使用特定的数据流测量带宽，例如指定的文件。 $ iperf -c <server address> -F <file-name>
-I		与-F一样，由标准输入输出文件输入数据。
杂项
-h, --help		显示命令行参考并退出 。
-v, --version		显示版本信息和编译信息并退出。

举例：

1）TCP测试51Testing软件测试网 J?s1_O,^`Yo
服务器执行：./iperf -s -i 1 -w 1M51Testing软件测试网'\4A'CT#yxs
客户端执行：./iperf -c host   -i  1  -w 1M51Testing软件测试网+Z%jx7B C,A yO*`(D
其中-w表示TCP window size，host需替换成服务器地址。 51Testing软件测试网%xgQcL
2）UDP测试
MwD!i OB:X65703服务器执行：./iperf -u -s
s#clS*[9u$\$JJ65703客户端执行：./iperf -u -c 10.255.255.251 -b 900M  -i 1  -w 1M  -t 6051Testing软件测试网]jL{w-]0g\
其中-b表示使用多少带宽，1G的线路你可以使用900M进行测试。

 

 

loadrunner的每秒点击数是指 Vuser 每秒向 Web 服务器提交的 HTTP 请求数。这里的请求数应该这样计算：

如果你点击一个链接，这个操作返回的页面上有5张图片，那么下载每一张图片都需要一个http请求，也就是说这个页面下载完成之后的点击数应该是6（有其他需要下载的东西也同样计算）

吞吐量：Vuser 在任何给定的某一秒上从服务器获得的数据量。这个数据量的计算是所下载的各个资源大小的总和

loadrunner的合并图问题

在并发测试结果中，将运行Vuser图与事物响应时间图关联合并，出来的图中，有一种比较奇怪的现象：用户用户越多的时候，反倒事物的响应时间越短，反复捉摸之后，终于理解了：

在并发测试的最后时刻，所有用户同时执行的一个事物，但是各个用户完成事物所用的时间长短一定是不同，比较快完成事物的用户，在完成之后就先退出了系统，在这种情况下，系统中运行着的用户数量越来越少，与此同时，这些用户完成事物所用的时间也就比较长，此时，loadrunner计算事物的平均响应时间也就长了。所以就出现了合并图上用户越少，事物响应时间越长的现象。这样，在并发测试结果中查看用户影响事物响应时间的图也就没什么意义了。

 

 

用LoadRunner监控windows的性能

2007-09-26 18:23:28 / 个人分类：性能测试

有两种情况
第一种：

如果是同一个用例 单机达到本机硬件承受能力极限或者许可证数量的极限 可以分成多个负载生成器统一加压.

第二种：

如果是一个包含多用例的综合场景 可以用多个负载生成器加压 也可以单独在各测试机上独立执行单个用例，加压时间不一定同步，有可能需要看其他机器的测试结果来决定加压的力度和时机

LoadRunner完全卸载方法

Left 函数
        返回 Variant (String)，其中包含字符串中从左边算起指定数量的字符。

语法

Left(string, length)

Left 函数的语法有下面的命名参数：

部分     说明
 
string  必要参数。字符串表达式其中最左边的那些字符将被返回。如果 string 包含 Null，将返回 Null。
 
length  必要参数；为 Variant (Long)。数值表达式，指出将返回多少个字符。如果为 0，返回零长度字符串 ("")。如果大于或等于 string 的字符数，则返回整个字符串。
 

说明

欲知 string 的字符数，使用 Len 函数。

注意    LeftB 函数作用于包含在字符串中的字节数据。所以 length 指定的是字节数，而不是要返回的字符数。

Mid 函数
        从字符串中返回指定数目的字符。

Mid(string, start[, length])

参数

string

        字符串表达式，从中返回字符。如果 string 包含 Null，则返回 Null。

Start

        string 中被提取的字符部分的开始位置。如果 start 超过了 string 中字符的数目，Mid 将返回零长度字符串 ("")。

Length

        要返回的字符数。如果省略或 length 超过文本的字符数（包括 start 处的字符），将返回字符串中从 start 到字符串结束的所有字符。

说明

        要判断 string 中字符的数目，可使用 Len 函数。

        下面的示例利用 Mid 函数返回字符串中从第四个字符开始的六个字符：

Dim MyVar

MyVar = Mid("VB脚本is fun!", 4, 6) 'MyVar 包含 "scrīpt"。

注意   MidB 函数与包含在字符串中的字节数据一起使用。其参数不是指定字符数，而是字节数。

 

Len 函数
        返回字符串内字符的数目，或是存储一变量所需的字节数。

Len(string | varname)

参数

string

        任意有效的字符串表达式。如果 string 参数包含 Null，则返回 Null。

Varname

        任意有效的变量名。如果 varname 参数包含 Null，则返回 Null。

说明

        下面的示例利用 Len 函数返回字符串中的字符数目：

Dim MyString

MyString = Len("VBscrīpt") 'MyString 包含 8。

注意   LenB 函数与包含在字符串中的字节数据一起使用。LenB 不是返回字符串中的字符数，而是返回用于代表字符串的字节数。

 

Right 函数
        从字符串右边返回指定数目的字符。

Right(string, length)

参数

string

        字符串表达式，其最右边的字符被返回。如果 string 参数中包含 Null，则返回 Null。

Length

        数值表达式，指明要返回的字符数目。如果为 0，返回零长度字符串；如果此数大于或等于 string 参数中的所有字符数目，则返回整个字符串。

说明

        要确定 string 参数中的字符数目，使用 Len 函数。

        下面的示例利用 Right 函数从字符串右边返回指定数目的字符：

Dim AnyString, MyStr

AnyString = "Hello World"      ' 定义字符串。

MyStr = Right(AnyString, 1)    ' 返回 "d"。

MyStr = Right(AnyString, 6)    ' 返回 " World"。

MyStr = Right(AnyString, 20)   ' 返回 "Hello World"。

注意   RightB 函数用于字符串中的字节数据，length 参数指定返回的是字节数目，而不是字符数目。

 

InStr 函数
        返回某字符串在另一字符串中第一次出现的位置。

InStr([start, ]string1, string2[, compare])

参数

start

        可选项。数值表达式，用于设置每次搜索的开始位置。如果省略，将从第一个字符的位置开始搜索。如果 start 包含 Null，则会出现错误。如果已指定 compare，则必须要有 start 参数。

string1

        必选项。接受搜索的字符串表达式。

string2

        必选项。要搜索的字符串表达式。

compare

        可选项。指示在计算子字符串时使用的比较类型的数值。有关数值，请参阅“设置”部分。如果省略，将执行二进制比较。

设置

        compare 参数可以有以下值：

常数
 值
 描述
 
vbBinaryCompare
 0
 执行二进制比较。
 
vbTextCompare
 1
 执行文本比较。
 

返回值

InStr 函数返回以下值：

如果
 InStr 返回
 
string1 为零长度
 0
 
string1 为 Null
 Null
 
string2 为零长度
 start
 
string2 为 Null
 Null
 
string2 没有找到
 0
 
在 string1 中找到 string2
 找到匹配字符串的位置
 
start > Len(string2)
 0
 

说明

下面的示例利用 InStr 搜索字符串：

Dim SearchString, SearchChar, MyPos

SearchString ="XXpXXpXXPXXP"   ' 要搜索的字符串。

SearchChar = "P"   ' Search for "P".

MyPos = Instr(4, SearchString, SearchChar, 1)   ' 在位置 4 进行的文本比较。返回 6。

MyPos = Instr(1, SearchString, SearchChar, 0)   ' 在位置 1 进行的二进制比较。返回 9。

MyPos = Instr(SearchString, SearchChar)   ' 默认情况下，进行的是二进制比较（省略了最后的参数）。返回 9。

MyPos = Instr(1, SearchString, "W")   ' 在位置 1 进行的二进制比较。返回 0（找不到 "W"）。

注意   InStrB 函数使用包含在字符串中的字节数据，所以 InStrB 返回的不是一个字符串在另一个字符串中第一次出现的字符位置，而是字节位置。

 

LTrim、RTrim与 Trim 函数
        返回不带前导空格 (LTrim)、后续空格 (RTrim) 或前导与后续空格 (Trim) 的字符串副本。

LTrim(string)

RTrim(string)

Trim(string)

string 参数是任意有效的字符串表达式。如果 string 参数中包含 Null，则返回 Null。

说明

        下面的示例利用 LTrim, RTrim, 和 Trim 函数分别用来除去字符串开始的空格、尾部空格、 开始和尾部空格：

Dim MyVar

MyVar = LTrim("   vbscrīpt ")   'MyVar 包含 "vbscrīpt "。

MyVar = RTrim("   vbscrīpt ")   'MyVar 包含 "   vbscrīpt"。

MyVar = Trim("   vbscrīpt ")   'MyVar 包含 "vbscrīpt"。

 

Rnd 函数
返回一个随机数。

Rnd[(number)]

number 参数可以是任意有效的数值表达式。

说明

        Rnd 函数返回一个小于 1 但大于或等于 0 的值。number 的值决定了 Rnd 生成随机数的方式：

如果 number 为
 Rnd 生成
 
小于零
        每次都相同的值，使用 number 作为种子。
 
大于零
        序列中的下一个随机数。
 
等于零
        最近生成的数。
 
省略
        序列中的下一个随机数。
 

        因每一次连续调用 Rnd 函数时都用序列中的前一个数作为下一个数的种子，所以对于任何最初给定的种子都会生成相同的数列。

        在调用 Rnd 之前，先使用无参数的 Randomize 语句初始化随机数生成器，该生成器具有基于系统计时器的种子。

        要产生指定范围的随机整数，请使用以下公式：

Int((upperbound - lowerbound + 1) * Rnd + lowerbound)

        这里， upperbound 是此范围的上界，而 lowerbound 是此范围内的下界。

注意   要重复随机数的序列，请在使用数值参数调用 Randomize 之前，立即用负值参数调用 Rnd。使用同样 number 值的 Randomize 不能重复先前的随机数序列。

 

Randomize 语句
初始化随机数生成器。

语法

Randomize [number]

        可选的 number 参数是 Variant 或任何有效的数值表达式。

说明

        Randomize 用 number 将 Rnd 函数的随机数生成器初始化，该随机数生成器给 number 一个新的种子值。如果省略 number，则用系统计时器返回的值作为新的种子值。

        如果没有使用 Randomize，则（无参数的）Rnd 函数使用第一次调用 Rnd 函数的种子值。

注意 若想得到重复的随机数序列，在使用具有数值参数的 Randomize 之前直接调用具有负参数值的 Rnd。使用具有同样 number 值的 Randomize 是不会得到重复的随机数序列的。

QTP的脚本语言是VBscrīpt，脚本在执行的时候，执行语句之间的时间间隔是固定的，也就是说脚本在执行完当前的语句之后，等待固定的时间间隔后开始执行下一条语句。会出现以下问题：假设后一条语句的输入是前一条语句的输出，如果前一条语句还没有执行完，这时候将要导致错误的发生！具体措施：加入同步点、加入Wait语句，如何实现呢？他们有什么区别呢？

 

 

1. 定义：
将特定属性的当前数据与期望数据进行比较的检查点，用于判定被测试程序功能是否正确
Check Point可以分两类：QTP内置验证点和自定义验证点
 
2. QTP内置验证点实现原理及优缺点
       A．录制时，根据用户设置的验证内容，记录数据作为基线数据
       B．回放时，QTP捕获对象运行时的数据，与脚本中的基线数据进行比较
       C．如果基线数据和运行数据相同，结果为PASS，反之为Failed.
       D．优点是 操作简单方便
       E．缺点是 QTP默认的检查的属性有时不符合自己的要求，如希望得到检查的属性没有在里面， 而默认的属性不需要检查等。
 
3. QTP内置验证点结果的应用
       A．录制的验证点在没有进行调整前，仅仅是给出了检查结果是通过还是错误的
       B．实际的测试过程中，可以根据验证点的结果进行不同的操作
       If Window("Flight Reservation").WinEdit("Name:").Check(CheckPoint("Name:")) = True then
              msgbox "oh, success!"
Else
              msgbox "oh, failure!"
End If
 
4. 自定义验证点的应用及优缺点
       A．使用条件语句对实际值和期望值进行对比，然后用Reporter对象报告结果
       '检查Ticket Number
If CStr(dbTicketNumber) = CStr(DataTable("oTicketNumber", dtLocalSheet)) Then
       Reporter.ReportEvent micPass, "打开订单- TicketNumber", "期望结果是：" & dbTicketNumber & ", 界面显示实际结果是：" & DataTable("oTicketNumber", dtLocalSheet)
Else
       Reporter.ReportEvent micPass, "打开订单- TicketNumber", "期望结果是：" & dbTicketNumber & ", 界面显示实际结果是：" & DataTable("oTicketNumber", dtLocalSheet)
End If
       B．优点是 非常灵活，前者实现的所有检查都可以用此方法来实现；
       C．缺点是 代码量大，对测试人员的要求高。
 
5. 对Check Point的深入理解
摘自：51Testing，http://bbs.51testing.com/viewthread.php?tid=86742&highlight=check
A．个人认为在比较简单的和有Active Screen的情况下可以使用QTP内置的Check Point，在比较复杂的情况下可以通过编程和使用Reporter来完成.
B．在使用check方法时，必须先在Keyword View或者Active Screen中新建CheckPoint。否则无法对该对象进行check，系统报错说无法在对象仓库中找到此对象。如果插入检查点，系统会自动把相关的对象添加到对象库中。
我认为检查点并不是一个实实在在的对象。因为你可以对同一个对象设置不同的检查点，可以把它的某个属性既设定成True，也可以设定为False。而对象库中的对象的属性值是必须依赖于对象的实际属性值的。如果随意更改有可能无法识别。还有就是可以针对同一个对象设定多个检查点。在测试窗口中可以看到这两个检查点的名称是区分开来的。所以我认为检查点并不是实际存在的对象，而是一些类似映射的东西。
尽管检查点并不是对象库中的实在的对象，但是它必须对应到对象库中的某个实实在在的对象，好像它的一个映像一样，而且在实际的操作过程中，QTP还是把它作为一个对象来处理的。
因为我们无法像其他对象一样把“检查点对象”添加到对象库中，而QTP又认为它是个对象，所以我们无法在专家视图中直接添加检查点脚本。但是我们可以采用编成描述的方式来实现检查点的功能。
CheckPoint 是一个依赖于Object Repository(对象库)中的某个对象的“虚拟对象”。其具体含义是：如果它所依赖的QTP 对象库中的对象没有了，那么此CheckPoint 也就不存在了；这个“虚拟对象”的属性是从它所依赖的对象的属性中“抽取”出来的，它具有它所依赖的对象的一个或几个属性，但不能增加它所依赖的对象没有的任何属性。
CheckPoint 是一个“虚拟对象”的重要原因是：每个Object都能在Object Repository找到它的Name、Class Properties，而CheckPoint 在Object Repository中就根本不存在。选择脚本中的某个对象后，在Object Property 的对话框里面有个Respository按钮，点击它后，你会看到此对象在Object Respository 的Name、Class 和 Properties。
选择一个CheckPoint后，在CheckPoint Properties 的对话框里没有 Respository 按钮，在Object Respository中也找不到此CheckPoint的Name、Class 和 Properties（因为它在对象库中根本就不存在！）。

 

什么是测试对象模型，测试对象，运行时对象？QTP的录制过程和回放过程是怎么实现的？