例を含む完全なパフォーマンステストガイド

complete performance testing guide with examples

パフォーマンステストとは何ですか？

パフォーマンステストは「パフォーマンステスト」とも呼ばれ、応答性と安定性の観点から、ワークロードの下でアプリケーションまたはソフトウェアがどのように実行されるかを確認するために実行されるテストの一種です。パフォーマンステストの目標は、アプリケーションのパフォーマンスのボトルネックを特定して取り除くことです。

このテストは主に、ソフトウェアがアプリケーションの速度、スケーラビリティ、および安定性の期待される要件を満たしているかどうかを確認するために実行されます。

C ++インタビューの質問と回答

このチュートリアルシリーズでは、パフォーマンステストの種類、プロセス、パフォーマンステスト戦略のドキュメントを最初から作成するなどの詳細について説明します。

これはあなたがブックマークしたいと思うかもしれない詳細なチュートリアルシリーズです！

探検しましょう！

このシリーズのすべてのパフォーマンステストチュートリアルのリスト：

チュートリアル＃1： パフォーマンステスト完全ガイド （このチュートリアル）
チュートリアル＃2： パフォーマンス、負荷、ストレステストの違い
チュートリアル＃3： 機能テストとパフォーマンステスト
チュートリアル＃4： パフォーマンステスト計画とテスト戦略
チュートリアル＃5： パフォーマンステストを強化する方法
チュートリアル＃6： クラウドパフォーマンステストガイド
チュートリアル＃7： モバイルアプリパフォーマンステストガイド
チュートリアル＃8： 手動パフォーマンステストを実行する方法
チュートリアル＃9： Webサイトパフォーマンステストチュートリアル
チュートリアル＃10： パフォーマンステスト会社
チュートリアル＃11： LoadRunnerを使用したパフォーマンステスト （シリーズ）

ツール：

チュートリアル＃12： トップパフォーマンステストツール
チュートリアル＃13： Neoloadパフォーマンステストチュートリアル
チュートリアル＃14： BlazeMeterモバイルパフォーマンステストチュートリアル
チュートリアル＃15： WAPT負荷、ストレス、およびパフォーマンステストのチュートリアル
チュートリアル＃16： SmartMeter.ioWebサイトパフォーマンステストチュートリアル

学習内容：

• パフォーマンステストの種類
  • 負荷テスト
  • ストレステスト
  • ボリュームテスト
  • 容量テスト
  • 信頼性/回復テスト
• パフォーマンステストプロセス
• パフォーマンステスト戦略ドキュメントの書き方は？
  • サンプルパフォーマンステスト戦略テンプレート
  • ＃1）はじめに
    • 目的
    • 建築
  • ＃2）範囲
    • 範囲内
    • 範囲外
  • ＃3）アプローチ
    • パフォーマンステストシナリオ
    • パフォーマンステストの種類
    • パフォーマンスメトリクス
    • パフォーマンステストの活動と成果物
  • ＃4）テストデータ
  • ＃5）入退場基準
  • ＃6）欠陥管理
    • 欠陥の重大度の定義
  • ＃7）テストツールとテクニック
  • ＃8）一時停止と再開の基準
  • ＃9）テスト成果物
  • ＃10）役割と責任
  • ＃11）潜在的なリスクと軽減計画
  • ＃12）仮定
  • ＃13）依存関係
  • ＃14）略語
• 現実的なパフォーマンステストのベストプラクティス
  • ＃1）計画
  • ＃2）開発
  • ＃3）実行
  • ＃4）分析
  • 結論
  • 推奨読書

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

負荷テスト

負荷テストは、アプリケーションが通常およびピーク使用時のパフォーマンスについてテストされるパフォーマンステストの一種です。アプリケーションのパフォーマンスは、ユーザーリクエストへの応答と、さまざまなユーザー負荷に対して許容範囲内で一貫して応答する能力に関してチェックされます。

重要な考慮事項は次のとおりです。

