無料トライアル

ロード テスト: HTTP 対 ヘッドレス対リアル ブラウザー

無料トライアルを開始
当社の監視ソリューション

概要

読み込みが遅い、または反応しないウェブページは、収益に影響を与える可能性があります。なぜなら、フラストレーションを感じたユーザーは、問題が解決されたとしても再び戻ってくる可能性が低いからです。そのため、パフォーマンステストは開発プロセスにおける基本的な要素となっており、その需要は今も増え続けています。

パフォーマンステストプラットフォームは、HTTP、ヘッドレスブラウザ、リアルブラウザなど、さまざまな負荷シミュレーション方法を提供しています。本稿では、それらの主要な側面を概説し、適切なシミュレーション方法を選択するための比較表も提示します。

HTTPベースの負荷シミュレーション

デジタル時代の初期には、HTTPベースのテストが非常に一般的でした。しかし、リッチなWebクライアント技術の登場により、HTTPベースのシミュレーション手法は次第に時代遅れになりつつあります。典型的なHTTPベースのテストドライバは、サービスリクエストを実行し、レスポンスを解析します。現代のWeb 2.0アプリケーションには多くのクライアントサイドスクリプトが含まれており、この種のテスト実行ではそれらが無視され、測定対象外となります。最悪の場合、クライアント側で生成されるIDが不足しているため、プロトコルレベルで複雑なユースケースをシミュレーションできないこともあります。

リクエストとレスポンスをベースとした設計により、負荷注入マシンへの負担は非常に少なく、1台のロードテストサーバーで最大800の同時セッションをシミュレートできます。ただし、プロトコルベースの複雑なユースケースは実装が困難です。パフォーマンスエンジニアは、クッキー、セッションID、その他の動的パラメータを扱う必要があります。また、システムの種類によっては、新バージョンのデプロイ時にWebフォームの名前が変更され、HTTPベースのスクリプトが失敗することがあります。

ヘッドレスブラウザベースの負荷シミュレーション

Web 2.0技術の進化により、テスト業界は深刻な課題に直面しました。リッチなブラウザアプリケーションは、スクリプトの再生時にクライアント側ロジックが再現されないため、プロトコルレベルではテストやシミュレーションができなくなりました。このため、HtmlUnit、PhantomJS、SlimerJSといった複数のヘッドレスブラウザが登場しました。これらはしばしば、ChromeやSafariの背後にあるエンジン「WebKit」をベースに構築されています。

ヘッドレスブラウザは、GUIのない本物のブラウザに似ています。多くのテスト自動化およびパフォーマンステストプラットフォームでは、トラフィックのシミュレーションにヘッドレスブラウザを使用しています。

ヘッドレスブラウザには欠点もあります。新しいブラウザが市場に出ると、ヘッドレスブラウザキットはそれに追いつく必要があり、実際のブラウザの性能と機能拡張に対応し続けなければなりません。

クライアント側のレンダリングのシミュレーションにはコストがかかります。1台の負荷注入サーバーで同時にシミュレートできるヘッドレスブラウザのセッション数は10〜12程度で、HTTPベースのセッション（約500）と比べると大幅に少なくなります。

テストスクリプトの実装とカスタマイズはそれほど難しくありません。基本的なコーディングスキルがあれば、シンプルなスクリプトを作成できます。ただし、すべてのヘッドレスブラウザがビジュアル再生機能を備えているわけではなく、それがない場合は、スクリプトのデバッグやエラー解析が非常に困難になります。

リアルブラウザベースの負荷シミュレーション

Web2.0アプリケーションは、JavaScript、Flash、Ajax、CSSで溢れています。完全なブラウザがなければ、ページ全体のエンドツーエンドの実際の応答時間を測定することはできません。リアルブラウザベースのパフォーマンステストでは、エンドユーザーが体感するサイトの機能と速度を検証できます。

一般的なリアルブラウザテストソリューションは、画像、JavaScript、CSSなどの読み込み時間を収集し、それらのコンポーネントの読み込み時間を可視化するウォーターフォールチャートを提供することがよくあります。

リアルブラウザの負荷はやや高くなります。ヘッドレスブラウザでは100%のリアルな応答時間が得られないことを考慮すると、リアルブラウザを使ったシミュレーションが望ましいといえます。実際のシナリオでは、ヘッドレスブラウザのパフォーマンスはリアルブラウザよりもわずか20%しか優れていません。つまり、1台の注入マシンで10〜12のヘッドレスセッションが可能なら、8〜10のリアルブラウザセッションも実行可能です。

