2014年10月18日、渋谷マークシティ サイバーエージェントセミナールームにて日本Seleniumユーザーコミュニティ主催による、「⁠第2回日本Seleniumユーザーコミュニティ勉強会」が開催されました。今回開催のきっかけにもなった、日本初の本格Selenium書籍『実践Selenium WebDriver』の著者、翻訳者である玉川竜司氏・玉川紘子氏はもちろん、SeleniumやAppiumを実際に利用している開発者たちも登壇し、盛りだくさんのセッションが繰り広げられました。ここではその様子を紹介します。

Seleniumをもっと知るための本の話（玉川竜司氏）

「実践Selenium WebDriver」ができるまで

2006年から、自社のWebアプリの回帰テストにSeleniumを使用していましたが、そのときはうまくいきませんでした。その後、またWebのテストを行うことになったのですが、Seleniumの情報をネット上で調べると、Selenium 1とSelenium 2の情報が混在しており、全体像が見えず非常にわかりづらい状況でした。ちょうどその頃、2014年1月に今回の本の原書が出ました。この本が非常に良い出来の本で、日本語の書籍に対する需要があると自分でもわかっていたので、今回の企画が立ち上がりました。

また、ちょうど原書が発売されたタイミングで第1回目の日本Seleniumユーザーコミュニティ勉強会が行われており、勉強会の玉川紘子氏のライトニングトークの内容がこの原書に欠けている内容だったため、玉川紘子氏に「W（ダブル）玉川本を出しませんか？（笑⁠）⁠」と声をかけてJenkins×Seleniumの部分を埋めていただき、今回の本が誕生しました。

英語の技術書を読む話

英語の本は、日本語の本と比較にならないほど多いのですが、それらを日本語に翻訳する、執筆者・翻訳者の数も潤沢ではありません。技術書を買ってくれる人も英語の本と比べると少ないです。この状況は加速していて、日本語の技術書は今後減ってくるのではないでしょうか。売れるものを翻訳せざるを得ないので基本的な内容の本が多くなり、とがった内容は英語の本を読むしかないので、頑張って読みましょう。

しかし、何も知らない状態では英語にあたるのはキツイので、まず日本語の本である程度概要を理解してから英語の本に取り掛かれば、難易度は多少下がるのではないかと思います。今後も翻訳本は出てくると思いますが、英語の資料を当たるという習慣をできれば皆さんにつけていただきたいです（会社の若いメンバーにもそのように指導しています⁠）⁠。

技術英語の勉強法において、よくある勘違いとして「映画のDVDで勉強」というのがありますが、スラングもあり大変です。英語の技術書は、英語へのチャレンジとしてはもっとも楽なチャレンジです。

お勧めを2つ紹介します。

• Kindle（言わずと知れたkindleです）
• Safari（年会費で書籍が読み放題、なぜ日本では知名度が低いのか謎です）

Q＆A

Q：電子版の発売は？

A：予定は今のところはないです。

Q：企画が通りそうな売上数は？

A：（言っていいのかな？と焦りながら）ウン千冊。今回の書籍のAmazonランキングはかなり良いほうです。

Q：どうして翻訳業を？翻訳期間は？自分もしてみたいんだがどうすればよいでしょうか？

A：Silverlightの翻訳本についてオライリー・ジャパンに問い合わせたのが始まりです。年間3～4冊ほど翻訳をしていますが、作業は地味でけっしてもうかる仕事ではないので、あまりお勧めはできないが、やるならば目的をしっかりと見据えてやりましょう！！

Q：翻訳をしてWebで得られない知識はありましたか？

A：英語圏では自分が作成したオープンソースソフトウェアについて書籍を書くことが多いため、英語圏の本には作成者しか知りえない情報が詰まっています。

じゃんけん大会

講演の後じゃんけん大会があり、5名の方に今回翻訳された書籍がプレゼントされました。休憩中には即席のサイン会のようなことも行われ、和やかな空気でした。

脱・独自改造！GebでWebDriverをもっとシンプルに（玉川紘子氏）

