1.  LoadRunner录制脚本时为什么不弹出IE浏览器？
　　答：启动浏览器，打开Internet选项对话框，切换到高级标签，去掉“启用第三方浏览器扩展（需要重启动）”的勾选，然后再次运行VuGen即可解决问题；如果系统中安装多个浏览器，使用IE6录制脚本，IE6->工具->internet选项->高级，把"启用第三方浏览器扩展"前面的勾取消掉，再"确定".重启一次IE也许可以解决；
　　2.   HTML-based script与URL-based script的脚本有什么区别？
　　答：使用“HTML-based script”的模式录制脚本，VuGen为用户的每个HTML操作生成单独的步骤，这种脚本看上去比较直观；使用“URL-based script”模式录制脚本时，VuGen可以捕获所有作为用户操作结果而发送到服务器的HTTP请求，然后为用户的每个请求分别生成对应方法。
　　通常，基于浏览器的Web应用会使用“HTML-based script”模式来录制脚本；而没有基于浏览器的Web应用、Web应用中包含了与服务器进行交互的Java Applet、基于浏览器的应用中包含了向服务器进行通信的JavaScript/VBScript代码、基于浏览器的应用中使用了HTTPS安全协议，这时使用“URL-based script”模式进行录制。
　　3.  Loadrunner录制脚本时Vuser_init，Action，Vuser_end的区别？
　　录制脚本时工具栏内默认会有"Vuser_init"，"Action"，"Vuser_end"3个脚本。"Vuser_init"，"Vuser_end"是必须存在，并且不能改名；"Action"脚本可以删除，改名或增加若干新的脚本。
　　"Vuser_init"通常用来存放初始化的脚本，例如登录信息；"Vuser_end"通常用来存放结束脚本，例如退出信息；这两个脚本只运行一次，而"Action"脚本可以被设置运行多次。
　　4.  为什么录制脚本的时候要关闭浏览器?
　　static { authenticateLicense(); /* * alex:每隔一个小时移除超时的Session *为什么把时间搞这么久呢? * *浏览器非正常关闭时，不会通知服务器closeSession *本来想通过浏览心跳机制来解决，却没想到浏览器端每30秒通知用的setInterval与ajax冲突*当ajax没有得到反馈时，setInterval的调用也停止了，不会每30秒做一次，很诡异，还要追查一下* *于是，6.5.3给SessionIDInfor设置一个isActive的属性，每次updateSession时设置为true，每次ReportServlet结束一个request时设置为false *只有isActive为false，才会被定时检查删除* *但这么做导致了代码的复杂度* *于是在code里面这么解决处理一下，因为这个定时操作是移除非正常关浏览器遗留的session，没有必要太频繁*/ new Timer().schedule(new TimerTask() { public void run() { if (ConfigManager.getInstance().isLicUseLock()) { authenticateLicense(); } removeTimeoutSessions(); } }， 600000， 600000); }
　　当客户端浏览器访问报表服务器端的某张报表时，便会产生一个session会话，当用户关闭浏览器的时候会通知报表服务器关闭这个session。那么如果访问的用户多，每个用户都产生>=1个session的话，可以看到 session将会很多。如果session设置的为100个，session保持时间为3分钟，那么如果3分钟有105个session，超过的5个session进入等待状态，如果没有关闭session，那么等待的session一直会占用线程，lr并发时，造成服务器线程不够现象，事务无法通过。
　　5.  在Controller中运行Web相关测试场景时，经常会有很多超时错误提示，如何处理这类问题？
　　答：这主要有脚本的默认超时设置引起。当回放Web脚本时，有时候由于服务器响应时间较长，会产生超时的错误。这时需要修改脚本的运行时配置。
　　进入“Run-time Setting”对话框后，依次进入“Internet Protocol→Preference”。然后点击“Options…”按钮，进入高级设置对话框，可以修改各类超时设置的默认值。
　　6.  LoadRunner如何自动创建脚本关联？
　　遇到sessionID之所以要用到关联，是因为每次访问被测页面时sessionID都是不同的，如果不关联sessionID，录制后的脚本把sessionID写死了，测试时，每次访问的都是同一个sessionID的页面，这是不符合实际的。而创建关联，是把产生的sessionID保存在一个变量中，供后面访问使用。
　　录制好脚本之后，查看脚本，找到sessionID，选中，右击–>scan for correlations，会弹出创建关联的界面，在底下的show differences in下拉框中选择all action，然后loadrunner会reply这个脚本，查看在sessionID部分，是不是和之前录好的不一样，如果是的，会在下面显示出来，然后我们点击右下角的correlation ，那么关联已经自动帮你创建好了，你可以打开脚本找到关于关联的参数定义。
　　7.  为什么Windows系统中的CPU、内存等资源仍然充足，但是模拟的用户数量却上不去？
　　答：在Windows计算机的标准设置下，操作系统的默认限制只能使用几百个Vuser，这个限制与CPU或内存无关，主要是操作系统本身规定了默认的大线程数所导致。要想突破Windows这个限制，须修改Windows注册表。以Windows XP Professional为例。
　　（1）打开注册表后，进入注册表项HKEY_LOCAL_MACHINE中的下列关键字：SystemCurrentControlSetControlSession ManagerSubSystems。
　　（2）找到Windows关键字，Windows关键字如下所示：
　　%SystemRoot%system32csrss.exe bjectDirectory=Windows
　　SharedSection=1024，3072，512 Windows=On SubSystemType=Windows ServerDll=basesrv，1
　　ServerDll=winsrv:UserServerDllInitialization，3 ServerDll=winsrv:ConServerDllInitialization，2
　　ProfileControl=Off MaxRequestThreads=16
　　SharedSection=1024，3072，512关键字的格式为xxxx，yyyy，zzz。其中，xxxx定义了系统范围堆的大值（以KB为单位），yyyy定义每个桌面堆得大小。
　　（3）将yyyy的设置从3072更改为8192（即8MB），增加SharedSection参数值。
　　通过对注册表的更改，系统将允许运行更多的线程，因而可以在计算机上运行更多的Vuser。这意味着能够模拟的大并发用户数量将不受Windows操作系统的限制，而只受硬件和内部可伸缩性限制的约束。
　　8.  如何让场景的用户执行发生错误继续运行，以保证不间断进行压力测试？
　　答：用VuGen打开虚拟用户脚本后，进入“Run-time Settings”对话框后，依次进入“General→Miscellaneous”，可以看到Miscellaneous设置中关于“Error Handling”的配置。勾选“Continue on error”即可让虚拟用户发生错误继续运行。
　　9.  LR运行场景时如何监控windows资源图
　　1、首先保证被监视的windows系统开启以下二个服务Remote Procedure Call(RPC)和Remote Registry Service。这两项服务在“管理工具”下的“服务”。
　　2、被监视的WINDOWS机器:右击我的电脑，选择管理->共享文件夹->共享 在这里面要有C$这个共享文件夹，若没有进行手动添加
　　3、测试机使用运行.输入\被监视机器IPC$然后输入管理员帐号和密码，如果能看到被监视机器的C盘了，说明你得到了那台机器的管理员权限。     完成了以后的准备工作，可以在LoadRunner的controller中监控windows了，操作步骤：在“windows resources”监视图中右击鼠标，选择“add measurements”跳出“windows resources”框，点击“add”输入被监控的IP。在“resource measurement on”选项框中选择要用到的计数器。
　　10. 为什么LoadRuner负载测试设置超过1000并发，运行时加压不上去？
　　因为loadRunner默认的vuser大值为1000，需要修改vuser默认值。点击Controller设计界面的Generators -->Disable，将Vuser Limits设置为想要的值
　　11. 问题描述wsa_io_pending
　　IO Overlapped是一种异步IO，在socket层，只有少量数据发送的时候，只要create new thread，send， receive，可以了。但是，当数据量增加的时候，要考虑资源的充分利用，也要避免资源的拥塞队列，如果创建线程过多，和CPU内存磁盘等资源的交互过多，可能导致拥塞出现。解决方法，调整tomcat的线程
　　12. TOMCAT的线程解释
　　maxThreads：tomcat起动的大线程数，即同时处理的任务个数，默认值为200
　　acceptCount：当tomcat起动的线程数达到大时，接受排队的请求个数，默认值为100
　　这两个值如何起作用，请看下面三种情况
　　情况1：接受一个请求，此时tomcat起动的线程数没有到达maxThreads，tomcat会起动一个线程来处理此请求。
　　情况2：接受一个请求，此时tomcat起动的线程数已经到达maxThreads，tomcat会把此请求放入等待队列，等待空闲线程。
　　情况3：接受一个请求，此时tomcat起动的线程数已经到达maxThreads，等待队列中的请求个数也达到了acceptCount，此时tomcat会直接拒绝此次请求，返回connection refused
　　maxThreads如何配置
　　一般的服务器操作都包括量方面：1计算（主要消耗cpu），2等待（io、数据库等）
　　第一种极端情况，如果我们的操作是纯粹的计算，那么系统响应时间的主要限制是cpu的运算能力，此时maxThreads应该尽量设的小，降低同一时间内争抢cpu的线程个数，可以提高计算效率，提高系统的整体处理能力。
　　第二种极端情况，如果我们的操作纯粹是IO或者数据库，那么响应时间的主要限制变为等待外部资源，此时maxThreads应该尽量设的大，这样 才能提高同时处理请求的个数，从而提高系统整体的处理能力。此情况下因为tomcat同时处理的请求量会比较大，所以需要关注一下tomcat的虚拟机内 存设置和linux的open file限制。
　　现实应用中，我们的操作都会包含以上两种类型（计算、等待），所以maxThreads的配置并没有一个优值，一定要根据具体情况来配置。
　　好的做法是：在不断测试的基础上，不断调整、优化，才能得到合理的配置。
　　acceptCount的配置，我一般是设置的跟maxThreads一样大，这个值应该是主要根据应用的访问峰值与平均值来权衡配置的。
　　如果设的较小，可以保证接受的请求较快相应，但是超出的请求可能直接被拒绝
　　如果设的较大，可能会出现大量的请求超时的情况，因为我们系统的处理能力是一定的。