ソフトウェアパフォーマンステスト

ソフトウェア品質保証において、パフォーマンステストとは、一般的に、特定のワークロード下でのシステムの応答性と安定性のパフォーマンスを判断するために実行されるテスト手法です。^[1]また、スケーラビリティ、信頼性、リソース使用率など、システムの他の品質属性を調査、測定、検証、または確認するためにも役立ちます。

パフォーマンス エンジニアリングのサブセットであるパフォーマンス テストは、システムの実装、設計、アーキテクチャにパフォーマンス標準を組み込むことを目指すコンピューター サイエンスの実践です。

負荷テストは、パフォーマンス テストの最も単純な形式です。負荷テストは通常​​、特定の予測負荷下でのシステムの動作を理解するために実施されます。この負荷は、設定された期間内に特定の数のトランザクションを実行するアプリケーションの予想される同時ユーザー数です。このテストでは、すべての重要なビジネス クリティカル トランザクションの応答時間が表示されます。テスト中はデータベース、アプリケーション サーバーなども監視されるため、アプリケーション ソフトウェアとソフトウェアがインストールされているハードウェアの ボトルネックを特定するのに役立ちます。

ストレス テストは通常​​、システム内の容量の上限を把握するために使用されます。この種のテストは、極端な負荷に対するシステムの堅牢性を判断するために行われ、現在の負荷が予想される最大値を大幅に上回った場合にシステムが十分に機能するかどうかをアプリケーション管理者が判断するのに役立ちます。

ソーク テスト(耐久テストとも呼ばれる) は、通常、システムが予想される継続的な負荷に耐えられるかどうかを判断するために行われます。ソーク テスト中は、メモリ使用率が監視され、潜在的なリークが検出されます。また、パフォーマンスの低下も重要ですが、見落とされがちです。つまり、長時間の継続的なアクティビティ後のスループットや応答時間が、テストの開始時と同じかそれ以上であることを確認することです。基本的には、システムにかなりの負荷を長時間かけて適用します。目標は、システムが継続的な使用下でどのように動作するかを確認することです。

スパイク テストは、非常に多数のユーザーによって生成される負荷を突然増加または減少させ、システムの動作を観察することによって行われます。目的は、パフォーマンスが低下するか、システムが失敗するか、または負荷の劇的な変化に対処できるかどうかを判断することです。

ブレークポイント テストは、ストレス テストに似ています。システムが事前に決められた障害条件にないかどうか監視されている間、時間の経過とともに増分負荷が適用されます。ブレークポイント テストは、システムが必要な仕様またはサービス レベル アグリーメントに従って動作する最大容量を決定するため、容量テストと呼ばれることもあります。固定環境に適用されたブレークポイント分析の結果は、必要なハードウェアまたはクラウド環境でスケールアウト イベントをトリガーする条件に関して最適なスケーリング戦略を決定するために使用できます。

負荷の観点からパフォーマンスをテストするのではなく、システムのコンポーネントの構成変更がシステムのパフォーマンスと動作に与える影響を判断するためにテストが作成されます。一般的な例としては、さまざまな負荷分散方法を試すことが挙げられます。

分離テストはパフォーマンス テストに固有のものではありませんが、システムの問題を引き起こしたテスト実行を繰り返します。このようなテストでは、多くの場合、障害領域を分離して確認できます。

これは比較的新しい形式のパフォーマンス テストで、Facebook、Google、Wikipedia などのグローバル アプリケーションのパフォーマンス テストは、実際のターゲット大陸に配置された負荷ジェネレータ (物理マシンまたはクラウド VM) から行われます。これらのテストを正常に実行するには、通常、膨大な準備と監視が必要です。

パフォーマンス テストにはさまざまな目的があります。

• システムがパフォーマンス基準を満たしていることを実証できます。
• 2 つのシステムを比較して、どちらのパフォーマンスが優れているかを調べることができます。
• システムのどの部分またはワークロードがシステムのパフォーマンスを低下させるかを測定できます。

