E2Eテスト自動化フレームワークを作成した話

エイジ＠

バックエンドエンジニアをしているエイジです。
早速ですが、業務でバックエンド間を一気通貫したテストをするためのAPIのE2E自動化テストフレームワークを作成した話をしたいと思います。


E2Eテストとは

E2Eテストとは一般的にはモバイルアプリ等からユーザが実際に操作して品質が担保されているか確認する。という定義がされていことが多いですが明確な定義はされていません。そのため、今回作成したフレームワークをE2Eテスト自動化フレームワークと呼んでいます。

きっかけ

私が携わるプロジェクトではバックエンドは以下のような前提がありました。そのためバックエンドのITaにおいては自マイクロサービス(以下MSと略)に観点を置いて実施しておりました。

前提

  • バックエンドのAPIはJSON形式でのやり取り

  • バックエンドは複数のMSによって構成されている

  • すべてのサーバGCP上にデプロイされている

モチベ＆目的

今回自動化テストのフレームワークをするにあたり以下のような目的を達成することを目指しました。

  • テスト工程の品質アップ

  • ITaテスト実施の高速化

  • リグレッションテストとして使用(リリースに向けたスピードアップ)

テスト工程の品質アップ

品質アップについてはDBのレコード確認や、APIのステータス、レスポンス確認等の確認は自動でシステム的に確認するようにしたいという思いがありました。今まではPostman等やIntellijのhttp clientを使用しテストを実施していました。テスト実施後はテスト実施者による確認 -> 開発チームのリードによるレビュー -> PM等によるテストレビューのようなフローでテスト後の確認作業を実施しておりました。複数人においてチェックを実施していてもやはり人間なので見逃し等はありました。

ITaテスト実施の高速化

テストケース作成、テストデータ作成実施後、すぐにテスト実施、バグがあればバグのfix等を高速にできるようにしたいという思いがありました。
テストケースとテストデータはエクセルに作成していました。観点等を網羅的に抑えているかということを確認するためにはエクセルを使用するのが一番わかりやすく品質が上がるためです。今回は作成したテストケースとテストデータから自動で自動化テスト用のテストケース、テストデータを生成するツールも作成しました。

リグレッションテストとして使用(リリースのスピードアップ)

新規開発を終えた後のリリースにて機能修正した後に他の機能に影響していないかということを確認する必要があります。そのため、開発環境に修正した資産をデプロイした際に自MSのAPIすべてが問題なく動作してテストがパスするか確認するためにも使用できるということもできると思いフレームワーク作成を実施しました。

作成したE2E自動化フレームワークについて

自動化テストフレームワークについては一部詳細を割愛をしている箇所がありますが以下のような処理を実装しました。

  1. テストデータの削除＆挿入

    1. テストは複数の案件で使用している開発環境のDBを用いていました。そのため、最初に不要なデータを削除し、テストに必要なレコードの挿入等を実施しています。(レコードの削除は別案件のレコードを削除しないようにしていました。)

  2. APIの実行

    1. APIの実行は実行するテストケースに記載されているヘダー情報、ボディ情報を読み取り、開発環境のサーバに向かってAPIのリクエストを実施します。(APIの実行時にUUIDを生成したいという要望もあり、柔軟なリクエストを作成できるようになりました。)

  3. APIのレスポンスステータスコードの比較

    1. 実行したAPIのレスポンスに対して、期待したステータスコードが返却されるかを確認しています。

  4. APIのレスポンスボディの比較

    1. APIのレスポンスの比較については以下の流れで実施しています。また、レスポンスの比較にはAPI内で採番された36桁のUUID等が返却されることがあったため、テストケース内に記載するレスポンスの期待値には「$UUID」等の予約語の記載を可能としています。

      1. 期待値と実際値のレスポンスを絶対一致で比較

      2. jsonレスポンス項目のレングスを比較

      3. レングスが同じ場合は予約語が定められている可能性があるので項目ごとに比較していく。

        1. 項目内に更にjson項目やlist項目がある可能性があるため、再帰的に比較を実施するようにしています。

  5. DBの値比較

    1. dbの値比較はテスト内に期待するレコードとレコードを取得する条件を記載しています。記載された条件をもとにレコードを取得し、期待値と実際値に相違がないか比較します。(DBの期待値にも予約語を使用できるようにしています。)

  6. ログの取得/比較

    1. ログもGCPのCloud Logging上にて参照可能であったためGCPが提供するAPIを使用して実行したAPIのログを取得しています。

    2. 取得したログからエラー情報がでていないか、また適切なエラー情報が出ていないか等の比較処理も実装しています。

  7. 結果のHTML生成

    1. すべてのテストの実行後に結果サマリをHTMLにて生成するようにしています。視覚的に失敗しているテストがすぐに分かるためHTMLに出力するようにしました。

実際に使用して思ったこと

良かったこと

  • 開発中に機能追加等があっても自動でテストを流してくれるのでテストを実施する負荷が下がった

  • テスト結果を機械的に見るので品質が上がりテストの速度も上がった

悪かったこと

  • 機械的見ているためテスト実施者が結果を隅々まで見なくても大丈夫だろうという意識になってしまった(気がする)

  • テスト実施者はwindowsやmacを使用しており、そのためdocker上からテストを実行するようにしていたが、環境差異でうまくテストが実施できない等があった

最後に

  • やはり、自動化は正義。

  • 自分でテストするなら楽にできる越したことはない。

この記事が気に入ったらサポートをしてみませんか？