我们在使用LR进行性能测试的时候，经常有需要监控OS的资源使用情况的需求。对于Windows系统，这个工作进行起来很方便，直接在LR的资源监控窗口中添加需要被监控的机器名或IP即可，但对于Linux/Unix系统，则要稍微复杂一些，我在这里简单介绍一下如何在LR中监控Linux/Unix系统的资源使用情况：

  Linux

  对于Linux系统，要想通过LR监控Linux/Unix系统的资源使用情况，需要运行rstatd服务。如果OS没有安装rstatd（可以查找一下系统中是否存在rpc.rstatd这个文件，如果没有，则说明系统没有安装rstatd），则需要进行安装。rstatd安装步骤如下：

  获得rstatd的安装介质（rstatd.tar.gz）。rstatd可以从redhat的安装CD中获得，或者从网站上下载（给出一个下载地址，sourceforge的：http://heanet.dl.sourceforge.net/sourceforge/rstatd）。

  将rstatd.tar.gz拷贝到Linux系统中，解压，赋予可执行权限，进入rpc.rstatd目录，依次执行如下命令：
      #./configure
      #make
      #make install 
  结束后，运行./rpc.rstatd命令，启动服务。这个时候，你就可以在LR中监控Linux资源了。

  Unix

对于Unix系统，比如Solaris，AIX或者HP UX等，它们的配置过程比较简单——在inetd.conf（在/etc目录下）文件中去掉rstatd前面的注释，然后启动rstatd服务即可。

概述

对于目前以 B/S 结构为主的产品来说，性能是一项必测的内容。

关于性能方面的测试，在很多地方又被细分为：负载测试、强度测试、容量测试、压力测试等等。这种细分在概念描述上有一些用处，但在实际工作中很少会只单独的进行其中的某一项测试，实际测试基本上都是交叉性的。我们这里把所有与性能相关的测试统称为性能测试，不做具体区别。

  我们在这里所说的性能测试，指的是对系统整体性能的测试，不涉及单元模块的性能检测。

  我们在这里讨论的内容主要是基于 B/S 架构的应用。

  要讨论性能测试，很难不涉及测试工具，我们在这里以 MI 公司的 LoadRunner 为默认的测试工具。

性能测试的介入时机

性能测试应该在什么时候开始？对测试人员来说，在产品的功能稳定下来后，就应该尽早开始对产品进行性能测试。一般建议在产品的 3 轮完整功能测试后开始。

测试过程

性能测试的整体测试过程如下：

    1.3.1     制定性能测试计划

    1.3.2      搭建测试环境

    1.3.3      编写测试程序/脚本

    1.3.4      测试执行和分析

    1.3.5      编写测试报告，结束测试

1.4         过程说明

各个子过程的具体说明：

1.4.1      制定性能测试计划

分析被测试系统的情况，收集性能测试需求。制定测试计划，形成文档。测试计划应考虑以下内容：

  测试对象和场景。即我们要测试的内容是什么。系统最后对外提供的功能有很多，我们不可能也没有必要对系统所有的功能点都进行性能测试。挑选性能测试对象的一般原则是：选取那些在系统实际投入使用后，并发访问量较大的、算法比较复杂的、占用系统资源较多的功能点，也就是压力点。设定好要测试的压力点后，需要详细的描述出具体的操作过程，以及预期应该达到的性能指标。

注：在制定测试计划时，对于系统预期应该达到的性能指标，常常是不能获得一个准确的数字。但即使是在没有任何参考数据的情况下，也应该和开发人员一起，设定一个初步的性能指标，作为后面测试的一个参照。有一个初步指标，也比没有任何指标要好。

  测试环境。具体包括：选用什么样的硬件环境（计算机配置，网络结构）；什么样的软件环境（操作系统，数据库，应用服务器， Web 服务器）；多大的数据量（数据库，文件系统）。

  需要监控的资源。进行性能测试时，需要监控的系统软硬件资源的占用情况。这和产品的具体情况有关，一般可以考虑的因素包括： CPU 使用情况、 Memory 的使用情况、磁盘的 I/O 、网络的占用情况、数据库运行状况、 Web/ 应用服务器运行状况等。

  测试工具。选用什么工具进行性能测试，是自己开发，还是选用第三方的测试工具。

  进度安排。各阶段的工作内容、时间安排。

 1.4.2      搭建测试环境

依照测试计划中的测试环境要求，搭建实际的测试环境，安装配置还好硬件、软件，准备好测试数据。

 1.4.3      编写测试程序/脚本

编写实际的测试程序或脚本。如果能够使用现有的成熟测试工具则尽量选用，如果现有工具不能满足测试要求，则需要编写定制的测试程序。