多くのパフォーマンス テストは、十分に現実的で目標指向的なパフォーマンス目標を設定せずに実施されます。ビジネスの観点から最初に問うべきことは、常に「なぜパフォーマンス テストを行うのか」です。これらの考慮事項は、テストのビジネス ケースの一部です。パフォーマンス目標は、システムのテクノロジと目的によって異なりますが、常に次の項目が含まれている必要があります。

システムが何らかのログイン手順でエンドユーザーを識別する場合、同時実行の目標が非常に望まれます。定義上、これはシステムが特定の時点でサポートすることが期待される同時システム ユーザーの最大数です。スクリプト化されたトランザクションのワークフローは、特に反復部分にログインとログアウトのアクティビティが含まれている場合、 実際の同時実行に影響を与える可能性があります。

システムにエンドユーザーの概念がない場合、パフォーマンス目標は最大スループットまたはトランザクション レートに基づく可能性が高くなります。

これは、あるシステム ノードが別のシステム ノードの要求に応答するのにかかる時間を指します。簡単な例としては、ブラウザー クライアントから Web サーバーへの HTTP 'GET' 要求が挙げられます。応答時間に関して言えば、これはすべての負荷テストツールが実際に測定するものです。システムのすべてのノード間でサーバー応答時間の目標を設定することが適切である可能性があります。

負荷テスト ツールでは、通常、ネットワーク上でアクティビティがない期間を認識すること以外に、ノード内で何が起きているかという概念がないため、レンダリング応答時間を測定することが困難です。レンダリング応答時間を測定するには、通常、パフォーマンス テスト シナリオの一部として機能テスト スクリプトを含める必要があります。多くの負荷テスト ツールでは、この機能は提供されていません。

パフォーマンス仕様 (要件) を詳細に記述し、パフォーマンス テスト プランに文書化することが重要です。理想的には、これは設計作業の前に、システム開発プロジェクトの要件開発フェーズで行います。詳細については、 「パフォーマンス エンジニアリング」を参照してください。

ただし、パフォーマンス テストは仕様に基づいて実行されることはあまりありません。たとえば、特定のユーザー グループの最大許容応答時間はどれくらいであるべきかを誰も明示していません。パフォーマンス テストは、パフォーマンス プロファイルの調整プロセスの一部として頻繁に使用されます。その目的は、「最も弱いリンク」を特定することです。システムには、応答を高速化すればシステム全体の実行速度が速くなる部分が必ず存在します。システムのどの部分がこのクリティカル パスを表すかを特定することは難しい場合があります。一部のテスト ツールには、サーバー (エージェント) で実行され、トランザクション時間、データベース アクセス時間、ネットワーク オーバーヘッド、その他のサーバー モニターを報告するインストルメンテーションが含まれています (または、それらを提供するアドオンがあります)。これらの情報は、生のパフォーマンス統計情報と一緒に分析できます。このようなインストルメンテーションがなければ、パフォーマンス テストによって生成される CPU 負荷の量を確認するために、サーバーのWindows タスク マネージャーに誰かをかがませる必要があるかもしれません (Windows システムをテスト対象とした場合)。

パフォーマンス テストは Web 全体で実行できます。また、インターネット自体の応答時間は地域によって異なることがわかっているため、国内のさまざまな場所で実行することもできます。社内で行うこともできますが、その場合はルーターを設定して、パブリック ネットワークで通常発生する遅延を導入する必要があります。負荷は現実的なポイントからシステムに導入する必要があります。たとえば、システムのユーザー ベースの 50% が 56K モデム接続経由でシステムにアクセスし、残りの半分がT1経由でアクセスする場合、負荷インジェクター (実際のユーザーをシミュレートするコンピューター) は、同じ接続の組み合わせで負荷を注入するか (理想的)、同じユーザー プロファイルに従って、そのような接続のネットワーク遅延をシミュレートする必要があります。

