Selenium vs Mercry

本稿はSelenium Advent Calendar 2013 18日目の記事です

WebのUIを操作できるテスト実行ツールSelenium。その名前の由来は、当時主流だったMercury社製のQuick Test Professionalに対抗してつけられたそうです。Mercuryは水星のほか、水銀という意味もあります。その水銀の中毒に対して有効だったのがセレンでした。この由来は、[Wikipedia]Selenium (software)で紹介されています。Quick Test ProfessionalはMercuryからHPに買収されUFTに名前を変えましたが、どんどん便利になっています。[Wikipedia]HP QuickTest Professional

今回はSeleniumの名前の由来となったMercury(QTP)※とSeleniumのメリット、デメリットを並べてみたい思います。
※現在はHPのUTFですが、私が使用していたものがMercuryのQTP6.5だったので、当時の情報を元に記載しています。

Seleniumのメリット

  • OSSのためツール自体にコストがかからない(人件費除く)
  • 基本はHTMLでノンプログラマにやさしい
  • 利用者が多く、情報がネット上にたくさんある
  • 様々なプラグインが作成されている
  • Web Driverは様々な言語を使用できる
  • 欲しい機能を自作できる

Seleniumのデメリット

  • webしか操作できない
  • TDDやるにもログを出すにもリポジトリ作るにも手間がかかる
  • いろいろやるには結局プログラミングが必須
  • 情報が点在しているので、情弱には辛い
  • ツールに不具合があっても文句が言えない

QTPのメリット

  • Webだけでなく、Java、PHP、Cなど様々なUIを操作できる
  • Excelを読み込ませられるので、Excel中毒の現場に嬉しい
  • DDTが超簡単にできる
  • リポジトリの機能がデフォルトでついている
  • Quality Centerと連携することで複数台同時実行やスケジューリングが可能
  • 画面キャプチャ付きのログが出力されるので、インシデントを確認しやすい
  • サポートをつけるとプロが相談に乗ってくれる

QTPのデメリット

  • (OSSと比べると)とにかく高価
  • 関連ツールも有償
  • サポートも有償
  • 情報がネットにあまり転がっていない
  • 操作対象のオブジェクトを認識させる必要がある
  • ログ容量がサーバーを圧迫するかも(カスタマイズは可能)

有償と無償という致命的な違いがあるので、「どちらがいい」とは言い切れませんし、予算上選択肢が1つしかない場合もあると思いますが、有償ツールには有償ツールのよさがあります。比較して改めて感じるのは、Seleniumはとても優秀で補助ツールもたくさん公開されていますが、情報を集めて適切に使用するのはとても難しいということです。調べたりカスタマイズしたりするのに1か月かかるのであれば、有償ツール1ライセンス買うという選択肢もありかもしれません。見えないコストに惑わされずに活用していきたいところです。

Seleniumを含む、テスト自動化の歴史は、12月1日に開催されたシステムテスト自動化カンファレンス2013のクロージングセッションで、辰巳さんが紹介しています。是非スライドをご覧いただければと思います。

広告

Visual StudioでKDTは実現できるのか(2)

「Visual Studio×Excel、できたらいいな。他にも何かできないかな。」と、調べてみました。Visual Studioでもキャプチャ&リプレイの機能があるんですね。対応しているバージョン等の情報はこちらから。職場で使用しているのはVisual Studio 2012 Premiumですが、自宅にあるのは無償のExpress版。残念ながら対応していませんでした。うまくいかなくて困っていたので、家から画像つきでUPしようと思っていましたが、できないので、記憶を頼りに書きたいと思います。

Visual Studioのキャプチャ&リプレイ機能「Coded UI Test(CUIT)」。日本語では「コード化されたテスト」と呼ぶようですが、名詞っぽくないのでCUITと呼ぶことにします。記録できるのはwebだけでなくWindowsアプリケーションももちろん操作可能。おそらくそちらの方が相性がいいかもしれません。webの場合、上に貼ったMSDNのドキュメントには、サポートはIE系のみとありますが、MSエバンジェリストの長沢さんの記事によると、VS2012のUpdate 1でchromeでの実行も可能になったようです。

クロスブラウザでの自動UIテスト~Visual Studio 2012 Update 1

私が担当しているものはブラウザ間のテストは不要なので、ひとまず動作を確認していきます。上の記事に、記録と実行の手順がありましたので、真似てやっていきました。
「コード化された UI テスト ビルダー」がとってもシンプルです。記録するとビルダーの上部に「ボタン1クリック」などの情報が出ますので、操作が記録されている感があります。よくあるキャプチャ&リプレイの罠に「操作が速すぎて記録できない」という問題(現在はもう、大丈夫なのかな?CUITは怪しそうな感じがありました)がありますので、ゆっくり操作するのが吉かと思います。おまじない程度で。ビルダーの表示方法を変えれば、取得したコントローラー情報と、記録一覧が表示されます。アサーションの入れ方もビルダーで楽々のようですが、まずは実行できなければ確認もなにもできないので、コード化して実行してみます。

コードの生成ボタンを押すと、C#のコードがばーーっとできあがります。ビルダーを消すとVSが立ち上がり、できあがったテストコードをビルド、テスト実行すれば、ブラウザが立ち上がり記録した操作を実行してくれる…という手順です。(Visual Studioに不慣れ、開発経験、単体テスト経験のない私にはこれがかなりハードルが高かった…orz)

テスト実行ポチっ。待つこと暫し…エラーになってしまいました。。

