Selenium Antipatterns

Selenium Antipatterns

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