selenium antipatterns

Selenium AntipatternsMiyata Jumpei (@miyajan)

Feb. 6, 2016 #seleniumjp

自己紹介

• 宮田 淳平 (@miyajan)

• サイボウズ株式会社

• 開発基盤部生産性向上チーム

• 品質保証部テストエンジニアリングチーム

• 最近の趣味：筋トレ

• 3ヶ月で50kg→58kg

寄稿しました！

日本語のSelenium本

• Selenium実践入門

• 実践 Selenium WebDriver

• Selenium デザインパターン ＆ ベストプラクティス

cybozu × Selenium

kintoneチームのSeleniumテスト

• 1,000以上のテストケース

• すべてのテストが年間で1,000回以上実行

• 年間数十件単位の不具合を防止

• フレームワークレベルの変更を安心して行える

一方、社内では導入失敗事例も数多く存在します…

世の中的にもうまく運用できている話をあまり聞かないような…？

Seleniumのよくある課題

• 運用してみたけど続かない

• コストの割にはメリットを感じない

• 改善したいけどよくわからない

よくある落とし穴と対策が もっと広まるとよさそう？

今回のお話

アンチパターン

• 最初は有益だと思えるが、最終的に悪い結果をもたらすもの

• リファクタリングするための方法が存在する

まえがき• 発表者が体験したもの

• 運用寄りの話中心なのでコードとかは出てこない

• 「Seleniumデザインパターン & ベストプラクティス」読もう

• デモなし、文章だらけ

• そこそこの規模で運用しようと思ってる人向け

• テストケースが少ないときはなんとかなってしまう

• 異論は認める

• 時と場合による

• 実際の運用寄りの議論が活発になってほしい

アンチパターン1 なんでもSelenium

背景

• 不具合の再発防止をしたい

• 手動で試験したくない

• 常に保証したいなにかがある

すべてSeleniumで解決！

• 結合テストが一番安心できる

• 自動化すれば後はなにもしなくてよさそう

• ブラウザを経由すればなんでも確認できそう

なにが問題？

実際にあった事例

• 開発者が気が向いたときにSeleniumテストを追加

• どのテストが自動化されているかわからない

• 数が増えてメンテコスト増大

• 最終的にメンテナンス不能

Seleniumテストは大きい

メンテナンスコストが大きい• 実行時間が長い

• 単体テストは数ms、Seleniumテストは数十秒～数分

• 不安定になりやすい

• ネットワーク

• Selenium Server

• ブラウザ

• テスト対象（アプリ、DB、KVS、etc.）

粒度が大きい

• 1メソッド、1リクエストで確認できる挙動のためにブラウザまで動かすのはやりすぎ

どう改善すればいいの？

例えば、Seleniumを避ける

適切な選択肢を選ぶ

• 静的解析

• 単体テスト

• APIテスト

• 手動テスト

適切な選択をするために Seleniumテストの 長所と短所を理解する

長所

• E2Eレベルでの保証ができる

• 人間ではほぼ不可能な速度とタイミングで実行できる

短所

• メンテナンスコストが高い（＝不安定）

• 柔軟性がない

まとめると

• 頻繁に確認したい

• E2Eレベルの

• シンプルなテストを

• メンテできる範囲の数で

• Seleniumを活用しよう

• それ以外は別の選択肢を検討しよう

実際に行った改善

• Seleniumは受入試験の自動化のみに絞る

• 単体テスト、APIテストで可能な限り保証する

• 自動化されてるテストが把握できる

• メンテできる範囲の数になる

アンチパターン2 手動テストの代わり

背景

• 既存の開発プロセスにSeleniumテストを取り入れたい

既存のプロセスにそのまま追加しよう！

• 既存の開発プロセス

実装 手動テスト

• 新しい開発プロセス

実装 手動テストSeleniumテスト

なにが問題？

実際にあった事例

• 回帰試験をSeleniumテストで自動化

• 実装がFIXしたら流す

• 実装期間のUI変更でSeleniumテストが通らなくなる

• 乖離が大きすぎるのでいったん放置して手動でテスト

• 最終的にメンテナンス不能

手動テストの代わりだけだと Seleniumテストのメリットを

最大化できない

そもそもSeleniumテストで 得られるメリットってなんだろう？

工数削減？

• 間違いではない

• けど、これだけを目的にすると辛い

• 導入コストやメンテコストを考えると

• 投資対効果が吊り合うまでに時間がかかる

速度とタイミング

• 繰り返しになるけど

• 人間には不可能な速度とタイミングでテストを実行できる

• より早い段階から繰り返しテストできる

• 問題の発見が早くなると対応コストとリスクが減る

もう一つ問題がある

Seleniumテストを放置すると

• ソフトウェア本体との乖離が大きくなる