記録したのは、ログイン画面での以下の操作です。

  1. ID入力
  2. パスワード入力
  3. ログインボタン押下

1の時点で、Editが操作できない、というエラーをはいているようでした。記録させたのを実行しただけなのに。。
おそらく、オブジェクトのマッピングがうまくいっていないのだろうと予測を立て、できあがったソースコードをひっくり返しました。UIMAPでオブジェクトマッピングが管理されており、エディターで編集ができました。

コード化された UI テスト エディターを使用したコード化された UI テストの編集

こちらのドキュメントにもあるのですが、「UI コントロールの検索」というボタンがあり、それを押すと保持されている情報をもとに、コントロールを特定し赤枠で囲って表示してくれます。エラーを返したEditを検索してみたところ、案の定、おかしなところを指し示しました。そして、パスワード入力用のEditerも同一のものと認識している…階層もおかしいし、編集や追加をしなければ…。

Seleniumだと位置の特定はid属性、name属性、Xpathなどでできますが、Visual Studioでは何で特定しているのかわかりませんでした。とりあえずnameを引っ張って指定してみましたが、「ないよ!」と怒られてしまいました。では、改めてオブジェクトを認識させてはどうでしょう。QTPではエディターから直接オブジェクトを認識させるボタンがあるのですが、見当たりませんでした。ネットで検索してみたところ、以下のリンクが見つかりました。

方法: コード化された UI テスト ビルダーを使用して UI コントロールと検証コードを追加する

アサーションを入れるときの操作ですね。これでオブジェクトの追加ができるようです。ビルダーの方向キーで親子関係にあるコントローラーも取得できるようなので、あっちこっち操作をして認識させてみました。
しかし、結果は変わらず。ボタンの認識はうまくいっていそうなので、ボタンクリックのみの操作を記録し実行したところ、これは成功。しかし、Editだけでなく、同じ画像が使われたボタンも、同一オブジェクトとして認識されてしまいました。階層の編集はいくら調べても見つからずでした(英語が読めないので日本語サイトしか検索していませんが…)
サンプルでwebが紹介されているくらいだし、そんなに梃子摺るところじゃないと思うんだけどな…と思いながらも、すっかりはまってしまったので、諦めて帰宅したのでした。

で、書いていて気が付いたのです。完全サポートしているのはIEだということに。ついSelenium感覚でFirefoxで記録させていました…。月曜日朝一で、IEで確認してみます 。。

Visual StudioでKDTは実現できるのか(1)

Visual Studioと出してMS属性の方を釣る作戦。
どうも。夏はおだんご。Mayです。

webアプリケーションのシステムテストを自動化できないか、ということでテスト仕様書作成からツール選定、自動化フレームワークの作成などなど格闘しているところです。なかなか思うように進まないのですが、そんな試行錯誤の記録が残せたらと思っています。
テスト仕様書からというのがミソで、そのまま読み込ませて自動化しちゃったらいいんじゃない?という思想の元、キーワード駆動テスト(KDT:Keyword Driven Testing)の形を目指しています。どんなフォーマットがよいのか、まだ確定はしていませんが、できあがったら結構自慢できるかもしれません。これはまた今度。

さて、webのUIテストならオープンソースのSeleniumがありますが、Visual Studioを使用しているので有効活用したいところ。調べてみると、手元にあるツールの選択肢としては、以下の3つがありそうです。

  • SeleniumIDE+RC
  • Selenium2+NUnit
  • Coded UI Test(CUIT)

SeleniumIDEは「操作」「対象」「値」の3つを指定すれば操作が可能なので、TABOKで言えばKeyword Driven Frameworkにあたるツールですが、1キーワードが1オペレーションになるので、粒度が細かくなっています。なので、KDTかと言うと微妙ではあります。その辺の概念がまとまるのは、もう少し先の話になりそうですが、今回私が考えているのは、スプレッドシートに書いたビジネスレベルの操作を元にテストを行うというもの。例えば、「申込み」「変更」とか大雑把な操作レベルです。
ですので、SeleniumIDE用のテストケースにしろ、Selenium2にしろCUITにしろ、スプレッドシートからキーワードを読み取って、UI操作するツールを動作させるための仲介役のプログラムが必要になります。SeleniumIDEなら、スプレッドシートからHTMLの形に変換をかけます。Selenium2はJavaやC#のコードに落とす必要があります。
この時、私が期待しているのは、現在使用している統合開発環境がVisual Studioという点です。Visual Studioと言えばMicrosoftの製品ですから、Excelとの相性が抜群。

Visual Studioで作るデータドリブンテスト

など様々な記事で紹介されている通り、単体テストでExcelを読み込みデータ駆動のテストを実現することができるようです。UIのテストでも同様に使うことができれば、コードに落とす手間が省けます。

さらに、Team Foundation Serverに登録しておけば

TFS 2012 プロジェクトのはじめ方 ~新TFSスクラム プロセステンプレート紹介つき [1/2]

で紹介されている

テスト作業) PBI → テスト スイート → テスト ケース → (テスト結果) → バグ → (ソースコード) → (ビルド) → (デプロイ)

の良いサイクルにも乗せられる…???

なんて夢を見ている次第。

夢かどうかは調査中なのですが、参考にできそうな事例が転がっていなくて、のろのろ亀さんのペース。そんなに悠長に過ごしてはいられないんですけどね…。ご存知の方がいましたら、コメントいただけると助かります。

今日はCUITを試しに使ってみていたのですが、そちらも悪戦苦闘。長くなってしまったので、次の記事であげようと思います。