初めまして！TeamSprit EXのQAエンジニアの河西です。
昨年9月に入社し、APIテストの実装や、負荷テストの実施に取り組んでいます。
その中で多くの試行錯誤があったため、そのことについて全3本の記事でご紹介したいと思います。
- JMeterによるAPIテストの実装について ◀︎ 今回はこちら
- JenkinsによるAPIテストの定期実行について
- JMeterを使ったSalesforceアプリへの負荷テストの実施について
既にAPIテストは少し作られていましたが運用されていなかったため、既存のAPIテストを参考にし、運用できるAPIテストの実装を始めました。
その取り組みの中で、自動テスト実装初心者の私が学んだことや工夫したことについて、今回は書いていきます。
なぜAPIテストを実施するのか？
APIはUIと比較して作りが単純であるため、テスト資産のメンテナンスの容易さも含め、自動化に向いています。
UIテストよりも変更が生じにくく一貫性があるため、既に作成したテスト資産を長期間にわたって利用（運用）しやすいという利点があります。
さらに、性能テストなどと組み合わせることで、製品の性能におけるボトルネックを発見しやすいという利点もあります。
どうやって実装するのか？
ツールは、 JMeter を採用しました。
JMeterは、Javaアプリケーションのオープンソースの負荷検証ツールで、ブラウザではなくプロトコルレベルで動作します。
サーバに対して指定した量のリクエストを送り、そのレスポンスを受けることで、パフォーマンス計測することができます。
今回は、リクエスト量を最小にすることでAPIテストとして利用します。
JMeterで作成したAPIテストは、リクエスト量を調整することで負荷テストに応用することができます。
JMeterの実装は、このようなJMXファイルを作成します。
こちらは手動でコーディングもできますが、JMeterではGUIが用意されているため、基本的にはGUIで実装することをオススメします。
GUIはわかりやすく、作成しやすいと感じました。一部コーディングが必要ですが、GUIで作成できるのはテスト自動化のハードルを下げられます。
GUIで実装したものが、JMXファイルに書き出されます。そのため、Gitによるコード管理も可能です。ちなみに、コピペや文字列置換などはコードを直接編集した方が早いです。
APIテスト実装における課題
私は、APIテストを実装するのも、JMeterを使うのも初めてでした。
最初は苦戦しましたが、既存のAPIテストとAPI仕様書を見ながら、実装して実行して、とやっている内に理解できました。
API仕様書がしっかりと書かれていたことと、APIが複雑な作りではないことが、とても助けになりました。
（開発の皆様、いつもありがとうございます！）
どうやって実装すればいいかがわかるようになった次は、本格的にテスト計画を考え始めました。
冒頭にも書きましたが、今回実装するのは「運用できるAPIテスト」です。
既存のAPIテストが運用できなかった課題を洗い出し、3つの改善に気付きました。
- 「テスト実装しづらいAPI」が無い状態にする
- 定期実行できるものにする
- テスト環境に依存しないものにする
- ログインに使うテストデータの部分だけを書き換えれば、どの環境でもテスト実行できるものが理想
これらの課題を解決するために、APIテストをシナリオテストの形で実装することにしました。
（既存のAPIテストは、コンポーネントテストの形でした。）
APIを理解して、まとめられるものはシナリオテストで実装することで、カバレッジの管理もしやすくなります。
また、データを作成して削除する、という流れにしてAPIテストの実行終了時にデータが無い状態にすることで、定期実行の自動化も容易になります。
APIには、リクエストにパラメータが必要なものがあります。
例えば、データを削除するAPIには、「何を削除するか」というデータを指定するパラメータが必要な場合があります。
その際に必要なパラメータを固定値にしてしまうと、繰り返し実行できない・他の環境で実行できない、APIテストになる可能性があります。
この場合においても、シナリオテストにすることで解決できます。
- データ作成
- データ参照・取得
- PostProcessorで「今登録したデータ」を取り出して、次のリクエストのパラメータで使えるようにする
- データ削除（対象を指定する）
この流れで実装することで、テスト実行ごとに削除したいデータを決めることができます。
これはAPIがどのような作りになっているかにもよりますが、私たちの場合はこの流れでテスト実装するのが一番スマートでした。
（こういったシナリオを考える上でも、API仕様書は重要です。開発の皆様、いつもありがとうございます！）
属人化問題と向き合う
シナリオテストを設計することで、あとは設計通りに実装すればカバレッジが上がっていく、という状態になります。
既存のAPIテストは、1人の方が実装されてそこからアップデートされていませんでした。
テスト自動化は属人化しがち、という話もよく聞くため、今回は早い段階から実装を分担することにしました。
（こういった分担をするためにも、Gitで管理ができるのは有難いです。）
属人化しないために行ったことは、下記の3点です。
- 共有資料を作成する
- APIテストやJMeterについてまとめた資料
- 実装方法についてまとめた資料（動画も入れました）
- 資料を基に、ナレッジ共有会を行う
- 日本のQAチームだけでなく、シンガポールのチームにも共有
- 受けた質問を基に、資料をアップデート
- 実装を分担して行う
- モブプロやPRレビューなどをやってみる
Gitの操作に慣れていない方も居たため、そこもサポートしました。
最初はモブプロが必要でしたが、今はサポート無しで、PRを出してもらえる状態になりました。
結果として、現在は私以外に3名程がAPIテストを実装できます。
大変ではありますが、テスト自動化をする時は早い段階で属人化を解消しておくことで、テストの拡充がスピーディに行えると感じました。
各スクラムチームに属しているQAメンバーもAPIテストを実装できるため、まだ実現できてはいませんが、開発のスピードに合わせてAPIテストを拡充していくことも可能な体制になりました。
次の課題は、命名規則やコメントの付け方などのコーディング規約だと思っています。 このあたりはまだルール化はしていませんが、「誰でもメンテナンスできるように」という方針でPRレビューを行なっています。
最後に
APIテストができると、テストデータを作る際にも役立ちます。新しいものを導入することは大変ですが、得られるものはとても多いと感じました。
私はQA歴も浅く、APIテストの実装も初めてでしたが、任せていただけたことでとてもスキルアップできたと感じています。
次回は、JenkinsでAPIテストの定期実行を始めたことについてご紹介します！
