LoadView は、閲覧、検索、ショッピングカートへの商品の追加、デバイスへの特定の種類のリクエストの生成など、ウェブサイト(デバイス)で特定のアクションを実行することにより、ウェブサイトまたはサーバー上のユーザーをエミュレートします。

デバイスがどの程度処理できるかを知ることで、ソフトウェアやハードウェアの更新を計画し、実際のトラフィックに備えることができます。

これらのアクションを実行するユーザーの数、LoadView テスト (ロード テスト) の期間を定義し、それらの仮想ユーザーの到着率と出発率を使用して完全にカスタマイズされたシナリオを設定できます。

ロードビューテストのセットアップ

ロード テストを実行するには、まず追加 ([新しいテスト ] ボタン) を追加し、新しいロード テストを設定する必要があります。 次の種類のテストを設定できます。

さらに、Postman を使用して Web API のパフォーマンスをテストしている場合は、 Postman コレクション テストを使用して、Postman からの Web API 呼び出しを使用して LoadView でロード テストを設定できます。 または、JMeterテスト計画を使用したロードテストの新機能を探索します-JMeterテスト計画をインポートし、ナレッジベースの JMeterテスト計画を使用したロード テストの記事で説明されているようにテストを設定します。

ロード テスト シナリオの構成

ターゲットを設定したら、ロード テスト シナリオを構成できます。 各テスト シナリオには、構成ページに一意の ID が表示されます。 LoadView API への要求を構成する際に ID を活用します。

 

シナリオ ID

LoadView のセットアップには、以下に説明するいくつかの手順が含まれます。

検証

検証では 、テストされたターゲットが有効であり、ターゲットへの要求がエラーなしで実行されることを確認します。 検証結果のステータスは、ターゲットの詳細セクションに表示されます。

システムがエラーを検出した場合は、[ 詳細の表示(View Details )] をクリックして、セッション レポート ページでエラーを確認します。

テストを実行する前に、すべてのエラーを修正することを強くお勧めします。

ユーザー動作プロファイル

プロファイルは、テスト実行中の Web サイトでシミュレートされたユーザーの動作を記述します。 Web サイトとのユーザー操作のシミュレーションをカスタマイズするには、 ユーザー動作プロファイルを参照してください。

荷重タイプの選択

ロード タイプでは、異なる種類のロード テストを選択できます。 各型には、使用する最適な内容、使用可能な設定、およびテスト結果を定義するいくつかの詳細があります。

次の荷重タイプから選択できます。

  • 目標に基づく曲線 は、シミュレートされたユーザーの数を自動的に調整することによって、ウェブサイトが所定のスループット(トランザクション)に準拠しているかどうかを確認します。 詳細な手順については、「 目標ベースのロード テストのセットアップ」を参照してください。
  • [ステップ カーブのロード ] では、ランプ アップ/ランプ ダウン率と時間を指定することで、特定の同時ユーザ数 (要求) を手動で設定できます。 詳細な手順については、「 ロード ステップのロード テストのセットアップ」を参照してください。
  • 動的調整可能な曲線 により、テスト実行中にリアルタイムで同時ユーザー数(リクエスト)を手動で調整できます。 詳細な手順については、『 動的調整可能ロード テストのセットアップ』を参照してください。

ロードタイプを選択する方法の詳細については、「ロード テストの適切な種類の選択」を参照してください。

ロード インジェクタ ペイロード

仮想ユーザーをエミュレートするために、仮想ユーザーを実行する ロード インジェクタ サーバー (LI) を起動します。 ペイロード設定では、各 LI で実行される仮想ユーザーの数を設定します。 ペイロードが高い場合は LI CPU の使用率に影響を与え、LI オーバーロードによる無効なテスト結果を招く可能性があります。 一方、テストに使用される多数のLAは、テストコストを増加させます。 したがって、最適なペイロード値を設定することが重要です。

ペイロード値は手動で調整できますが、デバイスのキャリブレーションを実行し、キャリブレーション結果にシステムが提案した値を適用することをお勧めします。

