パフォーマンス テストのチュートリアル - タイプ (例)

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

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

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

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

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

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

パフォーマンス テストは、速度、安定性、拡張性に関するアプリケーションに関する情報を関係者に提供するために行われます。 さらに重要なことは、パフォーマンス テストにより、製品が市場に投入される前に改善が必要な点が明らかになります。 パフォーマンス テストを行わないと、ソフトウェアは次のような問題に悩まされる可能性があります。 複数のユーザーが同時に使用しているときに動作が遅くなるneo通常、異なるオペレーティング システム間での不一致と、使いやすさの低下が問題です。

性能試験

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • BlazeMeter – 市場で唯一の完全な継続的テスト プラットフォームです。 この強力なパフォーマンス テスト ツールは、信頼性の高いアプリを強化します。 テスターは、モック サービス、合成テスト データ、API テストとモニタリングなどの高度な機能を活用できます。 最大 2 万ユーザーまで拡張可能。
  • HP ロードランナー は、今日の市場で最も人気のあるパフォーマンス テスト ツールです。 このツールは、数十万のユーザーをシミュレートし、アプリケーションを実際の負荷にさらして、予想される負荷での動作を判断することができます。 ロードランナー 仮想ユーザー機能を搭載 generator これは、実際の人間のユーザーの行動をシミュレートします。
  • jmeter – Web およびアプリケーション サーバーの負荷テストに使用される主要なツールの 1 つ。

よくある質問

❓ どのアプリケーションのパフォーマンス テストを行う必要がありますか?

パフォーマンス テストは常にクライアント サーバー ベースのシステムに対してのみ行われます。これは、クライアントサーバーベースではないアプリケーションを意味します。 archi技術的には、パフォーマンス テストを必要としてはなりません。

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

性能テスト

⚡ パフォーマンス テストとパフォーマンス エンジニアリングの違いは何ですか?

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

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

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

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

要約

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