Microsoft Visual Studio 2005 Team System における Web テストの紹介

Mark Michaelis

September 2005
日本語版最終更新日 2006 年 2 月 22 日

適用対象:
Microsoft Visual Studio 2005 Team System
Web アプリケーション開発

要約: この記事では、Microsoft Visual Studio 2005 Team System の Web テスト機能を紹介し、Web テストのテストケースをどのように作成し、カスタマイズするかを説明します。

※記事の原文は「Introducing Microsoft Visual Studio 2005 Team System Web Testing」です。

はじめに
 個人の Web サイトの作成
 テストプロジェクトの作成
 Web テストケースの実行
 リクエストルール
 テストデータのデータソースへのバインド
 Web テストコードの生成
 VSTS の Web テスト機能の拡張
 ブラウザユーザーインターフェイスのテスト
 テスト駆動開発
 まとめ

はじめに

最近行われたあるミーティングで、私は Web テストは不可能なものであり、これをどのように行えばよいのかを割り出した者は誰であろうと顧客に多大な貢献をすることができる、と主張する開発チームに出会いました。マイクロソフトは既にリソースの確保については解決し、Microsoft Visual Studio Team System (VSTS)のリリースにおいて、Web テストに関するツールを提供します。この記事では、この機能についての概要を説明します。まずは、どのようにして Web テストケースを設定するのか、そして何のコードも書かずにいかにカスタマイズするかをステップごとに説明するアプローチをとります。これにより、開発者ではないメンバーを含めた全ての開発工程に関わる参加者に、VSTSのWeb テストのアプローチのし易さが示されます。Web テストケースは容易にコーディングすることもできるので、以下でどのように Web テストをコーディングすればよいか、ビルドイン Web テストサポートをどのように拡張すればよいかを説明します。

説明を始める前に、VSTS が提供する Webテスト機能はユーザーインターフェイスのテストを目的としたものではない、ということを認識しておく必要があります。これは、Web ページの JavaScript を走らせたり、複数のブラウザ内でのページの見た目を検証するものではなく、回線上で送られる HTTP データを調べ、このデータを検証するために必要な様々なルールを提供するものです。

まず始めに、記録を行う (テスト対象となる) Web サイトが存在する場合に限り VSTS のWeb テストはテストの手順を記録することができるので、テストを開始するに当たり対象となるWeb サイトとテストプロジェクトそのものを用意する必要があります。Web サイトを作成した後に、自動テストを加えます。 (完全にテスト駆動開発という訳ではありませんが、記録機能は非常に便利で、無視できるものではありません)。

個人の Web サイトの作成

この記事内でテストを行うサイトは、個人の Web サイトです。これは、Microsoft Visual Studio 2005 に付属するウィザードを使用して作成されたものです。以下は、サイトを作成するためのステップです。

[ファイル] メニューを選択し、[新規作成] から [Web サイト] を選択します。Visual Studio 2005 では、新しい Web サイトは、他の新しいプロジェクトオプションとは別のダイアログボックスにあるので注意して下さい。
[パーソナル Web サイトスタートキット] を選択し、プログラム言語を選択します。この記事では、Microsoft C# を使用します。

図 1. 新しい Web サイトの作成 (図をクリックすると拡大図が表示されます)

いったんサイトが作成されたら、新しいアカウントを作成します。全てが正しく動いていることを確認するため、ここでは手動で行います。後に、新しいアカウントを使用してそのサイトにログインする、自動テストを示します。

次の手順に進む前に、サイトを少なくとも一度実行します。これは、メンバシップおよびロールのデータベースを確実に初期化するためです。 (Ctrl キーを押しながら F5 キーを押すことで、サイトの実行を行えます)

Web サイト管理ツールを開始するには、 [Web サイト] メニューの [ASP.NET 構成] を選択します。
セキュリティ リンクをクリックし, 次に ユーザーの作成 リンクをクリックします。
テストユーザー情報を入力します。[ユーザーの作成] ボタンをクリックする前に、ロールとして [Administrators] を選択してください。電子メールアドレスは有効なフォーマットとし、パスワードは最低 1 文字の英数字以外を含んだ 7 文字となるよう注意して下さい。

※ ロールに [Administrators] と [Friends] が表示されない場合は、ユーザー作成の前に Ctrl キーを押しながら F5 キーを押し、Web サイトの実行を行ってみてください。

アカウントを作成した後に、ASP.NET 設定 Web サイトを閉じて下さい。

図 2. 新しいアカウントの作成