1. アプリケーションが予期しない動作を開始する前に、アプリケーションが保持できる最大負荷はどれくらいですか？
2. システムの速度が低下したり、クラッシュが発生したりする前に、データベースが処理できるデータの量はどれくらいですか？
3. 対処すべきネットワーク関連の問題はありますか？

ストレステスト

ストレステストは、システムを破壊する方法を見つけるために使用されます。このテストでは、システムが保持できる最大負荷の範囲も提供されます。

一般に、ストレステストには、負荷が徐々に増加する増分アプローチがあります。テストは、アプリケーションがすでにテストされている負荷から開始されます。次に、負荷をゆっくりと追加して、システムに負荷をかけます。サーバーが要求に応答していないことがわかり始めた時点が、ブレークポイントと見なされます。

次の質問に対処する必要があります。

• システムが故障する前にシステムが耐えることができる最大負荷はどれくらいですか？
• システムはどのように故障していますか？
• クラッシュした後、システムは回復できますか？
• システムが壊れる可能性のある方法はいくつあり、予期しない負荷を処理しているときに弱いノードはどれですか？

ボリュームテスト

ボリュームテストは、アプリケーションのパフォーマンスが、アプリケーションによって処理されているデータのボリュームによって影響を受けないことを確認することです。ボリュームテストを実行するために、膨大な量のデータがデータベースに入力されます。このテストは、増分テストまたは定常テストにすることができます。インクリメンタルテストでは、データの量が徐々に増加します。

一般に、アプリケーションの使用に伴い、データベースのサイズが大きくなり、重いデータベースに対してアプリケーションをテストする必要があります。この良い例は、最初に保存するデータが少量の新しい学校や大学のWebサイトですが、5〜10年後、Webサイトのデータベースに保存されるデータははるかに多くなります。

容量テスト

=>アプリケーションは、通常の負荷状態とピーク負荷状態の両方でビジネスボリュームを満たすことができますか？

容量テストは通常​​、将来の見通しのために行われます。 キャパシティテストでは、次のことに対処します。

1. アプリケーションは将来の負荷をサポートできますか？
2. 今後の増加する負荷に耐えられる環境はありますか？
3. 環境を十分に機能させるために必要な追加のリソースは何ですか？

キャパシティテストは、特定のWebアプリケーションがサポートし、パフォーマンスを維持できるユーザーやトランザクションの数を決定するために使用されます。このテストでは、プロセッサ容量、ネットワーク帯域幅、メモリ使用量、ディスク容量などのリソースが考慮され、目標を達成するために変更されます。

オンラインバンキングは、容量テストが主要な役割を果たす可能性がある場所の完璧な例です。

信頼性/回復 テスト

信頼性テストまたは回復テスト–障害または異常な動作の後にアプリケーションが通常の状態に戻ることができるかどうか、およびそのためにかかる時間（つまり、時間の見積もり）を確認することです。

オンライン取引サイトで、ユーザーが1日の特定の時点（ピーク時間）に株式を売買できないが、1〜2時間後には株式を売買できるという障害が発生した場合、アプリケーションは信頼できると言えます。異常な動作から回復しました。

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

このテストで実行されたすべてのアクティビティは次のとおりです。

＃1）要件分析/収集

パフォーマンスチームは、技術的およびビジネス上の要件の特定と収集のためにクライアントと対話します。これには、アプリケーションのアーキテクチャ、テクノロジー、使用されているデータベース、対象ユーザー、機能、アプリケーションの使用状況、 テスト要件 、ハードウェアおよびソフトウェア要件など。

＃2）POC /ツールの選択

重要な機能が特定されると、POC（Proof Of Concept –リアルタイムアクティビティの一種のデモンストレーションですが、限られた意味で）が利用可能なツールを使用して実行されます。

