パフォーマンス テストのチュートリアル

負荷テスト

パフォーマンス テストとは

性能試験 特定のワークロード下でのソフトウェア アプリケーションの速度、応答時間、安定性、信頼性、スケーラビリティ、およびリソース使用量をテストするために使用されるソフトウェア テスト プロセスです。 パフォーマンス テストの主な目的は、ソフトウェア アプリケーションのパフォーマンスのボトルネックを特定して排除することです。 これはパフォーマンス エンジニアリングのサブセットであり、としても知られています。 「パフォーマンステスト」.

パフォーマンス テストの焦点は、ソフトウェア プログラムのチェックです。

  • 速度 – アプリケーションが迅速に応答するかどうかを判断します
  • スケーラビリティ – ソフトウェア アプリケーションが処理できる最大ユーザー負荷を決定します。
  • 安定性 – 負荷が変動してもアプリケーションが安定しているかどうかを判断します

なぜパフォーマンステストを行うのか?

ソフトウェア システムでサポートされる機能だけが問題ではありません。 ソフトウェア アプリケーションのパフォーマンス (応答時間、信頼性、リソース使用量、スケーラビリティなど) は重要です。 パフォーマンス テストの目的は、バグを見つけることではなく、パフォーマンスのボトルネックを排除することです。

パフォーマンス テストは、アプリケーションの速度、安定性、スケーラビリティに関する情報を関係者に提供するために行われます。さらに重要なのは、パフォーマンス テストによって、製品を市場に出す前に改善すべき点が明らかになることです。パフォーマンス テストを行わないと、ソフトウェアは、複数のユーザーが同時に使用する際に動作が遅くなる、異なるオペレーティング システム間での不整合、使い勝手の悪さなどの問題に悩まされる可能性が高くなります。

性能試験

パフォーマンス テストでは、ソフトウェアが予想されるワークロードの下で速度、拡張性、安定性の要件を満たしているかどうかを判断します。 パフォーマンス テストが存在しないか不十分なために、パフォーマンス メトリックが不十分なアプリケーションが市場に送り出されると、悪い評判が高まり、期待される販売目標を達成できない可能性があります。

だから、 ミッションクリティカルなアプリケーション 宇宙打ち上げプログラムや救命医療機器などは、性能テストを行って、逸脱することなく長期間稼働することを確認する必要があります。

Dunn & Bradstreet によると、Fortune 59 企業の 500% が毎週推定 1.6 時間のダウンタイムを経験しています。従業員数が 500 人以上の Fortune 10,000 企業の平均時給が 56 ドルであることを考えると、このような組織のダウンタイム コストの人件費は毎週 896,000 ドルとなり、年間 46 万ドル以上になります。

のみ 5分間のダウンタイム Google.com の廃止(19 年 13 月 XNUMX 日)は、検索大手に次のような費用がかかると推定されています。 $ 545,000。

企業は売上価値を失ったと推定される 1100秒あたりXNUMXドル 最近のせいで Amazon Web サービスの停止。

したがって、パフォーマンステストが重要です。 このプロセスを支援するには、このリストを確認してください。 パフォーマンステストツール.

パフォーマンステストの種類

ソフトウェア テストには主に 6 種類のパフォーマンス テストがあり、以下で説明します。

  • 負荷テスト – 予想されるユーザー負荷の下でアプリケーションが実行できる能力をチェックします。 目的は、ソフトウェア アプリケーションが稼働する前にパフォーマンスのボトルネックを特定することです。
  • ストレステスト 極端なワークロード下でアプリケーションをテストして、高トラフィックやデータ処理をどのように処理するかを確認することが含まれます。 目的は、アプリケーションのブレークポイントを特定することです。
  • 耐久テスト – これは、ソフトウェアが長期間にわたって予想される負荷を処理できることを確認するために行われます。
  • スパイクテスト – ユーザーによって生成された突然の大きな負荷のスパイクに対するソフトウェアの反応をテストします。
  • ボリュームテスト – ボリュームテスト中、大きな番号。 の。 データはデータベースに入力され、ソフトウェア システム全体の動作が監視されます。 目的は、さまざまなデータベース ボリュームの下でソフトウェア アプリケーションのパフォーマンスをチェックすることです。
  • スケーラビリティテスト – スケーラビリティ テストの目的は、ユーザー負荷の増加をサポートするための「スケールアップ」におけるソフトウェア アプリケーションの有効性を判断することです。 ソフトウェア システムへの容量追加を計画するのに役立ちます。