Visual Studio 内で Web サイトを立ち上げ、新しいアカウントを使用してログインし、全てが正しく動いているか検証することができます。

図 3. ログインの確認

デフォルトでは、Microsoft Internet Information Server (IIS) はサイトをホストしません。代わりに Visual Studio 2005 は、図 2 のシステムトレイ上に表示されているように、ASP.NET 開発サーバーを起動します。

図 4. ASP.NET 開発サーバーシステムトレイアイコン

通常 ASP.NET 開発サーバーは、無作為にポートを選択してそのポートを開き、その Web プロジェクトの名前と一致する仮想パスを使用し、そのポートからサイトをホストし始めます。ただし、ポートは Visual Studio の起動間で変更することもあり、その場合は元のポートに対してのテストは機能しなくなります。これを避けるために、ポートをある特定の値に固定することができます。

Visual Studio では、ポート番号を取得するためには、その Web プロジェクトのプロパティウィンドウ (F4 キー押下) を開いて下さい。これは、そのプロジェクトの [プロパティページ (Property Pages)] ダイアログボックスではなく、ドックウィンドウ (docked windows) であるという点に注意して下さい。動的ポートの使用 の値は、デフォルトで True です。
Visual Studio が別のポート番号を選択してしまうのを避けるためには、動的ポートの使用 オプションを False に設定して下さい。

図 5. 動的ポートの使用オプションの変更

Web サイトを立ち上げるもう 1 つのやり方は、WebDev.WebServer.exe を直接実行させることです。これは、そのサイトをホストするためのポート番号を特定する手段を提供します。コマンドラインは以下の通りです。

WebDev.WebServer /port:<port number> /path:<physical path> 
  [/vpath:<virtual path>]

このコマンドは、スタートメニューの全てのプログラムから、[Microsoft Visual Studio 2005] の [Visual Studio Tools] メニューの [Visual Studio 2005 コマンドプロンプト] を選択し起動する「Visual Studio 2005 コマンドプロンプト」から実行することが可能です。たとえば、以下のように個人の Web サイトを立ち上げることもできます。

start /B webdev.webserver.exe /port:4955 
  /path:"c:\documents and settings\MMichael\Local 
  Settings\Temp\HelloWorldWebSite"  /vpath:/HelloWorldWebSite

Start により、exit を待つのではなく、コマンドが確実に返ってくるようにします。

もし、どのポートもデフォルトで 80 に設定されていなく、しかし IIS が同じポートを使用して動いている場合、これは失敗します。Visual Studio 2005 を起動せずにビルド／テストスクリプトを起動させてしまうこともあるので、ある特定のポートを許可するのに加え、WebDev.WebServer.exe は重要です。

サイトが機能しているのを検証するのに際し、サイトのデフォルトページの URL (ポートと仮想ディレクトリを含む) を記録し、ブラウザウィンドウを閉じて下さい。Web テストケースを記録する際に、すぐにその URL を使用します。ただし、Web テストを行う前に、テストプロジェクトの作成が必要になります。

テストプロジェクトの作成

VSTS で単体テストを行う場合と同じように、Webテストを行うためには最初にテストプロジェクトを作成します。以下のステップにより、工程の概要が分かります。正常にテストを記録するためには、Web サイトは実行されている必要があります。

[ソリューション] を右クリックし、[追加] から [新しいプロジェクト] をクリックします。

(ソリューションが作成されていない場合、[ファイル]、[新規作成]、[プロジェクト] を選択します)

プログラム言語を選択し、[テスト] ノードを選択します。
プロジェクトに HelloWorldWebSite.Test という名前をつけます。

図 6. テストプロジェクトの作成 (図をクリックすると拡大図が表示されます)

既に最初の Web サイトは作成済みなので、そのサイトの活動を記録することにしましょう。

その作成されたプロジェクトが、Web テスト専用のプロジェクトだと特定するものは何もありません。そのため、該当のテストプロジェクトに追加するファイルは、他のテストファイルタイプ (単体テスト、ロードテスト、手動テスト、ジェネリックテスト、など) ではなく、Web テストファイルにしてください。次のステップは、したがって、Web テストケースを追加することです。テストプロジェクトに追加された他のタイプのテストファイル (手動テスト(ManualTest1.mht) や単体テスト (UnitTest1.cs)) は使用することはないので、削除してもかまいません。

プロジェクトを右クリックし、[追加] から [Web テスト] をクリックして下さい。これにより、Web テストリコーダーエクスプローラバーと共にブラウザが開きます。