使用可能なツールのリストは、ツールのコスト、アプリケーションが使用しているプロトコル、アプリケーションの構築に使用されているテクノロジー、テスト用にシミュレートしているユーザーの数などによって異なります。POC中に、識別されたキーのスクリプトが作成されます。機能性があり、10〜15人の仮想ユーザーで実行されます。

＃3）パフォーマンステストの計画と設計

前の段階で収集された情報に応じて、テストの計画と設計が行われます。

テスト計画には、パフォーマンステストがどのように行われるか（テスト環境、ワークロード、ハードウェアなど）に関する情報が含まれます。

以下のテスト戦略ドキュメントの詳細。

＃4）パフォーマンステストの開発

• PTのスコープとしてテスト計画で特定された機能のユースケースが作成されます。
• これらのユースケースは、承認のためにクライアントと共有されます。これは、スクリプトが正しい手順で記録されるようにするためです。
• 承認されると、スクリプト開発は、POC（概念実証）中に選択されたパフォーマンステストツールを使用したユースケースの手順の記録から始まり、相関（動的な値を処理するため）、パラメーター化（値の置換）、およびカスタム機能を次のように実行することによって強化されます。状況やニーズに応じて。これらのテクニックの詳細については、ビデオチュートリアルをご覧ください。
• 次に、スクリプトはさまざまなユーザーに対して検証されます。
• スクリプトの作成と並行して、パフォーマンスチームはテスト環境（ソフトウェアとハ​​ードウェア）のセットアップにも取り組んでいます。
• パフォーマンスチームは、このアクティビティがクライアントによって処理されない場合、スクリプトを介してメタデータ（バックエンド）も処理します。

＃5）パフォーマンステストモデリング

テスト実行用にパフォーマンス負荷モデルが作成されます。このステップの主な目的は、特定のパフォーマンスメトリック（クライアントによって提供される）がテスト中に達成されたかどうかを検証することです。負荷モデルを作成するには、さまざまなアプローチがあります。 「「 リトルの法則 ほとんどの場合、」が使用されます。

＃6）テストの実行

シナリオは、コントローラーまたはパフォーマンスセンターの負荷モデルに従って設計されていますが、初期テストは、負荷モデルに含まれる最大ユーザー数では実行されません。

テストの実行は段階的に行われます。 例えば、 ユーザーの最大数が100の場合、シナリオは最初に10、25、50ユーザーなどで実行され、最終的に100ユーザーに移動します。

＃7）テスト結果の分析

テスト結果は、パフォーマンステスターに​​とって最も重要な成果物です。ここで、パフォーマンステストの取り組みが提供できるROI（投資収益率）と生産性を証明できます。

結果分析プロセスに役立ついくつかのベストプラクティス：

1. すべてのテスト結果に一意で意味のある名前–これはテストの目的を理解するのに役立ちます。
2. テスト結果の要約に次の情報を含めます。

• 失敗の理由
• 前回のテスト実行と比較したアプリケーションのパフォーマンスの変化
• アプリケーションビルドまたはテスト環境の観点からテストで行われた変更。
• テスト結果が参照されるたびに分析結果がコンパイルされないように、各テストの実行後に結果の要約を作成することをお勧めします。
• PTは通常、正しい結論に達するために多くのテストを実行する必要があります。
• 結果の要約に次の点があるとよいでしょう。
  • テストの目的
  • 仮想ユーザーの数
  • シナリオの概要
  • テストの期間
  • スループット
  • グラフ
  • グラフの比較
  • 反応時間
  • エラーが発生しました
  • 推奨事項

＃8）レポート

結論がより明確になり、導出を必要としないように、テスト結果を簡略化する必要があります。開発チームは、分析、結果の比較、および結果の取得方法の詳細に関する詳細情報を必要としています。

テストレポートは、簡潔で説明的で要領を得たものであれば、優れていると見なされます。

パフォーマンステスト戦略ドキュメントの書き方は？

このチュートリアルでは、メッセージングアプリケーションのサンプルパフォーマンステスト戦略を作成する方法について説明します。

