ページを選択

新しい ウェブ サイトを持っているか、ユーザーが必要とする機能を開発しただけか、多数のユーザーが ウェブ サイトとやり取りを開始したときに、どのように ウェブ サイトのパフォーマンスを高くしますか? 答えは負荷テストです。 ロード テストは、通常の状態とピーク状態で ウェブ サイト、アプリケーション、またはソフトウェアの動作を判断するために使用されるパフォーマンス テストの重要な部分です。 ロード テストは、ウェブ サイトのパフォーマンスを向上させ、予想される負荷条件の安定性を向上させる有用なデータを提供します。 最近まで、プロトコルベースのロードテストは、予想されるロード条件のためにウェブ サイトをテストする唯一の方法でした。 技術とユーザーエクスペリエンスが進化するにつれて、実際のChromeブラウザを使用することで、実際のユーザーのシミュレーションに必要なより現実的な環境をテスターが使用でき、ロードテスト結果をより正確に再現できます。

この記事では、次の 3 つの広く使用されているロード テストの方法について説明します。

  1. ブラウザベースのロードテスト(通常の Chrome ブラウザを使用)
  2. ヘッドレス ブラウザの負荷テスト
  3. プロトコル ベースのロード テスト

 

Chrome ブラウザベースのロード テスト

ブラウザベースのロードテストでは、負荷ジェネレータを通じて通常のChromeブラウザインスタンスを作成することで実際のユーザーをシミュレートし、テスト対象のウェブサイトは簡単なスクリプトの助けを借りてナビゲートされます。 これは現実世界の実ユーザとほとんど同じ環境を作り出します。 ブラウザベースのロード テストの仮想ユーザーは、ブラウザ レベル ユーザ (BLU) と呼ばれます。 ブラウザベースのロードテストスクリプトには、ウェブ サイト上の実際のナビゲーションと操作に関する指示があります。 たとえば、クリックするボタン、移動する場所、入力ボックスにフィードする情報、要素との対話方法、要素と対話するタイミングなどです。 これにより、テスト担当者は、現実世界のシナリオと同じユーザー体験をシミュレートできます。

 

実際のブラウザベースのロードテストの利点

 

ユーザーの視点

実際のエンドユーザーは、実際の Chrome ブラウザなどで、ブラウザを使用して ウェブ サイトと対話します。 ブラウザベースのロードテストを使用すると、通常の Chrome ブラウザでウェブサイトをロードテストし、実際のユーザーの動作を理解できます。

 

単純なスクリプト

ブラウザベースのロード テスト スクリプトを作成する場合、基になるプロトコルについて詳しい知識を持っている必要はありません。 たとえば、ログインアクションを作成する場合は、入力するユーザー名とパスワード、および続行するボタンをクリックするだけで、認証プロトコルなどの技術を知る必要はありません。

 

テストの複雑さの軽減

渡すパラメーターと値が必要な他の従来のロード テスト方法とは異なり、ブラウザー ベースのロード テストは、合理化されたスクリプトを使用して簡単に作成および開始できます。

 

フロントエンドの最適化

ブラウザベースのロードテストでは、ユーザーが通常のブラウザを使用してウェブサイトと対話するため、ネットワークや要求の遅延など、最も正確な実世界のデータを収集できます。 これは、フロントエンドの最適化に役立ちます。

 

低メンテナンス

シンプルなスクリプトと複雑なテストが少ないと、負荷テストのメンテナンスが容易になり、より機敏になります。 たとえば、ログイン例では、認証プロトコルを変更する場合、ログインロードテストは変更する必要はありません。

 

実際のブラウザベースのロード テストの欠点

 

CPU とメモリ使用量の増加

たとえば、通常のクロム ブラウザを使用したブラウザベースのロード テストでは、予想される負荷のインスタンスを作成するために、より高い CPU とメモリが必要です。 ただし、クラウドベースのロード テスト プラットフォームを使用する場合は、この問題は発生しません。

 

ランタイムが長くなる場合があります

ブラウザー ベースのロード テストでは、API 要求/応答の単純な記録ではなく、ブラウザー インスタンスで完全な ウェブ サイト UI をレンダリングします。 これは、アプローチされた他のロード テストよりも時間がかかる場合があります。 ただし、ブラウザー ベースのテストを実行する単純さと優れたクラウド ベースのロード テスト ツールによって、多くの場合、この問題はこれに反します。

 

ヘッドレス ブラウザの負荷テスト

ヘッドレス ブラウザーのロード テストでは、’Head’ やユーザー インターフェイスを作成せずに、ブラウザー環境でロード テストを実行します。 つまり、グラフィカル ユーザー インターフェイス (GUI) を使用せずに、非表示のブラウザー インスタンスを作成することによってロード テストが実行されます。 ヘッドレス ブラウザのロード テストでは、シミュレートされたブラウザを誰も見ていないため、レンダリング操作や描画操作はスキップされます。 これにより、実際のブラウザー ベースのロード テストと比較して、リソースが少ないブラウザー環境で、ロード テストをすばやく実行できます。 ヘッドレス ブラウザの例を次に示します。

 

ヘッドレスクローム

Chromeブラウザは、バージョン59以降のヘッドレスモードで起動することができます。 軽量でリソースの消費が少なく、ナビゲーション、ページ上の情報の収集、PDF の生成、スクリーンショットの取得に使用できます。

 

ヘッドレスファイアフォックス

Firefox は、バージョン 56 以降のヘッドレスブラウザモードも提供しています。 ヘッドレステストや自動化用のセレンなどのテストツールを使用して、基本的なテストに使用できます。

 

ファントムJS