図 7. Web テストケースの記録
アドレスバーに、ASP.NET 開発サーバーによって選択されたポートを含む、その個人の Web サイトの URL を入力して下さい。このサイトの閲覧は、その他の入力される URL と同じく、Web テストリコーダーエクスプローラバーに記録されます。
先ほど追加されたユーザー名とパスワードを入力して下さい。[ログイン] ボタンをクリックする際に、フォームポストパラメータと共に、もう 1 つのエントリが記録されます。このようにして、テストの実行時に同じデータが自動的に送られます。ボタンのどこがクリックされたのかを示す X 座標と Y 座標でさえ、リクエストとしてサブミットされたので、テストの一部として保存されます。
サイトからログアウトし、再度無効な方法でログインを試みるステップを、テストに追加して下さい。
望ましいテストが記録されたら、ブラウザウィンドウを閉じてテストを保存して下さい。

自動的に、プロジェクトにはそれぞれの記録されたリクエストと共に Web テストケースファイルが含まれます。

図 8. 記録された Web テストケースの閲覧

WebTest ツリー内の任意のノードを選択することにより、[プロパティ] ウィンドウ内のデータを修正することができるようになります。

トランザクションを使用してリクエストをグループ化することもできます。プログラミングの概念である、ユニットとしてステートメントがコミットされたかされていないか、という "トランザクション" という用語と混同しないように注意して下さい。Web テストケースでは、トランザクションとは、後にコードを使用して列挙される、1 つのグループにカプセル化するというアクションのみを意味します。また、トランザクションは、たとえば実行時に毎秒ごとにいくつのトランザクションがあるかということを、レポートする際にも使用されます。

もう 1 つのポイントとして、それぞれのリクエストや Web テストケース全体に加えておくべき点として、コメントというものがあります。これをおこなうには、[リクエスト] を右クリックし、[コメントの挿入] をクリックします。コメントはリクエストの間に現れ、サブミットされたデータをドキュメント化する手段を提供し、後に付け加えられるレスポンスの検証も行います。

Web テストケースの実行

テストを記録すれば、実行の準備は整ったことになります。プロジェクト内の全てのテストを実行するには、単にプロジェクトを実行すればよいだけです。これによりテスト結果ウィンドウが開き、実行中のテストには保留のマークが付き、実行が完了した際には、成功／失敗を表示します。テストの選択と実行は、「テストマネージャ」と「テストビュー」で行うことができます。

図 9. テストの選択と実行

個別の Web テストファイル (テストケース) は、ファイル (たとえば、WebTest1.webtest ファイル) を開き、表示された情報の上部にある [テストの実行] ボタンをクリックすることにより実行することもできます。

図 10. Web テストの設定ダイアログ ([テストの実行構成の編集] から立ち上げたところ)

リクエストは、標準の認証方法を使用して、ターゲットとなるサイトへのログインの資格を提供することもできます。ログイン資格のダイアログは、データソースからログインデータをロードすることができます。

また、テストを実行した際、それぞれのリクエストからの結果は保存され、それぞれのリクエストの選択により詳細を操作することが可能になり、結果ページの HTML もしくはそのままのリクエスト/レスポンステキストを見ることができるようになります。

図 11. テスト結果ビューア

テスト実行の一部として、Web テストエンジンはページ上の全ての URL をチェックし、それらが有効なリンクであることを確かめます。これらのリンクはリクエストの下に子ノードとして現れ、その URL へのリクエストから返されてくる HTTP ステータスを表示します。

リクエストルール

レスポンスページ上の有効なハイパーリンクのチェック機能は便利な機能ですが、そのページが正常に動いているかを確かめるには十分ではありません。たとえば、有効な資格を入力する際、Web テストはログインが成功したかどうかを検証しなければなりません。似たように、資格が無効な場合、そのページに適切なエラーメッセージが表示されているかどうかをチェックしなければなりません。これをサポートするため、それぞれの Web リクエストは抽出規則と検証規則を含めることができます。

抽出規則

抽出規則は特定のページにおける返り値を捕らえ、後に別のリクエストにおいてその値を使用することができます。手動で HTTP レスポンス全体を解析するのではなく、抽出規則はレスポンス内の特定のデータ項目に注目する手段を提供します。抽出データ項目は、続いて起こるポストバックにおいて、検証されるか再度使用されます。ここで紹介する例では、ログイン時に自動的に抽出規則に加えられます。

