【勉強会】第4回 日本Seleniumユーザーコミュニティ勉強会
2016-12-18 第4回 日本Seleniumユーザーコミュニティ勉強会
これに行ってきた
最近のSelenium
2016 Selenium ゆく年くる年 〜最近のSelenium〜
戸田広さん
www.slideshare.net
Selenium3.0
WebDriverに関してはマイナーバージョンアップ程度だった
とはいえ、
- JavaバインディングではJava8以上が必須
- RubyバインディングはRuby2.0以上が必須
- SeleniumRCはleg−rcパッケージに（RC使ってなければ影響なし）
- SeleniumRCに依存しているツールは動かなくなる
- SeleniumIDEで出力したSeleneseHTMLは動かなくなる（別jar実行で動く）
など、細かいところは変更あるので注意。
その他
- FireFoxで動かなくなる事象は、FireFox側の仕様変更の影響
- SeleniumIDE/SeleniumBuilderは、2017中に対応するFireFoxがサポート外になる
- WebDriver標準化への流れ
Appiumの勘所
「実践Appium」の勘所 - とAppium1.6の補完
SHIFT 太田健一郎さん
オライリーの「実践Appium」の監訳しました！
Appiumとは？
（Appiumはしばらく縁がなさそうなので、メモは省略）
テスト自動化導入にあたって
「リクルートジョブズのブラウザテスト自動化の七転八倒そしてその先へ」
あるある
- 自動化をバックログに入れた時点で負け（それだけ負債がたまっているということ）
- テスト自動化と機能をどっち優先というと機能になっちゃう
- かといって、じゃあ勝手にテスト書くと双方幸せにならない
スコープの調整
- 自動化すると全てが解決する、という妄想
- 全てをテストしようとする、という無謀
社内横展開時、期待値調整は必要
- 「自動化って、全部やっても無駄だよね？」
自動テストに向くところ
まとめ
- まずは自分でやってみる
- 黙ってやってもいいことない、身近な偉い人から攻める
- 成功体験を積み上げる
E2Eテストの自動化
「一休.comのE2Eテスト事情〜Selenium3.0対応〜」
一休 赤坂翔太さん
E2E運用事情
ホテル宿泊サイト
- まず、止めたくない
- 確認観点は、予約・変更・取り消し
- ３０ケース程度ある
- 当時は、ガラケーを両手に持ってひたすら動確
それがいまは、Slackからチャット打つとテスト実施まで成長、という話
工夫したポイント
- PageBassClass
- 環境毎の設定ファイル
- 並列実行はJenkinsのParentJobからChildJob
- SeleniumGridは使ってない（特に検証して比較してはないが）
- 詳しくはこちら
サービス開発は進む
- 当初はしっかりテスト設計もしていた
- それが、マイクロサービスにした結果、リリースフローが別になる
- 認証周りで障害が出ても、原因調査が困難だったり
- 認証部分はテスト観点が違う、通常機能と別に独自で確認が必要と気づく
- サービス開発は進む、テストも対応していく可能性がある
まとめ
ユーザに価値を届けるため、サービスの根幹となる機能を確認する
E2Eテストを継続させるポイント
- 安定性
- オオカミ少年にしない、リトライ処理を入れるなり
- 技術的キャッチアップ
- メンテナンス性
- PageObjectDesignPattern重要
- テスト増やす時の手順を共有したり
- 実行速度
- 並列実行がキモ
オフショアでのテスト自動化
「オフショア手動テストチームが、テスト自動化チームとして生まれ変わった物語」
楽天 荻野恒太郎 さん、DHC 張永澤 さん
不満
オンサイト
- テストが高額だ、と上司から毎日言われる
- 詳細なテスト設計書に納得いかない（テストスクリプトで十分では？）
- 納期に間に合わなくなるとテスト品質が著しく低下
- カバレッジ100%の見積もりを作ってくる
- 遅い、長い
オフショア
- 見積もりを少なくするとすぐに赤字になる
- オフショアでは権限的にできないことがたくさん
- テスト不足でバグ・障害をだしたら責任問題
- テスト要求が曖昧すぎる
- 納期が少しでも遅れたら大問題
反撃
オンサイト
- 納品物を再定義
- テストを自動化したなら、自動化前と納品が同じではおかしい
- 要求分析→設計→実行→報告
- 手動テスト時は設計と報告を納品していた
- 自動テストでは実行部分（テストコードとJenkinsジョブ）が最重要
- 設計書は、不要ではなく合意形成に必要
- 報告書は、自動生成可能
- 自動テストフレームワークの準備、保守以降のメンテナンス性が重要
- Cucumberを使用
- FeatureファイルとPageObjectパターン
- PageObjectBaseとStep file
- 全部をプロジェクト毎に作成するのではなく、再利用性を考慮
- フレームワーク部分なら再利用可能
- オフショアからのアクセス権限は結構重要
- テスト対象のサーバにアクセスできるようにする
オフショア
- ペア作業体制
- これまでのテストエンジニアではテスト自動化はできない
- 開発エンジニアのSelenium知識、開発能力が必要→ペア作業
- 工数見積もり方法の改善
- 全てを自動化しない
- テスト観点に優先度付け＋自動か手動かをオンに選ばせる
- テストスクリプトの改善
- CucumberのFeatureファイルを使う（＝データ駆動方式）
- テスト設計のやり方を見直し
- 確認項目作成をやめて、マトリクスのみ作成
- 細かいテスト内容はテストスクリプトで確認できるから
明日から始めるSelenideによるブラウザテスト
アカウンティング・サース・ジャパン 島根義和さん
Selenideとは？
デモ
- 環境
- JUnit
- Selenideはv4.1
- FireFox48以上
- GeckoDriver
デバッガでブレイクポイント張って、評価式をリアルで試せる ブラウザ内の目的要素を探すのに便利 IDが振られてれば一意に取れるけど、IDないとDOMツリーから探す必要が、、
導入コストは低い、さくっと試すにはオススメ E2Eテスト自動化にあたっての課題を解決するものではない 本格的にテストプロセスに組み込む場合は慎重に検討を
TL
http://qiita.com/EichiSanden/items/ea857b46cbf5435b0c3b
Selenium Conference 2016 参加報告
新日鉄住金ソリューションズ 石川真也さん
www.slideshare.net
Pitalium？
- スクリーンショットベースでテストするもの
Selenium3.0
Appium
SeleniumIDE
- 今年中に最後のリリースをする予定
- コミッターもすでに消極的な印象
課題
- 不安定なテストをflakyという（flaky＝フレイキー、不安定）
- 同じコードで成功・失敗どちらにもなるテスト
- スクリプトの保守性
- PageObject PatternはSOLID原則に反している！という主張
Seleniumでキーワード駆動テストを実践した時のあれこれ
小島直也さん
www.slideshare.net
キーワード駆動テストとは
ギア本での分類
自動テスト テスト自動化フレームワークの開発
全てのテストレベルで使用できる
プログラミングやテストツールの専門知識がなくても実装できる
目的は、構造化・データ駆動の課題を軽減する
構造化スクリプティングとの比較
- テストシステム開発時、工数はキーワード駆動の方が高い
- テスト実装時、必要スキルが違う、コーディングスキルかキーワードの設計スキル
- テスト実行時、特に差異なし
- テストシステム保守時、保守工数はキーワード駆動の方が高い
キーワード駆動でコストがかかる箇所をどう下げるか、が今日の話
実践
背景
- 同じテストの繰り返し
- テストデータ入力のミスを検証する必要がある
- テストコードを書くスキルはない →キーワード駆動を選択
構造
やってみた課題
- 適切なキーワード抽出が不明
- 画面変更によりテストケース再作成が必要、ハイコスト
対策
Advent Calendarで！！
適切なキーワードの検討
ｰｰｰ
ディープラーニングとAppiumでモバイルテスト自動化
TRIDENT 伊藤望さん
SeleniumIDEとかAppium何とか、保守大変、何を作ったか後から読みにくい
WebDriverやAppiumだと、何でもできるけどコード書くの大変
ディープラーニングと組み合わせて、「Magic Pot」作りました！
近日改名の予定→「Magic Pod」
これまでのアプリのテストは？
大変。。。
そこで、
- アプリのスクリーンショットから画面要素を解析
- 解析結果からD＆Dでテストケース作成
- アプリの実態を与えると自動テスト実行
- 実行の実態はAppiumを利用
