ブラウザ機能部からサーバへのファイルアップロードを代理するファイルアップロードの代理方法であって、前記ブラウザ機能部から入力されるリクエストの記述内容と、リクエストの記述内容に対して、ファイルデータを特定する情報を含む予め定められた規則を格納する規則テーブルとに基づいて、前記サーバにアップロードするファイルデータを特定し、当該ファイルデータを前記リクエストに埋め込む埋め込み工程と、前記ファイルデータが埋め込まれたリクエストを前記サーバに送信する送信工程と、をコンピュータが実行することを特徴とするファイルアップロードの代理方法。前記規則テーブルにおいて前記リクエストの記述内容に適合する規則が存在していない場合に、当該記述内容に適合する規則の入力支援画面を表示する表示工程を、前記コンピュータに更に実行させることを特徴とする請求項1に記載のファイルアップロードの代理方法。コンピュータに、ブラウザ機能部からサーバへのファイルアップロードを代理させるファイルアップロードの代理プログラムであって、前記ブラウザ機能部から入力されるリクエストの記述内容と、リクエストの記述内容に対して、ファイルデータを特定する情報を含む予め定められた規則を格納する規則テーブルとに基づいて、前記サーバにアップロードするファイルデータを特定し、前記リクエストに埋め込み、前記ファイルデータが埋め込まれたリクエストを前記サーバに送信する、処理をコンピュータに実行させるファイルアップロードの代理プログラム。ブラウザ機能部からサーバへのファイルアップロードを代理するファイルアップロードの代理装置であって、前記ブラウザ機能部から入力されるリクエストの記述内容と、リクエストの記述内容に対して、ファイルデータを特定する情報を含む予め定められた規則を格納する規則テーブルとに基づいて、前記サーバにアップロードするファイルデータを特定し、当該ファイルデータを前記リクエストに埋め込む埋め込み部と、前記ファイルデータが埋め込まれたリクエストを前記サーバに送信する送信部と、を備えるファイルアップロードの代理装置。一方、ブラウザに依存しない技術として、サーバからのレスポンスをプロキシサーバ上で必要に応じて変換し、ブラウザに渡された時点でブラウザの入力欄に値を自動的に設定する技術が知られている特許文献2参照。しかしながら、ファイル型入力欄の場合、ブラウザのセキュリティ制限により自動設定自動入力できないため、ファイルアップロードの入力処理を自動化することはできない。また、ブラウザに依存しない別の技術として、多くのブラウザが実行できるスクリプトを使って、ブラウザの操作を自動化する技術が知られている。例えば、SeleniumRemoteControlRCと呼ばれるテストツールでは、JavaScript登録商標をブラウザ上で動かすことでブラウザを操作することができる。しかしながら、スクリプトによる自動入力はブラウザのセキュリティ制限により機能しないため、この方法を用いたファイルアップロードの入力処理の自動化はできない。そこで本件は上記の課題に鑑みてなされたものであり、ブラウザに依存せずにファイルアップロードを自動化することが可能なファイルアップロードの代理方法、代理プログラム及び代理装置を提供することを目的とする。本明細書に記載のファイルアップロードの代理方法は、ブラウザ機能部からサーバへのファイルアップロードを代理するファイルアップロードの代理方法であって、前記ブラウザ機能部から入力されるリクエストの記述内容と、リクエストの記述内容に対して、ファイルデータを特定する情報を含む予め定められた規則を格納する規則テーブルとに基づいて、前記サーバにアップロードするファイルデータを特定し、当該ファイルデータを前記リクエストに埋め込む埋め込み工程と、前記ファイルデータが埋め込まれたリクエストを前記サーバに送信する送信工程と、をコンピュータが実行するファイルアップロードの代理方法である。本明細書に記載のファイルアップロードの代理プログラムは、コンピュータに、ブラウザ機能部からサーバへのファイルアップロードを代理させるファイルアップロードの代理プログラムであって、前記ブラウザ機能部から入力されるリクエストの記述内容と、リクエストの記述内容に対して、ファイルデータを特定する情報を含む予め定められた規則を格納する規則テーブルとに基づいて、前記サーバにアップロードするファイルデータを特定し、前記リクエストに埋め込み、前記ファイルデータが埋め込まれたリクエストを前記サーバに送信する、処理をコンピュータに実行させるファイルアップロードの代理プログラムである。本明細書に記載のファイルアップロードの代理装置は、ブラウザ機能部からサーバへのファイルアップロードを代理するファイルアップロードの代理装置であって、前記ブラウザ機能部から入力されるリクエストの記述内容と、リクエストの記述内容に対して、ファイルデータを特定する情報を含む予め定められた規則を格納する規則テーブルとに基づいて、前記サーバにアップロードするファイルデータを特定し、当該ファイルデータを前記リクエストに埋め込む埋め込み部と、前記ファイルデータが埋め込まれたリクエストを前記サーバに送信する送信部と、を備えるファイルアップロードの代理装置である。本明細書に記載のファイルアップロードの代理方法、代理プログラム及び代理装置は、ブラウザに依存せずにファイルアップロードを自動化することができるという効果を奏する。以下、一実施形態について、図1~図12に基づいて詳細に説明する。図1には、一実施形態に係るアプリケーションテストシステム100の構成が概略的に示されている。図1に示すように、アプリケーションテストシステム100は、端末10と、サーバ80と、を備える。端末10とサーバ80は、インターネットなどのネットワーク70に接続されている。端末10は、PCPersonalComputerであり、サーバ80にリクエストを送ってサーバ80上で動作するアプリケーションが正常動作するかをテストするためのものである。図2には、端末10のハードウェア構成が示されている。この図2に示すように、端末10は、CPU90、ROM92、RAM94、記憶部ここではHDDHardDiskDrive96、表示部91、入力部93、ネットワークインタフェース97、及び可搬型記憶媒体用ドライブ99等を備えている。端末10の構成各部は、バス98に接続されている。端末10では、ROM92あるいはHDD96に格納されているプログラムファイルアップロードの代理プログラムを含む、或いは可搬型記憶媒体用ドライブ99が可搬型記憶媒体95から読み取ったプログラムファイルアップロードの代理プログラムを含むをCPU90が実行することにより、図3の各部の機能が実現される。図3には、端末10の機能ブロック図が示されている。この図3に示すように、端末10では、CPU90がプログラムを実行することで、ブラウザ機能部20と、代理装置としてのプロキシ機能部30としての機能を実現する。ブラウザ機能部20は、ウェブサイトを閲覧するためのブラウザとして機能する。ブラウザ機能部20は、プロキシ機能部30に対してリクエストHTTPリクエストを入力する。プロキシ機能部30は、リクエスト受付部32、埋め込み部としてのリクエスト変換部34、ファイルデータ提供部36、送信部としてのリクエスト送信部38、表示部としての変換規則更新部40、及び規則テーブルとしての変換規則テーブル50とを有する。リクエスト受付部32は、ブラウザ機能部20から入力されたリクエストを受け付ける。リクエスト変換部34は、一般的なプロキシサーバと同様の通常のリクエスト変換リクエスト行や、Connectionなど一部のヘッダフィールドなどの変換をする。また、リクエスト変換部34は、リクエストのうち、ブラウザで設定されなかったファイル用の各パラメータについて、変換規則テーブル50に基づいてファイルデータ提供部36からファイルデータを取得する。そして、リクエスト変換部34は、取得したファイルデータを用いてリクエストを変換する。すなわち、リクエスト変換部34は、ファイルデータが未だ入力設定されていないファイルアップロードのリクエストに対し、ファイルデータを埋め込んで、テストに用いることが可能なファイルアップロードのリクエストを生成する。なお、リクエスト変換部34ではリクエストのヘッダ部だけでなくボディ部も変換する場合がある。このため、リクエスト変換部34は、処理が簡単になるように、リクエストデータを全てHDD96にコピーして取り扱うようにしてもよい。また、リクエスト変換部34は、HTTPSプロキシサーバのふりをしつつHTTPSを終端させることで、HTTPSで暗号化されたリクエスト/レスポンスデータを参照/変換しても良い。ただし、この場合には、通常、ブラウザ上では安全な通信であることを確認できなくなるセキュリティの警告がされる。これらの方法は、例えばTheOWASPFoundationが公開しているWebScarabなどで実施可能である。なお、リクエスト変換部34は、図3に示すように、リクエスト変換をどのように行うかを判断するリクエスト変換判断部34aと、リクエスト変換を実行するリクエスト変換実行部34bと、を有している。ファイルデータ提供部36は、一般的なファイルシステム例えばNTFSNTFileSystemの機能を有する。ファイルデータ提供部36では、リクエスト変換部34リクエスト変換判断部34aから入力されたファイルパスに基づいて、ファイルパスに応じたデータをリクエスト変換部34リクエスト変換判断部34aに提供する。リクエスト送信部38は、リクエスト変換部34で変換されたリクエスト変換後リクエストをサーバに対して送信する。変換規則更新部40は、変換規則テーブル50を更新新たな変換規則を追加する機能を有する。変換規則テーブル50は、リクエストに対するファイルアップロードについての変換の規則を定義したものである。変換規則テーブル50には、変換条件と、その条件を満たしたときの変換に使うファイルデータを特定する情報が規定されている。具体的には、図4に示すように、変換規則テーブル50は、評価順序、有効期間、URLパターン、パラメータ名パターン、UserAgentパターン、ファイルパスの6つを列項目とする2次元の表形式で表現できるデータである。これらのうち、有効期間、URLパターン、パラメータ名パターン、UserAgentパターンの4項目が変換条件に相当し、ファイルパスの項目がファイルデータを特定する情報に相当する。評価順序の項目には、各行で異なる値が割り当てられる。なお、各行を予め評価順序の数値で並べ替えておいてもよいし、行番号を評価順序として用いることとしてもよい。有効期間の項目には、日時の範囲を示すデータが入力される。たとえば、S-ESEはそれぞれISO8601など機械が解析できる日時データなどと記述される。この場合、S-Eは、S以降でかつEより前の期間を意味する。なお、S及びEのいずれかを省略してもよいし、各行において複数の期間が定められてもよい。URLパターン、パラメータ名パターン、UserAgentパターンは、それぞれある文字列がリクエストに含まれているか否かを判定するために用いるデータである。各項目は、例えば、正規表現やglob形式図4ではglob形式で記述される。例えば、図4の評価順序=1の規則は、現在日時が2011年1月1日よりも前で、URLがhttpexamplenetで始まっているパラメータであれば、パスCdのデータで変換せよ、という意味である。また、評価順位=2の規則は、評価順位=1の規則を満足せず、かつ、現在日時が2010年10月1日以降で、URLがhttpexamplecomfileで、名前がfile1で、UserAgentパターンがBrowserで始まっているパラメータであれば、パスDf1のデータで変換せよ、という意味である。なお、ファイルパスが空の場合、そのパラメータについて変換しないの意味であるものとする。次に、本実施形態のプロキシ機能部30による、サーバ80上で動作するアプリケーションのテスト動作確認処理について、図5~図12に基づいて詳細に説明する。図5は、ブラウザ機能部20からプロキシ機能部30リクエスト受付部32に対して、テスト用のリクエストが入力された場合の、プロキシ機能部30の一連の処理を示すフローチャートである。ここで、ブラウザ機能部20からプロキシ機能部30に対して入力されるリクエストは、図6に示すようなHTTPリクエストであるものとする。図6のリクエストは、ヘッダ部と、ボディ部とを有し、そのURLがhttpexamplecomfileとなっている。また、図5の処理で用いる変換規則テーブル50は、図4のテーブルであるものとする。更に、ファイルデータ提供部36ファイルシステムでは、ファイルパスDf1にはデータ123という3バイトから成るファイルが対応づけられているものとする。なお、これら変換規則テーブル50やファイルについては、あらかじめユーザテスト実施者が手動で作成などしておく。図5の処理では、まず、ステップS10において、リクエスト変換判断部34aが、リクエスト受付部32から取得したリクエストを参照して、当該リクエストがファイルアップロードの形式の可能性があるか否かを判断する。この場合、リクエスト変換判断部34aは、図6のリクエストのContentTypeがmultipartformdataか否かを確認する。すなわち、リクエスト変換判断部34aは、リクエストヘッダーからContentTypeフィールドを探し、メディア型を確認する。そして、メディア型がmultipartformdataであった場合、ステップS10の判断が肯定されることになる。ステップS10の判断が肯定された場合には、ステップS12に移行し、ステップS10の判断が否定された場合には、図5の全処理を終了する。ステップS10の判断が肯定されて、ステップS12に移行すると、リクエスト変換判断部34aは、未処理のパラメータmultipartformdataパラメータのうち先頭のパラメータを抽出する。この場合、リクエスト変換判断部34aは、リクエストのボディ部をContentTypeで与えられたboundaryを用いて分解して、パラメータを順に抽出する。すなわち、リクエスト変換判断部34aは、例えば、名前がtitle、file1、file2のパラメータを順にステップS12の度に抽出することになる。次いで、ステップS14では、リクエスト変換判断部34aが、パラメータはファイル用かfilename情報を持つか否かを判断する。このステップS14では、パラメータのContentDispositionフィールドにfilename情報があったときに判断が肯定されて、ステップS16に移行する。一方、filename情報がなかった場合には、ステップS14の判断が否定され、ステップS22に移行する。例えば、ステップS12においてパラメータtitleが抽出されている場合には、ステップS14の判断が否定され、ステップS22に移行する。ステップS22では、リクエスト変換判断部34aが、全パラメータを抽出したか否かを判断するが、ここでの判断が否定されると、ステップS12に戻る。一方、ステップS12においてパラメータfile1又はfile2が抽出されていた場合には、ステップS14の判断が肯定され、ステップS16に移行する。ステップS16に移行すると、リクエスト変換判断部34aは、ファイル名項目filenameの値が空であるか否かを判断する。この場合、抽出されているパラメータがfile1、file2のいずれであっても、図6に示すように、ファイル名項目は空であるので、ステップS16の判断は肯定され、ステップS18に移行する。一方、ステップS16の判断が否定された場合には、ステップS22に移行する。なお、通常、ブラウザのフォームのファイル型入力欄に何も設定せずに送信submitすると、ブラウザ機能部20はfilenameの値が空のパラメータをプロキシ機能部30に対してリクエストすることになる。ステップS16の判断が肯定されると、ステップS18において、変換規則テーブル50に従った、ファイルデータ取得処理が実行されることになる。このステップS18では、具体的には、図7のフローチャートに沿った処理が実行される。図7の処理では、まず、ステップS30において、リクエスト変換判断部34aが、変換規則テーブル50の各行を評価順序順に並べ替える。なお、行番号を評価順序としている場合など、あらかじめ評価順序順に並べ替えされているような場合には、このステップS30の処理を省略することができる。次いで、ステップS32では、リクエスト変換判断部34aが、現在抽出されているパラメータfile1に関し、変換規則テーブル50の中に評価していない行があるか否かを判断する。ここでは、まだパラメータfile1に関して変換規則テーブル50の1つの行も評価していないので、判断は肯定され、ステップS34に移行する。なお、ステップS32の判断が否定された場合には、ステップS50に移行する。このステップS50の詳細については、後述するものとする。ステップS32の判断が肯定されて、ステップS34に移行すると、リクエスト変換判断部34aは、評価していない1つの行の各列項目値を抽出する。ここでは、評価順序=1の行の各列項目値が抽出されたものとする。次いで、ステップS36では、リクエスト変換判断部34aが、現在日時は有効期間内か否かを判断する。例えば、現在日時が2010年12月24日であれば、図4の有効期間-20110101の条件は満たされるので、ここでの判断は肯定され、ステップS38に移行する。一方、ここでの判断が否定された場合には、ステップS32に戻る。ステップS38では、リクエスト変換判断部34aが、リクエストのURLが、URLパターンにマッチするか否かを判断する。この場合、図6のリクエストのURLはhttpexamplecomfileであるため、評価順序=1の行のURLパターンとはマッチしていない。このため、ステップS38の判断は否定されて、ステップS32に戻る。ステップS32に戻ると、リクエスト変換判断部34aは、評価していない行が有るか否かを判断する。ここでの判断が肯定された場合、リクエスト変換判断部34aは、次のステップS34に移行して、評価していない行ここでは、評価順序=2の行の各列項目値を抽出する。そして、リクエスト変換判断部34aは、ステップS36において、現在日時は有効期間内か否かを判断し、ここでの判断が肯定されると、ステップS38に移行する。次いで、ステップS38では、リクエスト変換判断部34aが、リクエストのURLがURLパターンにマッチするか否かを判断する。この場合、図6のリクエストのURLはhttpexamplecomfileであり、評価順序=2の行のURLパターンとマッチしている。このため、ステップS38の判断は肯定されて、ステップS40に移行する。ステップS40に移行すると、リクエスト変換判断部34aが、現在抽出されているリクエストのパラメータ名が、パラメータ名パターンにマッチするか否かを判断する。現在抽出されているパラメータ名はfile1であるので、ここでの判断は肯定されて、ステップS42に移行する。なお、ステップS40の判断が否定された場合には、ステップS32に戻る。ステップS42に移行すると、リクエスト変換判断部34aは、リクエストのUserAgentが、UserAgentパターンにマッチするか否かを判断する。この場合、リクエストのUserAgentは、図6に示すように、Browser10であり、変換規則テーブル50の評価順序=2のUserAgentパターンは、Browserは任意の文字列であるので、ステップS42の判断は肯定され、ステップS44に移行する。なお、ステップS42の判断が否定された場合には、ステップS32に戻る。ステップS44に移行した場合、リクエスト変換判断部34aは、ファイルパスは空か否かを判断する。ここでの判断が肯定された場合には、ステップS46に移行し、リクエスト変換判断部34aは、変換しないというデータをリクエスト変換実行部34bに出力する。一方、図4の変換規則テーブル50の評価順序=2の行のように、ファイルパスが空でない場合には、ステップS46の判断が否定されてステップS48に移行する。そして、ステップS48では、リクエスト変換判断部34aが、ファイルパスDf1と、当該ファイルパスに基づいてファイルデータ提供部36から得られるデータ123を、リクエスト変換実行部34bに対して出力する。なお、図5のステップS12において抽出されたパラメータがfile2の場合にも、ステップS18図7の処理は行われる。この場合、図4の評価順序=1の行を評価した場合には、ステップS38の判断が否定される。また、評価順序=2の行を評価した場合には、ステップS40の判断が否定され、最終的には、ステップS32の判断が否定されることになる。この場合、ステップS50において、変換規則更新部40による変換規則テーブル50の更新処理が行われることになる。このステップS50は、変換規則の変換条件を満たさないパラメータに適用可能な新たな変換規則を生成するための処理であり、具体的には、変換規則更新部40は、図8のフローチャートに沿った処理を実行する。図8の処理では、まず、ステップS60において、変換規則更新部40が、新しい行空白の行を追加する図9a参照。次いで、ステップS62では、変換規則更新部40が、評価順序の値を最大値に設定する。なお、図9aの場合、評価順序は3に設定される図9b参照。次いで、ステップS64では、変換規則更新部40が、新しい行の有効期間の値を、所定の日付例えば本日に設定する。この場合、現在日時が2010年12月24日であるならば、図9cに示すように、有効期間の値20101225を設定する。なお、有効期間としては、本日中に限らず、たとえば本日の17時までや、今週末までなど、様々な値を設定することができるようにしてもよい。次いで、ステップS66では、変換規則更新部40が、リクエストの、URL、パラメータ名、UserAgentがそれぞれ一致するように、新しい行のURLパターン、パラメータ名パターン、UserAgentパターンを設定する。この場合、図9cに示すように、パラメータfile2に対しては、URLパターンとして、httpexamplecomfileが設定され、パラメータ名パターンとして、file2が設定され、UserAgentパターンとして、Browser10が設定される。なお、変換規則テーブル50の各値は、リクエストと完全に一致する値である必要はなく、たとえばそれぞれに値任意の文字列を設定するようにしてもよい。次いで、ステップS68では、変換規則更新部40が、ファイル選択ダイアログを端末10の表示部91上に表示する。この場合、変換規則更新部40は、パラメータfile2に関し、新しく変換規則を追加する旨などを端末10の表示部91上に表示する。これにより、ユーザテスト実施者に対し、ファイル選択ダイアログ上でのファイルパスの入力を促すことができる。次いで、ステップS70では、変換規則更新部40が、ファイルパスが入力されるまで待機する。そして、ユーザテスト実施者が図2の入力部93を介してファイルパスを入力した段階で、ステップS72に移行する。あるいは、ユーザが入力をキャンセルした場合は、ステップS74に移行するファイルパスとして空文字列が入力されたこととする。ステップS72では、変換規則更新部40が、入力されたファイルパス例えば、ファイルパスDf2を新しい行のファイルパスに設定する図9d参照。なお、一定時間選択されなかった場合には、ファイルパスの代わりに空文字列を設定するものとする。次いで、ステップS74では、変換規則更新部40が、新しい行の確認修正が可能なダイアログを端末10の表示部91表示する。例えば、図9dに示すような変換規則テーブル50を、表示部91上に表示する。なお、図9dの変換規則テーブル50においては、少なくとも評価順序3の行のファイルパスをユーザテスト実施者が修正できるようになっているものとする。次いで、ステップS76では、変換規則更新部40が、ダイアログが閉じられるまで待機する。そして、ダイアログがユーザテスト実施者によって閉じられた段階で、図8の全処理を終了し、図18のステップS44に移行する。その後は、パラメータfile2について、ステップS44~S48を上記と同様に実行する。そして、ステップS46又はS48が終了した段階で、図5のステップS20に移行する。なお、ファイルデータ提供部36では、ファイルパスDf2にはデータ123という6バイトから成るファイルが対応づけられているものとする。したがって、ステップS48では、ファイルパスDf2とデータ123が、リクエスト変換判断部34aからリクエスト変換実行部34bに対して出力されることになる。図5に戻り、ステップS20では、リクエスト変換実行部34bが、ファイルデータをリクエストに設定する処理を実行する。このステップS20では、具体的には、リクエスト変換実行部34bが、図10のフローチャートに沿った処理を実行する。図10の処理では、まず、ステップS80において、リクエスト変換実行部34bが、リクエスト変換判断部34aの出力が、変換しないであったか否かを判断する。このステップS80の判断が肯定された場合には、ステップS20の全処理を終了して、図5のステップS22に移行する。一方、ステップS80の判断が否定された場合には、ステップS82に移行する。なお、本実施形態のパターンfile1、file2の場合、ステップS80の判断は否定される。なお、以下においては、図5のステップS12で抽出されたパターンがfile1であった場合を例にとり、説明する。ステップS80の判断が否定されて、ステップS82に移行すると、リクエスト変換実行部34bが、パスのファイル名か、ファイルのデータに、boundaryと同じ文字列があるか否かを判断する。パターンfile1のデータは、123であり、boundaryは図6に示すように123であるとする。この場合、file1のデータ123に、boundaryの値123のすべてが含まれていないので、ステップS82の判断が否定され、ステップS86に移行する。そして、ステップS86では、リクエスト変換実行部34bが、boundaryを変更したか否かを判断するが、ここでは、変更していないS84を経ていないので、ステップS86の判断が否定され、ステップS90に移行する。ステップS90に移行すると、リクエスト変換実行部34bは、パスのファイル名をfilenameの値に設定する埋め込むとともに、データをパラメータのボディ部に設定する埋め込む。すなわち、図11に示すように、リクエストのパラメータfile1のfilenameをf1とし、データ123をパラメータfile1のボディ部に設定する。そして、ステップS92では、リクエスト変換実行部34bが、ContentLengthフィールドを更新する。すなわち、リクエスト変換実行部34bは、ContentLengthフィールドを、ステップS90の設定後のリクエストのボディ部のバイト数に変更する。なお、図5のステップS12で抽出されたパターンがfile2であった場合には、パターンfile2のデータは、123であり、boundaryは、図11に示すように123であるので、ステップS82の判断は肯定される。この場合、ステップS84において、リクエスト変換実行部34bが、boundaryの末尾に任意の文字を追加する。例えば、boundary123の末尾に任意の文字ここでは、数字の1を追加して、1231とする。なお、末尾に追加する文字は、適当な英数字でよく、リクエスト変換実行部34bは、当該文字を乱数を用いて決定することとしてもよい。その後は、ステップS82に戻り、リクエスト変換実行部34bは、再度ステップS82において、ファイル名又はファイルのデータに、boundaryと同じ文字列があるか否かを判断する。ここでの判断が肯定された場合には、リクエスト変換実行部34bは、ステップS84を繰り返すが、ここでの判断が否定された場合には、ステップS86に移行する。ステップS86では、リクエスト変換実行部34bが、boundaryを変更したか否かを判断する。この場合、判断は肯定され、ステップS88に移行する。そして、ステップS88では、リクエスト変換実行部34bが、リクエスト中の元のboundary値を、新しいboundary値で置換する。この場合、図11と図12とを比較するとわかるように、リクエスト変換実行部34bは、元のboundary123をステップS84で新たに生成されたboundary1231に置換する。そして、その後は、前述したのと同様に、ステップS90において、リクエスト変換実行部34bが、パスのファイル名をfilenameの値に設定し埋め込み、データをパラメータのボディ部に設定する埋め込む図12のfilename=f2、ボディ部の123参照。また、ステップS92において、リクエスト変換実行部34bが、前述と同様に、ContentLengthフィールドを更新する。すなわち、リクエスト変換実行部34bは、ContentLengthフィールドを、ステップS90の設定後のリクエストのボディ部のバイト数に変更する。以上のようにして、ステップS20の処理が終了すると、図5のステップS22に移行する。図5のステップS22では、リクエスト変換判断部34aが、全パラメータを抽出したか否かを判断する。ここでの判断が否定された場合、ステップS12に戻るが、判断が肯定された場合には、ステップS24に移行する。ステップS24では、リクエスト送信部38が、変換後のリクエストファイルデータが埋め込まれたファイルアップロード用のリクエストをサーバ80に対して送信する。そして、ステップS24が終了した段階で、図5の全処理を終了する。以上のような処理を経ることで、サーバ80は、ファイルアップロード用のリクエストを取得することができる。サーバ80のアプリケーションでは、当該リクエストに応じた処理ファイルアップロードを行い、当該処理結果を端末10の表示部91上に表示する。このようにすることで、ユーザテスト実施者は、サーバ80上で動作するアプリケーションのリクエストに対する処理結果テスト結果を表示部91上で確認することが可能となる。以上、詳細に説明したように、本実施形態によると、ブラウザ機能部20から入力されるリクエストの記述内容と、リクエストの記述内容に対して予め定められた変換規則テーブル50とに基づいて、サーバ80にアップロードするファイルデータを特定し、当該ファイルデータをリクエストに設定しS18、S20、ファイルデータが埋め込まれたリクエスト変換後リクエストを前記サーバに送信するS24。これにより、ブラウザのフォームのファイル型入力欄に何も設定しなくても、ブラウザ機能部20から入力されたリクエストを変換規則テーブル50に基づいて変換ファイルデータの埋め込みして、サーバ80に送信することができる。したがって、ブラウザに依存せずに、サーバ80に対するファイルアップロードの自動化を図ることが可能となる。これにより、サーバ上で動作するアプリケーションにおけるファイルアップロードの動作確認テストの作業効率を向上することができる。また、本実施形態では、変換規則テーブル50においてリクエストの記述内容に適合する規則が存在していない場合に、変換規則更新部40が、当該記述内容に適合する規則の入力支援画面ダイアログを表示するS68。これにより、変換規則テーブル50に不備抜けがあっても、ユーザテスト実行者は、簡易に変換規則テーブル50に新たな規則行を追加することができる。なお、上記実施形態では、端末10にブラウザ機能部20とプロキシ機能部30を設ける場合について説明したが、これに限られるものではない。例えば、端末10とサーバ80の間に配置される装置プロキシサーバなどに、プロキシ機能部30と同様の機能を持たせるようにしてもよい。また、上記実施形態では、変換規則テーブル50として、図4のようなテーブルを用意する場合について説明したが、これに限られるものではない。テーブルの各列項目としては、その他の項目を採用することとしてもよい。なお、上記実施形態では、変換規則テーブル50に不備抜けがあった場合に、ダイアログを表示して、変換規則テーブル50の更新追加の作業を簡素化する場合について説明したが、これに限られるものではない。例えば、変換規則テーブルに不備抜けがあった場合に、その旨をユーザテスト実施者に通知するのみでもよい。なお、上記実施形態では、予め変換規則テーブル50を作っておき、不備抜けがあった場合に、ステップS50において変換規則を追加更新する場合について説明したが、これに限られるものではない。例えば、変換規則テーブル50を予め作成せずに、都度、ステップS50を行うことで変換規則テーブル50を作成するようにしてもよい。なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。プログラムを流通させる場合には、例えば、そのプログラムが記録されたDVDDigitalVersatileDisc、CD-ROMCompactDiscReadOnlyMemoryなどの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。なお、以上の説明に関して更に以下の付記を開示する。付記1ブラウザ機能部からサーバへのファイルアップロードを代理するファイルアップロードの代理方法であって、前記ブラウザ機能部から入力されるリクエストの記述内容と、リクエストの記述内容に対して、ファイルデータを特定する情報を含む予め定められた規則を格納する規則テーブルとに基づいて、前記サーバにアップロードするファイルデータを特定し、当該ファイルデータを前記リクエストに埋め込む埋め込み工程と、前記ファイルデータが埋め込まれたリクエストを前記サーバに送信する送信工程と、をコンピュータが実行することを特徴とするファイルアップロードの代理方法。付記2前記規則テーブルにおいて前記リクエストの記述内容に適合する規則が存在していない場合に、当該記述内容に適合する規則の入力支援画面を表示する表示工程を、前記コンピュータが更に実行することを特徴とする付記1に記載のファイルアップロードの代理方法。付記3コンピュータに、ブラウザ機能部からサーバへのファイルアップロードを代理させるファイルアップロードの代理プログラムであって、前記ブラウザ機能部から入力されるリクエストの記述内容と、リクエストの記述内容に対して、ファイルデータを特定する情報を含む予め定められた規則を格納する規則テーブルとに基づいて、前記サーバにアップロードするファイルデータを特定し、前記リクエストに埋め込み、前記ファイルデータが埋め込まれたリクエストを前記サーバに送信する、処理をコンピュータに実行させるファイルアップロードの代理プログラム。付記4前記規則テーブルにおいて前記リクエストの記述内容に適合する規則が存在していない場合に、当該記述内容に適合する規則の入力支援画面を表示する処理を、前記コンピュータに更に実行させることを特徴とする付記3に記載のファイルアップロードの代理プログラム。付記5ブラウザ機能部からサーバへのファイルアップロードを代理するファイルアップロードの代理装置であって、前記ブラウザ機能部から入力されるリクエストの記述内容と、リクエストの記述内容に対して、ファイルデータを特定する情報を含む予め定められた規則を格納する規則テーブルとに基づいて、前記サーバにアップロードするファイルデータを特定し、当該ファイルデータを前記リクエストに埋め込む埋め込み部と、前記ファイルデータが埋め込まれたリクエストを前記サーバに送信する送信部と、を備えるファイルアップロードの代理装置。付記6前記規則テーブルにおいて前記リクエストの記述内容に適合する規則が存在していない場合に、当該記述内容に適合する規則の入力支援画面を表示する表示部を更に備える付記5に記載のファイルアップロードの代理装置。