企业官网建设流程全解析

想学性能测试的人，很多都卡在同一个地方：有工具、没环境，连一个能用来练手的被测系统都找不到。我最早接触性能测试时，也是在环境搭建上绕了很远的路，后来才发现 LoadRunner 自带的那套示例应用 WebTours，才是最适合新手入门、也最适合老手回归的靶场系统。这篇避坑版教程，就是把我从零搭建这套测试环境的完整过程写出来，从版本选型、服务安装、浏览器配置到脚本验证，每一步都给出可复现的操作，顺带把官方文档里绝对不会写的坑也一并排掉。文章比较长，如果你时间紧，可以直接跳到第6章的速查表，出了什么问题对照着查就行；如果你是第一次搭，建议从头到尾看一遍，能省下好几个晚上的折腾时间。

1. WebTours到底是什么：先搞清楚你在装什么

1.1 为什么选它当测试靶场

我不知道你是不是和我一样，最开始学性能测试的时候，最大的困扰不是看不懂脚本，而是手里没有一个“正常”的应用可以测。拿公司线上系统测，不敢乱压；自己写个 Demo，又丑又不真实，连登录、查询、下单这些基本流程都要自己维护，还没开始学压测，先写了一堆业务代码。而 LoadRunner 安装包里附带的 WebTours 示例服务，恰好解决了这个问题：它是一个完整的航班预订 Web 应用，有登录、航班查询、预订机票、退票这一连串真实业务动作，数据存在本地文本格式的数据库文件中，可以随便改、随便造。对做性能测试的人来说，它就是一个最接近真实业务、又不带任何生产风险的靶场。

更关键的是，WebTours 背后的设计意图，其实就是给 LoadRunner 用户做演示用的。你在这套应用上练会的技能，比如用户参数化、会话关联、事务响应时间分析，到了真实项目里几乎可以直接平移。很多人觉得它“老掉牙”，但性能测试的核心要素几十年没变，真正变的是工具界面和部署方式。拿它做练习，反而是效率最高的。

1.2 服务内部是怎么拼起来的

WebTours 表面看是一个网页，实际上由三部分协作组成：一个 Apache Web 服务器负责接收浏览器发来的 HTTP 请求；一组用 Perl 编写的 CGI 程序处理登录、查询、订票这些业务逻辑；一组文本数据文件充当“数据库”，记录用户账号、航班记录和订单数据。搭建这套环境的本质，就是把这三部分正确放到一台 Windows 机器上，让它们按预定的方式互相通信。

理解这个结构对排错特别有帮助。比如你启动完服务、浏览器却打不开页面，第一反应不应该是重装环境，而是先看那个命令行窗口还在不在、端口有没有被占用；如果页面能打开但登录没有反应，那多半是 CGI 处理环节出了问题，要检查 Perl 相关文件或数据文件权限。把问题拆到具体组件上，排查速度会快非常多。

1.3 版本选择与授权认知

很多新手一上来就找最新版 LoadRunner 安装，结果装完发现脚本录不了、界面和教程对不上、插件装不上，折腾两天还没进入正题。以我自己的经验，在纯学习环境里，优先选择资料最多、生态最成熟的版本序列，而不是最新的。早期的 12.55、12.60 是很多老教程的标配，网上课件、视频、提问记录都非常丰富，遇到问题一搜就能找到答案；之后的 2021、2023 功能更现代，但对操作系统位数、补丁要求也更苛刻，适合已经有一定基础、想了解新特性的同学。至于 WebTours 服务本身，它不依赖很新的环境，在大多数 Windows 系统上都能正常运行。

授权方面也需要提前确认。LoadRunner 是商用工具，WebTours 虽然跟随安装包附带，但全套压测能力必须有合法授权才能启用。学习场景可以用官方提供的试用授权，或者公司在采购时申请的实验室授权。这里要提醒一句，不要自己去网上找乱七八糟的破解包，这不仅涉及法律风险，破解包里有没有木马谁也没法保证，安装前先把授权方案准备好，比什么都重要。

1.4 为什么建议用 Windows 原生进程而不是容器

现在很多新工具都习惯用容器部署，我见过不少同学一上来就问 WebTours 有没有 Docker 镜像。客观说，社区里确实有人做过容器化版本，但版本混乱、依赖不完整，而且 WebTours 这套老程序依赖 Windows 批处理调度和多个进程协作，容器里要处理工作目录、信号传递非常别扭，经常出现容器起来了、端口也映射了，但页面里查不到航班数据这种诡异问题。

