従来のエンタープライズソフトウェア製品とインターネット製品のパフォーマンステストは、原則とテスト方法は基本的に同じです。最大の違いは同時実行数の順序であり、インターネット
ソフトウェア製品のパフォーマンステストも実稼働環境で直接実行する必要があります。リンク圧力テスト。フルリンクテストは、実際には従来のエンタープライズソフトウェア製品のパフォーマンステストに基づい
ており、拡張されています。
パフォーマンスベンチマークテスト
これは、製品がリリースされるたびに完了する必要があるテストのタイプです。
パフォーマンスベンチマークテストには、固定パフォーマンステストを実行することにより、固定ハードウェア環境と展開アーキテクチャ（専用サーバー、固定専用ネットワーク環境、固定サイズのクラスターサイズ、同じシステム構成、同じ
データベースバックグラウンドデータなど）が与えられます。このシナリオでは、システムのパフォーマンステストレポートを取得し、以前のバージョンのリリース時のインジケーターと比較します。インジケーターが劣化していることが判明した場合は
、さらに調査する必要があります。
典型的な悪化傾向は主に以下の側面で現れます：
同じトランザクションの応答時間は遅くなります。
たとえば、以前のバージョンでは、ユーザーログインの応答時間は2秒でしたが、テストされた最新バージョンでは、応答時間は4Sにする必要があり、
システムリソースの占有率が向上しています。
たとえば、以前のバージョンでは、平均CPU使用率は15％でしたが、テストされた最新バージョンでは、平均CPU使用率が30％になり、
ネットワーク帯域幅使用率が高くなりました。
たとえば、以前のバージョンでは、送信された合計バイト数は20MBで、受信された合計バイト数は200MBでしたが、新しいバージョンでは、送信された合計バイト数は25MBになり、受信された合計バイト数は250MBになりました。
ここで注意すべきは、これらの劣化傾向の前提は、まったく同じ環境とテスト負荷であることです。さまざまな劣化インジケーターを確認するには、さまざまな方法があります。
トラブルシューティングの方法を説明する例として、最も一般的なトランザクション応答時間を使用します。
パフォーマンスベンチマークテストの比較結果から、ユーザーログインの応答時間が2秒から4秒に変化したことがわかったとします。したがって、最初に行う必要があるのは、1人のユーザーの場合に応答時間
が長くなるかどうかを確認することです。具体的な方法は、ユーザーログインの仮想ユーザースクリプトを個別に取り出し、シングルユーザーパフォーマンステストシナリオを確立して実行し、ユーザーログインの応答時間が遅いかどうかを観察すること
です。遅くなる場合、これはシングルユーザーログインシナリオであることを意味します。パフォーマンスの問題を再現でき、その後の処理は比較的簡単です。解決策は、シングルユーザーログインのバックエンドログファイルを分析し、バック
エンドログファイルを確認してログインを完了し、前のステップと比較して、ログイン操作時間を完了するためにどのステップが実行されるかを確認することです。追加の手順は何ですか？
速度が低下しない場合は、このパフォーマンスの問題を再現する必要があります。そのためには、ユーザーログインの仮想ユーザースクリプトに基づいて同時テストシナリオを構築する必要がありますが
、このシナリオの設計で使用する同時ユーザーの数と思考時間を追加する時間は明確ではありません。現時点では、通常、パフォーマンスベンチマークで同時ユーザー数と思考
時間を直接使用して、問題の再現を試みます。それが再現できない場合は、テスト負荷を徐々に増やし、応答時間の変化の傾向を観察できます。
ここで、過度のテスト負荷を使用してはならないことに注意してください。テスト負荷が大きすぎると、システムリソースもパフォーマンスのボトルネックになり、応答時間が確実に長くなります。ただし今回は、応答時間が長くなるのは、
主にリソースのボトルネックが原因であり、探し始めた理由ではありません。
この時点で問題を再現できる場合は、並行シナリオでのユーザーログイン操作のタイムスライスをさらに分析して、特定の理由を見つけることができます。この時点で問題を再現できない場合、状況はさらに複雑になります
つまり、ログイン操作のパフォーマンスは、他のビジネス操作、または特定のリソース競合関係に依存する可能性があります。これは、特定の問題の特定の分析です。
一般に、パフォーマンスの「悪化」の原因が特定されて修正された場合、システムがリリースされる前のパフォーマンスベンチマークインジケーターが劣化していないことを確認するために、パフォーマンスベンチマークテストをもう一度実行します。それは言うことができ
、各プレリリース版のための性能ベンチマークによって、私たちは、新しいパブリッシングシステム環境の全体的なパフォーマンスを達成するために、最終的な性能試験である、落ちないようにすることができます。
従来の大規模なソフトウェア会社の多くは、専用のパフォーマンステストチームを抱えています。このチームは、標準のパフォーマンスベンチマークシナリオを確立し、パフォーマンスベンチマークの結果を、製品をリリースできるかどうかの基礎の
1つとして使用します。たとえば、以前使用していたHPソフトウェアは、Performance Testing Center of Excellenceによって保守され、パフォーマンスベンチマークテストを実行し、テスト結果を分析しました。
パフォーマンスベンチマークテストの設計の観点から、次の3つの点に特別な注意を払う必要があり
ます。1.パフォーマンスベンチマークテストでの仮想ユーザースクリプトの選択と比率は、実際の負荷状況にできるだけ一致する必要があります
。2.全体的な負荷設計は適切ではありません。高すぎる、通常、テストするシステムのすべての種類の占有率を30％以内に制御する必要があります
。リソースのボトルネックによる操作の遅延を回避するようにしてください。3。各パフォーマンスベンチマークテストの前に、通常、システムとネットワークリソースを実行する必要があります。毎回テスト対象の環境の一貫性を確保するため、およびデータベースのデータ量が
同じレベルであることを保証するための一連の迅速なベンチマークテスト。つまり、複数のパフォーマンスベンチマーク間で環境の一貫性を確保するために、あらゆる可能な手段を使用する必要があります。
安定性試験
安定性テストは信頼性テストとも呼ばれ、主にテスト対象システムのテスト負荷を長期間シミュレーションして、システムに長期的な運用中に潜在的な問題があるかどうかを確認します。システムインジケーターの監視を通じて
、安定性テストはメモリリークやリソースの違法な占有などの問題を見つけることができます。
多くのエンタープライズレベルのサーバー側製品は、リリース前に安定性テストを受けることがよくあります。安定性テストでは通常、パフォーマンスベンチマークテストで仮想ユーザースクリプトを直接使用しますが、パフォーマンステストシナリオ
とパフォーマンスベンチマークテストシナリオの設計は大きく異なります。最初にテスト負荷を徐々に増やすなど、「ウェーブ」テスト負荷が一般的に使用されます。高負荷の場合、10時間以上続いてから徐々に負荷が軽減され、
これが「波」を構成し、安定性テスト全体が複数の波から構成されます。
安定性は、主に以下の三つで、正常に完了フラグをテスト：
システム・リソースのすべてのモニタリング指標は、不可逆的な上昇傾向が存在しない、
取引動向の応答時間が徐々に遅く存在せず、
エラーレートは、トランザクションの1％を超えない
実際のプロジェクトをプロジェクトでは、安定性テストの実行時間のコストが高いため、通常3〜7日かかるため、他のすべてのテストが完了し、すべての問題が
修正された後で、安定性テストを開始します。
さらに、安定性テストの時間を短縮するために、「時間軸圧縮」方式を採用する企業もあります。具体的なアプローチは、テスト負荷を増やすことを前提に、各「波」
時間を適切に短縮して、全体的なテスト実行時間。
最後に、特に製品のバージョンが次第に成熟している場合は長い間ですが、安定性テストは問題を検出しませんが、
安定性テストの価値を過小評価しないでください。問題は、これらの問題は非常に深刻で非常に隠れた問題です。
したがって、多くの大規模なエンタープライズソフトウェア会社は、厳密な安定性テストを実行し、安定性テストの結果を、製品をリリースするためのハード要件として使用します。
同時実行テスト
並行性テストは、高い並行性の下で単一のビジネス機能の正確さとパフォーマンスを検証するためのテスト方法です。高い同時実行性のテストでは、一般に、思考時間がゼロの仮想ユーザースクリプトを使用して、「集約ポイント」で
テストを開始します。同時実行テストは、機能テストの補足としてよく使用され、主にマルチスレッド、リソース競合、リソースデッドロックなどのエラーを見つけるために使用されます。同時テストを実行するには、「ランデブーポイント」を追加する
必要があるため、多くの場合、仮想ユーザースクリプトを変更する必要があります。ランデブーポイントを結合するには、一般に2つの方法があります：
1.仮想ユーザースクリプトの記録中に直接
追加するか、2。lr_rendezvous（）関数を追加して仮想ユーザースクリプトを追加します。
キャパシティプランニングとテスト
キャパシティプランニングテストは、キャパシティプランニングを完了するために設計および実行されるテストです。キャパシティプランニングとは何ですか？いわゆるキャパシティプランニングは、ソフトウェア製品がユーザーの目標負荷を満たすように生産能力を調整するプロセスです。
したがって、キャパシティプランニングの主な目的は、システムの負荷が
処理能力の限界に近づいているときに、垂直拡張（単一マシンのハードウェアリソースを増やす）と水平拡張（クラスター内のマシン数を増やす）によってシステムの全体的な負荷処理能力をどのように増やすかを解決することです。質問です。現在、容量計画の主な方法は水平拡張に基づいています。ただし、追加するマシンの数、およびシステムの負荷処理能力が
増加後に直線的に増加するかどうか、これらの問題は、キャパシティプランニングを通じて検証する必要があります。
では、キャパシティプランニングテストは正確には何をするのでしょうか。パフォーマンスベンチマークテストの仮想ユーザースクリプトと各ビジネスオペレーションスクリプトのパーセンテージを使用して、単一のマシンによって展開されたテスト対象システムをテストできます。
手動方式を使用して、単一マシンシステムのスループットインデックスが単一マシンの処理能力に到達できる臨界値に達するまで、テスト負荷を継続的に増加させます。
まとめ
4種類のパフォーマンステスト方法、実際のプロジェクトでこれらのテストを実行してソフトウェアのパフォーマンスを確認する方法。
パフォーマンスベンチマークテストでは、新しくリリースされたシステムの全体的なパフォーマンスが低下しないことを確認できます。
安定性テストでは、主にテスト対象のシステムのテスト負荷を長時間シミュレーションして、システムに長期的な運用中に問題があるかどうかを確認します。
同時実行テストは、マルチスレッド、リソースの競合、リソースのデッドロックなどの問題を発見するために、機能テストが追加されています。
キャパシティプランニングとテストは主に、特定の負荷の下でのシステムクラスタのサイズを決定するために使用され、そのテスト結果はシステムキャパシティ設計の基礎として使用できます。