図 12. 抽出規則はリクエスト間でのリンク化が可能

このルールは、Web テストケースで、データが 2 番目のリクエストでポストバックされる、非表示のフィールドから抽出 (ExtractHiddenFields) というルールです。続いて行われるテストの間、このデータはページの隠れたフィールドに戻されます。この他の抽出規則オプションは、属性値の抽出 (ExtractAttributeValue) 、HTTPヘッダーの抽出 (ExtractHttpHeader) 、正規表現の抽出 (ExtractRegularExpression) 、およびテキストの抽出 (ExtractText) 等です。隠れたフィールドに自動的に行われる記録に頼るのではなく、抽出規則は必要に応じて手動で加えられ、カスタマイズすることができます。 (詳しくは、MSDN Library の「Web テストの操作の概要」の「方法：Web テストに抽出規則を追加する」を参照下さい)

検証規則

検証規則により、テスト作成者は HTTP レスポンス全体を調査し、それが正しいかどうかを検証することができます。たとえば、有効な資格はログアウトリンクを表示させ、HTML レスポンスに "ようこそ <username>" が表示されます。レスポンス内のこれらの項目をチェックする検証規則を加えて下さい。検証規則は、レスポンス本体のどこかに現れるこのテキストを検証します。

図 13. "ログアウト" の文字が含まれるかをチェックする検証規則

ある特定のルールが失敗した場合は、リクエストは失敗とマークされ、[詳細] タブにより、何が失敗したのかが説明されます。

図 14. 検証規則の結果の表示

このタイプの検証規則は、検索テキスト (ValidationRuleFindText) と呼ばれます。これはレスポンス body 全体を検索し、特定のテキストを探します。複雑な検索を操作するために、通常の表現が検索テキスト (ValidationRuleFindText) の一部としてサポートされます。

検索テキスト (ValidationRuleFindText) に加えて、最大要求時間 (ValidationRuleRequestTime) 、必要な属性値 (ValidationRuleRequiredAttributeValue) 、および必要なタグ (ValidationRuleRequiredTag) 等のあらかじめ用意された (ビルドイン) 検証規則があります。

テストデータのデータソースへのバインド

検証規則、抽出規則の双方供に、仮想的に全てのノードのプロパティウィンドウ内にテキストエントリを提供します。しかしながら、Visual Studio のWebテスト機能がをパワフルなのは、必要なテキストをデータベースから持ってこれるという点です。ここで示しているログインの例では、正しいパスワードの要件を満たしていない不正なパスワードの集合と新しいユーザーをデータとして用意し、これらが許可されてはならない、ということを確認できます。

データソースを使用してテストを行うには、Web テストのツールバーの [データソースの追加] をクリックして下さい。次のダイアログボックスで、OLE DB プロバイダをしていし、例えばテストプロジェクトに追加することができる *.mdf ファイルを指定してください。サーバーエクスプローラを利用し、必要なテストデータを含むテーブルを定義することも可能です。図 15 では、プライマリキーとしてユーザー名とパスワードのカラムを持った TestUser を使用します。

図 15. データソースへのパラメータの割り当て (サーバーエクスプローラでデータを作成し、データソースへの接続を行った後、データソースからのデータを利用したいパラメータのプロパティを開き"値"の項目で、データの指定を行った)

データソースとともにテストが設定されたら、[テストの実行構成の編集] ダイアログボックス (図 10 を参照) に戻り、実行カウントをデータソース行ごとに 1 つ実行に変更する必要があります。このようにして、新しく設定されたデータソースの行毎に Web テストが繰り返され、それぞれの実行の間、データソースに関連付けられたパラメータが、特定の行と列に値を割り当てます。

Web テストコードの生成

今まで説明してきた機能を利用していれば、コードを書く必要はありません。しかし、コードを使用した追加の Web テストカスタマイズを使用することもできます。これは、テスト内でのループや分岐などの構成や、他の Web テストをコールする際に必要になります。VSTS の Web テストはこのような用途に応えるため、テストケースのコードを生成するための機能を提供します。Web テストケースのツールバーに含まれている、[コードの生成] というボタン、あるいはメニューに[コードの生成]があります。これを指定すると、[コード化された Web テストの生成]ダイアログが表示され、C# や VB でのコードにより記述された Web テストが生成されます。生成されたコードは、追加されたそれぞれの検証と抽出規則を含みます。加えて、Web テストの一部として、ビューステートのようなデータがセットされ、渡されます。前述の、テストケースから生成されたコードは以下のようになります。