これは単なる例であり、要件はクライアントごとに異なることを忘れないでください。このチュートリアルでは、パフォーマンステストのベストプラクティスについても説明します。

サンプルパフォーマンステスト戦略テンプレート

ABCチャットアプリケーションについて– これがカスタマーサポートエージェントによって会社で使用されているチャットワークベンチであると仮定します。このチャットアプリケーションは、インスタントメッセージの送受信にXMPPプロトコル（Extensible Messaging and PresenceProtocolとOpenfire server）を使用します。

リモートPC制御、PC診断、修復ツール、オンラインチャットなど、この既存のチャットクライアントにいくつかの機能拡張が行われているため、このパフォーマンステスト戦略はそのようなアプリケーションのサンプルです。

このアプリケーションでは、プロジェクトチームが使用することを決定したと仮定しましょう JMeter パフォーマンステストおよび JIRA 欠陥追跡用。

パフォーマンステスト戦略ドキュメントの最初のページには、ドキュメントのタイトルと会社の著作権が含まれている必要があります。

charからintc ++

2番目のページには、ドキュメントのバージョン履歴、レビュー担当者と承認者のリスト、および寄稿者のリストを含むドキュメントコントロールが含まれている必要があります。

3ページ目には目次が含まれ、その後に以下のトピックが続きます。

＃1）はじめに

このドキュメントの目的は、現在および将来の状態について、ABCチャットアプリケーションでパフォーマンステストを実行する方法を定義/説明することです。

ABCチャットアプリケーションは、社内のリモートサポートエージェントワークベンチです。このワークベンチは、顧客の要求を満たすために使用されます。このワークベンチには、オンラインチャット、顧客識別、リモートPC制御、PC診断、修復ツールなどの機能があります。

目的

パフォーマンステストの主な目的は次のとおりです。

• 既存のチャットアプリケーションへの変更が定義されたサービスレベルアグリーメントに沿っているという確信を得るため。
• 新しい拡張機能の結果として、アプリケーションのパフォーマンス、サービスの可用性、およびアプリケーションの安定性が影響を受けないようにするため。
• トランザクション応答時間は、増加する負荷プロファイルにわたって許容範囲内にとどまります。
• JVMは、増加する負荷プロファイルにわたって安定したメモリ使用量を示します。

次の図は、パフォーマンステストと最適化のプロセスを明確に説明しています。

建築

このセッションでは、プロジェクトのアーキテクチャ図を組み込む必要があります。

＃2）範囲

範囲内

以下は、ABCチャットワークベンチのパフォーマンステストスコープです。

• システムの詳細な調査後、主要なビジネストランザクションの知識獲得と負荷分散の構築。
• さまざまなプロジェクトトラックの支援を受けて、パフォーマンステストの重要なシナリオを特定します。
• 以前のリリースの結果を将来のリリースのベースラインとして使用します。
• 追加のエージェントマシンのパフォーマンステスト環境とパフォーマンス/負荷テストツールインフラストラクチャを確認および検証します。
• 特定されたピーク負荷を模倣する特定されたシナリオのためのJMeterを使用したパフォーマンステストスクリプトの準備。
• テスト実行フェーズ中のボトルネックを特定するために、テストを監視するためにサーバーにパフォーマンス監視をセットアップします。
• パフォーマンステストの結果を公開します。
• 特定されたパフォーマンスの問題を解決するために、さまざまな利害関係者と調整します。
• 将来のリリースのパフォーマンスレベルをベースライン化します。

範囲外

