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