本文将通过在示例应用程序 PhoneNumberMonitoring.com 上的实际测试场景，比较 LoadRunner 和 LoadView。测试流程很简单：
启动应用程序 → 登录 → 导航至某个标签页 → 登出
然而，这一流程在 LoadRunner 和 LoadView 中的实现方式却截然不同——尤其是在 设置工作量、灵活性、可扩展性以及真实世界模拟的准确性方面。
使用 LoadRunner：协议级强大功能但复杂度高
LoadRunner 提供了使用 VuGen（虚拟用户生成器） 的 深入协议级控制，支持 HTTP/HTML、SAP、Web 服务、TruClient 等协议。虽然这为企业级测试提供了灵活性，但即使是配置一个基础流程，所需的工作量也非常大。
在本次测试中，我们使用了 Web HTTP/HTML 协议，它适用于不需要完整浏览器渲染的网页应用。
我们在 LoadRunner 中做了什么
- 协议选择：选择 HTTP/HTML；但选择正确的录制模式（基于 HTML 或 URL）是一项关键决策，通常需要反复试验以确保脚本生成正确。
- 使用 VuGen 录制：配置端口映射（如截图所示）并选择捕获级别（例如 WinInet 或 Socket）——每种都有其特性。
- 关联设置：使用 web_reg_save_param_ex 和 JSON 路径手动提取动态会话数据。如果关联失败，测试也会失败——没有自动建议或 UI 提示。
- 参数化：使用 LoadRunner 的数据参数化工具替换硬编码的值。
- 思考时间与事务：用 lr_start_transaction() 包裹关键操作，并添加 lr_think_time() 模拟用户延迟。
- 会话处理：手动管理 Cookie 和自定义请求头。
- 高级逻辑：使用 C 语言添加 if-else、循环和自定义代码控制流程。
LoadRunner 的主要痛点与限制
尽管 LoadRunner 功能强大，但它存在 多个使用难点：录制复杂性
- 选择 基于 HTML 或 URL 的录制方式 往往影响脚本质量。
- 选择 WinInet 或 Socket 级别的捕获 会让初学者感到困惑——某些应用只能在特定模式下正确响应。
日志排错与调试
- LoadRunner 日志是 协议特定且常常难以理解——HTTP 日志、XML 转储和回放日志分散在多个标签页，实时分析困难。
- 无法实时回放用户会话——使得脚本回放出错时难以可视化排查问题。
协议相关的关联
- 每种协议（SAP、Oracle、HTTP 等）都需要 不同的关联方法。
HTTP/HTML 协议
web_reg_save_param、web_reg_save_param_ex、web_reg_save_param_json、web_reg_save_param_xpath（HTTP/HTML、Web 服务）、web_reg_save_param_attrib 等
SAP GUI 协议
sapgui_get_text、sapgui_select_active_window、sapgui_set_property、sapgui_get_property、sapgui_status_bar_set_text 等
Oracle NCA 协议
nca_set_window、nca_set_menu_item、nca_edit_set、nca_button_press、nca_get_text 等
Web 服务协议
web_custom_request、web_service_call 等
- 没有统一的关联框架——即使是 TruClient 也完全不同，并且不共享 HTTP 协议的关联逻辑。
性能与可用性
- TruClient 脚本 模拟浏览器行为，但系统资源消耗大，执行时间长。
- 可视化流程编辑器功能有限，调试失败时需在多个日志窗口和截图之间切换。
使用 LoadRunner 进行分布式负载测试的设置
- LoadRunner 需要 多个组件：VuGen 用于脚本编写，Controller 用于编排，Load Generators（LGs）用于分发。
- 需要 手动设置，包括防火墙规则、端口开放和网络配置。
- 扩展性与执行编排 增加了复杂性——不适合需要快速迭代的敏捷团队。
LoadRunner 适用于传统系统，但 不适合现代网页测试或敏捷开发。
使用 LoadView：简化的真实浏览器负载测试
LoadView 提供一种现代化方法，具有 云原生、基于浏览器的负载测试。它可模拟 真实用户在 Chrome 或 Edge 中的行为，不仅验证后端响应，还验证 真实前端性能（UX 指标）。
在 PhoneNumberMonitoring.com 上进行相同流程测试时，我们使用 EveryStep Recorder，不到 5 分钟就完成了测试设置——无需编码、无需配置、无需插件。
为什么使用 LoadView 变得轻松
- 像真实用户一样录制：只需点击、输入、滚动——就像真实用户操作一样。
- 无需关联：LoadView 自动捕获动态值（令牌、会话）。
- 支持完整 C# 脚本：对高级用户，LoadView 提供完整的 C# 编程能力，支持 循环、条件、变量声明等，自定义流程非常灵活。
示例：在内容验证失败时中止脚本执行
- 预设 Cookie 和请求头：可在执行前设置请求头、认证信息、Cookie 和用户代理，更准确地模拟真实场景。
- 新手友好，专家可控：简单录制即可开始使用，高级测试人员也可按需扩展功能，是简洁与强大兼具的稀有工具。
- 完整浏览器渲染：支持 SPA、AJAX、WebSockets——你看到的就是你测试的。
- 地理分布测试：可从 40+ 全球区域中选择模拟用户位置。
- 实时会话回放：你可以 逐步观看测试过程，包括页面渲染与输入操作——这是 LoadRunner 无法做到的。
- 前端性能指标：直接从报告中查看 LCP（最大内容绘制时间）、FCP（首次内容绘制）和 TTI（可交互时间）。
- 可视化流程编辑器：可视化修改任意步骤——无需编写代码或查看日志。
功能对比：LoadRunner vs LoadView
| 功能 | LoadRunner | LoadView |
| 录制选项 | 多种捕获级别（WinInet、Socket）、协议选择 | 一键浏览器录制 |
| 是否需要脚本 | 是 – 需要高级脚本、参数化、关联 | 否 – 无需脚本即可录制与运行 |
| 动态值处理 | 手动 – 按协议处理 | 自动关联 |
| 真实浏览器模拟 | 仅通过 TruClient（耗资源、慢） | 原生 Chrome/Edge |
| 前端性能指标 | TruClient 支持有限 | 全面支持（FCP、LCP、TTI） |
| 实时会话回放 | 不支持 | 支持 — 可回放 |
| 测试创建时间 | 45–90 分钟 | 5–10 分钟 |
| 日志分析 | 协议日志复杂，需手动关联 | 基于 UI 的步骤日志与截图 |
| 协议处理方式 | 根据应用类型不同（HTML、SAP、Oracle） | 统一录制所有网页流程 |
| 分布式测试 | 需要生成器与控制器 | 内置云执行 |
| 技能要求 | 高 – 需脚本编写与调试 | 低 – 商业用户亦可测试 |
| 成本与授权 | 昂贵的企业授权 | 透明、按使用计费 |
实际应用场景影响
| 使用场景 | LoadRunner | LoadView |
| 电商结账 | 需为异步令牌与 JS 延迟编写脚本 | 真实浏览器流程，验证用户体验 |
| 银行 仪表板 |
需深入关联与令牌跟踪 | 轻松模拟登录与导航到安全仪表板 |
| 地理负载模拟 | 每个地区需配置 LG | UI 内简便地理选择器 |
| 敏捷迭代测试 | 修改与重跑测试较慢 | 创建快速，易于复用 |
| 客户演示与 POC | 需设置并协调 | 录制并即时分享测试结果 |
最终总结
选择 LoadRunner 的理由：
- 你需要深入的协议级测试
- 你在使用传统应用（SAP、Oracle、主机）
- 你的团队技术能力强，拥有独立基础设施
选择 LoadView 的理由：
- 你想测试 现代、基于浏览器的应用
- 你重视 前端性能 与用户体验
- 你需要 更快、更简单的测试流程并支持真实浏览器