WebアプリケーションE2Eテスト自動化3つの壁

WebアプリケーションE2Eテスト⾃動化の3つの壁

⾃⼰紹介末村拓也(Takuya Suemura) ⽊村拓也じゃないよ QA / テスト⾃動化エンジニアというテスト⾃動化プラットフォームを作る会社で働いています

https://autify.com/ja/

E2Eテスト⾃動化してますか？

理想アサーションを⾃動化し、リグレッションの⾒落としを防げるようになる⾃動化により⾼頻度で実⾏できるようになる BDD・ATDDで振る舞いを保護しながら安⼼して開発が出来る

現実⾃動化は進んだものの…… バグを検知できない⼿動でやればたくさんバグが⾒つかるのに…… 思ったより⾼頻度で実⾏できない実⾏速度が遅いどうでもいいところでコケまくる不安定不安定不安定不安定「また落ちてるな、リリース後に調べよう」 →深刻な不具合

3つの壁バグ検出実⾏速度安定性これらを解決するための技術を広く浅く紹介してみます →深く話したい⼈は懇親会で！

バグ検出

E2E⾃動テストでバグを⾒つけるのは難しい網羅性が低い（網羅しようとするとテストケース数が膨⼤になってしまう）アサーションが無いところでバグが出がち「⼈がやってた時はバグを⾒つけられたのに……」

どうやってバグを⾒つけるか？基本的には「広く浅く」調べるようにするスナップショットテストビジュアルリグレッションテスト実⾏時エラーの検知

1. スナップショットテスト HTMLの差分を⽐較する⽅法引⽤元: https://jestjs.io/docs/en/snapshot-testing

2. ビジュアルリグレッションテストスクリーンショットを⽐較して差分を⽐較する⽅法 Original Current 引⽤元: https://codecept.io/visual/#using-resemble-helper

引⽤元: https://codecept.io/visual/#using-resemble-helper

3. 実⾏時エラーを検知するクライアントサイド(JavaScript)やサーバサイドのエラーを取得する⽅法 Sentryなどのサービスを使うとJavaScriptやサーバサイドのエラーをまとめて補⾜できる本番環境で使っているものをステージングやQA環境でも使うと良い TestCafe など、JavaScriptの実⾏時エラーを検知するとテストを中⽌する（失敗になる）フレームワークもある
Seleniumはログ取得のためのAPIを廃⽌したっぽい、悲しい

実⾏速度

E2Eテストの実⾏速度を早めるのは難しい実ブラウザを使う以上重い仕事になる要素の表⽰待ちなど暗黙の「待ち」が多い実⾏環境によってはネットワークレイテンシが強烈

アプローチテストデータをAPIやコマンドで作る状態をキャッシュする並列実⾏

1. テストデータをAPIやコマンドで作るテストデータもE2Eで作ってませんか？画⾯ A, B, C がある B, Cのテストをする前にAを操作しないといけない
Aが動かない場合B, Cのテストができない

1. テストデータをAPIやコマンドで作る APIを使うコマンドラインから任意のメソッドを実⾏する Railsでの例: bundle exec rails runner 任意のコマンド

1. テストデータをAPIやコマンドで作るフロントエンド→バックエンドの通信部分だけを実⾏する F12 → Network タブ → Copy as
fetch

2. 状態をキャッシュする E2Eテストの実⾏はCookie, キャッシュなどが無いクリーンな環境で⾏うのが定⽯しかしログインなどの処理を毎回E2Eでやるのは⾟い⼀度ログインしSessionIDを保存しておけば後で使い回せる TestCafeにはUser Roleという機能があり、難しいことを考えずに↑のようなことが出来る

3. 並列実⾏複数のマシン (or ブラウザ) で並列に実⾏させる https://www.browserstack.com/guide/selenium-grid-tutorial

並列実⾏の注意点テストシナリオにべき等性を持たせる必要がある何度実⾏しても同じ結果になるようにするシナリオに順序を持たせてはいけない

コンテナによる並列実⾏環境を構築するためのOSS Chrome, FirefoxがインストールされたLinuxコンテナを必要に応じて⾃動で追加・削除してくれる Zalenium Selenoid 商⽤サービスあり

安定性

E2Eテストは不安定要素の表⽰待ち外部サービスのエラー通信環境

筋⾁リトライは全てを解決する

1. 失敗したステップをリトライする要素の表⽰を賢く待つよりも、リトライさせたほうが様々なケースに対応できるローディングスピナーが邪魔してクリックできない inputに⽂字⼊⼒できるようになるまでに時間がかかる URLが期待値に変わるまで時間がかかるステップのリトライ回数を設定できる場合は設定しておくと吉

2. 失敗したシナリオをリトライする外部サービスとの接続性などの問題で不安定になっている場合に有効規定の回数リトライし、⼀つでも成功すればOKとするステップと同様、デフォルトリトライ回数を設定しておくと楽

3. 不安定性を可視化する Allure Reporterでの例今までのテスト結果を全て保存しておき、失敗頻度が⾼いものにマークが付く

いかがでしたか？

E2Eテスト難しいこと多すぎ問題

そう、難しいんだ⾼レイヤーのテストになるほど時間とコストがかかる QAならみんな知ってるよね？ E2Eでやらなくてもいいことはたくさんあるまずは難しさを理解することが重要 E2Eでしか出来ないことに注⼒しよう

（余談）E2E = UIではないレンダリング + JavaScript実⾏の検証だけなら必ずしもE2Eである必要はないかもしれない Playwright はつい最近Microsoftから発表されたChromium, Firefox,
Webkitのテストをするためのツール AppliToolsのUltrafast Gridは任意のページのDOMスナップショットを複数のブラウザでレンダリングし⽐較する UIテストが実機の縛りを抜け、E2Eテストの責務を減らし、シンプルに実現できるようになる

3つの壁バグ検出実⾏速度安定性

壁を乗り越えた先は⾼速・⾼頻度で実⾏されるテスト広範囲でバグを検出できるテスト安定動作するテスト

難しいこともあるけど楽しく乗り越えていきましょう

Enjoy Testing!

WebアプリケーションE2Eテスト自動化3つの壁

WebアプリケーションE2Eテスト自動化3つの壁

More Decks by tsuemura

Other Decks in Technology

Featured

Transcript