「第1回 日本Seleniumユーザーコミュニティ勉強会」参加メモ

1月18日 第1回 日本Seleniumユーザーコミュニティ勉強会(東京都) に参加してきたので、そのメモです。

コミュニティ開催のごあいさつ: TRIDENT 伊藤望さん

日本Seleniumユーザーコミュニティは半年ほどで現在のメンバー 200弱。 海外だと 14000 超えるユーザーグループが。

今日の参加者アンケートでは、 - WebDriver, Selenium IDE, WebDriver と Selenium IDE 両方を使ってる、という人が 1/3ずつくらい - WebDriver 書くのに使ってる言語は Java が圧倒的に多い

招待セッション: Selenium Co-Founder/SauceLabs Jason Huggins さん (通訳付き)

ほんとは去年の 11 月に来るはずだったのが延期になって申し訳ない。でも、イイ言い訳があるんだ。HealthcareGov.com の問題対応のため、ワシントンDCに缶詰にされてた。おかげで何とかなったので、オバマも君たちに感謝してるよ :)

Selenium について

2004 年当時、Gmail とか GApps とか AJAX が出始める直前、JavaScript 安全で使えるよ!となってきた時代に Selenium 作った。「テストしてくれるロボット」だと人には説明してきた。 "FOXX" という、パソコンの前に座って操作してるロボット画像をたとえに使ってるんだけど、画像の出自が分からなくなってしまった。関係者いたら教えてね。

Job Trend の推移では、QTP (現在の UFT) を逆転。 そもそも Selenium という名前はジョークで、当時 QTP 作ってたのが Mercury (=水銀) で、化学物質 Selen は Mercury Poisoning (=水銀中毒)を緩和するというところから来てる。実際、できてるね :)

Appium について

2004年当時は Web といえば基本的にデスクトップPCだった。2007年に iPhone、 2008年に Android が出て、どんどん Mobile が増え、無視できないものになった。 Appium はもともと大企業向けに作った、モバイルテスト用のフレームワーク。去年オープンソース

Appium の方針: - marketplace に出すものと同じアプリをテストする - 言語、フレームワークにとらわれない - standard automation spec = Selenium API - open-source community effort

ちなみに、W3C で WebDriver をデファクトとして標準化しようと進めている理由は、クロスプラットフォームなテストのために余計なコード書かなくていいようにするため。標準化することで、ブラウザごとの差異の解決をブラウザーベンダーのしごとにしたい。

Appium は HTTPサーバである。テストクライアント = WebDriver では HTTP でやりとりする。 iOS では、 Appiumは UIAutomation in Instruments とやりとりする Proxy である。 Android では同様に、 UiAutomator とやりとりする。

デモ

ライブデモは危険なので動画でやるよ :) - デモ1: Appium デモ (テスト実行するコンソールと、Appium が走ってるコンソールと、対象デバイスのエミュレータ) - デモ2: HealthcareGov.com での一幕 -- 政府の CTO と言われる人が議会での証言で、サイトを画面で見せているが、アカウント作成ボタンが動かないw → その日のうちに修正される こんなことがないようにテストしようと思ったという

Appium の使い方: Appium に対象アプリを教える方法: zip が置いてある appUrl を渡す Selenium と同様、 desired capability をセットして、WebDriver セッションを開始して、テストコメンドを実行する

ロボットについて

文字通りのロボット。スタイラス持たせたアームを動かしてスマホタブレットの画面さわるようなもの。 (このコーナーが、 Jason さん一番イキイキしてたように見えましたw)

2011年: レーザーカットした、レゴ互換の部品で作った (実際一部レゴの部品も使ってる) 2012年: スイスの delta アーム?的な技術採用、高速化 (ゲーム操作させようと思ったらスピードないとダメだよね :) 2013年: 3Dプリンタ製にバージョンアップ。けっこうスゴいって言ってもらえるんだけど、日本の税関で見せたときは何このプラスチック?みたいなリアクションだった :)

