この記事では、LoadRunnerとLoadViewを、サンプルアプリケーションPhoneNumberMonitoring.comを使った実践的なテストシナリオで比較します。テストフローはシンプルです：
アプリケーション起動 → ログイン → タブに移動 → ログアウト
しかし、このフローの実装方法はLoadRunnerとLoadViewでまったく異なります。特にセットアップの手間、柔軟性、スケーラビリティ、実際のシミュレーション精度に大きな違いがあります。
LoadRunnerを使用：高い複雑性を伴うプロトコルレベルの強力さ
LoadRunnerは、VuGen（Virtual User Generator）を使用して、プロトコルレベルの詳細な制御を提供します。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のデータパラメータ化ユーティリティを使用して、ハードコードされた値をデータファイルに置き換え。
- 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はレガシーシステムに強力ですが、モダンなWebテストやスプリントベースの開発には不向きです。
LoadViewを使用：リアルブラウザ負荷テストが簡単に
LoadViewは、クラウドネイティブかつブラウザベースの負荷テストというモダンなアプローチを提供します。ChromeやEdgeなどのブラウザ上で実際のユーザーの行動をシミュレーションし、バックエンドだけでなくフロントエンド（UXメトリクス）も検証します。
PhoneNumberMonitoring.comの同じフローで、EveryStep Recorderを使い、5分以内でテスト設定を完了しました。コード不要、設定不要、プラグイン不要です。
LoadViewが簡単に感じられた理由
- リアルユーザーのように録画：クリック、入力、スクロールするだけでOK。実際の操作をそのまま記録。
- 相関設定不要：LoadViewはトークンやセッションなどの動的値を自動で取得します。
- 完全なC#スクリプト対応：上級者向けに、ループ、条件分岐、変数定義など、柔軟なフロー制御が可能なC#スクリプティング機能を搭載。
例：コンテンツ検証エラー時にスクリプトを中断
- Cookieとヘッダーの事前設定：ヘッダー、認証、Cookie、User-Agentなどを事前に設定し、実環境に近いシナリオを構築可能。
- 初心者にも上級者にも対応：シンプルな録画で始められ、上級テストにもスケールする稀有なツール。
- 完全なブラウザレンダリング：SPA、AJAX、WebSocketをサポート — 画面に見えるものをそのままテスト。
- 地理的に分散されたテスト：世界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 |
| ECサイトのチェックアウト | 非同期トークンやJS遅延用のスクリプトが必要 | UX検証付きの実ブラウザチェックアウトフロー |
| バンキング ダッシュボード |
深い相関処理やトークン追跡が必要 | ログインとセキュアなダッシュボードの操作を簡単にシミュレート |
| 地理的負荷分散 | 地域ごとにLGのセットアップが必要 | UI内で簡単に地域選択 |
| アジャイルスプリントテスト | テストの修正や再実行に時間がかかる | 素早い作成と再利用が容易 |
| クライアント向けデモ・POC | セットアップと調整が必要 | テスト結果を即座に記録・共有 |
最終まとめ
以下に該当するならLoadRunnerを選ぶべき：
- プロトコルレベルの詳細なテストが必要な場合
- SAP、Oracle、メインフレームなどのレガシーアプリを扱う場合
- 技術力のある専任チームと専用インフラがある場合
以下に該当するならLoadViewを選ぶべき：
- モダンなブラウザベースアプリをテストしたい場合
- フロントエンドのパフォーマンスやユーザー体験を重視する場合
- 実ブラウザ対応の、迅速かつ簡単なテストサイクルが必要な場合