2.1 LoadRunner简介
LoadRunner是一种预测系统行为和性能的负载测试工具，以模拟上千万用户并发负载并实时监测系统性能的方式来确认和查找问题。
特点：
（1）按需生产工作量
（2）支持企业环境
（3）支持企业监控
（4）诊断
（5）自动分析
（6）简易使用
（7）高度可扩展性
（8）统一的脚本引擎
2.2 LoadRunner工作原理
LoadRunner由四大组件组成：VuGen、控制器、负载发生器和分析器
总体架构原理
（海量免费测试资料加1140267353，群内还会有同行一起交流）
（1）VuGen （Visual User Generator）：捕捉用户的业务流，并录制成一个脚本
1.1 选择一种协议，例如图中的 HTTP Protocol；
1.2 通过相应的客户端操作，捕获业务流程，并记录成脚本；
1.3 编辑Scripts和Run-Time Settings；
1.4 编译生成一个可执行的脚本；
（2）控制器（Controller）：设计场景和场景监控
2.1 场景设计分为目标场景设计和手动场景设计，我暂时只用过后者，前者在后面会深入研究一下；
2.2 可以通过添加计数器来监控Windows资源、应用服务器和数据库使用情况，后面会深入研究一下；
2.3 场景设计的目的是为了设计一个更接近实际用户使用情况的场景，这样测出来的数据会更真实，常用技巧有IP欺骗、负载均衡等；
（3）负载发生器（Load Generators）：模拟用户对服务器提交请求
3.1 我在日常使用中，Controller和Load Generators是放在一起的，因为默认设置没有分开，但在日常使用中，已经尝试过，在多台Agent机器上执行脚本，增加并发数。
建议分开的原因：
3.1.1 脚本编辑时会有大量的参数化文件，运行时会有大量的日志文件，都会占用测系统资源；
3.1.2 每个虚拟用户也需要消耗系统资源，如果在一台机器上执行并发，会导致测试机本身出现瓶颈；
3.1.3 负载发生器的计算：因为任何一台机器所能支持的虚拟用户数都有一个上限值，为了避免测试机的负载机本身成为瓶颈。从官方文档可以查询到每个虚拟用户需要消耗的系统资源值，再根据实际机器去估算一台机器能运行多少虚拟用户；
3.1.4 需要注意的是，如果使用多台Load Generators，就需要保证负载均衡，这样才能保证每台负载机器能均衡地对服务器施压；
（4）分析器（Analysis）：对测试结果进行分析
4.1 LoadRunner提供了很丰富的报告，和一些分析技术：图表合并、图表叠加、页面细分和钻取技术
2.3 LoadRunner工作过程（海量免费测试资料加1140267353，群内还会有同行一起交流）
工作过程
试着按我自己的理解去阐述一下这个图：
1、我想每个人在接触LoadRunner时，肯定都是从VuGen开始的吧，因为都是先写脚本或录制脚本，但这并不意味着LoadRunner的工作流是从VuGen开始的，因为对已整个工作流来说，脚本只是其中一个已经Ready的Input；
2、LoadRunner的整个工作流应该就像上图所示，围绕着Controller展开的：
首先，我们需要在Controller里设置场景，接着Controller开始启动，它会把脚本和Run-Time Setting里的设置，按照场景的设计，分发到每一台Load Generators上；
其次，在运行过程中，它会实时收集相关的数据，并对资源进行监控，保存在本地的Access数据库里。
最后，我们可以用Analysis去分析这些数据，获得相关的Report；
2.4 LoadRunner内部结构
（海量免费测试资料加1140267353，群内还会有同行一起交流）
LoadRunner 内部结构
这张图涉及LoadRunner的内部运作机制，比较复杂。从这一小节里，我只是大概了解了常见的一些文件是用于什么的。后面会在实践过程中深入了解。
脚本目录：
.dat -- 脚本里的参数化文件
.cfg -- Run-Time Settings配置文件
.lrs -- 场景文件
.usr -- 脚本文件
res -- 场景运行结果目录
log -- 日志目录
result1 -- 我理解是单步在VuGen里执行脚本生成的结果目录
2.5 LoadRunner 性能测试步骤
性能测试工作流程
当应用在不同类型的产品或项目上时，该流程需要做一定程度上的裁剪，基于我当前的实际理解，还只能粗显的理解这个流程，并没有深入实践并完成过相关的东西，所以有待后续实践再总结。
最后，只想说，从这一章的寥寥几页，就感觉到对LoadRunner这个工具的了解和挖掘估计1%都不到，任务还很艰巨，加油！