一般的なパフォーマンスの問題

パフォーマンスの問題のほとんどは、速度、応答時間、読み込み時間、およびスケーラビリティの低さに関係しています。速度は、多くの場合、アプリケーションの最も重要な属性の 1 つです。実行速度の遅いアプリケーションは、潜在的なユーザーを失うことになります。パフォーマンス テストにより、ユーザーの注意と関心を維持するのに十分な速度でアプリケーションが実行されるようになります。次の一般的なパフォーマンスの問題のリストを見て、速度がそれらの多くで共通の要因となっていることに注目してください。

  • ロード時間が長い – ロード時間は通常、アプリケーションの起動にかかる初期時間です。 通常、これは最小限に抑える必要があります。 一部のアプリケーションでは XNUMX 分未満でロードを行うことが不可能ですが、可能であればロード時間は数秒未満に抑える必要があります。
  • 応答時間が遅い – 応答時間は、ユーザーがアプリケーションにデータを入力してから、アプリケーションがその入力に対する応答を出力するまでにかかる時間です。 通常、これは非常に高速であるはずです。 繰り返しますが、ユーザーは待ち時間が長すぎると興味を失います。
  • スケーラビリティが低い – ソフトウェア製品は、予想されるユーザー数を処理できない場合、または十分な範囲のユーザーに対応できない場合、スケーラビリティが低下します。 負荷テスト アプリケーションが予想されるユーザー数を確実に処理できるようにするために実行する必要があります。
  • ボトルネック – ボトルネックとは、システム全体のパフォーマンスを低下させるシステム内の障害物です。 ボトルネックとは、コーディング エラーまたはハードウェアの問題により、特定の負荷の下でスループットが低下することを指します。 ボトルネックは、コードの XNUMX つのセクションに欠陥があることが原因で発生することがよくあります。 ボトルネックの問題を解決するための鍵は、速度低下の原因となっているコードのセクションを見つけて、そこを修正することです。 ボトルネックは通常、動作不良のプロセスを修正するか、ハードウェアを追加することで修正されます。 いくつかの 一般的なパフォーマンスのボトルネック  
    • CPU使用率
    • メモリ使用率
    • ネットワーク利用
    • Operaシステムの制限事項
    • ディスクの使用状況

パフォーマンス テストの方法

パフォーマンス テストに採用される方法論は大きく異なりますが、パフォーマンス テストの目的は同じです。 これは、ソフトウェア システムが特定の事前定義されたパフォーマンス基準を満たしていることを実証するのに役立ちます。 または、XNUMX つのソフトウェア システムのパフォーマンスを比較するのに役立ちます。 また、ソフトウェア システムのパフォーマンスを低下させる部分を特定するのにも役立ちます。

以下は、パフォーマンス テストを実行する方法に関する一般的なプロセスです。

パフォーマンステストのプロセス
パフォーマンステストのプロセス

ステップ 1) テスト環境を特定する

物理的なテスト環境、運用環境、および利用可能なテスト ツールを把握します。テスト プロセスを開始する前に、テスト中に使用されるハードウェア、ソフトウェア、およびネットワーク構成の詳細を理解します。これにより、テスターはより効率的なテストを作成できます。また、パフォーマンス テスト手順中にテスターが遭遇する可能性のある課題を特定するのに役立ちます。

ステップ 2) パフォーマンスの許容基準を特定する

これには、スループット、応答時間、リソース割り当ての目標と制約が含まれます。 これらの目標や制約以外のプロジェクトの成功基準を特定することも必要です。 多くの場合、プロジェクトの仕様には十分な種類のパフォーマンス ベンチマークが含まれていないため、テスターに​​はパフォーマンスの基準と目標を設定する権限が与えられる必要があります。 まったくない場合もあります。 可能であれば、比較対象となる類似のアプリケーションを見つけることは、パフォーマンスの目標を設定する良い方法です。