• 機能テスト 、UAT、システムテストおよびセキュリティテスト。
• サードパーティのインターフェイスのパフォーマンステスト/監視。
• 性能調整。 （ほとんどの場合、チューニングは別のチームによって行われます。システムをチューニングするパフォーマンスエンジニアがいる場合は、これをInscopeに追加できます）。
• コードプロファイリング/ハードウェアサイジング/キャパシティプランニング。
• セキュリティ/脆弱性テスト/ UAT / ホワイトボックステスト 。
• パフォーマンステストのためのデータ生成。
• 非機能テスト（ 例えば、 パフォーマンステスト以外のフェイルオーバー、ディザスタリカバリ、バックアップ、ユーザビリティ）。
• モバイルソリューションのテスト。
• サードパーティアプリケーションのパフォーマンステストとチューニング。
• パフォーマンスの推奨事項、アプリケーションコードの変更、およびベンダーがサポートする製品/サーバー構成の変更の実現は、パフォーマンスチームの観点からは範囲外になります。
• インフラストラクチャのサポート/ビルドの展開/環境の準備/データベースの復元/ネットワークのサポートなど

＃3）アプローチ

ABCチャットのパフォーマンステストは、XMPP接続にsmackライブラリを使用するカスタムXMPPプラグインを作成することにより、Jmeterを使用して実施されます。これらのライブラリは、接続のセットアップ、ログイン、およびXMPPサーバーへのチャットメッセージの送信に使用されます。

これらのライブラリは、Jmeterにデプロイされ、テストされるシナリオに基づいて設計されたjarファイルにバンドルされています。 Jmeter Work Benchは、負荷ジェネレーターを備えたJMeterサーバーに接続するローカルマシンにインストールされ、システムの動作を監視するためにチャットサーバーシステムに必要な負荷を生成します。

テストシナリオは、JMeterツールを使用してスクリプト化されます。スクリプトは必要に応じてカスタマイズされます。スケジュールは、実際のシナリオをシミュレートするために必要なランプアップで作成されます。

テストシナリオは、以下の側面で分割および測定されます。

a）ベースラインテスト： アプリケーションのパフォーマンスがビジネスのサービスレベル契約を満たしているかどうかを確認するために、1つの仮想ユーザーと複数の反復で各シナリオを実行します。

Windows7用の無料のバックアップソフトウェア

b）ベースロードテスト： 負荷テスト中のビジネスベンチマークを満たすために、パフォーマンステストチームはベースロードテストを実行します。これは、負荷の増加に伴うシステムパフォーマンスの問題を特定し、次のレベルのパフォーマンステストのベースラインを作成するのに役立ちます。

c）ピーク負荷/スケーラビリティテスト： パフォーマンステストチームは、予想される負荷を満たすために仮想ユーザーを増やして複数のテストを実行し、アプリケーションパフォーマンスを測定してパフォーマンス曲線を確立し、展開がピークユーザー負荷の下でサービスレベル契約をサポートできるかどうかを識別します。

これは、個々のJava仮想マシン（JVM）、必要なJVMの総数、およびプロセッサーの調整または容量計画に役立ちます。これは、仮想ユーザーの数をピーク容量の50％、75％、100％、および125％に増やすことで実現されます。

d） 耐久試験： パフォーマンステストチームは、このテストを8時間/ 16時間/ 24時間実行して、メモリリーク、時間の経過に伴うパフォーマンスの問題、およびシステム全体の安定性を特定します。耐久性テスト中、パフォーマンステストチームは、トランザクションの応答時間やメモリ使用量の安定性などの主要業績評価指標を監視します。

CPU、メモリ、IOなどのシステムリソースは、プロジェクトチームの助けを借りて監視する必要があります。

パフォーマンステスト環境は、実稼働環境のレプリカであると想定されています。テストは、アプリケーションが失敗する場所を特定するために、増分ロードで実行されます。

パフォーマンステストシナリオ

一連のシナリオにExcelを含めます。

例えば、

シナリオ1：シナリオ1： Xのエージェントとカスタマーチャットを検証するには同時セッションの。

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

以下の表は、さまざまなタイプのパフォーマンステストとその目的を説明しています。

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

• クライアント側のメトリクス

• システムとネットワークのパフォーマンスメトリクス

パフォーマンステストの活動と成果物

＃4）テストデータ

