JP2012194803A

JP2012194803A - ファイルアップロードの代理方法、代理プログラム及び代理装置

Info

Publication number: JP2012194803A
Application number: JP2011058422A
Authority: JP
Inventors: Yuji Yamaoka; 裕司山岡
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2011-03-16
Filing date: 2011-03-16
Publication date: 2012-10-11
Anticipated expiration: 2031-03-16
Also published as: JP5594199B2

Abstract

【課題】ブラウザに依存せずに、サーバに対するファイルアップロードの自動化を図る。
【解決手段】ブラウザ機能部から入力されるリクエストの記述内容と、記述内容に対して予め定められた変換規則テーブルとに基づいて、サーバにアップロードするファイルデータを特定してリクエストに設定し（Ｓ１８）、ファイルデータが埋め込まれたリクエストをサーバに送信する（Ｓ２４）。これにより、ブラウザ機能部での設定を行わなくても、ブラウザ機能部から入力されたリクエストを変換規則テーブルに基づいて変換（ファイルデータの埋め込み）して送信することができる。
【選択図】図５

Description

本件は、ファイルアップロードの代理方法、代理プログラム及び代理装置に関する。

Ｗｅｂサーバ上で動作するアプリケーションの動作確認（テスト）を行う場合、様々な入力に対するアプリケーションの動作確認や、様々なＷｅｂブラウザを用いた場合の動作確認が必要である。

このテストにおいては、アプリケーションのＨＴＭＬフォームにファイルアップロードの入力処理を行う必要がある場合がある。この場合、ファイルアップロードの入力処理は、Ｗｅｂブラウザ上に表示されたフォームのファイル型入力欄にファイルパスを設定することで行うことができる。

ただし、多くのＷｅｂブラウザ上では、ファイル型入力欄へのファイルパスの設定が必要な度に、ユーザがファイル選択ダイアログからファイルパスを選択しなければならない。すなわち、このような入力処理を様々なブラウザで行おうとすると手間と時間を要するため、この処理が動作確認作業の効率低下を引き起こすおそれがある。

なお、ブラウザを改造すれば、入力を自動的（又は半自動的）に行うことができる。たとえば、特許文献１では、ブラウザに専用のツールバーを設置し、そのツールバー上のボタンを押すと、入力欄への入力を機械が代行する技術が開示されている。しかし、ブラウザ毎に専用のツールバーを用意する必要があり、そのために大きな初期コストがかかるおそれがある。また、特許文献１ではツールバーのボタンを人手で押す必要があり、手間がかかる。

特開２０１０−３３１１１号公報特開２００２−６３１７９号公報

一方、ブラウザに依存しない技術として、サーバからのレスポンスをプロキシサーバ上で必要に応じて変換し、ブラウザに渡された時点でブラウザの入力欄に値を自動的に設定する技術が知られている（特許文献２参照）。しかしながら、ファイル型入力欄の場合、ブラウザのセキュリティ制限により自動設定（自動入力）できないため、ファイルアップロードの入力処理を自動化することはできない。

また、ブラウザに依存しない別の技術として、多くのブラウザが実行できるスクリプトを使って、ブラウザの操作を自動化する技術が知られている。例えば、Selenium Remote Control（RC）と呼ばれるテストツールでは、JavaScript（登録商標）をブラウザ上で動かすことでブラウザを操作することができる。しかしながら、スクリプトによる自動入力はブラウザのセキュリティ制限により機能しないため、この方法を用いたファイルアップロードの入力処理の自動化はできない。

そこで本件は上記の課題に鑑みてなされたものであり、ブラウザに依存せずにファイルアップロードを自動化することが可能なファイルアップロードの代理方法、代理プログラム及び代理装置を提供することを目的とする。

本明細書に記載のファイルアップロードの代理方法は、ブラウザ機能部からサーバへのファイルアップロードを代理するファイルアップロードの代理方法であって、前記ブラウザ機能部から入力されるリクエストの記述内容と、リクエストの記述内容に対して、ファイルデータを特定する情報を含む予め定められた規則を格納する規則テーブルとに基づいて、前記サーバにアップロードするファイルデータを特定し、当該ファイルデータを前記リクエストに埋め込む埋め込み工程と、前記ファイルデータが埋め込まれたリクエストを前記サーバに送信する送信工程と、をコンピュータが実行するファイルアップロードの代理方法である。

本明細書に記載のファイルアップロードの代理プログラムは、コンピュータに、ブラウザ機能部からサーバへのファイルアップロードを代理させるファイルアップロードの代理プログラムであって、前記ブラウザ機能部から入力されるリクエストの記述内容と、リクエストの記述内容に対して、ファイルデータを特定する情報を含む予め定められた規則を格納する規則テーブルとに基づいて、前記サーバにアップロードするファイルデータを特定し、前記リクエストに埋め込み、前記ファイルデータが埋め込まれたリクエストを前記サーバに送信する、処理をコンピュータに実行させるファイルアップロードの代理プログラムである。