ステップ 3) パフォーマンス テストの計画と設計

エンド ユーザー間で使用状況がどのように異なるかを判断し、考えられるすべての使用例をテストするための主要なシナリオを特定します。 さまざまなエンド ユーザーをシミュレートし、パフォーマンス テスト データを計画し、収集するメトリクスの概要を作成する必要があります。

ステップ 4) テスト環境の構成

実行前にテスト環境を準備します。 また、ツールやその他のリソースも手配します。

ステップ 5) テスト設計を実装する

テスト設計に従ってパフォーマンス テストを作成します。

ステップ 6) テストを実行する

テストを実行して監視します。

ステップ 7) 分析、調整、再テスト

テスト結果を統合、分析、共有します。 その後、微調整して再度テストし、パフォーマンスの向上または低下があるかどうかを確認します。 通常、再テストするたびに改善は小さくなるため、CPU が原因でボトルネックが発生した場合は停止します。 その場合は、CPU 能力を高めるというオプションを検討することもできます。

パフォーマンス テストのメトリクス: 監視されるパラメータ

パフォーマンス テスト中に監視される基本パラメータには次のものがあります。

パフォーマンステストの指標

  • プロセッサーの使用状況 – プロセッサがアイドル状態ではないスレッドの実行に費やす時間の量。
  • メモリ使用量 – コンピュータ上のプロセスに使用できる物理メモリの量。
  • ディスク時間 – ディスクが読み取りまたは書き込みリクエストの実行でビジーである時間。
  • 帯域幅– は、ネットワーク インターフェイスで使用される XNUMX 秒あたりのビット数を示します。
  • プライベートバイト – プロセスが割り当てた、他のプロセス間で共有できないバイト数。 これらは、メモリ リークと使用量を測定するために使用されます。
  • コミットされたメモリ – 使用される仮想メモリの量。
  • メモリ ページ/秒 – ハード ページ フォールトを解決するためにディスクに書き込まれる、またはディスクから読み取られるページの数。 ハード ページ フォールトは、現在のワーキング セットにないコードが他の場所から呼び出され、ディスクから取得される場合に発生します。
  • ページフォールト/秒 – プロセッサによってフォールト ページが処理される全体の速度。 これは、プロセスがそのワーキング セットの外部からのコードを必要とする場合にも発生します。
  • XNUMX 秒あたりの CPU 割り込み – プロセッサが 1 秒間に受信して処理するハードウェア割り込みの平均数です。
  • ディスクキューの長さ – サンプル間隔中に選択されたディスクに対してキューに入れられた読み取りおよび書き込み要求の平均数です。
  • ネットワーク出力キューの長さ – パケット単位の出力パケットキューの長さ。 XNUMX を超える場合は遅延を意味し、ボトルネックを阻止する必要があります。
  • XNUMX 秒あたりのネットワーク合計バイト数 – フレーム文字を含む、インターフェイス上で送受信されるバイトのレート。
  • 反応時間 - ユーザーがリクエストを入力してから、レスポンスの最初の文字が受信されるまでの時間。
  • スループット – コンピューターまたはネットワークが XNUMX 秒あたりに受信するリクエストの割合。
  • 接続プールの量 – プールされた接続によって満たされるユーザー要求の数。 プール内の接続で満たされるリクエストが増えるほど、パフォーマンスは向上します。
  • アクティブなセッションの最大数 – 一度にアクティブにできるセッションの最大数。
  • ヒット率 – これは、の数と関係があります。 SQL コストのかかる I/O 操作ではなく、キャッシュされたデータによって処理されるステートメント。これは、ボトルネックの問題を解決するための出発点として適しています。
  • XNUMX 秒あたりのヒット数 – いいえ。 負荷テストの XNUMX 秒あたりの Web サーバー上のヒット数。
  • ロールバックセグメント – 任意の時点でロールバックできるデータの量。
  • データベースのロック – テーブルとデータベースのロックを監視し、慎重に調整する必要があります。
  • トップ待機 – メモリからデータを取得する速度を処理するときに短縮できる待機時間を決定するために監視されます。
  • スレッド数 – アプリケーションの健全性は、番号によって測定できます。 実行中で現在アクティブなスレッドの数。
  • ガベージコレクション – これは、未使用のメモリをシステムに戻すことに関係しています。ガベージ コレクションは、効率性を監視する必要があります。

