Download as PDF, PPTX
Selenium Antipatterns
- 1. Selenium Antipatterns Miyata Jumpei(@miyajan) Feb. 6, 2016 #seleniumjp
- 2. 自己紹介 • 宮田 淳平(@miyajan) • サイボウズ株式会社 • 開発基盤部生産性向上チーム • 品質保証部テストエンジニアリングチーム • 最近の趣味：筋トレ • 3ヶ月で50kg→58kg
- 3.
- 4. 日本語のSelenium本 • Selenium実践入門 • 実践Selenium WebDriver • Selenium デザインパターン ＆ ベストプラク ティス
- 5.
- 7. kintoneチームのSeleniumテスト • 1,000以上のテストケース • すべてのテストが年間で1,000回以上実行 •年間数十件単位の不具合を防止 • フレームワークレベルの変更を安心して行える
- 8.
- 9.
- 10. Seleniumのよくある課題 • 運用してみたけど続かない • コストの割にはメリットを感じない •改善したいけどよくわからない
- 11.
- 12.
- 13.
- 14. まえがき • 発表者が体験したもの • 運用寄りの話中心なのでコードとかは出てこない •「Seleniumデザインパターン & ベストプラクティス」読もう • デモなし、文章だらけ • そこそこの規模で運用しようと思ってる人向け • テストケースが少ないときはなんとかなってしまう • 異論は認める • 時と場合による • 実際の運用寄りの議論が活発になってほしい
- 15.
- 16. 背景 • 不具合の再発防止をしたい • 手動で試験したくない •常に保証したいなにかがある
- 17. すべてSeleniumで解決！ • 結合テストが一番安心できる • 自動化すれば後はなにもしなくてよさそう •ブラウザを経由すればなんでも確認できそう
- 18.
- 19. 実際にあった事例 • 開発者が気が向いたときにSeleniumテストを 追加 • どのテストが自動化されているかわからない •数が増えてメンテコスト増大 • 最終的にメンテナンス不能
- 20.
- 21. メンテナンスコストが大きい • 実行時間が長い • 単体テストは数ms、Seleniumテストは数十秒∼数分 •不安定になりやすい • ネットワーク • Selenium Server • ブラウザ • テスト対象（アプリ、DB、KVS、etc.）
- 22.
- 23.
- 24.
- 25. 適切な選択肢を選ぶ • 静的解析 • 単体テスト •APIテスト • 手動テスト
- 26.
- 27.
- 28.
- 29. まとめると • 頻繁に確認したい • E2Eレベルの •シンプルなテストを • メンテできる範囲の数で • Seleniumを活用しよう • それ以外は別の選択肢を検討しよう
- 30. 実際に行った改善 • Seleniumは受入試験の自動化のみに絞る • 単体テスト、APIテストで可能な限り保証する •自動化されてるテストが把握できる • メンテできる範囲の数になる
- 31.
- 32.
- 33. 既存のプロセスにそのまま追加しよう！ • 既存の開発プロセス 実装 手動テスト •新しい開発プロセス 実装 手動テストSeleniumテスト
- 34.
- 35. 実際にあった事例 • 回帰試験をSeleniumテストで自動化 • 実装がFIXしたら流す •実装期間のUI変更でSeleniumテストが通らなくなる • 乖離が大きすぎるのでいったん放置して手動でテスト • 最終的にメンテナンス不能
- 36.
- 37.
- 38. 工数削減？ • 間違いではない • けど、これだけを目的にすると辛い •導入コストやメンテコストを考えると • 投資対効果が吊り合うまでに時間がかかる
- 39. 速度とタイミング • 繰り返しになるけど • 人間には不可能な速度とタイミングでテストを 実行できる •より早い段階から繰り返しテストできる • 問題の発見が早くなると対応コストとリスクが 減る
- 40.
- 41.
- 42.
- 43.
- 44. 常に繰り返し実行する • 自動テストのメリットを最大化するために • 理想的には本体が変更されるたびにテストを実行したい •乖離が最小になる • 厳しいなら一日一回とか、可能な範囲で頻度を上げる 実装 手動テスト Seleniumテスト
- 45. 開発プロセスを変えるのは大変 • 推進役が必要 • 難しい場合は •まずは単体テストとかからCI/CD文化を広める • メリットを実感できれば協力者も増える • 繰り返しになるけどSeleniumテストは大きい
- 46. まとめると • Seleniumテストを手動テストの置き換えに留めずに • 常に繰り返し実行される開発プロセスを目指そう •推進役を立てよう • 小さいことからでもメリットを実感しよう
- 47. 実際に行った改善 • デプロイパイプラインを構築してコードが変更されるたびに Seleniumテストをすべて実行 • 誰が落としたかすぐ分かる •落とした人は即修正を義務化 • 常に製品とテストの乖離がない状態 • 問題の早期発見にもつながり安心感が出てくる • 意識が高いわけではないです:)
- 48.
- 49.
- 50.
- 51.
- 52. 実際にあった事例 • IE8∼IE11、Firefox、Chromeで毎日すべての Seleniumテストを実行 • すべてのテストが通ることはない •毎日環境のメンテナンスに時間がとられる • 最終的にメンテナンス不能
- 53.
- 54.
- 55. ブラウザ × WebDriver •ブラウザのバージョンとWebDriverのバー ジョンがある • 組み合わせ数が増えるにつれてトラブルを踏 む可能性が高くなる
- 56. IE • 不安定 • クラッシュしてiedriver.exeのプロセスが残ったままになる •マウスカーソルがブラウザに重なってるとhoverの挙動がお かしくなる • 保護モードの設定 • 突然のブルースクリーン
- 57.
- 58.
- 59. IEサポート IE8 IE9 IE10IE11 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
- 60. Microsoft Edge • WebDriver対応状況が公開されている •https://dev.windows.com/en-us/microsoft-edge/ platform/status/webdriver/details/ • 正直まだ早い
- 61. ヘッドレスブラウザ • GUIがないブラウザ • 速度やリソース消費量でメリットはありそう •前にPhantomJSを試したときはファイルアップロードが動かなくて諦めた • 2.1で改善されてるかも？ • Seleniumでの運用事例をあまり見かけないのが辛い • と思ったら本日素晴らしい事例が！ • PhantomJSはやっぱり辛そうという結論＼(^o^)／
- 62.
- 63. TaaS Platform • SauceLabsとか • お金で環境メンテコストを解決 • 微妙な挙動の差異とかはさておき
- 64.
- 65. 実際に行った改善 • 過去のブラウザ依存の不具合を集計 • 重要不具合でSeleniumで発見できる種類のものはほぼなかった •Chromeのみに絞った • OSもLinuxにしてDockerで管理 • 安定 • メンテも楽
- 66. そのほかアンチパターン • 依存関係のあるテスト • setup,tearDown • GUI変更に弱い • ページオブジェクト • 実行時間長すぎ • Selenium Gridで並列化 • 冗長なコード • Gebとかラッパーライブラリ
- 68.
- 69. まとめ • Seleniumは便利だけど落とし穴もある • 本格的に運用する前にアンチパターンを知って回避 •もちろんベストプラクティスも重要なので、
- 70.
- 71.
- 72.