我的建议是，学习初期尽量用 Windows 原生进程，直接双击启动，当前目录、环境变量、文件权限都由系统原生处理，问题会少很多。等你把整套逻辑跑通了，以后想封装成自动化环境再研究容器化也不迟。学习阶段最重要的原则是减少变量，哪个方案最省心就用哪个。

2. 环境准备：动手装之前先避开三个坑

2.1 虚拟机与系统选型

我强烈建议第一次搭建这套环境时，不要在你自己日常办公的笔记本上直接装。没有单独的物理测试机，用虚拟机最合适。常用的虚拟机软件（比如 VMware Workstation 或 VirtualBox）里建一台 Windows Server 2016 或 Windows 10 企业版 LTSC 的虚拟机。选服务器系统是因为后续要模拟多用户并发，服务器版的网络任务调度更稳定；选 LTSC 是因为它没有商店、没有频繁的自动更新，不会在你压测压到一半的时候突然通知重启。

虚拟机的硬件配置不用高，双核 CPU、4G 内存、40G 磁盘足够了。WebTours 本身是非常轻量的应用，吃资源的大头是运行脚本生成压力的 LoadRunner 主机，这一点要有数，别把资金浪费在被测虚拟机配置上。装好系统之后，顺手做一次系统更新和磁盘清理，保持一个干净的基础环境，后面出问题的概率会小很多。

2.2 安装顺序与杀毒软件处理

安装顺序建议是：先装操作系统，再装 LoadRunner 完整客户端，然后从安装包中找到 WebTours 独立安装部分完成部署。为什么按这个顺序？因为 LoadRunner 安装过程中会检查很多前置组件，WebTours 不少文件也依赖这些组件。你先装 WebTours、后装 LoadRunner，不是完全不行，但可能某些动态链接库版本不对，后面录制脚本时会出现难以解释的问题。

另一个非常关键的步骤，是在所有安装开始之前，把系统的杀毒软件、Windows Defender 实时保护全部临时关闭，或者把安装目录加入白名单。这个问题我踩过不只一次：WebTours 启动脚本运行的进程，在很多杀毒软件眼里就是典型的无签名可执行文件，经常把关键文件隔离掉，服务起不来，处理方式还出奇一致——要么恢复文件，要么重装。不如一开始就把目录信任掉，省得后面排查半天。

2.3 安装路径的选择，直接影响你后面是否顺利

安装 LoadRunner 和安装 WebTours 时，目标路径都不要带中文、空格和特殊字符。我知道很多人喜欢自定义目录，比如建一个“D盘\性能测试工具”这样的文件夹，看起来挺整齐，可这套老架构的程序在解析路径时经常出问题，脚本文件一多、路径一长，就会报找不到文件、无法启动服务之类的错误。最稳的方法是用默认路径，或者用一个像 D:\LR 这样纯英文短路径。

如果你已经装在带空格的路径里，我的建议是别想着修复，直接卸载重装。因为后面 WebTours 启动脚本、Apache 配置、录制脚本之间的路径引用是一环扣一环的，某一步没同步改到位，就会出现服务端能启动、但页面资源加载不了这种状态，排查成本远比重装高得多。这个坑我在早期踩过一次，后来凡是装这套环境，一律短路径纯英文，再没出过路径相关的问题。

2.4 网络规划：固定IP与防火墙端口的提前确认

WebTours 服务默认监听 1080 端口，这在你装好之后必须心里有数。安装前，先给虚拟机配置一个固定 IP。方法是在网络适配器设置里关闭自动获取，手动填一个和宿主机同一网段的地址，避免 DHCP 每隔一段时间换一次 IP，导致后面对应的地址全失效。如果只是本机学习，NAT 模式就够用；如果准备用另一台主机专门跑 Controller 生成压力，桥接模式更直观，网络互通更容易理解。

防火墙端口这件事也建议提前处理。很多 Windows 版本默认拦截外部访问，导致服务所在机器页面能打开，但另一台机器访问不了。测试环境中最直接的做法是把 Windows 防火墙暂时关闭，或者只对 1080 端口放行。先明确自己是哪种使用场景，再决定怎么做，不要装完环境才发现压测主机连不上服务，白折腾一场。

