レベル: 中級 Joshua Fruhlinger (dw@jfruh.com), Editor and Writer, Freelance
2007年 12月 18日 「複数のブラウザーでのテスト」は、テスト対象となるブラウザーが複数になって以来、お題目のように唱えられてきました。すべてのブラウザーに対してテストすることは、(特に最近では) 不可能です。しかし、皆さんが考えるよりももっとその状態に近づけることができるのです。この記事では、クロスブラウザーのテストを行うためのさまざまな手法を、非常に完璧なものから間に合わせのものまで含めて学びます。どの手法を選ぶかはお持ちのリソース次第で変わってきますが、無視することのできない重要な問題です。
私達は皆、Web アプリケーションを複数のブラウザーやオペレーティング・システムでテストする必要がある、ということを知っています (というよりも、知っている必要があります)。しかしそれは多くの場合、理論的に同意することは容易でも、実際に行おうとすると困難なものです。皆さんのサイトにアクセスする顧客が使用する可能性のある、ブラウザーとオペレーティング・システムの組み合わせは多数あることを考え始めると、クロスブラウザーの完全なテスト・スイートを用意することは、開発リソースの無駄遣いに思えてくるかもしれません。
え？IE 以外にもたくさんある？
2000年の始め頃であれば、Internet Explorer でテストしさえすれば許されたかもしれませんが、そうした日々は遠く過ぎ去りました。現在 IE は、さまざまなサイトを訪れるブラウザーの約 80% を占めています。これは大多数ではありますが、圧倒的多数ではありません。自社の顧客層の 20% を切り捨てても構わない、という会社はないはずです。
また、ブラウザーの使い方の習慣に関して、ある特定のユーザーがインターネット・ユーザーの世界全体を反映していると想定してはなりません。ブラウザーや OS に関する習慣はユーザーの関心事項や国によって変わります。特定のユーザーを対象にした多くのサイトでは、Windows を使用していないユーザーが Internet Explorer 以外のブラウザーでアクセスする傾向があります。例えば、developerWorks のサイトを訪れる人の約 60% は Internet Explorer を使用しており、約 35% は Firefox を使っています。特に Web development ゾーンでは、Firefox が 51%、Internet Explorer が 41% という数字になっています。
幸いなことに、いくつかのツールや特別な方法を利用することで、このプロセスが少し容易に (そしてコストがかからなく) なります。この記事では、テスト用に使用できるさまざまな手法について説明します。皆さんはその中から、皆さんの要求とリソースを基に、最適なものを選択することができます。まず、より完全にテストをするための方法から説明しますが、時間とリソースの制約があるために望んでいるほど掘り下げたテストができない場合には、他にも方法があることがわかるはずです。
複数のブラウザーで実行する
 |
