Action.c(33): Error: C interpreter run time error: Action.c (33):  Error -- Unresolved symbol : vuser_end.

       日志意思是vuser_end部分的语法错误。

      比如缺少下面这段中的某行。

vuser_end()
{
 return 0;
}

      然后loadrunner给定位到Action.c33行，害我看了半天也没看出33行附近哪里出了问题。

 

问题现象：
使用controller加载另外的负载机，提示failed：

Connection to load generator failed.

Error: Process "lr_bridge.exe" was not created on remote host "192.168.170.161". Reason: communication error. Make sure the Agent process or service is running on the remote machine..    [MsgId: MERR-29987]

Error: Communication error: Failed to connect to remote host [server IP: 192.168.170.161].    [MsgId: MERR-10343]

解决方法
出现这种通常都是防火墙之类给限制了。 负载机是windows 2008，装的loadrunner9.5，上面没有另外装防火墙或者杀毒软件。
所以关闭掉windows防火墙（控制面板--防火墙--关闭）。
链接成功

当然可以不关闭防火墙，添加例外。添加loadrunner agent process


另外有时候，loadrunner也是傻傻地，之前都可以了连接的，现在不能连接了。请重启机器后试下能否链接。

问题1：
执行场景时出现  Error: Exception was raised when calling event-notify Vuser function in extension lrwreplaymain.dll: System Exceptions: EXCEPTION_ACCESS_VIOLATION

解决办法：在C盘新建一个TEMP目录，把环境变量TMP,TEMP值设置成新建的就可以解决

问题2：
Action.c(77): Continuing after Error -27728: Step download timeout (120 seconds) has expired when downloading non-resource(s)

设置loadrunner9.1的设置过程，run-time setting---internet protocal----preferences----advanced--打开options--修改General中Step download timeout(sec)：600.
这个值根据自己的实际需要而设置。我这里的场景是要下载一个附件，手工操作大概是3.4分钟。我这里就设置为了。

问题3：
Action.c(77): Continuing after Error -27782: Timeout (120 seconds) exceeded while waiting to receive data for URL "http://192.168.170.24/downloadFile.jsp?code=82v167l1&key=1Uf1Ssvk1D_U37jkUnAU-7jLU8UUSUjvUn5U-7jvUbtU3JjpUnA1Sn2L1gdUS7jLU1AU37jkUnAU-7jLUbJUaUjLU1AUSUjvUn5U-

Message Code 27782 Timeout ('timeout value'_ld seconds) exceeded while waiting to receive data for URL 'URL address'.

A timeout occurred while trying to reach the specified URL.

Troubleshooting
Ping the remote host to which you were connected. If it does not respond, it may be off-line or there may be a network problem.
Verify that the server application you are trying to access is running.
Increase the HTTP-request receive timeout in Run-Time Settings > Internet Protocol:Preferences > Options.

解决办法：修改Run-Time Settings > Internet Protocol:Preferences > Options >http-request receive timeout(sec):240

超时时间根据实际情况而设置。

问题4：
Abnormal termination, caused by mdrv process termination.
原因不清楚，偶尔都会遇到这个问题的，我都是重新运行场景就可以了。

问题5：
 75004 Transaction : <http://192.168.170.24/common/login/logo.gif> InstanceID: 98784247812 VUser info:Host:192.168.171.18, Group:trsdownload_a_1_4, Script.:trsdownload_a_1_4, ID:1. End Time: 1259897034.73092 Transaction end time is less than the scenario start time

问题6：
Action.c(32): Continuing after Error -27727: Step download timeout (120 seconds) has expired when downloading resource(s). Set the "Step Timeout caused by resources is a warning" Run-Time Setting to Yes/No to have this message as a warning/error, respectively

 

 

STD是标准偏差值（Standard Deviation），主要用来反应样本空间分布情况。各个样本越接近平均值，STD越小，
        在LoadRunner中，STD越小，说明系统测试时的原始数据分布比较集中，基本接近平均值。所以这个值很小时，一定程度上可以表明系统更加稳定。
      计算方法如下：
        S2 = Σ( Xi − X )2 / n − 1
         式中X ： 样本平均值
         S ： 标准偏差
         n ： 样本数量

