ページを選択

HTTP ロード テストは、ウェブ サイト、アプリケーション、および ウェブ サービスのパフォーマンス テストを行い、アプリケーション インフラストラクチャに関する情報に基づいた意思決定を計画、準備、および決定する方法として行ってきました。 しかし、継続的に進化するテクノロジースタックとインタラクティブなコンテンツでは、従来のHTTPロードテストの方法は、すべてのベースをカバーするのに十分ですか? 短い答えはノーです。 HTTP ロード テストの最新のアプローチとその方法を理解するための詳細な方法で回答をレイアウトするには、基本から始めましょう。

 

静的ページと動的ページ

静的 ウェブ ページは、すべての ウェブ サイトリソースを開始した最も単純な形式です。 これらは、基本的な HTML、CSS、および Java スクリプトで記述されています。 手動で変更を行うまで、これらのページに大きな変更は加えず、サーバーの終わりからこれらのページにコンピューティングや処理を行う必要はありません。 これらのページは、基本的な要求と応答メカニズムを使用してブラウザーによってレンダリングされます。 ブラウザーは要求を送信し、サーバーは、事前に構築された HTML コードを送信する以外に、実際には何も追加せずに応答します。 例としては、ブログページ、ドキュメントページ、個人ウェブサイトなどがあります。

一方、動的ページは、ユーザーからの後続の各要求に対して、対話的なリソースと要素を提供します。 動的ページを作成するための今日より一般的な技術のいくつかは、AJAX、 AngularJSVueJSReactJSなどです。 動的ページコンテンツは、時間、地域、ユーザー プロファイルなど、さまざまな要因やユース ケースに基づいて生成されます。 これらの例には、ソーシャルメディア、電子商取引、ゲームウェブサイト、ストリーミングウェブサイト、その他の最新のアプリケーションが含まれます。

 

動的ページを使用した最新アプリケーションの進化

静的ページと動的ページから議論を続け、最新のアプリケーションの機能と動作を理解しましょう。

 

ランタイムの変更

静的ページは実行時に変更されませんが、最新のアプリケーションではさまざまなプロファイリング要因に基づいてコンテンツが変更されます。

 

相互作用

静的ページにはクリックベースの操作はほとんどありませんが、最新のアプリケーションには、ゲームからビデオプレーヤー、電子商取引まで、さまざまなインタラクティブな機能があります。

 

モジュラー

静的ページは、毎回、どこでも、そしてすべての人にとって同じです。 動的ページは、ユーザー操作とユーザー トランザクションに基づいて複数のサービスと機能を追加できます。

 

サードパーティサービス

最新のアプリケーションでは、動的に変更およびアクセスできるサードパーティのサービスを多用しています。

 

建築

静的アプリケーションは、最も単純な形式の GET/POST HTTP 要求を使用します。 これに対し、最新のアプリケーション要求と応答には、認証、VPN、リアルタイムコラボレーションなど、複数のサービスが互いに組み合っています。

 

単一ページ アプリケーションの台頭

シングルページ アプリケーション (SPA) は、ユーザーナビゲーションを最小化したり、ページ間のナビゲーションをなくしたりするために、アプリケーションを開発する最も一般的で広く使用されています。 すべてのコンテンツのレンダリングとトランザクションは、サーバーがすぐに使用できる HTML コードを提供するのではなく、ブラウザ自体の中で多くの処理を行うことによって同じページで発生します。

SPAは、ブラウザで1ページで重い持ち上げを行うことで、ウェブサイトの機能を変革しました。 また、従来の HTTP ロード テスト ツールでは、ブラウザ ベースのコンピューティングをレンダリングおよび実行することができないため、HTTP ロード テストの課題が生まれます。 これは、動的アプリケーション、特に SPA の HTTP ロード テストの新しいメソッドを必要とします。

 

HTTP ロード テストの課題: ロード テストの SPA

動的ページを広範に使用する場合、最も現実的なロード環境を作成するための HTTP ロード テストの新たな課題が SPA に提示されます。 従来の HTTP ロード テストを過去のものにする重要なポイントを次に示します。

 

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

これまでに説明したように、SPA は、サーバーではなく JavaScript を使用してブラウザによる HTML の計算の負荷が高いという問題に依存しています。 これにより、クライアントとサーバー間の対話が劇的に変化しました。 アプリケーションの GET/POST 負荷を効果的かつ正しく生成するには、実際のブラウザーからテスト ユーザーをシミュレートするツールを使用する必要があります。

 

ロケーションベースのロードテスト

おそらく、SPA は、コンテンツをカスタマイズするために場所ベースのデータを考慮に入れるでしょう。 たとえば、通貨や現地の取引、および取引の様々なパフォーマンスなどです。 複数の場所からの実際のブラウザー ベースのロード テストでは、アプリケーションが 地理的位置 のパフォーマンスを最適化するための現実的な負荷が生成されます。

 

トランザクションベースのロード テスト

個々のアクションおよびパラメータベースのアクションに対するスクリプトを使用したユーザーアクションのマッピングは、ロードテストのSPAの重要な部分です。 たとえば、e コマース ウェブ サイトで現実的な負荷を生成する場合、フィルターと並べ替えの組み合わせでページを読み込んで、トラフィックの多い ウェブ サイトのパフォーマンスにどのような影響を与えるかを確認します。

 

RIA ロードテスト

お客様の SPA は、ビジネス要件に従って進化します。 ある日、あなたはビデオコンテンツを持っているだろうし、別の日にあなたは投票コンテストを持つことになります。 ゲームアプリケーションであれば、あらゆる種類のユーザーの操作とレンダリングが行われます。 ロード テスト ソリューションでは、ブラウザーでレンダリングおよび実行できるほとんどすべてのテストを実行できる必要があります。

 

 

HTTP ロード テストでは不十分な理由: 最新の動的アプリケーションのロード テスト

従来の HTTP ロード テストでは、これらの要因と要件に基づいて現実的な負荷を生成することはできません。 これらの課題には、すべてを総合的に組み合わせて最も現実的な負荷を生み出す新しい包括的なアプローチが必要です。 多くの場合、SPA には、多層的なテクノロジ スタックと RIA テクノロジを使用して、ユーザーの革新的な方法や問題の解決方法が含まれています。 したがって、従来の HTTP ロード テストはテスト目的を果たすのが困難です。 この問題を解決するには、実際のブラウザや複数の場所から実際のトランザクションや対話を記録できるプラットフォームが必要です。 これらのトランザクションやスクリプトの記録の容易さも、このようなプラットフォームを選択する上で重要な役割を果たします。それ以外の場合は、実際の HTTP ロード テストではなく、時間のスクリプティングを無駄にします。

LoadView には、簡単なポイントを使用してロード テスト シナリオを作成する EveryStep Web レコーダー が付属しており、スクリプトをクリックするだけで、間もなく作業できます。 LoadViewを使用すると、複数の場所から実際のブラウザからユーザーをテストして、アプリケーションが正常に動作していることを確認し、遅れやボトルネックを伴うことなく、ストレスの下で正確なコンテンツを提供することもできます。 EveryStep Web Recorder と LoadView プラットフォームの組み合わせにより、包括的なロード テスト プラットフォームが作成され、すべてのロード テストのユース ケースで一貫して正しく実行するために必要なすべてをプロアクティブに把握できます。

LoadViewプラットフォームを今すぐ試してみて、 ロードテストクレジットで20ドルを受け取って 始めましょう!