ユーザーエクスペリエンスに関しては、 ウェブ アプリケーションのスムーズで安定した機能を体験することほどユーザーにとって重要なことはありません。 これらの側面は、Web サイトや ウェブ アプリケーションの基本的な部分のようなものであり、その成功に不可欠です。 ただし、より多くのユーザーがアプリケーションにアクセスし始めると、より多くのリソースが使用され、通常は速度が低下します。 奇妙なシステムエラーメッセージ、タイムアウト、 ページ応答の遅さ、サーバーエラーが発生し始めたため、ユーザーにとってはひどい経験です。 これらすべてから私たちを救うために 問題、機能テストを次のステップに進め、次のような非機能テストを実行する必要があります 負荷テストまたはストレス テストこれは、アプリケーションが多数の 同時ユーザー数、およびトラフィックのスケーリングに伴うシステムの応答方法を決定します。
ロード テストの旅を始める前に、運用環境に近い アプリケーションのストレス テストをシミュレートする方法に関するベスト プラクティスを理解することが重要です。 基本的な パフォーマンス テスト 戦略には、次のような質問に答えることが含まれます。
- ロード テストに必要な同時ユーザーの数。
- 実際のユーザー テスト シナリオをシミュレートします。
- 地理的に分散された仮想負荷。
- 期間を増減します。
- テスト期間。
これらのそれぞれについて説明し、ロード テストを実行する前に チェックリストに含める必要がある理由を理解し ましょう。
ロード テストに必要な同時ユーザー
実際のユーザーの行動に近いテストを設定する前に、テストのためにシミュレートするために必要な同時ユーザーの数を把握するために時間を費やす必要があります。 同時ユーザーは、当社のWebサイトまたは ウェブ アプリケーションを閲覧し、特定の期間にトランザクションを実行するユーザーの数を定義します。 サイトとアプリケーションへのトラフィックは週を通して増減する可能性がありますが、サイトとアプリケーションを適切にテストするには、トラフィックのピーク時間を超えるようにテストを構成する必要があります。 しかし、どのようにして正しい同時ユーザー数を正しく見つけるのでしょうか。
Web分析ツールを使用して、Webサイトの現在のトラフィック統計を特定し、訪問数、ウェブ サイトでのセッション時間などの詳細を確認できます。 Google アナリティクスや他の多くの分析ツールでは、定期的なタイムスタンプ、平均セッション時間、ユーザーがウェブサイトで費やした時間ごとに、ウェブサイトが持つセッション指標を提供できます。 次の式を使用して、同時ユーザー数を見積もることができます。
同時ユーザー = 時間単位のセッション x 平均 セッション時間 (分単位)/60
ウェブ 分析データがない場合は、予想されるユーザー訪問数を使用して、同時ユーザーの数を計算できます。
同時ユーザー数 = 分あたりの予想訪問数 * 訪問時間 (分)
現在のユーザーの構成に関する詳細とヒントについては、ナレッジベースにアクセスし、ウェブ 分析からの同時ユーザーの計算に関する記事をお読みください。
実際のユーザー テスト シナリオのシミュレーション
同時ユーザーの準備が整ったので、ストレス テストの一部となる頻繁でトラフィックの多いテスト シナリオを見つける必要があります。 すべての状況で多くのスクリプトを使用する必要はないことに注意してください。 通常、すべてのトランザクションの実際の負荷を決定するために必要なユースケースはごくわずかです。
同時ユーザーの適切なレベルを決定したら、テスト対象のアプリケーションに基づいて、適切なロード テスト タスク シミュレーション アプローチを選択する必要があります。
Web アプリケーションと Web ページのロード テスト
Web アプリケーションと ウェブ サイトのユーザー シナリオとトランザクションをシミュレートするには、テスト シナリオをシミュレートするためのユーザー体験をスクリプト化する必要があります。 このユース ケースでは、ブラウザーの操作を記録し、ロード テストに使用できるスクリプトを作成する EveryStep Web レコーダーを使用できます。 EveryStep Web レコーダーは使いやすいですが、最も複雑なシナリオをスクリプト化することができます。 さらに、ユーザーは遅延の設定、キーワードやフィールド変数の編集、ネットワークスロットリングの設定などを行うことができます。 EveryStep Web レコーダーを使用したスクリプトの編集の詳細については、ナレッジ ベースで詳細を確認してください。
Web ページのロード テストを実行するために、チームは LoadView の Web ページ オプションを使用して、同時ユーザーで ウェブ ページをテストするプロセスを開始できます。ウェブ
さらに、 LoadView プラットフォームを使用すると、開発チームはテスト API とストリーミング メディアを読み込むことができます。 APIおよびストリーミングメディアページの詳細については、製品ページをご覧ください。
地理分散型仮想負荷
すでにご存知かもしれませんが、ネットワーク遅延はWebサイトに大きな影響を与えるため、ストレステストでは、同時ユーザーが地理的に分散した負荷を無視してはならず、本番環境で見られるのと同じ動作をシミュレートし、データセンターから遠く離れた場所にいるユーザーの応答時間を確認します。 更新時に 2 MB のコンテンツをダウンロードし、バックエンド要求ごとに 10 ミリ秒をダウンロードする ウェブ ページについて考えてみます。 データセンターの読み込み時間は、近接性と低遅延のため、5秒未満になります。
アジアなど、遅延が200ミリ秒の海外の特定の場所では、このWebサイトの応答時間は、バックエンドで5秒、ネットワーク転送で200ミリ秒を超えます。 間違えてはならず、データセンター内でのみ応答時間を測定する必要があります。 ここでは、世界中の幅広いロードインジェクションマシンを提供するLoadViewを使用できます。 これらすべてのオプションから、お客様の通常の場所を表すすべてのオプションを選択できます。
スケール間のランプアップ期間
通常、当社のWebサイトにはさまざまな時間帯に同時ユーザーが分散しており、トラフィックが最も多いピーク時間はほとんどありません。 同じアプローチを使用して、同じランプアップ戦略を使用してアプリケーションをスケールアウトおよびストレステストする必要があります。 LoadView を使用すると、ランプアップ、ホールド時間、およびランプダウンする必要があるレートを設定できます。
ロード テスト期間
テスト期間は、応答時間、スループットなどの詳細を含む現実的な結果を生成するためにアプリケーションに十分な時間を提供し、アプリケーションにキャッシュメカニズムが存在する場合は、ランプアップ期間中にキャッシュされるため、ロードテスト中に非常に重要な要素です。 テスト期間を決定するには、テストシナリオと要件を楽しみにする必要があります。 ロード テストのテスト期間を決定する際に、次のケースを検討できます。
- 各要求/テストステップが少なくとも10回実行されることを確認する必要があります。 小規模なシナリオと比較して、長いシナリオのテスト期間を長く保つ必要があります。
- また、アプリケーションの安定性とパフォーマンスの特性を長期間にわたって検証する必要がある場合は、より長い期間を設定する必要がある可能性があるため、実行する予定のロード テストの種類を決定する必要があります。
- 上記のように、アプリケーションをウォームアップするために、常に数分のバッファーを追加してください。
まとめ:WebサイトまたはWebアプリケーションのトラフィックを適切にシミュレートする方法
ご覧のとおり、ロード テストを設定して実行する前に考慮する必要がある多くの要因があります。 ウェブ アプリケーションとサイトが顧客にとって完璧に機能することを保証することは、ビジネスの成功に不可欠です。 LoadView プラットフォームは、テストを設定するためのステップ バイ ステップ プロセスをすばやく簡単に説明できるように設計されています。 プラットフォームは、実際のシナリオを設定し、複数の場所からのパフォーマンスを測定するのに役立ちます。
LoadView 無料試用版 にサインアップして無料のロード テストを開始するか、LoadView デモにサインアップします。 パフォーマンスエンジニアの1人がソリューション全体を順を追って説明し、プラットフォームに関する質問に答えたり、ロードテストプロセスに関する特定の質問に答えたりします。