同时，要为脚本编写说明文档，文档的内容主要是脚本的名称，以及其对应的测试内容。

 1.4.4      测试执行和分析

设定多种测试场景组合，反复运行测试，记录结果数据，逐步优化系统，最后达到一个可接受的性能结果。测试执行过程中，注意每次测试后下次测试开始前的测试环境恢复工作。

性能测试和功能测试一样，也有测试迭代的过程，也会有产品版本的更新。在性能测试过程中，需要和开发人员协同工作，一起调优系统。

 1.4.5      编写测试报告，结束测试

整理测试数据，总结测试结果，编写测试报告，结束测试。

附录 1 保证LoadRunner测试脚本的正确性

在用 LoadRunner 编写完测试脚本后，要保证脚本在以下情况下能够正确运行：

在脚本编辑器中：单用户单循环运行脚本；单用户多循环运行脚本。

在 controller 中：多用户单循环运行脚本；多用户多循环运行脚本。

附录 2 性能测试术语解释

测试场景：包含一个或多个脚本，设定并发数量，运行方式，模拟系统在现实中的一个情景。

事务：是指一组相关的操作，是性能测试中的计时单位。比如‘登录应用系统’就可以作为一个事务。

集合点：设置集合点后，先到达的请求会等待，直到所有的请求都到达，然后一起发送请求。设置集合点，是为了进行更严格和精确的并发测试。

checkpoint ：也叫检查点。和功能测试一样，性能测试也需要检验结果的正确性。 当返回标准的 HTTP 错误时（状态码不是 200 +时），Loadrunner能够识别出来，但如果返回的不是标准HTTP错误，Loadrunner则无法识别，这时只能通过我们设置的check point来发现错误。

参数化：为了更真实的模拟现实操作，我们经常需要对测试输入进行参数化。比如登录时的用户名。

关联：对于脚本中动态变化的部分，需要对其进行参数化， Loadrunner 提供了对这种变量进行参数化的功能，叫做关联。比如下面这种情况： 在一个基于 WEB 的应用中，用户每次登录时会被服务端赋予了一个 SessionID ，该用户的后续操作都必须给出这个 SessionID 。在这种情况下，由于被赋予的 SessionID 是由服务端给出的，每次执行脚本时，获得的 SessionID 都会不同，因此就需要在脚本中取得用户每次登录，服务端返回的 SessionID ，在后续步骤中使用。这时我们就需要对 SessionID 进行参数化。即 Loadrunner 提供的关联功能。

迭代次数：在性能测试中，对于一个场景，我们需要运行多次取其平均值，即迭代运行多次。目的是为了避免意外因素对测试结果的影响。

think time ：思考时间。在进行长时间的稳定性测试时，要考虑在脚本中加入适当的 think time ，来更好的模拟现实中的情况。

    双击,进行安装,显示安装向导,其中有一个步骤是要求填入密码,这个密码随CA证书文件一起提供的.其余步骤,按默认设置即可.最后,系统会显示一个安装成功的信息提示.这个时候,你启动IE,打开'工具>Interner选项',进入'内容'标签页,点击'证书'按钮,会显示下面这样一个窗口:

    其中列出了这台机器上所安装的所有CA证书.我们这次测试所要使用的CA证书是列表中的第二个,即TRS-test3.
    2)录制测试脚本
    启动LR的Virtual User Generator,选择Web(HTTP/HTML)协议,开始录制,填入被测试网站URL,执行你预先设计好的操作,LR开始录制客户端与服务器之间的信息交互,最后停止录制.
    在你填入被测试网站URL之后,执行你预先设计好的操作之前,IE会显示一个要你选择CA证书的窗口,选择正确的CA证书即可,然后会显示一个安全连接的确认窗口,点击确定即可,然后开始正式的录制过程.
    3)修改测试脚本
    录制完成后,观察脚本内容,你会找到一条LR产生的Authentication Functions ,LR的Authentication Functions 包括如下三个:
          web_set_certificate 
          web_set_certificate_ex 
          web_set_user
    如果LR没有自动产生这条语句,那就需要你手工添加到脚本中(我们当时的情况就是LR没有自动产生这个函数,结果试了很多其它的方法,最后才找到这个函数),脚本代码类似于这样:

/* 加载指定的URL */
      web_url("wcm",
          "URL=http://wcmtest.sz.gov.cn/wcm",
          "Resource=0",
          "RecContentType=text/html",
          "Referer=",
          "Snapshot=t1.inf",
          "Mode=HTML",
          LAST);

/* 选择相应的注册到IE中的CA证书 */
      web_set_certificate( "2" );

