LoadRunner
目录
摘要
请用一段简单的话描述该词条，马上添加摘要 。
LoadRunner 是一种预测系统 行为和性能的工业 标准级负载测试 工具。通过以模拟上千万用户实施并发负载及实时性能监测 的方式来确认和查找问题，LoadRunner 能够对整个企业架构 进行测试。通过使用LoadRunner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统 的发布周期。它适用于各种体系架构 的自动负载 测试具，它能预测系统行为并优化 系统性能。LoadRunner 的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助您更快的查找和发现问题。此外，LoadRunner 能支持广范的协议和技术，为您的特殊环境提供特殊的解决方案。
目前企业的网络 应用环境都必须支持大量用户，网络体系架构中含各类应用环境且由不同供应商 提供软件 和硬件产品。难以预知的用户负载和愈来愈复杂的应用环境 使公司时时担心会发生用户响应速度过慢，系统 崩溃等问题。这些都不可避免地导致公司收益的损失。Mercury Interactive 的 LoadRunner 能让企业保护自己的收入来源，无需购置额外硬件而最大限度地利用现有的IT 资源，并确保终端 用户在应用系统 的各个环节中对其测试应用的质量，可靠性和可扩展性都有良好的评价。
LoadRunner LoadRunner工具原理：
代理 （Proxy）是客户端 和服务器 端之间的中介人，LoadRunner就是通过代理方式截获客户端和服务器 之间交互的数据流。
1）虚拟用户 脚本生成器通过代理方式接收客户端发送的数据包 ，记录并将其转发给服务器端；接收到从服务器端返回的数据流，记录并返回给客户端。
这样服务器端和客户端都以为在一个真实运行环境中，虚拟脚本 生成器能通过这种方式截获数据流 ；虚拟用户脚本生成器在截获数据流后对其进行了协议层上的处理，最终用脚本函数将数据流交互过程体现为我们容易看懂的脚本语句。
2）压力 生成器则是根据脚本内容，产生实际的负载 ，扮演产生负载的角色。
3）用户代理 是运行在负载机上的进程 ，该进程与产生负载压力的进程或是线程协作，接受调度系统的命令，调度产生负载压力的进程或线程。
4）压力调度是根据用户的场景要求，设置各种不同脚本的虚拟用户数量，设置同步点等。
5）监控系统则可以对数据库 、应用服务器 、服务器的主要性能计数器进行监控。
6）压力结果分析工具是辅助测试结果分析。
LoadRunner LoadRunner工具组成：
1、虚拟用户脚本生成器：捕获最终用户业务流程和创建自动性能测试脚本，即我们在以后说的产生测试脚本；
2、压力产生器：通过运行虚拟用户产生实际的负载；
3、用户代理：协调不同负载机上虚拟用户，产生步调一致的虚拟用户；
4、压力调度：根据用户对场景的设置，设置不同脚本的虚拟 用户数量；
5、监视系统 ：监控主要的性能计数器；
6、压力结果分析工具：本身不能代替分析人员，但是可以辅助测试结果的分析。
LoadRunner 组建并执行性能测试场景：
从VU 运行成功到controller运行成功，一般需要以下几个步骤（我也是从英文论坛上看到的，觉得不错，拿出来共享）：
1. 确认在VU里SUSI（单用户单循环次数single user & single iteration）
2. 确认在VU里SUMI（单用户多循环次数single user & multi iteration）
3. 确认在controller中MUSI（多用户单循环次数multi user & single iteration）
4. 确认在controller中MUMI（多用户多循环次数 multi user & multi iteration）
做这样一个步骤划分是有道理的，第一步骤是验证脚本编写的正确，第二步骤可以验证数据池是否正常运作。第三步骤验证并发功能，第四步骤是最终目的，验证软件系统 的性能。在论坛上看到一些朋友提的问题，有一些就是于此的，在controller中运行场景时出现问题，首先得保证VU中运行成功，这是一个显然的逻辑。软件工程中把软件开发的种种行为都要制定一个proccess，即过程，性能测试 也是如此，按照过程来调试脚本和场景，能及早发现问题和定位问题。除非是高手，烂熟于心中，才能超越proccess而不出问题。
场景是把虚拟用户和交易数按一定规则组织起来去模拟 真实世界的业务行为。这其实是把单个用户的行为复制，连接。场景的组织通常和真实世界的业务规则有很大关系。
做个如下可能并不恰当的比喻：
脚本像演员 ，场景就像表演的舞台 ，而测试工程师是导演，多少个演员，怎么在舞台上演出，都由导演说了算，而剧情又不能离谱，脱离现实，否则就要砸锅了。注意，导演 的职责不光是确保演出能顺利结束，而且还要同时观察和收集观众的反馈信息，以确认这次演出是否成功。
同样的也是，性能测试 人员不光是看场景是否得到顺利的执行，同时还要收集各个server的反馈信息，以确认软件系统的性能表现是否正常。
在真实世界中的用户业务 规则要转换到可操作的性能指标是需要分析和计算的。当然这通常是市场需求分析 人员干的活，但我觉得测试人员应该在做性能测试时，对这些指标进行理解，知道为什么要这样做。有时有的性能指标并不清楚和准确，还需要测试人员来分析。比如一个性能指标：要求软件系统 支持每分钟700用户的登陆行为。这对于测试人员来说，其实是一个不确切的性能需求。这指的是瞬时并发用户700，在一分钟的响应时间要求下登陆系统？还是在一分钟内陆续有700个用户登入软件系统即可？这两种场景其实对软件系统的压力是不同的，第一种显然大，第二种要小一些。甚至有的性能需求就是支持50000注册用户，这种需求就更需要分析了，还要引入一些业务发生概率算法模型来做。这已经不是性能测试人员的职责了，但由于目前有不少软件公司流程不规范，或者有流程 没执行，这些工作都要测试人员来做了，不过也好，正好是锻炼的机会。
VU生成脚本：
脚本 的生成方式就两种，一种是自写或嵌入源代码，一种是录制 生成。常常听见有人说，这两种方式中首选录制生成脚本，因为它简单且智能化。但我个人总觉得手写脚本要好一些，因为：
1．可读性好，流程清晰，检查点截取含义明确。业务级的代码读起来总比协议级的代码更易让人理解，也更容易维护，必要时可建立一个脚本库。而录制生成的代码大多没有维护的价值，现炒现卖。
2．手写的程序相比录制的脚本更能真实地模拟应用运行。因为录制的脚本是截获了网络包 ，生成了协议级的代码，而略掉了client端 的处理逻辑。举个例子，用VU录制一个运行script 和applet 的IE行为，它只会生成http协议的API ，在IE中运行的applet和script不会被模拟到，这就不是一个完整的系统。
3．手写程序相比录制脚本更能增加测试人员的技术含量。开发和测试能力双重提高，何乐而不为呢？loadrunner提供了java user，vb user，c user等语言类型的脚本，就是给我们开发脚本用的，而不是录制用的。
脚本不管录制也好，还是手写也好，选择的时候应该以脚本模拟 程序真实有效为准，结合项目进度，开发难易程度等因素考虑。
在这里我想要说的是，开发一个好的脚本是成功性能测试的必要条件。一个好的脚本应该能够最大程度再现client程序行为。如上面那个例子，脚本只模拟了client端的部分行为，有一些没有模拟到，那么client的瓶颈就有可能被忽略了。
LoadRunner 分析结果数据，找到软件系统性能瓶颈 ：
在性能测试中，测试方案就是我们的作战计划，执行性能测试就是我们的作战战场。在性能测试中，可能会发现种种意想不到的问题。当然一个经验足够丰富 的性能测试专家 可能会在测试之前就能考虑全面，使测试方案吻合测试执行实际情况，并一举找出性能瓶颈 。在此过程中，需要了解很多的知识，知识了解得越多，就越接近软件系统运行的真相，也就能找出性能瓶颈了。
一旦测试完毕后，LoadRunner 收集汇总所有的测试数据，并为您提供高级的分析和报告工具，以便迅速查找到性能问题并追溯原由。使用LoadRunner 的Web 交易细节监测器，您可以了解到将所有的图象、框架 和文本下载到每一网页上所需的时间。例如，这个交易细节分析机制能够分析是否因为一个大尺寸的图形文件或是第三方的数据 组件造成应用系统运行速度减慢。另外，Web 交易细节监测器分解用于客户端 、网络 和服务器上端到端的反应时间，便于确认问题，定位查找真正出错的组件。例如，您可以将网络延时进行分解，以判断DNS 解析时间，连接服务器或SSL 认证所花费的时间。通过使用LoadRunner 的分析工具，您能很快地查找到出错的位置和原因并作出相应的调整。
比如：loadrunner要是调用程序员 的程序，服务器资源占用情况可能是追查瓶颈的一个线索，但如果是标准中间件 ，那就没那么简单了，比如oracle 数据库的某项参数设得不对，照样会造成数据库瓶颈，应用程序调用数据库的API写法不对，比如未使用软解析变量，也有可能导致数据库瓶颈。这些瓶颈都不会反映在cpu ，内存 使用量上等指标上的。
对于这种情况，一方面需要对中间件有一定的了解，知道哪些参数有什么作用，怎么可调的，另外还可能使用中间件的专有监测工具，来分析。lr的性能计数器是不够用的。
个人体会，查找瓶颈的难易程度，由易到难
服务器 硬件瓶颈-〉网络 瓶颈-〉应用瓶颈-〉服务器操作系统瓶颈（参数配置）-〉中间件 瓶颈（参数配置，数据库，web服务器 等）