3. 服务安装与初始化：从安装目录到能正常访问

3.1 找到入口并开始安装

WebTours 随 LoadRunner 一起发布，不同版本的安装方式会略有差异。有的版本里，它作为独立安装包放在 LoadRunner 安装镜像的某个子目录；有的版本在安装 LoadRunner 时有单独的勾选项。你可以先确认自己手里的安装包里有没有标记为 WebTours 或 Samples 的目录，有的话就按里面的安装说明执行，没有的话就回到 LoadRunner 安装向导，勾选示例应用部分。

安装过程本身没什么特殊的，一路下一步即可，但有一点要注意：安装完成时，安装程序会生成两个桌面快捷方式或开始菜单入口，一个叫 Start WebTours，一个叫 Stop WebTours。这两个入口保留好，以后你几乎每天都会和它们打交道。虽然也可以去目录里找底层批处理文件直接点击，但我建议用快捷方式，因为里面可能封装了环境变量设置，直接跑底层文件可能因为当前目录不对而失败。

3.2 启动服务与第一次访问

双击 Start WebTours，屏幕会弹出两个命令行窗口，一个写着 Apache 相关字样，一个运行着 WebTours 服务进程。这两个窗口不能关，最小化可以，关掉就等于把服务停了。等窗口里出现类似端口监听成功、等待请求的提示后，打开浏览器输入 http://localhost:1080/webtours/ 进行验证。

如果页面能显示出 WebTours 的入口界面，说明服务已经基本正常。接下来用默认账号登录，大多数版本内置的可用用户是 jojo 和 bean，用户名和密码分别填 jojo、bean，登录后能看到一个包含航班查询入口的页面，就说明登录链路也通了。后续要做的测试脚本、压测任务，都是在这个基础上展开的。第一次访问如果看到证书警告，先不用慌，第4章会专门讲证书处理。

3.3 用户数据与页面数据都在哪

WebTours 的用户数据放在安装目录下一个文本格式的数据文件里，每行是一个用户，字段用斜杠分隔。这意味着你可以用记事本打开它，手动追加账号。追加完保存文件，重启 WebTours 服务，新用户就可以登录了。这个特性在做用户名参数化时非常有用，因为它省去了通过页面批量注册的麻烦，写几行数据就能生成一批账号，这在压测场景里简直是提升效率的利器。

页面数据则存放在 webtours 相关的 HTML 和资源目录里。有人会去改页面文案和样式，想让靶场看起来更清爽，这个想法可行，但要提醒一句：性能测试关注的是业务流程和响应时间，花太多时间改页面样式，对学习本身帮助不大。不如把时间花在登录、查询、订票这几个核心事务的脚本编写和关联练习上，那才是真正会带到工作中的技能。

3.4 初始化业务数据：让场景更像真实业务

WebTours 自带的航班数据数量有限，反复跑同一批数据，容易出现重复预订、库存不足这类边界情况。更合理的做法是打开数据文件查看格式，手动往里面加一批航班记录和用户记录，让每次压测的数据更丰富。修改前备份原文件，修改后用页面登录验证新数据能查到，确保格式没有写错。

这一步看似麻烦，但很有意思，它模拟了真实性能测试项目里的“基础数据准备”环节。在公司做压测时，测试环境里的用户、订单、商品数据往往也需要提前构造，数据量和分布直接影响压测结果。你在 WebTours 上提前练一练这套思路，以后面对真实环境时就不会毫无概念。

4. 浏览器与录制环境配置：这里是新手最容易卡住的部分

4.1 为什么浏览器设置比服务安装还麻烦

服务装得好好的，页面也能打开，但一进 VUGEN（LoadRunner 的脚本录制工具）准备录制就会出各种状况，要么浏览器打不开，要么打开了录不到请求，要么录了半天导出脚本是空的。这些问题十有八九出在浏览器和证书配置上。WebTours 默认支持 HTTP 访问，但部分功能在录制时会涉及 HTTPS 证书校验，如果你的系统没有把 WebTours 的证书导入受信任的根证书颁发机构，录制过程就会频繁出现连接中断、页面报错，脚本自然录不全。

