Webテストにおけるデータバインディング
ここまで見てきたさまざまな設定は、あらかじめ固定の文字列を設定しておくものがほとんどでした。通常アプリケーションのテストを行う場合にはさまざまな値の組み合わせを用いてテストを行うことがほとんどです。Webテストにはこの値の組み合わせを切り替えるための補助的な機能としてデータバインディングが用意されています。
データバインディングを用いることでCSVファイルやExcelファイル、AccessファイルなどOLE DB経由で接続可能なさまざまなデータソースをWebテストの入力として利用することができるようになります。また、OLE DBデータソースを利用したデータバインディングの設定はWebテストエディタで簡単に行うことができます。
しかし、データバインディングはWebテストのすべてに対して設定することはできないという点に注意が必要です。Webテストでデータバインディングが有効なものは、以下の4点になります。
- 資格情報の設定
- QueryStringパラメータ
- フォームフィールドパラメータ
- 要求URL
ここで、資格情報という言葉が初めて登場したので補足しておきます。Webテストの資格情報とは、対象のWebアプリケーションがIISの基本認証やWindows統合認証でユーザー認証を行っている場合に利用するものです。この設定を利用することによって、ASP.NETのForms認証を利用していないWebアプリケーションでもWebテストの実行が可能となります。なお、資格情報の設定はWebテストのプロパティから設定することができます。
それでは以下に、SQL Server 2005 Express Editionの「MSPetShop4Services」データベースの「dbo.aspnet_Users」テーブルからデータソースを作成し、あるフォームフィールドパラメータに「UserName」列をデータバインディングする設定の説明を行います。
- まず、データソースの追加を開始します。Webテストのメニューから［データソースの追加］を選択します。
図15 データソースの追加
- 開いたダイアログでOLE DBプロバイダを選択し、必要な設定を行います。ここでは、SQL Server 2005 Express EditionにWindows統合認証で接続し、MSPetShop4Servicesデータベースを選択しています。
図16 データソースの接続の設定
- 次のダイアログでは利用するテーブルを選択します。Excelを選択している場合はここにシート名が表示されます。ここでは「dbo.aspnet_Users」テーブルを選択しています。
図17 データソースのテーブルの選択
- データソースが作成されるとWebテスト内に図18のように表示されます。この状態で「dbo.aspnet_Users」テーブルの指定の列をデータバインディングすることができるようになります。
図18 データソースの追加の確認
- データバインディング可能なプロパティを開くと図19のような画面が表示され、任意の列を設定することができます（ここではSign Inの際のUser Nameのフォームフィールドパラメータにデータバインディングの設定を行っています）。
図19 データバインディングの設定
- データバインディングの設定がされている部分をWebテスト上で確認すると図20のように「{{データソース名.テーブル名.列名}}」といった表示されているのですぐに確認することができます。
図20 データバインディングの設定
この状態でWebテストを実行すると、データバインディングされたデータとして実際にどんな値が使用されたのかをテストの実行結果画面から確認することができます。
実際にデータバインディングの設定を行ったURL部分のコンテキストタブを確認すると名前欄に「データソース名.テーブル名.列名」という名前があり、値として「AdamBarr」が利用されていることを確認できます。
現在までの設定のままでは、何回実行しても毎回のように「AdamBarr」が利用されてしまいます。実は、データソースは利用方法を設定できるようになっており、以下の3パターンがあります。
| 設定値 | 説明 |
| 順次（Sequential） | 最初のレコードから読み取りを行い、1行ずつ順次読み取ります。 |
| ランダム（Random） | テーブル内の行をランダムに読み取ります。 |
| ユニーク（Unique） | 最初のレコードから読み取りを行い、1行ずつ順次読み取ります。 |
このようにデータソースの使われ方には3種類の方法がありますが、Webテストを行うだけではこの設定はあまり意味がありません。なぜなら、Webテストを実行する場合、そのテストは1度しか実行されず、2つ以上の行が利用されることがないからです。このデータバインディングの設定はWebテストよりもむしろ次回解説予定のロードテストのときに大きく影響してきます。ここでは、順次とユニークはまったく同じであるように見えますが、その差がどんなものであるかはロードテストの回に改めて解説します。
Webテスト機能の大切な注意
さて、VSTTのWebテストに関して、作成・カスタマイズ・実行の方法をいろいろとご説明してきました。Webテストの大雑把な使い方はご理解いただけたのではないでしょうか。
最後にWebテスト機能を使う上での大切な注意事項を示しておきます。それは、
「Webテスト機能はHTTPリクエストをキャプチャしてWebテストを作成する」
という点です。このため、一般的なテストツールがよく陥るような、「サードパーティ製コントロールに未対応のため、テストが正常に作成されない」といった問題は起きませんが、JavaScriptやActiveXなどクライアント側のみで動作するものに関してはテストすることができません。また、JavaScriptやActiveXが動作した結果、送信されるHTTPリクエストをキャプチャすることはできますが、XML HTTPリクエストはキャプチャすることができません。これは、AJAXを利用して動くWebアプリケーションのテストができないということを示唆しています。
このため、VSTTとは別のツールとして、「Fiddler」というツールも配布されています。Fiddlerはブラウザから送信されるHTTPリクエストや応答のHTTPレスポンスをキャプチャするツールで、XML HTTPリクエストもキャプチャすることができます。また、FiddlerでキャプチャしたHTTPリクエストはそのままVSTTのWebテストの形式に変換することもできます。現在のWebテスト機能でAJAX対応アプリケーションのWebテストを実施するにはこのFiddlerというものを用いることになります。
なお、もうまもなくリリースされるVisual Studio 2008 Team Systemに含まれるWebテスト機能には、Fiddler相当の機能が盛り込まれ、Webテスト機能単体として、AJAXアプリケーションのWebテストも作成、実行ができるようになっているとのことです。
まとめ
VSTTのWebテスト機能を利用した、Webアプリケーションテストの作成方法、実行方法、テストの検証方法をカスタマイズする方法などについて説明してきました。その名の通り、Windowsアプリケーションのテストには利用できない、Webテスト機能だけでは、AJAXアプリケーションのテストが実行できないなどの制約はありますが、Webアプリケーションのテストを行う上では有用なツールであることが少しはご理解いただけましたでしょうか。
Webテストだけではまだ足りない！ という場合には、次回解説予定のVSTTのロードテスト機能についてもぜひご覧ください。Webテストとロードテストを合わせて利用することで非常に強力な品質テストができるということをご理解いただけると思います。