PhantomJS は、ウェブ の多くの標準をサポートする柔軟なヘッドレス ウェブ キットです。 テストにファントム JS を使用する場合は、テスト スクリプトを記述するために JavaScript API を使用します。 これは主にナビゲーションとアサーションのテストに使用されます。

 

ヘッドレス ブラウザロードテストの利点

 

リソースの負荷が少ない

ブラウザ環境のロード テストでは GUI がレンダリングされていないので、ヘッドレス ブラウザの負荷テストを使用すると、より少ないリソースでより多くの負荷を生成できます。

 

より迅速なブラウザ環境テスト

ヘッドレスブラウザの負荷テストでは、テストを実行し、潜在的な問題を迅速に修正するための結果を得る方が迅速です。

 

ブラウザベースのロード テストの欠点

ブラウザ環境の機能が制限される

ヘッドレスブラウザテストでは多くのブラウザベースのシナリオをテストできますが、Chromeのような通常のブラウザを使用している実際のユーザーの全体像を把握するだけでは不十分です。

 

ブラウザの監視の欠如

テスト ケースのシナリオでは、ロード テストを徹底的に分析するために、アニメーション、SPA の移行など、ブラウザー ベースのテストを確認する必要があります。 ヘッドレス ブラウザーのロード テストには、この機能はありません。

 

プロトコル ベースのロード テスト

プロトコル ベースのロード テストは、負荷サーバー上の HTTP/S レベルでトラフィックをシミュレートすることで、最も従来のロード テスト方法です。 これは主に、サーバー上で予想される負荷に対する要求/応答交換の評価と評価に使用されます。 プロトコル ベースのロード テストは、ユーザー エクスペリエンスに焦点を当てた複雑な ウェブ アプリケーションには適さない最小限のロード テストです。

 

プロトコルベースのロード テストの利点

リソース集中の少ない

プロトコル ベースのロード テストでは、最小限のリソースで非常に高い負荷を生成できる HTTP/S 要求応答トラフィックの生成のみが必要です。

 

より迅速な実行

プロトコル レベルのメトリックについて分析されるのは HTTP/S トラフィックだけであるため、プロトコル ベースのロード テストでは、予想される負荷が高くなるテストの実行が高速になります。

 

プロトコル ベースのロード テストの欠点

 

複雑なテスト

プロトコル・ベースのスクリプトでは、ログイン用の Oauth プロトコルなど、HTTP/S レベルで使用されるさまざまなプロトコルを詳細に理解する必要があります。 これにより、スクリプトのロード テストが複雑で時間のかかるプロセスになります。

 

最も現実的な環境

ユーザーが Chrome のような通常のブラウザを使用してウェブサイトにアクセスする実際の環境とは対照的に、プロトコルベースのロード テストはそのような機能を提供しません。 ユーザーの視点に焦点を当てたウェブサイトには適した選択ではありません。

 

現代のウェブサイトの機能の欠如

最近の ウェブ サイトでは、多くのテスト シナリオでプロトコル ベースのロード テストを制限するなど、ブラウザーの JavaScript と AJAX 呼び出しを多用する、より複雑なスタックが発生しています。

 

ブラウザー ベースのロード テスト用の LoadView

これまでに説明した内容に基づいて、ブラウザーベースのロード テストが次の進化を示すロード テスト アプローチは明らかです。 今日の ウェブ サイトとテクノロジは、豊富なユーザー エクスペリエンスに重点を置き、サーバー側ではなくブラウザー側の解釈とレンダリングに大きく依存しています。 単一ページ アプリケーション (SPA) は、クライアント側の JavaScript フレームワークを使用する一般的なフレームワークや AJAX 呼び出しで、UI を更新するためのページの更新をほとんどまたはまったく行いません。

LoadView は、Chrome のような実際のブラウザを使用してクラウドベースのロード テストを提供し、ロード テスト シナリオに最も現実的な環境を作成します。 LoadView を使用すると、さまざまなユーザーの操作や動作に対応する スクリプトを簡単に作成 し、数回のクリックでテストを実行できます。

 

ロードビューでテストできる内容

  1. ウェブサイト
  2. シングル ページ アプリケーション (SPA)
  3. サードパーティのサービス/API
  4. ストリーミング メディア サービスのようなメディアリッチなウェブサイト

 

実際のブラウザベースのロード テストにおける LoadView の利点と利点

  1. すべてのページをロードテストするために 、EveryStep Web Recorder を使用して、1 行のコードを記述することなく、テスト スクリプトを簡単に作成できます。
  2. 事実上すべてのデバイス上でウェブページをテストすることを可能にする40以上の実際のデスクトップ/モバイルブラウザ。
  3. 地理的分散ロード テストでは、 複数の場所からユーザーをテストし、 実際のシナリオでより正確な結果を得ることができます。
  4. LoadView は DevOps に優しく、パフォーマンスを測定し、ウェブ アプリケーションを最適化するための複数のテスト 曲線を提供します。

 

ラッピング: 実際のブラウザベースのロードテストの利点

ブラウザベースのロードテストは、最新のフレームワークとメディアリッチコンテンツに基づいて構築されたウェブ サイトに必要です。 市場シェアの65%以上を占めるChromeのような実際のブラウザを使用したロードテストでは、ウェブサイトをすばやく最適化するためのパフォーマンスの結果が得られます。 ただし、ロード テストや単一のデバイスの場合は、Chrome だけに制限しないでください。 複数の地域から、事実上すべてのブラウザやデバイスでウェブサイトをテストする機能を持つことで、予想される負荷に合わせてウェブサイトを分析し最適化するためのテストに関する包括的な洞察が得られます。

今すぐビューを読み込んでみて下します。 Chrome ブラウザベースのロード テストを開始するには、ロード テスト クレジットで 20 ドルを受け取ります。