パフォーマンス環境データは本番データのコピーであり、必要なテストデータはプロジェクトチームによって提供されると想定されています。

＃5）入退場基準

• 環境内のすべてのアプリケーションへのアクセス。
• 環境の準備が完了しました。
• パフォーマンステストデータの準備。

＃6）欠陥管理

• JIRAの欠陥管理モジュールは、プロジェクトで欠陥ログとクローズまでの追跡に使用されます。
• テスト実行フェーズで見つかった欠陥の識別はJIRAでキャプチャされ、これらの欠陥は以下の重大度に従って開発チームによって解決されます。
• 欠陥レビュー会議は、テスト、開発、品質アナリスト、およびビジネスチームの参加を得て毎日開催されます。
• プロジェクトが稼働開始日に近づくにつれて、欠陥を修正するための基準は厳しくなります。欠陥レビュー会議で公開される欠陥修正基準のガイドライン。

欠陥の重大度の定義

重大度コードの定義は次のとおりです。

＃7）テストツールとテクニック

＃8）一時停止と再開の基準

以下に示すのは、テストアクティビティに影響を与えるクリティカルな一時停止と再開の基準です。

＃9）テスト成果物

パフォーマンステストの成果物は次のとおりです。

• パフォーマンステスト戦略
• パフォーマンス要件ドキュメント
• パフォーマンステストシナリオドキュメント
• パフォーマンステストスクリプト
• パフォーマンステストの結果

＃10）役割と責任

役割と責任は、以下の表に明確に説明されています。

＃11）潜在的なリスクと軽減計画

＃12）仮定

• パフォーマンステスト環境は、製品アーキテクチャランドスケープのレプリカになります。 （つまり、正しいハードウェア、ソフトウェア、インターフェース、統合レイヤーなど）。
• パフォーマンススクリプトは、使用率の高いクリティカルフローに基づいて設計されます。
• パフォーマンステストを開始する前に、すべてのインフラストラクチャの問題を解決する必要があります。後でシステム構成を変更すると、テスト結果が無効になります。
• アプリケーションは安定しており、パフォーマンステスト環境ですぐに使用できます。
• 必要なハードウェアおよびソフトウェアリソース（負荷ジェネレーターマシン/ソフトウェア、コントローラー/エージェントマシンなど）が利用可能になります。
• スコープへの変更はすべて変更管理プロセスを経て、パフォーマンステストチームがタイムラインとリソースの影響を評価します。
• それぞれのサーバーが負荷を処理することが期待されています。
• アプリケーショントレースログは、監視目的でサポートシステムに対して有効にする必要があります。

＃13）依存関係

• 製品アーキテクチャランドスケープのレプリカであるパフォーマンステスト環境の可用性。
• テストの準備と実行の段階で、さまざまな機能、開発、データベース、インフラストラクチャの各チームからのサポートが必要です。
• 時間が非常に限られているため、パフォーマンステストフェーズ全体でコードの変更は実装されません。
• タイムライン内の制限につながる予期しない問題が発生した場合、タイムラインですべてのテストスコープを元のマイルストーンの日付内に満たすことができない場合は、リリースマネージャーからサポートを利用して、スコープと優先順位を決定できます。
• アプリケーションビジネスユーザー/対象分野の専門家は、機能の説明とビジネストランザクションの承認に利用できるようになります。
• ABCチャットプログラムマネージャーが確認してサインオフします。

＃14）略語

これまでに、メッセージングアプリケーションの効果的なパフォーマンステスト戦略を作成する方法を明確に理解している必要があります。

現実的なパフォーマンステストのベストプラクティス

パフォーマンステストプロジェクトを正常に完了するには、計画段階、つまり計画、開発、実行、分析から正しい方法でプロジェクトを実行していることを確認する必要があります。

パフォーマンステストを効果的に実施するために、各段階を詳しく見ていきましょう。

＃1）計画