系统响应时间与应用延迟时间的关系

　  软件性能测试的主要目的是测试和改善所开发软件的性能，对于复杂的网络化的软件而言，简单地用响应时间进行度量就不一定合适了。

　　考虑一个普通的网站系统。开发该网站系统时，软件开发实际上只集中在服务器端，因为客户端的软件是标准的浏览器。虽然用户看到的响应时间时使用特定客户端计算机上的特定浏览器浏览该网站的响应时间，但是在讨论软件性能时更关心所开发网站软件本身的 “响应时间”。也就是说，可以把用户感受到的响应时间划分为“呈现时间”和“系统响应时间”，前者是指客户端的浏览器在接收到网站数据时呈现页面所需的时 间，而后者是指客户端接收到用户请求到客户端接收到服务器发来的数据所需的时间。显然，软件性能测试更关心“系统响应时间”，因为“呈现时间”与客户端计 算机和浏览器有关，而与所开发的网站软件没有太大的关系。

　　如果仔细分析这个例子，还可以把“系统响应时间”进一步分解为“网络传输时间”和“应用延迟时间”（及响应时间=网络传输时间+应用延迟时间）。其中前者是指数据（包括请求数据和响应数据）在客户端和服务器端进行传输的时间，而后者是指网站软件实际处理请求所需的时间。类似的，软件性能测试也更关心“应用延迟时间”。实际上，这种分解还可以继续下去，如果该网站系统使用了数据库，我们可以把“数据库延迟时间”分离出来，如果该网站系统使用了 中间件，还可以把“中间件延迟时间”也分离出来。

应用延迟时间也就是上图的应用程序响应时间，对应上图是

                     应用响应时间=A1+A2+A3。

应用延迟时间比系统响应时间更能体现出系统性能，不过lr里无法得出应用延迟时间。

如果哪位知道如何得到应用延迟时间，还望告之（或者是否有其他工具能够得到应用延迟时间？）

 

 

    loadrunner总是要出些稀奇古怪的问题。今天又让我碰到了。

    打开virtual user generator 报告如图，runtime error! this application hos requested,the runtime to terminate it in an unusual way.please contat the application's support team for more information.

     打开analysis提示：startup error:外部组件发生异常。 点确定后提示：parse command line error:未将对象引用设置到对象的事例。

 

 

      现在唯一正常的就是controller了。不过不能分析和录制脚本也都没用啦。现在暂时不知道是什么原因导致的。先记录到这里。哪位xdjm知道的，麻烦提点下。

     呵呵 如果我找到原因了，再来报告啊。

 

脚本录制好后回放。提示如下，

Virtual User Script. started
Starting action vuser_init.
Web Turbo Replay of LoadRunner 9.10.0 for WINXP; WebReplay85 build 5896   [MsgId: MMSG-27143]
Run Mode: HTML   [MsgId: MMSG-26000]
Run-Time Settings file: "C:\Documents and Settings\ranting\Local Settings\Temp\noname4\\default.cfg"   [MsgId: MMSG-27141]
Starting to download the proxy automatic configuration script, URL="file://c:/docume~1/ran/locals~1/temp/customprofiledir1a07e92299d94e479c03108f9992bf44/proxy.pac"   [MsgId: MMSG-27097]
Fatal Error -27099: Address (URL="file://c:/docume~1/ranting/locals~1/temp/customprofiledir1a07e92299d94e479c03108f9992bf44/proxy.pac") of the proxy automatic configuration script. does not start with "http:" / "https:" / "ftp:". See the 'Run-time settings/Internet Protocol/Proxy'   [MsgId: MERR-27099]
Fatal Error -27072: The URL of the proxy automatic configuration script. was explicitly specified in "Run-time settings/Internet Protocol/Proxy".  Aborting   [MsgId: MERR-27072]

两个办法

1.临时性的：Run-time settings--Internet Protocol---Proxy 选择no proxy。

2.或者设置ie--internet选项---连接---局域网设置---取消掉“使用自动撇之脚本”

两种都可以解决。

负载的机器上报告：

