1、首先要了解LoadRunner是一种预测系统行为和性能的负载测试工具，通过模拟用户实施并发负载及实时监测来分析问题的。它主要分为四个部份；

　　脚本生成器Virtual User Generator：提供了基于录制的可视化图形开发环境,录制脚本、脚本编写、事物、参数化等在此实现。

　　压力调度和监控系统Controller：负责对整个负载过程进行设置，设定负载的周期与方式并监控系统。

　　压力生成器Load Generator：负责将脚本虚拟成大量的用户对系统实时负载。

　　结果分析工具Analysis：对负载生成后的相关数据进行分析整理。

　　2、要想做好性能测试真的是一件不太容易的事情，但相对于学习LoadRUnner的使用来说，对基础并没有太高的要求，只要你掌握一些编程语言、熟悉各个模块功能就可以使用LoadRunner了，再就说到掌握到什么程度就是一个成手的话题上，这个程度还真是不太好说，定位不一样，有些公司只要求你会使用工具，只是把别人设计好的脚本在场景里运行即可，而有些公司不但要做以上这些事，还要进行脚本的设计、结果的分析,一般的人认为结果分析是最难的，但我到是认为结果分析只是抓取数据并不是想像中的那么难。

　　3、如果你在负载测试、压力测试、性能测试或者可量测性测试方面是个新手，你大概会疑惑在测试过程中会牵涉到一些什么。或许你在自动化测试或者人工功能测试方面有很多的经验，并且也打算制作一个负载测试的流程。这会有一些相似之处，但最为重要的是，有巨大的差别。

　　系统：安装一个用作负载测试的环境看起来要花费很多的努力。仔细研究当前的生产系统。决定下来负载测试环境的范围。你是否想要模拟整个的生产系统？或者你只是想模拟生产系统的一个部分？尽管后者不是最为理想的一个方法，但是它是很实用的。会有什么样的组件参与进来？第三方的软件有否集成到你的底层架构中？你想要包括这些第三方的软件吗？硬件如何？记住：你不但需要包含测试下的系统（SUT），而且要包含LoadRunner的压力注射器。如果有可能的话，你应该单独有一个压力测试的环境，和其他的开发、测试或者生产的环境分离开来。所有的这些问题和以及将来更多的问题需要包含在预算中的。

　　网络：理想的状态，你的压力测试的环境应在一个独立的网络中。如果无关紧要，可以用一个交换网络来替代。原因是非常明显的，但又常常被忽略掉。首先，你不想让一些和测试无关的操作介入你的测试。如果你正在进行一个压力测试，这时其他人却在网络上通过FTP或者NDM传送大量的文件或者数据，这样会导致你的测试失去意义。同时，你也不想让你的大规模的压力测试影响网络上的开发或者生产系统。如果你对网络造成涌堵会成为不受欢迎的人。

　　范围：你的压力测试实验室的主要焦点是什么？是针对单独的一个应用程序？或者是负责整个企业的多个应用程序的测试？这是一个需要你在安装你的测试实验室之前需要考虑的关键问题。

　　计划：对一个压力测试来讲，在测试计划方面下再大的努力也是不充足的。试图在一个礼拜之内运行一个大规模的压力测试是有很多问题存在的。你必须创建一个非常详细的计划，在这个计划里需要包含关于这个测试的方方面面：交易的流程/工作量/生产量，而且需要测试的系统的详细图表，关于你的测试方法论的相关信息（换算系统，成功因素，运行测试的每一步的步骤），整个项目组的观点以及他们的关心，需要收集的重要属性的解释，执行测试的日期和时间，联络人的列表，包含在内的系统的组件，风险和减轻风险的措施。这些都是你测试计划里需要包括的例子。并非所有的测试都需要做到如此的详细，但是你应该从类似的模板中精选出你认为需要包括进去的。

　　支持：在你运行你的测试的时候，总是需要系统和开发部门的人做支持的。在一个关键测试运行的中间阶段，如果一个服务器出现锁定是让每一个人灰心丧气的事情。如果你自己能够解决最好，不能解决就要找人来解决。

　　人员：压力测试会消耗掉你的大量的时间。如果你在对多个应用程序进行压力测试，并且是按照特定的程序重复你的测试，那么你需要有足够的人员来满足你的需求。

原帖地址：http://bbs.51testing.com/viewthread.php?tid=263958&extra=&page=1

版权声明：本文由会员yetties2005首发于51Testing软件测试论坛“我要做专家-你问我来答”活动第二期。

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。