Jenkins, Seleniumを使った自動テストの課題とこれからの取り組み

このエントリーをはてなブックマークに追加
こんにちは。QAの井上です。

今回は現在QAチームで行っている自動テストに関する課題、それに対する取り組みについて紹介します。
まだまだ詰めが甘いところがあると思うで、フィードバックいただけるとうれしいです。


早速ですが、QAチームではCIツールにJenkinsを使用していて、約8割がSeleniumによるテストケースでできています。
テストケースの作成から実行まではざっくりですが、以下のようになっています。

- テストケースはFirefoxのIDEを使用して作成
- 作成したテストケースはSVNに保存
- 毎日夜中に最新のソースコードに対してテストを実施
- テストの実施は、Jenkinsのseleniumhqプラグインを使用して、複数台のクライアント(Windows)上でSeleniumRCサーバーに直接テストスイートを渡すことで行う
- テストで使うクライアントはWindowsでブラウザはFirefox
- テスト結果を次の日に確認


テスト実行の流れを図にするとこのようになります。
基本的にSeleniumRCのマニュアルに書いてあることと同じなのですが、SeleniumRCサーバーがテストスイートを直接実行する所がちょっと違いますね。





Jenkinsを導入することで、毎日最新のソースコードで、決まった時間に自動でテストが実行されるようになっているのですが、次のような課題を抱えて困っていました。。。

(1) ソースコードを何も変更していないときでも、必ずしも毎回テストがパスしない
(2) テストが失敗した時は、テストが実行されるPC(Windows)にリモートデスクトップで繋いで、再度テストを実行しながら動作を確認したりするのですが、リモートデスクトップは複数人で同時に接続できないので、誰かが接続すると切られてしまう
 あと、できれば仮想化したい
(3) IEなどの他のブラウザでもテストしたいが、(1)の課題が頻発して使えない


そこで、これらの課題に対してどのように取り組んでいるのか(取り組んで行こうとしてるのか)について書いていきます。

まず、大きな課題である(1)に対してです。
ソースコードを何も変更していないにも関わらずテストが失敗したりするのは致命的ですよね。
これまでも何度も調べていたのですが、結局どう対策したらよいのか分からなかったんです。。。
しかし、最近やっと解決方法らしきものを見つけました。


How to Lose Races and Win at Selenium

で、この方が言うには、問題なのはSeleniumの実行が早く、ページのロードと競争しているからだそうです。

The problem is that Selenium is overeager, and it needs to chill out and wait.
Selenium tests often fail because they’re too fast.
Selenium will interact with a page at the speed of code, before the page is ready.

There are several ways for a page to be “loaded,” and Selenium doesn’t wait for the right one.
It races your page’s loading logic, often “winning” the race and clicking on things before they’re ready to be clicked on.
You need Selenium to lose the race.


これに対する解決作として、SeleniumRCサーバーに対して繰り返し waitForTextPresent などを成功するまで何度か送ってみるといいと言っています。

wait_for_text_present will repeatedly ask the Selenium server whether the text is present until it shows up.


なるほどー、って感じですね。
そこで、まず変えなければいけないことは、テストスイートを直接SeleniumRCサーバーに投げていたことです。
そのために、次のように変更しようとしています。

1. テストスイート、テストケースは現状のままFirefoxのIDEで作成する。
 これはやっぱり作成やメンテナンスが楽だからです。なので、保存しておくのもHTMLのものになります。
2. 作成したテストスイートをJavaのソースコードにエクスポートする
3. 出力したJavaコードをコンパイル、実行することでテストが行われるようにする

このように一度Javaに変換することで、テストの実行を自分たちでコントロールできるようになり、この課題に対してある程度解決できるようになるのではないかと考えています。



次に、(2)の課題に対してですが、PCを追加すれば解決できるのですが、1台あたりのリソースはまだまだ余っている状態っていうのと、増やすたびにお金かかる(Windowsのライセンスを買わないといけない)っていうのもちょっと嫌だったんでどうしようか悩んでいました。

で、クライアントPCをLinuxにすればいいんじゃない??と思い、まずLinuxのFirefoxでテストを実行してみると普通に動いたので単純にクライアントPCをLinuxにしようとしています。1台のHWに複数の仮想マシン(Linux)を立て、動作を確認するときはVNCで接続するっていう方法です。
あと、Jenkinsから実行するときにどのディスプレイで実行するかはこちらでいけるんじゃないかと思っています。うまくいけば、複数人で同じHWを共有で使えるようになります。
http://www.linux-archive.org/centos/463349-how-run-command-specific-vnc-display.html



最後に(3)の課題に対してですが、こちらは(1)の課題を解決することで同時に解決できると思っているのですが、どうせなので少し前にリリースされたSelenium2系(WebDriver)も試していきたいと思っていて。。。

WebDriverはSeleniumRCと違ってJavascriptでの実行という方法ではなくネイティブなAPIを使ってブラウザを実行するようなので、クロスブラウザの問題がクリアできるらしく、またブラウザのサポートもIphone, Androidまで対応しようとしているらしく広いみたいです。



情報源はこちら(もしかしたら少し古いかもしれません)
- SeleniumRC ブラウザサポート
- WebDriber ブラウザサポート


といった感じで、現状抱えている課題とそれに対する取り組みについて書いてみました。
今回書いた内容に関してはまだまだ取組中で変わっていくと思いますので、ある程度できたら構築中のはまりポイントなどを一緒に取り組んでいるメンバーが紹介してくれると思います。

それでは。
次の記事
« Prev Post
前の記事
Next Post »
Related Posts Plugin for WordPress, Blogger...