この記事では、LoadRunner と LoadView をサンプルアプリケーション PhoneNumberMonitoring.com 上の実践的なテストシナリオで比較します。テストフローはシンプルです：
アプリケーション起動 → ログイン → タブ移動 → ログアウト
しかし、このフローの LoadRunner と LoadView での実装方法はまったく異なります。特に セットアップの手間、柔軟性、スケーラビリティ、実世界のシミュレーション精度において差があります。
LoadRunnerの使用：高い複雑性を伴うプロトコルレベルの制御力
LoadRunner は VuGen（Virtual User Generator） を利用した プロトコルレベルでの深い制御を提供し、HTTP/HTML、SAP、Webサービス、TruClient など複数のプロトコルをサポートします。これは企業向けテストには柔軟性をもたらしますが、基本的なフローの設定でさえ手間が多くなる場合があります。
今回のテストでは Web HTTP/HTML プロトコル を使用しました。これは完全なブラウザレンダリングが不要なウェブアプリケーションに適しています。
LoadRunnerでの作業内容
- プロトコルの選択: HTTP/HTMLを選択。ただし、正しい録画モード（HTMLベースかURLベースか）を選ぶのは重要で、多くの場合試行錯誤が必要です。
- VuGenでの録画: ポートマッピングを設定（スクリーンショット参照）、キャプチャレベル（WinInetまたはSocketなど）を選択しました。各レベルで動作が異なります。
- 相関設定: web_reg_save_param_ex や JSONパスを用いて動的セッションデータを手動で抽出。相関を誤るとテストは失敗し、UIによる自動サジェストはありません。
- パラメータ化: LoadRunnerのデータパラメータ化機能を使い、ハードコードされた値をデータファイルに差し替えました。
- Think Time とトランザクション: 重要な操作を lr_start_transaction() で囲み、lr_think_time() でユーザー遅延をシミュレートしました。
- セッション管理: クッキーやカスタムヘッダーを手動で管理しました。
- 高度なロジック: 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 Services), 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 (LG) 。
- 手動セットアップ、ファイアウォールルール、ポート開放、ネットワーク設定などが必要です。
- スケーラビリティと実行オーケストレーションが複雑で、迅速な対応が求められるアジャイルチームには向きません。
LoadRunnerはレガシーシステムには強力ですが、モダンなウェブテストやスプリントベースの反復には理想的ではありません。
LoadViewの使用：シンプルなリアルブラウザ負荷テスト
LoadViewはクラウドネイティブのブラウザベース負荷テストというモダンなアプローチを提供します。ChromeやEdgeなどのブラウザ上で実際のユーザー行動をシミュレーションし、バックエンドの応答だけでなく**フロントエンド性能（UX指標）**まで検証します。
同じPhoneNumberMonitoring.comのフローでは、EveryStep Recorderを使用し、5分以内にテスト設定を完了しました。コード不要、設定不要、プラグインも不要です。
LoadViewが簡単に感じられた理由
- 実際のユーザーのように録画: クリック、入力、スクロールなど、実際のユーザーが行う操作をそのまま記録。
- 相関不要: LoadViewは動的値（トークン、セッション）を自動的にキャプチャ。
- 完全なC#スクリプティングサポート: 上級ユーザー向けに、LoadViewはループ、条件分岐、変数宣言などC#の全機能をサポートし、フローを柔軟にカスタマイズ可能。
例：コンテンツ検証エラー時にスクリプト実行を中断する方法
- プリセットクッキーとヘッダー: 実行前にリクエストヘッダー、認証情報、クッキー、ユーザーエージェントを設定し、実際の環境を正確に模擬可能。
- 初心者向けだが専門家も対応可能: 簡単な録画で始められ、経験豊富なパフォーマンステスターのニーズにも応えられるシンプルさと強力さの稀有な組み合わせ。
- 完全なブラウザレンダリング対応: SPA、AJAX、WebSocketをサポート、「見たものをそのままテスト」します。
- 地理的分散テスト: 40以上のグローバルリージョンから選び、実際のユーザー所在地からの負荷をシミュレーション可能。
- ライブセッションリプレイ: テストの実行内容をページレンダリングや入力操作を含めてステップごとに視聴可能（LoadRunnerでは不可）。
- フロントエンド指標: レポートから直接LCP（Largest Contentful Paint）、FCP（First Contentful Paint）、TTI（Time to Interactive）を確認可能。
- ビジュアルフローエディター: コードやログを触らずに任意のステップを視覚的に編集可能。
機能比較：LoadRunner vs LoadView
| 機能 | LoadRunner | LoadView |
| 録画オプション | 複数のキャプチャレベル（WinInet, Socket）、プロトコル選択 | 1クリックのブラウザベース録画 |
| スクリプティングの必要性 | あり – 高度なスクリプト、パラメータ化、相関 | なし – 録画して実行するだけ |
| 動的値の処理 | 手動 – プロトコルごと | 自動相関 |
| リアルブラウザシミュレーション | TruClientのみ（重く遅い） | ネイティブChrome/Edge |
| フロントエンド指標 | TruClientで限定的 | 完全対応（FCP、LCP、TTI） |
| ライブセッションリプレイ | なし | あり – 再生可能 |
| テスト作成時間 | 45〜90分 | 5〜10分 |
| ログ分析 | 複雑なプロトコルログ、手動相関 | UIベースのステップログ、スクリーンショット |
| プロトコル固有の対応 | アプリタイプごとに異なる（HTML、SAP、Oracle） | すべてのウェブフローに対して統一レコーダー |
| 分散テスト | LGとControllerが必要 | クラウド実行が組み込み |
| スキル要件 | 高い – スクリプト作成とデバッグが必要 | 低い – ビジネスユーザーもテスト可能 |
| コストとライセンス | 高額な企業向けライセンス | 透明性のある使用量ベースの料金 |
実際のアプリケーション インパクト
| ユースケース | LoadRunner | LoadView |
| ECチェックアウト | 非同期トークンやJS遅延のスクリプティングが必要 | UX検証付きのリアルブラウザチェックアウトフロー |
| 銀行ダッシュボード | 深い相関とトークントラッキングが必要 | ログインとセキュアダッシュボードナビゲートが簡単にシミュレーション可能 |
| 地理的負荷シミュレーション | 各地域ごとにLGセットアップが必要 | UI内のシンプルな地理選択ツール |
| アジャイルスプリントテスト | テスト修正と再実行が遅い | テスト作成が迅速で再利用も容易 |
| クライアントデモ・PoC | セットアップと調整が必要 | 録画してテスト結果を即共有可能 |
まとめ
LoadRunnerを選ぶべき場合：
- 深いプロトコルレベルのテストが必要な場合
- レガシーアプリ（SAP、Oracle、メインフレーム）を扱っている場合
- チームに技術的な熟練者がおり、専用インフラが整っている場合
LoadViewを選ぶべき場合：
- モダンなブラウザベースのアプリをテストしたい場合
- フロントエンド性能やユーザー体験を重視する場合
- リアルブラウザ対応による、より速くシンプルなテストサイクルが必要な場合