APIのスタブ化とJmeter
『負荷試験の準備よろしく』
とだけ言われて、知らんシステムの負荷試験やれって急に言われた。
（よく知らんシステムの本番障害の巻き込み事故、さいあくじゃん。。）
1年半前の記憶を掘り起こして、
ひとまずローカルでの動作確認まで完了したから忘れないうちにやったこと書く。
インターフェース仕様書の作成 -UI
製造 -PGPT
負荷試験 -性能テスト
1.と2.は他の人がやってて、私は3.負荷試験の準備を並行して進める感じ。
Jmeterとは
指定したURLに任意のリクエストを大量に投げられる、ツール。
イメージ的には、ドッジボールで1人だけに大量のボールを投げつける的な。
実装の流れ
※今回のテスト対象は、新規API1本
①テスト計画に対して1スレッドグループ、
1スレッドグループに対して1リクエスト、
1リクエストに対して1リクエストヘッダー。
をまずぶら下げる。
②適宜リスナー（統計レポート、結果ツリーetc）をぶら下げる。
③ユーザ定義変数でIPアドレスやポート番号、リクエストパスを持つ。（汎用性がある）
④リクエストの中身をIF仕様書に従って作成する。
動作確認
まだ製造終わってないのに動作確認してって言われて、できなくない？？？？って思ったけど、
できるらしい。。
①ローカル環境構築
手順書なくて困ったけど、TomcatサーバーとJava(JRE)のバージョンが合ってれば、適当でも大丈夫らしい。
②疎通確認
既存のAPIをJmeterでも何でもいいから叩いて、リクエストが届いていることを確認。
http://localhost/xxxxxx/yyyyyy
xxxxx:APIのプロジェクト名
yyyyy:struts-xxxxxAction.xmlに記載あり
③スタブ作成
ここが今回の鬼門。
APIのスタブを作成して、呼び出されたらただ結果を返す箱を作ってあげる。
やることは、
・actionクラスの実装
→return "200” のように、何かしらは返す(nullだとだめ）
・struts-xxxxxxAction.xmlの実装
→URLが叩かれた時に呼び出すactionクラスをマッピングするための、XMLファイル
・struts.xmlの修正
→インクルード定義に、新規作成したstruts-xxxxxAction.xmlを定義
④疎通確認
Jmeterを実行して、結果ツリーを見ながらリクエストを修正。
200が返って来ればひとまずOK。
製造後
APIのPGPTが終わったら、トランザクション数の調整をする。
定数スループットタイマー(TPM)で、調整できる。TPSじゃないのでそこは注意。
※TransactionPerMinutes。1分あたりのトランザクション数
※TransactionPerSecond。1秒あたりのトランザクション数。
TPSがわかったら、60かけた値を定数スループットタイマーに設定すればいい（と思ってる）
あとは、サーバーの台数とかスレッド数を調整すればいい（と思ってる）
おまけ
今回は下記の機能も使ったよ。
・CsvDataSetConfig
→csvファイルからデータを読み込んで、任意の変数にセットする。
・BeanShellPreProsessor
→前処理でJavaみたいにコードを書ける。csvから受け取った値を変数に設定して、その値を使ってif文で分岐させて別の変数定義したりできる。
vars.get()
vars.put()
こんな感じのメソッド。
csvファイルは、データ作成ツールをJavaアプリケーションで実行してデータパターンの割合も考慮して作成した。
まとめ
負荷試験計画書を作ろうね。