Nirvana へのインタビュー: Jmeter パフォーマンス テスト ガイド (パート 1)

序文

パフォーマンス テストは、フルスタック エンジニア/アーキテクトが知っておくべきスキルの 1 つであり、パフォーマンス テストを学習することによってのみ、取得されたテスト レポートを分析し、システム パフォーマンスのボトルネックを見つけることができ、アーキテクチャ設計を最適化するための重要な基礎でもあります。

第 1 章 テストプロセス:

要件分析→環境設定→テスト計画→スクリプト開発→実行と監視→欠陥管理→結果とレポート

圧力試験

1. スレッド グループの設定 ここでのスレッドの数は、タイマーを同期しているユーザーの数と同じです。

2. HTTP Cookie マネージャーを追加する

3. デフォルトのリクエスト値

4. ビジネスとして使用できるトランザクション コントローラーを追加します。

5. トランザクション コントローラーの下に同期タイマーを追加します。

スレッドグループ内のスレッド数と同じユーザー数を設定し、タイムアウトを設定できます。

6. スクリプトの追加 (http リクエスト)

7. ビュー結果ツリーの追加

8.「追加」->「リスナー」

9. 最後に集計レポートを追加します: [追加]->[リスナー]

第 2 章 負荷テストの実践

1. 50 ユーザーのスレッド グループ設定 (期間: 秒単位で計算、ここでは 300=60*5、つまり実行時間が 5 分であることを意味します)

2. HTTP Cookie マネージャーを追加する

3. デフォルトのリクエスト値

4. ビジネスとして使用できるトランザクション コントローラーを追加します。

5. トランザクション コントローラーの下にガウス ランダム タイマーを追加します。

総遅延 = 固定遅延時間 + ランダムに生成されたガウス偏差値 (注: 単位はミリ秒、固定遅延は 300ms、偏差は 100ms、つまり時間遅延は 300 ~ 400ms の間であることを意味します)

6. スクリプトの追加 (http リクエスト)

7.「追加」->「リスナー」

8. 最後に集計レポートを追加します: [追加]->[リスナー]

第 3 章 パフォーマンステストとは何ですか?

  • パフォーマンスは、機能に加えて製品の速度、効率、機能を記述するために使用される総合的な能力評価です。
  • 製品またはアイテムの性能を定性的または定量的に測定するプロセス
  • このプロセスでは、いくつかのツールを使用してシナリオをシミュレートし、パフォーマンス テストを実施します。

第 4 章 パフォーマンス テスト ケース

テスト要件: 負荷が 30QPS に達したときの、Web サイトにアクセスする 20 人のユーザーの平均応答時間をテストします。

QPS: Query Per Second 1 秒あたりのクエリ速度。(クエリ サーバーが 1 秒あたりに処理できるクエリの数。ドメイン ネーム サーバーのパフォーマンスは、多くの場合、1 秒あたりのクエリ レートによって測定されます。)

テスト手順

1. スレッドグループを追加します (スレッド数 + 準備時間 + サイクル数)

1.1. スレッド数: 仮想ユーザーの数 1 つの仮想ユーザーが 1 つのプロセスまたはスレッドを占有します (設定されている仮想ユーザーの数 = 設定されているスレッドの数)

1.2. 準備時間 (秒): 設定された数の仮想ユーザーがすべてアクティブ化されるまでにかかる時間。例: スレッド数は 20、準備時間は 10 です。これは、20 個のプロセスを開始するのに 10 秒かかることを意味します。

1.3. サイクル数: 各スレッドがリクエストを送信する回数。例: スレッド数が 20、ループ数が 5 の場合、各スレッドは 5 つのリクエストを送信し、リクエストの総数は 20*5=100 となります。

2.HTTPリクエストを追加する

3. QPS 制限の設定: 特定のサンプラーによって送信されるリクエストのスループットを制御します。

4. 監視集計レポートの追加、結果ツリーの表示

5. スクリプトを実行します

6. 集計レポート分析(応答時間単位:ミリ秒)

