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

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

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

パフォーマンス テストの焦点は、ソフトウェア プログラムの以下の点を確認することです。

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

パフォーマンス テストが重要な理由

ソフトウェアシステムがサポートする機能や性能だけが重要なのではありません。ソフトウェアアプリケーションのパフォーマンス、例えば応答時間、信頼性、リソース使用量、拡張性なども重要です。パフォーマンス テストの目的はバグを見つけることではなく、パフォーマンスのボトルネックを解消することです。

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

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

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

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

のみ 5分間のダウンタイム of Google.com（2013年8月19日）は、検索大手にとって、 $ 545,000。

企業は、推定で、 1100秒あたりXNUMXドル 最近のせいで Amazon Web サービスの停止。

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

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

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

• 負荷テスト – 予想されるユーザー負荷の下でアプリケーションが実行できる能力をチェックします。 目的は、ソフトウェア アプリケーションが稼働する前にパフォーマンスのボトルネックを特定することです。
• ストレステスト – 極端なワークロード下でアプリケーションをテストして、高トラフィックやデータ処理をどのように処理するかを確認することが含まれます。 目的は、アプリケーションのブレークポイントを特定することです。
• 耐久テスト – これは、ソフトウェアが長期間にわたって想定される負荷を処理できることを確認するために行われます。これにより、継続的な動作中にのみ顕在化するメモリリークやリソース枯渇などの問題を検出するのに役立ちます。
• スパイクテスト – スパイクテストは、ユーザーによって発生する負荷の急激な増加に対するソフトウェアの反応をテストします。ストレステストとは異なり、スパイクテストは、システムが短時間で急激に増加するトラフィックにどのように対処し、そこからどのように回復するかを特に重点的に検証します。
• ボリュームテスト – これは、大量のデータをデータベースに格納し、ソフトウェアシステム全体の動作を監視する作業です。目的は、データベースの容量が変化する状況下でのソフトウェアアプリケーションのパフォーマンスを確認することです。
• スケーラビリティテスト – ユーザー負荷の増加に対応するためのソフトウェアアプリケーションの「スケールアップ」の有効性を判断します。ソフトウェアシステムの容量拡張計画に役立ちます。

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

パフォーマンスの問題のほとんどは、速度、応答時間、読み込み時間、スケーラビリティの低さに起因します。速度は、アプリケーションにとって最も重要な属性の1つです。動作の遅いアプリケーションは、潜在的なユーザーを失います。パフォーマンス テストは、アプリケーションがユーザーの注意と関心を維持するのに十分な速度で動作することを保証します。以下は、速度が繰り返し問題となる一般的なパフォーマンスの問題です。

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

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

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

以下に、パフォーマンス テストを実施するための一般的な手順を示します。

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

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

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

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

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

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

ステップ4）テスト環境の設定

実行前にテスト環境を準備してください。また、必要なツールやその他のリソースも準備してください。テスト結果が現実的で実用的なものとなるよう、本番環境をできる限り忠実に再現してください。

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

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

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

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

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

テスト結果を統合、分析、共有します。その後、微調整を行い、再度テストしてパフォーマンスが向上したか低下したかを確認します。一般的に、再テストを繰り返すたびに改善度は小さくなるため、CPUがボトルネックになっていることが判明したらテストを中止します。その場合は、CPUの性能向上を検討する必要があるかもしれません。

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

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

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

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

以下は、パフォーマンス テストのサンプル テスト ケースです。

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

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

パフォーマンス テストのベスト プラクティス

確立されたベストプラクティスに従うことで、パフォーマンス テストは信頼性の高い結果をもたらします。これらのガイドラインは、チームがよくある落とし穴を回避するのに役立ちます。

• 生産環境を反映する – テスト環境は、本番環境にできる限り近い状態に設定してください。ハードウェアやソフトウェアのバージョンの違いは、誤った結果を招く可能性があります。
• 現実的なテストシナリオを設計する – 思考時間や同時トランザクションの組み合わせなど、実際のユーザー行動をシミュレートするテストケースを作成します。
• パーセンタイルベースの指標を使用する – 平均値だけでなく、90パーセンタイル値と95パーセンタイル値の応答時間を参考にしてください。パーセンタイル値は、平均値では隠されてしまう末端の遅延を明らかにします。
• 早期かつ継続的に検査する – パフォーマンス テストを最終段階の活動として扱うのではなく、CI/CD パイプラインに統合する。
• 文書化およびベースライン結果 – すべてのテスト実行結果を記録してください。新しい結果をベースラインと比較することで、リリース間の不具合を容易に検出できます。

AIがパフォーマンス テストをどのように変革しているか

人工知能はping 複雑な分析タスクを自動化し、予測機能を有効にすることで、パフォーマンステストを実現します。AIを活用したツールは、過去のデータを分析し、パターンを検出し、あらゆる段階で人間の介入を必要とせずに、実用的な推奨事項を提供します。

• 予測的異常検知 – AIアルゴリズムは、負荷テスト中にパフォーマンス指標をリアルタイムで分析し、重大な障害に発展する前に異常を検知して警告を発します。
• 自動根本原因分析 – AIを活用したツールは、分散システム全体のデータを相関分析することで、パフォーマンス低下の原因となっている正確なコンポーネントを特定します。
• インテリジェントなテスト最適化 – 機械学習モデルは、冗長なテストシナリオを特定し、最適な構成を提案することで、実行時間を短縮しながらテスト範囲を維持します。
• 自己修復テストスクリプト – AIはアプリケーションのインターフェースが変更された際にテストスクリプトを適応させることで、パフォーマンステストスイートのメンテナンス負担を軽減します。

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

市場には多種多様なパフォーマンス テスト ツールが存在します。テストに使用するツールの選択は、サポートされるプロトコルの種類、ライセンス費用、ハードウェア要件、プラットフォームのサポートなど、多くの要因によって決まります。以下に、よく使用されるテスト ツールの一覧を示します。

• HP ロードランナー – は、市場で最も人気のあるパフォーマンス テスト ツールの 1 つです。このツールは、数十万人のユーザーをシミュレートすることができ、アプリケーションに実際の負荷をかけて、想定される負荷下での動作を判定します。 LoadRunner 実際の人間のユーザーの行動をシミュレートする仮想ユーザー ジェネレーターを備えています。
• JMeter – ウェブサーバーやアプリケーションサーバーの負荷テストに使用される、主要なオープンソースツールの1つです。複数のプロトコルをサポートし、豊富なレポート機能を提供します。

よくあるご質問