本明細書に記載のファイルアップロードの代理装置は、ブラウザ機能部からサーバへのファイルアップロードを代理するファイルアップロードの代理装置であって、前記ブラウザ機能部から入力されるリクエストの記述内容と、リクエストの記述内容に対して、ファイルデータを特定する情報を含む予め定められた規則を格納する規則テーブルとに基づいて、前記サーバにアップロードするファイルデータを特定し、当該ファイルデータを前記リクエストに埋め込む埋め込み部と、前記ファイルデータが埋め込まれたリクエストを前記サーバに送信する送信部と、を備えるファイルアップロードの代理装置である。

本明細書に記載のファイルアップロードの代理方法、代理プログラム及び代理装置は、ブラウザに依存せずにファイルアップロードを自動化することができるという効果を奏する。

一実施形態に係るアプリケーションテストシステムの構成を概略的に示す図である。端末のハードウェア構成図である。端末の機能ブロック図である。変換規則テーブルを示す図である。プロキシ機能部の一連の処理を示すフローチャートである。リクエストの一例を示す図である。図５のステップＳ１８の具体的処理を示すフローチャートである。図７のステップＳ５０の具体的処理を示すフローチャートである。図９（ａ）〜図９（ｃ）は、図８の処理を説明するための図である。図５のステップＳ２０の具体的処理を示すフローチャートである。リクエストの変換状態を示す図である。変換後リクエストを示す図である。

以下、一実施形態について、図１〜図１２に基づいて詳細に説明する。図１には、一実施形態に係るアプリケーションテストシステム１００の構成が概略的に示されている。図１に示すように、アプリケーションテストシステム１００は、端末１０と、サーバ８０と、を備える。端末１０とサーバ８０は、インターネットなどのネットワーク７０に接続されている。

端末１０は、ＰＣ（Personal Computer）であり、サーバ８０にリクエストを送ってサーバ８０上で動作するアプリケーションが正常動作するかをテストするためのものである。図２には、端末１０のハードウェア構成が示されている。この図２に示すように、端末１０は、ＣＰＵ９０、ＲＯＭ９２、ＲＡＭ９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、表示部９１、入力部９３、ネットワークインタフェース９７、及び可搬型記憶媒体用ドライブ９９等を備えている。端末１０の構成各部は、バス９８に接続されている。端末１０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（ファイルアップロードの代理プログラムを含む）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９５から読み取ったプログラム（ファイルアップロードの代理プログラムを含む）をＣＰＵ９０が実行することにより、図３の各部の機能が実現される。

図３には、端末１０の機能ブロック図が示されている。この図３に示すように、端末１０では、ＣＰＵ９０がプログラムを実行することで、ブラウザ機能部２０と、代理装置としてのプロキシ機能部３０としての機能を実現する。

ブラウザ機能部２０は、ウェブサイトを閲覧するためのブラウザとして機能する。ブラウザ機能部２０は、プロキシ機能部３０に対してリクエスト（ＨＴＴＰリクエスト）を入力する。

プロキシ機能部３０は、リクエスト受付部３２、埋め込み部としてのリクエスト変換部３４、ファイルデータ提供部３６、送信部としてのリクエスト送信部３８、表示部としての変換規則更新部４０、及び規則テーブルとしての変換規則テーブル５０とを有する。

リクエスト受付部３２は、ブラウザ機能部２０から入力されたリクエストを受け付ける。

リクエスト変換部３４は、一般的なプロキシサーバと同様の通常のリクエスト変換（リクエスト行や、Connectionなど一部のヘッダフィールドなどの変換）をする。また、リクエスト変換部３４は、リクエストのうち、ブラウザで設定されなかったファイル用の各パラメータについて、変換規則テーブル５０に基づいてファイルデータ提供部３６からファイルデータを取得する。そして、リクエスト変換部３４は、取得したファイルデータを用いてリクエストを変換する。すなわち、リクエスト変換部３４は、ファイルデータが未だ入力（設定）されていないファイルアップロードのリクエストに対し、ファイルデータを埋め込んで、テストに用いることが可能なファイルアップロードのリクエストを生成する。

なお、リクエスト変換部３４ではリクエストのヘッダ部だけでなくボディ部も変換する場合がある。このため、リクエスト変換部３４は、処理が簡単になるように、リクエストデータを全てＨＤＤ９６にコピーして取り扱うようにしてもよい。また、リクエスト変換部３４は、ＨＴＴＰＳプロキシサーバのふりをしつつＨＴＴＰＳを終端させることで、ＨＴＴＰＳで暗号化されたリクエスト／レスポンスデータを参照／変換しても良い。ただし、この場合には、通常、ブラウザ上では安全な通信であることを確認できなくなる（セキュリティの警告がされる）。これらの方法は、例えばThe OWASP Foundationが公開しているWebScarab(http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project)などで実施可能である。

