新しい Web サイトを持っているか、ユーザーが必要とする機能を開発しただけか、多数のユーザーが Web サイトとやり取りを開始したときに、どのように Web サイトのパフォーマンスを高くしますか? 答えはロード テストです。 ロード テストは、通常およびピーク条件下での Web サイト、アプリケーション、またはソフトウェア の動作を判断するために使用されるパフォーマンス テストの重要な部分です。 ロード テストは、Web サイトのパフォーマンスを向上させ、予想される負荷条件の安定性を向上させる有用なデータを提供します。 最近まで、プロトコルベースのロードテストは、予想されるロード条件のためにWebサイトをテストする唯一の方法でした。 テクノロジーとユーザーエクスペリエンスが進化するにつれて、実際のChromeブラウザを使用すると、テスターは実際のユーザーのシミュレーションに必要なより現実的な環境と、より正確なロードテスト結果を使用できます。
この記事では、次の 3 つの広く使用されているロード テストの方法について説明します。
- ブラウザベースのロードテスト(通常の Chrome ブラウザを使用)
- ヘッドレス ブラウザの負荷テスト
- プロトコル ベースのロード テスト
Chrome ブラウザベースのロード テスト
ブラウザベースのロードテストでは、負荷ジェネレータを通じて通常のChromeブラウザインスタンスを作成することで実際のユーザーをシミュレートし、テスト対象のウェブサイトは簡単なスクリプトの助けを借りてナビゲートされます。 これは現実世界の実ユーザとほとんど同じ環境を作り出します。 ブラウザベースのロード テストの仮想ユーザーは、ブラウザ レベル ユーザ (BLU) と呼ばれます。 ブラウザベースのロードテストスクリプトには、Web サイト上の実際のナビゲーションと操作に関する指示があります。 たとえば、クリックするボタン、移動する場所、入力ボックスにフィードする情報、要素との対話方法、要素と対話するタイミングなどです。 これにより、テスターは実際のシナリオと最も同一のユーザー体験を シミュレート できます。
実際のブラウザベースのロードテストの利点
ユーザーの視点
実際のエンドユーザーは、実際のChromeブラウザなどのブラウザを使用してウェブサイトを操作します。 ブラウザベースの ロードテストを使用すると、通常のChromeブラウザでウェブサイトのロードテストを行い、実際のユーザーの行動を理解できます。
単純なスクリプト
ブラウザベースのロード テスト スクリプトを作成する場合、基になるプロトコルについて詳しい知識を持っている必要はありません。 たとえば、ログインアクションを作成する場合、ユーザー名とパスワードを入力するだけで、どのボタンをクリックして続行するかだけで、 認証プロトコルなどの技術を知る必要はありません。
テストの複雑さの軽減
パラメーターと値を渡す必要がある他の従来のロード テスト方法とは異なり、ブラウザー ベースのロード テスト は、合理化されたスクリプトを使用して簡単に作成および開始できます。
フロントエンドの最適化
ブラウザーベースのロード テストでは、 ユーザーが 通常のブラウザーを使用して Web サイトを操作するため、ネットワークや要求の遅延など、最も正確な実世界のデータを収集できます。 これは、フロントエンドの最適化に役立ちます。
低メンテナンス
シンプルなスクリプトと複雑なテストが少ないと、負荷テストのメンテナンスが容易になり、より機敏になります。 たとえば、ログイン例では、認証プロトコルを変更する場合、ログインロードテストは変更する必要はありません。
実際のブラウザベースのロード テストの欠点
CPU とメモリ使用量の増加
たとえば、通常のクロム ブラウザを使用したブラウザベースのロード テストでは、予想される負荷のインスタンスを作成するために、より高い CPU とメモリが必要です。 ただし、クラウドベースのロード テスト プラットフォームを使用する場合は、この問題は発生しません。
ランタイムが長くなる場合があります
ブラウザー ベースのロード テストでは、API 要求/応答の単純な記録ではなく、ブラウザー インスタンスで完全な Web サイト UI をレンダリングします。 これは、アプローチされた他のロード テストよりも時間がかかる場合があります。 ただし、ブラウザー ベースのテストを実行する単純さと優れたクラウド ベースのロード テスト ツールによって、多くの場合、この問題はこれに反します。
ヘッドレス ブラウザの負荷テスト
ヘッドレス ブラウザーのロード テストでは、’Head’ やユーザー インターフェイスを作成せずに、ブラウザー環境でロード テストを実行します。 つまり、グラフィカル ユーザー インターフェイス (GUI) を使用せずに、非表示のブラウザー インスタンスを作成することによってロード テストが実行されます。 ヘッドレス ブラウザのロード テストでは、シミュレートされたブラウザを誰も見ていないため、レンダリング操作や描画操作はスキップされます。 これにより、実際のブラウザー ベースのロード テストと比較して、リソースが少ないブラウザー環境で、ロード テストをすばやく実行できます。 ヘッドレス ブラウザの例を次に示します。
ヘッドレスクローム
Chromeブラウザは、バージョン59以降のヘッドレスモードで起動することができます。 軽量でリソースの消費が少なく、ナビゲーション、ページ上の情報の収集、PDF の生成、スクリーンショットの取得に使用できます。
ヘッドレスファイアフォックス
Firefox は、バージョン 56 以降のヘッドレスブラウザモードも提供しています。 ヘッドレステストと自動化のための Selenium などのテストツールを使用した基本的なテストに使用できます。
ファントムJS
PhantomJS は、Web の多くの標準をサポートする柔軟なヘッドレス Web キットです。 テストにファントム JS を使用する場合は、テスト スクリプトを記述するために JavaScript API を使用します。 これは主にナビゲーションとアサーションのテストに使用されます。
ヘッドレス ブラウザロードテストの利点
リソースの負荷が少ない
ブラウザ環境のロード テストでは GUI がレンダリングされていないので、ヘッドレス ブラウザの負荷テストを使用すると、より少ないリソースでより多くの負荷を生成できます。
より迅速なブラウザ環境テスト
ヘッドレスブラウザのロードテストを使用すると、テストをより迅速に実行し、 潜在的な問題を迅速に修正するための結果を得ることができます。
ブラウザベースのロード テストの欠点
ブラウザ環境の機能が制限される
ヘッドレスブラウザテストでは多くのブラウザベースのシナリオをテストできますが、Chromeのような通常のブラウザを使用している実際のユーザーの全体像を把握するだけでは不十分です。
ブラウザの監視の欠如
テスト ケースのシナリオでは、ロード テストを徹底的に分析するために、アニメーション、SPA の移行など、ブラウザー ベースのテストを確認する必要があります。 ヘッドレス ブラウザーのロード テストには、この機能はありません。
プロトコル ベースのロード テスト
プロトコルベースのロード テストは、ロード サーバーで HTTP/S レベルで トラフィックを シミュレートする、最も伝統的なロード テスト方法です。 これは主に、サーバー上で予想される負荷に対する要求/応答交換の評価と評価に使用されます。 プロトコルベースのロード テストは、最小限の形式のロード テストであり、それだけでは、ユーザー エクスペリエンスに重点を置いた複雑な ウェブ アプリケーションには適していません。
プロトコルベースのロード テストの利点
リソース集中の少ない
プロトコル ベースのロード テストでは、最小限のリソースで非常に高い負荷を生成できる HTTP/S 要求応答トラフィックの生成のみが必要です。
より迅速な実行
プロトコル レベルのメトリックについて分析されるのは HTTP/S トラフィックのみであるため、プロトコル ベースのロード テストでは、予想される負荷が高い場合のテスト実行が高速になります。
プロトコル ベースのロード テストの欠点
複雑なテスト
プロトコルベースのスクリプトでは、 ログイン用のOauthプロトコルなど、HTTP/Sレベルで使用されるさまざまなプロトコルを深く理解する必要があります。 これにより、スクリプトのロード テストが複雑で時間のかかるプロセスになります。
最も現実的な環境
ユーザーが Chrome のような通常のブラウザを使用してウェブサイトにアクセスする実際の環境とは対照的に、プロトコルベースのロード テストはそのような機能を提供しません。 ユーザーの視点に焦点を当てたWeb サイトには適 していません。
現代のウェブサイトの機能の欠如
たとえば、最新の Web サイトでは、ブラウザーの JavaScript と AJAX 呼び出しを多用する複雑なスタックがあり、プロトコル ベースのロード テストが多くのテスト シナリオで制限されています。
ブラウザー ベースのロード テスト用の LoadView
これまでに説明した内容に基づいて、ブラウザーベースのロード テストが次の進化を示すロード テスト アプローチは明らかです。 今日の Webサイト とテクノロジーは、豊富なユーザーエクスペリエンスに重点を置いており、 サーバー側ではなくブラウザー側の解釈とレンダリングに大きく依存しています。 シングルページ アプリケーション (SPA) は、 UI を更新するためのページ更新がほとんどまたはまったくないために、クライアント側の JavaScript フレームワークと AJAX 呼び出しを使用する一般的なフレームワークで広く使用されています。
LoadView は、Chrome などの実際のブラウザーを使用した クラウドベースの ロード テストを提供し、ロード テスト シナリオで最も現実的な環境を作成します。 LoadView を使用すると、さまざまなユーザー アクションと動作のスクリプトを簡単に作成し、数回クリックするだけでテストを実行できます。
ロードビューでテストできる内容
- ウェブサイト
- シングル ページ アプリケーション (SPA)
- サードパーティのサービス/API
- ストリーミング メディア サービスのようなメディアリッチなウェブサイト
実際のブラウザベースのロード テストにおける LoadView の利点と利点
- すべてのページをロードテストするために 、EveryStep Web Recorder を使用して、1 行のコードを記述することなく、テスト スクリプトを簡単に作成できます。
- 事実上すべてのデバイス上でウェブページをテストすることを可能にする40以上の実際のデスクトップ/モバイルブラウザ。
- 地理的分散ロード テストでは、 複数の場所からユーザーをテストし、 実際のシナリオでより正確な結果を得ることができます。
- LoadView は DevOps に優しく、パフォーマンスを測定し、Web アプリケーションを最適化するための複数のテスト 曲線を提供します。
ラッピング: 実際のブラウザベースのロードテストの利点
ブラウザベースのロードテストは、最新のフレームワークとメディアリッチコンテンツに基づいて構築されたWebサイトに必要です。 市場シェアの65%以上を占めるChromeのような実際のブラウザを使用したロードテストでは、ウェブサイトをすばやく最適化するためのパフォーマンスの結果が得られます。 ただし、ロード テストや単一のデバイスの場合は、Chrome だけに制限しないでください。 複数の地域から、事実上すべてのブラウザやデバイスでウェブサイトをテストする機能を持つことで、予想される負荷に合わせてウェブサイトを分析し最適化するためのテストに関する包括的な洞察が得られます。
今すぐビューを読み込んでみて下します。 無料のロード テストを受け取って、Chrome ブラウザベースのロード テストを開始します。