在本文中，我们通过对示例应用程序 PhoneNumberMonitoring.com 的实际测试场景比较 LoadRunner 和 LoadView。测试流程很简单：
启动应用程序 → 登录 → 导航到标签页 → 注销
然而，LoadRunner 与 LoadView 对此流程的实现方式完全不同——尤其是在 配置工作量、灵活性、可扩展性以及真实世界模拟准确性 方面。
使用 LoadRunner：协议级强大控制但复杂度高
LoadRunner 通过 VuGen（虚拟用户生成器） 提供 深度协议级控制，支持 HTTP/HTML、SAP、Web Services 和 TruClient 等协议。虽然这为企业级测试提供了灵活性，但即使是配置一个基础流程也可能令人生畏。
本次测试中，我们使用了适用于无完整浏览器渲染的 web 应用的 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 和自定义请求头。
- 高级逻辑：添加 if-else、循环和 C 语言自定义代码以控制流程。
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 对于传统系统非常强大，但对于现代 Web 测试或基于冲刺的迭代来说并不理想。
使用 LoadView：简化的真实浏览器负载测试
LoadView 提供了现代化的 云原生、基于浏览器的负载测试 解决方案。它模拟 Chrome 或 Edge 等浏览器中的 真实用户行为，验证不仅是后端响应，还包括 实际的前端性能（用户体验指标）。
针对 PhoneNumberMonitoring.com 的同一流程，我们使用了 EveryStep Recorder，并在不到 5 分钟内完成了测试配置——无需编码、配置或插件。
为什么 LoadView 让测试变得轻松
- 像真实用户一样录制：只需点击、输入、滚动——就像实际用户操作那样。
- 无需关联：LoadView 会自动捕获动态值（令牌、会话）。
- 完整的 C# 脚本支持：面向高级用户，LoadView 提供完整的 C# 脚本功能，支持循环、条件、变量声明等，使您能够根据需要自定义流程。
例如：在内容验证错误时中止脚本执行
- 预设 Cookie 和请求头：可在执行前配置请求头、身份认证信息、Cookie 以及用户代理，更准确地模拟真实场景。
- 初学者友好，专家可用：不仅易于开始录制，LoadView 还能满足经验丰富测试人员的需要，实现简单与强大的难得结合。
- 完整浏览器渲染：支持单页应用（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） | 统一录制所有 Web 流程 |
| 分布式测试 | 需要 Load Generators 和 Controller | 内置云端执行 |
| 技能要求 | 高 – 需要脚本和调试能力 | 低 – 业务用户也能操作 |
| 成本与许可 | 昂贵的企业许可 | 透明的按使用计费 |
真实应用影响
| 用例 | LoadRunner | LoadView |
| 电商结账 | 需针对异步令牌和 JS 延迟编写脚本 | 真实浏览器结账流程并验证用户体验 |
| 银行 仪表盘 |
需要深度关联和令牌跟踪 | 轻松模拟登录并导航受保护仪表盘 |
| 地理负载模拟 | 每个区域需配置 Load Generator | 简单的 UI 地理选择器 |
| 敏捷冲刺测试 | 修改和重新运行测试较慢 | 快速创建并易于复用 |
| 客户演示与概念验证 | 需配置和协调 | 录制并即时分享测试结果 |
最终总结
如果您需要选择 LoadRunner：
- 您需要深度协议级测试
- 您处理的是传统应用（SAP、Oracle、大型机系统）
- 您的团队具备较高技术能力并有专门的基础设施支持
如果您需要选择 LoadView：
- 您想测试现代的基于浏览器的应用
- 您关注前端性能和用户体验
- 您需要一个更快速、更简单的测试生命周期，且支持真实浏览器