なお、リクエスト変換部３４は、図３に示すように、リクエスト変換をどのように行うかを判断するリクエスト変換判断部３４ａと、リクエスト変換を実行するリクエスト変換実行部３４ｂと、を有している。

ファイルデータ提供部３６は、一般的なファイルシステム（例えばＮＴＦＳ（NT File System））の機能を有する。ファイルデータ提供部３６では、リクエスト変換部３４（リクエスト変換判断部３４ａ）から入力されたファイルパスに基づいて、ファイルパスに応じたデータをリクエスト変換部３４（リクエスト変換判断部３４ａ）に提供する。

リクエスト送信部３８は、リクエスト変換部３４で変換されたリクエスト（変換後リクエスト）をサーバに対して送信する。変換規則更新部４０は、変換規則テーブル５０を更新（新たな変換規則を追加）する機能を有する。

変換規則テーブル５０は、リクエストに対するファイルアップロードについての変換の規則を定義したものである。変換規則テーブル５０には、変換条件と、その条件を満たしたときの変換に使うファイルデータを特定する情報が規定されている。具体的には、図４に示すように、変換規則テーブル５０は、評価順序、有効期間、ＵＲＬパターン、パラメータ名パターン、User-Agentパターン、ファイルパスの６つを列項目とする２次元の表形式で表現できるデータである。これらのうち、有効期間、ＵＲＬパターン、パラメータ名パターン、User-Agentパターンの４項目が変換条件に相当し、ファイルパスの項目がファイルデータを特定する情報に相当する。

評価順序の項目には、各行で異なる値が割り当てられる。なお、各行を予め評価順序の数値で並べ替えておいてもよいし、行番号を評価順序として用いることとしてもよい。

有効期間の項目には、日時の範囲を示すデータが入力される。たとえば、Ｓ−Ｅ（Ｓ,ＥはそれぞれISO8601など機械が解析できる日時データ）などと記述される。この場合、Ｓ−Ｅは、Ｓ以降でかつＥより前の期間を意味する。なお、Ｓ及びＥのいずれかを省略してもよいし、各行において複数の期間が定められてもよい。

ＵＲＬパターン、パラメータ名パターン、User-Agentパターンは、それぞれある文字列がリクエストに含まれているか否かを判定するために用いるデータである。各項目は、例えば、正規表現やｇｌｏｂ形式（図４ではｇｌｏｂ形式）で記述される。

例えば、図４の評価順序＝「１」の規則は、現在日時が「２０１１年１月１日」よりも前で、ＵＲＬが「http://example.net/」で始まっているパラメータであれば、パス「C:\d」のデータで変換せよ、という意味である。また、評価順位＝「２」の規則は、評価順位＝「１」の規則を満足せず、かつ、現在日時が「２０１０年１０月１日」以降で、ＵＲＬが「http://example.com/file」で、名前が「file1」で、User-Agentパターンが「Browser/」で始まっているパラメータであれば、パス「D:\f1」のデータで変換せよ、という意味である。なお、ファイルパスが空の場合、そのパラメータについて「変換しない」の意味であるものとする。

次に、本実施形態のプロキシ機能部３０による、サーバ８０上で動作するアプリケーションのテスト（動作確認）処理について、図５〜図１２に基づいて詳細に説明する。図５は、ブラウザ機能部２０からプロキシ機能部３０（リクエスト受付部３２）に対して、テスト用のリクエストが入力された場合の、プロキシ機能部３０の一連の処理を示すフローチャートである。

ここで、ブラウザ機能部２０からプロキシ機能部３０に対して入力されるリクエストは、図６に示すようなＨＴＴＰリクエストであるものとする。図６のリクエストは、ヘッダ部と、ボディ部とを有し、そのＵＲＬが「http://example.com/file」となっている。また、図５の処理で用いる変換規則テーブル５０は、図４のテーブルであるものとする。更に、ファイルデータ提供部３６（ファイルシステム）では、ファイルパス「D:\f1」にはデータ「123」という３バイトから成るファイルが対応づけられているものとする。なお、これら変換規則テーブル５０やファイルについては、あらかじめユーザ（テスト実施者）が手動で作成などしておく。

図５の処理では、まず、ステップＳ１０において、リクエスト変換判断部３４ａが、リクエスト受付部３２から取得したリクエストを参照して、当該リクエストがファイルアップロードの形式の可能性があるか否かを判断する。

この場合、リクエスト変換判断部３４ａは、図６のリクエストのContent-Typeが「multipart/form-data」か否かを確認する。すなわち、リクエスト変換判断部３４ａは、リクエストヘッダーからContent-Typeフィールドを探し、メディア型を確認する。そして、メディア型が「multipart/form-data」であった場合、ステップＳ１０の判断が肯定されることになる。ステップＳ１０の判断が肯定された場合には、ステップＳ１２に移行し、ステップＳ１０の判断が否定された場合には、図５の全処理を終了する。