• 最も一般的なワークフロー、つまりテストする必要のあるビジネスシナリオを特定してください。アプリケーションが既存のものである場合は、サーバーログを確認して、最も頻繁にアクセスされるシナリオを理解してください。アプリケーションが新しい場合は、プロジェクト管理チームに相談して、主要なビジネスフローを理解してください。
• 軽度の使用量、中程度の使用量、ピーク負荷などの幅広いワークフローをカバーするように、負荷テストを計画します。
• 負荷テストを何度も実行する必要があるため、同じスクリプトを何度も使用できるようにフレームワークを作成してみてください。また、スクリプトのバックアップをとるようにしてください。
• テストを実行する必要がある時間を分析してみてください。1時間ですか？ 8時間？ 1日または1週間？通常、長期間のテストでは、OSのバグ、メモリリークなど、多くの主要な欠陥が明らかになります。
• 組織でAPM（アプリケーション監視ツール）を使用している場合は、テスト実行中にそれを含めることができるため、パフォーマンスの問題を簡単に特定し、根本原因をより簡単に特定できます。

＃2）開発

• スクリプトを開発するとき、つまり記録するときは、計画に記載されているビジネスフロー名に基づいて、より意味のあるトランザクション名を付けるようにしてください。
• サードパーティのアプリケーションを記録しないでください。記録された場合は、スクリプトを拡張しながら除外してみてください。
• ツールの自己相関機能を使用してすべての動的値を相関させることができるわけではないため、エラーを回避するために手動相関を実行してみてください。
• キャッシュサーバーだけでなく、アプリケーションのバックエンドにアクセスするようにパフォーマンステストを設計してください。

＃3）実行

• SSL、ロードバランサー、ファイアウォールなどの要素を含む、本番環境のような環境でテストを実行してください。これは、システムの現実的な負荷をシミュレートするために必要です。
• 非常に現実的なワークロードを作成してみてください。これは、サーバーログが既存のアプリケーションであるかどうかを確認し、新しいアプリケーションである場合は、ビジネスチームからこの情報を取得する必要があります。パフォーマンステストを成功させるには、ワークロードが非常に重要であることを忘れないでください。
• 実稼働サイズの半分の環境でテストを実行して結論を​​出すことは決してありません。実稼働とまったく同じ環境でテストを実行することを常にお勧めします。
• 長時間のテストを実行している間は、テストがスムーズに実行されていることを確認するために、頻繁に実行を監視するようにしてください。

＃4）分析

• 最初にいくつかの重要なカウンターを追加してアプリケーションを分析し、ボトルネックが見つかったら、ボトルネックに関してカウンターを追加してみてください。これにより、問題をより簡単に見つけることができます。
• アプリケーションは、リクエストへの応答に失敗したり、エラーコードで応答したり、検証ロジックに失敗したり、応答が遅すぎたりするなど、さまざまな理由で失敗する可能性があります。したがって、結論を出す前に、これらすべてを調べてみてください。

結論

このチュートリアルでは、パフォーマンステストと、詳細な例を含むパフォーマンステスト戦略ドキュメントの作成方法に関する膨大な知識が得られたと思います。

今後のチュートリアルでは、パフォーマンス、負荷、およびストレステストの違いについて詳しく学習します。

また、チェック=> 無料のLoadRunner詳細トレーニングシリーズ

次のチュートリアル

推奨読書

• パフォーマンステストvs負荷テストvsストレステスト（違い）
• HPLoadRunnerチュートリアルを使用した負荷テスト
• クラウドパフォーマンステスト：クラウドベースの負荷テストサービスプロバイダー
• WAPTを使用したWebアプリケーションの負荷、ストレス、およびパフォーマンスのテスト
• ウェブサイトのパフォーマンステストツールとサービス
• 手動パフォーマンステストを実行する方法は？
• BlazeMeterを使用したモバイルアプリケーションのパフォーマンステスト
• LoadRunnerVuGenスクリプトを使用したWebサービスパフォーマンステスト