ピーク時にシステムを使用すると予想されるピーク時のユーザー数に関する記述があると、常に役に立ちます。また、最大許容 95 パーセンタイル応答時間を構成するものに関する記述があれば、インジェクター構成を使用して、提案されたシステムがその仕様を満たしているかどうかをテストできます。

パフォーマンス仕様では、少なくとも次の質問をする必要があります。

• 具体的には、パフォーマンス テストの範囲は何ですか? このテストの範囲内と範囲外のサブシステム、インターフェイス、コンポーネントなどは何ですか?
• 関連するユーザー インターフェイス (UI) ごとに、同時ユーザー数はどれくらいになると予想されますか (ピーク時と公称時のユーザー数を指定)?
• ターゲット システム (ハードウェア) はどのようになっていますか (すべてのサーバーおよびネットワーク アプライアンスの構成を指定します)。
• 各システム コンポーネントのアプリケーション ワークロード ミックスはどれくらいですか? (例: ログイン 20%、検索 40%、アイテム選択 30%、チェックアウト 10%)。
• システム ワークロード ミックスとは何ですか? [1 つのパフォーマンス テストで複数のワークロードをシミュレートできます] (例: 30% ワークロード A、20% ワークロード B、50% ワークロード C)。
• すべてのバックエンド バッチ プロセスの時間要件は何ですか (ピークと公称を指定)?

可能な限り実稼働環境に似たシステムの安定したビルド。

一貫した結果を確保するには、パフォーマンス テスト環境を、ユーザー受け入れテスト(UAT) や開発などの他の環境から分離する必要があります。ベスト プラクティスとして、可能な限り実稼働環境に似た別のパフォーマンス テスト環境を用意することが常に推奨されます。

パフォーマンス テストでは、テスト条件が予想される実際の使用状況に似ていることが非常に重要になることがよくあります。ただし、実稼働システムは予測できないワークロードにさらされるため、実際にはこれを調整するのは難しく、完全には不可能です。テスト ワークロードは、実稼働環境での発生を可能な限り模倣できますが、このワークロードの変動性を正確に再現できるのは、最も単純なシステムだけです。

疎結合アーキテクチャ実装 (例: SOA ) により、パフォーマンス テストがさらに複雑になっています。実稼働状態を真に再現するには、共通のインフラストラクチャまたはプラットフォームを共有するエンタープライズ サービスまたは資産で、すべてのコンシューマーが共有インフラストラクチャまたはプラットフォーム上で実稼働状態のようなトランザクション ボリュームと負荷を作成する、調整されたパフォーマンス テストが必要です。このアクティビティは非常に複雑で、費用と時間がかかるため、一部の組織では、パフォーマンス テスト環境 ( PTE ) で実稼働状態のような条件 (「ノイズ」とも呼ばれます) を監視およびシミュレートするツールを使用して、容量とリソースの要件を理解し、品質属性を検証しています。

新しいシステムのコスト パフォーマンスにとって、開発プロジェクトの開始時にパフォーマンス テストの取り組みを開始し、導入まで継続することが非常に重要です。パフォーマンスの欠陥の検出が遅れるほど、修復コストが高くなります。これは機能テストの場合に当てはまりますが、エンドツーエンドの範囲であるため、パフォーマンス テストの場合はさらに当てはまります。テスト環境やその他の主要なパフォーマンス要件を取得して準備するには時間がかかるため、パフォーマンス テスト チームができるだけ早い段階で関与することが重要です。

パフォーマンス テストは、主に次の 2 つのカテゴリに分けられます。

パフォーマンス テストのこの部分では、主に、特定された主要なビジネス プロセスのワークフローの作成/スクリプト化を扱います。これは、さまざまなツールを使用して実行できます。

