InfoQ

InfoQ

News

マイブックマーク

ブックマークするためにログイン または 会員登録 する

ブックマークされました!

ブックマークがエラーになりました。もう一度お願いします。

WebTest vs. Selenium: 本物のテストとシミュレートされたブラウザテスト

作者 Geoffrey Wiseman , 翻訳者 編集部 投稿日 2007年11月13日

セクション
デベロップメント,
プロセス/プラクティス
トピック
Agile ,
Artifacts & Tools
タグ
Selenium ,
テスト

Webアプリケーション用の機能的なテストツールには多様なスタイルのものがあるが、その中でも最も模範的な違いは、Seleniumのように実際的な環境をフルに作るために一つかもしくはより多くのWebブラウザを動かすツールと、Canoo WebTestのようにWebブラウザが動作するやり方をシミュレートするツールがある。Marc Guillemot氏(source)はこの二つを比較し(source)、また彼の意見においてはWebTestが13対5の割合で勝利を勝ち取っている。

その二つを比較するにあたって、Marc氏はそれぞれのカテゴリーにおいてWebTestとSeleniumを勝者と考えている。

Canoo WebTest Selenium 引き分け
Reports
Speed
Integration into Development Process
Scalability
Capture JS Errors
Documentation
Predictable Behaviour
XPath Support
Extensibility
Data-Driven Tests
Internationalization Support
Support for Non-HTML Content
Browser Fidelity
Beginner Friendly
Support for Badly Formatted HTML Code
Multi-Language Support
Testing Ajax

Marc氏はテストが十分に速いことはないが、しかし”WebTestは単にやることが少なく、また全てはJVM内にて起こるのです。”と提案している。また彼はSelniumがテストを失敗に至らせるJavascriptのエラーを捕まえることができないと論じている。

あなたはユニットテストが通過する限り、プログラム内でのコンピレーションエラーを受け入れますか?とんでもないです!しかしながら、実のところまさにこれがあなたのアプリケーションに含まれているJavascriptのエラーが発見されない時に行うことなのです(それらが直接的にその特定のテストを失敗させるような影響を及ぼさない限り)。

彼はまた、一般的にブラウザシミュレーターの弱点であると考えられているAjaxのテストが重点に成り得ることを論じている。

人気をよそに、Ajaxの機能をテストするためにはブラウザ内でテストをJavaScriptとして動作させなくてもいいのです。HtmlUnitとそれゆえに、WebTestも同様にタスク次第なのです。またそれは予測できないビヘイビアを予測可能にし、ページ内のリクエストをどのようにスケジュールするかという点において、より良いコントロールを許容するので、それよりも優れているとさえも考えられるのです。参考に以前の私の掲載記事を参照してください。)。

一方、彼は複数の言語をサポートするSeleniumも称賛していて、”WebTestがAntに収束されている一方、Selenium RCは異なる言語(Java、Ruby、PHP等)にバインディングが可能である”と述べている。またそれが粗悪にフォーマットされたHTMLとブラウザの忠実度をサポートするという。

HtmlUnitJavaScriptサポートは驚くべき進展を遂げましたが、未だ普通のブラウザのようには動作しません(そして今後も変わらないでしょう。)。Seleniumはアプリケーションの通常のJavaScript実行を修正しますが、それはブラウザそれ自体を使用し、それゆえにブラウザの標準のビヘイビアにより近いものなのです。

Canoo WebTestHtmlUnitのリードデベロッパであるMarc氏は、明らかにこのスタイルのツールを好み認めていて、またこれに関して反論したい人は、まず彼の分析文書を読んで欲しいと述べている。

明確にすると、WebTest(とHtmlUnit) のコミッターとして、私は間違いなく偏った意見を持っています。一方私は数年間に渡って開発、保持されている巨大なテストスイートにおける経験もあります。客観的になろうとすると、過剰反応してSeleniumを過剰評価してしまうかもしれません。もちろん私がSeleniumに対して持っている意見に対して間違っているところがあれば、それは修正したいと思っています。でも批判する前に一度私の掲載記事を最後まで読んでみてください。

フィードバックにはいろいろな見解が含まれていた。またそれはWebTestとSeleniumが全く異なるものであるということを提示していた(source)。”Selenium、WebTest(HttpUnit)、 DBUnit、JUnitと他のものは補足的なものなのです。これでできてもそれで出来ないものがあるのが事実です。”他の人々は録画・プレイバック vs.スクリプトされたテストの優劣とテストの持続性(source)のためのアプローチに関して論議した。Murali氏はPragmatic QA Elementを提案した(source)

Christian氏はWebTestのAjaxサポートに反論し(source)、彼のアプリケーションにおいて”HtmlUnitはDojoがステートメントをインポートするのを解析しないので一番シンプルなページでさえも例外を投げている”と主張している。

Simon氏(source)にとっては、ブラウザの忠実度が一番重要なポイントであった(source)

WebTestのようなツールは多少理論的に思えます。それらはコードが完璧に働くことを証明するのですが、それはプロダクションに少し類似した理想的な環境においてのみ行われます。本物のユーザ達はIEやFirefox、Seleniumを使用していて、Seleniumはメモリ漏れする稚拙で、標準に準拠しないブラウザを用いて’現実的な’状況下でテストを行う事を可能にします。

WebTestが使用している、特定のエンジン上のアプリケーションを使用するクライアントなんて絶対にいないのです。それは、それが何かの上で稼働するということが分かっ て良いのですが、一方それがどうでもいいことであることを意味しているのです。その反対にSeleniumのテストはFirefox、IE上で動作し、また誰かがクロスプラットフォームに準拠しないで何かを記述した際に起こる問題をたくさん捕らえるのです。

最後に、Kent Tong氏は二つのアプローチを結びつかせている(source)

WebTestとSelenium両方の上で動作できる、テスト一式の記述を可能にするミドルレイヤを開発することは可能なのでしょうか?このやり方でWebTestとSeleniumを毎晩頻繁に稼働させることによって、二つの世界を把握することができるでしょう。

あなたはこのどちらかを使用するだろうか。それとも他のテストツールを一緒に使用するだろうか?次世代のテストツールに関するディスカッションに参加したくなっただろうか?更なる情報に関してはCanoo WebTest(source)、Selenium(source)、Testing(source)と次世代のテストツールを読んで欲しい(source)

原文はこちらです:http://www.infoq.com/news/2007/11/canoo-webtest-selenium-testing

特集コンテンツ一覧

GAE開発の落とし穴

Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します

イベントレポート:「Coqチュートリアル#1」

去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。

Javaの未来についてのNeal Gafter氏とのディスカッション

Choosing Options

Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。

Google Dartのエッセンス:アプリケーションの構築、スナップショット、Isolate

GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式

CSPベースのモデル検査ツール「Process Analysis Toolkit」

本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。

Jenkinsによる継続的インテグレーションのススメ(4) ~CloudBeesでJenkinsをサービスとして使う~

前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。

書籍『抽象によるソフトウェア設計-Alloyではじめる形式手法-』の紹介

Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。

Windows デバイスで開発するタッチユーザーインターフェイス

スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。