第3回 日本Seleniumユーザーコミュニティ勉強会
かなり遅い投稿になりますが、、第3回 Seleniumユーザーコミュニティ勉強会に参加してきました。
初めての？勉強会だったけど、すぐにでも職場で使えそうなネタもあって、なかなか有意義な時間でした。
Opening session (TRIDENT 伊藤)
参加申し込み時に集計された、Selenium使用言語率。上から順にJava、Selenium IDE, Rubyと続い行く感じ。
自分が使っているPythonは8番目のかなり低めで、しょんぼり。多方面でJavaScriptの躍進が目立つので、覚えてみようかな。
WebスクレイピングでもSelenium利用者が増えているとのことだったけど、あんまりメリットがわからないかった。
「Seleniumデザインパターン & ベストプラクティス」の勘所
Seleniumデザインパターン&ベストプラクティスのさわりを説明してくれました。
アンチパターン
- DRYテストパターン
- Hermeticテストパターン
ベストプラクティス
依存関係を廃止
特にデータの依存。独立性が上がる！ただし、実行時間が上がるデメリットあり。
ランダム実行順序原則
暗黙的な依存関係を防ぎます、全体実行と単独実行をそれぞれ行うことで、暗黙的な依存関係を防ぎ、独立性が上がる。 何度も繰り返し動くが継続的デリバリには必須。
結論：いいパターンがいっぱいだよ！（時間切れ）
「Selenium実践入門」で学ぶテスト自動化の世界
昔の自動試験
最近の自動試験
- Selenium1 -> 2で安定化
- 導入事例がWeb上でもかなり散見できるようになりましたよ
Selenium実践入門の内容
APIドキュメントにない内容もあるよ。
ファイルダイアログ、Basic認証、HTTPヘッダ、HTML5などなどややこしいマイナー機能。
Wrapperについても
そのほか盛りだくさん！Seleniumerは買うと幸せになれるよ！電子書籍もあるよ！
E2Eテストフレームワークを使用したテスト自動化事例
E2Eテストフレームワークの選定から、導入までのお話。
E2Eテストフレームワーク
Nightwatch.js
Node.jsベース
Protractor
AngularJSに特化。自動待機APIがあって待機処理を明示的に指定する必要がない
ヘッドレスブラウザー
PhantomJS, Zombie,,,,,などなど
PhantomJSがメジャーなので、こちらを選択。技術情報多く、Nightwatch.js/Protractorでサポートされているらしいです。
ただ、結果的にPhantomJS固有に問題があって結構無駄が多いらしいです。その結果、Xvfbでリアルブラウザーのヘッドレス化！どれくらいパフォーマンスがよくなるんだろ。とは言え、安易にヘッドレスブラウザとか使うと良くないんだなあと。
STFとAppiumをもちいたAndroidアプリの自動テスト
AWS Device FarmとかをLocal環境に建てれちゃう優れもの。ぬるぬるサクサクでビビる。
Appium使用者はまだそんなに多くない感じでした。そういう人はそれぞれのautomatorを使ってE2Eの試験を自動化しているのかな。
Azureを使って手軽にブラウザテストの自動化をはじめよう
Azureに限らず、SeleniumでE2Eテストの自動化を行ったときのはまったところの紹介などをしてくれました。
テストケースのマネジメントとかテストケース駆動・テストデータ駆動のあたりは、あるあるだなあと思った。自分のところもテストスクリプトが増えてきてカオスな感じになってきているので、見直したいところ。
Gebに実践入門するために
Gebの良いところと悪いところを説明してくれました。簡潔にかけて、わかりやすく書けるのが一番のメリットなのかな。
ただ、一方で学習コストが高く、敷居が高いと感じてしまうことが多いようです。
Selenium実践入門にもGebの章があるので、読んだ上で、Gebやろう！
エビデンス取るのも自動化したい！
テスターあるある、『テストエビデンスって証明するのつらいよね』を自動化しちゃいましょう。な、お話。
詳しくはGithubへ。
Selenium Antipatterns
Selenium導入・運用時に陥りがちなアンチパターンを紹介してくれました。
とりあえずSelenium
Selenium、結構メンテコスト大きい。そして、実行時間長い。適切なところにSeleniumを使いましょう。、、適切って？
Selenium Pros/Cons
Pros
- E2Eの自動化
- 夜実行できます
Cons
- メンテコスト
- 不安定
- 柔軟性
あるあるですね。ツール導入が目的になってしまって、やりたいことを見失うケース。可能な限り単体テストで実行し、E2Eでやらなきゃいけないことは減らしましょう。
手動テストの代わり
UIの変更でテストが通らなくなる。メンテが面倒なので、とりあえずマニュアルで試験。結果、メンテ不能。。
常にCI/CDを意識する必要がある。働き方が変わることを肝に命ずる。
クラスブラウザがんばりすぎ
全部でテストパスは非現実的。最終的にメンテコストで死亡。
対象は絞る。
Taasを利用する。
Seleniumのうすいはなし
つねに遊び心が必要。以上。でも実際、そういう人と仕事したいよね。。
音声合成エンジン（Voice Text）を使って、Jenkinsでjobがコケたときにそれを音声で通知する。っていうやつはすごく面白かった！
