テストという観点からWeb2.0について分析する。
Web2.0アプリケーションは、以下の点において特徴的と考えられる。
1)「永遠のβ」と言われるように、アプリケーションが頻繁に修正されること。
2)プレゼンテーション層としては(X)HTML+CSS+JavaScriptを基盤とすること。
3)通信プロトコルとして、主にHTTPが用いられること。
これらの特徴に対応したテスト手法が求められる。
オープンソース・ソフトウェアにおいては「足りないものは作ればよい」ということで、これらの要求に応えるテスト用ツールが登場している。
1)「永遠のβ」と言われるように、アプリケーションが頻繁に修正されること。
アプリケーションが修正されたときのテストにおいて課題となるのは、「修正されていない部分が以前と変わらず動作することの確認」である（いわゆるレグレッションテスト）。
理想的には、「修正されていない部分」のすべての動作が変わっていないことをテストするべきであるが、テスト工程を多くを人手によっている場合には、現実的には影響範囲を人が判断して実施するテストを絞り込むことになる。
レグレッションテストを自動化すれば、「修正されていない部分」のテストにかかる工数は大きく削減することができ、カバレッジを大きくとることができる。
この後に述べる二つのツールは、テストのシナリオを一度作ってしまえば自動でテストを繰り返すことができる。注意すべき点として、テストのシナリオ作成にかかる工数が大きくなりがち（なまじ自動化できるだけに、テスト項目を多くしてしまいがちである）なことがあげられる。
2)プレゼンテーション層としては(X)HTML+CSS+JavaScriptを基盤とすること。
プレゼンテーション層に対するテストとして、JavaScript + DOMを基盤とした自動テスト技術が登場している。プレゼンテーション層（=ブラウザ）に対するユーザーの操作をDOMに対するJavaScriptの操作によってエミュレートし、結果として表示される内容、すなわち生成されたDOMが想定どおりになっているかどうかをテストする技術である。
この技術のオープンソース実装として、Seleniumを後に紹介する。
3)プレゼンテーション層とビジネスロジック層との通信にHTTPが用いられること。
Web2.0アプリケーションでは、HTTPの上に多種多様なデータを乗せて通信が行われる。加えて、一般に不特定多数のクライアントからのリクエストを処理する必要があることから、多数のクライアントからのHTTPリクエストをエミュレートしてテストすることが重要である。
HTTPレベルでのテストツールの代表的なオープンソース実装として、JMeterを後に紹介する。
Seleniumは、ThoughtWorks社によってその原型が開発され、Apache License 2.0の元で公開されているオープンソース･ソフトウェアである。Seleniumの特徴は以下の通り。
・テストの対象となるWebアプリをブラウザのフレーム内で動作させる ・他のフレームからJavaScriptでDOMを操作し、アプリケーションを駆動する ・結果がどうなったかをDOMで取得、予想と一致しているか確認 ・実装スタイル（Ajaxを使っているかどうか）は問題になりにくい特にWeb2.0アプリケーションにおいては、Ajaxなどの技術により動的にページの内容が変化する。Seleniumによるテストでは、ページ内のDOMを直接読んで結果を確認するため、アプリケーションの実装スタイルに左右されずにテストを実施することができる。
Seleniumは、以下の製品群から構成される。
それぞれ概要を見ていくことにする。
図3-1 Selenium Core
Selenium Coreは、HTML + JavaScriptで書かれたテストの実行エンジンである。
テストシナリオ(画面中央のフレーム)およびテストシナリオのリスト(画面左のフレーム)は、単なるHTMLのテーブルとして作成する。テストの実行は、コントロールパネル（画面右のフレーム）から指示する。テスト対象になるアプリケーションは、画面下のフレーム内で実行される。
コントロールパネルからテストの開始を指示すると、実行エンジンはテストシナリオ内に書かれたコマンドを読み取り、そのコマンドを実施した結果をテストシナリオおよびテストシナリオのリストのDOMを操作することで表示していく（成功したテストはセルは緑色に、失敗したテストのセルはピンクになる）。コマンドには、DOMを操作してテスト対象アプリケーションを操作するものや、テスト対象アプリケーションのDOMを読みとり、予想される結果と一致しているかをテストするものなどが用意されている。
図3-2 Selenium IDE
前述の通り、Seleniumのテストシナリオは単なるHTMLなので、通常のテキストエディタやHTMLエディタで書くことができる。とはいえ、アプリケーションが複雑なものになると、一連の操作とその結果の流れを直接記述していくのにかかる工数は膨大なものになってしまう。
Selenium IDEはFireFoxのExtensionとして実装されたIDEであり、Seleniumのテストシナリオの作成を大幅に省力化する。もっとも特徴的な機能は「テストシナリオの自動記録」である。これは、FireFox上でテスト対象アプリケーションを操作すると、その一連の流れがSeleniumのテストシナリオとして記録されていくという機能である。記録されたシナリオはその場で再実行させることもできるし、Selenium IDEの中で編集することもできる。
図3-3 Remote Controlのブロック図
Selenium Core単体で実施できるテストには限度がある。特に、バックエンドのデータベースへのテストデータの投入といった、テストの前処理・後処理などが実行できない。
Selenium Remote Controlを使うと、Perl/Ruby/Python/Javaなどのプログラム中からSeleniumのテストを実施することができる。ビジネスロジックのテストや、複数ブラウザからの操作が関係するテストなど、より複雑・大規模なテストを省力化する際に有効な機能である。
Selenium on Railsは、Ruby On Railsのアプリケーションを対象に、さらに簡易にSeleniumを使えるようにする拡張パッケージである。テストシナリオをより簡易なフォーマットで書いたり、セッションデータの自動消去を行ったりする機能を持つ。
Jmeterは、Apache Foundationによって開発・メンテナンスが行われているツールである。Apache License 2.0の元で公開されている。Jmeterの特徴は以下の通り。
JMeterは多彩な機能を持っており、サポートしているプロトコルだけでもHTTP/HTTPS/ftp/LDAP/JDBC/SOAP/JMS/AJP/POP3/IMAPなどがある。 本稿では、HTTPでのテストに絞って紹介する。
JMeterは複数のHTTPクライアントをエミュレートする（内部的にはJavaの複数のスレッドがそれぞれブラウザに相当することになる)。このとき、それぞれのHTTPクライアントは独立してクッキーを扱うことができるので、クッキーを利用したユーザー認証を行っているアプリケーションのテストも問題なく行うことができる。もちろん通信の負荷にもよるが、一台のLinuxで100台以上のクライアントをエミュレートすることも可能である。加えて、複数台のPCでJMeterを実行しておき、それらを一括して制御する機能も用意されている。Webアプリケーションのスケーラビリティの予測とテストは複雑な課題であるが、こういった機能をうまく使えば少ない機材でスケーラビリティの評価を行えるだろう。
JMeterでは、いわゆるテストシナリオのことをテスト計画（Test Plan）と呼ぶ。HTTPクライアントの動作は、テスト計画によって制御される。
図4-1 テスト計画
多くの場合、処理の基本的な流れは、
となるであろう。
テスト計画は基本的にGUIで編集するが、JMeter内蔵のプロキシ機能を使うと、ブラウザから行った操作をそのままJMeterのテスト計画として記録することができる。ブラウザから行った操作のうち、一度だけしか行わないものはそのままにしておき、複数回繰り返したい操作については後からループ要素を追加していけばよい。
JMeterでは、このようなテスト計画の中でさまざまなパラメータを使い、多様なテストケースを想定することができる。たとえば主なパラメータとして、
などが利用でき、CSVファイルで用意したデータを順次HTTPリクエスト中のパラメータとして送信することもできる。
図4-2 ループの設定
図4-3 スレッドの設定
より複雑なテストケースを実施したい場合（状況に応じてHTTPリクエスト中のパラメータを変化させたい場合など)には、組み込み関数やスクリプトを利用することができる。スクリプトの利用はJavaのBeans Scripting Frameworkによって実現されており、JavaScriptの実装系であればRhinoを利用することができる。
テストの実行結果は、レスポンスタイムおよびHTTPのリザルトコードで確認できる。レスポンスのデータそのものも保存することができるが、メモリを大量に消費するため、利用に際しては注意が必要となる。リザルトコードなどに基づいて、指定した場合にのみログを残すような設定も可能であり、長期間にわたるテストでごくまれに発生するようなエラーケースを捕捉するのに有効である。 テスト結果は、表やグラフで確認することができる。
図4-4 グラフによる結果表示
図4-5 表による結果表示
・テストのしやすさからコーディング・ルールを考える
SeleniumやJMeterに限らないが、テストツールは万能ではない。アプリケーションの作り方によって、テストシナリオの書きやすさや実施のしやすさ（=人件費）に大きな違いが出てくる。
Seleniumを例にとろう。
Seleniumでは、DOMエレメントへのアクセスが多用される。DOMエレメントにID属性やName属性を割り振っておけば、テストシナリオの作成は非常に楽になる。IDやName属性が降られていない場合は、DOMツリーをたどるような記述をしなければならなくなり、テストシナリオの作成やメンテナンスにかかる手間は非常に大きなものになってしまう。
したがって、使用するテストツールのクセや長所･短所を理解し、アプリケーションの設計やコーディング･ルールのレベルでテストにかかる工数を削減できるような工夫をしておくことがのぞましい。
・テストツールのカスタマイズ
オープンソースのツールの利点の一つは、「足りないものは自分で作ればよい｣ところである。SeleniumもJMeterも、ソースコードレベルで機能を追加するための仕組みを持っている。
Seleniumではテストシナリオ中に書くコマンドを追加することができるし（JavaScriptを使用する）、JMeterでは前述のスクリプトの使用に加え、Javaを使って独自のプロトコルへ対応するためのコードを書くことができる。
それでも足りない場合は、もちろん本体のコードを直接修正することもできる。ここまでくると、カスタマイズ可能な範囲とカスタマイズに要するスキル・知識とのトレードオフを十分検討する必要がある。
なお、どちらの製品についても充実したマニュアルと活発なユーザーのメーリングリストがあるので（英語ではあるが）、カスタマイズに手をつける前に、本当にそのカスタマイズが必要なのか・すでに代替え手段が存在していないかを十分調査するべきである。
・テストシナリオの自動生成
多くのテストパターンを構築する際に便利なのがExcelである。VBAやPython等のスクリプト言語を使うと、Excelのワークシートから直接データを読み出して変換することができる。
前述の通り、SeleniumではテストシナリオそのものがHTMLで書かれているし、JMeterではCSVを読みこんでその内容をパラメータとして使うことができる。やや複雑だが、JMeterのテスト計画ファイルそのものもXMLなので、外部のデータと合成してカスタムのテスト計画を生成することも比較的容易にできるであろう。
アプリケーションの複雑度にもよるが、画面仕様書の作成にExcelを使い、テストシナリオの自動生成するといった用途も考えられる。
・JavaのGCは要注意
JMeterはHTTPのレスポンスタイムを記録することができるが、注意が必要である。デフォルト設定のJava VMでJMeterを使うと、ガベージ・コレクションが走ったときにやや長い実行中断時間が生ずる（発生の頻度はテスト計画や実施状況による）。この期間はJMeterの動作が完全に止まってしまうので、実際にはHTTPのレスポンスがすぐに返ってきているにもかかわらず、記録上はレスポンスを返すのに長い時間がかかったかのように見えてしまう。
したがって、基本的にJMeterが計測するレスポンスタイムで極端に悪いものがあっても、それは必ずしもアプリケーションの問題とは限らない。厳密にレスポンスタイムを計測するのであれば、Java VMのGCログとつき合わせてJMeter側の問題で記録が悪くなっているケースを除外する、あるいはGCの設定を工夫して中断期間を生じさせないようにするといった工夫が必要である。
以上、Web2.0アプリケーションの特徴から要求されるテストの手法とツールについて述べた。
Web2.0アプリケーションのテストは活発な開発が行われている技術分野であり、新しい実装系も次々に登場している。開発の現場においては、新しい手法を取り込むことの利点とリスクのバランスは常に難しい問題であるが、技術動向に対してアンテナを常に高く持っておくことが、競争力を持つためには重要であることを述べておきたい。
本頁の著作権： Copyright (c) XML コンソーシアム 2007 All rights reserved. Copyright (c) Sky株式会社 2007 All rights reserved.