ソフトウェア アプリケーションのテストは、その機能が正しく機能することを確認するほど簡単ではありません。 スケーラビリティ テスト の重要性は、公開されているアプリケーションは、世界中のどこからでも、いつでも誰でもアクセスできるため、無視することはできません。 アプリケーションがローカルで実行する方法に関心がなくなります。 今では、さまざまなデバイス、ネットワーク条件から、世界中の複数の場所からアプリケーションの信頼性を確保し、ユーザー数が増加し、時間の経過とともに減少するにつれてシームレスに実行する必要があります。 スケーラビリティテストがかつてソフトウェア開発の観点から「持っている素晴らしい」ものであった場合、それはユーザーの要求と現代のインターネットの自然な進化のために「持っている必要があります」に進化しました。
アプリケーションの機能はスムーズかつ完璧に動作する必要がありますが、ユーザーはその安定性と応答性により影響を受ける可能性があります。 パフォーマンス テストは、機能性に欠かせないテストの重要な要素です。 パフォーマンス テストには、その特定のアプリケーションで予想される使用の種類に応じて必要になるさまざまな種類があります。 次に、パフォーマンス テストのプロセスについて詳しく説明します。
Web アプリケーションのパフォーマンス テストとは
パフォーマンス テストとは、さまざまな使用 (ストレス) レベルでのアプリケーションの速度、応答性、スケーラビリティ、安定性などを分析することです。 これを行うために、開発者は手動の方法または特定のパフォーマンス テスト ツールを通じて人為的に、より高い使用期間を誘導できます。 この記事の後半でそれらのいくつかを見ていきます。
パフォーマンス テストには、主に 3 種類があります。 アプリケーションのパフォーマンスをテストする主な方法は、さまざまな負荷レベルを適用し、そのパフォーマンスを分析することです。
負荷テスト
ロード テストでは、アプリケーションの運賃がさまざまな使用量でどのように行われますか。. また、アプリケーションの応答を確認し、インフラストラクチャがどのように拡張されているかを監視するために、急激な使用率の急増も引き起こされます。 LoadView のような革新的なロード テスト ツールを使用すると、地理的に分散した場所からのトラフィックに基づいてアプリケーションを分析できます。 この種のテストは、グローバル ユーザー ベースにとって不可欠な場合があります。
耐久試験
耐久テストは、アプリケーションが長期間にわたって高負荷にさらされるもう 1 つの有用なタイプのテストです。 耐久テストの主な利点は、インフラストラクチャの使用率やその他の弱点の長期にわたるスティントによって引き起こされる可能性のある メモリリークなどの問題を特定できることです。
ストレステスト
ストレステストは、ソフトウェアレジリエンスエンジニアリングの概念で一般的になりました。 これにより、開発者は、非常に高い使用率が原因でアプリケーション (または 1 つ以上のコンポーネント) が失敗するポイントを特定できます。 アプリケーションやシステムを限界点までプッシュすることは、ソフトウェアレジリエンスエンジニアリングに精通していない人にとっては直感に反するように思えるかもしれませんが、開発者が開発者や テスター に、システムがクラッシュする前にどれだけの負荷やストレスに耐えることができるかについての洞察を提供します。 間違いなく、失敗が起こるでしょう、そしてそれに備えることが最善です。 ストレステスト では、システムがどのように応答し、回復するかも示します。 ストレス テストでは、インフラストラクチャと容量の投資が必要なことも示される場合があります。
たとえば、新しい製品とマーケティング キャンペーンを開始し、サイトとアプリケーションに生成されるトラフィックを見積もったとします。 ストレス テスト中にアプリケーションが予想よりも早く失敗した場合、これは、予定された着信トラフィックのレベルを処理するために必要なシステム リソースが多いことを示します。
スケーラビリティ テストとは
パフォーマンス テスト と比較して 、スケーラビリティ テストとは、同時ユーザー数の変化に対するシステムの応答を分析することです。 システムは、同時ユーザー数が多くても一貫性のある安定したパフォーマンスをユーザーに提供できるように、リソースの使用率を増減し、調整することが期待されます。
スケーラビリティ テストは、ハードウェア、ネットワーク リソース、および データベース に対して実行して、さまざまな数の同時要求にどのように応答するかを確認することもできます。 ロード テストとは対照的に、システムがさまざまな負荷レベルにどのように応答するかを分析する場合、スケーラビリティ テストでは、さまざまな負荷レベルに応じてシステムのスケールがどの程度適切に行えるのかを分析します。 後者は、コンテナ化された環境で特に重要です。
パフォーマンス テスト プロセス
各アプリケーションで必要なパフォーマンス テストの種類と量は、多くの要因によって決まります。 ただし、これらは正しいパスにあなたを置くいくつかの一般的な手順です。
ベースラインの確立
任意のプロセスの結果を測定できるように、ベースラインを確立する必要があります。 パフォーマンス テストも変わりません。 開発者は、応答時間や安定性に影響を与えることなく、アプリケーションで許容できる最大負荷を特定するための基本的なテストを実行できます。 その後、ベースラインを文書化し、将来のテストと比較できます。 ベースラインは、特に、改善や是正措置を実行する場合に役立ちます。
開発者の中には、ステージング アプリケーションを運用環境と同じ仕様と構成で維持し、それを改良されたインスタンスと比較する場合があります。 このアプローチの利点は、新しいテストを両方の環境で実行できるため、未確認のシナリオもカバーできることです。
ウォーターフォールチャート
このステップは、パフォーマンス最適化プロセスのさまざまな段階で実行されます。 ただし、その主な目的は、他のコンポーネントやアプリケーションよりも比較的低速なアプリケーションの機能を識別することです。 これらの領域は、修復アクションを特定するために特定する必要があります。
詳細なウォーターフォール分析では、アプリケーションに対する要求の各側面 (DNS、最初のパケットまでの時間、SSL など) の各側面で消費される時間の内訳が生成されます。
パフォーマンステスト
パフォーマンス テストについて覚えておくべきことは、継続的なプロセスです。 アプリケーションの使用は時間とともに増加することが期待でき、定期的な注意が必要です。 パフォーマンス テスト プロセスは、次のように要約できます。
ベンチマークが確立されたら、次のステップはテストを計画することです。 各テストで適用される負荷の量は、レベルの特定の数(1X-10X)を持つスケールに依存します。 その他の要因 (例えば、使用/機能のタイプや要求の地理的分散など) も、状況に基づいて考慮することができます。
その後、テストを実行することができます。 その機能のサイズと複雑さに応じて、テストは手動で行うことも、LoadView などのサードパーティ ツールを使用して行うこともできます。 これらのツールを使用すると、開発者は一連のアクションを記録し、プラットフォームによって大量に複製され、より高い負荷を模倣できます。
結果が分析されると、遅延や不安定性を引き起こしているアプリケーションの領域を特定できるようになります。 パフォーマンス テスト プラットフォームは、最適な読み込み時間と最悪の読み込み時間、個々の要求の詳細なデータ、ウォーターフォール チャート、エラー レポートなど、さまざまな種類のレポートを提供します。 機能テストでは通常発生しないランタイム エラーを特定するために、後者は重要です。
アーキテクチャのボトルネックを特定する
メモリ リークは開発者にとって最も厄介な問題の 1 つです。 彼らは一貫して起こらず、識別することは比較的困難です。 しかし、これらは、作り上げることができる問題の唯一のタイプではありません。 CPU、I/O、およびネットワークは、影響を受ける可能性のあるその他の領域の一部です。 最近のアプリケーションでは、コンテナ化された環境を使用しています。 これらのコンテナー オーケストレーション プラットフォームの多くは、多くの形式の自動スケーリングを提供していますが、インフラストラクチャは常にボトルネックを引き起こす可能性があります。
是正措置
修正アクションは 2 倍にすることができます。 まず、アプリケーションの機能に関して特定されたすべてのパフォーマンスの問題に対処することが重要です。 これらは、コードとデータベースの相互作用の両方で最適化できます。 インフラストラクチャのボトルネックは、アプリケーションに割り当てるハードウェア デバイスの量や種類を調整することで、迅速に解決できます。 ただし、物理的な制限と財務上の制限の両方が原因で、これはある程度しか可能ではありません。 より複雑なシナリオでは、負荷分散の設定を変更し、サーバーを地域のデータ センターに分散させる必要があります。
これらのアクションが完了したら、次の手順は、パフォーマンス テストを再度実行することです。 これは、適用された修復アクションを検証し、定量化するために必要です。 これらの新しい結果をベースラインと比較し、外部アプリケーションでベンチマークを行うことができます。 比較の結果は、以前に存在していたボトルネックと遅延がどの程度利用可能であるかを示すことができます。
その後、プロセスは最初からやり直します。 ベースラインとパフォーマンス テストを更新し、新しいテストを計画できます。
パフォーマンス テストとスケーラビリティ テスト: 結論
この記事では、ソフトウェア アプリケーションのパフォーマンス テスト プロセスについて簡単に説明します。 説明されている手順は、ほとんどのシナリオに合わせて一般化されています。 ただし、特定のアプリケーションでは、特定の領域で注意が必要な場合があります。 また、実際のパフォーマンス テストを実行するために使用できるツールをいくつか見ました。 これらのテストを手動で実行することは不可能ではありませんが、専用のプラットフォームを使用する方がはるかに効率的です。 LoadViewの詳細と、Web サイト、アプリケーション、API などのロード テストを実行する方法について説明します。
今すぐ無料試用版にサインアップして 、最大5つの無料ロードテストを取得して 開始してください。