Jmeter のパフォーマンス テスト プロセスについての話

パフォーマンス テストに Loadrunner を使用するか jmeter を使用するかに関係なく、テスト プロセスは基本的に同じです。例としてテスト プロセスの分析を Jmeter に限定します。

1. パフォーマンステスト要件の分析

一般的に、テスト対象のオブジェクトのパフォーマンス要件は、単位時間あたりの訪問数、ビジネスの応答時間が超過してはいけない、ビジネスの成功率がそれを下回ってはいけない、ハードウェアなど、ユーザー要件の仕様で指定されます。リソース消費量は合理的な範囲内である必要があり、パフォーマンス指標は定量的なデータで与えられる必要があります。標準化された製品の場合、製品チームは次のパフォーマンス要件を与えます。

製品チームがパフォーマンス テストの要件を指定していない場合、またはシステムの TPS が 300 以上である必要があり、単一のトランザクション時間が 3 秒を超えないなど、文字通りの要件のみを指定している場合、テスト エンジニアはどのように数値化できますか?事前にインジケーターは？

ビジネス要件やシステム特性と組み合わせて、明示的および暗黙的な要件をさらに分解して抽出する必要があります。これらは、次の 2 つのユーザー方法から決定できます。

1. ビジネスユーザー

• ユーザーが頻繁に利用し、多くのユーザーが頻繁に利用する業務プロセスがある
• トランザクションの割合が高く、1 日あたりの割合が 80% 以上であるビジネス プロセス
• 特別取引日またはピークトランザクションが 80% 以上を占めるビジネス プロセス
• パフォーマンスが低く調整されたビジネスプロセス
• 特別なビジネスシナリオ
• コアビジネスは、大幅なプロセス調整を伴うビジネスプロセスを送信します

上記はビジネス ユーザー レベルで要求される可能性のあるパフォーマンス要件であり、実際のプロジェクトではエンド ユーザーに対して調査が行われる場合があります。

2.プロジェクトチーム（業務システム）

• 性能検証後にアーキテクチャ設計を調整した事業者
• 論理的に複雑で重要なビジネス
• リソースを大量に消費する可能性のあるビジネス
• 外部システムとのインターフェイス呼び出しがあり、大量のデータのやり取りを行うビジネスがある
• サードパーティのビジネスコンポーネント、ロジック複雑なビジネスを呼び出す

上記は、プロジェクト開発の観点から必要とされる可能性のあるパフォーマンス要件です。パフォーマンス テスト エンジニアは、開発チームと緊密に連携して、テスト対象を深く理解する必要があります。

3. 事例分析

分析を通じて、オンライン ショッピング モールのパフォーマンス需要指数を例として、次のデータを取得します。

2. テストケースの設計とテストデータの準備

1. テストケースの設計

テスト対象オブジェクトの潜在的なパフォーマンス問題を正確に反映するには、テスト対象オブジェクトがボトルネックとなる可能性のあるビジネス シナリオを可能な限りシミュレートする必要があります。ビジネス タイプはテスト要件分析プロセスで決定されます。 、次のパフォーマンス テスト シナリオを設計する必要があります。

2. テストデータの準備

このテストを例にとると、2 時間以内に 50,000 人のユーザーがログインします。これは、使用可能なアカウントが 50,000 個あることを意味します (できるだけ多くのアカウントを準備し、60,000 個まで可能)。これをデータベースに直接追加できますが、比較的精通している必要があります。データベース構造; Jmeter を使用して登録スクリプトを記録し、3 つのスレッドを使用し、2000 回ループできます。

テスト データの構築後、後の回帰テストのためにデータベースをバックアップする必要があります。NaviCat はデータのバックアップに使用できます。

3. パフォーマンステストスクリプトの開発

• ログイン ビジネス モデルに従って、BadBoy を使用してユーザーのログイン プロセスを記録し、Jmeter スクリプトを生成します。
• パラメータ化のためのログインユーザー名
• タイマーを設定します。テスト ケースを参照して情報を 5 秒間入力し、ログイン成功後の戻りを 3 秒待ち、正常終了後の戻りを待ちます。
• ログイン成功ページのアサーションを設定します。失敗した場合は情報を求めるプロンプトが表示され、成功した場合はプロンプトが表示されません。
• 結果ツリーの表示、集計レポートなどを追加して、スクリプトの実行ステータスをリアルタイムで表示します

4. シーンの設計とリソースの監視

1. シーンデザイン

ログイン業務を例に挙げると、このテストの目的は、プラットフォームが期間を考慮せずに 100 ユーザーの同時ログインをサポートできるかどうかを検証することです。対応するシナリオのテスト ケースに従って、スレッド グループ データを設定し、スクリプトを実行できます。普遍的に使用されます (必要に応じて削除できます) 時間を考えたり、ランデブー ポイントを追加したりできます)。