『実践Selenium WebDriver』で付録でJenkins × Seleniumの部分を担当していますが、第1回の勉強会でJenkinsの話をしたので、今回はGeb（読み方は“⁠じぇぶ⁠”⁠、Groovyで動くWebDriverのラッパ）のお話をします。

WebDriverはそのまま使用するのはハードルが高く、ちょっとした処理でも行数が増えてしまいがちです。ほとんどの人が独自にラッパを作成しているのが現状かと思います。

そんなあるある感を、オープンソースで公開されている、より便利なツールを使って、独自改造をやめてみんなで幸せになろうというお話です。

Gebで便利になる点

Gebで便利になることとして、以下の点などが挙げられます。

• コード量が少なくてすっきりする
• jQueryライクでわかりやすい※
• データ駆動や強力なアサートの機能がある
• これまで自社で作成してきたJavaライブラリの資産が使える

※）

フロントのデザイナにどこをテストしているのか伝えやすいという利点もあります。
例）assert $("h1").text() == "Please Login"

Gebを使う際の注意点

Gebを使う際の注意点として、以下があります。

• Syntaxの省略に注意。省略は便利だが型をきちんと書いていないミスにつながる場合もある。IDE（Integrated Development Environment：統合開発環境）上の補完に頼りたければ型を書いたほうがベター
• Implicit Assertionの使い方に注意しなければ思わぬところでエラーを出すこともある（ifの中にassertを書くとエラーも出ず素通りしてしまった）
• PageObjectに生の処理を書いてしまいがちだが、それをしては意味がなくなってしまう

利点はとにかくコードがシンプルになることなので、お勧めです。

Q＆A

Q：GroovyやGebの勉強方法は？

A：英語ですが、Gebの公式サイトに『Book of Geb』というマニュアルがあるため、体系的に学ぶことができてお勧めです。Groovyはやりたいことが増えるたびに調べています。

Q：jQueryのセレクタが全部使えますか？

A：似ているだけで、すべてが使えるわけではないです。

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

日本Seleniumユーザーコミュニティ主宰の伊藤望氏からは、Seleniumカンファレンス2014の内容についての紹介がありました。

• 2011年から毎年やっている
• 世界中からSelenium開発者・ユーザが集まる
• 3日間にわたるセッション＆ワークショップ

続いて各セッションについての紹介があったのですが、とてもすべてを書ききれないので、3つ抜粋して紹介します。

正しいテストピラミッドを実現するためのSeleniumデトックス

単体テストでできるものは単体テストできちんとやろう。そのほうが保守コストも安くすむ

Allureフレームワーク- 水晶のようにクリアなSeleniumテスト結果レポート（どんな言語でも使える）

リッチなテスト結果レポートを出力できる。スクリーンショットなども表示できる

Seleniumプロジェクト取込みと拡張：Seleniumプロジェクトはどうやって世界最大のクローズドソース企業を参画させたか

MicrosoftをSeleniumプロジェクトに参加させるまでの話。スライドがないが、WebDriverの機能が次期Internet Explorerからは取り込まれるもよう。

まとめとして、良い発表が多かったので、スライドがなく動画のみの発表も今後頑張って内容を把握していくとのことでした。

次に事例紹介セッションになります。Seleniumの活用事例情報はまだまだ少ないため、ここからを楽しみにしてきた方も多いのではないでしょうか？

ハイパフォーマンスSeleniumテスト＠サイボウズ（宮田淳平氏）

サイボウズの宮田淳平氏より、kintoneの開発でSeleniumをどのように使用しているか？パフォーマンスをあげるためにどのような対策を採ったかについて発表がありました。

Seleniumテストの問題点

Seleniumはブラウザを使用してネットワーク経由でテストを行うため、実行時間がどうしても長くなります。kintoneでは、Gitのメインブランチにマージされるたびに、すべてのSeleniumテストが実行されます。たとえばこのテストが1時間かかった場合、混雑している状態ですと問題が発生してしまいます。現在は実行時間30分ほどで一応回ってはいるが、コミットが集中する時期だとやはり混雑してしまうので、理想で言えば20分に抑えたいとのことです。

問題の解決策

