画像を形成する画像形成装置であって、情報処理装置に接続されたUSBデバイスを制御する遠隔USB制御モジュールを受信する受信手段と、前記受信手段で受信された前記遠隔USB制御モジュールを、前記画像形成装置に接続されたUSBデバイスを制御するUSB制御モジュールより優先的に利用されるようにアプリケーション実行環境の設定を変更する変更手段と、前記USBデバイスを利用するテスト用アプリケーションを前記アプリケーション実行環境で実行する実行手段と、テストが完了した場合、前記変更手段で変更された前記アプリケーション実行環境の設定を元に戻す復旧手段と、を有する画像形成装置。テストが完了した場合、前記受信手段で受信された前記遠隔USB制御モジュールを削除する削除手段を更に有する請求項1記載の画像形成装置。前記情報処理装置より受信した前記テスト用アプリケーションをインストールするインストール手段を更に有し、前記実行手段は、前記インストール手段でインストールされた前記テスト用アプリケーションを前記アプリケーション実行環境で実行し、テストが完了した場合、テスト結果を前記情報処理装置に送信する送信手段と、テストが完了した場合、前記インストール手段でインストールされた前記テスト用アプリケーションをアンインストールするアンインストール手段と、を更に有する請求項1又は2記載の画像形成装置。情報処理装置と、画像形成装置と、を含むシステムであって、前記情報処理装置は、前記情報処理装置に接続されたUSBデバイスを制御する遠隔USB制御モジュールを前記画像形成装置に送信する送信手段を有し、前記画像形成装置は、前記遠隔USB制御モジュールを受信する受信手段と、前記受信手段で受信された前記遠隔USB制御モジュールを、前記画像形成装置に接続されたUSBデバイスを制御するUSB制御モジュールより優先的に利用されるようにアプリケーション実行環境の設定を変更する変更手段と、前記USBデバイスを利用するテスト用アプリケーションを前記アプリケーション実行環境で実行する実行手段と、テストが完了した場合、前記変更手段で変更された前記アプリケーション実行環境の設定を元に戻す復旧手段と、を有するシステム。画像を形成する画像形成装置が実行するUSBデバイスのテスト方法であって、情報処理装置に接続されたUSBデバイスを制御する遠隔USB制御モジュールを受信する受信ステップと、前記受信ステップで受信された前記遠隔USB制御モジュールを、前記画像形成装置に接続されたUSBデバイスを制御するUSB制御モジュールより優先的に利用されるようにアプリケーション実行環境の設定を変更する変更ステップと、前記USBデバイスを利用するテスト用アプリケーションを前記アプリケーション実行環境で実行する実行ステップと、テストが完了した場合、前記変更ステップで変更された前記アプリケーション実行環境の設定を元に戻す復旧ステップと、を含むテスト方法。情報処理装置と、画像形成装置と、を含むシステムにおけるUSBデバイスのテスト方法であって、前記情報処理装置が、前記情報処理装置に接続されたUSBデバイスを制御する遠隔USB制御モジュールを前記画像形成装置に送信する送信ステップと、前記画像形成装置が、前記遠隔USB制御モジュールを受信する受信ステップと、前記画像形成装置が、前記受信ステップで受信された前記遠隔USB制御モジュールを、前記画像形成装置に接続されたUSBデバイスを制御するUSB制御モジュールより優先的に利用されるようにアプリケーション実行環境の設定を変更する変更ステップと、前記USBデバイスを利用するテスト用アプリケーションを前記アプリケーション実行環境で実行する実行ステップと、前記画像形成装置が、テストが完了した場合、前記変更ステップで変更された前記アプリケーション実行環境の設定を元に戻す復旧ステップと、を含むテスト方法。コンピュータに、情報処理装置に接続されたUSBデバイスを制御する遠隔USB制御モジュールを受信する受信ステップと、前記受信ステップで受信された前記遠隔USB制御モジュールを、前記コンピュータに接続されたUSBデバイスを制御するUSB制御モジュールより優先的に利用されるようにアプリケーション実行環境の設定を変更する変更ステップと、前記USBデバイスを利用するテスト用アプリケーションを前記アプリケーション実行環境で実行する実行ステップと、テストが完了した場合、前記変更ステップで変更された前記アプリケーション実行環境の設定を元に戻す復旧ステップと、を実行させるためのプログラム。画像形成装置上で動作するアプリケーションを開発する場合、画像形成装置の設置スペース等の問題から手元にデバイスを置いて開発を行うことは難しい。そのため画像形成装置は開発PCとは離れた場所に設置されることが多い。このような環境で実機を用いてデバッグを行う場合はネットワーク経由でデバッグを行うことになる。しかしながら、画像形成装置に接続されたUSBデバイスICカードリーダやUSBメモリ等を利用するアプリケーションのデバッグを行う場合は、画像形成装置と開発PCの間を行き来する必要があり不便であった。また、遠隔地にある端末からローカルのUSBデバイスを制御する技術を適用することでローカル端末のUSBデバイスを使ったデバッグが可能となるが、事前に画像形成装置にそのような機能を組み込んでおく必要があった。そのため、過去にリリースされた機種では容易に実現できないという問題があった。また、複数の開発者が同じ実機を使って開発を行う環境では、他の人のUSBデバイスが接続されたままになっていて意図しないUSBデバイスを使用してテストを実行してしまうことがあるという問題もあった。本発明はこのような問題点に鑑みなされたもので、開発者の利便性を向上させ、また、意図しないUSBデバイスを利用してテストを行ってしまうミスを防ぐことを目的とする。そこで、本発明は、画像を形成する画像形成装置であって、情報処理装置に接続されたUSBデバイスを制御する遠隔USB制御モジュールを受信する受信手段と、前記受信手段で受信された前記遠隔USB制御モジュールを、前記画像形成装置に接続されたUSBデバイスを制御するUSB制御モジュールより優先的に利用されるようにアプリケーション実行環境の設定を変更する変更手段と、前記USBデバイスを利用するテスト用アプリケーションを前記アプリケーション実行環境で実行する実行手段と、テストが完了した場合、前記変更手段で変更された前記アプリケーション実行環境の設定を元に戻す復旧手段と、を有する。本発明によれば、開発者の利便性を向上させ、また、意図しないUSBデバイスを利用してテストを行ってしまうミスを防ぐことができる。以下、本発明の実施形態について図面に基づいて説明する。<実施形態1>図1は、画像形成装置用アプリケーションのテストシステムのシステム構成の一例を示す図である。画像形成装置101は、スキャナやプリンタを備えた装置であり、様々なアプリケーションをインストールして動作させることが可能である。画像形成装置101上で動作するアプリケーションの中には、画像形成装置101に接続されたUSBデバイス102を利用するアプリケーションが存在する。例えば、USB接続のICカードリーダで認証を行うアプリケーションや、USBメモリにスキャン画像を格納したりするようなアプリケーションが存在する。このような画像形成装置用アプリケーションの開発を行う場合、通常、開発用PC103にて統合開発環境を動作させてプログラム作成テストデバッグ等を行う。また、アプリケーションのテストを行う場合は、開発用PC103から画像形成装置101にネットワーク100経由でアプリケーションをインストールして画像形成装置101上でアプリケーションを動作させてテストを行う。本実施形態の技術を適用したアプリケーションテストにおいては、画像形成装置101上のアプリケーションが開発用PC103に接続されたUSBデバイス104を制御するように画像形成装置101の内部構成を自動的に更新する。開発用PC103は、情報処理装置の一例である。図2は、図1における画像形成装置101のハードウェア構成の一例を示す図である。CPU201は、画像形成装置101のソフトウェアプログラムを実行し、装置全体の制御を行なう。ROM202は、リードオンリーメモリであり、装置のブートプログラムや固定パラメータ等が格納されている。RAM203は、ランダムアクセスメモリであり、CPU201が装置を制御する際に、一時的なデータの格納等に使用する。外部記憶装置204は、インストールされたアプリケーションやアプリケーションのデータや印刷データの格納等、様々なデータの格納に使用する。USBHI/F制御部205は、USBホストインタフェースを制御するためのものであり、様々なUSBデバイスとの通信を制御する。スキャナI/F制御部206は、スキャナ211を制御する装置である。プリンタI/F制御部207は、プリンタ212を制御する装置である。NVRAM208は、不揮発性のメモリであり画像形成装置101の各種設定値が保存される。パネル制御部209は、操作パネル213を制御し、各種情報の表示、使用者からの指示入力を行なうためのものである。ネットワークI/F制御部210は、LANネットワーク215とのデータの送受信を制御する。バス214には、CPU201、ROM202、RAM203、外部記憶装置204、USBHI/F制御部205、スキャナI/F制御部206、プリンタI/F制御部207が接続される。また、バス214には、NVRAM208、パネル制御部209、ネットワークI/F制御部210が接続される。またバス214は、CPU201からの制御信号や各装置間のデータ信号が送受信されるシステムバスである。USBデバイス216は、USBメモリやICカードリーダ等のUSBデバイスである。図3は、開発用PC103のハードウェア構成の一例を示す図である。CPU301は、本装置上の各処理を司る中央演算装置である。ROM302は、本装置の各処理に関わるプログラムやデータを記憶する。RAM303は、本装置の各処理に関わる一時的なデータを記憶する。HDD304は、本装置の各処理に関わるプログラムやデータ、及び一時的なデータ、本実施形態に関わるプログラムモジュールが格納される。入力装置305は、本装置への指示入力を受け付けるキーボードやポインティングデバイスである。表示部306は、本装置の動作状況や、本装置上で動作する各プログラムが出力する情報を表示する。ネットワークI/F307は、ネットワーク経由でLAN及びインタネットに接続し、外部と情報交換を行う。USBHI/F308は、USBホストインタフェースであり、様々なUSBデバイスを接続する。それら要素がシステムバス309により結び付き、データをやりとりしている。USBデバイス104は、USBメモリやICカードリーダ等のUSBデバイスであり、画像形成装置用アプリケーションテスト時に画像形成装置101上で動作するアプリケーションから制御される。図4Aは、工場出荷状態の画像形成装置101のアプリケーションプラットフォームのソフトウェア構成の一例を示す図である。Java登録商標VM401は、Javaプログラムを動作させるための仮想マシンである。クラスパス設定管理部402は、JavaVMがロードするライブラリの設定管理を行う。ジョブ制御ライブラリ403は、スキャンジョブやプリントジョブを実行するためのAPIを備えたライブラリである。USB制御ライブラリ404は、USBHI/F制御部205に接続されたUSBデバイス216を制御するためのAPIを備えたライブラリであり、接続されたUSBデバイス情報の取得や、USBデバイスとのデータ送受信等を行うことができる。アプリケーションフレームワーク405は、JavaVM401上で複数のアプリケーションを動作させるためのフレームワークである。アプリ管理サービス406は、アプリケーションフレームワーク405上で動作するアプリケーションの管理を行うためのサービスであり、アプリケーションのインストールアンインストール開始停止等を行う。JavaVM401は、アプリケーション実行環境の一例である。図4Bは、統合開発環境を利用してテストを行う場合のソフトウェア構成の一例を示す図である。図4Aの状態の画像形成装置101に対してアプリケーション開発者がアプリ管理サービス406経由でテストブローカ407をインストールすることで統合開発環境を利用したテストを行うことができるようになる。テストブローカ407は、開発用PC103から後述する図4Cに示されるテスト用アプリ408を受信してテストを実行したり、テスト結果を開発用PC103に送信したり、テスト完了後にテスト用アプリ408をアンインストールしたりするモジュールである。また、開発用PC103に接続されたUSBデバイス104を利用してアプリケーションのテストを行う場合、テストブローカ407は、後述する図4Cに示される開発用PC103から遠隔USB制御ライブラリ409を受信する。そして、テストブローカ407は、受信した遠隔USB制御ライブラリ409を画像形成装置101内にインストールする。テスト用アプリ408は、ユーザが開発したアプリケーションとテストのためのプログラムが一つにまとめられたテストのためのアプリケーションである。遠隔USB制御ライブラリ409は、USB制御ライブラリ404とAPI互換のライブラリであり、クラスパス設定管理部402がライブラリのロード順を制御することにより、USB制御ライブラリ404よりも優先的にロードされるようになる。テスト用アプリ408は、USB制御ライブラリ404のAPIを呼び出すと遠隔USB制御ライブラリ409のAPIが実行される。遠隔USB制御ライブラリ409のAPIが実行されると開発用PC103にUSB制御要求を出し開発用PC103に接続されたUSBデバイス104を制御する。USB制御ライブラリ404は、USB制御モジュールの一例である。また、遠隔USB制御ライブラリ409は、遠隔USB制御モジュールの一例である。また、テスト用アプリ408は、テスト用アプリケーションの一例である。図4Cは、開発用PC103に接続されたUSBデバイス104を利用してアプリケーションのテストを実行しているときのソフトウェア構成の一例を示す図である。テストが完了するとテストブローカ407は、テスト用アプリ408及び遠隔USB制御ライブラリ409を削除して図4Bの状態に戻る。また、アプリケーション開発者がアプリ管理サービス406経由でテストブローカ407をアンインストールすると図4Aの状態に戻すことができる。図5は、開発用PC103で動作する統合開発環境のソフトウェア構成の一例を示す図である。ソース管理部501は、アプリケーションのソースやテストケースのソースの管理を行う。テスト用アプリ作成部502は、ソース管理部501で管理されているソースをコンパイルして画像形成装置101にインストール可能なアプリケーションファイルを生成する。テスト制御部503は、テスト用アプリ作成部502で生成したアプリケーションを通信制御部506経由で画像形成装置101に送信し、テストの実行指示や結果の受信を行う。ライブラリ送信部504は、開発用PC103に接続されたUSBデバイスを利用してテストを行いたい場合に遠隔USB制御ライブラリ409を画像形成装置101に送信する。USBHost制御部505は、遠隔USB制御ライブラリ409からのUSBデバイス制御要求を受けて開発用PC103に接続されたUSBデバイス104の制御を行い、遠隔USB制御ライブラリ409に応答を返す。図6は、図4におけるテストブローカ407のソフトウェア構成の一例を示す図である。テスト制御部601は、テスト用アプリのインストール開始停止アンインストールテストケース実行等の制御を行ったり、テスト結果を統合開発環境に送信したりする。ライブラリ制御部602は、遠隔USB制御ライブラリ409をファイルシステム上に配置してクラスパス設定管理部402経由でライブラリのロード順変更の制御を行う。接続先管理部603は、テスト用アプリと開発用PCの対応の管理を行う。通信制御部604は、開発用PCと各種データの送受信を行う。図7は、図4における遠隔USB制御ライブラリ409のソフトウェア構成の一例を示す図である。アプリ向けI/F部701は、アプリケーションに公開しているI/Fである。アプリ情報管理部702は、アプリケーションからアプリ向けI/F部701が呼び出されたときに呼び出し元のアプリケーションの特定を行う。接続先判定部703は、API呼び出し元のアプリケーションに対応する開発用PC103を特定する。通信制御部704は、接続先判定部703で特定した開発用PC103上で動作するUSBHost制御部505にUSBH制御要求を出してUSBデバイスの制御を行う。図8は、図4におけるテスト用アプリ408の構成の一例を示す図である。テスト用アプリ408は、アプリケーション801とテストケース802とテストエージェント803とアプリケーション情報804とから構成される。アプリケーション801は、開発者が開発しているアプリケーションの実体である。テストケース802は、アプリケーション801をテストするためのプログラムである。テストエージェント803は、テストブローカ407から指示を受けてテストケース802の実行を行う。アプリケーション情報804は、そのアプリケーションの識別IDやアプリケーション名称やバージョン情報を含む。図9Aは、統合開発環境におけるプログラム作成画面の一例を示す図である。プロジェクト表示領域901は、統合開発環境上で開発を行っているプロジェクトについての情報を表示する領域であり、アプリケーションに含まれるクラスやファイルのリストが階層構造で表示される。ソース表示領域902には、プロジェクト表示領域で選択したクラスのソースが表示される。開発者は、プロジェクト表示領域901でテストケースのプロジェクト903を選択して右クリックすることで、テスト実行の指示を行うことができる。テスト実行を指示されると図9Bのダイアログが表示される。図9Bは、テスト実行のためのダイアログの一例を示す図である。図9Bにおいてテキストフィールド911は、テストを実行する画像形成装置101のホスト名若しくはIPアドレスを入力するためのフィールドである。チェックボックス912は、開発用PCに接続されているUSBデバイスを利用してテストを行う場合にチェックするためのものである。このチェックボックスにチェックが入れられると、開発用PCに接続されたUSBデバイスが制御されるようになり、チェックボックスにチェックを入れずにテストを実行すると画像形成装置101に接続されたUSBデバイスが制御される。OKボタン913は、開発者がテストの実行を指示するためのボタンである。キャンセルボタン914は、開発者がテストの実行を取り消すためのボタンである。OKボタン913が押されると、図9Cのダイアログが表示される。図9Cは、テストの実行中のダイアログの一例を示す図である。図9Cのダイアログは、全てのテストケースが実行完了すると自動的にダイアログが閉じられる。テスト実行中に中断したい場合は、開発者は、終了ボタン921を押下することでテストを終了させることができる。図9Dは、テスト終了時若しくは中断時に表示される画面の一例を示す図である。テスト結果概要表示領域931には、実行されたテストケース数及びテスト失敗数、エラー数及びテスト成功率が表示される。パッケージ情報表示領域932には、アプリケーションのパッケージ毎のテスト結果の一覧が表示される。開発者がパッケージ名933をクリックすることでテストケースごとの細かい結果も表示することができる。図10は、接続先管理テーブルの一例を示す図である。接続先管理テーブルは、テスト用アプリと開発用PCのIPアドレスとの対応を管理するためのものであり、アプリ識別子フィールド1001とIPアドレスフィールド1002とから構成される。画像形成装置101に格納され、テストブローカ407が開発用PC103からテスト開始通知を受信した際に接続先管理部603により更新される。また、遠隔USB制御ライブラリ409は、この接続先管理テーブルを利用して接続先の開発用PCを決定する。図11は、図9BのUIにてOKボタンが押され、テスト実行を指示された場合の開発PCで動作する統合開発環境の処理の流れを示すフローチャートである。まずステップS1101にてテスト制御部503がテキストフィールド911で指定された画像形成装置101上で動作しているテストブローカ407に対しテスト開始通知を送信する。テスト開始通知にはローカルのUSBデバイスを利用してテストを行うか否かの設定情報チェックボックス912の状態及びテスト用アプリの識別子情報が含まれる。次にステップS1102に進み、テスト制御部503がローカルのUSBデバイスを利用してテストを行うか否かの設定を判定する。もしローカルのUSBデバイスを利用する設定であると判定された場合、ステップS1103に進む。ステップS1103では、ライブラリ送信部504が遠隔USB制御ライブラリ409をテストブローカ407に送信し、ステップS1104に進む。一方ステップS1102にてローカルのUSBデバイスを利用する指定がされていないと判定された場合は、ステップS1104に進む。ステップS1104では、ソース管理部501がアプリケーションのソースとテストケースのソースとからテスト用アプリを生成し、生成したテスト用アプリを、テストブローカ407に送信する。次にステップS1105に進み、テスト制御部503が実行中ダイアログを表示する。次にステップS1106に進み、テスト制御部503がテストブローカ407から終了通知を受信したかを判定する。終了通知を受信したらステップS1107に進む。ステップS1107では、テスト制御部503がテストブローカ407からテスト結果を受信する。次にステップS1108に進み、テスト制御部503がテスト結果表示画面を表示して処理を終了する。一方ステップS1106にてテスト終了通知を受信していないと判定した場合はステップS1109に進む。ステップS1109では、テスト制御部503が実行中ダイアログ中の終了ボタンが押下されたかどうかを判定する。ステップS1109にて終了ボタンが押下されていないと判定した場合はステップS1106に進み、終了ボタンが押下されたと判定された場合はステップS1110に進む。ステップS1110では、テスト制御部503がテストブローカ407に対してテスト終了要求を送信し、ステップS1107に進む。それ以降の処理は前述の通りである。図12は、統合開発環境からテスト開始通知を受信した際のテストブローカ407の処理の流れを示すフローチャートである。まずステップS1201にて、テストブローカ407は、テスト開始通知に含まれる情報を参照してローカルのUSBを利用してテストを行うべきか否かを判定する。もしローカルのUSBを利用してテストを行うべきと判定した場合はステップS1202に進む。ステップS1202では統合開発環境から送信された遠隔USB制御ライブラリ409を受信し、ライブラリ制御部602が、ファイルシステムに配置する。次にステップS1203に進み、接続先管理部603は、テスト開始通知に含まれるアプリケーション識別子とテスト開始通知の送信元との対応情報を図10のように接続先管理テーブルに登録する。次にステップS1204に進み、ライブラリ制御部602は、クラスパス設定管理部402の設定を参照して遠隔USB制御ライブラリ409が優先的にロードされる設定に変更されているか否かを判定する。既に設定が変更されていた場合はステップS1206に進む。設定が変更されていないと判定された場合はステップS1205に進む。ステップS1205では、ライブラリ制御部602が、遠隔USB制御ライブラリ409が優先的に利用されるようにクラスパスの設定を変更し、ステップS1206に進む。ステップS1206ではテスト制御部601が、統合開発環境から送信されるテスト用アプリを受信し、インストール及び開始を行う。次にステップS1207に進み、テスト制御部601は、テストが完了したかどうかを判定する。ここでは、テスト制御部601は、全てのテストケースの実行が完了したか、統合開発環境からテスト終了通知を受信した場合に、テストが完了したとみなす。ステップS1207にてテストが完了していないと判定された場合はステップS1208に進む。ステップS1208では、テスト制御部601は、まだ実行していないテストケースを実行して結果を蓄積し、ステップS1207に進む。ステップS1207にてテストが完了したと判定された場合はステップS1209に進む。ステップS1209では、テスト制御部601は、統合開発環境にテスト結果を送信する。次にステップS1210に進む。ステップS1210では、テスト制御部601は、テスト用アプリの停止及び削除アンインストールを行う。次にステップS1211に進み、接続先管理部603は、接続先管理テーブルからテスト用アプリの情報を削除する。次にステップS1212に進み、テスト制御部601は、接続先管理部603に問い合わせて接続先管理テーブルに情報が存在するかどうかを判定する。もし情報が存在すると判定された場合は処理を終了する。一方ステップS1212にて情報が存在しないと判定された場合はステップS1213に進む。ステップS1213ではライブラリ制御部602は、遠隔USB制御ライブラリ409を削除し、ステップS1214に進む。ステップS1214ではライブラリ制御部602は、ステップS1205で変更したクラスパスの設定を元に戻し復旧し、処理を終了する。図13は、遠隔USB制御ライブラリ409のアプリ向けI/Fがアプリケーションから呼び出された際の処理の流れを示すフローチャートである。アプリ向けI/Fが呼び出されると、ステップS1301にてアプリ向けI/F部701は、アプリ情報管理部702に問い合わせて呼び出し元のアプリケーション識別子を取得する。アプリ情報管理部702は、コールスタックから呼び出し元アプリケーションを特定し、そのアプリケーションに含まれるアプリケーション情報を参照することでアプリケーション識別子を取得する。次にステップS1302に進み、接続先判定部703は、図10の接続先管理テーブルを参照してアプリケーション識別子に対応する接続先を特定する。次にステップS1303に進み、アプリ向けI/F部701は、通信制御部704を経由してステップS1302で特定した接続先に、呼び出された関数に応じた処理要求を送信する。処理要求の種類としては、接続されているUSBデバイスの情報取得、USBデバイスへのデータ送信、USBデバイスからのデータ受信等がある。また、アプリ向けI/F部701は、接続デバイス数が変化した場合に通知を受けるための要求も行える。次にステップS1304に進み、アプリ向けI/F部701は、通信制御部704を経由して要求に対する処理結果を受信する。もし結果が受信できればステップS1305に進み、アプリ向けI/F部701は、呼び出し元に対して結果を返して処理を終了する。一方、ステップS1304にて結果が受信できなかった場合はステップS1306に進み、アプリ向けI/F部701は、呼び出し元に対してエラーを返して処理を終了する。図14は、統合開発環境のUSBHost制御部505が遠隔USB制御ライブラリ409から処理要求を受信した際の処理の流れを示すフローチャートである。まずステップS1401にて、USBHost制御部505は、要求を受信する。次にステップS1402に進み、USBHost制御部505は、要求に応じたUSBH制御を行う。次にステップS1403に進み、USBHost制御部505は、処理結果を送信し処理を終了する。以上、説明してきたように本実施形態によれば、アプリケーションのテストを行う場合、開発用PCに接続されているUSBデバイスを制御するためのモジュールを送り込み、テスト実行中だけそのモジュールが利用されるように制御している。これにより、過去の機種においてもファームウェア全体を事前にアップデートすることなくローカルの開発用PCに接続されたUSBデバイスを利用したテストを行うことが可能になり開発者の利便性が向上する。また、USBデバイスが接続された開発用PCのアドレスとテスト用アプリとの対応を管理して接続先をテスト用アプリ毎に変更することにより、複数の開発者による開発を行っている場合に、意図しないUSBデバイスを利用してテストを行ってしまうというミスを防ぐことができるようになる。なお、本実施形態では、開発用PCとテスト用アプリとの対応を管理して複数の開発者が同時にテストを行えるような構成にしているが、このような構成に限られるものではない。例えば、既にテスト用アプリが実行中であれば他の開発用PCからのテスト要求をエラーで返すようにしてもよい。この構成では、テスト用アプリ408が存在するかどうかをテストブローカ407が管理して、テスト要求受信時にテスト用アプリ408が存在した場合にエラーを返す。これにより同時に1つのテスト用アプリしか実行されないことが保証されるため図10のような接続先管理テーブルが不要になり、より単純な構成でローカルのUSBデバイスを用いたテストを行うことが可能となる。<その他の実施形態>また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェアプログラムを、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ又はCPUやMPU等がプログラムを読み出して実行する処理である。以上、上述した各実施形態によれば、過去の機種においてもファームウェア全体を事前にアップデートすることなくローカルの開発用PCに接続されたUSBデバイスを利用したテストを行うことが可能になり、開発者の利便性が向上する。また、複数の開発者による開発を行っている場合に、意図しないUSBデバイスを利用してテストを行ってしまうというミスを防ぐことができるようになる。したがって、開発者の利便性を向上させ、また、意図しないUSBデバイスを利用してテストを行ってしまうミスを防ぐことができる。以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形変更が可能である。