load testing complete guide
初心者向けの完全な負荷テストガイド：
このチュートリアルでは、負荷テストを実行する理由、それから何が達成されるか、アーキテクチャ、負荷テストを正常に実行するために従うべきアプローチ、負荷テスト環境のセットアップ方法、ベストプラクティス、および市場で入手可能な最高の負荷テストツール。
機能テストと非機能テストの両方のタイプについて聞いたことがあります。非機能テストでは、パフォーマンステスト、セキュリティテスト、ユーザーインターフェイステストなど、さまざまな種類のテストがあります。
したがって、負荷テストは、パフォーマンステストのサブセットである非機能タイプのテストです。
したがって、アプリケーションのパフォーマンスをテストしていると言うとき、ここでテストしているのは何ですか？アプリケーションの負荷、ボリューム、容量、ストレスなどをテストしています。
学習内容：
負荷テストとは何ですか？
負荷テストはパフォーマンステストのサブセットであり、アプリケーションに同時にアクセスする複数のユーザーをシミュレートすることにより、さまざまな負荷条件下でシステムの応答をテストします。このテストは通常、アプリケーションの速度と容量を測定します。
したがって、負荷を変更するたびに、さまざまな条件下でのシステムの動作を監視します。
例 ：ログインページのクライアント要件が2〜5秒であり、この2〜5秒は、負荷が5000ユーザーになるまでずっと一貫している必要があると仮定します。では、何を観察する必要がありますか？それはシステムの負荷処理機能だけですか、それとも応答時間の要件だけですか？
答えは両方です。すべての同時ユーザーに対して2〜5秒の応答時間で5000ユーザーの負荷を処理できるシステムが必要です。
では、同時ユーザーと仮想ユーザーとはどういう意味ですか？
同時ユーザーとは、アプリケーションにログインし、同時に一連のアクティビティを実行し、同時にアプリケーションからログオフするユーザーです。一方、仮想ユーザーは、他のユーザーアクティビティに関係なく、システムに乗り降りするだけです。
負荷テストアーキテクチャ
次の図では、さまざまなユーザーがアプリケーションにアクセスしている様子を確認できます。ここでは、各ユーザーがインターネットを介してリクエストを行っており、後でファイアウォールを通過します。
ファイアウォールの後に、任意のWebサーバーに負荷を分散し、アプリケーションサーバーに渡し、後でデータベースサーバーに渡して、ユーザーの要求に基づいて必要な情報を取得するロードバランサーがあります。
負荷テストは、手動およびツールを使用して実行できます。ただし、負荷が少ないかどうかアプリケーションをテストしないため、手動の負荷テストはお勧めしません。
例：オンラインショッピングアプリケーションをテストして、ユーザーがクリックするたびにアプリケーションの応答時間を確認するとします。つまり、ステップ1 – URLの起動、応答時間、アプリケーションへのログイン、応答時間の記録などを選択します。製品、カートへの追加、支払い、ログオフ。これらはすべて、10人のユーザーに対して行う必要があります。
したがって、10人のユーザーのアプリケーションの負荷をテストする必要がある場合、ツールを使用する代わりに、異なるマシンから10人の物理ユーザーが手動で負荷をかけることでこれを実現できます。このシナリオでは、ツールに投資してツールの環境を設定するのではなく、手動の負荷テストを行うことをお勧めします。
1500ユーザーの負荷テストが必要な場合は、アプリケーションが構築されているテクノロジーとプロジェクトの予算に基づいて、利用可能なツールのいずれかを使用して負荷テストを自動化する必要があります。
予算があれば、Load runnerのような商用ツールを選ぶことができますが、予算があまりない場合は、JMeterなどのオープンソースツールを選ぶことができます。
qaテストリードインタビューの質問と回答
商用ツールであろうとオープンソースツールであろうと、ツールを完成させる前に詳細をクライアントと共有する必要があります。通常、概念実証が準備されます。ここでは、ツールを使用してサンプルスクリプトを生成し、ツールを完成させる前に、ツールの承認を得るためにサンプルレポートをクライアントに表示します。
自動負荷テストでは、リアルタイムのユーザーアクションを模倣する自動化ツールを使用してユーザーを置き換えます。ロードを自動化することで、時間だけでなくリソースも節約できます。
以下は、ツールを使用してユーザーを置き換える方法を示す図です。
なぜ負荷テストなのか？
ユーザーがアプリケーションにログインし、さまざまな製品カテゴリを閲覧し、製品を選択し、カートにアイテムを追加し、チェックアウトしてログオフできる、通常の営業日中にかなりうまく機能しているオンラインショッピングWebサイトがあると仮定しましょう。許容範囲であり、ページエラーや膨大な応答時間はありません。
その間、ピークの日が来ます。たとえば、感謝祭の日があり、システムにログインしている何千人ものユーザーがいて、システムが突然クラッシュし、ユーザーの応答が非常に遅くなり、一部のユーザーは応答できませんでした。サイトにログインすると、カートへの追加に失敗したものと、チェックアウトに失敗したものがあります。
したがって、この大事な日に、会社は多くの顧客と多くのビジネスも失ったため、大きな損失に直面しなければなりませんでした。これはすべて、ピーク日のユーザー負荷を予測しなかったという理由だけで発生しました。会社のWebサイトで負荷テストが行われなかったと予測したとしても、アプリケーションが処理できる負荷の量がわかりません。ピークの日に。
したがって、このような状況に対処し、莫大な収益を克服するために、このようなタイプのアプリケーションの負荷テストを実施することをお勧めします。
- 負荷テストは、強力で信頼性の高いシステムの構築に役立ちます。
- システムのボトルネックは、アプリケーションが稼働する前に事前に特定されています。
- これは、アプリケーションの容量を特定するのに役立ちます。
負荷テスト中に何が達成されますか？
適切な負荷テストを行うことで、次のことを正確に理解できます。
- システムが処理できる、またはスケーリングできるユーザーの数。
- 各トランザクションの応答時間。
- システム全体の各コンポーネントは、負荷の下でどのように動作しますか。つまり、アプリケーションサーバーコンポーネント、Webサーバーコンポーネント、データベースコンポーネントなどです。
- 負荷を処理するのに最適なサーバー構成は何ですか？
- 既存のハードウェアで十分か、追加のハードウェアが必要かどうか。
- CPU使用率、メモリ使用量、ネットワーク遅延などのボトルネックが特定されます。
環境
テストを実行するには、専用の負荷テスト環境が必要です。ほとんどの場合、負荷テスト環境は実稼働環境と同じであり、負荷テスト環境で使用可能なデータは、同じデータではありませんが、実稼働と同じになるためです。
SIT環境、QA環境など、複数のテスト環境があります。これらの環境は同じ本番環境ではありません。負荷テストとは異なり、機能テストや統合テストを実行するために、それほど多くのサーバーやテストデータを必要としないためです。
例：
実稼働環境には、3つのアプリケーションサーバー、2つのWebサーバー、および2つのデータベースサーバーがあります。 QAには、アプリケーションサーバーが1つ、Webサーバーが1つ、データベースサーバーが1つしかありません。したがって、本番環境と等しくないQA環境で負荷テストを実行した場合、テストは無効であり、正しくないため、これらの結果を確認することはできません。
したがって、本番環境と同様の負荷テスト専用の環境を常に用意するようにしてください。
また、システムが呼び出すサードパーティアプリケーションがある場合もあります。そのような場合、データの更新やその他の問題やサポートについてサードパーティベンダーと常に連携できるとは限らないため、スタブを使用できます。
準備ができたら環境のスナップショットを撮ってみてください。そうすれば、環境を再構築するときはいつでも、このスナップショットを使用できます。これは時間管理に役立ちます。 Puppet、Dockerなどの環境をセットアップするために市場で入手可能なツールがいくつかあります。
アプローチ
負荷テストを開始する前に、システムで負荷テストがすでに実行されているかどうかを理解する必要があります。以前に負荷テストが行われた場合は、応答時間、収集されたクライアントとサーバーのメトリック、ユーザーの負荷容量などを知る必要があります。
また、現在のアプリケーション処理能力についての情報も必要です。新しいアプリケーションの場合、要件、目標負荷、予想される応答時間、およびそれが実際に達成可能かどうかを理解する必要があります。
既存のアプリケーションの場合は、サーバーログから負荷要件とユーザーアクセスパターンを取得できます。ただし、新しいアプリケーションの場合は、ビジネスチームに連絡してすべての情報を入手する必要があります。
要件が決まったら、負荷テストをどのように実行するかを特定する必要があります。それは手動で行われますか、それともツールを使用して行われますか？負荷テストを手動で実行するには、多くのリソースが必要であり、非常にコストもかかります。また、何度も何度もテストを繰り返すことも難しいでしょう。
したがって、これを克服するために、オープンソースツールまたは商用ツールのいずれかを使用できます。オープンソースツールは無料で利用できます。これらのツールは他の商用ツールのようにすべての機能を備えているとは限りませんが、プロジェクトに予算の制約がある場合は、オープンソースツールを利用できます。
商用ツールには多くの機能がありますが、それらは多くのプロトコルをサポートし、非常にユーザーフレンドリーです。
負荷テストのアプローチは次のとおりです。
＃1）負荷テストの合格基準を特定する
例えば：
- ログインページの応答時間は、最大負荷状態でも5秒を超えないようにする必要があります。
- CPU使用率は80％を超えてはなりません。
- システムのスループットは、1秒あたり100トランザクションである必要があります。
＃2）テストする必要のあるビジネスシナリオを特定します。
すべてのフローをテストするのではなく、本番環境で発生すると予想される主なビジネスフローを理解するようにしてください。既存のアプリケーションの場合は、本番環境のサーバーログから彼の情報を取得できます。
新しくビルドされたアプリケーションの場合は、ビジネスチームと協力して、フローパターン、アプリケーションの使用法などを理解する必要があります。プロジェクトチームがワークショップを実施して、アプリケーションの各コンポーネントの概要や詳細を説明する場合があります。
アプリケーションワークショップに参加し、負荷テストを実施するために必要なすべての情報をメモする必要があります。
＃3）作業負荷モデリング
ビジネスフロー、ユーザーアクセスパターン、およびユーザー数の詳細がわかったら、本番環境での実際のユーザーナビゲーションを模倣するように、またはアプリケーションが適用された後の将来のように、ワークロードを設計する必要があります。生産になります。
ワークロードモデルを設計する際に覚えておくべき重要なポイントは、特定のビジネスフローが完了するまでにかかる時間を確認することです。ここでは、ユーザーがより現実的な方法でアプリケーション間を移動できるように、思考時間を割り当てる必要があります。
作業負荷パターンは通常、ランプアップ、ランプダウン、および定常状態になります。システムにゆっくりとロードする必要があるため、ランプアップとランプダウンが使用されます。定常状態は通常、ランプアップが15分、ラムダウンが15分の1時間の負荷テストです。
ワークロードモデルの例を見てみましょう。
アプリケーションの概要–ユーザーがアプリケーションにログインし、さまざまなドレスを購入して、各製品間を移動できるオンラインショッピングを想定します。
各製品の詳細を表示するには、製品をクリックする必要があります。商品の価格と製造方法が気に入った場合は、カートに追加して、チェックアウトして支払いを行うことで商品を購入できます。
以下にシナリオのリストを示します。
- ブラウズ –ここで、ユーザーはアプリケーションを起動し、アプリケーションにログインし、さまざまなカテゴリを参照して、アプリケーションからログアウトします。
- 閲覧、製品ビュー、カートに追加 –ここで、ユーザーはアプリケーションにログインし、さまざまなカテゴリを参照し、製品の詳細を表示し、製品をカートに追加してログアウトします。
- 閲覧、製品ビュー、カートに追加、チェックアウト –このシナリオでは、ユーザーはアプリケーションにログインし、さまざまなカテゴリを参照し、製品の詳細を表示し、製品をカートに追加し、チェックアウトしてログアウトします。
- 参照、製品ビュー、カートに追加チェックアウトして支払いを行う –ここで、ユーザーはアプリケーションにログインし、さまざまなカテゴリを参照し、製品の詳細を表示し、製品をカートに追加し、チェックアウトし、支払いを行い、ログアウトします。
| S.No | ビジネスフロー | トランザクション数 | 仮想ユーザーの負荷 | 応答時間（秒） | 許容される故障率％ | 1時間あたりのトランザクション |
|---|---|---|---|---|---|---|
| 1 | ブラウズ | 17 | 1600 | 3 | 2％未満 | 96000 |
| 二 | 閲覧、製品ビュー、カートに追加 | 17 | 200 | 3 | 2％未満 | 12000 |
| 3 | 閲覧、製品ビュー、カートに追加、チェックアウト | 18 | 120 | 3 | 2％未満 | 7200 |
| 4 | 参照、製品ビュー、カートに追加チェックアウトして支払いを行う | 20 | 80 | 3 | 2％未満 | 4800 |
上記の値は、次の計算に基づいて導き出されたものです。
- 1時間あたりのトランザクション数=ユーザー数* 1時間に1人のユーザーが行ったトランザクション。
- ユーザー数= 1600。
- 参照シナリオでのトランザクションの総数= 17。
- 各トランザクションの応答時間= 3。
- 1人のユーザーが17のトランザクションを完了するための合計時間= 17 * 3 = 51は60秒（1分）に丸められます。
- 1時間あたりのトランザクション= 1600 * 60 = 96000トランザクション。
＃4）負荷テストを設計する- 負荷テストは、これまでに収集したデータ、つまりビジネスフロー、ユーザー数、ユーザーパターン、収集および分析するメトリックを使用して設計する必要があります。さらに、テストは非常に現実的な方法で設計する必要があります。
＃5）負荷テストを実行する –負荷テストを実行する前に、アプリケーションが稼働していることを確認してください。負荷テスト環境の準備が整いました。アプリケーションは機能的にテストされており、安定しています。
負荷テスト環境の構成設定を確認してください。実稼働環境と同じである必要があります。すべてのテストデータが利用可能であることを確認します。テスト実行中のシステムパフォーマンスを監視するために、必要なカウンターを必ず追加してください。
常に低負荷から始めて、徐々に負荷を増やしていきます。全負荷から始めてシステムを壊さないでください。
＃6）負荷テストの結果を分析する –他のテスト実行と常に比較するためのベースラインテストを用意します。テストの実行後にメトリックとサーバーログを収集して、ボトルネックを見つけます。
一部のプロジェクトでは、アプリケーションパフォーマンス監視ツールを使用してテスト実行中にシステムを監視します。これらのAPMツールは、根本原因をより簡単に特定し、多くの時間を節約するのに役立ちます。これらのツールは、問題がどこにあるかを特定するための広い視野を持っているため、ボトルネックの根本原因を簡単に見つけることができます。
市場に出回っているAPMツールには、DynaTrace、Wily Introscope、AppDynamicsなどがあります。
＃7）レポート –テストの実行が完了したら、すべてのメトリックを収集し、観察結果と推奨事項を含むテスト要約レポートを関係するチームに送信します。
ベストプラクティス
以下に、負荷テストのベストプラクティスの一部を示します。
＃1） 負荷テストを開始する前に、必ずアプリケーションの安定性を確認してください。アプリケーションは、機能テストチームによって機能的に安定した署名が必要であり、ビルドを負荷テスト環境にコピーする前に、すべての主要な欠陥を修正してテストする必要があります。
＃二） 負荷テスト環境がレプリカであるか、サーバーの数、ロードバランサー、サーバー構成、ファイアウォールなどの実稼働環境に近いことを確認します。
＃3） 負荷テストを実行する前に、テストデータが一意であり、すべてのテストデータが負荷環境にコピーされているかどうかを確認します。
＃4） 本番環境で発生するリアルタイムのユーザーアクションを模倣するようにテストシナリオを設計します。
＃5） 本番ユーザーの負荷とビジネスフローに基づいてワークロードを設計し、古いアプリケーションの場合は、ビジネスフローとユーザー負荷に関するビジネスチームとの新しい話し合いであるかどうかを確認します。
＃6） 応答時間、1秒あたりのヒット数、スループット、CPU、メモリ、ネットワーク、実行中の仮想ユーザーなど、すべての重要な指標を収集します。
推奨読書=> 市場で入手可能なパフォーマンステストツールのリスト 排他的負荷テストを実施するため。
結論
このチュートリアルでは、負荷テストがアプリケーションのパフォーマンステストでどのように重要な役割を果たすか、アプリケーションの効率と機能を理解するのにどのように役立つかなどを学びました。
また、アプリケーションで追加のハードウェア、ソフトウェア、またはチューニングが必要かどうかを予測するのにどのように役立つかを知るようになりました。
幸せな読書！！