• するとメンテコストが高くなってさらに放置

• 負のスパイラル

どう改善すればいいの？

”組織にテスティングツールを取り入れると、人々の働き方を変えることになるということを肝に銘じておくことが重要である。”

「システムテスト自動化標準ガイド」より引用

常に繰り返し実行する

• 自動テストのメリットを最大化するために

• 理想的には本体が変更されるたびにテストを実行したい

• 乖離が最小になる

• 厳しいなら一日一回とか、可能な範囲で頻度を上げる

実装 手動テスト

Seleniumテスト

開発プロセスを変えるのは大変

• 推進役が必要

• 難しい場合は

• まずは単体テストとかからCI/CD文化を広める

• メリットを実感できれば協力者も増える

• 繰り返しになるけどSeleniumテストは大きい

まとめると

• Seleniumテストを手動テストの置き換えに留めずに

• 常に繰り返し実行される開発プロセスを目指そう

• 推進役を立てよう

• 小さいことからでもメリットを実感しよう

実際に行った改善• デプロイパイプラインを構築してコードが変更されるたびに

Seleniumテストをすべて実行

• 誰が落としたかすぐ分かる

• 落とした人は即修正を義務化

• 常に製品とテストの乖離がない状態

• 問題の早期発見にもつながり安心感が出てくる

• 意識が高いわけではないです:)

アンチパターン3 クロスブラウザがんばりすぎ

背景

• 動作環境のすべてのブラウザで品質保証したい

Seleniumテストをすべてのブラウザで実行しよう！

• Seleniumはクロスブラウザ対応してる

• すべての動作環境で確認したい

なにが問題？

実際にあった事例

• IE8～IE11、Firefox、Chromeで毎日すべてのSeleniumテストを実行

• すべてのテストが通ることはない

• 毎日環境のメンテナンスに時間がとられる

• 最終的にメンテナンス不能

”デフォルト設定で、他のブラウザよりもたくさんの問題を引き起こすブラウザがあります。 私が言っているのはInternet Explorerのことです。”

「Selenium デザインパターン ＆ ベストプラクティス」より引用

Seleniumテストをクロスブラウザで運用するのは思ったより大変

ブラウザ × WebDriver

• ブラウザのバージョンとWebDriverのバージョンがある

• 組み合わせ数が増えるにつれてトラブルを踏む可能性が高くなる

IE

• 不安定

• クラッシュしてiedriver.exeのプロセスが残ったままになる

• マウスカーソルがブラウザに重なってるとhoverの挙動がおかしくなる

• 保護モードの設定

• 突然のブルースクリーン

どう改善すればいいの？

ブラウザを絞る

• ブラウザ依存の重大な不具合が過去にほとんどなければ

• ChromeかFirefoxが比較的安定

IEサポート

IE8 IE9 IE10 IE11

Windows Vista 2016/01/13 2017/04/11 None None

Windows 7 2016/01/13 2016/01/13 2016/01/13 2020/01/14

Windows 8.1 None None None 2023/01/10

Windows 10 None None None 2025/10/14

Microsoft Edge

• WebDriver対応状況が公開されている

• https://dev.windows.com/en-us/microsoft-edge/platform/status/webdriver/details/

• 正直まだ早い

ヘッドレスブラウザ

• GUIがないブラウザ

• 速度やリソース消費量でメリットはありそう

• 前にPhantomJSを試したときはファイルアップロードが動かなくて諦めた

• 2.1で改善されてるかも？

• Seleniumでの運用事例をあまり見かけないのが辛い

• と思ったら本日素晴らしい事例が！

• PhantomJSはやっぱり辛そうという結論＼(^o^)／

どうしてもクロスブラウザでSeleniumテスト実行したい

TaaS Platform

• Sauce Labsとか

• お金で環境メンテコストを解決

• 微妙な挙動の差異とかはさておき

まとめると

• ブラウザは可能な限り絞る

• 絞れないならTaaS

実際に行った改善• 過去のブラウザ依存の不具合を集計

• 重要不具合でSeleniumで発見できる種類のものはほぼなかった

• Chromeのみに絞った

• OSもLinuxにしてDockerで管理

• 安定

• メンテも楽

そのほかアンチパターン• 依存関係のあるテスト

• setup, tearDown

• GUI変更に弱い

• ページオブジェクト

• 実行時間長すぎ

• Selenium Gridで並列化

• 冗長なコード

• Gebとかラッパーライブラリ

アンチパターンの兆候

• メリットが感じられていない

• 必要以上に苦労していると感じる

まとめ

• Seleniumは便利だけど落とし穴もある

• 本格的に運用する前にアンチパターンを知って回避

• もちろんベストプラクティスも重要なので、

MUST BUY!

Thanks!

Questions?