新しいものが出てくるとテスト、特に自動化されたテストを作るのはムズカシイ。 実際、モバイルに対しても Appium のようなものが出てくるまで時間かかった。 手動テストでやってることそのものができれば、新しいものにも対応できる。

手動テスターは手と目を使う。今のロボットはまだ手しかないので道半ば。 最終的には Selenium や Appium でロボット動かしてテストできるようにしたいと思ってる。今の API はまだだいぶローレベル。 「ここにいけ」という人間的な指示をロボット的に表現しようと思うと、全部角度や距離で表現しないといけない = ムツカシイ言葉でいうと inverse kinematics

デモ

(座標とか角度とかハードコードしたコマンドらしきものをコンソールにコピペして順番に実行、Angry Bird を操作させる)

SauceLabs 社について

営業じゃないよ、と前置きしつつ :)

SauceLabs は大量のテストをクロスプラットフォームでメンテするためのサービスを提供してる。 以前 Google では、2, 3人のチームで 「Selenium ファーム」をメンテしていた。 そのままテスト増やすとテストの数だけ時間がかかってしまうのを、複数マシンに分散させる。 SauceLabs 使わなくても Selenium Grid 使えばできるようにはなってるよ。

質疑応答

Q: たとえば Chrome など、ブラウザの変更にどうついていく体制なのか?

A: (WebDriver の W3C 標準化の話でも言ったように) ブラウザの対応はブラウザベンダーにまかせる方向。Selenium コミッターが責任もたなくていいように。 Chrome だったら Google に文句がいくようにw

Q: Seleinum3 はいつでるの?

A: http://code.google.com/p/selenium/wiki/ShippingSelenium3 などウォッチしといて

Q: Appium は Selenium 3 に含まれていく?

A: Selenium3 は Proxy の集合みたいになっていく(?)

Q: RC とか中身的には実際はどうなっていく?

A: JS も残っていくとは思う。(JSによる) emulation ではなく実際の動き = native event に近いほうがよい。とはいえ、使えない場合のフォールバックとして残す必要はあるだろう

Q: Selenium3 の新機能?

A: (Web テスト向けに)特にメジャーな変更はない。機能を関連させるのではなくプロトコルの共通化を重視したい。モバイル独自の API は追加される

Q: ジェブ?という groovy の Selenium ラッパー的なもの使ってる、IE 遅いのとかどうにかならないか

A: 基本原則はマシン増やすこと。Selenium 外のことはどうにもならないが、 HTTP プロトコルは改善の余地あり、 SPDY、protocol buffer とか。

Q: いろんな Selenium (IDE とか Builder とか)はどうなっていくのか (だったか。質問ちょっと聞き逃し)

A: それぞれコミュニティとして残っていく。ただ IDEFirefox しばりであり、Selenium1 と同じ問題に直面している。 Selenium Builder は ブラウザ固有の実装を極力少なくしようとしている。 仕組みとしては Builder のほうがいいが、今は IDEのほうが機能が豊富な状態。 記録再生ツールの倫理、という点では、プロトタイプ作るにはいいが、作ったケースはすぐに Java などのプログラムにエクスポートすべき(というのは Selenium コミッター的な意見)。 とはいえ、記録再生ツールをベースにテストしたい人も多いので、Selenium プロジェクト内でどう位置づけていくかは不透明でもある。 Builder は undo とかもできないが、よりよいものにすることにはコミットしていく。

Q: Appium、日本語とかモバイルのキーボード使って入力するのが難しい、テキスト直接いれられる?

A: 入れられる。デモでは見栄えがいいのでキーボードで入れる版を見せている :)

Q: Selenium の発音?

A: 元素記号のこというときは セリーニアムっていうけどアメリカでそれいうとイギリス人ぽい :) (結局、「セレニアム」って感じの発音が正しい感じ?)

Q: テストの分析や設計といったところの自動化は対象としない?

A: Selenium はテストの実行に特化している。結果出力なども別。テスト実行だけでも、いろいろなプラットフォーム対応などたくさん仕事があるので、それにスコープを絞っている