対応するスレッド グループの名前をシーン名「ユーザー ログイン ビジネス コンカレント ロード」に変更できます。

2. Jmeter はリソース監視に独自のプラグインを使用します

• JMeterPlugins-Extras-1.4.0.zip および JMeterPlugins-Standard-1.4.0.zip を Jmeter インストール ディレクトリ /lib/ext に解凍します。
• Jmeter を再起動し、リスナーを追加します: jp@gc - PerfMon メトリクス コレクター
• ServerAgent-2.2.3.zip をダウンロードし、rz コマンドを使用してサーバー (Linux) の指定されたディレクトリにアップロードし、unzip -o ServerAgent-2.2.3.zip を実行してファイルを現在のディレクトリに解凍します。
• サーバーのファイアウォールをオフにします: systemctl stop firewalld.service
• 起動ファイルの実行権限を設定します: chmod u+x startService.sh
• sh ファイルを実行します: ./startService.sh
• Jmeter リスナー jp@gc - PerfMon メトリクス コレクターの下に、CPU、メモリなどの監視対象リソースを追加します。
• シーンを実行して、サーバーの対応するリソースを監視します。

シナリオのユースケースの要件に従って、業務量テストのスレッド数を 78 に設定する必要があり、同時に実行時間を設定する必要があります (業務量指標: 50,000 トランザクションまたはを参照) TPSは2時間で完了）、設定は以下の通りです。

5. シナリオの実行と結果の分析

1. シナリオの実行

シナリオを実行する前に、テスト環境を確認して、すべての環境とシステム サービスが正常に使用できることを確認する必要があります。

• データベースのリカバリ（スクリプト設計プロセス中のデータベース内のデータ量への影響を回避）、商品や取引などの関連データを記録します。
• 商品をランダムに購入し、商品在庫がゼロになることを避けるため、在庫を一律1000個に設定します
• Jmeter がサーバーのパフォーマンスに与える影響を避けるために、サーバーを Linux システムに個別にデプロイしてみてください。
• 実行前に、対応するモニタリング エージェントと Apache および mysql サービスを開始します。

CMD での非 GUI モード実行シナリオ:

Jmeter -n -t 测试脚本Jmx文件 -l 日志文件名 -e -o HTML测试结果文件路径

2. シナリオ結果分析

集計レポートと組み合わせて、ログイン ビジネスの各リクエストの平均応答時間を分析します: 15 秒で、5 秒未満であるため、このインジケーター テストは失敗します。最大応答時間と最小応答時間が大きく異なる場合、90% のトランザクション応答を使用できます。標準的な時間です。

Apdex (Application Performance Index) 指標は国際標準です。アプリケーションのパフォーマンスに対するユーザーの満足度を定量的に表したもので、エンド ユーザーのエクスペリエンスとアプリケーションのパフォーマンスを統一的に測定できるように、統一された測定方法とユーザー エクスペリエンス方法を提供します。下図では、0 は満足度なし、1 は満足度を意味しますすべてのユーザーが満足する、それが開発チームが追求する目標です。

6. パフォーマンスのチューニングと回帰テスト

テスト結果の分析が完了すると、パフォーマンスの問題を特定して最適化できます。通常、パフォーマンスの問題は次のような側面で現れます。

1. 応答時間の問題:

• 応答時間は安定しているが長い、テスト中の応答時間は長い、スレッド数（負荷）を減らしても減少しない
• 応答時間は徐々に長くなり、テスト中は同じ負荷のままであり、実行時間が長いほど、エラーが多数発生するまでの応答時間が長くなります。
• 負荷の変化に応じて応答時間が変化し、応答時間が長くなります。負荷が減少すると、応答時間が短くなり、リソース使用率も低下します。
• データが蓄積するとロックが発生し、最初は正常に動作するが、データが一定量蓄積するとすぐにエラーが発生し、解消できず再起動するしかない

2. 安定性の問題:

特定のシナリオで、または長時間実行した後、突然問題が発生し、システムの動作が遅くなる主な原因は次のとおりです。

• 物理メモリリソースが不十分です
• メモリーリーク
• リソースの競合
• 外部システムの相互作用
• ビジネス失敗時の再試行が頻繁に発生し、終了ステータスが発生しない
• ミドルウェア構成が無理がある
• データベースリンクの設定が適切ではありません（接続数またはキャッシュ）
• プロセス/スレッド設計エラー

最後に:以下の完全なソフトウェア テスト ビデオ チュートリアルが整理されてアップロードされており、必要な友人は自分で入手できます[100% 無料を保証]

ソフトウェアテストの面接ドキュメント

私たちは高給の仕事を見つけるために勉強しなければなりません。次の面接の質問は、アリ、テンセント、バイトなどの一流インターネット企業からの最新の面接資料であり、一部のバイトの上司が権威ある回答をしています。このセットを完了してください。面接資料は次のとおりです。誰もが満足のいく仕事を見つけることができると信じています。