上記のリストに記載されている各ツール (網羅的でも完全でもありません) は、スクリプト言語 (C、Java、JS) または何らかの視覚的表現 (ドラッグ アンド ドロップ) を使用して、エンド ユーザーのワークフローを作成し、シミュレートします。ほとんどのツールでは、「記録と再生」と呼ばれる機能を使用できます。この機能では、パフォーマンス テスターがテスト ツールを起動し、ブラウザーまたはシック クライアントに接続して、クライアントとサーバーの間で発生するすべてのネットワーク トランザクションをキャプチャします。これにより、さまざまなビジネス シナリオをエミュレートするために拡張/変更できるスクリプトが開発されます。

これはパフォーマンステストのもう一つの側面です。パフォーマンス監視では、テスト対象のアプリケーションの動作と応答特性が観察されます。パフォーマンステストの実行中は通常、以下のパラメータが監視されます。

サーバーハードウェアパラメータ

• CPU使用率
• メモリ使用率
• ディスク使用率
• ネットワーク利用率

最初のステップとして、これら 4 つのパラメータによって生成されるパターンは、ボトルネックがどこにあるかを示す良い指標となります。問題の正確な根本原因を特定するために、ソフトウェア エンジニアはプロファイラーなどのツールを使用して、デバイスまたはソフトウェアのどの部分がパフォーマンスの低下に最も影響しているかを測定したり、許容可能な応答時間を維持するためのスループット レベル (およびしきい値) を確立したりします。

パフォーマンス テスト テクノロジでは、1 台以上の PC または Unix サーバーをインジェクターとして利用し、各 PC または Unix サーバーが多数のユーザーの存在をエミュレートし、パフォーマンスをテストするホストとの一連の自動インタラクション (スクリプトとして記録されるか、さまざまな種類のユーザー インタラクションをエミュレートする一連のスクリプトとして記録される) を実行します。通常、別の PC がテスト コンダクターとして機能し、各インジェクターからのメトリックを調整して収集し、レポート用にパフォーマンス データを照合します。通常のシーケンスは、負荷を徐々に増加させることです。つまり、少数の仮想ユーザーから始めて、時間の経過とともにその数を事前に決定された最大値まで増やします。テスト結果には、負荷によってパフォーマンスがどのように変化するかが、ユーザー数と応答時間の関係で示されます。このようなテストを実行するには、さまざまなツールを使用できます。このカテゴリのツールは通常、システムに対して実際のユーザーをエミュレートする一連のテストを実行します。結果から奇妙な点が明らかになる場合もあります。たとえば、平均応答時間は許容範囲内かもしれませんが、完了までにかなり長い時間がかかるいくつかの重要なトランザクションが外れ値として存在することがあります。これは、データベース クエリや画像などの非効率性が原因である可能性があります。

パフォーマンス テストをストレス テストと組み合わせて、許容可能な負荷を超えた場合に何が起こるかを確認できます。システムはクラッシュしますか? 大きな負荷が軽減された場合、回復にはどのくらいの時間がかかりますか? 障害によって付随的な損害が発生しますか?

分析的パフォーマンス モデリングは、スプレッドシートでシステムの動作をモデル化する方法です。このモデルには、トランザクション リソース需要 ( CPU、ディスク I/O、LAN、WAN ) の測定値が取り込まれ、トランザクション ミックス (1 時間あたりのビジネス トランザクション数) で重み付けされます。重み付けされたトランザクション リソース需要を合計して 1 時間あたりのリソース需要を取得し、1 時間あたりのリソース容量で割ってリソース負荷を取得します。応答時間の式 (R=S/(1-U)、R=応答時間、S=サービス時間、U=負荷) を使用して、応答時間を計算し、パフォーマンス テストの結果を使用して調整できます。分析的パフォーマンス モデリングを使用すると、実際のまたは予想されるビジネス使用に基づいて設計オプションとシステム サイズを評価できます。したがって、ハードウェア プラットフォームを完全に理解する必要がありますが、パフォーマンス テストよりもはるかに高速で安価です。

このようなテストを実行するためのタスクには次のものが含まれます。