Error: Process "mdrv.exe" was not created. Reason: 系统找不到指定的文件。

解决办法：首先查看mdrv.exe文件是否存在。lr 9.1 目录D:\Program Files\HP\LoadRunner\bin

        发现真的没有这个文件

        在别的机器上copy mdrv.exe文件解决问题。

 

估计是给杀毒软件之类的给杀了。这个是我同事的机器上遇到的

我自己机器上就遇到过360报告lr的bin目录下的dll是灰鸽子，本着试一试的心态，杀了，结果lr就彻底用不了。当时是重装了，因为也有些其他问题。

性能测试方法

1.性能测试

    性能测试方法通过模拟生产运行的业务压力量和使用场景组合测试性能是否能够满足需要。具备三个特点：

     （1） 这种方法的目的是验证系统是否具有系统宣称具有的能力。
       （2） 这种方法需要事先了解被测试系统典型场景、并确定性能目标。
       （3） 这种方法要求在已确定的环境下运行
       使用IBM Rational Performance Tester、HP Mercury LoadRuner、OpenSTA、Apache ab、
Jmeter、QALoad 、TagUnit、Java Test Runner。

 

 

2. 负载测试
       负载测试用来测定系统饱和状态、确定阀值。其特点有：
       （1） 这种方法的目的是找到系统处理能力的极限；通过“检测、加压、阀值”手段找到如“响应时间不超过10秒”，“服务器平均CPU利用率低于65%”等指标。
       （2） 这种性能测试方法需要在给定的测试环境下进行，通常也需要考虑被测系统的业务压力量和典型场景、另外HP Mercury LoadRuner在使用该方法进行“加压”的时候必须选择典型场景。
       （3） 这种性能测试方法一般用来了解系统的性能容量，或者是配合性能调优的时候来使用。特别是该项目的Weblogic Server和Oracle数据库的性能调优。

 

 

3. 压力测试
       压力测试方法测试目标系统在一定饱和状态下，例如CPU、内存等在饱和状态下、系统能够处理的session的能力，以及系统是否会出现错误。该方法需要在系统cache调优与pool优化方面着手。该方法具备以下特点：
       （1） 该方法的目的是检查系统处于压力情况下的，应用的表现。如增加VU数量、节点数量、并发用户数量等使应用系统的资源使用保持一定的水平，这种方法的主要目的是检验此时的应用表现，重点在于有无错误信息产生，系统对应用的响应时间等。
       （2） 该方法通过模拟负载在实现压力。这种模拟需要考虑的层面很多、首先、模拟必须是有效的，我的经验是需要结合业务系统和软件架构来定制模拟指标、我测试过一些国内生产的压力测试工具、他们使用通用的指标来考量、造成很多信息反馈有很大的水分。需要考虑的层面如：Oracle I/O、JVM GC、Conn Pool等。
       （3） 该方法还可以测试系统的稳定性。这里的技巧在于“什么样的平台定义一个多长的压力测试时间让其稳定运行才是科学的？”

 

 

4. 配置测试
       配置测试方式是指在测试前、测试中、测试后三个时间段通过对被测系统的软件/硬件环境的调整，了解各个不同环境对系统性能影响的程度，从而找到系统各个资源的最优分配原则。它具备以下特点：
       （1） 该方法的目的是了解各个不同的因素对系统性能影响的程度、从而判断出最值得进行的调优操作。该方法不同于与“功能测试”中涉及到的“配置测试”。
       （2） 该方法存在很大的灵活性、可以在测试环节的各个时间进行、但是什么时候开始、什么时候暂停、什么时候结束才是运用这个方法的关键。

 

 

5. 并发测试
       该方法通过模拟用户的并发访问，测试多用户环境并发访问同一个应用、同一个模块或者数据记录时系统是否存在死锁或者其他性能问题。该方法特点是：
      （1） 可以发现应用系统的全局性性能问题。
       （2） 该方法可以在开发工作的各个环节使用可以使用多个工具的配合。如：Compuware公司的DevPartner工具、EJ-Technologie公司的J Profile工具，QUEST公司的J Probe工具等。
       （3） 并发测试一般关注的问题是：
              问  题  类  别 、问  题  描  述
              内存问题：是否有内存泄露（COM+，JAVA）       
        是否有太多的临时对象（JAVA）       
          是否有太多不合理声明的超过设计生命周期的对象       
        数据库问题 ：是否有数据库死锁       
          是否经常出现长事务       
         线程/进程问题 ：是否出现线程/进程同步失败       
         其他问题 ：是否出现资源争用导致的死锁       
           是否没有正确处理异常（如超时）导致的系统死锁

 

 