1) ラベル: 各 Jmeter 要素には Name 属性があり、ここに表示されるのは Name 属性の値です。

2) #Sample: このテスト中に合計で発行したリクエストの数を示します。10 人のユーザーをシミュレートし、各ユーザーが 10 回反復すると、ここには 100 が表示されます。

3) Average: 平均応答時間 - デフォルトでは、単一のリクエストの平均応答時間です。トランザクション コントローラーを使用すると、平均応答時間をトランザクション単位で表示することもできます。

4) 中央値: 中央値、ユーザーの 50% の応答時間

5) 90%Line: 90% ユーザー応答時間

6) Min: 最小応答時間

7) 最大: 最大応答時間

8) Error%: このテストでエラーが発生したリクエストの数/リクエストの総数

9) スループット: スループット - デフォルトでは 1 秒あたりのホワイトストーン リクエスト

10) KB/秒: 1 秒あたりにサーバーから受信したデータの量

第5章 性能試験の分類

性能試験の分類

ストレステスト、負荷テスト、同時実行テスト、安定性テスト

ストレステストとは何ですか?

ストレス テストは、強度テストとも呼ばれます。システムに徐々に圧力を加え、システムのパフォーマンスの変化をテストし、一部のシステム リソースを飽和またはシステム崩壊の端に達させ、それによってシステムが耐えられる最大圧力を決定することを指します。 。

たとえば、100 メートルのレースでは、100 メートルを完走できなくなるまで徐々に負荷を増やしていきます。これは、倒れる寸前で耐えられる最大負荷です。

負荷テストとは何ですか?

テスト対象のシステムが通常のサービスにあるという前提の下で、システムが耐えることができる最大サービス負荷 (つまり、同時実行の最大数) が最終的にシステム パフォーマンスのボトルネックを分析します。

例: 100 メートルのレースでは、負荷をかけて走って (負荷を継続的に増加させながら) 15 秒で設定を完了する必要があります。

ストレステストと負荷テストの違い

ストレス テストでは、システムが崩壊しそうになったときに耐えられる同時実行の最大数をテストします。

負荷テストは、システム インデックス要件が満たされている場合に許容できる同時実行の最大数です。

同時実行テストとは何ですか

例: ショッピング モールで商品を販売する場合、アフターセールス スタッフは在庫フォームの記録に従って商品を販売します。

倉庫管理者は出荷と同時に在庫フォームレコードテーブルを更新する必要がありますが、ユーザーが多すぎるため、フォームレコードの更新がタイムリーではありません。

その結果、倉庫には商品がありませんが、営業担当者は、在庫フォーム記録テーブルにはまだ在庫があることが示されており、商品は販売されていますが、出荷できなくなっていることに気付きます。

第 6 章 性能テストのプロセス

1. パフォーマンス要件を分析します。ログイン、検索、注文など、テストに最も頻繁に使用されるシナリオを選択します。トランザクション通過率が 100%、TOP99% が 5 秒、最大同時ユーザー数が 1,000、CPU とメモリの使用率が 70% 未満などのパフォーマンス指標を決定します。

2. パフォーマンス テスト計画を作成し、テスト時間 (通常、最初のテスト ラウンドなど、機能が安定した後) とテスト環境およびテスト ツールを明確にします。

3. テストケースを書く

4. テスト環境の構築とテストデータの準備

5. パフォーマンス テスト スクリプトを作成する

6. パフォーマンス テスト スクリプトの調整。チェックポイント、パラメータ化、関連付け、ランデブー ポイント、トランザクションの設定、思考時間の調整、冗長スクリプトの削除

7. テストシナリオを設計し、テストスクリプトを実行し、サーバーを監視し、

8. テスト結果を分析し、開発のために関連するログシートを収集します。

9. 回帰パフォーマンステスト

10.テストレポートを書く

これからも皆様の「いいね!」が更新の一番の励みになります!

おすすめ

転載: blog.csdn.net/a448335587/article/details/133208565