オプション機能のテスト
多くの Web アプリケーションが依存する 2 つの技術、つまり Flash と JavaScript を、ユーザー全員がブラウザーで有効にしているとは限らないことを忘れてはいけません。この記事で説明する手法のどれを使うことになるにしても、JavaScript と Flash をオンにした状態とオフした状態の両方でテストを行う必要があります。(ホスト・サービスの多くは、このオプションをオンオフするための簡単な方法を提供しています。) この点はクッキーにも当てはまります。サイトを訪問するブラウザーの状態として考えられるものをシミュレートするために、クッキーをオフにしたりクリアーしたり、できることは何でも行う必要があります。
JavaScript は、当然ながら Ajax アプリケーションの基礎です。Ajax コードをクロスプラットフォームでテストするのは、とても大変な作業になってしまうかもしれませんが、ポイントは、ハードウェアまたはブラウザーのエミュレーション・レイヤーをなるべく小さくし、実際のユーザー・エクスペリエンスに近づければ近づけるほど良い、ということです。さまざまなブラウザーにまたがって Ajax アプリケーションをデバッグすることの大変さ、そしてそれらのアプリケーションが検索エンジンによって適切に索引付けされるようにすることの難しさ、の 2 点が、Ajax コードのクロスプラットフォーム・テストをしようとする際に大きな障害となる点です。詳細については、developerWorks 独自の Ajax resource center へのリンクを含めて、「参考文献」のリンクを参照してください。
|
|
複数のブラウザーと OS にまたがってテストするための、最も明白で最も完全、そして通常最もコストのかかる方法は、実際に複数のブラウザーと OS でテストしてみることです。このテストに必要なもののなかで、ブラウザーを用意するのが一番簡単なことです。なぜなら最も頻繁にサイトを訪問するブラウザーの大部分は無料で入手できるからです。ただし忘れてはならないことですが、皆さんはおそらく、単にいくつかの異なるブラウザーをテストするだけではなく、同じブラウザーのいくつかの異なるバージョンでもテストしたいと思うはずです。きっと皆さんは開発者として、最新で最高のバージョンのブラウザーを使用しているはずです。(実はそうした事態こそ、そもそも「複数のブラウザーでテストする」というお題目が始まった理由の 1 つです。) しかし皆さんのサイトのブラウザー統計を少し見れば、皆さんの顧客の少なくとも一部は最新で最高のブラウザーを使っているわけではないことがわかるはずです。
同じブラウザーの複数のバージョンを同時に実行することは少し面倒です。大部分のブラウザーでは、インストールのプロセスで以前のバージョンが上書きされてしまうからです。幸いなことに、回避策はあります。Firefox の場合であれば、通常は、各ブラウザーの実行可能ファイルを別の名前で保存し、そして各バージョンを最初に起動する際に必ずプロファイル・マネージャーを起動し、プロファイルが共有されないようにすればよいだけです。図 1 は Firefox ブラウザーの 2 つのバージョンを示しており、最新の 2.0.0.10 リリースと古めかしい 0.7 バージョンが並んで実行されています。
図 1. Firefox の複数のバージョンを同時に実行する
Internet Explorer の場合、このプロセスは少し面倒です。Windows は複数のバージョンを同時に実行させることを本当に嫌っています。この抵抗を回避するためには、レジストリーの設定を少しいじる必要があります。TredoSoft という小さなソフトウェア会社は、複数のバージョンの IE をインストールするための手軽な無料のツールと、適切なレジストリー・キーと DLL の操作をするための方法をリリースしたことで非常に注目を集めました。これについては「参考文献」のリンクを参照してください (またここで紹介する他のツール、そしてヒントの応用へのリンクも「参考文献」にあります。ただしそうしたリンクは、必ずしも私や developerWorks がそれらを保証していることを意味するものではありません)。
|
現実の世界でのテスト
さまざまなブラウザーをさまざまな構成でテストする必要があるだけではなく、テスト・マシン (あるいは専用のマシンを持たないような環境では、信頼できるリモートのユーザー兼テスター) がそれぞれ独自にインターネットに接続されている必要があることは言うまでもありません (またそうでなければなりません)。つまり実際に接続した状態でテストすることを忘れてはならず、画像やスクリプトをローカルでロードするだけですませてはならない、ということです。実際にあり得る要素でテストに追加できるものは、ありとあらゆるものを含める必要があります (例えば、ユーザーがマシンで有効にしている可能性のある、ポップアップや広告のブロッカー、パーソナル・ファイアーウォール、その他のソフトウェアは、ページの表示方法に影響を与えるかもしれません)。そうすることによって、実際のエンドユーザーのユーザー・エクスペリエンスをより適確に把握することができます。ワシントン大学による Web Tripwire Toolkit (「参考文献」を参照) を利用すると、おかしな動作がブラウザーの実装によってではなく、さまざまな要素の干渉によって発生するのはどんな時なのかを調べることができます。
|
|
当然のことですが、これらのブラウザーをすべて起動して実行させる前に、そのブラウザーをどこから入手するのかを知らなければなりません。例えば Microsoft® のサイトでは Internet Explorer 5 はダウンロード用に提供されておらず、また Mozilla Foundation のページのどこで Firefox 1.0 を入手できるかは明白ではありません。幸い、エンタープライズ指向の Web 市民達が、古い実行可能ファイルのアーカイブを作成しています。evolt.org の、ボランティアによる Web コミュニティーには、考えられるあらゆる種類の古いブラウザーが、IE から Opera まで、そしてそれ以外も、幅広く集められています。ただし最近の Mozilla リリースに関しては少し欠けているものもありますが、そうした不足分は filehippo.com などのファイル集約サイトを利用することで補うことができます (この種のファイル集約サイトはそれほど苦労せずに見つかるはずです)。そして Apple の Safari に関しては、1 人の開発者による愛の成果である Multi-Safari プロジェクトが、これまでのバージョンの Safari を手軽に利用できるようにパッケージしており、大きな手間をかけなくてもそれらを同時に実行することができます。(「参考文献」には、これらのすべてに対するリンクを挙げてあります。)
画面スペースを節約する
複数のブラウザーを操作する際に突き当たる 1 つの現実的な問題は、さまざまなウィンドウで画面が乱雑になってしまうことです。これはほとんどの場合避けられないことですが、いくつかの便利なツールを使うことで少し整理することだけは可能です。IE Tab は Firefox のプラグインですが、Internet Explorer のインスタンスを Firefox タブの中から実行することができます。これはエミュレーションではなく、実際に IE の描画エンジンを使っています。つまり表示されるものは実際に Internet Explorer に表示されるもの、ということですが、Windows でしか動作しないという意味でもあります。図 2 は実際に IE Tab が動作しているところを表しています。
図 2. IE Tab を使う
RightLynx は Internet Explorer と Firefox 用のプラグインであり、右クリックするとウィンドウがポップアップされ、現在のページが Lynx でどう表示されるかをそのウィンドウに表示します。そのため、アクティブなターミナル・ウィンドウを開いておく必要がありません (Web サービスは Lynx で表示されるページをロードし、そのテキストを現在のページを表示しているコンピューターに返送します)。どちらのツールも無料で入手できる上、簡単にインストールすることができます。リンクは「参考文献」のセクションにあります。
Lynx: あまりにも古いため、かえって新しい
前のセクションで Lynx を取り上げていることに関して、一瞬戸惑った人もいるかもしれません。Lynx は、(あまりにも若く、知らない人のために言うと) テキスト・ベースのブラウザーであり、最初は UNIX® のコマンドラインで使用するために 1990年代の初めに開発されました (ただし DOS 用のバージョンもあり、従って Windows 用もあります)。図 3 は developerWorks の Web development ゾーンを Lynx で表示したものです。
図 3. Lynx の実際
Lynx を使ってサイトをテストすることは、最初は的外れに思えるかもしれません。つまり皆さんのサイトを訪れるほとんど全員は、最近のグラフィカル・ブラウザーを利用しているはずです。しかし皆さんのサイトから装飾部分を一切除き、必要最低限のもののみを Lynx で表示することによって、皆さんのサイトにとって最も重要な訪問者、つまり Web クローラーや Web スパイダーに見えている皆さんのサイトの様子を非常によく表すことができるのです。(Web クローラーや Web スパイダーは、トラフィックの大部分を提供する検索エンジン用にサイトを索引付けします)。重要な検索用語が Ajax ウィジェットの後ろに隠れていないかどうか確認する上で、Lynx は素晴らしいツールです。
視覚化とエミュレーション
ブラウザーに関する苦労は、まだテストに関する苦労の半分にすぎません。皆さんはおそらく、複数のオペレーティング・システムに対してもテストを行いたいはずです。もちろんこれは、単にフリーのブラウザーを開発マシンにダウンロードすることに比べると、ずっとコストのかかる作業です。これに関して最も完璧な方法は、当然ながら、テストの対象にしたい Windows マシンと Mac、そして Linux® マシン、そしてそれ以外のシステム用のマシンを実際に用意する方法です。しかしそんなことをすると、皆さんの Web 開発予算の 1 年分を超えてしまう可能性があります。しかし幸いなことに、1 台のコンピューターを複数のテスト・プラットフォームに変えるための方法がいくつかあるのです。
最も直接的な方法の 1 つは、デュアル・ブート設定にする方法です。つまり複数の OS を 1 台のマシンにインストールし、どちらをロードするかを起動時に選択するのです。一般的に、OS はすべてハードディスク上の別のパーティションに保存されますが、いわゆる LiveDistro は CD または USB メモリーに保存されるため、ハードディスクをフォーマットする手間を省くことができます。デュアル・ブートは歴史的に Linux などオープンソースのディストリビューションに付き物でしたが、x86 ベースの Mac の登場は、多くのマシンが今や Windows と OS X をデュアル・ブートできるようになったことを意味しています。
デュアル・ブートの欠点は、OS 間の切り替えに時間がかかることです。仮想化の場合は、こうした問題はありません。仮想化では複数の OS が同時に実行されます。仮想化は、かつては強力なサーバーで行うものでしたが、今では標準的な仕様のデスクトップ PC を使用する人であれば誰でも十分に手が届くものになっています。もし複数の OS を使用するユーザーを対象にするつもりであれば、何らかの形の仮想化機能を備えたテスト・マシンが必要です。図 4 では、Power Mac 上で Virtual PC を使用することによって、developerWorks の Web architecture ゾーンを 2 つの OS 上の 4 つの異なるブラウザーに同時に表示しています。
図 4. 4 つのブラウザーを同時に表示する: OS X 上で Safari、OS X 上で Firefox、Windows XP 上で Firefox、そして Internet Explorer
汎用の PC ならばどんな PC でも Windows や他の大部分の x86 互換 OS を容易に実行できる、VMWare や Virtual PC を始めとするいくつかのツールがあります。1 つの OS はホストとして動作し、それ以外の OS は仮想化アプリケーションの中で実行されます。これによって、画面上の隣り合ったウィンドウで、例えば Windows Vista と Windows XP、そして最新の Ubuntu ディストリビューションを起動し、そのそれぞれの OS 上でリブートすることなく、アプリケーションを実行することができます。それでもなお、異なるすべてのOS をすべて購入する必要があることは変わりませんが、少なくともハードウェアは 1 台のみですませることができます。
この前の段落で挙げた OS の例の中に Mac OS X がなかったことに注意してください。残念ながら OS X は Mac ハードウェア以外では実行できません。しかし、Mac 用の仮想化オプションは入手可能です。従って、可能な限り広範な OS を1 台のマシンでカバーしたい場合には、Intel® 版の Mac と、Intel 版の Mac 用に利用可能な 2 つの主な仮想化製品、VMWare Fusion または Parallels Desktop (リンクは「参考文献」を参照) を使うことを検討するとよいでしょう。こうした設定を行えば、OS X と Windows、Linux その他、x86 ハードウェア上で動作する任意のオペレーティング・システムをテストすることができます。欠点は当然ながら、ソフトウェアもハードウェアも無料ではなく、特別安くもないことです。
モバイルの場合
Web サイトまたは Web アプリケーションがモバイル・ユーザーを対象としている場合や、あるいは多数のユーザーがモバイル機器からアクセスすることを想定している場合でも、理想は当然、実際のモバイル機器上でテストすることです。残念ながらモバイル機器の市場は PC 市場よりもずっと細分化されており、実際のモバイル機器をテスト用に大量に購入して維持管理することは困難であり、またコストもかかりすぎます。幸いなことに、デスクトップ・コンピューターはモバイル・プラットフォームをエミュレートするためにも使用できるのです。
個々のモバイル・プラットフォームには、多くの場合、無料の SDK が用意されており、その中には PC のデスクトップ上で実行するデバイス・エミュレーターが含まれています。例えば、Google の Android プラットフォーム用の SDK をダウンロードすることができます (「参考文献」にリンクがあります)。モバイル機器のブラウザーにアクセスするのは少し面倒で、Android プラグインを Eclipse 開発環境にインストールし、サンプル・アプリケーションの 1 つを起動する必要があります。しかしいったんそれを行えば、WebKit をベースにブラウザーにアクセスすることができます (WebKit はオープンソースのフレームワークであり、Safari と、Nokia の S60 スマートフォンのブラウザーの両方の基礎となっています)。図 5 はブラウザー・エミュレーターが動作している様子を示しています。
図 5. Android SDK でのブラウザーの様子
モバイル・ブラウザーの市場も、やや細分化されています。しかしハイエンドのスマートフォンの多くに現在組み込まれているブラウザーは、デスクトップ用のブラウザーをモバイル用に変更したものです。例えば iPhone は Safari を使っており、Opera Mobile は多くのスマートフォンで使われています。また携帯電話のブラウザー用のテストの大部分をデスクトップ上で直接行うことはできますが、その相関性は完全ではありません。(iPhoney はデスクトップ用の標準バージョンの Safari を使う OS X アプリケーションですが、少なくとも iPhone の制限された画面スペースでサイトがどう表示されるかの感覚をつかむことはできます。無料でダウンロードできるリンクを「参考文献」に挙げてあります。)
もちろん、WAP という「壁に囲まれた庭」から Web にアクセスする携帯電話が今でも数多く使われています。WAP サイトをテストする必要がある場合には、ブラウザー・ウィンドウ上で簡単に実行できるフリーの WAP エミュレーターを、いくらでもオンラインで入手することができます。
一般的に、モバイル機器の分野は、社内テストによって本当に適確で広い範囲をカバーすることが相変わらず非常に困難な領域です。しかし他にもまだ選択肢はあり、それを次のセクションで説明します。
テストをアウトソースする
皆さんは、この記事をここまで読んできて、ある程度の絶望を感じているかもしれません。もしかすると、皆さんの締め切りは明日かもしれません。もしかすると、皆さんはまだ確信を持てないかもしれません。もしかすると、皆さんの予算は時間的に、あるいは金額的に、非常に限られているかもしれません。もしかすると皆さんの IT 部門は、コンピューターに古いバージョンのブラウザーをインストールしたりレジストリー・キーをいじったりすることに対して、眉をひそめるかもしれません。ではどうしたらよいのでしょう。最新バージョンの Firefox と IE 以外ではまったくテストできないのでしょうか。
限られた状況であっても、もう 1 つ、他の選択肢があります。それは、テストを行ってくれるホスト・サービスを使う方法です。URL を指定すると、その URL がさまざまなプラットフォームでどのように表示されるのか、ホスト・サービスが示してくれます。皆さん自身のテスト・マシンから実際にサイトを操作することはできなくなりますが、ほとんどコストをかけずに、場合によってはまったくコストをかけずに、非常に広範囲な種類のプラットフォームにアクセスすることができます。
こうしたサービスのうち、無料のサービスではどんなことができるのか、Browsershots.org を見るとわかります。図 6 は、どんなオプションが利用できるかを示しています (ここにはモバイル・プラットフォームや Lynx は含まれていません)。各ボックスをチェックするごとに、チェックしたブラウザーと OS の組み合わせに対する、指定された URL のスクリーンショットを含んだ PNG ファイルを得ることができます。このプロセスは 30 分以上かかる場合もあるため、何か他のことを行いながらバックグラウンドで実行した方が賢明ですが、これによって重要なベースを費用をかけずにカバーすることができます。
図 6. Browsershots.org から得たい結果を指定する
絶対確実に一晩で、しかも至る所でテストしなければならない場合
もし支払えるだけの予算があるなら、もう少し高度なことができます。例えば、毎月の使用料を支払えば、Browsercam.com によって (一部のモバイル・プラットフォームを含めて) より広範囲のプラットフォームとブラウザーにアクセスすることができます。またページは動的であり、Ajax アプリケーションや他の JavaScript ベースのページをテストすることができます。Litmusapp など一部のサービスでは、テストと開発のワークフローを統合することができ、またバージョン管理と、テスト結果を外部のクライアントに公開するための方法も提供しています。
こうした種類のサービスは、モバイルの世界にも非常に適しています (モバイルの世界では、大部分の人が追いつくよりも早く、新しい機器が常に登場しています)。DotMobi Virtual Developer Lab はモバイル機器に焦点を当てたホスト・サービスの好例です。このサービスを利用すると、何百もの異なるモバイル機器にアクセスすることができ、またそれらの機器を何通りもの方法で操作することができます。こうしたサービスが提供するインターフェースは、実際に動作する機器を扱う場合とは同じではありませんが、多くの場合は十分実物に似たインターフェースとなっています。また DotMobi Virtual Developer Lab はモバイル機器のみに焦点を当てているので、皆さん自身の内部テストまたはデスクトップ用の別のサービスのいずれかを補完する役割を果たすことになります。
まとめ
理想的には、すべての Web アプリケーションに対して、そのアプリケーションにアクセスする可能性のあるすべてのブラウザーで、そのアプリケーションが完璧に動作することを確認するテストを行う必要があります。しかしブラウザーの市場が細分化され、さらにモバイル・プラットフォームという非常に変化の激しい世界の重要性が増すにつれ、そうした完璧なテストは現実には不可能になってきています。とはいえ、皆さんが考えるよりももっと理想に近づくことは可能なのです。クロスプラットフォームの Web テストを行うために、非常にさまざまな種類のツールを利用することができます。いくつかの仮想化 OS を備えたワークステーション用のリソースを持っている場合であれ、あるいはホスト・サービスでアプリケーションを実行することしかできない場合であれ、さまざまなユーザー環境でアプリケーションがどのように動作するかを調べることができます。そして、そのアプリケーションが可能な限り多くの場所で動作するようになるのは、さまざまなユーザーのおかげなのです。
参考文献 学ぶために
製品や技術を入手するために
著者について | | | Joshua Fruhlinger はフリーランスのライターであり編集者です。彼は妻の Amber と猫の Hoagie と共に Baltimore に住んでいます。 |
記事の評価
| 