テストスクリプトの実装と保守は簡単です。ユーザーの操作が直接反映され、ビジュアル再生によりデバッグも容易です。以下のサンプルスクリプトでは、ブラウザがURLを開き、ユーザー名とパスワードを入力してログインボタンをクリックします。

パフォーマンステストの種類

コンポーネント速度テスト

近年、ソフトウェア開発手法はアジャイル型へと移行しています。短いリリーススプリントが不可欠です。開発者やテストエンジニアは、品質保証とパフォーマンスチェックを自動化しています。一般的に、プロトコルレベルでのサービスベースのパフォーマンステストや、リアルブラウザによるエンドツーエンドの応答時間を、あらかじめ定めた基準と比較するためのテストを実施します。

目的

  • + 再現性
  • + 自動化されたインターフェースおよびエンドツーエンドの性能チェック
  • + 応答時間を合意されたしきい値と比較

負荷テスト

いくつかの理由から、負荷テストは非機能要件の検証に理想的な方法です。1つは、再現可能な条件下で応答時間を確認できることです。また、応答時間のしきい値を検証できることも大きな利点です。現実的な応答時間の測定は負荷テストにおいて不可欠であり、テストエンジニアはヘッドレスまたはリアルブラウザによるユーザーシミュレーションを利用します。

目的

  • + 再現可能な負荷シミュレーション
  • + 応答時間のしきい値の検証
  • + 本番環境に近い条件下でのボトルネックの特定
  • + 現実的なエンドツーエンドのテストシナリオ

ストレステスト

アプリケーションがピーク時の負荷下でどの程度信頼できるかを検証したい場合は、ストレステストを実施します。この種のテストでは、主に最大ユーザー数と、ランプアップおよび安定状態の持続時間を設定します。目的は、アプリケーションの限界点を特定することです。

目的

  • + スケーラビリティと安定性の実証
  • + ピーク負荷条件のシミュレーション
  • + 完全な再現性は不要

比較

プロトコル、ヘッドレス、リアルブラウザベースのユーザーシミュレーションには、それぞれ合理的な理由があります。以下の比較表は、適切なアプローチを選ぶための参考になります。

基準 HTTP ヘッドレスブラウザ リアルブラウザ
ユーザーシミュレーション クライアント側レンダリングなし 一部のクライアント側要素をシミュレート 実際のユーザー操作を再現
スクリプトの実装とカスタマイズ サイトが複雑な場合は困難 堅牢なスクリプト作成には開発スキルが必要 シンプルなスクリプトで簡単に対応
スクリプトの再生 低レベルの分析が必要 エンジンによってはビジュアル再生が可能 目に見える動作で確認可能
スクリプトの保守性 プログラミングスキルが必要 レンダリングされない部分のエラー対応が困難 再生中にエラーを目視で確認可能
マルチブラウザサポート 一部ツールはブラウザをエミュレートするが非現実的 対応するが一部要素が欠落することもある 複数バージョンや異なるブラウザをサポート可能
負荷注入マシンの負担 低：最大800セッション／サーバー 中：最大10〜12セッション／サーバー 高：最大6セッション／サーバー
DevOpsへの推奨 実際のテストシナリオに依存 いいえ、スクリプトが複雑なことが多い はい、使いやすく現実的な数値が得られる
負荷テストへの推奨 いいえ、クライアント処理が省略される はい、HTTPよりも優れている はい、現実的なユーザー操作を再現
ストレステストへの推奨 はい、マシンへの負荷が少ない いいえ、負荷が高すぎる いいえ、最も高い負荷がかかる
コスト 低 高 高
大量で低コストのWebサーバーストレステストに推奨（可能な場合） 非推奨 現実的で複雑なアプリケーションのシミュレーションに推奨

本稿で使用した参考ページ：

Latest Web Performance Articles​

SSL 証明書監視に関するすべて

SSL モニタリングのすべて、SSL 証明書の追跡、管理、更新方法を学びます。無料ツール、自動アラート、最適な監視ソリューションを見つけましょう。

Dotcom-Monitorを無料で開始する

クレジットカード不要

今すぐ無料で始めよう