その解決策として挙げられていたのは、余計なテストを極力作らず、Seleniumテストを本当にコアな部分のメインシナリオのみに絞って行うことです。パフォーマンスが悪く時間のかかるテストだと1日に何度も実行できません。いつでも何度でもすばやくテストを実行できるのがテスト自動化の利点であり、自動テストが開発のボトルネックになってしまうことは避けなければなりません。余計なテストを作らないためには、単体テストでしっかりカバーを行うのが良いとのことでした。

次の解決策として挙げられていたのは、SeleniumGridを使用した並列化です。並列化を行う場合、ブラウザは1マシンに1つにするのが良いとのことです。複数起動も可能ですが、フォーカスの関係などでうまく動かないことが多いとのことです。

並列実行環境の構築方法

クラウドサービスの利用

Sauce Labs、TestingBot、BrowserStackなど、予算があれば一番お勧めです。あらゆる実行環境に加え、実行録画機能などもあります。Sauce Labsのサービスはフリーで試してよさそうだったのですが、想定よりも費用が高かったのであきらめました。各サービスの比較表を誰か詳しい人が書いてくれるとうれしいです。

VM

クラウドサービスをあきらめた場合、自分たちでマシンを用意する必要があります。最初に思いつくのはやはりVMです。kintoneチームではVM（Virtual Machine、仮想マシン）テンプレートを作って量産を行っています。テンプレートを使えばある程度環境を量産できますが、環境を作り直したり設定を変えるなどの作業を行うと途端に手間がかかるようになります。マシンリソースも、ある程度ブラウザテストができるマシンとなると、それなりのスペックが必要となり大変です。

Docker

Dockerは高速デプロイでき、かつ軽量です。ただし環境はLinuxだけなのでChromeとFirefoxのみに限られてしまい、Internet Explorerのテストはできません。次期バージョンのWindowsではDockerが対応するようなので期待をしています。

並列実行について

並列実行を行った際、以下の点に注意し、必要であれば改善していく必要があるとのことでした。

• （全テストの実行時間の合計）÷（並列実行時間）＝（並列数）となっていれば理想
• 実際の並列数より極端に小さい値のときは改善余地がある
• 時間の長いテストケースを最初に実行できれば理想値に近づく。それにはテストランナーに手を加える必要があるかもしれない

個々のテストの高速化

テストの高速化については、実行時間の長いテストは普段からわかるようにしておき、極端に長いテストは改善したほうが良いとのことです。また、多くのテストで共通の処理で時間がかかっているところは改善していく価値がある（初期データの作成、ブラウザ起動、認証処理など）ところです。

初期データの作成

初期データを作成する方法はいくつかありますが、ブラウザ操作を使うと不安定になるし、DBダンプを使うとスキーマ更新時にメンテナンスの手間が発生します。APIを使う方法ならばそこそこ速いので、環境が整っているのであれば一番お勧めです。

安定性

宮田氏のチームでは、リトライを3回まで行い、ネットワークの問題などで失敗した場合でも救済されるようにしている。リトライされたテストはどこかに不安定な部分がある可能性が多いので、わかるようにして後で直すと良いとのことです。また、findElementなどは不安定に失敗することがあるので、条件付きのWaitを使うようにしているとのことです。

メンテナンス性

メンテナンス性が低いと、手動テストのほうがよいのではないかというネガティブな意見が現場から出てくることになります、また、メンテナンス性が低いことによって、徐々に自動テストが困難になっていき、実際チーム内でも一度メンテナンス不能になってしまったことがあるとのことでした。

メンテナンス性を上げるために必要なこととして以下の点を挙げていました。

• PageObjectパターンの利用。UI（User Interface）変更があるならば必須
• 失敗時のスクリーンショットの記録、録画などで原因調査が楽になる
• テストコードにも規約を作ることが重要。レビューも行う

まとめ

• Seleniumテストの運用はパフォーマンスとの戦い
• 自動化するテストは重要なものに絞る
• 実行時間短縮は並列化してその効果を最大限まで活かしきるのが一番効果的
• 安定性やメンテナンス性も大事

Seleniumの事例は少ないので今回は発表しようと思いました。今後もこういう事例がたくさん発表されるとうれしいとのことでした。

