負荷テスト[1]またはストレステストという用語は、プロのソフトウェアテストコミュニティではさまざまな意味で使用されています。負荷テストは通常、複数のユーザーが同時にプログラムにアクセスすることをシミュレートすることによって、ソフトウェアプログラムの予想される使用法をモデル化する手法を指します。[2]そのため、このテストはマルチユーザーシステム、つまりWebサーバーなどのクライアント/サーバーモデルを使用して構築されるシステムに最も関連しています。ただし、他の種類のソフトウェアシステムも負荷テストできます。たとえば、ワードプロセッサまたはグラフィックエディターに非常に大きなドキュメントを読み込ませたり、財務パッケージに数年分のデータに基づくレポートを生成させたりすることができます。最も正確な負荷テストは、理論モデルまたは分析モデルを使用したテストではなく、実際の使用をシミュレートします。
負荷テストでは、実際の顧客行動に基づいて Web サイトのサービス品質(QOS) パフォーマンスを測定できます。ほぼすべての負荷テスト ツールとフレームワークは、従来の負荷テスト パラダイムに従います。顧客が Web サイトにアクセスすると、スクリプト レコーダーが通信を記録し、関連する対話スクリプトを作成します。負荷ジェネレーターは記録されたスクリプトの再生を試行します。再生前に、さまざまなテスト パラメーターでスクリプトが変更される可能性もあります。再生手順では、ハードウェアとソフトウェアの両方の統計がコンダクターによって監視および収集されます。これらの統計には、物理サーバーの CPU、メモリ、ディスク IO、応答時間、テスト対象システム (SUT) のスループットなどが含まれます。最後に、これらすべての統計が分析され、負荷テスト レポートが生成されます。
負荷およびパフォーマンス テストでは、さまざまな数の仮想ユーザーと実際のユーザーにソフトウェアを負荷させ、さまざまな負荷の下でパフォーマンス測定を監視することで、複数のユーザーを対象としたソフトウェアを分析します。負荷およびパフォーマンス テストは通常、ソフトウェア システムの稼働が許可される前に、運用環境と同一のテスト環境で実施されます。
負荷テストの目的: - システムがパフォーマンス ベンチマークを満たしていることを確認する。 - システムの限界点を特定する。 - 負荷によるダウンタイムに対する製品の反応をテストする。
たとえば、ショッピング カート機能を備えた Web サイトでは、次のアクティビティに分類される 100 人の同時ユーザーをサポートする必要があります。
- 25人の仮想ユーザー(VUser)がログインし、アイテムを閲覧してからログオフします。
- 25 VUserがログインし、ショッピングカートに商品を追加し、チェックアウトしてログオフする
- 25 VUserがログインし、以前購入した商品を返品してログオフする
- 25 VUser はその後のアクティビティなしでログインするだけです
テストアナリストは、さまざまな負荷テスト ツールを使用して、これらの VUser とそのアクティビティを作成できます。テストが開始され、安定状態に達すると、アプリケーションは上記のように 100 VUser の負荷でテストされます。その後、アプリケーションのパフォーマンスを監視してキャプチャできます。
負荷テスト計画またはスクリプトの詳細は、通常、組織によって異なります。たとえば、上記の箇条書きリストの最初の項目は、開発されたテスト計画またはスクリプトに応じて、固有の項目、ランダムな項目、または選択された項目セットを参照する 25 人の仮想ユーザーを表すことができます。ただし、すべての負荷テスト計画は、予想されるピーク ワークフローとボリュームの範囲でシステム パフォーマンスをシミュレートしようとします。負荷テストの合格または不合格の基準 (合格/不合格の基準) も、通常、組織によって異なります。許容される負荷テスト パフォーマンス メトリックを指定する標準はありません。
よくある誤解は、負荷テスト ソフトウェアが回帰テストツールのような記録および再生機能を備えているというものです。負荷テスト ツールはOSI プロトコル スタック全体を分析しますが、ほとんどの回帰テスト ツールはGUIパフォーマンスに重点を置いています。たとえば、回帰テスト ツールは Web ブラウザーのボタンのマウス クリックを記録して再生しますが、負荷テスト ツールはユーザーがボタンをクリックした後に Web ブラウザーが送信するハイパーテキストを送信します。複数のユーザー環境では、負荷テスト ツールは、各ユーザーが固有のログイン ID、パスワードなどを持つ複数のユーザーにハイパーテキストを送信できます。
一般的な負荷テスト ツールは、パフォーマンス低下の原因についての洞察も提供します。システム パフォーマンス低下の原因は多数考えられますが、以下に挙げるものに限定されません。
アプリケーション、システム、またはサービスがサービス レベル アグリーメント(SLA) の対象となる場合は、負荷テストが特に重要です。
負荷テストは、通常の負荷条件と予想されるピーク負荷条件の両方でシステムの動作を判断するために実行されます。アプリケーションの最大動作容量とボトルネックを特定し、どの要素がパフォーマンス低下の原因になっているかを判断するのに役立ちます。システムにかかる負荷を通常の使用パターンを超えて増加させ、異常に高い負荷またはピーク負荷でのシステムの応答をテストすることを、ストレス テストと呼びます。通常、負荷は非常に大きいため、エラー状態が予想される結果になりますが、アクティビティが負荷テストでなくなりストレス テストになる明確な境界はありません。
「負荷テスト」という用語は、同時実行テスト、ソフトウェア パフォーマンス テスト、信頼性テスト、および特定のシナリオのボリューム テストと同義でよく使用されます。これらはすべて、特定のソフトウェアの使用に対する適合性を検証するために使用される機能テストの一部ではない 非機能テストの種類です。
負荷テストでのユーザーエクスペリエンス
上記の例では、テスト対象デバイス (DUT) が実稼働負荷 (100 VUser) を受けている間に、ターゲット アプリケーションを実行します。ここでのターゲット アプリケーションのパフォーマンスは、負荷時のユーザー エクスペリエンスになります。これは、DUT の応答速度や、ユーザーが実際にパフォーマンスをどのように認識しているか、つまり満足度を表します。
ブラウザレベルのユーザーとプロトコルレベルのユーザー
歴史的に、すべての負荷テストは、プロトコル層での同時インタラクションによるトラフィックをシミュレートする自動 API テストで実行されていました (プロトコル レベル ユーザーまたは PLU と呼ばれることが多い)。コンテナとクラウド インフラストラクチャの進歩により、実際のブラウザーでテストするオプションが提供されるようになりました (ブラウザー レベル ユーザーまたは BLU と呼ばれることが多い)。[3]各アプローチには、さまざまな種類のアプリケーションに対するメリットがありますが、一般的に、ブラウザー レベル ユーザーは、Web サイトが経験する実際のトラフィックに近く、より現実的な負荷プロファイルと応答時間の測定を提供します。[4] BLU は確かにテストを実行する方法としてはより高価であり、すべての種類のアプリケーション、特にデスクトップ クライアントや API ベースのアプリケーションなど、Web ブラウザーからアクセスできないアプリケーションで機能するわけではありません。[5]
負荷テストツール
参考文献
- ^ Jiang, Zhen Ming; Hassan, Ahmed E. (2015). 「大規模ソフトウェアシステムの負荷テストに関する調査」. IEEE Transactions on Software Engineering . 41 (11). IEEE: 1091–1118.
- ^ Wescott, Bob ( 2013). 『Every Computer Performance Book』、第 6 章:負荷テスト。CreateSpace。ISBN 978-1482657753。
- ^ Platz, Wolfgang. 「負荷テストの未来は BLU にある」InfoWorld 。 2018 年 11 月 23 日閲覧。
- ^ 「We're All Load Testers Now (Maybe) - DevOps.com」。DevOps.com 。 2018年2月8日。 2018年11月23日閲覧。
- ^ 「Flood Element を使用して実際のブラウザーで負荷テストを実行する方法」。geekflare.com。2018年 11 月 17 日。2018年 11 月 23 日閲覧。
- ^ エリンレ、バヨ (2014). JMeter クックブック。パックト出版。ISBN 978-1783988280。
- ^ Erinle, Bayo (2015). JMeterによるパフォーマンス テスト。Packt Publishing。ISBN 978-1784394813。
- ^ 「Visual Studio 2010 を使用した ASP.NET アプリケーションの負荷テスト」。Eggheadcafe.com。2013年 1 月 13 日閲覧。