/* 进入页面后相关的操作 */
      web_url("loginpage2.jsp",
          "URL=http://wcmtest.sz.gov.cn/wcm/loginpage2.jsp"
          "Resource=0",
          "RecContentType=text/html",
          "Referer=",
          "Snapshot=t2.inf",
          "Mode=HTML",
          LAST);
        .....
        .....
    上面代码中的第二条语句,即是选择相应的CA证书的操作.其中的参数是注册到IE中的CA证书序号,序号从1开始计算.
    4)验证脚本
    好了,这个时候脚本中与CA相关的操作就做好了.在脚本中加入其它你需要的代码后,以各种方式重放脚本,保证脚本的正确性,然后你就可以组织各种场景展开测试了.

 搜索引擎服务商Google让很多应用软件开发商的日子越来越难过。高效率、快速主页面显示、不超过半秒钟的搜索处理速度，这就是我们大家所熟悉的Google，它的表现常常被运行Web应用并制订性能指针的业务经理们奉为圭臬。而相关的Web应用开发者们则试图说明，缺少足够的资源和经费是不可能获得超强的性能表现。同时Web应用开发者也需要合适的技能以及良好的软件引擎技术处理支持。 

 为了找出两种观点中的平衡点：以可以负担的费用成本实现可接受的性能指针，Web应用的营运者和开发者常在行业标准中寻找相关性能指针以做为参考之用。目前普遍参照的性能指针来自于Keynote Systems 和Gomez，其资料显示一般的Web网站对用户的响应时间从单一页面的3秒钟到需要处理页面的12秒钟不等，而56k拨接用户则大约在20秒左右。

 上述性能指针来自于运转状况良好的Web网站。然而大多数的应用尚未有相对应的行业标准出现，大多是"视具体情况而定"。网络业流行一种说法：如果Web网站在8秒钟后没有还反应，那么浏览者会弃之而去，但Gartner集团的分析结果却发现此一观点并不准确。

性能指针视情况而定

 不断调整用户使用环境的最佳化，此一商业目标是重视性能指针的主要原因。需要说明的是，一个网站的性能表现并非影响用户感受的唯一因素，内容和设计也不能忽略。当然性能是最重要的因素之一，网站的性能不佳最容易导致用户的不满，他们会选择中断操作或是直接离开该网站。据调查表明，用户能够等待较慢的Web页面显示，但如果执行一项操作的反应较慢时，就容易失去耐心，用户才不理会该项操作在后台处理的复杂程度。

 制定性能指针需要参照应用的工作内容、用户承载量以及该项服务对于服务商和客户的价值。

大多数一数二的Web网站其页面加载速度是低于5秒钟的，但此一参照指针已经缩短，因为这会左右一个企业品牌的公众形象。

 我们知道，所谓的用户行为（user behavior）就是指网站的浏览者们出于各自的需求和习惯所发生的操作行为，其将直接影响对于服务商的系统满意度，连带影响到服务厂商的产品销售。因此了解用户行为是非常重要的，能够让服务商的网站吸引力增强并提高用户的忠诚度。但了解用户行为与系统性能的关联程度并非易事，这需要若干工具来完成。主流的Web分析工具有NetIQ/WebTrends、 WebSideStory以及 digiMine等功用，它们能够显示用户的完整浏览历程，以此显示出何种页面内容点阅率较高，而何种页面内容人气冷清。

 综合的交易处理响应监测工具有Keynote、Mercury Interactive 以及 Gomez等，它们能够统计从不同地点浏览同一页面的进入时间。网站服务质量检测工具包括Watchfire 和 Keynote等产品，它们通过分析页面内容（包含图片和内容结构）来预估页面显示时间。此外，来自Adlex、NetQoS、 Mercury以及Network Associates等厂商的实时监测工具，能够从用户浏览的资料以及放弃浏览比率来分析用户的满意程度。

 上述所有的工具如均采购将是一笔不小的开支，同时还需要一位专业人士进行资料的分析和综合。预计到2005年时，将有可能出现整合上述各项功能的工具，针对用户行为和应用性能进行分析。在该种工具上市之前，企业用户还是必须购买各种不同功能的工具以满足需求。

 如果想得到大概的性能指针参考数值，企业用户可以对照其竞争对手的网站进行分析。大多数企业应搜集其竞争对手提供的线上浏览服务，最简单的对照方法就是用码表来统计各网站各项操作的响应时间；市场上也有厂商提供长期监测产品，诸如Freshwater Software的SiteScope以及Keynote推出的Web Site Perspective服务。Keynote 和 Gomez还为市场提供目标性能基准测试服务，为证券交易、金融业以及政府网站等单位服务。