6. 可靠性测试
       这里说的“可靠性测试”并不等同于“获得软件的可靠性”，软件的可靠性是一个很大的命题，这里指的可靠性测试是通过给系统加载一定的业务压力（例如：资源在80%~90%的使用率），让应用系统运行一段时间、测试系统是否稳定运行。这里有三点需要注意：
       （1） 在使用该测试前需要目的系统的资源使用率已经达到70%~90%。即在这样的苛刻环境下运行该应用系统。
       （2） 应用系统运行起来后，加载业务压力使应用系统资源达到90%。比如：该J2EE系统中设置的JDBC数据库连接池定义为30，那么加载业务压力使连接达到27。
       （3） 应用系统运行起来后结合业务情况来设定一个运行时间。比如：电力资产系统要求MTBF（平均无故障时间）达到10000小时、那么我们可以认定该系统的运行时间至少需要达到三年重新启动一次。超过这个数字我们就可以认为“不可靠”。一般情况下对于这个要求、我们让J2EE系统在资源使用率90%~100%状态连续稳定的运行3天左右没有错误就可以认定该MTBF指标已经达到。

 

 

7. 失效恢复测试
       该方法是针对有HACMP等冗余备份和Edge Server for LB等负载均衡的J2EE系统设计的。该方法考量系统失效恢复的时间、用户受到多大程度、多大范围的影响，并将其量化。该方法有以下特点：
       （1） 一般的关键业务都会采用双机热备或负载均衡方式来实现。
       （2） 该方法回答两个问题：当问题发生的时候“能支持多少用户访问”，“有多少功能不能使用”
       （3） 需要说明的是，对于HNDLZCGLXT的这个项目来说，负载均衡需要仔细考虑其实现方式，这影响到性能的调优。可以考虑使用F5等硬件技术方式、也可以考虑使用 IBM WebSphere Edge Server等商业版本的软件技术方式。

 

 

                             性能测试方法论

 1. SEI负载测试计划过程

 

      目标：产生一个清晰、好理解、可验证的负载测试计划。

内容：关注6个区域：目标、用户、用例、生产环境、测试环境、测试场景。

工具：IBM、HP、OpenSource工具都支持。需有文档配合。
      

 2. RBI方法

       目标：快速识别性能瓶颈。

       内容：重点测试“吞吐量”指标，因为RBI认定80%的系统性能瓶颈由吞吐量造成。按照网络、硬件、数据库、应用服务器、代码的顺序自上而下分析性能。

       工具：IBM、HP、OpenSource工具都支持。需使用分析模块、根据Weblogic、Oracle区别有专门的工具实现RBI。

 

 3. 性能下降曲线分析法

       目标：性能随着用户数的增加而出现下降趋势的曲线分析、查看性能下降的环境点与上下文。确定性能阀值。

       内容：通过单用户区域、性能平坦区域、压力区域、性能拐点进行监控和分析。

       工具：IBM、HP、OpenSource工具都支持。IBM报表功能更强。

 

4. HP（LoadRuner）性能分析法

       特点：侧重于该厂商的性能分析方法、主要体现在需求收集、VU脚本。

       缺点：没有对测试计划阶段、测试设计阶段的具体行为、方法、目的进行描述,方法局限于LoadRuner产品的特性上,不能通用。

 

 5. IBM（Rational UP）软件测试方法

       特点：软件产品生命周期RUP的实现、侧重于迭代测试、宽广的方法论。可适合任意测试环境及方法、工具。

       缺点：需要根据测试环境进行剪裁、难以掌握、但掌握后非常成熟、高品质工具：涉及到IBM  Rational 测试环境的所有软件、功能强大。

