第2回 日本Seleniumユーザーコミュニティ勉強会に参加してきました

このエントリーをはてなブックマークに追加

QAのkmtです。
先週の土曜日、第2回 日本Seleniumユーザーコミュニティ勉強会 に参加してきました。
各内容とも非常に充実した内容で、かなり参考になりましたし刺激をうけました。


●【玉川竜司さん】Seleniumをもっと知るための本の話

実践Selenium WebDriver発売されたのでそのお話と、英語で技術書を読むことの大切さをお話ししてくださいました。


1.「実践Selenium WebDriver」ができるまで
翻訳しようと思ったきっかけ

  Selenium1系と2系の情報がまじってる
  IDEとかRCとかいろいろあってわからないので全体像が見える本を提供しよう


ということで翻訳


2.英語の技術書を読む話

Seleniumの本

  日本では1冊だけ
  英語は20件以上


とがったトピック、非常に深いものなどは、英語で技術書を読むようにしたほうがいい
総合的な本を翻訳で読んで、あとは英語の本をあたる


のがおすすめ



英語の技術書を読むために

  英語のDVDとかを見て勉強はおすすめしない
  スラングや日常会話の表現が多種多様で理解の幅が広く必要なため


技術書を読むのは英語へのチャレンジとしてはもっとも楽なチャレンジ

kindle と safari(アメリカのオライリーの電子書籍購入サービス、メジャーどころの技術系出版社はほぼカバー)
玉川さんはFire HDX8.9を使ってる
7インチは小さい
kindleは単語を長押しで辞書をひけるのが便利


3.Seleniumの本の紹介

紹介してくださった本

    3-1.Selenium Desigh Patterns and Best Practice
      初級~中級に強い印象
     テストの書き方に重点

     出版社
     この出版社はいろいろほかにも出版している
     https://www.packtpub.com/

    3-2. Selenium WebDriver in Python
       kindleで読める
     WebDriverそのものに関する部分のPython版といった印象
     Pythonでサンプルコードをたくさんみたい人におすすめ

    3-3. Selenium IDE Automation Testing Tutorial
      Selenium IDEにフォーカス
    まさにチュートリアルでかなり初歩的な本

    3-4. Stack OverflowのSeleniumのQ&Aをそのまま書籍化
    トピックの羅列なんだがみているとおもしろい

4.Q&A

    4-1.今回出版された本の電子版でますか?
     →予定はない

    4-2.技術書何冊くらい売れれば次の本だせますか?
      (本が売れないと次の技術書のテーマの本の企画があがらないというネタを前提にした質問です)
     →うん千冊かな?

    4-3.翻訳期間は?
     →年間3~4冊なので3~4か月に1冊

    4-4.英語の本で英語でのWeb情報にないSeleniumに関する情報で目玉はある?
      →英語においても体系的な知識を最初にえるために英語の技術書を読むといいかなと
      Webだと情報が点在しているので最初は理解しにくい

●【玉川紘子さん】脱・独自改造!GebでWebDriverをもっとシンプルに

Javaでテストを書くのに、ちょっとしたことを書くのにも、長い。。。
ので、Gebで書くとシンプルになっていいよっていうお話でした。


OSSで提供されているライブラリ

-FluentLenium(java)
-Geb(Groovy)

Gebとは
  Groovyで動くWebDriverのラッパー
  

Gebで便利になること

1.記述量の少なさ
  可読性がいい
  特定のURLひらくのは go とかですむ

2.Seleniumあるあるがある程度解決済み

 -テキスト入力のシンプル化

 -設定ファイルの外だし
   GebConfig.groovyに集約

 -もちろんPageObjectもサポート
 
   PageObjectパターンとは
     デザインパターン
     画面の要素扱う部分と
       テストケースを扱う部分を扱う部分とわける

   Gebはある程度すでにサポートしてくれてる

 -Groovyto/Spockの嬉しい機能が使える
  --プロックを使ってテストのフェーズを表現できる
  --データ駆動テストがシンプルに書ける
    where を使って簡単にいろいろなデータパターンが書ける
  --モジュールが使える
    複数ページに共通メニューを表現するときに便利
  --javaの上位互換
    javaのクラスをそのままインポート可能
    原則、Javaの構文そのままでも記述できる

-注意するところ
  --Syntaxの省略に注意
   省略は便利だが、場合によってはミスを招くこともある
   IDE上での補完に頼りたければ、多少長くなっても型を明記

  --Implicit Assertionの使い方に注意
    if文を使う場合はassertをいれないとスルーされちゃう

  --PageObjectの作り方に注意
  getter/setterを作らなくても動かせるので、ついつい生の処理を書いてしまいがち
  PageObjectの意味がなくなってしまう


