LoadRunner的Web（HTTP/HTML）协议脚本开发录制引擎提供了两种脚本生成方式：HTTP/HTML方式（HTML-based script） 和 URL方式（URL-based script）。看似只是录制选项的差别，但决定了脚本的结构、易读性、后期维护成本，以及能否完整捕获所有需要压测的请求。

1. 原理差别：模拟浏览器分析和纯网络流量记录

HTTP/HTML方式 并不是简单地记录浏览器发出的请求，而是让VuGen的录制引擎扮演一个简化的HTML分析器。当录制一段操作时，每加载一个主页面（一般是对HTML文档的请求），引擎就会分析服务器返回的HTML源码，从中提取出图片、样式表、脚本、iframe等静态资源的引用，并自动为这些资源生成对应的请求。脚本以用户操作/页面为基本单位来组织：访问一个页面，脚本中可能由一个主请求和如果干子资源请求组成，虽然在代码方面仍是独立的web_url函数，但在思路上被包裹在同一个步骤上下文中，且子请求会被自动标记为Resource=1，代表它是页面依赖资源。

URL方式则完全放弃了对HTML内容的分析。录制引擎工作在更底层的Socket级别，像网络嗅探器一样记录下浏览器发出的每一个HTTP请求，不管它是由HTML分析触发的，还是由JavaScript异步调用、动态脚本标签插入、甚至是浏览器后台服务发起的。所有请求-HTML页面、API接口、图片、CSS、JS文件-都被以完全等同的、扁平的方式记录下来，没有任何页面归属或主资源/子资源的方面概念。

2. 脚本结构的直观对比

假设我们访问一个简单的页面index.html，该页面引用了1个CSS和2张图片。

在HTTP/HTML方式下，脚本大致如下：

一个web_url获取index.html，并设置Resource=0，表示这是页面的主资源。

紧接着三个web_url调用，分别请求style.css、logo.png和banner.png，这些请求都被标记为Resource=1。所有请求顺序执行，但你很容易看出它们和主页面的从属关系。

而在URL方式下，脚本会是四个完全扁平的web_url请求，依次列出完整的URL，没有任何层级标记。一个简单的页面访问就会展开成多条并列的请求，如果页面复杂、动态请求多，脚本会变得极其冗长，难以分辨哪些是主要业务请求，哪些是无关紧要的埋点或广告资源。

3. 深入对比

请求捕获的完整性

HTTP/HTML方式由于依赖内置的HTML分析器，无法执行JavaScript。这意味着所有由JS动态生成的请求-比如Ajax调用、fetch API发起的异步数据请求、通过动态创建<img>或<script>标签加载的资源、单页应用（SPA）的路由切换请求-都极有可能被遗漏。这些漏掉的请求往往是系统的重要API，不录制进去测试就毫无意义。而URL方式直接抓取网络层的全部HTTP流量，除非流量本身被加密且未正确代理，否则几乎不会丢包，对重度JavaScript应用和SPA有天然的完整性优势。

脚本的可读性和维护性

HTTP/HTML方式以页面步骤为骨架，脚本结构清晰，能直接对应到业务操作（如“登录”、“搜索”、“提交订单”）。引入事务、检查点、参数化都非常直观，后期维护时增删一个页面操作也相对简单。URL方式则将所有请求摊平，一个“搜索”动作可能产生30个以上的web_url调用，没有思路分组，读脚本就像查看网络日志，维护成本很高。

负载模拟的真实性

两种方式在默认情况下都是串行执行所有请求，并不能完全模拟现代浏览器对同一个域名的6-8个并发连接。但HTTP/HTML方式可以通过运行时设置（Runtime Settings）中的“模拟浏览器缓存”、“每次迭代模拟一个新用户”等选项，更好地重现浏览器的缓存行为。URL方式由于你手动控制每一个请求，可以更精细地调整资源请求的时机和并发度，甚至可以单独为某些请求编写异步思路，但需要非常高的手工编码技能。

适用范围

HTTP/HTML方式要求被测对象是一个返回HTML内容的Web页面，它必须有“页面”的概念。如果你在测试一个纯HTTP API服务（如微服务接口、移动端后端、Restful服务），根本没有HTML可分析，录制出来会是空的或者残缺的，此时必须使用URL方式。同样，如果你的应用包含大量非浏览器标准的HTTP交互（比如自定义TCP上的HTTP隧道、WebSocket握手请求等），URL方式是唯一能完整捕获的选择。

4.选择指南

面对不同的测试场景，你可以按以下思路进行选择：

如果测试的是传统的服务器端渲染网站，以页面跳转为主，JavaScript仅用于简单交互：优先选择HTTP/HTML方式。它的可维护性优势远大于偶尔遗漏一两个无关紧要的JS请求的风险，并且后期补充起来也方便。

如果被测系统是单页应用（SPA），大量使用Vue/React/Angular等框架，页面内容由异步API动态填充：强烈建议使用URL方式。先用URL方式录制完整的API请求列表，然后利用VuGen的过滤功能去掉不必要的静态资源请求（如图片、CSS），保留JSON数据接口，从而得到一个干净、完整的业务API测试脚本。

如果被测对象是一个纯后端服务或移动端API，没有网页界面：必须使用URL方式。此时根本不存在HTML上下文，HTTP/HTML方式没有分析的基础，只会生成空脚本。

如果需要高度控制每一个资源的加载，如测试图像CDN性能、或对某个特定CSS文件做压力：选择URL方式，它可以让你独立操作每一个资源请求。

如果希望快速生成能跑通且易于理解的脚本：从HTTP/HTML方式开始，发现遗漏后，再去录制设置中切换到URL方式重录一次，将缺失的请求手工复制到原脚本中。

如果面对一个混合型应用，或者不确定缺漏程度：推荐采用“先HTML后补全”的方法。用HTTP/HTML方式录制，回放时在浏览器开发者工具中对比Network请求列表，如果发现有重点的异步请求没有被录下来，就使用URL方式单独录制那部分操作，提取相应web_url函数，并将其以Resource=0（因为它是独立业务请求而不是页面资源）的形式插入到HTTP/HTML脚本的适当位置。这样就能兼得清晰结构和完整请求。

5. 实战技巧

静态资源过滤：如果用了URL方式得到一大堆图片、CSS、JS请求，可以进入Recording Options的Filter设置，定义排除规则，比如排除所有包含.png, .css, .js的URL，或者只保留指定域名的请求。这能立刻让脚本聚焦于业务动态请求。

运行时设置里的“Simulate browser cache”：对HTTP/HTML方式尤其重要，启用后每个虚拟用户会模拟浏览器缓存行为，避免在每次迭代中重复下载不变的资源，使负载更真实。

两种方式不能直接转换：如果你已经用HTTP/HTML方式生成脚本，不能通过设置切换自动变成URL方式脚本。必须重新录制，但可以将两个脚本的请求代码融合，用web_custom_request按需组合。

一致性检查：不管使用哪种方式，录制完成后必须在VuGen中多次回放，并配合代理工具（如Fiddler）或服务器日志，确定所有重点请求都被发送且响应正确。

HTTP/HTML方式以可维护性优先，牺牲了部分请求完整性；URL方式以完整性优先，牺牲了脚本的可读性。 选择的重点是被测应用类型-它是页面主导还是API主导，是服务器渲染还是客户端渲染。现代混合架构最好的往往不是二选一，而是以HTTP/HTML为框架，利用URL方式的录制片段来修补动态异步请求，获得一个既清晰又准确的性能测试脚本。