ステップＳ１０の判断が肯定されて、ステップＳ１２に移行すると、リクエスト変換判断部３４ａは、未処理のパラメータ（multipart/form-dataパラメータ）のうち先頭のパラメータを抽出する。この場合、リクエスト変換判断部３４ａは、リクエストのボディ部をContent-Typeで与えられたboundaryを用いて分解して、パラメータを順に抽出する。すなわち、リクエスト変換判断部３４ａは、例えば、名前が「title」、「file1」、「file2」のパラメータを順に（ステップＳ１２の度に）抽出することになる。

次いで、ステップＳ１４では、リクエスト変換判断部３４ａが、パラメータはファイル用か（filename情報を持つか）否かを判断する。このステップＳ１４では、パラメータのContent-Dispositionフィールドに「filename」情報があったときに判断が肯定されて、ステップＳ１６に移行する。一方、「filename」情報がなかった場合には、ステップＳ１４の判断が否定され、ステップＳ２２に移行する。例えば、ステップＳ１２においてパラメータ「title」が抽出されている場合には、ステップＳ１４の判断が否定され、ステップＳ２２に移行する。ステップＳ２２では、リクエスト変換判断部３４ａが、全パラメータを抽出したか否かを判断するが、ここでの判断が否定されると、ステップＳ１２に戻る。

一方、ステップＳ１２においてパラメータ「file1」又は「file2」が抽出されていた場合には、ステップＳ１４の判断が肯定され、ステップＳ１６に移行する。

ステップＳ１６に移行すると、リクエスト変換判断部３４ａは、ファイル名項目（filenameの値）が空であるか否かを判断する。この場合、抽出されているパラメータが「file1」、「file2」のいずれであっても、図６に示すように、ファイル名項目は空であるので、ステップＳ１６の判断は肯定され、ステップＳ１８に移行する。一方、ステップＳ１６の判断が否定された場合には、ステップＳ２２に移行する。なお、通常、ブラウザのフォームのファイル型入力欄に何も設定せずに送信（submit）すると、ブラウザ機能部２０はfilenameの値が空のパラメータをプロキシ機能部３０に対してリクエストすることになる。

ステップＳ１６の判断が肯定されると、ステップＳ１８において、変換規則テーブル５０に従った、ファイルデータ取得処理が実行されることになる。このステップＳ１８では、具体的には、図７のフローチャートに沿った処理が実行される。

図７の処理では、まず、ステップＳ３０において、リクエスト変換判断部３４ａが、変換規則テーブル５０の各行を評価順序順に並べ替える。なお、行番号を評価順序としている場合など、あらかじめ評価順序順に並べ替えされているような場合には、このステップＳ３０の処理を省略することができる。

次いで、ステップＳ３２では、リクエスト変換判断部３４ａが、現在抽出されているパラメータ「file1」に関し、変換規則テーブル５０の中に評価していない行があるか否かを判断する。ここでは、まだパラメータ「file1」に関して変換規則テーブル５０の１つの行も評価していないので、判断は肯定され、ステップＳ３４に移行する。なお、ステップＳ３２の判断が否定された場合には、ステップＳ５０に移行する。このステップＳ５０の詳細については、後述するものとする。

ステップＳ３２の判断が肯定されて、ステップＳ３４に移行すると、リクエスト変換判断部３４ａは、評価していない１つの行の各列項目値を抽出する。ここでは、評価順序＝「１」の行の各列項目値が抽出されたものとする。次いで、ステップＳ３６では、リクエスト変換判断部３４ａが、現在日時は有効期間内か否かを判断する。例えば、現在日時が２０１０年１２月２４日であれば、図４の有効期間（−２０１１０１０１）の条件は満たされるので、ここでの判断は肯定され、ステップＳ３８に移行する。一方、ここでの判断が否定された場合には、ステップＳ３２に戻る。

ステップＳ３８では、リクエスト変換判断部３４ａが、リクエストのＵＲＬが、ＵＲＬパターンにマッチするか否かを判断する。この場合、図６のリクエストのＵＲＬは「http://example.com/file」であるため、評価順序＝「１」の行のＵＲＬパターンとはマッチしていない。このため、ステップＳ３８の判断は否定されて、ステップＳ３２に戻る。

ステップＳ３２に戻ると、リクエスト変換判断部３４ａは、評価していない行が有るか否かを判断する。ここでの判断が肯定された場合、リクエスト変換判断部３４ａは、次のステップＳ３４に移行して、評価していない行（ここでは、評価順序＝「２」の行）の各列項目値を抽出する。そして、リクエスト変換判断部３４ａは、ステップＳ３６において、現在日時は有効期間内か否かを判断し、ここでの判断が肯定されると、ステップＳ３８に移行する。