ロードインジェクタの分布

ターゲット Web サイトがパブリック インターネットからアクセス可能かどうか、およびクラウドベースまたはオンプレミスのロード テストを探しているかどうかに基づいて、ロード トラフィックを送信する場所のタイプを選択します。クラウドベースのロード テストの場合は、[ グローバル分散] を選択します。独自のネットワーク内のマシンからテストを実行するには、 OnSite Distribution を使用します。

ロードインジェクターの地理的分布。デフォルトでは、すべてのロードトラフィックは、ランダムに割り当てられたIPアドレスを持つロードインジェクタ(LI)を使用して、自動的に選択された地理的位置から送信されます。これにより、各ロードインジェクターは独自の一意のIPアドレスを持ちます。 LIの地理的な位置を選択し、次に、異なる地理的位置間での仮想ユーザーの割り当てを選択して、トラフィック分布により適したものにすることができます。 ファイアウォールの背後でテストするには、 パブリック ネットワーク プロキシ オプションを検討してください。

ネットワークプロキシ。 使用しないでください あなたのウェブサイトが公共のインターネットから利用可能な場合、ネットワークプロキシ。あなたのウェブサイトがファイアウォールの内側にある場合、あなたは2つの選択肢から選ぶことができます。ファイアウォールの内側でWebサイトをテストする必要がある場合は、ファイアウォールを開くことができる特定のIPアドレスからのロードトラフィックを許可できます。

これを行うには、[ パブリック ] オプションを使用します。 負荷トラフィックは、専用 IP アドレスを持つロード インジェクタ サーバーから送信されます。 静的 IP アドレスの一覧を 見 つけ、IP をファイアウォールにホワイトリストに入れられます。 LoadView 静的プロキシ サーバーを使用したファイアウォールの背後のテストに関する記事で、パブリック プロキシ オプションを使用するホットを学習します。

ターゲット Web サイトがパブリック インターネットから利用できず、特定の IP に対してファイアウォールを開くことができない場合は、[
オンサイト プロキシ エージェント
 ] オプションを使用します。 LoadView オンサイト プロキシ エージェントは、ターゲット Web サイトと同じネットワーク内にインストールできます。 これにより、負荷トラフィックはローカルネットワーク内から送信されます。

概要

ロード テストの概要は、テスト シナリオ ページの右側のサイドバーにあり、ロード テスト設定の概要と、テスト構成に基づく価格見積もりを提供します。 何かを調整する場合は、変更するセクションに戻って設定を編集できます。 検証に失敗した場合は、テストを開始する前にエラーを修正します。

ロード テストの価格は、テストに必要な 仮想マシンのコスト 、 テスト期間、 および実行中にシミュレートされた 仮想ユーザーの数に 基づいて計算されます。

TOS

法的契約書を読み、チェックボックスをチェックして自分の名前を入力して、条項に同意してください。 500 ドルを超える LoadView テストでは、携帯電話番号を入力し、指定した番号に送信された確認コードを入力して、電話の確認が必要になります。 1,000 ドル以上の LoadView テストでは、指定された番号に電話をかけるサポート スタッフによる電話による音声検証が必要です。

走る

[ ロード テストの開始 ] ポップアップで、テスト完了時に通知を受け取り、開始モードを選択する電子 メール 通知セクション (オプション) に電子メールを入力するよう求められます。 ロード テストは、特定の時間 (最大 24 時間) にすぐに開始することも、後で開始することもできます。

開始時刻が延期されたテストでは、 同時実行テスト のオプションも使用できます。

テストを実行すると (即時開始)、10 分以内に開始されます (選択したリージョンに応じて最大 1 時間)。

何らかの理由でテストを停止する必要がある場合は、テスト実行の [概要] ページで [テストの中止] をクリックします。 ただし、リスが開始されている場合( ロード インジェクタの開始 ステータス)、テスト価格はウォレットから損金処理されます。