处理方式分两步。第一步，用浏览器访问一次 HTTPS 版 WebTours，把证书按提示导出并安装到本机“受信任的根证书颁发机构”存储区。安装时注意选择当前用户还是本地计算机，建议选本地计算机，这样录制工具的进程也能读到。第二步，根据 VUGEN 使用的录制内核配置浏览器兼容性，老版本基于 IE 内核时，要把 WebTours 加入本地 Intranet 区域并开启兼容性视图；新版本使用 Chromium 内核时不再依赖 IE，但证书导入依然是必需操作。

4.2 录制前的基础检查清单

录制之前，我建议按顺序做一遍检查，每项都不难，但漏掉任何一项，都会在后续录制阶段以各种形式冒出来：

• 关闭 IE 增强安全配置。尤其是 Windows Server 系统，默认开着增强安全设置，不关的话访问网页各种弹窗，录制过程会被频繁打断。
• 清空浏览器缓存和历史记录，避免把历史请求一起录进脚本。
• 确认 VUGEN 中可以正常打开浏览器。点击录制后浏览器没反应，多半是默认浏览器路径配置不对，需要手动指定浏览器可执行文件。
• 确认目标服务没有被防火墙拦截。在虚拟机上测试时，至少放行 1080 端口，否则 VUGEN 或 Controller 访问不到服务。

这些检查看起来琐碎，但能帮你把录制阶段很多“莫名其妙”的问题提前扼杀掉。我见过不少同学花了半小时在 VUGEN 里调设置，最后发现只是浏览器的增强安全配置没关。先做检查清单，再碰工具配置，顺序很重要。

4.3 最容易忽略的登录会话关联

录脚本时你会发现，WebTours 登录成功后，页面地址或 Cookie 里会出现一段动态变化的会话标识。这是服务端生成的临时会话 ID，下一次请求就变了。如果你录完脚本直接回放，第一次可能成功，第二次大概率失败，因为回放时还带着第一次录下来的旧标识，服务端一看会话不合法，直接返回错误。

处理办法是做关联。把脚本里动态变化的会话标识用函数替换成动态获取的值，具体逻辑是：从服务端响应中提取新 ID，再传给后续请求使用。这几乎是每个学习 WebTours 的人都会遇到的第一个关联练习，也是这套环境最有价值的学习点之一。你在 WebTours 上把关联逻辑彻底弄明白，以后处理各种动态令牌、Session 参数就都能举一反三。

4.4 老版本与新版VUGEN的录制模式差异

不同版本 VUGEN 的录制内核差异很大，这也是最容易踩坑的地方。老版本录制依赖 IE 浏览器，很多同学把系统默认浏览器改成了 Chrome，点击录制后直接报错，必须先手动把 IE 设为默认浏览器，再在 VUGEN 里选择对应的浏览器配套模式。新版本录制内核换成 Chromium 后，对 WebTours 这种简单站点反而更友好，打开即录，不用折腾默认浏览器，但要注意新建脚本时不要选错协议模板，走通用的 Web - HTTP/HTML 模板就够了。

版本差异经常导致同一套操作在不同机器上表现完全不同，这很正常。遇到和教程里对不上的界面或功能，优先去查自己当前版本对应的官方文档，而不是照着老教程硬填。我见过太多人因为这点浪费时间，最后还是回到“先确认版本再查资料”这条路上。

5. 脚本验证与压测联调：确认环境真的能扛住

5.1 录制完先回放，别急着上 Controller

录完脚本，先做单脚本回放。回放通过的标准很简单：在 VUGEN 的树形图里能看到登录成功、查询成功的有效响应，没有红色报错；回放日志里没有明显的 HTTP 500 或超时信息。如果回放失败，先看错误发生在第几个请求，再对照录制时的操作步骤，确认是关联没做，还是参数化数据问题。

回放这一步很容易被跳过，尤其是时间赶的时候。但我建议无论如何都别省，因为一个连回放都过不了的脚本，拿去压测只会得到一堆无效结果，运气好是客户端报错，运气不好是压了一堆根本没登进去的“伪并发”，数据全白跑。多花十分钟回放一遍，能省掉后面几小时的无效劳动。

5.2 改端口与确认配置的一致性

如果你本机 1080 端口与其他应用冲突，就需要给 WebTours 换端口。换端口的操作不复杂，但要改得完整：先把服务停掉，然后用记事本打开启动脚本和相关配置文件，全局搜索 1080，把所有出现端口的地方统一改成同一个新端口，再启动服务验证。只改其中一个文件，就会出现服务看起来起来了、但浏览器输入新端口访问不到，或者服务监听的是新端口、页面内部跳转还指向旧端口的半通不通状态。

