第7回 オープンソースの自動化テストツール「Jameleon」の概要：理論的、計画的なWebアプリケーションのテストの実現（1/2 ページ）

この連載では、さまざまなテストプロセスがあることを説明してきた。今回は、自動化に向いている機能テストを考えつつ、それを実現するオープンソースのフレームワーク「Jameleon」を紹介しよう。

[加藤大受，ITmedia]

　「テストの自動化」と聞いて、多くの人が真っ先に思い浮かべるのが、JUnitなどのxUnitを利用した単体テストだと思います。JUnitはJavaの単体テストのフレームワークとして最も有名なもので、JUnitを利用することで、単体テストの自動化を簡単に実現できます。

　すでに、この連載の中でさまざまなテストプロセスがあることを説明してきました。前回からかなり時間が経ってしまったので、これまでの連載を読み返し、テストプロセスの種類を再度確認してみるのもいいでしょう。

　単体テストはホワイトボックステストの一部であり、単体テストで確認できる内容は、対象のクラスやモジュールが仕様書で要求された機能や性能を満たしているかどうかであり、機能レベルで確認できるのは単機能となります。また、JUnitによる単体テストというと、各クラスのPublicメソッドの確認で終わっていることが多く、HTTPレベルやスタブを利用してのDB連携のテストなどのテスト設計まで考慮されていることは少ないのではないでしょうか。単体テストを自動化することで、ビルドプロセスの中に単体テストを組み込むことができるだけでなく、最低限の機能確認を自動的に行え、生成されたビルドの品質を数値化できます。

　JUnit以外にも数多くのフレームワークや自動化テストツールがあり、製品もオープンソースのものから商用製品まで数多く存在します。また、負荷検証ツールなどにおいても事前にスクリプトなどを用意することでテストを自動化できる製品も存在しています。

　この連載ではWebアプリケーションを前提に話を進めているため、機能テストの自動化を実現できるオープンソースのフレームワーク「Jameleon」と、Webアプリケーションの自動化ツールとして非常に有名なMercury Interactiveの「Mercury Quick Test Professional」の2製品を例に挙げ、同じWebアプリケーションの機能テストを行います。

機能テストの自動化の利点

　すべての機能テストを自動化すれば品質が上がるのかというと、それは間違いです。テストはプロジェクト内の限られたスケジュールの中で行われるものであり、やはり効率と優先度が重要になります。では、どのような機能テストを自動化すればよいのでしょうか。筆者が考える自動化に向いている機能テストは次のようなものです。

1. Webアプリケーションを利用するのに必ず行わなければならない処理
2. 同じアクションで複数の値の選択パターンがある処理
3. 優先度が高い機能を伴う処理
4. 不具合の発見された機能を伴う処理
5. 同一の処理を異なるOSやブラウザで実行する必要があるWebアプリケーション

　このほかにもプロジェクトによっては、自動化した方が良い処理も存在すると思いますが、ここでは5つのケースについて説明します。

　まず、「Webアプリケーションを利用するのに必ず行わなければならない処理」とは、Webアプリケーションを利用するために必須のシステム設定や利用ユーザーの登録処理などです。これらの処理が正しく動作しないと、Webアプリケーションが利用できないだけでなく、テストも開始できないため、常に確認する必要がある処理です。

　「同じアクションで複数の値の選択パターンがある処理」とは、複数のリストボックス、チェックボックス、テキストボックスからなる検索オプションなどの処理です。組み合わせを考えると非常に多くのパターンがある定型の処理は自動化することで、すべてのパターンをテストできます。

　「優先度が高い機能を伴う処理」とは、Webアプリケーションを利用するのに最低限動いていなければならない処理、つまり、常にテストしなければならない機能の組み合わせです。この優先度の高い機能を自動化し、単体テストと同様にビルドプロセスに組み込むことで、ビルドの品質をすぐに数値化でき、テスト対象となるビルドかそうでないかを即座に判断できます。この連載の中で何度も書いていますが、テストは常に優先度を考えて設計しなければならず、この優先順位の高い機能を組み合わせたテストの自動化は、テスト作業の効率を非常に高くするものです。

　「不具合の発見された機能を伴う処理」はその名のとおり、数々のテストによって発見された不具合の再現手順を自動化したものです。不具合の修正確認を自動化することで、修正された不具合が特定のビルドから再発するなどの問題をすぐに見つけることができます。できれば修正確認だけでなく、修正によって影響する機能などを含めた影響範囲確認を入れることで、そのほかの不具合の修正による新たな不具合を簡単に見つけ出すことができます。つまり、リグレッションテスト（回帰テスト）を自動化するということです。

　最後の「同一の処理を異なるOSやブラウザで実行する必要があるWebアプリケーション」とは、Webアプリケーションの動作環境の組み合わせテストに、自動された回帰テストを利用するということです。OSとWebサーバの組み合わせであれば、HTTPレベルでのテストでも意味はありますが、各種Webブラウザでの機能テストの場合では、自動化テストツールがブラウザを操作する機能を持っている必要があります。

　ここでは機能テストを自動化するメリットがある5つのケースについて説明しま従、この5つのうち1つでも実現するだけでもテスト効率は高くなっていくと思われます。自動化を実現するにはツールの深い理解と自動化に適した処理の選択、合否判定のポイントをどのように設定するかという問題がありますので、いきなり、すべてのケースについて自動化を考慮するのではなく、少しずつ実現していって欲しいと思います。自動化することでスケジュールが遅れたり、作業効率が落ちたりするのは本末転倒です。

合否の判定について

　手動で機能テストを行う場合、テスト結果が正しいか正しくないかは目視で確認できますが、自動化した場合、テストの合否をどのように判断するかを決める必要があります。多くの場合は次のようなケースで合否を判断します。

• 入力した値、選択した項目を送信後のページにも含まれている
• 入力した値、選択した項目を送信後、指定されたページに遷移した。または、指定されたエラーが表示された
• リンクを選択し、指定されたページに遷移された
• 入力した値がエラーとなりエラーメッセージまたはエラーウィンドウが表示される

　遷移によって合否を判断する場合は、遷移後のページのタイトルやHTMLの中に含まれる文字列で合否を判断できます。同様に、リンクをクリックした場合も遷移後のページが正しいかどうかを同じ方法で判断できます。JavaScriptsを利用し、クライアントサイドで入力値のチェックをしている場合は、エラーメッセージが表示されたか、あるいはエラーウィンドウが表示されたかによって合否を判断できます。

　このように、手動でテストした場合と異なり、目視で確認ができないため、自動化された場合は必ず何らかの合否のポイント、遷移後のページに含まれている値やエラーメッセージ、エラーウィンドウなどによってテストの合否を判断する必要があります。また、一つのメッセージを利用しての合否判定は本当にテストが合格したかを決めるのには情報が足りなすぎるので、実際は複数のメッセージやページタイトル、HIDDEN属性の変数などを利用して、合否を判断する必要があります。

次ページ：Jameleonについて