テストの開始時には、次に説明する一連のステータスを確認します。

  • テスト要求の送信 – テスト設定をサーバーに送信して実行します。
  • 初期化します。
  • スケジュール済み – テストは指定された時刻の実行を待機しています。
  • ロード インジェクタの起動 – 必要な数の仮想サーバーをセットアップし、仮想ユーザーをデプロイする信号をクラウド プロバイダーに送信します。 この手順は、多くの時間(最大 1 時間)を要する可能性があり、電子メール通知が完了したら電子メールを受信するように指定することをお勧めします。
  • 実行プランの送信 – LoadView のシナリオとタスクを LI に送信します。
  • 実行中 – テストが実行されると、 訪問者数、 エラー 数 (存在する場合)、 デバイスの応答時間など、LoadView メトリックがリアルタイムで更新されたグラフが表示されます。
  • データの処理 – テストが終了すると、仮想サーバーからすべての応答がサーバーにアップロードされ、より詳細な分析とレビューのためにそれらの応答が表示されます。 データ保持期間は、有料版の場合は 365 日、試用版では 31 日間です。 LoadView テストでは多くの応答データが生成されるため、この手順には時間がかかる場合があります。
  • 終了しました。

テストが完了すると、[ ロード テスト レポート ] ページに対応するメッセージが表示されます。

ロード テストの結果