改完端口后，重新录制一遍脚本并回放，确认所有请求地址都指向新端口。这里有个非常实用的细节：如果之前录制的脚本里写的是旧端口，回放时所有请求都会发到错误地址，报错还不好定位。我个人的习惯是，在脚本里把端口单独提出来设置成一个变量，以后换环境、换端口，只改一处就行，不用重新录制。

5.3 用 Controller 做一次最小的并发冒烟

最后一步，用 Controller 验证整套压测链路。把回放通过的脚本挂到 Controller 的场景里，设计一个最简单的测试场景：初始 10 个用户、每 10 秒增加 5 个、持续运行几分钟，然后观察事务响应时间、吞吐量、错误率三项指标。只要这三项曲线正常，没有大面积报错，就说明从 LoadRunner 到 WebTours 的完整测试链路已经通了，这套环境可以正式投入使用。

第一次跑这种冒烟测试时，我还习惯把被测虚拟机的资源监视器打开，等压测结束后对比一下 CPU、内存、磁盘 IO 的变化。这个习惯看起来简单，但能帮你在以后分析真实系统性能瓶颈时，更早地把压力结果和系统资源关联起来。性能测试如果只看响应时间不看资源占用，很多时候看不出瓶颈在哪。

5.4 Agent 连接与远程压力的规划

单机学习时，Controller 默认使用本机 Agent 就能工作，几乎不需要额外配置，这也是我第一次搭建时偷懒跳过的一块。但如果 Controller 和被压服务分开，就需要先在被压机器上启动 LoadRunner Agent 进程，再在 Controller 里配置 Agent 地址为被测机 IP，同时保证防火墙允许 Agent 相关端口通信。

很多人是在分布式压测时才第一次接触 Agent 概念，WebTours 环境刚好提供了一个低成本的联调机会。建议先在同一台机器上验证 Agent 能正常连接、脚本能分发到目标机，再扩展到远程机器。这套流程跑通了，以后在公司做多负载机压测时就不会手忙脚乱。序列别搞反，先本机后远程，一步步来。

6. 高频问题排查速查表

6.1 我整理的高频问题速查表

这些年帮不少同行排查过这套环境，问题翻来覆去都集中在几个点上，我整理成一张速查表，方便你遇到的时候直接对号入座：

这张表覆盖了 90% 的入门场景。真正遇到表里没有的情况，我的建议是先看日志，服务端有 Apache 的错误日志，VUGEN 有回放日志，先把日志时间范围缩小到问题发生的那几秒，通常就能定位到具体请求。日志永远是排错的第一抓手，别凭感觉瞎猜。

6.2 我后来养成的几个操作习惯

环境折腾多了，我慢慢总结出几个让操作更省心的习惯。第一，做完任何一个配置变更之前，先给虚拟机做一个快照。WebTours 这套老环境的配置文件特别敏感，改错一个符号可能整晚都修不回来，有了快照，一秒钟就能回到改之前的状态，这个习惯尤其在尝试新配置时能救命。第二，每次压测前把测试脚本、场景参数、系统资源截图这三样东西放进同一个以日期命名的文件夹，方便后续复盘，时间长了会发现这个文件夹就是性能测试的历史档案库。第三，遇到问题先怀疑最简单的可能，端口、防火墙、证书，这三样检查完再动数据文件和脚本。

这些习惯看起来琐碎，但能在你真正投入性能测试工作后，减少大量重复排查。环境本身只是一个起点，真正有价值的是你在这个起点上建立起来的调试思路和操作规范。

我搭这套环境前前后后踩了不知道多少个坑，现在回看，最大的体会其实是：WebTours 虽然老，但它把所有性能测试需要用到的核心要素都浓缩在了一个轻量应用里。把登录、查询、订票这些事务跑通，你在真实项目中面对同类场景，思路基本上不会变。尤其值得提醒的是，一开始就花五分钟把端口、证书、浏览器、防火墙这四件事理清楚，后面的录制和压测会顺畅很多。如果你按这篇流程走完后在某个细节上卡住，先回头检查这四件事，大概率就在其中。真遇到我这边没写到的报错，也欢迎分享出来互相补全，毕竟环境这东西，一个人踩过的坑，足够让后来的人少走好大一段路。