負荷テストプロジェクトの1つで、この質問に対する答えを見つける必要がありました。
当時、2つのソリューションがありました。
- テストに必要な単純なロジックを実装する独自のJMSアプリケーションを作成します。
- JMeterを使用します。
最初のパスは、JMSアプリケーション（単純なアプリケーションも）を作成した経験がなかったため、不確実な人件費（比較的小さいとはいえ）を約束しました。
JMeterでのある程度の経験が、集計レポートなどの要素のおかげで、将来のスタブの作業をリアルタイムで監視できることを考えると、2番目のオプションで停止することになりました。
まず、スタブの要件が策定されました。
- キューからメッセージを読み取ります。
- CorrelationIdおよびビジネスデータを抽出して、適切な応答を選択して送信します。
- 一定時間待機します（外部システムからの遅延応答をエミュレートするため）。
- いくつかの動的データとともに適切な応答を送信します。
JMeterの初期設定は、出版物「JMeterを使用したMQプロトコルを使用したサービスの自動テスト」で説明されているものと同じですが、 JMeterプラグイン （特にデバッグ用のDummy Sampler）も使用されました。
スレッドグループとして、テスト計画はかなり標準的でした（スタブの動作中にスレッド数の特別な規制はありませんでした）。
次に、JMSサブスクライバーを追加します。これは、キューからメッセージを読み取る役割を果たします。 次の図は、サブスクライバの設定を示しています。
結果ツリーの表示を使用してキューからメッセージを読み取った後、そのプロパティを確認できます。 メッセージキューから読み取られたメッセージのプロパティの例を以下に示します。
JMSCorrelationID（テスト対象のキューマネージャーとアプリケーションがスタブによって送信されたメッセージが応答である要求を理解できるようにするメッセージプロパティの1つ）とビジネス日付（この場合、適切な応答を選択できるXML要求のフィールドの1つの値）を取得するために使用します正規表現エクストラクター（下図の使用例）：
NT方式では、外部システムからの応答遅延が修正されたため、Constant Timerを使用してそれをエミュレートし（以下を参照）、連続したリクエスト間の固定遅延を作成します。 テスト中にさまざまな遅延が必要な場合は、ランダムタイマーを詳しく調べることをお勧めします。
これで、読み取ったメッセージに基づいて、適切な回答を選択できます。 これを行うには、スイッチコントローラーを使用します。
Switchコントローラー内の要求に応答を送信するには、p_destination変数（Subscriberからの正規表現によって抽出された）の可能な値に対応する名前でJMS Publisherサンプラーをアタッチします。
JMS Publisherサンプラーの本文（テキストメッセージエリア）内に、JMeter変数（タイムスタンプなど）を使用して動的データを追加します。
JMS Publisherサンプラーの[JMSプロパティ]領域で、ID値$ {corrId}のJMSCorrelationIdを追加します。
作業の統計を分析するために、集計レポートを追加できます。これにより、受信および送信されたメッセージの数に関してスタブの動作の統計を分析できます。
まとめると、自己開発と比較してJMeterを使用してJMSスタブを作成する利点についてもう一度説明します。
- 足を踏み入れる機会が少なくなります（記述する必要のあるコードの量は最小限に抑えられ、ロジックのほとんどはJMeter要素を使用して実装できます）。
- スタブの操作に関する統計を収集するためのグラフィカルインターフェイスとリスナーがありますが、自分でスタブをねじ込む必要はありません。
- スタブ（TomcatまたはGlassfish）をデプロイするために追加のソフトウェアをインストールする必要はありません。
- 簡単な起動（通常のJMeterテストとして実行）。