1. パフォーマンステストの基礎
テストスクリプトの作成：パフォーマンステストは一般的に録画方式とスクリプト作成方式の2種類があります。録画方式はシンプルなページには適していますが、複雑なロジックを持つアプリケーションでは録画結果が煩雑になる傾向があるため、スクリプトを使用したテストが推奨されます。JMeterテストでは、各URLはAPIエンドポイントとして扱われます。
ユーザー同時実行とデータ伝達：認証トークンなしのテストは無効な負荷テストとなるため、データ伝達の仕組みは非常に重要です。
テスト結果分析とパフォーマンス監視：結果の分析方法、監視システムの構築、メトリクス収集については別の記事で詳述します。
分散テストとJMeterのサイレント実行：単一のテスト実行マシンの性能が不足する場合、システムのボトルネックを特定するために分散テスト環境の構築が必要となることがあります。
2. 実践的なパフォーマンステスト
まず、GitHubからサンプルアプリケーションのコードをダウンロードして起動します。このアプリケーションは、ログイン、メニュー照会、注文作成、ログアウトの4つのエンドポイントを持つデモアプリケーションです。
アプリケーション起動後、Postmanを使用して各エンドポイントにリクエストを送信し、正常に応答があることを確認します。これにより、アプリケーションが正しく起動していることを検証できます。
3. テストスクリプトの作成
HTTPリクエストの設定（POST、GET、DELETE）
1） ユーザーログインエンドポイント
2） ログインエンドポイントにJSON抽出器を追加
主な目的はアクセストークンを解析することです。ログインレスポンスからトークンを抽出し、後続のリクエストで使用します。トークンはリクエストヘッダーを通じて参照されます。
変数名：auth_token、JSON Path式を使用してトークンを解析します。構文に注意してください。
$.authentication_token
3） HTTPヘッダーマネージャーの追加
リクエストヘッダーを通じてauth_tokenを参照します。トークンテンプレートを追加します。
${auth_token}
4） JSONアサーションによるログイン成功の検証
パフォーマンステストはAPIの正確性を前提として行う必要があるため、各エンドポイントの応答を検証することが重要です。
検証対象のレスポンスフィールド：
{
"authentication_token": "5c7865g11cc1174082d6c82df3c67c5fe167b74504f896cfb96c85d52df301",
"status": "200",
"response": "authentication successful"
}
5） ユーザー定義変数の追加
メニュー照会エンドポイントは、変数を参照する形式で記述できます。これにより、ドメイン名やポート番号が変更された場合でも、ユーザー定義変数の一箇所の修正で対応できます。
6） 待機時間の設定
前項で定義したdelayはユーザー定義変数で、ミリ秒単位の待機時間を表します。これによりユーザーの操作間隔をシミュレートできるため、各エンドポイントに定数タイマーを追加します。
7） 注文確認エンドポイント
8） 重要なエンドポイントの応答検証
パフォーマンステストはAPIの正確性を前提としているため、重要なエンドポイントには応答検証を追加します。エンドポイントの応答例：
{
"status": "200",
"response": "Order processed successfully.",
"amount": 1250
}
9） ログアウトエンドポイント
10） CSVデータセット設定の追加
テストデータのインポートには、相対パスまたは絶対パスを指定できます。
11） リスナーの追加
これにより、テスト結果をInfluxDBデータベースに書き込み、Grafanaでグラフィカルに表示できます。