日本Seleniumユーザーコミュニティ勉強会 に参加してきました
1/18(土) に品川の渋谷のサイバーエージェントさんで開催された「日本Seleniumユーザーコミュニティ勉強会」に参加してきました。
イベントの詳細はこちら。
http://kokucheese.com/event/index/117476/
登壇者と発表内容はこんな感じです。
[本編]
- Selenium, Appium & robots by Jason Huggins
[LT]
Selenium, Appium & robots
Seleniumの話（少しだけでした）
Javascriptがヘビーに使われているAJAXが普及し始めたころに「テストがしづらい」という理由で作った。だんだんと広まってきており、現在では競合ツールであるQTP (Quick Test Professional/Functional Test)を上回っている。
Appiumの話
Appiumはモバイル向けのテスト自動実行ツール。iOS/Androidのクロスプラットフォームをサポートしていて、1つのテストを複数のプラットフォーム上で実行できる。また、複数言語をサポートしているのでJavaでもRubyでもPythonでも好きなプログラム言語でテストができる。HagginsさんはPythonをよく使っているらしい。
Appiumの哲学・ルール
- Test the same app you submit to the marketplace
- Write your tests in any language, using any framework
- Use a standard automation specification and API
- Build a large and thriving open-source community effort
AppiumはHTTP Serverとして動作し
- [Appium向けに書かれたテストスクリプト]←→[Appium]←→[モバイルアプリ]
という感じで間に入ってテストスクリプトに基づいてモバイルアプリを動作させてテストを実行する。
（めっちゃわかりやすい画像があったので、Hagginsさんの資料がアップされたら更新します）
ここで、モバイルアプリ向けのテストデモ（動画）がありました。ログイン機能についてのテストをAppiumで実行するというもので、複雑な動作でなければ十分に使えそうな雰囲気でした。一休だったら例えば、「検索→ログイン→予約までをAppiumで実行する」みたいなこともできるんじゃないかなと思いました。
robotの話
「Seleniumはテストを実行するロボットのようなもの」とHagginsさんは話しており、ホントのロボットも作っているそうです。「メカニカルエンジニアリング？」って話していました。
"angry bird"をテストするロボット（実際にタッチペンを動かしてアプリを操作する物理的なロボット）のデモがありました。（多分ここが一番Hagginsさんのテンションが高かったような気が、、、）
この後、Q&Aの時間だったのですが同時並行でココナラの案件対応（急務）が入ってしまい、メモがとれませんでした。。。他の方のブログ内容を拾えればアップデートするかもしれません。最後の方の「SeleniumとCIを連携させる際のポイント」は聞いていたのですが、「エラーが発生した際にはスクリーンショットを撮り、CIのレポートでスクリーンショットを確認できるようにした方が良い」とアドバイスをされていました。
ノンプログラマのためのSelenium DDTはじめの一歩 by 浦山 さつきさん
テスト自動化の第一歩として、「データ駆動テスト」についてデモを交えながら説明をされていました。
という流れだったと思います。「簡単に始めて、それを育てていった方がうまくいくよ」というお話。その通りだと思いました。
現場でのSelenium活用事例(仮) by 大田尾 一作さん
エンプラ系現場でもSeleniumを活用してみたよ、というお話。テストスクリプトは仕様変更や機能追加によって動かなくなる（テストが壊れる）ので保守にも時間（工数）がかかることをしっかり認識しておくべき。繰り返し実行するテストは繰り返しの回数と頻度によっては継続的に利用することで初期のコストを回収できる。また、デグレを発見できたり、属人性が排除されたりといった良い副作用も見られた。効果が見られたケースでは手動テストと比較して約40%程度のコストを削減できた。ここでも「一部分から始めてみる」ということをお話されていました。
Jenkins×Selenium 最初の一歩 by 玉川 紘子さん
テストの会社「SHIFT」の玉川さんのお話。12月に行われたJenkinsの勉強会でもお話をされていた方です。「Seleniumが使えるようになったらJenkinsと連携してCIにSeleniumのテストを組み込んでみよう」というお話。
- seleniumhq plugin
- seleniumhtmlreport plugin
という2つのメジャーなプラグインを利用して、テストスイートを指定すればCI実行時にデプロイした環境に対してSeleniumのテストスイートを実行できる。レポートも確認できる。
SeleniumとCIを連携させる際のポイント
- テスト環境はなるべく専用のものを用意する
- データ初期化の仕組みを作る
- ジョブは機能カテゴリごとに小分けにして作る
- スクリーンショットをとる
やはり、CIのジョブは小さく分けた方が扱いやすいようです。また、ここでもHagginsさんのアドバイスと同じく、スクリーンショットを撮るというお話した出てきています。また、Twitterで@okitanさんに教えていただいたのですが、「エラー時のURLを一緒にとっておくと良い」らしいです。確かにエラーが発生した際のURL（getパラメータとかも含めて）があればローカルでの再現も比較的容易にできそうですよね。
Selenese Runnerができるまで(仮) by 岩室 元典さん
Selenese RunnerというSeleniumが読み書きする"selenese"というスクリプトを直接実行するツールのお話。Web Driverベースでクロスブラウザに対応するテストを実行できるし、ログもちゃんと出せるようになっている。また、テスト箇所のハイライトなどもできるし、スクリーンショットも撮れる。岩室さん曰く、「Selenium RCの代替」とのこと。
発表資料はコチラ
http://vmi.jp/software/selenium/StudyingSelenium-01/SeleneseRunner-20140118.html#1
Seleniumと相性がいいテンプレートエンジンMixer @nabedge さん
Mixerというテンプレートエンジンを使えば、Seleniumを使いやすい形でコードとViewを分離できるよ、というお話。
総括
一休でも一部分でSeleniumを使用してテストを実行していますが、主要機能のみでカバレッジが低いのが現状です。機能の重要度に応じて手動実行する部分と自動化する部分の精査は必要ですが、基本的には自動化するというスタンスでいた方がデプロイ毎にテストを実行できるので中長期的に見たら価値があることなのだと再認識できました。LTで玉川さんがお話されていた「CIとの連携」はまだできていないので、こちらも導入を進めていけばデプロイ後のテスト自動化も価値が高まっていく、そう感じました。
また、本編でHagginsさんが紹介していたAppiumですがスマートフォン向けのアプリもテストを自動化する流れが進んでいくと思うのでAppiumも導入を検討した方が良いと感じました。
やりたいことがさらに盛りだくさんになった土曜日でした。
