こんにちは。TeamSprit EXのQAエンジニアの河西です。
この記事は、APIテストの取り組みに関する記事の2本目です（全3本）。
- JMeterによるAPIテストの実装について
- JenkinsによるAPIテストの定期実行について ◀︎ 今回はこちら
- JMeterを使ったSalesforceアプリへの負荷テストの実施について
前回は、運用できるAPIテストの実装の取り組みについてご紹介しました。
自動テストを運用するということは、定期的に実行して結果をウォッチし、開発にフィードバックできる状態にする必要があります。
その取り組みの中で、CIサーバ初心者の私が学んだことや工夫したことについて、今回は書いていきます。
なぜAPIテストを定期実行するのか？
TeamSprit EX は、複数のスクラムチームによって継続的に開発が行われています。
開発が進み、その複雑さが増してくると、改修した部分が影響して不具合が発生するリスクが高くなります。
それを早期に検知するためには、定期的なリグレッションテストの実施が重要になります。
リグレッションテストは、同じテストの実施を何度も行うため、手動テストよりも自動テストの方が向いています。
今回追加したAPIテスト以外にも、下記3点のテストを自動で定期実行しています。
- Unitテスト
- E2Eテスト（Autifyなど）
- 性能テスト（Webpagetest）
このように様々なアプローチのテストを定期実行することで、リグレッションテストの範囲を広げることができ、手動テストの負荷を軽減させることができます。
どうやって定期実行するのか？
前回ご紹介した通り、APIテストはJMeterで実装しています。
JMeterを定期実行するために、CIツールを利用することにしました。ツールは、チームで使っていることもあって、 Jenkins を採用しました。
Jenkinsとは、継続的インテグレーション(CI)や継続的デリバリー(CD)、継続的デプロイメントを実現するツールです。 下記の4点の特徴があります。
- 汎用性が高いことから大きな支持を得ている
- 世界中のソフトウェアエンジニアによって開発された 1,800以上ものプラグインが利用可能
- Javaが動く環境であればLinuxでもWindowsでも動作させることができる
- プラグインが提供する機能だけでなく、スクリプトを記述することで、より柔軟に自動化を行うことができる
JenkinsでJMeterを実行するためには、下記の作業が必要です。
- Jenkinsが動作しているサーバーに、JMeterをインストールする
- サーバーで、JMeterを実行できることを確認する
- Jenkinsに Performanceプラグイン をインストールする
- Jenkinsのジョブを作成する
詳細については こちら を参考に、作業を行いました。
Jenkinsのジョブを作成したら、それを定期実行するように設定すれば、APIテストの定期実行ができるようになります。
（私たちの場合は、テスト環境へのデプロイなどと組み合わせたパイプラインを作成し、それを毎朝実行するようにしています。）
JMeter, Jenkins, Performanceプラグイン を利用することで、 実行も集計も自動化することができます。
Performanceプラグインによって、このように結果をGUIで確認することもできます。
（これはサマリーですが、サンプラーごとの集計結果も確認できます。 ）
JenkinsでJMeterを実行する際の課題
定期実行はできるようになりましたが、私たちがAPIテストを運用する上で、新たに2つの課題が生まれました。
- 1件のエラーも逃さない仕組み
- エラーが発生したら、Jenkinsジョブのビルドが失敗する （Slack通知は設定済み）
- エラー時に誰でも問題を確認できる
- ログに、エラー箇所と原因が特定できる情報を追加する
エラーをどの程度許容するかは、定期実行を検討する上で重要な指標です。私たちは今回実装したAPIテストの特性から「1件のエラーも無視できない」と定めました。
（Performanceプラグインの一般的な設定は こちら のようです。）
上記2つの課題を解決する方法は複数あると思いますが、今回は下記の改善を行いました。
① jmeter.log にエラー箇所と原因が特定できる情報を追加する
これを各サンプラーに追加しました。
② Jenkinsジョブで、APIテスト実施後に jmeter.log の内容を確認し、エラーが見つかればビルド失敗とする
※ result.jtl などのテスト結果を格納しているファイルは、Performanceプラグインを使用している場合は履歴を蓄積している必要があるため、実行毎のNGを判断するのには不向き、と判断したため jmeter.log を活用しました。
この改善により、定期実行のエラーにすぐに気付くことができ、エラー原因の特定もスムーズになりました。
定期実行の結果をウォッチして、運用する
サンプラーごとの結果は、Jenkinsの「Performance Report」から、このように確認することができます。
ざっくりと結果を見る分にはこれで十分ですが、結果を分析したりするには、前回実行時との差分などの情報が含まれているため、少し不便です。
そのため私たちは、Jenkins上のレポートとは別に、定期的にレポートを作成してチームに共有しています。
その方法は、下記の通りです。
- 定期実行の結果が出力されているファイル（result.jtlなど）をダウンロードする
- ダウンロードしたファイルを、JMeterの「統計レポート」というリスナーで参照する
- 出力された結果をコピーし、Excelファイルに貼り付ける
少し手間ですが、こうしてExcelファイルにすることで、ソートやマークアップがしやすくなります。
チームにはこのレポートと、レポートの見方を共有しています。必要に応じて、各自が使いやすいように加工して利用してもらっています。
ここまで大変なことも多くありましたが、こうしてAPIテストの運用を確立できました。
最後に
今まであまり考えていなかった「テストを運用する」ということを、深く考える機会となりました。
何の為にどのように運用するかによって、実装や設定は異なります。
そのため、インターネット上の知見だけでは解決しないこともあり、試行錯誤しました。
現在、運用しているAPIテストからバグは検出されていません。
だからといって無意味ではなく、「不具合が発生していない」という結果を上げられていると思っています。
また、副産物として「APIレスポンスタイムの調査」などに使っていただくこともあるため、お役には立てているのかな、と感じています。
次回は、JMeterでSalesforceアプリへの負荷テストを実施したことについてご紹介します！