namespace HelloWorldWebSite.Test
{
  using System;
  using System.Collections.Generic;
  using Microsoft.VisualStudio.TestTools.WebTesting;
  using Microsoft.VisualStudio.TestTools.WebTesting.Rules;

  public class LogonCoded : WebTest
  {

      public LogonCoded()
      {
      }

      public override IEnumerator<WebTestRequest> GetRequestEnumerator()
      {
          WebTestRequest request1 = 
               new WebTestRequest("http://localhost:4955/HelloWorldWebSite");
          request1.ThinkTime = 17;
          ExtractHiddenFields rule1 = new ExtractHiddenFields();
          rule1.ContextParameterName = "1";
          request1.ExtractValues += 
               new EventHandler<ExtractionEventArgs>(rule1.Extract);
          yield return request1;

          // デフォルトページへリダイレクト

          WebTestRequest request2 = 
               new WebTestRequest(
               "http://localhost:4955/HelloWorldWebSite/default.aspx");
          request2.ThinkTime = 7;
          request2.Method = "POST";
          BindHiddenFields request2BindHiddenFields = 
               new.BindHiddenFields();
          request2BindHiddenFields.HiddenFieldGroup = "1";
          request2.PreRequest += 
               new EventHandler<PreRequestEventArgs>(
               request2BindHiddenFields.PreRequest);
          FormPostHttpBody request2Body = new FormPostHttpBody();
          request2Body.FormPostParameters.Add(
               "ctl00$Main$LoginArea$Login1$UserName", "Administrator");
          request2Body.FormPostParameters.Add(
               "ctl00$Main$LoginArea$Login1$Password", "G00d-P@ssw0rd");
          request2Body.FormPostParameters.Add(
               "ctl00$Main$LoginArea$Login1$LoginButton.x", "45");
          request2Body.FormPostParameters.Add(
               "ctl00$Main$LoginArea$Login1$LoginButton.y", "5");
          request2.Body = request2Body;
          ValidationRuleFindText rule2 = new ValidationRuleFindText();
          rule2.FindText = "Administrator";
          rule2.PassIfTextFound = true;
          request2.ValidateResponse +=
               new EventHandler<ValidationEventArgs>(rule2.Validate);
          ValidationRuleFindText rule3 = new ValidationRuleFindText();
          rule3.FindText = "LOGOUT";
          rule3.PassIfTextFound = true;
          rule3.IgnoreCase = true;
          request2.ValidateResponse += 
               new EventHandler<ValidationEventArgs>(rule3.Validate);
          ValidationRuleRequestTime rule4 = 
               new ValidationRuleRequestTime();
          rule4.MaxRequestTime = 500;
          request2.ValidateResponse += 
               new EventHandler<ValidationEventArgs>(rule4.Validate);
          yield return request2;

          // 有効な資格でログオンし、正常なログオンを検証する

          WebTestRequest request3 = 
               new WebTestRequest(
               "http://localhost:4955/HelloWorldWebSite/default.aspx");
          request3.ThinkTime = 17;
          request3.Method = "POST";
          FormPostHttpBody request3Body = new FormPostHttpBody();
          request3Body.FormPostParameters.Add(
               "__EVENTTARGET", "ctl00$LoginStatus1$ctl00");
          request3Body.FormPostParameters.Add(
               "__EVENTARGUMENT", "");
          request3Body.FormPostParameters.Add(
               "__VIEWSTATE", ...);
          request3.Body = request3Body;
          ExtractHiddenFields rule5 = new ExtractHiddenFields();
          rule5.ContextParameterName = "1";
          request3.ExtractValues +=
               new EventHandler<ExtractionEventArgs>(rule5.Extract);
          yield return request3;

          // ログアウト

          WebTestRequest request4 = 
               new WebTestRequest(
               "http://localhost:4955/HelloWorldWebSite/default.aspx");
          request4.Method = "POST";
          BindHiddenFields request4BindHiddenFields = 
               new BindHiddenFields();
          request4BindHiddenFields.HiddenFieldGroup = "1";
          request4.PreRequest += 
               new EventHandler<PreRequestEventArgs>(
               request4BindHiddenFields.PreRequest);
          FormPostHttpBody request4Body = new FormPostHttpBody();
          request4Body.FormPostParameters.Add(
               "ctl00$Main$LoginArea$Login1$UserName", "IMontoya");
          request4Body.FormPostParameters.Add(
               "ctl00$Main$LoginArea$Login1$Password", "bad-password");
          request4Body.FormPostParameters.Add(
               "ctl00$Main$LoginArea$Login1$LoginButton.x", "64");
          request4Body.FormPostParameters.Add(
               "ctl00$Main$LoginArea$Login1$LoginButton.y", "10");
          request4.Body = request4Body;
          ValidationRuleFindText rule6 = new ValidationRuleFindText();
          rule6.FindText = "LOGIN";
          rule6.IgnoreCase = true;
          rule6.PassIfTextFound = true;
          request4.ValidateResponse += 
               new EventHandler<ValidationEventArgs>(rule6.Validate);
          ValidationRuleFindText rule7 = new ValidationRuleFindText();
          rule7.FindText = "LOGOUT";
          rule7.IgnoreCase = true;
          rule7.PassIfTextFound = false;
          request4.ValidateResponse += 
               new EventHandler<ValidationEventArgs>(rule7.Validate);
          yield return request4;

          // 無効な資格を使用してログオンし、
          // ログオンの失敗を検証
      }
  }
}