パフォーマンステストのテストケースの例

  • テストケース01: 4 人のユーザーが同時に Web サイトにアクセスした場合、応答時間が 1000 秒以内であることを確認します。
  • テストケース02: ネットワーク接続が遅い場合、負荷がかかっているアプリケーションの応答時間が許容範囲内であることを確認します。
  • テストケース03: アプリケーションがクラッシュする前に処理できる最大ユーザー数を確認してください。
  • テストケース04: 500 件のレコードを同時に読み取り/書き込みする場合のデータベース実行時間をチェックします。
  • テストケース05: ピーク負荷条件下でのアプリケーションとデータベース サーバーの CPU とメモリの使用量を確認します。
  • テストケース06: 低負荷、通常負荷、中負荷、高負荷の条件下でのアプリケーションの応答時間を検証します。

実際のパフォーマンス テストの実行中、許容範囲、高負荷などのあいまいな用語は具体的な数値に置き換えられます。パフォーマンス エンジニアは、ビジネス要件とアプリケーションの技術的状況に応じてこれらの数値を設定します。

パフォーマンステストツール

市場にはさまざまなパフォーマンス テスト ツールが入手可能です。 テスト用に選択するツールは、サポートされているプロトコルの種類、ライセンスのコスト、ハードウェア要件、プラットフォームのサポートなど、多くの要因によって異なります。以下は、よく使用されるテスト ツールのリストです。

  • HP ロードランナー は、今日の市場で最も人気のあるパフォーマンス テスト ツールです。 このツールは、数十万のユーザーをシミュレートし、アプリケーションを実際の負荷にさらして、予想される負荷での動作を判断することができます。 ロードランナー 実際の人間のユーザーの行動をシミュレートする仮想ユーザー ジェネレーターを備えています。
  • jmeter – Web およびアプリケーション サーバーの負荷テストに使用される主要なツールの 1 つ。

よくある質問

パフォーマンス テストは、常にクライアント サーバー ベースのシステムに対してのみ実行されます。つまり、クライアント サーバー ベースのアーキテクチャではないアプリケーションでは、パフォーマンス テストは必要ありません。

たとえば、 Microsoft Calculator はクライアントサーバーベースではなく、複数のユーザーを実行するものでもありません。したがって、パフォーマンス テストの対象にはなりません。

性能テスト

パフォーマンス テストとパフォーマンス エンジニアリングの違いを理解することが重要です。 理解は以下で共有されます。

性能試験 に関係する学問です テストとレポート さまざまなパラメータの下でのソフトウェア アプリケーションの現在のパフォーマンス。

パフォーマンスエンジニアリング 必要なパフォーマンスを実現することを目的として、ソフトウェアをテストおよび調整するプロセスです。 このプロセスは、最も重要なアプリケーションのパフォーマンス特性、つまりユーザー エクスペリエンスを最適化することを目的としています。

歴史的に、テストとチューニングは明確に分離されており、しばしば競合する領域でした。 しかしここ数年、いくつかのテスターと開発者が独立して協力してチューニング チームを立ち上げてきました。 これらのチームが大きな成功を収めたため、パフォーマンス テストとパフォーマンス チューニングを組み合わせるという概念が定着し、現在ではそれをパフォーマンス エンジニアリングと呼んでいます。

まとめ

In ソフトウエアエンジニアリング, ソフトウェア製品を販売する前に、パフォーマンステストが必要です。 顧客満足度を確保し、製品の故障から投資家の投資を保護します。 通常、パフォーマンス テストのコストは、顧客満足度、忠誠心、維持率の向上によって十分に補われます。