LoadRunner可以说是现在应用最广泛的性能测试工具.性能测试已经成测试的一个重要的组成部分.
在没有网络没有得到广泛应用之前,人们通常使用单机版的软件.随着互联网的广泛应用,软件制作厂商不但要注意软件的功能,而且还要重视软件的性能.
很多时候软件的功能已经达到了要求,但是在系统上线后却发现随着大量并发用户访问的增加,最终导致系统崩溃,为企业带来重大的经济损失.
本教程会以实例的方式讲解在实际工作中使用LoadRunner如何完成性能测试。
教程需要的测试环境请大家自行搭建，本站提供相关实例的源代码。
因为本人时间不多，同时写教程也是个很费时间的事情，教程的进度会有些缓慢，请大家谅解！
好了，前言已经写完了，下面我们将正式开始。
定义需求
不管我们做什么类型的测试，必须有一个测试目标，这个测试目标就是我们的测试需求。在大部分情况下是没有明确的需求，我们需要自己来定义需求。
看看这个例子：某互联网ＩＴ公司开发了一个 WEB应用系统，系统完成r后需要进行测试。如果你是一名测试人员，你会经常到听老板对你说 ”对系统进行性能测试，测试了告诉我结果“ ，听起来很简单需求，在仔细的思考之后我们就会发现太多模糊的需求。对系统的哪一部分进行？测试通过的标准是什么？应该如何运用并发用户策略？
如果你不知道有性能测试工具可以使用，你还会发愁如何制造多用户同时访问的测试？如果公司的人数较多，你可能还会想可以让大家一起来访问这个网站看看效果如何，在现实中也确有这种测试方法，我就遇到过，公司在没有引入性能测试工具之前真的就是找了１００多人在内部进行了并发测试，很显然这是一个无可奈何的方法，希望大家不要进行同样的测试，如果你正在考虑做类似的事情，那么你需要仔细的阅读以后的教程。
继续回到我们的话题定义需求，对于上面的例子我们应该如何定义需求呢？
其实有两种方法可以使用：
一、性能测试的需求已经明确写入了《设计说明书》。我们知道系统大约有多少个并发用户，用户要求完成哪些类型的操作……，这种需求的确定通常是基于设计需求，或来源于实际的数据。
二、性能测试的需求是找到系统性能瓶颈，这个需求听起来比较大，我们需要确定操作类型和操作习惯，这些可以来源于对系统的分析，在实施过程中需要找出系统的性能瓶颈。这个对于初学者有一定难度，同时也是我们最常见的测试需求。
很显然对于这个例子我们的目标可以将测试需求定义为找出系统的性能瓶颈。
好了，现在我们已经知道自己的测试目标是什么了，接下来我们考虑如何进行具体的操作与实施。
在上一节中我们已经知道了自己的工作目标，接下来我们要思考如何完成这些工作。
此时为了完成测试目标我们会去寻找一些工具，接下来我们将会介绍如何使用LoadRuner 完成性能测试。
确定了测试工具后，我们需要制定工作流程。在LoadRunner的技术手册给出了性能测试的基本工作流程。这里我们一起来看看这个工作流程包含哪些工作，以及这个流程为我们带来了哪些概念。
建立测试计划 -> 制作测试脚本 -> 设定测试场景 -> 运行测试场景 -> 监视测试场景 -> 分析测试结果
以上是性能测试的基本流程。由于我们是第一次进行性能测试，对于测试计划可以先跳过由制作测试脚本开始我们的测试工作。
制作测试脚本：制作一系列的操作动作，以B/S结构为例我们要告诉测试工具我们需要打开哪些链接，输入哪些数据。
设计测试场景：是标明制作好的脚本应该如何运行，要多少个虚拟用户？虚拟用户如何运行？运行多少时间？
监视测试场景：是指在测试运行过程中对指定服务器的性能进行监视，监控数据用于后期的数据分析。
分析结果：从数据中找出性能瓶颈。
在这里插播一下LoadRunner的测试原理（刚才忘了说明）LoadRunner的测试原理很简单，用多线程或多进程的方式向服务器端发送大量的数据包，同时接收服务器的返回结果。举个例子：用户注册的性能测试，打开注册页，输入注册信息，然后提交，对于性能测试而言注册信息的收入过程 LoadRunner并不会进行记录，当提交时客户端向服务器端发送请求，这个才是LoadRunner真正关心的内容。不知道我说清楚了没有，如果有疑问的朋友可以跟帖提出疑问。
回到我们的上一个话题测试流程，当知道了流程中每一步的工作任务后，我们要开始一步步的完成每一个任务。
在LoadRunner中分别不同的工具对应测试流程中的每一步。
制作测试脚本 ----- Virtual User Generator
设定测试场景 ----- Controller
运行测试场景 ----- Controller
监视测试场景 ------ Controller
分析测试结果 ------ Analysis
对测试流程、测试流程中的每个任何所需要的工具我们已经有了一个初步了解，接下来我们会实例的方式完成一次性能测试。(未完待续)