C# のプロジェクトでは、新しい C# 2.0 のイテレータが使用されます。それぞれのリクエストの後に、コードは、1 つのリクエストを次のリクエストに分ける yield return ステートメントを通じて、次の Web リクエストを返します。

カスタマイズされないのであればコードを生成する理由がないのは明らかですが、コードの生成は特定の Web テストケースをカスタマイズする上でのよいスタートポイントであり、複数のサイトで実行する場合でも作業の重複が少なくて済みます。

VSTS の Web テスト機能の拡張

利用できるリクエストルールと、作成された Web テストからカスタムコードを書く機能により、Web テストシナリオの大部分はカバーされます。ですが、場合によっては個別の検証と抽出規則を作成したり、個別の Web テストプラグインをコーディングして、VSTS の Web テスト機能を拡張した方がよい場合があります。このような拡張は、別のアセンブリで定義されなければならないのですが、複数の Web テストプロジェクトに渡って使用することができます。一度定義されたら、新しい拡張 Web テストのアセンブリはその Web テストプロジェクトから参照され、[追加] ダイアログボックスのリクエスト選択に表示されます。

ダイアログボックスは、検証と抽出規則に使用できるだけでなく、リクエストとテストのプラグインにも使用されます。リクエストコールバックはリクエスト毎に別々に加えることができ、リクエストのプレインターセプションとポストインターセプションを実行します。テストコールバックは、リクエストの全体の中で、プレインターセプションとポストインターセプションコードを実行します。これらはまず始めにテストケースの最初でコールされ、同じテストケースの最後で再びコールされます。たとえば、テストの全ての Web ページが XHTML に従っているか、あるいはそれぞれの Web リクエストで cookie を設定しているかをチェックするコールバックを定義する場合を考えて下さい。この検証を実行するプラグインがリクエストコールバックだった場合、テスト内のそれぞれのリクエストに別々に追加することができます。あるいは、そのコールバックは、テスト実行前の段階での全てのリクエストの検証と関連付けられた、テストコールバックにもなり得ます。以下に Web テストコールバックを生成する手順を示します。

WebTestFramework という名前の新しいクラスライブラリプロジェクトを生成します。
Microsoft.VisualStudio.QualityTools.UnitTestFramework と Microsoft.VisualStudio.QualityTools.WebTestFramework への参照を追加します
Microsoft.VisualStudio.TestTools.WebTesting.WebTestPlugin を継承する ValidationRuleXHTML という新しいクラスを定義します
PreWebTest() と PostWebTest() abstract メソッドを実装します

これらの 2 つのメソッドは、sender を最初のパラメータとし、 PreWebTestEventArgs/PostWebTestEventArgs を 2 番目の項目とする、標準イベントに従っています。以下にあるのはサンプルの Web テストプラグインクラスで、どのようにして XHTML 検証を作成するかを示しています。

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.VisualStudio.TestTools.WebTesting;
using System.Diagnostics;

namespace WebTestFramework
{

    public class ValidationRuleXHTML : WebTestPlugin
    {
        public override void PostWebTest(object sender, PostWebTestEventArgs e)
        {
            // PostWebTest は今回は不要
            // ベースとなるクラスが抽象メソッドであるために、実装のみ作成しておく
        }

        public override void PreWebTest(object sender, PreWebTestEventArgs e)
        {
            // テストの範囲内で、それぞれのPostRequest にイベントコールバックを登録
            e.WebTest.PostRequest += WebTestPostRequest;
        }

