はじめに
こんにちは！今回は私達のチームで運用しているE2Eテストについて紹介しようと思います。今回の記事はEXNOAの小山、川田、河本、近藤の提供でお送りします。
以前、こちらの記事で少し触れさせていただいたDatadogを活用し、Synthetics TestのBrowser Testを利用してE2Eテストを回しています。
Datadogによるクラウドネイティブなモニタリングの実践
E2Eテストを導入する前は、例として下記のような問題が発生していました。
- キャンペーン対応のリリースが影響し、ゲーム内でのアイテム課金ができない不具合が発生
→（原因） リリース対象機能ではないため検証が漏れていた
→人的ミス
- ゲームAPIのライブラリ更新の影響で、ゲーム内でのアイテム課金ができない不具合が発生
→（原因）決済機能の検証は行っていたが、ゲーム内でのアイテム課金が検証から漏れていた
→ 人的ミス
これらはアプリケーション内でのエラーのため死活監視では検知できない内容かつ、人的ミスが原因であったこともあり、「自動化で検知力の向上を図ることが効果的だろう」とチームで検討していました。
そこで、上記のDatadogの機能を用いたE2Eテストの運用を開始し、下記のような効果が得られました。
- デプロイ前の検知力向上
- リリース後の問題発生時の検知速度向上
- リリース時の人的検証を削減することによるデリバリー効率の向上
本記事では私達のチームが、具体的にどのようにE2Eテスト環境を構築し、運用しているかを紹介したいと思います。
システム構成
私達のサービスでは、本番・ステージング・開発環境でE2Eテストを実施しています。
本番環境のシステム構成
本番環境はIP制限がなく、インターネットへ公開されているため、Datadogが用意しているManaged LocationからE2Eテストが行えます。
ステージング・開発環境のシステム構成
ステージング・開発環境はIP制限があるため、Datadog Private Location Workerを作成し、Private LocationからE2Eテストを行う必要があります。
Private Locationは内部用アプリケーションの監視や、パブリックインターネットから接続できないプライベートURLの監視が行えます。
Private Locationの構築方法は割愛しますが、下記ドキュメントに記載の通りです。
https://docs.datadoghq.com/ja/synthetics/private_locations/?tab=docker
料金
Synthetics Browser Testの料金は12ドル / 1,000テストで、私達のサービスでは月毎に120ドル / 10,000テストまでを目安としています。
https://www.datadoghq.com/ja/pricing/
テスト実行数はSynthetics Browser Test Runsから確認できます。
シナリオ作成
シナリオを作成をするにあたり、必要な条件とユースケースの洗い出しを行います。
条件の例
PC ・ SP / 閲覧する言語 / その他サイト固有のバージョンなど
ユースケース
会員登録 / ログイン / ログアウト/ ポイントの購入 / ポイントの消費 など
論理シナリオ
検討した条件とユースケースを元に論理シナリオを検討します。
PC 英語 : 会員登録 → ログイン → ログアウト
SP 英語 : 会員登録 → ログイン → ログアウト
PC 繁体字 : 会員登録 → ログイン → ログアウト .....
一つ一つのシナリオが長くなってしまうとメンテナンスしにくくなってしまうので、必要なユースケースを細かくする事を心がけました。
また、定期実行に耐えることができるように、「ポイントの購入」→ 「ポイントの消費」といった、一つのシナリオを複数回実行してもエラーにならないシナリオにしました。
Datadogでテストの作成
準備
ブラウザテストを行うためには、Datadog test recorderという拡張機能をインストールしておく必要があります。
https://chrome.google.com/webstore/detail/datadog-test-recorder/kkbncfpddhdmkfmalecgnphegacgejoa
新規ブラウザテスト作成
UX Monitoring > Synthetic Tests を押下
New Test > New Browser Test を押下
テストの詳細情報を設定
| Starting URL | テスト開始のURL |
| Name | テスト名 |
| Environment | テストの実行環境 検索やフィルタリングで利用できます。 |
| Additional Tags | 追加のタグ |
| Browers & Devices | テストを実行するロケーション |
| Select Location | テストを行う国を指定する事ができます。 ※開発環境などのIP制限されている環境へアクセスする為にPrivate のlocationを設定する事もできます。 |
| Specify test frequency | 定期実行の頻度 |
| Define alert conditions: | アラートの閾値の設定 |
| Configure the monitor for this test | アラートの通知先の設定 |
| Set permissions | 作成したテストに対する制限の設定 |
論理シナリオに沿ったテストの作成
準備
論理シナリオで利用する動的な値を利用するために[ Variables ]の値を準備しておきます。
会員登録の論理シナリオを行うケースでは、同じEmailのアドレスを登録するとエラーになってしまうので、テストではVariablesで定義した値を利用します。
例：
| Variable Name | MAIL_ADDRESS |
| Value | hogehoge+{{ date(0, YYYYMMDDhhmmss) }}@gmail.com |
| 利用方法 | {{ MAIL_ADDRESS }} |
Start Recording
Start Recording を押下後、実際にブラウザ上にテスト対象のサイトが表示されるので、論理シナリオに沿って操作を記録していきます。
画面を操作すると、Steps Recorded の部分に操作した内容が記録されていきます。
ステップを個別に修正したい場合には、ステップをクリックして修正を行うことができます。
フォームに入力したいValueを設定する場合には、ステップをクリックしてVariableで設定した値を設定することで、動的な値を設定する事が可能です。
シナリオ内のステップで失敗した場合、そこでシナリオの実行が停止し、シナリオ全体がfailed扱いとなります。
もし期間限定のポップアップなどでシナリオが失敗してしまう場合、「Continue with test if this step fails」にチェックを入れることで、ステップが失敗してもシナリオを継続して、シナリオ全体をfailed扱いにしないことができます。
(さらに、「Consider entire test as failed if this step fails」にもチェックを入れると最後のステップまで実行後シナリオ全体をfailed扱いにすることもできます)
論理シナリオに沿ったオペレーションが完了したら、Stop Recordingを押下して Save & Quit を押下します。
作成したテストの詳細画面にある Run Test Nowを押下することで、設定したステップの通りに操作を実行してくれます。
ステップ毎にスクリーンショットを確認できるので、どのステップの時にエラーが起きて、どのような画面が表示されていたかなどの詳細情報を確認する事ができます。
トリガー作成
設定したテストは定期実行に加え、DatadogのAPIを実行することで任意のトリガーを追加で設定することも可能です。
私達のチームでは下記追加トリガーを設定しています。
サイト改修時の実行
開発者が改修した内容のデプロイをArgoCDで監視して、Jobコンテナを作成。作成したコンテナからDatadogのテストを実行する様に設定を行いました。
監視運用フローについて
テストを実行し失敗した場合、特定のSlackチャンネルに、どのテストが成功・失敗したのかのログを投稿するように設定しています。
失敗した際、必ずしもシステム障害が発生している訳ではなく、日々の機能リリースによってテスト内容が画面仕様と合わなくなりテストが失敗している可能性もあり、失敗した理由の確認が必要になります。
例えば、対象要素をクリックして遷移するステップでHTML構造が変更されたことにより対象要素を参照できなくなった、などが分かりやすい例です。
▼ Slackにログが投稿されている様子
現状は特に誰が確認をするのか定めていないため、チーム内の気付いた人が詳細を確認するフローになっています。
ただ、今までの運用経験上、システム障害が実際に発生していた回数より機能リリースによってテスト内容が合わなくなっている状況が多く、実装担当者がテスト内容を修正することが多いです。
Slack投稿のリンクからDatadogのStep Resultページに遷移することができ、テストのどのステップまで成功し、どのステップで失敗したのか詳細を確認できます。
ここで失敗した事象から、原因がシステム障害なのかどうかを確認し、テスト内容が画面仕様と合わなくなっているのであれば、画面仕様通りに実行されるようステップの修正を行い、最後に手動でテストを実行して、該当テストが成功することを確認します。
▼Datadog Synthetic Monitoring Step Result
運用開始してからの課題と対応策
E2Eテストを導入し運用して、現状下記のような課題が見えてきています。
（課題）シナリオ数ではなくテスト実行数で従量課金のため、油断しているとお金がかかるようになってしまった
（対応）まとめられるシナリオはまとめたり、定期実行の頻度を減らしたり、必要なシナリオと不要なシナリオの切り分けを行うことで対応しました
（課題）テストが失敗した際に確認・修正をする人が固定化されている
（対応）Chrome拡張ツールで操作がそのままステップに反映され修正は比較的簡単なため、E2Eテストの重要性を再認識し、特定の人がずっと保守する状況は避けるような体制、ルール作りをしていきたい
（課題）画面仕様が変更されるたびにテスト内容の修正が必要になる場合が多い
（対応）シナリオ保守に塵積でコストがかかるため、テストを追加する際は重要な部分に絞りたい
（課題）テストの進行やシステム障害が発生した際の判断を行うAssertion方法で工夫が必要な場面があり、そのナレッジを開発チームで共有があまりできていないため改善したい。例えば、下記のような対応となります。
- 動的にHTMLを追加しレイアウトがずれてしまう画面にテストを行う際、クリックする瞬間に座標がずれ別の要素をクリックしテストが失敗してしまうことがあり、解決策として動的なHTMLが挿入されるまでWaitするステップを追加した
- 必要なデータがなくてシナリオが失敗したこともあるため、データ更新が含まれるシナリオの場合は管理画面で必要なデータの準備を行うシナリオに修正した
いくつかの課題は既に改善済みですが、改善活動は継続することが重要だと考えているので、引き続きサイクルを回していければと思います。
感想、まとめ
上記のように私達のチームでE2Eテスト導入をしてみての感想を下記にまとめます。
- E2Eテストを導入することで、サービスを安定稼働させつつ、機能追加や改善時に重要機能(ログインやゲーム実行、課金など)のテストを自動で動かせるため、一定の安心感を持って行えるようになった
- 人力でのテストは工数がかかったり、網羅性に欠けるといった課題があり、E2Eテストを導入することで、それらの課題をクリアできた
- 各シナリオは思ったよりも簡単に設定できる
- テスト用カードの利用期限という仕様の存在を新たに知るなど、普段他チームがメインで触っている箇所の把握できたということもあった
ここまで本記事をお読みいただきありがとうございます。私達のチームで運用しているE2Eテストの運用については以上となります。E2Eテストの導入を検討されている方へ少しでも参考になればと思います。
総合的に導入するメリットは大きいと考えているため、引き続き改善含め取り組んでいきます。
EXNOAでは、GAMESプラットフォームを一緒に発展させていくメンバーを募集しております。ご興味のある方はぜひ下記御覧の上ご応募ください！