次いで、ステップＳ３８では、リクエスト変換判断部３４ａが、リクエストのＵＲＬがＵＲＬパターンにマッチするか否かを判断する。この場合、図６のリクエストのＵＲＬは「http://example.com/file」であり、評価順序＝「２」の行のＵＲＬパターンとマッチしている。このため、ステップＳ３８の判断は肯定されて、ステップＳ４０に移行する。

ステップＳ４０に移行すると、リクエスト変換判断部３４ａが、現在抽出されているリクエストのパラメータ名が、パラメータ名パターンにマッチするか否かを判断する。現在抽出されているパラメータ名は「file1」であるので、ここでの判断は肯定されて、ステップＳ４２に移行する。なお、ステップＳ４０の判断が否定された場合には、ステップＳ３２に戻る。

ステップＳ４２に移行すると、リクエスト変換判断部３４ａは、リクエストのUser-Agentが、User-Agentパターンにマッチするか否かを判断する。この場合、リクエストのUser-Agentは、図６に示すように、「Browser/1.0」であり、変換規則テーブル５０の評価順序＝「２」のUser-Agentパターンは、「Browser/*（*は任意の文字列）」であるので、ステップＳ４２の判断は肯定され、ステップＳ４４に移行する。なお、ステップＳ４２の判断が否定された場合には、ステップＳ３２に戻る。

ステップＳ４４に移行した場合、リクエスト変換判断部３４ａは、ファイルパスは空か否かを判断する。ここでの判断が肯定された場合には、ステップＳ４６に移行し、リクエスト変換判断部３４ａは、「変換しない」というデータをリクエスト変換実行部３４ｂに出力する。

一方、図４の変換規則テーブル５０の評価順序＝「２」の行のように、ファイルパスが空でない場合には、ステップＳ４６の判断が否定されてステップＳ４８に移行する。そして、ステップＳ４８では、リクエスト変換判断部３４ａが、ファイルパス「D:\f1」と、当該ファイルパスに基づいてファイルデータ提供部３６から得られるデータ「123」を、リクエスト変換実行部３４ｂに対して出力する。

なお、図５のステップＳ１２において抽出されたパラメータが「file2」の場合にも、ステップＳ１８（図７）の処理は行われる。この場合、図４の評価順序＝「１」の行を評価した場合には、ステップＳ３８の判断が否定される。また、評価順序＝「２」の行を評価した場合には、ステップＳ４０の判断が否定され、最終的には、ステップＳ３２の判断が否定されることになる。この場合、ステップＳ５０において、変換規則更新部４０による変換規則テーブル５０の更新処理が行われることになる。このステップＳ５０は、変換規則の変換条件を満たさないパラメータに適用可能な新たな変換規則を生成するための処理であり、具体的には、変換規則更新部４０は、図８のフローチャートに沿った処理を実行する。

図８の処理では、まず、ステップＳ６０において、変換規則更新部４０が、新しい行（空白の行）を追加する（図９（ａ）参照）。次いで、ステップＳ６２では、変換規則更新部４０が、評価順序の値を最大値に設定する。なお、図９（ａ）の場合、評価順序は「３」に設定される（図９（ｂ）参照）。

次いで、ステップＳ６４では、変換規則更新部４０が、新しい行の有効期間の値を、所定の日付（例えば本日）に設定する。この場合、現在日時が２０１０年１２月２４日であるならば、図９（ｃ）に示すように、有効期間の値「-20101225」を設定する。なお、有効期間としては、本日中に限らず、たとえば本日の１７時までや、今週末までなど、様々な値を設定することができるようにしてもよい。

次いで、ステップＳ６６では、変換規則更新部４０が、リクエストの、ＵＲＬ、パラメータ名、User-Agentがそれぞれ一致するように、新しい行のＵＲＬパターン、パラメータ名パターン、User-Agentパターンを設定する。この場合、図９（ｃ）に示すように、パラメータ「file2」に対しては、ＵＲＬパターンとして、「http://example.com/file」が設定され、パラメータ名パターンとして、「file2」が設定され、User-Agentパターンとして、「Browser/1.0」が設定される。なお、変換規則テーブル５０の各値は、リクエストと完全に一致する値である必要はなく、たとえばそれぞれに値「＊」（任意の文字列）を設定するようにしてもよい。

次いで、ステップＳ６８では、変換規則更新部４０が、ファイル選択ダイアログを端末１０の表示部９１上に表示する。この場合、変換規則更新部４０は、パラメータ「file2」に関し、新しく変換規則を追加する旨などを端末１０の表示部９１上に表示する。これにより、ユーザ（テスト実施者）に対し、ファイル選択ダイアログ上でのファイルパスの入力を促すことができる。

次いで、ステップＳ７０では、変換規則更新部４０が、ファイルパスが入力されるまで待機する。そして、ユーザ（テスト実施者）が図２の入力部９３を介してファイルパスを入力した段階で、ステップＳ７２に移行する。あるいは、ユーザが入力をキャンセルした場合は、ステップＳ７４に移行する（ファイルパスとして空文字列が入力されたこととする）。

ステップＳ７２では、変換規則更新部４０が、入力されたファイルパス（例えば、ファイルパス「D:\f2」）を新しい行のファイルパスに設定する（図９（ｄ）参照）。なお、一定時間選択されなかった場合には、ファイルパスの代わりに空文字列を設定するものとする。

次いで、ステップＳ７４では、変換規則更新部４０が、新しい行の確認・修正が可能なダイアログを端末１０の表示部９１表示する。例えば、図９（ｄ）に示すような変換規則テーブル５０を、表示部９１上に表示する。なお、図９（ｄ）の変換規則テーブル５０においては、少なくとも評価順序「３」の行のファイルパスをユーザ（テスト実施者）が修正できるようになっているものとする。

次いで、ステップＳ７６では、変換規則更新部４０が、ダイアログが閉じられるまで待機する。そして、ダイアログがユーザ（テスト実施者）によって閉じられた段階で、図８の全処理を終了し、図１８のステップＳ４４に移行する。その後は、パラメータ「file2」について、ステップＳ４４〜Ｓ４８を上記と同様に実行する。そして、ステップＳ４６又はＳ４８が終了した段階で、図５のステップＳ２０に移行する。なお、ファイルデータ提供部３６では、ファイルパス「D:\f2」にはデータ「---123」という６バイトから成るファイルが対応づけられているものとする。したがって、ステップＳ４８では、ファイルパス「D:\f2」とデータ「---123」が、リクエスト変換判断部３４ａからリクエスト変換実行部３４ｂに対して出力されることになる。

図５に戻り、ステップＳ２０では、リクエスト変換実行部３４ｂが、ファイルデータをリクエストに設定する処理を実行する。このステップＳ２０では、具体的には、リクエスト変換実行部３４ｂが、図１０のフローチャートに沿った処理を実行する。

図１０の処理では、まず、ステップＳ８０において、リクエスト変換実行部３４ｂが、リクエスト変換判断部３４ａの出力が、「変換しない」であったか否かを判断する。このステップＳ８０の判断が肯定された場合には、ステップＳ２０の全処理を終了して、図５のステップＳ２２に移行する。一方、ステップＳ８０の判断が否定された場合には、ステップＳ８２に移行する。なお、本実施形態のパターン「file1」、「file2」の場合、ステップＳ８０の判断は否定される。

なお、以下においては、図５のステップＳ１２で抽出されたパターンが「file1」であった場合を例にとり、説明する。

ステップＳ８０の判断が否定されて、ステップＳ８２に移行すると、リクエスト変換実行部３４ｂが、パスのファイル名か、ファイルのデータに、boundaryと同じ文字列があるか否かを判断する。パターン「file1」のデータは、「123」であり、boundaryは図６に示すように「--123」であるとする。この場合、「file1」のデータ「123」に、boundaryの値「--123」のすべてが含まれていないので、ステップＳ８２の判断が否定され、ステップＳ８６に移行する。そして、ステップＳ８６では、リクエスト変換実行部３４ｂが、boundaryを変更したか否かを判断するが、ここでは、変更していない（Ｓ８４を経ていない）ので、ステップＳ８６の判断が否定され、ステップＳ９０に移行する。

ステップＳ９０に移行すると、リクエスト変換実行部３４ｂは、パスのファイル名をfilenameの値に設定する（埋め込む）とともに、データをパラメータのボディ部に設定する（埋め込む）。すなわち、図１１に示すように、リクエストのパラメータ「file1」のfilenameを「f1」とし、データ「123」をパラメータ「file1」のボディ部に設定する。そして、ステップＳ９２では、リクエスト変換実行部３４ｂが、Content-Lengthフィールドを更新する。すなわち、リクエスト変換実行部３４ｂは、Content-Lengthフィールドを、ステップＳ９０の設定後のリクエストのボディ部のバイト数に変更する。

なお、図５のステップＳ１２で抽出されたパターンが「file2」であった場合には、パターン「file2」のデータは、「---123」であり、boundaryは、図１１に示すように「--123」であるので、ステップＳ８２の判断は肯定される。この場合、ステップＳ８４において、リクエスト変換実行部３４ｂが、boundaryの末尾に任意の文字を追加する。例えば、boundary「--123」の末尾に任意の文字（ここでは、数字の１）を追加して、「--1231」とする。なお、末尾に追加する文字は、適当な英数字でよく、リクエスト変換実行部３４ｂは、当該文字を乱数を用いて決定することとしてもよい。

その後は、ステップＳ８２に戻り、リクエスト変換実行部３４ｂは、再度ステップＳ８２において、ファイル名又はファイルのデータに、boundaryと同じ文字列があるか否かを判断する。ここでの判断が肯定された場合には、リクエスト変換実行部３４ｂは、ステップＳ８４を繰り返すが、ここでの判断が否定された場合には、ステップＳ８６に移行する。ステップＳ８６では、リクエスト変換実行部３４ｂが、boundaryを変更したか否かを判断する。この場合、判断は肯定され、ステップＳ８８に移行する。そして、ステップＳ８８では、リクエスト変換実行部３４ｂが、リクエスト中の元のboundary値を、新しいboundary値で置換する。この場合、図１１と図１２とを比較するとわかるように、リクエスト変換実行部３４ｂは、元のboundary「--123」をステップＳ８４で新たに生成されたboundary「--1231」に置換する。

そして、その後は、前述したのと同様に、ステップＳ９０において、リクエスト変換実行部３４ｂが、パスのファイル名をfilenameの値に設定し（埋め込み）、データをパラメータのボディ部に設定する（埋め込む）（図１２のfilename＝"f2"、ボディ部の「---123」参照）。また、ステップＳ９２において、リクエスト変換実行部３４ｂが、前述と同様に、Content-Lengthフィールドを更新する。すなわち、リクエスト変換実行部３４ｂは、Content-Lengthフィールドを、ステップＳ９０の設定後のリクエストのボディ部のバイト数に変更する。

以上のようにして、ステップＳ２０の処理が終了すると、図５のステップＳ２２に移行する。

図５のステップＳ２２では、リクエスト変換判断部３４ａが、全パラメータを抽出したか否かを判断する。ここでの判断が否定された場合、ステップＳ１２に戻るが、判断が肯定された場合には、ステップＳ２４に移行する。ステップＳ２４では、リクエスト送信部３８が、変換後のリクエスト（ファイルデータが埋め込まれたファイルアップロード用のリクエスト）をサーバ８０に対して送信する。そして、ステップＳ２４が終了した段階で、図５の全処理を終了する。

以上のような処理を経ることで、サーバ８０は、ファイルアップロード用のリクエストを取得することができる。サーバ８０のアプリケーションでは、当該リクエストに応じた処理（ファイルアップロード）を行い、当該処理結果を端末１０の表示部９１上に表示する。このようにすることで、ユーザ（テスト実施者）は、サーバ８０上で動作するアプリケーションのリクエストに対する処理結果（テスト結果）を表示部９１上で確認することが可能となる。

以上、詳細に説明したように、本実施形態によると、ブラウザ機能部２０から入力されるリクエストの記述内容と、リクエストの記述内容に対して予め定められた変換規則テーブル５０とに基づいて、サーバ８０にアップロードするファイルデータを特定し、当該ファイルデータをリクエストに設定し（Ｓ１８、Ｓ２０）、ファイルデータが埋め込まれたリクエスト（変換後リクエスト）を前記サーバに送信する（Ｓ２４）。これにより、ブラウザのフォームのファイル型入力欄に何も設定しなくても、ブラウザ機能部２０から入力されたリクエストを変換規則テーブル５０に基づいて変換（ファイルデータの埋め込み）して、サーバ８０に送信することができる。したがって、ブラウザに依存せずに、サーバ８０に対するファイルアップロードの自動化を図ることが可能となる。これにより、サーバ上で動作するアプリケーションにおけるファイルアップロードの動作確認（テスト）の作業効率を向上することができる。

また、本実施形態では、変換規則テーブル５０においてリクエストの記述内容に適合する規則が存在していない場合に、変換規則更新部４０が、当該記述内容に適合する規則の入力支援画面（ダイアログ）を表示する（Ｓ６８）。これにより、変換規則テーブル５０に不備（抜け）があっても、ユーザ（テスト実行者）は、簡易に変換規則テーブル５０に新たな規則（行）を追加することができる。

なお、上記実施形態では、端末１０にブラウザ機能部２０とプロキシ機能部３０を設ける場合について説明したが、これに限られるものではない。例えば、端末１０とサーバ８０の間に配置される装置（プロキシサーバなど）に、プロキシ機能部３０と同様の機能を持たせるようにしてもよい。

また、上記実施形態では、変換規則テーブル５０として、図４のようなテーブルを用意する場合について説明したが、これに限られるものではない。テーブルの各列項目としては、その他の項目を採用することとしてもよい。

なお、上記実施形態では、変換規則テーブル５０に不備（抜け）があった場合に、ダイアログを表示して、変換規則テーブル５０の更新（追加）の作業を簡素化する場合について説明したが、これに限られるものではない。例えば、変換規則テーブルに不備（抜け）があった場合に、その旨をユーザ（テスト実施者）に通知するのみでもよい。

なお、上記実施形態では、予め変換規則テーブル５０を作っておき、不備（抜け）があった場合に、ステップＳ５０において変換規則を追加（更新）する場合について説明したが、これに限られるものではない。例えば、変換規則テーブル５０を予め作成せずに、都度、ステップＳ５０を行うことで変換規則テーブル５０を作成するようにしてもよい。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

なお、以上の説明に関して更に以下の付記を開示する。
（付記１）ブラウザ機能部からサーバへのファイルアップロードを代理するファイルアップロードの代理方法であって、前記ブラウザ機能部から入力されるリクエストの記述内容と、リクエストの記述内容に対して、ファイルデータを特定する情報を含む予め定められた規則を格納する規則テーブルとに基づいて、前記サーバにアップロードするファイルデータを特定し、当該ファイルデータを前記リクエストに埋め込む埋め込み工程と、前記ファイルデータが埋め込まれたリクエストを前記サーバに送信する送信工程と、をコンピュータが実行することを特徴とするファイルアップロードの代理方法。
（付記２）前記規則テーブルにおいて前記リクエストの記述内容に適合する規則が存在していない場合に、当該記述内容に適合する規則の入力支援画面を表示する表示工程を、前記コンピュータが更に実行することを特徴とする付記１に記載のファイルアップロードの代理方法。
（付記３）コンピュータに、ブラウザ機能部からサーバへのファイルアップロードを代理させるファイルアップロードの代理プログラムであって、前記ブラウザ機能部から入力されるリクエストの記述内容と、リクエストの記述内容に対して、ファイルデータを特定する情報を含む予め定められた規則を格納する規則テーブルとに基づいて、前記サーバにアップロードするファイルデータを特定し、前記リクエストに埋め込み、前記ファイルデータが埋め込まれたリクエストを前記サーバに送信する、処理をコンピュータに実行させるファイルアップロードの代理プログラム。
（付記４）前記規則テーブルにおいて前記リクエストの記述内容に適合する規則が存在していない場合に、当該記述内容に適合する規則の入力支援画面を表示する処理を、前記コンピュータに更に実行させることを特徴とする付記３に記載のファイルアップロードの代理プログラム。
（付記５）ブラウザ機能部からサーバへのファイルアップロードを代理するファイルアップロードの代理装置であって、前記ブラウザ機能部から入力されるリクエストの記述内容と、リクエストの記述内容に対して、ファイルデータを特定する情報を含む予め定められた規則を格納する規則テーブルとに基づいて、前記サーバにアップロードするファイルデータを特定し、当該ファイルデータを前記リクエストに埋め込む埋め込み部と、前記ファイルデータが埋め込まれたリクエストを前記サーバに送信する送信部と、を備えるファイルアップロードの代理装置。
（付記６）前記規則テーブルにおいて前記リクエストの記述内容に適合する規則が存在していない場合に、当該記述内容に適合する規則の入力支援画面を表示する表示部を更に備える付記５に記載のファイルアップロードの代理装置。

２０ブラウザ機能部
３０プロキシ機能部
３４リクエスト変換部
３８リクエスト送信部
４０変換規則更新部
５０変換規則テーブル
８０サーバ
９０コンピュータ

Claims

ブラウザ機能部からサーバへのファイルアップロードを代理するファイルアップロードの代理方法であって、
前記ブラウザ機能部から入力されるリクエストの記述内容と、リクエストの記述内容に対して、ファイルデータを特定する情報を含む予め定められた規則を格納する規則テーブルとに基づいて、前記サーバにアップロードするファイルデータを特定し、当該ファイルデータを前記リクエストに埋め込む埋め込み工程と、
前記ファイルデータが埋め込まれたリクエストを前記サーバに送信する送信工程と、をコンピュータが実行することを特徴とするファイルアップロードの代理方法。
前記規則テーブルにおいて前記リクエストの記述内容に適合する規則が存在していない場合に、当該記述内容に適合する規則の入力支援画面を表示する表示工程を、前記コンピュータに更に実行させることを特徴とする請求項１に記載のファイルアップロードの代理方法。
コンピュータに、ブラウザ機能部からサーバへのファイルアップロードを代理させるファイルアップロードの代理プログラムであって、
前記ブラウザ機能部から入力されるリクエストの記述内容と、リクエストの記述内容に対して、ファイルデータを特定する情報を含む予め定められた規則を格納する規則テーブルとに基づいて、前記サーバにアップロードするファイルデータを特定し、前記リクエストに埋め込み、
前記ファイルデータが埋め込まれたリクエストを前記サーバに送信する、処理をコンピュータに実行させるファイルアップロードの代理プログラム。
ブラウザ機能部からサーバへのファイルアップロードを代理するファイルアップロードの代理装置であって、
前記ブラウザ機能部から入力されるリクエストの記述内容と、リクエストの記述内容に対して、ファイルデータを特定する情報を含む予め定められた規則を格納する規則テーブルとに基づいて、前記サーバにアップロードするファイルデータを特定し、当該ファイルデータを前記リクエストに埋め込む埋め込み部と、
前記ファイルデータが埋め込まれたリクエストを前記サーバに送信する送信部と、を備えるファイルアップロードの代理装置。