        void WebTestPostRequest(object sender, PostRequestEventArgs e)
        {
            // Response を確認し、そのHTMLが有効なXHTMLであるかチェック
            
       　　 // [参考] Response をイベントログに書き込むサンプル
            EventLog log = new EventLog();
            log.Source = "Application";
            log.WriteEntry(e.Response.BodyString, EventLogEntryType.Information);
            
        }

    }
}

この例では、PreWebTest() がおこなうのは、PostRequest イベントのデリゲートである (WebTestPostRequest()) を登録しているだけです。この方法で、Web テストエンジンからリクエストが生成されたらいつでも、登録されたデリゲートリスナを呼び出します。そのデリゲートの PostRequestEventArgs パラメータは、string BodyString プロパティを提供する、Response プロパティを含みます。この最後のプロパティは、XHTML をチェックする際のレスポンス本体への必要なアクセスを提供します。XML validators のようなものに対する注意点として、ロードテストを実行する際、ロード (負荷) 生成能力に大きな影響を与える、という点があります。多大なリソースを必要とするような検証テストは、ロードテストシナリオでは使用されない、単体テストに限られるべきです。

Web テストプラグインをビルドするためのオブジェクトモデルを図 13 に示します。

図 16. Web テストプラグインオブジェクトモデル (図をクリックすると拡大図が表示されます)

このモデルでは、Web テストプラグインでどのような機能にアクセスできるか、そしてどの検証が Web テストプラグインで提供されているのかを説明します。Pre/PostWebTest メソッドでは、Web テストケースの情報に全体としてアクセスでき、たとえば、証明済みの情報と供にテストに関連付けられたデータソースなどにアクセスできます。恐らくもっとも重要なのは、これらのメソッドはリクエスト毎に関連付けられる XHTML validator コールバックを可能にする、Pre/PostRequestEvent にアクセスを提供するという点です。

PreRequestEvent と PostRequestEvent 双方共に、(それぞれの EventArgs クラスを通じて) WebTest オブジェクトへのアクセスを提供します。これらは、リクエスト自体の詳細情報へのアクセスを提供するために、WebTestRequest オブジェクトへのアクセスも提供します。[PostRequestEventArgs] プロパティには、リクエストから返されたデータの調査を可能にする、WebTestResponse オブジェクトへのアクセスも含まれます。

カスタマイズされた検証、抽出規則も可能であると前述しました。このようなルールを作成するためには、Microsoft.VisualStudio.TestTools.WebTesting.WebTestPlugin や Microsoft.VisualStudio. TestTools.WebTesting.WebTestRequestPlugin の代わりに、Microsoft.VisualStudio. TestTools.WebTesting.ValidationRule および Microsoft.VisualStudio. TestTools.WebTesting.ExtractionRule から引き出します。ルールベースクラスの概要を図 17 に示します。

図 17. カスタマイズされた検証、抽出規則を使用した拡張

ValidationEventArgs および ExtractionEventArgs クラスは、Validate() および Extract() メソッドそれぞれのルールの、タイプパラメータです。個別のリクエストを扱う際は、これらのイベント構文は、プラグインの複製よりも、リクエストに関連したデータへのダイレクトアクセスを提供します。さらに、IsValid のようなプロパティは、前述の Web テストプラグインの例外メカニズムにわたすよりもずっとよいレポーティングの手段を提供します。しかしながら、前述の通り、ルールは全体のテストに渡ってではなく、個別のリクエストベースで挿入されなければなりません。プラグインアプローチのもう 1 つの利点は、リクエストそのものを奪うことができるという点です。リクエストが生成された後と、レスポンスが返された時に呼び出されるだけではないのです。要するに、全てのリクエストに渡って検証が提供されたり、リクエストがサーバーに送られる前に奪う必要がない限り、検証と抽出規則を使用して下さい。

ブラウザユーザーインターフェイステスト

JavaScript を通じてのリクエスト、ActiveX コントロールとアプレットは VSTS Web テスト機能ではサポートされていません。同様に、VSTS Web テストはユーザーインターフェイス (UI) テストツールとして設計されている訳ではありません。クライアント側の JavaScript を実行し、結果を検証することはできません。クリックにより詳細メニューを拡張するタイプのシンプルなアクションでさえも、ツールによりシミュレートすることができません。サーバーに対して特定のブラウザクライアントをシミュレートしますが、Microsoft Internet Explorer の時でさえ、クライアントブラウザ内で返されるレスポンスの検証という点では何もしません。VSTS Web テストはネットワーク接続を前提としたテストプロトコルです。回線を通じて何が送られ、何が返されたかを検証しますが、ブラウザからどのようにしてデータが返されたかをテストする、ビルドイン機能は提供されません。

