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

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

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

テストの種類

負荷下での動作を検査するテストは、ベースラインテスト、負荷テスト、ストレステスト、ソークテスト、スモークテスト、アイソレーションテストの6つの基本的な種類に分類されます[ 2 ] : 38–39 。これらの基本的な種類に加えて、構成テストやインターネットテストを行うこともできます。

ベースラインテスト

ベースラインテストは、他の種類のテスト（例えばストレステスト）の比較ポイントを作成するために使用されます。「最良のケース」（例えば5人の同時ユーザーのみ）におけるシステムの反応を測定することで、他の種類のテストで最悪のケースにおけるパフォーマンスの低下を比較することができます。

負荷テスト

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

ストレステスト

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

スパイクテストは、ストレステストの特殊な形態であり、非常に多くのユーザーによって生成される負荷を突然増加または減少させ、システムの動作を観察することによって行われます。その目的は、パフォーマンスが低下するか、システムが故障するか、あるいは負荷の急激な変化に対応できるかを判断することです。

ブレークポイントテストもストレステストの一種です。システムが所定の障害条件を満たしているか監視しながら、時間の経過とともに段階的に負荷をかけて負荷をかけます。ブレークポイントテストは、システムが要求仕様やサービスレベルアグリーメント（SLA）を満たすための最大キャパシティを決定することから、キャパシティテストと呼ばれることもあります。固定環境に適用されたブレークポイント分析の結果は、必要なハードウェアやクラウド環境でスケールアウトイベントをトリガーする条件の観点から、最適なスケーリング戦略を決定するために活用できます。

浸漬試験

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

分離テスト

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

構成テスト

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

インターネットテスト

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

パフォーマンス目標の設定

パフォーマンス テストはさまざまな目的に使用できます。

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

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

同時実行性とスループット

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

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

サーバー応答時間

これは、あるシステムノードが別のノードからのリクエストに応答するまでにかかる時間を指します。簡単な例としては、ブラウザクライアントからウェブサーバーへのHTTP「GET」リクエストが挙げられます。応答時間という点では、これはすべての負荷テストツールが実際に測定するものです。システムの全ノード間でサーバー応答時間の目標を設定することが適切である場合があります。

レンダリング応答時間

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

性能仕様

パフォーマンス仕様（要件）を詳細に定義し、パフォーマンステスト計画に文書化することは非常に重要です。理想的には、システム開発プロジェクトにおける要件定義フェーズ、つまり設計作業に着手する前の段階で実施するのが良いでしょう。詳細については、 「パフォーマンスエンジニアリング」をご覧ください。

応答時間、同時実行性などのパフォーマンス仕様は、通常、サービスレベルアグリーメント（SLA）に規定されます。[ 2 ] : 24 また、テストケースのパフォーマンスを前回の実行結果と比較することで、回帰を特定することもできます。パフォーマンス測定は非決定論的であるため、パフォーマンス回帰を検出するには、パフォーマンステストのワークロードを適切に繰り返し実行し、適切な統計的検定を実施する必要があります。[ 3 ]

さらに、パフォーマンステストは、パフォーマンスプロファイルのチューニングプロセスの一環として頻繁に使用されます。その目的は、ボトルネック（システムのどの部分で応答速度を向上すればシステム全体の動作速度が向上するか）を特定することです。システムのどの部分がこのクリティカルパスであるかを特定することは困難な場合があります。一部のテストツールには、サーバー（エージェント）上で実行されるインストルメンテーション（またはアドオン機能）が組み込まれており、トランザクション時間、データベースアクセス時間、ネットワークオーバーヘッド、その他のサーバーモニターをレポートし、生​​のパフォーマンス統計情報と組み合わせて分析できます。このようなインストルメンテーションがなければ、システム監視に頼らざるを得なくなる可能性があります。

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

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

質問すべきこと

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

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

前提条件

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

一貫した結果を得るためには、パフォーマンステスト環境は、ユーザー受け入れテスト（UAT）や開発環境などの他の環境から分離する必要があります。ベストプラクティスとして、本番環境に可能な限り類似した独立したパフォーマンステスト環境を用意することが推奨されます。

試験条件

パフォーマンステストでは、テスト環境を想定される実際の使用状況に近づけることが非常に重要になります。しかし、実際には、本番システムは予測不可能なワークロードにさらされるため、これを調整するのは困難であり、完全に実現できるわけではありません。テストワークロードは、本番環境で発生する事象を可能な限り模倣しますが、このワークロードの変動性を正確に再現できるのは、最もシンプルなシステムに限られます。

疎結合アーキテクチャ実装（例：SOA）は、パフォーマンステストの複雑さをさらに増大させています。本番環境に近い状態を忠実に再現するには、共通のインフラストラクチャまたはプラットフォームを共有するエンタープライズサービスまたはアセットにおいて、すべてのコンシューマーが共有インフラストラクチャまたはプラットフォーム上で本番環境に近いトランザクション量と負荷を発生させる、協調的なパフォーマンステストが必要です。この作業は非常に複雑で、費用と時間の両方がかかるため、一部の組織では、パフォーマンステスト環境（PTE）において本番環境に近い状態（「ノイズ」とも呼ばれます）を監視およびシミュレートするツールを導入し、キャパシティとリソースの要件を把握し、品質特性を検証・検証しています。

タイミング

新システムのコストパフォーマンスを向上するには、開発プロジェクトの開始から導入までパフォーマンステストの取り組みを継続的に実施することが不可欠です。パフォーマンス上の欠陥の検出が遅れるほど、修正コストは増大します。これは機能テストにも当てはまりますが、エンドツーエンドで実施されるパフォーマンステストでは、その範囲が複雑であるため、さらに顕著になります。テスト環境やその他の主要なパフォーマンス要件の取得と準備には時間がかかるため、パフォーマンステストチームは可能な限り早期にプロジェクトに参画することが不可欠です。

ツール

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

パフォーマンススクリプト

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

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

パフォーマンス監視

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

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

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

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

テクノロジー

パフォーマンステスト技術では、1台以上の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を追加するかの選択肢があります。

参照

参考文献

  1. ^ Thakur, Nitish (2012). 「Rational Performance Tester: Tips & Tricks」(PDF) . IBM . 2024年2月3日閲覧。
  2. ^ a bモリノー、イアン（2014年）『アプリケーションパフォーマンステストの芸術』ISBN 978-1-491-90054-3。
  3. ^ Reichelt, David Georg; Kühne, Stefan; Hasselbring, Wilhelm (2022). 「コードレベルでのパフォーマンス変化の自動識別」. 2022 IEEE 第22回ソフトウェア品質、信頼性、セキュリティに関する国際会議 (QRS) . IEEE. pp.  916– 925. doi : 10.1109/QRS57517.2022.00097 .
「 https://en.wikipedia.org/w/index.php?title=ソフトウェアパフォーマンステスト&oldid =1328746424」より取得