想学性能测试的人很多都卡在同一个地方有工具、没环境连一个能用来练手的被测系统都找不到。我最早接触性能测试时也是在环境搭建上绕了很远的路后来才发现 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 为什么浏览器设置比服务安装还麻烦服务装得好好的页面也能打开但一进 VUGENLoadRunner 的脚本录制工具准备录制就会出各种状况要么浏览器打不开要么打开了录不到请求要么录了半天导出脚本是空的。这些问题十有八九出在浏览器和证书配置上。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 我整理的高频问题速查表这些年帮不少同行排查过这套环境问题翻来覆去都集中在几个点上我整理成一张速查表方便你遇到的时候直接对号入座现象可能原因解决步骤双击 Start WebTours 后窗口一闪即逝杀毒软件拦截进程、依赖组件缺失关闭杀毒或加入白名单查看系统事件日志确认缺失组件端口已监听但浏览器打不开页面防火墙拦截、访问地址写错关闭防火墙或放行端口确认地址和端口与配置一致页面能打开但登录后无反应CGI 处理环节故障、数据文件被改动检查数据文件格式和权限确认 Perl 相关文件完整录制时浏览器不启动VUGEN 默认浏览器路径错误在 VUGEN 设置里手动指定浏览器可执行文件路径录制结束脚本为空浏览器内核不兼容、代理未生效关闭增强安全配置清缓存按录制内核调整兼容设置回放日志出现大量 500 错误会话关联未做、URL 端口写死做会话关联把端口提取为变量统一管理新加用户无法登录数据文件格式错误、服务未重启按原格式逐字符核对数据行保存后重启 WebTours 服务这张表覆盖了 90% 的入门场景。真正遇到表里没有的情况我的建议是先看日志服务端有 Apache 的错误日志VUGEN 有回放日志先把日志时间范围缩小到问题发生的那几秒通常就能定位到具体请求。日志永远是排错的第一抓手别凭感觉瞎猜。6.2 我后来养成的几个操作习惯环境折腾多了我慢慢总结出几个让操作更省心的习惯。第一做完任何一个配置变更之前先给虚拟机做一个快照。WebTours 这套老环境的配置文件特别敏感改错一个符号可能整晚都修不回来有了快照一秒钟就能回到改之前的状态这个习惯尤其在尝试新配置时能救命。第二每次压测前把测试脚本、场景参数、系统资源截图这三样东西放进同一个以日期命名的文件夹方便后续复盘时间长了会发现这个文件夹就是性能测试的历史档案库。第三遇到问题先怀疑最简单的可能端口、防火墙、证书这三样检查完再动数据文件和脚本。这些习惯看起来琐碎但能在你真正投入性能测试工作后减少大量重复排查。环境本身只是一个起点真正有价值的是你在这个起点上建立起来的调试思路和操作规范。我搭这套环境前前后后踩了不知道多少个坑现在回看最大的体会其实是WebTours 虽然老但它把所有性能测试需要用到的核心要素都浓缩在了一个轻量应用里。把登录、查询、订票这些事务跑通你在真实项目中面对同类场景思路基本上不会变。尤其值得提醒的是一开始就花五分钟把端口、证书、浏览器、防火墙这四件事理清楚后面的录制和压测会顺畅很多。如果你按这篇流程走完后在某个细节上卡住先回头检查这四件事大概率就在其中。真遇到我这边没写到的报错也欢迎分享出来互相补全毕竟环境这东西一个人踩过的坑足够让后来的人少走好大一段路。