Q: Jenkins との関係とか?

A: 前の質問と関連で、結果出力などは Jenkins 使うといい。JUnit, TestNG などの形式とからめて。 スクリーンショットをとるのは大事、最初は結果を信じたくないと思うからね :) それで JUnit で結果をみるとよい。ケースで失敗したときや、ポイントごとでスクショとる。GIFアニメとして見るのもよい。テキストだけじゃなくビジュアル情報も大事。

Q: モバイルのテスト作るのもうちょっと楽にできないか?

A: iOS 用には Appium Inspector というのがある。エレメントを調べたりとかできる。 Android 向けにはまだなので、興味があれば参加してね :)

ライトニングトーク

LT1: 浦山さつき さん

  • マニュアルテスター向けの自動化入門
  • 手動テストが当たり前のテスト部門には自動化導入するハードル高い
  • デモ: Excelマクロによる、入力データと確認結果の組み合わせでIDE用のケース生成=データドリブンテストという位置づけ
  • TABOK の Test Automation Framework の定義でいうとデータドリブンテストは レベル2 とされている

LT2: 大田尾一作さん

  • エンタープライズ向け活用事例
  • 2006年 Selenium 0.7 の頃から使ってます/記事書いてる
  • テスト作成・保守大変 → データ駆動(画面項目を自動取得、コマンドひとつでそのテスト読み込む)・スクショ1行で・DB作成
  • IE 複数バージョン対応、ただし工数は削減されず、初期実行時のみ不具合あったり課題も
  • オフショア受け入れ、工数は 40%削減、ただしポップアップやセッション制御で苦労
  • ERPが生成したHTMLは input タグに name がなく、IDも都度変わる、カスタマイズする時間なく適用見送り
  • 工数は数10%から2倍ほど初期コストかかるので長期での回収を見込む
  • 部分適用でも意味ある

LT3: 玉川紘子さん

  • Selenium & Jenkins
  • seleniumhq plugin: IDE で作成したHTMLのテストを実行
  • selniumhtmlreport plugin: 結果表示(特に複数)
  • Selenium plugin: Grid 実行サポート(ノード起動&ブラウザ設定)
  • Tips -- 専用環境、データ初期化の仕組み、機能カテゴリごとのジョブ、失敗解析のためのスクショ

LT4: 岩室元典さん

  • Selenese Runner
  • RC ベースだとバージョンアップで急に動かなくなったり、ログが足りなかったり。かといってWebDriver にしちゃうと IDE に戻せなくてメンテできる人限られるなど。
  • WebDriver 指定、ロギング、スクショ、結果出力(JUnit 形式 or HTML)、条件分岐機能追加等
  • FF, Chrome, Safari, phantomJS, HTMLUnit に対応
  • 実行時、操作中のエレメントをハイライト

LT5: わたなべさん (飛び入り)

  • Mixer2 というテンプレエンジン作ってる
  • Mixer2 使うと Selenium に親切なHTML(ID が必ずあるとか)が生成される
  • テストケース記述も Mixer2 方式で書けるので、開発とテストで同じ書き方できる

個人的な感想など

  • WebDriver が W3C 標準になろうとしてる理由が、ブラウザごとの差異をテスト作る側が気にしなくていいようにするため、というのはとても腑に落ちた
  • Jason さんは Selenium RC 捨てて WebDriver に移行すべき、って言ってたけど、ライトニングトークでは IDE や RC ベースのテスト実行の話があったりするあたり、まだギャップがあるのかなと感じた。実際、僕のいる会社でも WebDriver ベースでごりごりプログラムとしてテストケース作ってるのはまだ少数だし
  • なんでロボット?って思ってたけど、 Jason Huggins さんがロボット大好きだから、というのがよく分かったw それは別としても、新しいデバイスとか出てきた時、結局人間ができることができるようになってれば対応が出来るというのは極論だけどそうかもなーと思った。しかし、Google Glass とか、 iWatch (仮) みたいなものが出てきたらどうテストするんだろうなーとか思ったりした