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.6k
WebアプリケーションE2Eテスト自動化3つの壁
JaSST'20 Tokyo RejectCon
tsuemura
February 03, 2020
Tweet
Share
More Decks by tsuemura
See All by tsuemura
コンテキストとセマンティクスを意識してリーダブルなE2Eテストコードを書こう
tsuemura
12
27k
60分で学ぶE2Eテスト(実装編)
tsuemura
0
330
全部乗せフレームワーク CodeceptJS でE2Eテストを楽にしよう
tsuemura
7
4.9k
10年前に初めてVBAで業務自動化したときの思い出
tsuemura
1
14k
テストを自動化するのをやめ、自動テストを作ろう
tsuemura
68
31k
How can we improve the testability of applications?
tsuemura
0
910
結局おれたちはどのフレームワークを使えばいいのか
tsuemura
2
3.2k
QA・テストエンジニアのためのOSSコントリビュートハンズオン
tsuemura
0
430
Selenium完全に理解した
tsuemura
0
2.7k
Other Decks in Technology
See All in Technology
「スニダン」開発組織の構造に込めた意図 ~組織作りはパッションや政治ではない!~
rinchsan
4
620
【基本】データベース設計
oracle4engineer
PRO
2
200
[新卒向け研修資料] テスト文字列に「うんこ」と入れるな(2024年版)
infiniteloop_inc
5
18k
Amplify 🩷 Bedrock 〜生成AI入門〜
minorun365
PRO
8
930
Autonomous Database Cloud 技術詳細 / adb-s_technical_detail_jp
oracle4engineer
PRO
15
35k
MLOpsの「壁」を乗り越える、LINEヤフーの Data Quality as Code
lycorptech_jp
PRO
8
630
中年男性がメインフレームから クラウドへキャリアシフトしてみた
uechishingo
0
280
2023年度にEMとして頑張ったこと
ikefukurou777
0
100
チームでロジカルシンキングに改めて向き合っている話 〜学習環境と実践⽅法〜
sansantech
PRO
3
3.3k
プロンプトエンジニアリングでがんばらない-Agentic Workflow へ-近藤憲児
kenjikondobai
6
1.2k
今日からできる!簡単 .NET 高速化 Tips -2024 edition-
xin9le
7
4.1k
Cracking the KubeCon CfP
inductor
2
270
Featured
See All Featured
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3.1k
GraphQLの誤解/rethinking-graphql
sonatard
56
9.3k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
275
13k
Producing Creativity
orderedlist
PRO
338
39k
Building a Modern Day E-commerce SEO Strategy
aleyda
22
6.4k
Side Projects
sachag
451
41k
Debugging Ruby Performance
tmm1
70
11k
Building Your Own Lightsaber
phodgson
100
5.7k
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
Robots, Beer and Maslow
schacon
PRO
155
7.9k
Scaling GitHub
holman
457
140k
Fontdeck: Realign not Redesign
paulrobertlloyd
76
4.9k
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!