Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
WebアプリケーションE2Eテスト自動化3つの壁
Search
tsuemura
February 03, 2020
Technology
1
2.9k
WebアプリケーションE2Eテスト自動化3つの壁
JaSST'20 Tokyo RejectCon
tsuemura
February 03, 2020
Tweet
Share
More Decks by tsuemura
See All by tsuemura
事業継続を支える自動テストの考え方
tsuemura
0
330
テスト自動化ことはじめ(202412_オープンロジ版) / Enter the testing automation (2024 Dec, for OPENLOGI)
tsuemura
0
600
E2Eテストのシナリオと抽象化の粒度の話.pdf
tsuemura
6
640
テスト自動化ことはじめ
tsuemura
3
330
ようこそ、ソフトウェアテストの世界へ!
tsuemura
1
73
リーダブルなE2Eテストコードのための3つのC
tsuemura
7
1.1k
コンテキストとセマンティクスを意識してリーダブルなE2Eテストコードを書こう
tsuemura
12
28k
60分で学ぶE2Eテスト(実装編)
tsuemura
0
400
全部乗せフレームワーク CodeceptJS でE2Eテストを楽にしよう
tsuemura
7
5.3k
Other Decks in Technology
See All in Technology
TAMとre:Capセキュリティ編 〜拡張脅威検出デモを添えて〜
fujiihda
2
240
データマネジメントのトレードオフに立ち向かう
ikkimiyazaki
6
940
株式会社EventHub・エンジニア採用資料
eventhub
0
4.3k
技術負債の「予兆検知」と「状況異変」のススメ / Technology Dept
i35_267
1
1.1k
【Developers Summit 2025】プロダクトエンジニアから学ぶ、 ユーザーにより高い価値を届ける技術
niwatakeru
2
1.4k
『衛星データ利用の方々にとって近いようで触れる機会のなさそうな小話 ~ 衛星搭載ソフトウェアと衛星運用ソフトウェア (実物) を動かしながらわいわいする編 ~』 @日本衛星データコミニティ勉強会
meltingrabbit
0
140
Larkご案内資料
customercloud
PRO
0
650
PHPカンファレンス名古屋-テックリードの経験から学んだ設計の教訓
hayatokudou
0
220
速くて安いWebサイトを作る
nishiharatsubasa
10
12k
Building Products in the LLM Era
ymatsuwitter
10
5.4k
Developer Summit 2025 [14-D-1] Yuki Hattori
yuhattor
19
6.1k
Data-centric AI入門第6章:Data-centric AIの実践例
x_ttyszk
1
400
Featured
See All Featured
Build your cross-platform service in a week with App Engine
jlugia
229
18k
A designer walks into a library…
pauljervisheath
205
24k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.3k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
100
18k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
Product Roadmaps are Hard
iamctodd
PRO
50
11k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.4k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Facilitating Awesome Meetings
lara
52
6.2k
Into the Great Unknown - MozCon
thekraken
35
1.6k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
Transcript
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!