Q＆A

Q：どうやってチームでテストを書く運用を整えたのですか？

A：一時、WebDriverテストがメンテナンス不能状態になりました。『⁠継続的デリバリー』の社内勉強会を実施し、CI（Continuous Integration、継続的インテグレーション）の重要性を再認識しました。

Q：Seleniumテストの録画はどうやって実現しているのですか？

A：vnc2flvというPythonのライブラリを使用し実施しています。テストが失敗したときのみ保存を行います。

宮田氏の発表時のブログではQ＆Aの補足もされていますので、より詳しく内容を知ることができます。

クックパッドアプリの開発を支援するAppiumの話し（松尾和昭氏）

クックパッドでテストエンジニアとして活動している松尾氏、今回はSelenium勉強会ということもありAppiumの話で大丈夫かと思ったが、そんなことはまったくなかったので一安心している、と冒頭に述べたあと、今回の発表の経緯について、「⁠Appiumに関するブログ記事を書いたら、声をかけられた」と述べられました。

Appiumを使うまでの経緯

Appiumは、モバイルアプリのテストを自動化できるツールです。Webを飛ばしてモバイルアプリと言う流れは、世界的な流れとして一気に来ており、クックパッドでも、モバイルファーストということでモバイルに力を入れています。モバイルのテストにはAppiumを使ってみることにしました。

リリースビルドをテストする

描画テストを実行する場合、SDK＋専用ビルドで行っていたが、これはリリースビルドとは別物で、追加でリリースビルドの動作確認もしなければいけませんでした。デバッグ用のSDKを内蔵して作ったビルドで、UIが崩れるという事象も起きていました。Appiumを使えば、リリースビルドに対し、OSの提供するテストフレームワークを使用してテストを行えるようになります。

Appiumの良い点

松尾氏は、Appiumの良い点として以下を挙げました。

• リリースビルドをテストできる
• 他のさまざまなツールとの組み合わせが可能
• OSの変化に追従しやすそう

Appiumのあまり良くない点

逆にAppiumのあまり良くない点は以下を挙げていました。

• 実例がない。今も開発が活発で変化が激しく、エラーに対処するために自分たちで修正が必要なこともある
• 実行に時間がかかる。UIからアプリを操作する点はSeleniumと同じで、工夫が必要
• 環境構築に手間がかかり、社内に広めるきっかけの妨げになっている

クックパッドにおける活用事例

クックパッドでは、Appiumを開発の全フェーズで使っており、帰り際にテストを動かして翌朝結果を見ているとのことです。主な確認項目は、画面遷移とレイアウト崩れ（スクリーンショットで確認）を中心に、1capabilityあたり100テストケース、テスト時間は1時間とのことでした。

工夫

Appiumを利用する際の工夫として以下の点を挙げていました。

• Appiumはまだ開発が活発にされているため、変化への追従が大事
• Appium側の修正によってテストシナリオを修正する必要がないよう、テストシナリオとAppiumによる具体的なテスト実装を、ラッパを作って分離している

どんなテストをAppiumにまかせるか？

どのようなテストをAppiumにまかせるのがよいかについては、以下の点を挙げていました。

• 機械が実行可能なタスクは機械に任せる
• 人間が忘れがちなシナリオは機械に任せる
• 人間は、機械が実施していない領域を探索的にテストする

これまでの成果と課題について

Appiumでモバイルアプリの自動テストを実行するようになって、バグをこれまでよりつぶせるようになったからか、お客様からの問い合わせが減ってきています。非常に便利なツールですが、iOS 8対応や、自動テストでカバーできる範囲は限られているので、評価体制をスケールすることなどが今後の課題としてあります。

Q＆A

Q：テストは実機で行っているのですか？

A：実機は手間がかかるので、すべてシミュレータで行っています。

以上、駆け足ながら「第2回日本Seleniumユーザーコミュニティ勉強会」の紹介でした。書籍発売や大手Web企業による活用事例の発表など、日本でもSeleniumが着実に普及してきたように感じます。まだ使っていないという方は、この機会にSelenium、Appiumにトライしてみてはいかがでしょうか。