• 社内の専門知識（またはその欠如）に応じて、テストを実行するために内部リソースを使用するか外部リソースを使用するかを決定します。
• ユーザーやビジネスアナリストからパフォーマンス要件 (仕様) を収集または引き出します。
• 要件、リソース、タイムライン、マイルストーンを含む高レベルの計画(またはプロジェクト憲章) を作成します。
• 詳細なパフォーマンステスト プラン(詳細なシナリオとテスト ケース、ワークロード、環境情報などを含む) を作成します。
• テストツールを選択します。
• 必要なテスト データとチャーター作業を指定します (見落とされがちですが、有効なパフォーマンス テストを実行するには不可欠です)。
• 選択したテスト ツールと戦略を使用して、テスト対象の各アプリケーション/コンポーネントの概念実証スクリプトを開発します。
• すべての依存関係と関連するタイムラインを含む詳細なパフォーマンス テスト プロジェクト計画を作成します。
• インジェクター/コントローラーをインストールして構成します。
• テスト環境 (理想的には実稼働プラットフォームと同一のハードウェア)、ルーター構成、静かなネットワーク (他のユーザーによって結果が混乱しないようにするため)、サーバー インストルメンテーションの展開、開発されたデータベース テスト セットなどを構成します。
• テストのドライ ラン - 事前定義されたユーザーで負荷テストを実際に実行する前に、スクリプトの正確性を確認するためにドライ ランが実行されます。
• テストを実行します。おそらく繰り返し（反復的に）実行して、考慮されていない要因が結果に影響するかどうかを確認する必要があります。
• 結果を分析します（合格/不合格、またはクリティカルパスの調査と是正措置の推奨）。

Microsoft Developer Network によれば、パフォーマンス テスト方法論は次のアクティビティで構成されます。

1. テスト環境を特定します。物理的なテスト環境と運用環境、およびテスト チームが使用できるツールとリソースを特定します。物理的な環境には、ハードウェア、ソフトウェア、およびネットワーク構成が含まれます。テスト環境全体を最初から十分に理解しておくと、テストの設計と計画がより効率的になり、プロジェクトの早い段階でテストの課題を特定しやすくなります。状況によっては、プロジェクトのライフ サイクル全体を通じてこのプロセスを定期的に再検討する必要があります。
2. パフォーマンス受け入れ基準を特定します。応答時間、スループット、およびリソース使用の目標と制約を特定します。一般的に、応答時間はユーザーの懸念事項、スループットはビジネスの懸念事項、リソース使用はシステムの懸念事項です。さらに、これらの目標と制約では捉えられない可能性のあるプロジェクトの成功基準を特定します。たとえば、パフォーマンス テストを使用して、どの構成設定の組み合わせが最も望ましいパフォーマンス特性をもたらすかを評価します。
3. テストを計画および設計します。主要なシナリオを特定し、代表的なユーザー間の変動とその変動をシミュレートする方法を決定し、テスト データを定義し、収集するメトリックを確立します。この情報を 1 つ以上のシステム使用モデルに統合し、実装、実行、および分析します。
4. テスト環境を構成します。機能とコンポーネントがテストに利用可能になったら、各戦略を実行するために必要なテスト環境、ツール、およびリソースを準備します。必要に応じて、テスト環境にリソース監視用のインストルメントが組み込まれていることを確認します。
5. テスト設計を実装します。テスト設計に従ってパフォーマンス テストを開発します。
6. テストを実行します。テストを実行して監視します。テスト、テスト データ、および結果の収集を検証します。テストとテスト環境を監視しながら、検証済みのテストを実行して分析します。
7. 結果の分析、調整、再テスト。結果データを分析、統合、共有します。調整を変更して再テストします。両方のテストの結果を比較します。改善するたびに、前回の改善よりも小さな改善が返されます。いつ停止しますか? CPU ボトルネックに到達したら、コードを改善するか、CPU を追加するかの選択肢があります。

• ベンチマーク（コンピューティング）  – 標準化されたパフォーマンス評価
• Web サーバー ベンチマーク – Web サーバーのパフォーマンスの推定
• アプリケーション応答測定 – ボトルネックを管理するための標準