6. PTGM性能测试模型

       内容：一个非常适合行业用户（电力、金融、政务、制造）的性能测试过程模型。规范化的测试模型、每个环节都做到迭代测试、每一个过程的工作产品明显可察、测试流程、测试上下文方面很优秀。包括以下环节：前期准备、工具引入、测试计划、测试设计与开发、测试执行与管理、测试分析。

       工具：可以使用任意商业工具全新部署测试流程、不限于任何厂商工具的局限、也可以使用部分工具即可完成整个流程、或结合自己需要基于OpenSource工具进行定制。个人倾向使用多个产品的整合、综合使用、扬长避短。

 

该部分着重于PTGM方法论
       1. 能力验证
       能力验证一般采用这样的描述：“该系统是否能在A条件下具备B能力？”。这里强调以下内容：
       （1） 充分准备以下内容：硬件设备、软件环境、网络条件、基础数据
       （2） 充分准备测试场景、典型的场景包括操作序列、并发用户数量条件、用例。
       该部分包括使用到上述测试方法：性能测试方法、可靠性测试、压力测试、失效恢复测试。

      2. 规划性能
       该分析方法关心的是“应该如何才能使系统具有我们要求的性能能力”，“应该如何调整系统配置，使系统能够满足增长的用户数的需要”等问题。这个部分常常使用到的测试方法是：负载测试、配置测试、压力测试。

       3. 性能调优
       一个标准的性能调优过程是：
       （1） 确定基准环境、基准负载和基准性能指标。
       （2） 调整系统运行环境和实现方法，执行测试。
       （3） 记录测试结果、进行分析。
       在J2EE性能测试中有很多常见的错误，比如：对于某些建立在J2EE/EJB技术上的应用，在服务启动的时候，没有注意到测试之前首先进行一段时间的预热。这是因为JAVA语言的hot-spot技术特性决定的，这种技术允许weblogic第一次运行应用的时候将字节码编译为本地代码并执行，这样在后续的执行过程中执行过程会大大加快，但第一次由于存在一个编译过程会比较慢。如果使用这个时间来作为基准那么就容易得出错误的结论。
       我对第2个过程比较擅长、具体下来包括硬件环境的调优、Weblogic调优、Oracle调优。这个过程中也是使用工具最多的测试环节。

       4. 发现缺陷
       这个环节中是交付给用户的主要工作成果。需要多和开发人员作沟通、多次迭代发现问题、根据用户的需求定义与缺陷的涉及范围、制定一个解决缺陷的优先级。由于软件永远有BUG这一真理，所以发现缺陷不是一次就能结束的工作。比较适合作为服务外包。持续进行。

 