「テスト・シナリオ・マネージャー」ページからテスト・レポートをプルするには、「アクション」メニューから、または対応するテスト・インスタンスのクイック・アクション・メニューから「レポート」を選択します。 テスト レポートは、左側のサイドバーの [レポート] メニューの一覧にも表示されます (「 ロード テスト結果の確認」を参照)。


  • ロードビューを使用した Web パフォーマンス (負荷およびストレス) テスト

    経験則として、Web サイトのパフォーマンス テストには次の項目が含まれます。

    • ロードテスト
    • ストレステスト

    Web サイトまたは Web アプリケーションのロード テストは、多数のユーザーが同時に同じ Web リソースに対して要求を行う場合のパフォーマンス テストの一種です。 ロード テストは、Web アプリケーションがパフォーマンスを損なうことなくピーク負荷を処理できるかどうかを調べるのに役立ちます。

    Web アプリケーションのストレス テストは、負荷を増やしてサイトまたは Web アプリケーションの障害を発生させ、Web アプリケーションのパフォーマンスの限界を評価するために実行されます。 Web アプリケーションをストレス テストする場合、ロード レベルは Web アプリの運用負荷よりも大幅に高くなります。 ストレス テストは通常、ストレスに対する Web アプリの応答と、障害から回復する方法を確認するために使用されます。

    一般に、ロード テストには次の手順が含まれます。

    1. ロード テストの目標と要件の設定。
    2. ロード パターンを選択する。
    3. テスト環境のセットアップ
    4. 負荷テストツール/ストレステストツールの選択
    5. ロード テスト シナリオを作成する。
    6. ロード テスト/ストレス テストを実行しています。
    7. 結果分析。

    まず、テスト環境のセットアップを開始し、使用するロード テスト ツールを探す前に、テストの結果として正確に何を受け取りたいのかを決定する必要があります。 次の質問に注意を払うことをお勧めします。

    1. ターゲット Web アプリケーションにどの程度の負荷がかかると予想されますか? たとえば、パフォーマンスを低下させることなく、Webサイトが1時間あたりに処理する必要がある訪問数などです。 Web 分析を同時ユーザーに翻訳する方法については、 こちらをご 覧ください。
    2. 負荷レベルに応じて、どのレベルのパフォーマンスが必要か。例えば、対象Webサーバの応答時間、ウェブページの読み込み時間の平均、ウェブ要素の読み込み時間などである。
    3. ウェブサイトが使用される条件をどのように説明しますか? ターゲット Web サイトはインターネットから利用できますか、それともローカル ネットワーク内からのみ利用できますか。 ウェブサイトへのリクエストはどの地域から来ていますか? ネットワーク調整の最も可能性の高いタイプは何ですか。 Web リソースは、ブラウザー ウィンドウ内の実際のユーザーによって、または API を介してサードパーティ製のアプリケーションによって使用されますか。
    4. 負荷テストとストレステストを実行する必要がある頻度は? つまり、更新をロールアウトする頻度、Web コンテンツの変更、および Web サーバーの構成を決定する必要があります。

    ロード テストで考慮すべき最も重要な問題の 1 つは、実際のユーザー側からの実際の状況での Web アプリケーションのパフォーマンスです。 最新の Web アプリケーションを詳しく見て、対話型の Web アプリケーションをテストするために HTTP レベルのロード テストを使用するだけでは不十分である理由を説明しましょう。

    実際のブラウザでの Web アプリケーションのロードとストレス テストと HTTP レベルのロード テスト

    Web アプリケーションは、クライアント/サーバー アーキテクチャを持つ Web ベースのアプリケーションです。 原則として、Web ブラウザーはクライアントであり、Web サーバーはサーバーです。

    Web アプリケーションは Web サーバー上で実行されます。 一般に、Web サーバー側は、Web アプリケーションのビジネス ロジック 、つまりクライアント要求に対する対応方法を担当します。 クライアントから HTTP 要求を受信し、要求を処理し、対応する応答をクライアントに送り返します。

    その結果、クライアント側は、サーバーからの応答で受信したデータをレンダリングして、グラフィカルな人間に優しい形式でユーザーに配信します。 サーバーからの応答を受信すると、ブラウザー (クライアント) は Web サーバー応答に含まれるデータを処理します。 HTML、CSS、JavaScript 技術は、最新の Web ページを実装する Web 開発で最も頻繁に使用されます。 したがって、ブラウザウィンドウでユーザーに情報を配信するために、WebブラウザはHTMLコンテンツをレンダリングするだけでなく、JavaScriptを実行し、CSSを使用してデータを適切な方法で表示します。

    Web アプリケーションの自動ロードテストとストレス テストを実行するために広く使用されているアプローチとして、HTTP ベースのテストと実際のブラウザ ベースのテストの 2 つがあります。

    最初の HTTP ベースのアプローチでは、Web 開発者や QA エンジニアは、実際のユーザーがブラウザー ウィンドウ (フロントエンド) で表示する Web アプリのグラフィカル インターフェイスを操作せずに、直接 Web サーバー (バックエンド) に HTTP 要求をエミュレートできます。 一般に、HTTP ベースのロード テストアプローチでは、Web サイト上のいくつかのトランザクションで実際のユース ケースをシミュレートするために、技術的な背景とコーディングの経験が必要です。 一方、ユーザーの負荷の高さをシミュレートするために多くのリソースを必要としません。

    まったく逆に、ブラウザーベースのアプローチは、実際のユーザーと Web アプリのフロントエンドとの対話をシミュレートして、現実的なテスト シナリオを作成します。 この場合、Web ブラウザーの複数のコピーがインスタンス化され、ブラウザー・ウィンドウでユーザー・アクションが自動的に実行されます。 ロード インジェクタ マシンで複数のブラウザ コピーを実行するには、より多くのサーバー リソースが必要なため、Web サイトや Web アプリケーションのロード テストにクラウドベースのサービスをオンラインで使用することをお勧めします。

    最新の Web アプリケーションのフロントエンド指向の性質を考慮すると、バックエンドのロード テストだけでは、負荷の下で発生する可能性のあるパフォーマンスの問題をすべて完全にカバーするだけでは不十分です。 さらに、単一ページアプリケーション、いわゆるSPAなどのWebアプリケーションは、Webブラウザによって実行されるJavaScriptに完全に依存しており、ブラウザを実行しないと正しくテストすることはできません。

    実際のブラウザでのロード テスト Web サイトを使用すると、クライアント側の Web サイトの機能を確認し、Web ページのコンテンツが読み込まれ、テキスト要素、画像、RIA 要素、Web フォームなど、正しく機能していることを確認できます。 ブラウザーベースのロード テストとストレス テストのアプローチにより、Web アプリケーションとの実際のユーザー操作をシミュレートし、トラフィックの多い時間帯にユーザーが Web アプリのパフォーマンスを損なわないことを確認できます。 また、実際のブラウザーでロード テストを実行すると、Web アプリのコンテンツ表示の正確性を確認し、異なるデスクトップブラウザーやモバイル ブラウザーで負荷が高い状態で機能することができます。

    オンライン負荷およびストレス テスト用の LoadView ソリューション

    LoadViewは、Webサイトの負荷とストレステストのためのオンラインクラウドベースのソリューションです。 Web 開発者およびソフトウェアテスターが、ビジネス アプリケーション、Web ポータル、API、オンライン ストリーミング メディア、Web サービスなど、Web サイトのテストを設定して実行するための信頼性の高いツールです。 このツールは、動的に変更されるコンテンツ、SPA、パブリックインターネットからは利用できないウェブサイトなど、RIAアプリケーションのロードテストをサポートします。

    クラウドでのテスト 最新の Web サイトや Web アプリケーションは、多くの場合、クラウドに配置されている分散システムです。 このような Web サイトをロード テストするには、LoadView は Amazon および Azure クラウド サービスのロード インジェクタ サーバーを使用します。 これにより、多数の仮想ユーザーがターゲット Web リソースに同時にアクセスして、負荷テストとストレス テストを実行できます。 LoadView は、20 以上の世界中の分散地理的場所からのテストをサポートし、テスト条件を可能な限りユーザー プロファイルと同様にします。

    ファイアウォールの背後での負荷テスト: ファイアウォールで保護されたロード テスト Web サイトの場合、LoadView は、事前に決定された IP アドレスを持つロード インジェクタ サーバーからの負荷テストとストレス テストを提供します。 したがって、すべての着信トラフィックに対してファイアウォールを開く必要はありません。

    ローカル ネットワーク内からロード テストを行います。 LoadView は、パブリック インターネットからは利用できないテスト Web サイトをロードする LoadView オンサイト エージェント ソフトウェアを提供します。 オンサイト エージェント ソフトウェアは、企業ネットワーク内のローカル コンピュータにインストールできます。 会社のネットワーク内部から LoadView サービスへの接続を実行し、LoadView ロード インジェクタから負荷トラフィックを受信するためにこの接続を使用します。 ここでは、任意の着信トラフィックのためにファイアウォールを開く必要はありません。

    実際のブラウザでのロードとストレステスト。 HTTP ベースのロード テストに加えて、LoadView は実際のブラウザーでの負荷テストとストレス テストをサポートします。 LoadViewを使用すると、テスト要件に応じて、40以上の異なるデスクトップおよびモバイルブラウザからWebアプリにアクセスする仮想ユーザーをエミュレートすることができます。

    テスト シナリオを簡単に作成できます。 LoadView は、EveryStep Web レコーダー ツールを使用して、ロード テスト スクリプトをブラウザー ウィンドウに記録します。 このツールを使用すると、複数のデスクトップブラウザーやモバイルブラウザーで実行できるコーディングを使用せずに、複雑なロードテストを作成できます。 組み込みのコード スニペットを使用してスクリプトをカスタマイズして、ネットワーク フィルター、ユーザー遅延、応答修飾子などを追加できます。 さらに、スクリプトの記録中に別の種類のパスワードや個人情報を保護するために、LoadViewはセキュアなヴォールトオプションを提供しています。 セキュアな Vault オプションを使用すると、記録されたロード テスト スクリプトで使用される機密情報を暗号化された形式で保存できます。

    Web ページのコンテンツの検証。 場合によっては、ロード テスト中にターゲット Web リソースが使用可能で、Web ページが読み込まれることを確認するだけでは不十分な場合があります。 Web ページのコンテンツがエラーなく読み込まれ、動的な Web 要素がページ上で正しく機能していることを確認する必要がある場合は、コンテンツまたは RIA 検証を使用する必要があります。 Web アプリケーションロードテストのスクリプトを記録したり、HTTP ベースのロードテストを構成したりする際に、LoadView では、ページ上のテキストコンテンツを検証するためのキーワード検証を設定できます。 イメージの検証と RIA 要素の検証は、EveryStep Web レコーダー ツールで提供されます。 ページ上で必要なキーワードまたはイメージを選択すると、ロード テストの実行中に要素が正しく読み込まれているかどうかがシステムによって確認されます。 検証時にエラーが検出された場合、対応するレコードがロード テスト レポートに追加されます。

    実際のユーザーの動作をシミュレートする。 実際の Web サイトパフォーマンスに対応する Web ページと Web サイトのロード テストの現実的な結果を提供する LoadView は、ユーザー動作オプションを提供します。 最大速度ユーザー プロファイルを使用すると、できるだけ高速にサーバーに HTTP 要求をシミュレートすることで、ターゲット Web サーバーに負荷を与えます。 ターゲット Web リソースで実際のユーザー エクスペリエンスを再現するには、通常のユーザー プロファイルをお勧めします。 Web サイト上のユーザー アクション間にカスタム遅延を設定して、できるだけ現実的なロード シナリオを作成できます。 システムは、ユーザーの遅延を “移動” と “移動” アクションの間に追加します。 したがって、Web サイトへの HTTP 要求は、ターゲット Web サイトの動作条件に近いパターンで生成されます。

    Web アプリケーションのロード テスト用のスクリプトを記録する場合は、EveryStep Web レコーダー ツールでユーザーの動作設定を使用できます。 マウスの移動速度、マウスクリック、テキストタイプの速度などのパラメータを指定したり、スクリプトステップ間の遅延を設定したりできます。

    さまざまな負荷パターン。 LoadView を使用すると、ロード パターンの 3 つの種類を取得します。

    • 荷重ステップ曲線
    • 目標ベース
    • ダイナミック調整可能曲線

    ロード テストの目標に応じて、対応するパターンを使用して Web サイトのブレークポイントを見つけたり、トラフィックピーク時にユーザーロードをシミュレートしたり、SLA や非機能要件への準拠を確認したりできます。

    ロード テスト レポート。 ロード テストの結果は、さまざまなレベルの負荷の下でターゲット Web サイトのパフォーマンス特性を分析できるように、ロード テスト セッション レポートとグラフの形式で視覚的な形式で表示されます。 レポートを使用すると、Web サイトの日常業務で問題を引き起こす可能性のあるボトルネックを特定して排除し、ハードウェアとソフトウェアの構成を最適化できます。 レポートには、次のロード テスト結果が表示されます。

    • 時間間隔ごとにエミュレートされた仮想ユーザーの数を含む実行プラン。
    • 時間間隔ごとに計算された平均応答時間。
    • エラーのあるセッションや正常に実行されたセッションを含む、実行されたセッションの数。
    • 成功したセッションとエラーのあるセッションの合計数を含む、累積セッション数。
    • ロード テストの結果を確認するために LoadView ロード インジェクタ サーバーに登録された CPU 負荷メトリック。
    • 要素別の詳細な要素グラフと参照ビデオ (Web アプリのロード テストの実行) を含むセッション レポート。

    ロード テストの概要レポートと生データ レポートをコンピューターにダウンロードできます。

    サブスクリプション プラン。 LoadViewを使用すると、オンデマンドテストに使用できるクレジットで$ 20を提供することで、無料であなたのウェブサイトのストレステストを開始することができます。 この量では、デフォルトのパラメータを使用して、いくつかの簡単なテストを実行できます。 カスタマイズされたパラメーターを使用してソリューションを使用し続けるには、毎月または年間のサブスクリプションにサインアップするか、テストの実行ごとに支払うオンデマンド パッケージを続行する必要があります。