-失敗時のスクリーンショットの取得
  Spockのリスナ機能をつかう

-TestSuiteの動的生成ができる
  Jenkinsで実行したときだけテストが失敗するみたいな場合に対応できる
  失敗したケースだけを修正前後にさくっと実行したりできる
  Jenkinにパラメータで%Test_CLASS%を置換


3.Q&A

  3-1.各種情報はどうやって手にいれてる?
    →Gebの知識はどこで手に入れる?→公式サイト
     SpockとGroovyは都度検索していた

  3-2.IDEはなにつかってますか?
    →IntelliJ使ってる

  3-3.xpathはGEBではサポートしていないけどどうしてますか?
    →ほぼ同等の記述をすることができる

  3-4.Gebで実現できないことがあった場合、JavaのWebDriverを同時に使ったりできるか?
    →たぶんできると思う


●【伊藤望さん】海外のSeleniumカンファレンスではどんな発表がされているのか2014

Seleniumカンファレンスでどんなテーマで発表されているかを紹介してくださいました。


Selenium Conferenceとは?
2011年から毎年開催

今年はインド

1.9/14 ワークショップDay
2.9/15~16 セッションDay

定員:425名
参加費 5000~25000ルピー


セッション紹介
1.テストインフラ
  -Selenium Gridのスケーリングと管理
    Grouponのエンジニア
    Selenium Git Extras
  -WebDriverでウェブプラットフォームをテストする
    Test the Web Forward
  -SeleniumとJoomlaオープンソース

2.Seleniumセッション
  -Javascript界のWebDriver
  -取り込みと拡張:Seleniumプロジェクトはどうやって世界最大のクローズド・ソース企業を参画させたか
   時期バージョンのIEの機能を試用できる
  -GebでよりよいSeleniumテスト


3.モバイルセッション
  -Seleniumテストをクラウド上
  -Appiumとモバイル


4.セキュリティ
  -機能テストで、アプリケーションからハッカーを守る
   IronWASP
   -インジェクション攻撃をSeleniumでテスト

5.ページオブジェクトパターン
  -Page Objectを超えるデザインパターン:Page Object 構築時に使われるデザインパターンの探求
  -Page Object パターンの危機
  -Page Objectをきちんとやる

6.マイグレーション
  -正しいテストピラミッドを達成するためのSeleniumデトックス
  -Salesforceはいかにして3万5千のテストケースを移動したか
  -ケーススタディ -QTP/UFTからSleniumへの移行 - 80%の実行時間の削減

7.その他
  -Allureフレームワークのサポート

他にもいろいろ紹介されていました



●ハイパフォーマンスseleniumテスト@サイボウズ

サイボウズのkintoneチームの開発エンジニアの宮田さんから
チームでどうやってテストを作成しているかの事例をお話しいただきました。

まず

以前一度テストを作成したがメンテされなくなったこと
そのあと、自発的に継続的デリバリーの勉強会や実践アジャイルテストなどの勉強会が開かれ
テストが必要であると開発者自らが認識して取組をはじめたことなどを話しておられました。


-テストを安定させるために1マシンで1実行させている
-テストを並列実行させている(たしか36並列とか)
-テストの実行時間が長くなるのを避けるために最低限を受け入れテストを作成してコンパクトにしている


とのこと




  モバイルアプリは
  mvcなどで切り分けが難しい

  sdk+専用ビルドを作る手法があるが
  リリースビルドでのテストもある程度必要となる
  実際リリースビルドでは画面崩れないが専用ビルドでは問題ない問題などがあった


appiumのよいところ

  リリースビルドに対してテストしやすいのがアピウムでそこが良い
  多彩なツールを組み合わせられる

あまりよくないところ

  実行に時間がかかる
  実例が少ない
  環境構築が手間

クックパッド松尾さんの事例

  アンドロイド、iOSアプリのテスト1人でしてる
  ネイティヴアプリ
  二週間でストアにアップ
  エンジニア数人、多くて五人
  UIが変わったりする

   企画→開発→検証の全フェーズで使っている
   帰社後テスト実行し、翌朝スクリーンショット結果確認

  画面遷移とレイアウト崩れのチェック
  100ケース程度
  並列せずに一時間


  変化への追従ができるように意識している
    シナリオ 
    実装コード
    ラッパー
    UI

    rspecたたく 
    Turnipが実行
    ラッパーで、スリープいれたりしてる

  シナリオの統合、書き換えなども定期的にやっている

  人に任せるとこは人がやる

  アピウムiOS8対応大変
  今後はアンドロイドのシナリオの充実させたいとのこと
  評価体制のスケールもさせたい


次の記事
« Prev Post
前の記事
Next Post »
Related Posts Plugin for WordPress, Blogger...