1. 响应时间
       我把“响应时间”的概念确定为“对请求作出响应所需要的时间”，把响应时间作`为用户视角的软件性能的主要体现。响应时间划分为“呈现时间”和“系统响应时间”两个部分。

       其中“呈现时间”取决于数据在被客户端收到响应数据后呈现页面所消耗的时间、而“响应时间”指J2EE应用服务器从请求发出开始到客户端接受到数据所消耗的时间。性能测试一般不关注“呈现时间”，因为呈现时间很大程度上取决于客户端的表现。

       这里我们没有使用很多性能测试定义中的概念——“系统响应时间”定义为“应用系统从请求发出开始到客户端接收到最后一个字节数据所消耗的时间”，没有使用这种标准的原因是，可以使用一些编程技巧在数据尚未完全接收完成时进行呈现来减少用户感受到的响应时间。

 

 2. 并发用户数
       我把“并发用户数”与“同时在线数”进行区别对待，我的“并发用户数”的标准是：并发用户数取决于测试对象的目标业务场景，因此，在确定这个“并发用户数”前，必须（必要）先对用户的业务进行分解、分析出典型的业务场景（也就是用户最常使用、最关注的业务操作），然后基于场景采用某些方法（有多种计算并发用户数的数学模型与公式）获得“并发用户数”。

       这样做的原因是：假设一个应用系统、最高峰有500人同时在线、但这500人却不是并发用户数、因为假设在一个时间点上、有50%的人在填写复杂的表格（填写表格动作对服务器没有任何负担、只有在“提交”动作的时候才会对服务器系统构成压力）、有40%的人在不停的从一个页面跳转到另外一个页面（不停发出请求与回应、产生服务器压力）、还有10%的人挂在线上，没有任何操作在发呆：）（没有对服务器构成压力的动作）。因此只有那40%的人真正对服务器产生了压力，从这里例子可以看出、并发用户数关心的是不但是业务并发用户数、还取决于业务逻辑、业务场景。

 3. 吞吐量
       我把吞吐量定义为“单位时间内系统处理的客户请求的数量”，直接体现软件系统的性能承载能力，对于交互式应用系统来说、吞吐量反映的是服务器承受的压力、在容量规划的测试中、吞吐量是一个重要指标、它不但反映在中间件、数据库上、更加体现在硬件上。我们在以下方面利用这个指标：
       （1） 用来协助设计性能测试场景，衡量性能测试是否达到了预计的设计目标、比如J2EE应用系统的连接池、数据库事务发生频率、事务发生次数。
       （2） 用来协助分析性能瓶颈、参照本文第二部分总的RBI方法。

 4. 性能计数器
       性能计数器式描述服务器或操作系统性能的一些数据指标、例如对WINDOWS来说使用内存数、CPU使用率、进程时间等都是常见的计数器。
       对于性能计数器这个指标来说、需要考虑到的不但有硬件计数器、web服务器计数器、Weblogic服务器计数器、Servlet性能计数器、EJB2的性能计数器、JSF性能计数器、JMS性能计数器。找到这些指标是使用性能计数器的第一步、关键是找到性能瓶颈、确定系统阀值、提供优化建议才是性能计数器使用的关键。性能计数器复杂而繁多、与代码上下文环境、系统配置情况、系统架构、开发方式、使用到的规范实现、工具、类库版本都有紧密的联系、在此不作赘述。
      

5. 思考时间
       我把思考时间确定为“休眠时间”。从业务系统的角度来说，这个时间指的是用户在惊醒操作时、每个请求之间的时间间隔、从自动化测试的角度来说、要真实的测试模拟用户操作、就必须在测试脚本中让各个操作之间等待一段时间、体现在脚本上就是在操作之间放置一个Think的函数，体现为脚本中两个请求语句之间的间隔时间、不同的测试工具提供了不同的函数或方法来实现思考时间、比如HP LoadRuner和IBM Rational Performance Tester的方式就完全不同。

    



转载自http://blog.csdn.net/chenshaoying/archive/2008/04/15/2294342.aspx

Monitor name :Windows Resources. Cannot collect data on the machine 192.168.170.171.
Details: The query does not currently have any counters.
Hint:
Close the application and reopen it later (it seems to be a temporary problem) (entry point: CFactory::CollectData).    [MsgId: MMSG-47292]

这个问题，关掉controller，再开就可以了。

    
loadrunner监控windows资源遇到net use failed，拒绝访问的问题。
   今天下午用loadrunner监控windows服务器资源时，遇到提示“net use failed,error code:5,error descrīption :拒绝访问”。。。



这个错误在网上可以搜到很多解决办法：
比如:1.在目标机器"服务"中开启"Remote Procedure Call (RPC)"和"Remote Registry"
     2. 被监视的WINDOWS机器:右击我的电脑,选择管理->共享文件夹->共享  在这里面要有C$这个共享文件夹,(要是没有自己手动加)
     然后保证在安装LR的机器上使用运行.输入\\被监视机器IP\C$  然后输入管理员帐号和密码,如果能看到被监视机器的C盘了,就说明你得到了那台机器的管理员权限,可以使用LR去连接了.


   这两种方法都试过了，还是监控不到windows资源。

   最后把windows 2003上的域控制器删除掉，解决问题了。
    不知道域控制器哪里的设置影响到，使得lr监控不到系统资源。
     试过把域控制器里的administrator里有关权限的部分都设置为了允许还是监控不了。最后没辙，把域控制器给删除掉了。
   有空再看看具体是域控制里哪里设置问题。

 linux系统硬盘格式化，mkfs.ext3 /dev/hdb1
 硬盘挂载 mount -t ext3 /dev/sdb /home/
 卸载硬盘分区 umount /dev/sdb
系统启动时，自动挂载硬盘。修改/etc/fstab

[root@as4-231 home]# more /etc/fstab
# This file is edited by fstab-sync - see 'man fstab-sync' for details
/dev/VolGroup00/LogVol00 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
none                    /dev/pts                devpts  gid=5,mode=620  0 0
none                    /dev/shm                tmpfs   defaults        0 0
none                    /proc                   proc    defaults        0 0
none                    /sys                    sysfs   defaults        0 0
/dev/VolGroup00/LogVol01 swap                    swap    defaults        0 0
/dev/hdc                /media/cdrom            auto    pamconsole,exec,noauto,managed 0 0
/dev/fd0                /media/floppy           auto    pamconsole,exec,noauto,managed 0 0
/dev/sdb                /home/coremail/var/ms/01 ext3   defaults        1 1
 

/etc/fstab文件详解

fstab中存放了与分区有关的重要信息，其中每一行为一个分区记录，每一行又可分为六个部份，下面以/dev/hda7 / ext2 defaults 1 1为例逐个说明：
1. 第一项是您想要mount的储存装置的实际位置，如hdb或如上例的/dev/hda7。
2. 第二项就是您想要将其加入至哪个目录位置，如/home或如上例的/,这其实就是在安装时提示的挂入点。
3. 第三项就是所谓的local filesystem，其包含了以下格式：如ext、ext2、msdos、iso9660、nfs、swap等，或如上例的ext2，可以参见/prco/filesystems说明。
4. 第四项就是您mount时，所要设定的状态，如ro（只读）或如上例的defaults（包括了其它参数如rw、suid、exec、auto、nouser、async），可以参见「mount nfs」。
5. 第五项是提供DUMP功能，在系统DUMP时是否需要BACKUP的标志位，其内定值是0。
6. 第六项是设定此filesystem是否要在开机时做check的动作，除了root的filesystem其必要的check为1之外，其它皆可视需要设定，内定值是0。

      看了不少资料都是说做性能测试的时候要模拟客户的真实环境。
      做什么事情都从他的目的出发，是想得到什么样的效果。如果是想找出系统程序上的问题，比如内存泄露等，就可以在虚拟机上进行，个人觉得虚拟机更好，可以随时恢复到某个状态，使得每次测试的环境一致。
     
  

      简单的写写测试计划
     1.做什么事情，都有它的目的。首先就是要搞清楚，做这件事情的目的是什么。
     2.然后根据这个目的，设计场景。
     3.根据平时的经验，估算整个测试时间。
     4.测试环境和系统测试前的准备工作，比如准备数据，创建1万用户，并且在这1万用户生成部分测试数据。需要比较长的时间，尽量把这些事情安排在下班时间做。
     5.录制和修改脚本。
     6.运行测试场景。
     7.写报告。
 
    为了使得每次测试环境的一致。服务器是一台虚拟机的话，可以按下面的方法设置：
    在vmware server console 选中测试的虚拟机，右键选择virtual machine settings,选择hardware选项卡，选择hard disk—advanced---independent，选择nonpersistent。
    在每次测试前，先power off 虚拟机，再power on 虚拟机，可以达到保持测试环境前后一致的目的。

     今天用360杀毒，报告C:\Program Files\HP\LoadRunner\bin\OrchidUtils.dll感染了灰鸽子。

怀着半信半疑的态度，先把OrchidUtils.dll备份了出来，然后用360立即查杀功能杀360所谓的灰鸽子。

结果导致vugen，用不了。提示runtime error。

analysis报告startup error。

现在vugen和analysis都用不了了。

把之前备份出来的OrchidUtils.dll文件再copy回去，结果还是一样，用不了的还是用不了。

恼火。以后可以真要留心点才行。

360误报可真是害人不浅啊。

 

     

      Error: Exception was raised when calling event-notify Vuser function in extension lrwreplaymain.dll: System Exceptions: EXCEPTION_ACCESS_VIOLATION

这个是什么错误？