このようなタイプのテストを提供するのは難しく、困難でもあります。しかし、幾つかの状況に対して使用できるメソッドも存在します。同一のレスポンスが複数回発生し、そのブラウザ内で同様に値を返し、機能すると仮定するのは妥当なことです。したがって、たとえば JavaScript が正常に動作しているかチェックし、ページが正常に返されているかをチェックなど、ある特定のレスポンスが正しいかどうかを手動で検証するのであれば、次回も同じレスポンスが正常に動作すると考えることができます。この原理を使用し、視覚的にレスポンスを検証でき、スクリプトが正常に動作していると手動でチェックできます。データタイム、ユーザー名、広告、のバリアンスなどのマイナーなデータ変更はワイルドカードを使用してハンドルすることにより、類似のレスポンスをチェックする検証テストを作成することができます。もし、後にページが変更した場合にテストを実行する場合は、レスポンスは再検証され、テストも更新されるべきで、したがってページにコントロールの変更のレベルが提供されなければなりません。これはチームが大量に導入するようなものではありませんが、よいベースラインテストメカニズムを提供し、コントロールされたバリエーションを実現できます。

テスト駆動開発

この記事では、テストを始めに書きページがそのテストの条件を満たすという、テスト駆動開発 (TDD:Test-Driven Development) ではなく、既存の Web サイトをテストしてきました。テスト駆動の方法を使用しなかった大きな理由は、VSTS Web テストの記録機能です。「Web テストレコーダ」機能はリクエストごとに手動で URL を入力するのではなく、Web サイトを閲覧し、それぞれのリクエストをテストに自動的に保存します。

記録機能は、それぞれのリクエストを手動で入力するのに比べ、遥かに効率のよい機能です。しかしそれでも、テスト駆動のアプローチの利点を活かすことは可能です。まず第一にページを設計し、リクエストを処理するためのリンクを設定し、リクエストをサブミットするボタンを設置します。これ以外のコーディングは最小限に留めるべきです。次に、サイト周りのナビゲーションを記録し、テストケース構造に適切なリクエストを加えていきます。最後に、Web テストケースを開き、検証と抽出規則を含むように修正します。この時点で Web テストを実行すると、ルールを満たすコードがまだ加えられていないので、結果は失敗となるはずです。したがって、TDD アプローチで指示されているように、テストを書くことからコードを書くことに進みましょう。

たとえば、TDD を使用したログインシナリオを考えてみましょう。始めに、開発者はログインページを作成し、認証をサブミットする [ログイン] ボタンを設置します。次に、「Web テストレコーダ」を開き、リクエストの記録を行います。実装する前に、ユーザー ID がレスポンスに表示され、ログアウトリンクがあることを確かめるために、スタブに確認を加えます。この時点でのテストの実行でテストに失敗したことが明らかになり、何をテストしたかの記述を行います。

まとめ

この記事では、VSTSのWeb テスト機能について概要を説明しました。対象となる Web サイトに対する活動を記録することによって生成された Web テストケースの作成方法、ならびにそれを含むテストプロジェクトの作成の仕方について説明しました。これにより VSTS のWeb テストが、いかに容易にセットアップでき、いかに効率的にテストケースの作成を行えるかを学びました。これは、テストエンジニアがソフトウェアへのアクセス/テストができるような状態になるまで待つのではなく、開発チームが開発サイクルの早い段階でテストを開始できる有効な機能です。

VSTS のWeb テストは、記録だけでは終わりません。記録テストを拡張する、大きな可能性もあります。テストコードを生成する機能は、特別なカスタマイズが必要な時のコードテストへの移行を容易にします。コードは単純なもので、多くの開発者が Web テストケースを作成するさいに、マウスでの UI ではなく、このコードに頼ることになるでしょう。とにかく、VSTS の Web テストの拡張はシンプルに可能ですので、テスト機能の追加/拡張を行う開発者の皆様に素晴らしいテストのプラットフォームを提供します。

Top of Page

Microsoft Visual Studio 2005 Team System における Web テストの紹介

目次

はじめに

個人の Web サイトの作成

テスト プロジェクトの作成

Web テスト ケースの実行

リクエスト ルール