パフォーマンス テスト方法は、静的テストと動的テストの 2 種類に分類できます。
静的性能試験
静的パフォーマンス テスト (以下、静的テストと呼びます) は、システム アーキテクチャの設計段階で不合理またはアンバランスなシステム アーキテクチャなど、多くの重大なパフォーマンスと効率の欠陥が導入されるため、パフォーマンス テストでは機能テストよりも重要であることがよくあります。等 これらの欠陥は、設計者やアーキテクトによる誤解や関連知識の欠如、あるいは設計要件が応答時間、スループット レート、リソース使用率の目標、予想される負荷と使用量、制約などの要素を適切に捉えていないために発生する可能性があります。したがって、静的テストは、システム構築の初期段階での実行に特に適しています。
静的テストには次のものが含まれます。
❑パフォーマンスとパフォーマンスのリスクに関する要件のレビュー。
❑ データベース アーキテクチャ、エンティティ関係図、メタデータ、ストアド プロシージャ、クエリなどのレビュー。
❑ システムおよびネットワーク アーキテクチャのレビュー。
❑ システムの主要部分のコードのレビュー (複雑なアルゴリズムなど)。
動的パフォーマンステスト
システムが構築されたら、できるだけ早く動的パフォーマンス テスト (以下、動的テストと呼びます) を開始する必要があります。主なテストの機会は次のとおりです。
❑ 単体テスト中に、情報分析を使用して潜在的なボトルネックを特定し、動的分析を使用してリソースの使用率を評価します。
❑ コンポーネント統合テスト中に、特にさまざまなユースケース機能を統合する場合、またはワークフローのバックボーン構造と統合する場合に、コンポーネント全体にわたる主要なユースケースとワークフローをテストします。
❑ システムのテスト中に、さまざまな負荷条件下で全体的なエンドツーエンドのパフォーマンスをチェックします。❑ システム統合テスト中、特に重要なシステム間のインターフェイスでデータ フローやワークフローをテストする場合、「ユーザー」は別のシステムまたはマシン (センサーや他の入力システムなど) である可能性があります。
❑ ユーザー受け入れテスト段階では、システムのパフォーマンスに対するユーザー、顧客、およびオペレーターの信頼を築き、実際の条件下でシステムを調整します (ただし、これは通常、システムのパフォーマンス上の欠陥を発見するためではありません)。カスタムまたは新しいハードウェアがシステムの一部である場合は、エミュレータを使用して初期の動的パフォーマンス テストを実行できます。ただし、シミュレーターではリソースの制約やパフォーマンス関連の動作が適切に把握できないことが多いため、できるだけ早く実際のハードウェアでテストを開始することをお勧めします。
システム テスト、システム統合テスト、ユーザー受け入れテストなどのより高度なテストでは、実際のテスト環境、データ、負荷を使用することが、パフォーマンス テスト結果の精度にとって非常に重要です。
アジャイルおよびその他の反復的および増分開発モデルでは、チームは、パフォーマンス テストの開始を最終反復まで待つのではなく、ソフトウェアの初期反復計画に静的および動的テストを組み込む必要があります。
この記事「エンタープライズパフォーマンステスト」