パフォーマンステストの理由：
複数のクライアントが同時にアクセスするとプレッシャーが発生
●Webアプリケーションサーバー
●アプリケーションサーバー
●データベース
●ネットワーク
したがって、パフォーマンステストでは、生産前に対応する圧力を監視および復元する必要があります。
パフォーマンステストの概念
1.ソフトウェアシステムのパフォーマンステストは、非常に広い概念を持つ非常に大規模な概念です。
実行効率、リソース占有率、システムの安定性、セキュリティ、互換性、信頼性、およびスケーラビリティを含むソフトウェアシステム。（同時実行性が高い場合、2人での訪問と同じくらいスムーズにできます）
2.パフォーマンステストは、パフォーマンスに関連するテストオブジェクトの特性を記述および評価するタイプのテストであり、さまざまな正常、ピーク、および異常な負荷条件をシミュレートするために、主に自動テストツールを通じて実装および実行され
ます。テストする。
パフォーマンステストの概要
パフォーマンステストには通常、次の側面が含まれます。
生産準備ステータスの
評価、パフォーマンス判断基準の評価
、複数の異なるシステム間または同じシステムの異なる構成間のパフォーマンス特性の比較、パフォーマンス問題の原因の
特定、
システムパフォーマンスチューニングの支援、および
スループットレベルの決定そのような指標）
パフォーマンステストのコアアクティビティ
◆テスト環境の決定
テストチームが使用できる物理環境、実稼働環境、ツール、およびリソース。
◆パフォーマンス受け入れ基準を
決定して、応答時間（同時実行性が高い場合にリアルタイムでシステムにアクセスできる時間）、スループット（1秒あたりの処理可能なタスク数tps）、全体的なデータ使用率の目標と制限を決定します。 （CPU、メモリ使用状況）。
◆計画と設計のテスト
主要なシナリオを決定します（機能テストの通常のシナリオ、パフォーマンステストの複数同時実行、複数ユーザーアクセスを
推奨）一般的なユーザーの変動性とこれらの変更のシミュレーション方法を決定します。（継続的に動作するか、部分的に動作しない
か
など）収集する必要がある測定値（応答時間、tps、スループットなど）を決定するためのテストデータ（ユーザー数）を決定します。
◆テスト環境の構築テスト
する機能やコンポーネントの改善に伴い、各戦略の実行に必要なテスト環境、ツール、リソースを段階的に準備しています。
◆テスト設計の実装テスト設計に
基づく段階的なパフォーマンステスト
◆実行テスト
実行および監視テスト
◆結果の分析、レポート、繰り返しテスト
結果データの統合と共有
パフォーマンステストの目的
◆評価ソフトウェアのリリース準備
実際の生産におけるアプリケーションソフトウェアの特性を予測または推定し、これらの予測に基づいてパフォーマンス要因を強調する必要があるかどうかを評価します。
システムパフォーマンス特性に対するユーザーの不満を反映する関連データを
提供します。スケーラビリティの理由と安定性の問題、またはアプリケーションソフトウェアの対応する時間に対するユーザーの不満のために、予測に役立つデータを提供します。収益の損失またはブランドの信頼性下がる。
パフォーマンステストの概要
インフラの妥当性を評価する：
現在の容量の評価をするのに十分である
許容範囲の安定性を決定する
決定機能のアプリケーション・インフラストラクチャである
異なるシステム構成を比較し、実際のアプリケーションとビジネス要件との間のどの構成で最適な効果を決定することができる
決意アプリケーションを予想されるリソース使用制限内で、最高のパフォーマンス特性が示されています。
開発したソフトウェアのパフォーマンスが要件を満たしているかどうかを評価します。
対応するソフトウェアが変更される前後に、アプリケーションソフトウェアが
現在のパフォーマンス特性と達成可能な最高のパフォーマンス特性を提供するために、アプリケーションソフトウェアが満足のいくパフォーマンス特性を取得していることを確認する必要があります。比較。
パフォーマンス調整効率の向上：
さまざまな負荷レベルでのアプリケーションソフトウェアの動作ステータスを分析
し、製品リリースの前にアプリケーションソフトウェアのボトルネックを特定し、製品の動作速度、スケーラビリティ、および安定性に関する情報を提供します。利害関係者は、システムを調整するかどうか、またはいつ調整するかについて、より多くの情報に基づいた決定を行うことができます。
パフォーマンステストの種類
◆負荷テスト
◆ストレステスト
◆容量テスト
◆その他：
構成テスト
同時実行テスト
信頼性テスト
安定性テスト…
◆パフォーマンステストは、速度、スケーラビリティ、および（または）安定性など、テスト環境でのシステムまたはアプリケーションソフトウェアのさまざまな特性を決定または効果的に検証することです。
◆パフォーマンスとは、プロジェクトまたは製品のパフォーマンス目標を満たすのに十分な、対応する時間、スループット、およびリソース使用率を指します（出力は評価指標です）
◆パフォーマンステストは一般的な概念であり、その他のパーソナリティ関連のテストはパフォーマンスですテストのサブカテゴリ。
負荷テスト
1.ワークロード条件で実際にテストされているシステムまたはアプリケーションソフトウェアの関連するパフォーマンス特性を決定することに焦点を当てます。（50,000の同時実行を実現するには、応答時間は0.5秒以内でなければならないため、この条件下でのtps、時間、cpuなど、システムの対応するパフォーマンスインジケーターを確認してください。）
2.システム負荷を徐々に証明してシステムパフォーマンスの変化をテストし、最後に、パフォーマンスインジケーターの下でシステムが耐えられる最大負荷を決定します。（ユーザーの経験時間は、どの操作が実行されても、応答時間が0.5秒を超えることはできないため、人数の負荷インジケーターが表示されます。したがって、システムがロードできる最大負荷に到達するように、引き続き加圧しようとします）
3.負荷テストは、段階的な加圧を通じてシステムの処理能力を決定し、システムが耐えられるしきい値を決定することです。
ストレステスト
1. 実際の運用段階の期待を超える特定の条件下でのシステムまたはアプリケーションソフトウェアのパフォーマンス特性を決定します。（負荷は、システムが耐えることができます決定された場合、最大は今加圧され始めた5800から、8500で、そのリソースの一部が飽和でも見に失敗到達するためということが何であるかを、現在のパフォーマンス指標）
が徐々に増加させることにより2システムの負荷、システムパフォーマンスの変化のテスト、最終的にシステムのパフォーマンスが障害状態にある負荷条件を特定し、システムを取得して最も基本的なサービスを提供できます。
3.ストレステストは、負荷を徐々に増やしてシステムの特定のリソースを飽和させるか、場合によっては失敗させるテストです。
容量テスト
1. パフォーマンス目標を満たすことを前提に、システムは最大セッション容量を処理し、システムが同時に処理できるユーザーの最大数を決定します。
2.キャパシティテストでは、サーバーの限界故障ポイントを特定し、さまざまな負荷およびフローモードレベルでのパフォーマンス結果を監視します。（パフォーマンス目標を達成するという前提の下で、システムがクラッシュせず、通常のフィードバックを達成できる限り、到達できるプロセスの最大数。このような多数の同時実行性はより遅くなります。遅くなります。たとえば、メモリCPUは99.9％に達しています。 10000ですが、正常に実行できます。10050に追加すると、崩壊します。この10000は、容量テストと対応するパフォーマンスインデックスの結果です。
構成テスト（jdk、ソフトウェアパラメーターを調整し、コードを調整しない）
テストされたソフトウェアのソフトウェアおよびハードウェア構成をテストすることにより、システムリソースの最適な割り当て原理が見つかります。
同時実行テスト
デッドロックまたはその他のパフォーマンスの問題がある場合、複数のユーザーが同じアプリケーション、同じモジュールまたはデータレコードに同時にアクセスするかどうかをテストします。ほとんどすべてのパフォーマンステストには、いくつかの同時テストが含まれます
信頼性試験
システムに一定のビジネス上のプレッシャーをかけてロードし、一定期間実行して、システムが安定しているかどうかを確認します。通常、システムにメモリリークやその他の問題があるかどうかをテストできます。（ノンストップランニング）
安定性試験
複雑で変化する環境においてシステムが提供できる総合的な信頼性、堅牢性、機能
とデータの整合性、有効性、および応答の継続性。（例えば、ノンストップサービスアップグレードを実行し、システムが安定しているかどうか、顧客が操作できるかどうか）
コアパフォーマンステストアクティビティ：
コアパフォーマンステストアクティビティ
◆アクティビティ1：テスト環境を
決定する物理環境、本番環境、およびテストチームが使用できるツールとリソースを決定します。
物理環境には、ハードウェア、ソフトウェア、ネットワーク構成が含まれます。
テストの最初にテスト環境全体を包括的に理解すると、テストの設計と計画がより効果的になり、プロジェクトの早い段階でテストの複雑な問題を特定するのに役立ちます。
◆アクティビティ2：パフォーマンス受け入れ基準（製品の提供、および受け入れ基準を決定するためのエクスペリエンスデザイン）を
決定する応答時間、スループット、全体的なリソース使用率の目標と制限を決定します。
一般に、応答時間はユーザー関係の焦点であり、スループットはビジネス関係の焦点であり、リソース使用率はシステム関係の焦点です。
プロジェクトの成功基準を決定します。この基準は、上記の全体的な目標や制限に含まれない場合があります。たとえば、パフォーマンステストを使用して、関連する構成を組み合わせて最高のパフォーマンス特性を得る方法を評価します。（ページの1.2秒以内、アプリの0.5秒以内など、私たちが受け入れることができる応答時間）
◆アクティビティ3：計画と設計のテスト
典型的なユーザーの変動性を決定するための主要なシナリオ（5000の同時実行性、同時に同時入力、必要な分数）を決定し、この変動性をシミュレートする方法、および
テストデータを決定します。
この情報を実装、実行、および分析のための1つ以上のシステム使用モデル。
（シーンの組み合わせ、スパイクの一部、他の操作の一部）
◆活動4：テスト環境の設定
テストするのに最適な機能およびコンポーネントで、各政策がするために必要なテスト環境、ツール、およびリソースを実行する準備ができている徐々にとして
試験環境が適切に設定されていることを確認し、リソース監視することができ
◆アクティビティ5：
テスト設計を実装するテスト設計に基づいて、段階的なパフォーマンステストを実施します。
◆アクティビティ6：テストの
実行テストの実行と監視
テスト、テストデータ、結果が効果的に収集され
ていることを確認するテストとテスト環境を監視して、効果的なテストが確実に実行され、結果分析の精度が確保されるようにします。
◆アクティビティ7：結果を分析し、レポートを作成してテストを繰り返します。
単一のデータを分析するだけでなく、機能横断的なテストチームの観点からデータを分析するために、結果データを統合して共有
します。すべてのメトリックが許容範囲内にある場合、事前設定されたしきい値に違反し、必要なすべての情報を収集し、特定の構成に基づいて特定のフィールドでテストを完了しました
（以前のパフォーマンステストが目標に達しなかった場合は、再テストする必要があるかもしれませんが、今回は前のいくつかは必要ありません）ステップ、次のテストを実行する必要があります。）
