1. 如何对API进行负载测试与调优（一）
本文由Donny译自 3scale.com 的 《How to load test & tune performance on your API》
这几年API的作用不断演化，以前API还只是用来做内部系统之间的集成点，但现在API已成为一个公司的核心系统，一个构建于Web和移动端应用之上的核心系统。
当API仅只用来处理后台的任务（例如生成报告），那么性能差点也不是问题。但是如今API慢慢地发展成为连接服务与终端用户的核心纽带。这种关键性的角色变化表明了一个重要的观点：那就是API的性能真的很重要。
如果API数据源响应快，前端的应用程序的设计好点或差点影响不大，要是响应慢如蜗牛，前端的设计再出色也是然并卵。现在我们的客户端应用展羡旅示的数据源可能都是来自多个API响应内容的聚合，性能对这种微服务构架来说真的非常重要。
可以毫不夸张的说出色的性能就是你API提供的最好功能。我们知道向目标改进的唯一正确的方法就是找到问题的关键点，或者叫关键路径，并不断迭代测量和调整你的架构系统，直到系统达到预定的目标。对于API来说，测量和提高性能的过程就是负载与压力测试的过程。
本文将重点介绍如何对你的API进行负载压力测试。我们会以一个简单的、未测过的例子开始，然后再添加一个访问控制层，要确保一切都经过严格测试，做好处理真实流量的准备工作。OK，开始吧！
首先我们要明确要测试什么，可以是对你所有的API接口，或者是对单个API接口，或是对需要排除故障或改进的API接口的常规测试。
本文的其部分，我们将使用一个示例API。这是一个棋牌类游戏的Node.js API。它有三个API接口：
/question – 返回一个随机黑牌
/answer – 返回一个随机白牌
/pick – 返回一对随机的问题与答案
你测试用的负荷情况越和真实环境的越类似，你的负载测试就越有用。如果你不知道实际流量有多少或者你不知道负载在所有接口上是否都一致，那么就算你知道你的API可以保持400 请求/秒的吞吐量也没啥鸟用。
所以，你应该先从收集你兄册凳API的使用数据开始。你可以直接从你的API服务日志或者从其他你在用的应用性能工具（例如New Relic）中获取数据。在对你的API进行第一次测试之前，你应该对以下问题做到心中有数：
（1）每秒请求数的平均吞吐量（Average throughput in requests per second）
（2）峰值吞吐量（您在某段时间内获得的最大流量是多少？）（Peak throughput）
（3）API各接口的吞吐量分布情况（有没有一些接口的流量远姿野超其他接口？）
（4）用户的吞吐量分布情况（少数用户产生大多数的流量，或者是更均匀分布？）
另外还需要考虑的一个关键点是，在测试期间将要模拟的流量会是怎样的，主要考虑点是：
（1）重复负载生成（Repetitive load generation）
（2）模拟流量模式
（3）真实流量
通常我们最好以最简单的方法开始测试，然后逐步演化到更为接近真实环境的测试。我们可以先用重复负载生成来做为API接口的第一个测试，这样不仅可以验证我们的测试环境是否稳定，更重要的是可以让我们找到API能承受的最大吞吐量，这样我们就可以知道API可以达到的性能上限是多少。
找到你的API性能上限值后，你就可以开始考虑如何将你的生成的测试流量塑造得更接近真实环境。使用真实流量来测试是最理想的，但实际操作不太可行。要模拟真实流量比较难，也太花时间。所以我们有一个折中点的方法：先研究你的流量分析数据，并做一个简单的概率模拟。比如你有100个API接口（提示：原文endpoint在这里我译为接口，翻译成端点也可以，不过译成接口感觉更容易理解），你检查了上个月的使用情况，发现80%的流量来自20个接口，其中3个接口占用了50%的流量。那么你就可以创建一个遵循这种概率的请求列表，并提供给你的负载测试工具。这样做就相对快多了，并且它相对比较接近你真实负载，可以显示出你实际环境中可能遇到的问题。
最后，如果你拿到你要测试的API的真实访问日志，你就可以用它们来做最接近客观现实的测试。我们待会儿要讨论的大部分负载测试工具，都是接收一个请求列表作为输入文件。你可以用你的访问日志，稍微做一个格式调整就可以匹配每个测试工具所需的格式。搞定这个你就可以在测试环境中轻松重现你的生产流量。
好了，你清楚了你要测试什么鬼了，准备工作的最后一步就是配置好你的测试环境。你需要一个专用的测试环境。如果你不怕被你老板骂的话，或者比较任性，你也可以直接在你的生产环境中进行性能测试，不过出问题别说哥事先没跟你说清楚哈。
如果您已经设好一个预生产或沙箱环境，并且你的API也在上面运行了，那么你就万事俱备了。因为本文要用示例API，我们会在AWS的服务实例上设置我们的环境。
在我们的例子中，我们使用一个简单的API，不需要从磁盘读取或在内存中保存大型数据集。我们选择Linux C4.large 实例就够了。
注意：我们对比过其他相似处理资源数但内存更大的AWS实例，但实际测试中内存大部分没使用，所以我们选了C4.large
接下来，我们将一个配好的负载测试实例（服务器）运行起来，这只是一个运行模拟测试程序的服务器，它会通过从多个并发连接重复发送请求到我们的API服务器。你需要模拟的负载越高，机器的性能就要求越高。再次，这也是一个CPU密集型工作负载。这里我们选择具有4个虚拟核，16个 ECU的优化处理器的 c4.xlarge AWS服务器
我们选择在相同的可用区内部署所有实例（API服务器与测试服务器在同一个区/机房），这样可以将外部因素对我们测试结果的影响降到最小。
我们有一个沙箱环境来运行我们的API，同时也有另一台服务器准备开始负载测试。如果这是你第一次做性能测试，你一定会想知道什么是最好的方法。在本节中，我们将会分享我们如何选择工具，同时也会介绍一下目前市面上一些公认比较好的工具。
JMeter
在人们意识当中，首当翘楚的估计是 Apache JMeter ，这是一个开源的Java程序，他关键的特性就是提供一个强大而完善的创建测试计划的GUI。测试计划由测试组件组成，测试组件定义了测试的每一个部分，例如：
（1）用来注入负载测试的线程
（2）参数化测试中使用的HTTP请求
（3）可添加侦听器，象widget测试组件那样，可以以不同的方式显示测主式结果
优点：
（1）它是功能性负载测试的最好工具。你可以设定条件来为复杂的用户流建模，还可以创建断言来验证行为。
（2）轻松模拟复杂的http请求，比如请求前的登录验证或文件上传
（3）可扩展性强，有很多社区插件可以修改或扩展内置的行为
（4）开源并且免费
缺点：
（1）GUI学习曲线陡峭，一大堆的选项，在你运行第一个测试之前你得了解大量的概念。
（2）测试高负载时，操作步骤很麻烦。你需要先使用GUI工具来生成XML测试计划，然后在非GUI模式下导入测试计划运行测试，因为GUI会消耗掉本用于生成负载的大量资源。你还需要注意所有的侦听器（收集数据与展示测量的组件）哪些要被禁用或启用，因为它们也很耗资源。测试结束后后，你需要将原始结果数据导入GUI以才能查看结果。
（3）如果你的目标是测试一段时间内的持续吞吐量（例如在60秒内每秒请求1000次），那么很难找到正确的并发线程数量和计时器来求出一个比较稳定的数值。
JMeter只是我们在开始测试时用的工具，我们很快开始寻找其他替代方案。原因是，如果你的目标是在Web应用上压力测试复杂的用户流，那么JMeter可能是最好的工具，但如果你只是需要在一些HTTP API接口上进行性能测试，那用它就是杀鸡用牛刀了。
Wrk
Wrk 是一款和传统的 Apache Benchmark （最初用来做Apache服务器的测试工具）非常相似的工具。wrk和ab完全不同于JMeter：
（1）一切都是可以通过命令行工具配置和执行的。
（2）配置少但强大，只有基本生成HTTP负载的必要几项配置
（3）性能强悍
然而，和传统ab工具相比还是有几个优势的地方，主要是：
（1）多线程，所以能利用多核处理器的优势，更容易生成更高的负载
（2）利用Lua脚本很容易进行扩展默认的行为
不好的地方，主要是生成的默认报告在内容与格式上都受到限制（仅文本，无绘图）。当你的目标是找到你的API可以处理的最大负载量，那么wrk是你最佳选择工具。wrk用起来很快就可以上手。
Vegeta
Vegeta 是一款开源命令行工具，但它采用的方式不同于我们以前所见的工具。它专注于如何达到与维持每秒请求数速率。也就是说它侧重在测试支撑每秒X次请求时API会有怎样的服务行为，当你有实际的数据或对你将要达到的峰值流量有个估算时就非常有用，你可以用于验证你的API是否能满足你的需求。
SaaS 工具
正如你之前所看到的，运行一个简单的负载测试需要准备好配置环境。最近有些产品提供负载测试服务。我们试过两个， Loader.io 和 Blazemeter （话外：阿里也有性能测试工具 PTS ，老外估计没试过）。
注意：我们只试了这两个工具的免费版，所以得到的测试结果仅适用于免费版的限定。
Blazemeter
这个产品和我们前面提到的JMeter一样有同样的毛病：如果你只需要用在高负载测试，你需要在GUI界面上创建测试计划，然后在另一个运行非GUI模式的JMeter中导入这些计划。Blazemeter允许你上传JMeter的测试计划到他们的云端并运行，但可惜的是免费版只能设置50个并发用户。
Loader.io
它是一款 SendGrid 出品的简单而强大的云负载测试服务工具。它有你所需要的功能和漂亮的可视报告。 Loader.io 的免费版还是不错的，每秒最多可以有10000次请求的吞吐量，你基本上就可以用它来运行一个真实的负载测试。
我们推荐使用多个工具，以便可以多重检查我们的测试结果，不同的工具有不同的功能与方法，可以更多方面地反映测试结果。
我们先尝试找到我们的API可以承受的最大吞吐量。在这个吞吐量下，我们的API服务达到最大CPU利用率，同时不会返回任何错误或超时。这个吞吐量就可作为我们后面测试要用的每秒请求数。
同样，重要的是要注意到：CPU是限制因素之一，但你也还必须清楚地知道哪些资源会成为你API的性能瓶颈。
我们有必要在API服务器上安装一些工具，以便我们在测试过程中监控资源的利用率情况。我们使用 Keymetrics.io 和 PM2 模块。
我们的Node.js应用运行了一个非常简单的HTTP 服务。Node.js是单线程设计的，但为了利用c4.large AWS实例中提供的双核，我们使用PM2的集群功能来运行应用程序的两个工作进程。
由于我们的API是完全无状态的，所以很容易使用PM2的 核心集群模块（PM2在内部直接使用）。PM2提供的集群功能提供了不错的快捷命令来start/stop/reload应用程序，也可以监控进程。
我们先使用Loader.io对API进行测试。以下是持续30秒，每秒10,000次请求的测试结果，10000次请求是Loader.io免费版中允许的最大吞吐量。
在测试期间，我们观察到API服务器的CPU处理器在测试期间只有几次达到100％的容量。
这表示我们的API可能还可以处理更高的吞吐量。我们接下来通过运行wrk进行第二次测试证实了这一点。我们的目标就是要将我们的API服务器性能推到极限。
wrk -t 4 -c 1000 -d 60 --latency --timeout 3s http://api-server/questions
这里是我们对这个测试做了多次重复测试的结果：
Running 1m test @ http://api-server/question
4 threads and 1000 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 62.23ms 30.85ms 1.35s 99.39%
Req/Sec 4.07k 357.61 5.27k 94.29%
Latency Distribution
50% 60.04ms
75% 63.85ms
90% 64.17ms
99% 75.86ms
972482 requests in 1.00m, 189.89MB read
Requests/sec: 16206.04
Transfer/sec: 3.16MB
结果表明，我们的预感被证实：它达到16,206请求/秒，同时保持合理的延迟，第99百分位只有75.86毫秒。 我们将这作为我们的基准最大吞吐量，因为这一次我们看到了API服务器的最大容量处理能力：
我们刚看到用一个简单的方式来找出你的API可承受的最大流量负载，同时在这过程中我们介绍并讨论了我们看到的一些工具。
请继续关注本文的第二部分，我们将介绍如何控制流量，不要让随随便便一个客户端就可以轻松搞跨您的API。 我们将展示如何通过在架构前端添加代理来确保我们的API的性能不受影响。
本文译自： How to load test & tune performance on your API
2. 如何对Web应用程序进行负载测试
定义测试策略 到目前为止，您肯定参加过这样的会议，客户倚靠在宽大的会议桌上，问您：“这个系统能处理上千个用户吗？”传统的负载测试方法要求您编写脚本并执行测试，以试图给出此问题的精确答案。对于这种测试，您需要定义“处理”的含义以及 1000 名典型用户在站点活动时的情形。您需要定义测试用例以代表各种用户活动：例如，购买股票或注册新的帐户。接下来，您必须估计用户在这些测试用例上的分布。对以下数据进行假设，即模拟真实用户与应用程序交互时，需要多长的思考时间（或等待时间）。因此，负载测试期间活动的可从某个方面大致反映出同样数量的真实用户在站点活动时的情形。 这种方法有几个不足之处。首先，其结果不会比您做的假设更好。显然，不正确的假设将使结果出现偏差。 其次，估计真实用户需要大量客户端硬件。如果对每名虚拟用户给定需要的处理能力和内存量，则典型的客户端计算机可以处理大约 200 名虚拟用户。因此，对 2000 名用户并发处理级别的测试需要 10 台客户端计算机 — 这是一笔重大投资。测试使用 HTTPS 的站点将需要多得多的客户端硬件。 最终，此方法难以向您的开发团队提供以操作为导向的信息。当某处出现故障时，常常难以再现该问题。 作为备选方案，我们建议您围绕以下这些关键问题设计测试用例： �6�1 系统瓶颈在哪里？系统能同步处理多少个并发请求？ �6�1 在响应时间变得不可接受之前，一台机器能处理多少名不同步的超级用户？ �6�1 添加额外的硬件时，结果是线形增长的吗？ �6�1 有任何稳定性问题会妨碍站点运行于生产环境中吗？ 此方法将使用开发团队（此开发团队参与可能出现问题的领域）提供的附加信息。请关注这些领域。对于上一个示例，其瓶颈可能出在定单提交领域。从这里您可以派生出更具体的问题，例如“提交流程可以同时处理多少个请求？”攻击这些特定领域是最快且成本最小的方法，用来向开发团队提供以操作为导向的信息，以便他们能改进系统。在使用这种方法的同时，我们推荐您记住遵循以下建议。 关注负载测试正如我们已提到的那样，首先要做的是构建导致潜在瓶颈和稳定性问题的脚本。这种“数据第一，假设第二”的方法使您能够从应用程序收集原始数据，然后根据假设确定更高级别的结果。不用担心为识别低风险站点的脚本编写问题。例如，为站点的帮助领域或只读文档领域编写脚本不大可能出现系统瓶颈。 同步请求使用同步请求攻击瓶颈。此处的这个主意是模拟最坏的情况：即，站点上的用户精确地在同一时间攻击瓶颈。通过使用户同步，您可以重复进行此测试。如果不同步结果，则难以再现故障情况。可以使用同步点做到这一点，同步点是大多数较健壮（成本也较高）的测试工具中提供的一项功能。同步点迫使每名虚拟用户一直等到剩余的用户到达脚本中定义的点后，才能开始下一请求。它允许您精确并重复地确定站点的潜在瓶颈区域能处理的并发用户数。例如，下限可以是 7 名并发同步用户。 创建循环测试用例脚本使测试用例循环。在另一种方法中，每次测试用例迭代前后，站点应处于相同状态。这允许您长时间地重复运行测试用例。 使用超级用户最后，使用我们所称的超级用户。正如前面所提到的，超级用户运行时思考时间设置为零。请记住，思考时间假设是用于常规测试中，以使虚拟用户模拟真实用户。但是，如果将虚拟用户思考时间减半，则服务器的实际负载将加倍。在另一种方法中，服务器真正关心的与负载有关的变量是每秒的请求数。虚拟用户的数量及其思考时间结合起来生成该负载。 让我们进行一些数学运算以使此概念更清晰。下面的公式计算访问站点的真实用户生成的负载（请求数/秒）： 例如，某个站点有 100 名并发用户，假设下载时间为 10 秒，思考时间为 30 秒，则每秒将生成 2.5 页。如果我们假设每页 3 个请求，则在 Web 服务器上将转化为每秒 7.5 个请求。 以超级用户运行测试时，观察每秒请求数，并与刚刚计算的值比较。根据我们的经验，真实用户数与超级用户数的比例通常约为 15:1。对于同一个示例，这意味着 (100/15) 名超级用户将生成与 100 名普通用户相同的负载。再举一个例子，假设在 10 名超级用户之后响应时间变得不可接受。请注意转换回真实用户数的该点每秒请求数。现在您可以进行任何希望的思考时间假设，甚至可以更改它而无需重新运行测试。在几天的测试之后，您将能根据直觉从超级用户数转换成真实用户数。此方法允许您保持用户数可控，减少所需的客户端硬件数量，并包含负载测试软件的成本。 这些超级用户测试用例对于多机测试很有用。要测试站点的可伸缩性，可添加第二台 Web 服务器和一个负载平衡器，并重复超级用户测试。理想情况下，在看见相同的相应次数之前，您将能加倍超级用户数量。 要回答稳定性问题，可运行测试，以在延长的时间段内维持合理数量的并发且未同步超级用户。我们在上一个项目中熬了很多个通宵，甚至 24 小时昼夜不停，但持续时间与应用程序有关。我们称之为“内置”测试。一旦您已采取步骤识别并潜在地解决了找到的瓶颈，则重复同步点测试，看下限是否有所增长。然后用所支持的新的并发用户数重新运行“内置”测试。以努力提高此数字为目标重复该循环，直到达到质量条。 但是有多少用户呢？ 尽管此方法向开发团队提供了有价值的信息，但它使得您更难于回答会议室的问题。不过，您可以近似地估计答案。例如，假设站点的最坏情况瓶颈显示，每台计算机多于 20 名超级用户的情况下，响应时间超过 10 秒。根据您从我们建议的公式计算的结果，近似地估计有 300 名真实用户（20 名超级用户 × 15 名真实用户）。此时，您可以做出与常规用例中相同的假设。通常情况下，有百分之多少的用户正在使用站点的此领域？假设预期 50% 的用户正在使用此领域，而其他领域，例如文档或数据库读取，用户比例则没有这么大。这意味着具有一台 Web 服务器的系统将处理大约 600 名用户。 到目前为止，我们已讨论了在能明确地指向站点的一个瓶颈领域的情况下该如何做，但如果影响性能的领域不止一个时您又应如何做呢？答案是创建单独查看各个领域的测试脚本。首先孤立地运行这些脚本，然后一起运行。再比较结果，看站点的一个领域对另一个领域的影响有多大。
3. loadrunner包含哪些组件
1．Virtual User Generator（虚拟用户生成器）用于捕获最终用户业务流程和创建自动性能测试脚本（宴册也称为虚拟用户脚本）。
2．Controller 用于组织、驱纯祥知动、管理和监控负载测试
3．负载生成器用于通过运行虚拟做消用户生成负载
4．Analysis 有助于您查看、分析和比较性能结果
5．Launcher 为访问所有 LoadRunner 组件的统一界面
4. loadrunner如何使用
1、使用LoadRunner 完成测试一般分为四个步骤：
2、Vvitrual User Generator 创建脚本
创建脚本，选择协议
录制脚本
编辑脚本
检查修改脚本是否有误
3、中央控制器（Controller）来调度虚拟用户
创建Scenario，选择脚本
设置机器虚拟用户数
设置Schele
如果模拟多机测试，设置Ip Spoofer
4、运行脚本
分析scenario
分析测试结果
5、安装LoadRunner 中文版
LoadRunner 分为Windows 版本和Unix 版本。如果我们的所有测试环境基于Windows
平台， 那么我们只要安装Windows 版本即可。本章讲解的安装过程就是LoadRunner7.8中文的Windows 版本的安装。
6、使用LoadRunner进行负载/压力测试
7、录制基本的用户脚本
创建用户脚本需要用到VuGen。提示： 运行VuGen 最好在1024*768 的分辨率下， 否则有些工具栏会看不到。
启动Visual User Generator 后， 通过菜单新建一个用户脚本， 选择系统通讯的协议。
这里我们需要测试的是Web 应用，同时考虑到后台SQL数据库所以我们需要选择Web(HTTP/HTML)协议＋SQL SERVER协议，确定后， 进入主窗体。通过菜单来启动录制脚本的命令。
8、在URL 中添入要测试的Web 站点地址..。
●测试http://lms.ah.sp.com.cn/lms-lmm/loginForm.do选择要把录制的脚本放到哪一个部分， 默认情况下是“Action”。
这里简单说明一下：VuGen 中的脚本分为三部分：vuser_init、vuser_end 和Action。其
中vuser_init 和vuser_end 都只能存在一个， 不能再分割， 而Action 还可以分成无数多个部分（ 通过点击New 按钮， 新建ActionXXX）。在录制需要登陆的系统时， 我们把登陆部分放到vuser_init 中， 把登陆后的操作部分放到Action 中， 把注销关闭登陆部分放到vuser_end 中。（ 如果需要在登陆操作设集合点， 那么登陆操作也要放到Action 中， 因为vuser_init 中不能添加集合点） 在其他情况下， 我们只要把操作部分放到Action 中即可。注意： 在重复执行测试脚本时，vuser_init 和vuser_end 中的内容只会执行一次， 重复执行的只是Action 中的部分。
点“ 选项 ”按钮， 进入录制的设置窗体， 这里一般情况下不需要改动。
●然后点“OK” 后，VuGen 开始录制脚本。在录制过程中， 不要使用浏览器的“ 后退” 功能，LoadRunner 支持不太好！ 录制过程中， 在屏幕上会有一个工具条出现。录制的过程和WinRunner 有些类似， 不再多介绍。录制完成后， 按下“ 结束录制” 按钮，VuGen 自动生成用户脚本， 退出录制过程。
完善测试脚本
当录制完一个基本的用户脚本后， 在正式使用前我们还需要完善测试脚本， 增强脚本的
灵活性。一般情况下， 我们通过以下几种方法来完善测试脚本。插入事务、插入结合点、插入注解、参数化输入。这里只举例介绍参数化如何设置，其它只作简单介绍。
插入事务
事务（Transaction）： 为了衡量服务器的性能， 我们需要定义事务。比如： 我们在脚本
中有一个数据查询操作， 为了衡量服务器执行查询操作的性能， 我们把这个操作定义为一个事务， 这样在运行测试脚本时，LoadRunner 运行到该事务的开始点时，LoadRunner 就会开始计时， 直到运行到该事务的结束点， 计时结束。这个事务的运行时间在结果中会有反映。
插入事务操作可以在录制过程中进行， 也可以在录制结束后进行。LoadRunner 运行在
脚本中插入不限数量的事务。
具体的操作方法如下： 在需要定义事务的操作前面， 通过菜单或者工具栏插入。输入该事务的名称。注意： 事务的名称最好要有意义， 能够清楚的说明该事务完成的动作。插入事务的开始点后， 下面需要在需要定义事务的操作后面插入事务的“ 结束点”。同样可以通过菜单或者工具栏插入。默认情况下， 事务的名称列出最近的一个事务名称。一般情况下， 事务名称不用修改。事务的状态默认情况下是LR_AUTO。一般情况下， 我们也不需要修改， 除非在手工编写代码时， 有可能需要手动设置事务的状态。
插入集合点
插入集合点是为了衡量在加重负载的情况下服务器的性能情况。在测试计划中， 可能会
要求系统能够承受1000 人同时提交数据，在LoadRunner 中可以通过在提交数据操作前面加入集合点， 这样当虚拟用户运行到提交数据的集合点时，LoadRunner 就会检查同时有多少用户运行到集合点，如果不到1000 人，LoadRunner 就会命令已经到集合点的用户在此等待， 当在集合点等待的用户达到1000 人时，LoadRunner 命令1000 人同时去提交数据， 从而达到测试计划中的需求。
注意： 集合点经常和事务结合起来使用。集合点只能插入到Action 部分，vuser_init 和vuser_end 中不能插入集合点。具体的操作方法如下： 在需要插入集合点的前面， 通过菜单或者工具栏操作输入该集合点的名称。注意： 集合点的名称最好要有意义， 能够清楚的说明该集合点完
成的动作。
插入注释
注释的作用就不多说了， 不过插入注释最好是在录制过程中。具体的操作方法如下： 在需要插入注释的前面， 通过菜单或者工具栏操作
参数化输入
如果用户在录制脚本过程中， 填写提交了一些数据， 比如要增加数据库记录。这些操作
都被记录到了脚本中。当多个虚拟用户运行脚本时， 都会提交相同的记录， 这样不符合实际的运行情况， 而且有可能引起冲突。为了更加真实的模拟实际环境， 需要各种各样的输入。参数化输入是一种不错的方法。
用参数表示用户的脚本有两个优点：
① 可以使脚本的长度变短。
② 可以使用不同的数值来测试你的脚本。例如， 如果你企图搜索不同名称的图书， 你
仅仅需要写提交函数一次。在回放的过程中， 你可以使用不同的参数值， 而不只搜索一
个特定名称的值。
参数化包含以下两项任务：
① 在脚本中用参数取代常量值。
② 设置参数的属性以及数据源。
参数化仅可以用于一个函数中的参量。你不能用参数表示非函数参数的字符串。
另外， 不是所有的函数都可以参数化的。
参数化输入的讲解， 我们采用一个例子的方式来进行。
在本例中我们参数化用户的登陆名：
先看如下脚本，通过脚本录制找到用户登陆部分，如图
参数名随意取，建议取通俗易懂的名字，下面我们重点介绍一下参数的类型。
●DateTime： 很简单， 在需要输入日期/时间的地方， 可以用DateTime 类型来替代。
其属性设置也很简单， 选择一种格式即可。当然也可以定制格式。
.●Group Name：暂时不知道何处能用到，但设置比较简单。在实际运行中，LoadRunner
使用该虚拟用户所在的Vuser Group 来代替。但是在VuGen 中运行时，Group Name
将会是None
.●Load Generator Name： 在实际运行中，LoadRunner 使用该虚拟用户所在Load Generator 的机器名来代替。
.●Iteration Number： 在实际运行中，LoadRunner 使用该测试脚本当前循环的次数来
代替。
.●Random Number： 随机数。很简单。在属性设置中可以设置产生随机数的范围
.●Unique Number：唯一的数。在属性设置中可以设置第一个数以及递增的数的大小。
注意： 使用该参数类型必须注意可以接受的最大数。例如： 某个文本框能接受的
最大数为99。当使用该参数类型时， 设置第一个数为1， 递增的数为1， 但100 个
虚拟用户同时运行时，第100 个虚拟用户输入的将是100，这样脚本运行将会出错。
注意： 这里说的递增意思是各个用户取第一个值的递增数， 每个用户相邻的两次循
环之间的差值为1。举例说明： 假如起始数为1， 递增为5， 那么第一个用户第一
次循环取值1， 第二次循环取值2； 第二个用户第一次循环取值为6， 第二次为7；
依次类推。
●Vuser ID： 设置比较简单。在实际运行中，LoadRunner 使用该虚拟用户的ID 来代
替，该ID 是由Controller 来控制的。但是在VuGen 中运行时，Vuser ID 将会是–1。
File： 需要在属性设置中编辑文件，添加内容，也可以从现成的数据库中取数据（ 下
面我们将会介绍）
●User Defined Function： 从用户开发的dll 文件提取数据。就目前我认为， 这种方式
没有必要。VuGen 支持C 语言的语法，在VuGen 中重新编写类似的函数应该不难。
上面的例子中， 我们取随机数即可。点“Properties… ..” 按钮， 进行属性设置窗口
添入随机数的取值范围为（1-50）， 选择一种数据格式。在“属性” 中有以下几
个选项：
◆Each Occurrence：在运行时， 每遇到一次该参数， 便会取一个新的值
◆Each iteration：运行时， 在每一次循环中都取相同的值
◆Once：运行时， 在每次循环中， 该参数只取一次值
这里我们用的是随机数， 选择Each Occurrence 非常合适。
下面我们再介绍用数据库中的用户名来参数化登陆用户名。
框选住登陆名，点鼠标右键，弹出对话框，选择“替换为新参数”弹出对话框，此时参数名输入：name，参数类型选择File，如图
注意： 参数的文件名不要使用con.dat、pm.dat 或者lpt*.dat 等系统装置名下面我们将会连接数据库， 从数据表中选择用户名。点“数据向导” 按钮，显示如图
添入连接字符串， 点“创建” 按钮，选择事先配置好的ODBC连接。在SQL语句里输入select查询语句，出现如图窗口
提醒： 在参数数据显示区， 最多只能看到100 行， 如果数据超过100 行， 只能点“编辑” 按钮， 进入记事本看。
“选择下一行 ” 有以下几种选择：
●Sequential： 按照顺序一行行的读取。每一个虚拟用户都会按照相同的顺序读取
●Random： 在每次循环里随机的读取一个， 但是在循环中一直保持不变
●Unique ： 唯一的数。注意： 使用该类型必须注意数据表有足够多的数。比如Controller 中设定20 个虚拟用户进行5 次循环， 那么编号为1 的虚拟用户取前5 个数， 编号为2 的虚拟用户取6-10 的数， 依次类推， 这样数据表中至少要有100 个数据， 否则Controller 运行过程中会返回一个错误。
“按编号”指选择列表中的那一列数据，从左到右分别是1、2、3依次
通常用在有关联性的数据上面。我们这里取值Sequential 即可。完成设置关闭即可
4.3 单机运行测试脚本
经过以上的各个步骤后， 脚本就可以运行了。运行脚本可以通过菜单或者工具栏来操作。
执行“ 运行” 命令后，VuGen 先编译脚本， 检查是否有语法等错误。如果有错误，VuGen
将会提示错误。双击错误提示，VuGen 能够定位到出现错误的那一行。为了验证脚本的正
确性， 我们还可以调试脚本， 比如在脚本中加断点等， 操作和在VC 中完全一样， 相信大家谁都不会感到陌生。如果编译通过， 就会开始运行。然后会出现运行结果。