ソフトウェア テスターは、アプリケーションの品質をチェックするためにいくつかのテクニックを実践します。パフォーマンス テストは、チームがソフトウェアの速度、応答時間、拡張性、信頼性をテストする決定的な手段の 1 つです。 この記事では、パフォーマンス テストにおけるスループットに関する核心事項について説明します。 パフォーマンステストにおけるスループットの基礎 詳細を始める前に、パフォーマンス テストの重要事項をいくつか見てみましょう。 なぜパフォーマンステストを行うのか? パフォーマンス テストは次の理由から重要です。 一般に報告される論理的または機能的な問題以外に、アプリケーションは信頼性を決定する にも悩まされます。 ネットワークの問題 アプリケーションのアクセシビリティ エクスペリエンスが良くないと、 。 顧客は簡単に してしまいます イライラ 使用されている に応じて変化します。したがって、さまざまな速度やネットワークでのアプリケーションのパフォーマンスを判断することが重要です。 アプリケーションの速度とパフォーマンスは、 地域 システムは特定のユーザー数であれば完全に動作しますが、 。したがって、特定の条件下でのパフォーマンス テストの基本を確認することが必要です。 その制限を超えて増加すると、動作が異なる可能性があります ユーザー数が パフォーマンス テストはいつ開始する必要がありますか? ソフトウェア アプリケーションの開発段階の 。このようにして、Web サーバーを最適化し、後の段階でのビジネスコストを防ぐことができます。 パフォーマンス テストを開始できます できるだけ早い段階で アプリケーションのデプロイメント後にパフォーマンスの問題を発見すると、問題を修正するために多くの作業時間がかかります。したがって、非常に高価になる可能性があります。 アプリケーションの基本的な Web ページが動作するとすぐに、品質保証チームは初期負荷テストを実施する必要があります。その時点から、ビルドごとに定期的にパフォーマンス テストを実行する必要があります。 アプリケーションのパフォーマンス テストにはさまざまなツールと基準があります。ここで重要な尺度であるスループットについて説明します。 パフォーマンステストにおけるスループットとは何ですか? すべてのソフトウェア アプリケーションや Web サイトには、さまざまなリクエストを実行する多数のユーザーがいます。テスターは、アプリケーションが稼働する前に、必要なリクエストの容量を満たしていることを確認する必要があります。 パフォーマンス テストのスループットを調べてみましょう。 プロセス中に測定する必要があるパフォーマンス テストの基本がいくつかあります。 。 スループットもその 1 つです スループットは、ソフトウェア アプリケーションが特定の時間 (秒、分、または時間) 内に処理できるリクエストの数を示す重要な指標です。 テストを開始する前に、より正確で信頼性の高い結果を得ることができるように、現実的なパフォーマンス スループット目標を設定する必要があります。 現実的なスループットを決定するための重要な要素は次のとおりです。 アプリケーションまたは Web サイトを使用するユーザーの推定数と種類。 ユーザーの行動、つまりアプリケーションを使用してどのようなアクションを実行するか。 接続の種類は、システムの応答に影響を与え、最終的にはユーザー エクスペリエンスにも影響します。 システムに対する一時停止と遅延の影響。 実際のシナリオでのスループット ここでは、実際の を使用してスループットの概念を説明します。 「ヤミー・バーガーズ」という名前のファーストフードの屋台があると想像してください。彼らは顧客にハンバーガーとフライドポテトを提供します。 例 「ヤミー バーガー」の屋台には 3 人の従業員がいて、各従業員が 1 人の顧客に料理を提供するのに常に 5 分かかるとします。 つまり、3 人の従業員がサービスを提供するために 3 人の顧客が並んでいる場合、「Yummy Burgers」は 5 分で 3 人の顧客に料理を提供できることになります。 したがって、「Yummy Burgers」のパフォーマンス レポートを作成する必要がある場合、そのスループットは 5 分あたり 3 人の顧客であることがわかります。 ヤミー・バーガーズのジレンマは、食べ物を待っている客の数に関係なく、特定の時間枠内に処理できる最大数は常に同じ、つまり 3 人であるということです。 。 これが最大スループットです 食べ物を求めて並ぶ客が増えると、順番を待たなければならず、行列ができてしまいます。 同じ概念が Web アプリケーションのテストにも当てはまります。 Web アプリケーションが 1 秒あたり 100 のリクエストを受信しても、1 秒あたり 70 のリクエストしか処理できない場合、残りの 30 のリクエストはキューで待機する必要があります。 。 パフォーマンス テストでは、スループットを として表します 「1 秒あたりのトランザクション数」または TPS パフォーマンス テスト JMeter のスループット: を使用してソフトウェア アプリケーションのパフォーマンスをテストすることは非常に一般的です。 JMeter は、アプリケーションが処理できる同時ユーザーの最大数を決定するのに役立ち、パフォーマンス テスト用のグラフィカル分析も提供します。 Apache JMeter JMeter には、スループットの値を記録するためのさまざまな方法が用意されています。この目的に使用できるいくつかの JMeter リスナーを次に示します。 概略報告 集計レポート 集計グラフ グラフ結果 JMeter は、「 というタイマー コンポーネントも提供します。これを使用して、1 秒あたりのトランザクション数 (TPS) の値を設定し、アプリケーションの負荷をテストできます。 Constant Throughput Timer」 ここで、JMeter を使用したパフォーマンス テストでのスループットの使用状況を示します。100 個の同時スレッドでサンプル テストを実行し、スループットの値を追跡するとします。 システムに JMeter の最新リリースがインストールされており、その他の必要な構成はすべてすでに実行されているとします。次に、テスト計画を作成する必要があります。 1. テストの構成 このテストでは、5 つの ThreadGroup 要素を定義します。これらの各要素には、異なるランプアップ時間 (0、15、25、35、および 45) が設定されます。ランプアップ時間は、すべてのスレッドを開始するまでの時間です。これらの ThreadGroup 要素で 100 人のユーザーを構成します。 より多くのユーザーを構成する場合は、より多くの立ち上げ時間が必要になります。 これらのスレッド グループには、サンプル Web サイト (www.samplesite.com とします) のホームページ上でリクエストを生成する HTTP サンプラーが含まれます。 使用例 1 では、100 個のスレッドで構成された ThreadGroup 要素があり、その立ち上がり時間は 0 です。 「スレッド数」フィールドは 100 に設定されます。これは、100 人のユーザーが一度にリクエストを送信することを意味します。同様に、残りの 4 つのスレッドも構成し、それらの立ち上がり時間を 15、25、35、および 45 に設定できます。また、各スレッド グループのサンプラーに名前を付けます。 前述したように、これらの HTTP サンプラーはサンプル Web サイトのホームページを指します。 これらのスレッド グループを適切な順序で実行する必要があります。このためには、コントロール パネルから [テスト計画] を選択し、[スレッド グループを連続して実行する] フィールドにチェックを入れます。 2. 試験結果の分析 「集計レポート」は、テスト結果を分析および観察するために使用されるリスナーです。このリスナーを使用するには、「テスト計画」を右クリックして次を選択します。 追加 → リスナー → 集計レポート 次に、開始アイコンをクリックしてテストを実行します。 次に、集計レポートからスループットの結果を理解する方法を見てみましょう。 立ち上がり時間が 0 の最初のスレッド グループは、すべてのスレッドが同時に開始することによってサーバーに瞬間的な負荷をかけていることを示しています。このシナリオはスループットがかなり高くなりますが、実用的ではありません。したがって、これは現実的な出力を示しません。 2 番目と 3 番目のスレッド グループの立ち上がり時間は現実的な範囲であるため、適切なパフォーマンス スループットとリクエストの読み込み時間を示す可能性が高くなります。 スレッド グループ 4 と 5 は立ち上がり時間が長いため、スループットが低下します。 したがって、信頼できる出力は、2 番目と 3 番目のスレッド グループの結果から決定できます。 スループットをテストする際に覚えておくべき重要な点: 新しいリリースまたは変更を導入するかどうかは、アプリケーションが特定の TPS を処理できるかどうかに依存します。したがって、パフォーマンス テスト計画には特定のスループット目標があります。ただし、これらの目標が現実的であり、作品の真の特徴を表していることを確認する必要があります。 非現実的な条件で合格してしまったら、試験計画はすべて無駄になってしまいます。たとえば、上で説明したテスト計画では、最初のスレッド グループのスループットの値が高くなりましたが、実際の環境の実際のシナリオを示したものではありませんでした。 したがって、このような方法を使用しても、アプリケーションが実際の負荷を処理するかどうかを適切に把握することはできません。したがって、適切なテストを設定することが重要です。 次に、パフォーマンス スループットをテストするために考慮する必要があるいくつかの重要な点について説明します。 生成されたスループットが現実的かどうかはテスト設計によって決まります。リアルタイムのシナリオでは、各リクエストは異なる可能性があり、必要な結果を得るために複雑なプロセスをトリガーする場合もあります。したがって、予想されるライブ環境に応じてテストを操作する必要があります。 適切なテスト設計: 各アプリケーション ユーザーは、システムのリソースに影響を与えるリクエストを持っている可能性があります。そのため、実際のユーザーがテスト シナリオで表現されていない場合、バックエンドでの不正確なリソース使用量が結果に示される可能性があり、テストでは正しい条件がエミュレートされません。 実際のユーザーの表現: **==一時停止と遅延を考慮する: ==**ライブ環境では、ユーザーは情報を考え、取得して処理し、フィールドに情報を入力するなどの作業を行う必要があります。しかし、サーバーは一時停止中にもリソースを使用します。したがって、これらのユーザーの動作をスクリプトに組み込むようにしてください。 アプリケーションのユーザーは、さまざまなネットワーク速度、地域、またはモバイル ネットワーク経由で接続します。したがって、そのようなユーザー接続を表す帯域幅も選択する必要があります。 接続速度: 結論 一言で言えば、 。ただし、スループット指標だけに依存するだけでは十分ではありません。したがって、 。 スループットは Web アプリケーションの重要なパフォーマンス指標です 遅延と応答時間をチェックする必要があります 設定されたパフォーマンス テストの目標を達成するには、 を作成することも非常に重要です。 現実的なスループット
