(57)【要約】【課題】複数のプラットフォーム上で動作するアプリケーションの自動テストを行うためのモジュールを、可搬性を有する形で実現することができるようにする。【解決手段】DTV１には、テストの対象となるアプリケーションが搭載される。一方、PC２はアプリケーションの開発ホストであり、テスト対象のアプリケーションの他、テストに用いられる各種のデータが用意される。PC２には、テストに用いられるデータとして、DTV１に搭載されるアプリケーション全体の動作を評価するような粒度の粗いものではなく、粒度の細かいアプリケーションの動作を評価するためのデータが用意される。また、アプリケーションにイベントを実際に配信するモジュールとして、複数の異なるプラットフォームに対応したものがそれぞれPC２に用意される。本発明は、アプリケーションのテストを行う機器に適用することができる。【選択図】図１
2007072827.tif 000002
【特許請求の範囲】
【請求項１】
プラットフォーム毎に用意されるモジュールのうち、テスト対象のアプリケーションが動作するプラットフォームに応じた、イベントの配信定義を保持する配信定義保持モジュールと、イベントを配信する配信モジュールとを選択し、
選択した前記配信定義保持モジュールにより保持される配信定義に従って、テスト対象の前記アプリケーションに対して前記配信モジュールによりイベントを配信させ、
イベントが配信されたテスト対象の前記アプリケーションの状態を評価する
ステップを含む処理をコンピュータに実行させるテスト管理プログラム。
【請求項２】
アプリケーションの状態を評価するモジュールとしてアプリケーション毎に用意される評価モジュールのうち、テスト対象の前記アプリケーション用の評価モジュールを選択するステップをさらに含み、
イベントが配信されたテスト対象の前記アプリケーションの状態の評価は、選択された評価モジュールにより行われる
請求項１に記載のテスト管理プログラム。
【請求項３】
前記テスト管理プログラム自身はテスト対象の前記アプリケーションの開発ホストとしてのコンピュータに用意され、前記アプリケーションを搭載する電気機器において実行される
請求項１に記載のテスト管理プログラム。
【請求項４】
前記テスト管理プログラム自身はネットワークを介して前記コンピュータから前記電気機器に提供される
請求項３に記載のテスト管理プログラム。
【請求項５】
前記配信定義はXML形式で記述される
請求項１に記載のテスト管理プログラム。
【請求項６】
プラットフォーム毎に用意されるモジュールのうち、テスト対象のアプリケーションが動作するプラットフォームに応じた、イベントの配信定義を保持する配信定義保持モジュールと、イベントを配信する配信モジュールとを選択し、
選択した前記配信定義保持モジュールにより保持される配信定義に従って、テスト対象の前記アプリケーションに対して前記配信モジュールによりイベントを配信させ、
イベントが配信されたテスト対象の前記アプリケーションの状態を評価する
ステップを含むアプリケーションのテスト管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、テスト管理プログラムおよび方法に関し、特に、複数のプラットフォーム上で動作するアプリケーションの自動テストを行うためのモジュールを、可搬性を有する形で実現することができるようにしたテスト管理プログラムおよび方法に関する。
【背景技術】
【０００２】
近年、CE(Consumer Electronics)機器の高機能化が進んでおり、そのような高機能なCE機器に搭載されるソフトウエアの開発においては、ソフトウエア構成の複雑さから、品質保証のためのテストに膨大な工数が必要になる。
【０００３】
品質保証のためのテストとしては、例えば、バリテーションスタッフと呼ばれる人が、CE機器のリモートコントローラを用いて、テスト項目としてあらかじめ定められる様々な操作を手動で行い、想定された通りに動作するか否かを検証する方法がある。
【０００４】
また、人が行うことは非常に手間がかかることから、リモートコントローラの操作などに相当するイベントをCE機器に対して配信し、イベントに対するCE機器の動作を自動的に検証するシステムも提案されている（例えば、特許文献１乃至５）。
【０００５】
【特許文献１】特開２００５−１０００６８号公報
【特許文献２】特開２００３−２９６１３４号公報
【特許文献３】特開２００４−２８０２３１号公報
【特許文献４】特開２００４−１１０２６７号公報
【特許文献５】特開２００２−３６６３８７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ところで、それぞれ異なる部署の社員などにより開発される複数のソフトウエアモジュールを組み合わせて構成される大規模なソフトウエアの開発においては、テストの統合が困難であり、例えば、テスト内容をソフトウエアモジュール毎に分担して定義することができない場合、動作を並行して検証することができず作業効率が悪いという問題がある。
【０００７】
また、同一のシステムやシステム上で動作するアプリケーションを複数の異なるプラットフォームに移植する場合、イベントの自動配信や自動テストを行うモジュールの移植も問題になる。
【０００８】
例えば、テレビジョン受像機と携帯機器にそれぞれ搭載された同一のシステムの検証を行う場合、特に、イベントの配信機構がプラットフォームに依存し、テレビジョン受像機のプラットフォームと携帯機器のプラットフォームとでイベントの配信順序が異なったりすることから、このことが可搬性を実現する際の障害となり、テレビジョン受像機と携帯機器のプラットフォーム毎に、イベントの自動配信や自動テストを行うモジュールを用意する必要がある。
【０００９】
さらに、予め用意されたイベント配信定義情報（どのイベントをどの順序で配信するのかを定義する情報）に基づいて行われる自動テストにおいては、その定義付けを行うこと自体の困難さも、可搬性を実現する際の障害になる。
【００１０】
本発明はこのような状況に鑑みてなされたものであり、特に、複数のプラットフォーム上で動作するアプリケーションの自動テストを行うためのモジュールを、可搬性を有する形で実現することができるようにするものである。
【課題を解決するための手段】
【００１１】
本発明の一側面のテスト管理プログラムは、プラットフォーム毎に用意されるモジュールのうち、テスト対象のアプリケーションが動作するプラットフォームに応じた、イベントの配信定義を保持する配信定義保持モジュールと、イベントを配信する配信モジュールとを選択し、選択した前記配信定義保持モジュールにより保持される配信定義に従って、テスト対象の前記アプリケーションに対して前記配信モジュールによりイベントを配信させ、イベントが配信されたテスト対象の前記アプリケーションの状態を評価するステップを含む。
【００１２】
アプリケーションの状態を評価するモジュールとしてアプリケーション毎に用意される評価モジュールのうち、テスト対象の前記アプリケーション用の評価モジュールを選択するステップをさらに含むことができる。この場合、イベントが配信されたテスト対象の前記アプリケーションの状態の評価は、選択された評価モジュールにより行われる。
【００１３】
前記テスト管理プログラム自身はテスト対象の前記アプリケーションの開発ホストとしてのコンピュータに用意され、前記アプリケーションを搭載する電気機器において実行させることができる。
【００１４】
前記テスト管理プログラム自身はネットワークを介して前記コンピュータから前記電気機器に提供させることができる。
【００１５】
前記配信定義はXML形式で記述させることができる。
【００１６】
本発明の一側面のテスト管理方法は、プラットフォーム毎に用意されるモジュールのうち、テスト対象のアプリケーションが動作するプラットフォームに応じた、イベントの配信定義を保持する配信定義保持モジュールと、イベントを配信する配信モジュールとを選択し、選択した前記配信定義保持モジュールにより保持される配信定義に従って、テスト対象の前記アプリケーションに対して前記配信モジュールによりイベントを配信させ、イベントが配信されたテスト対象の前記アプリケーションの状態を評価するステップを含む。
【００１７】
本発明の一側面においては、プラットフォーム毎に用意されるモジュールのうち、テスト対象のアプリケーションが動作するプラットフォームに応じた、イベントの配信定義を保持する配信定義保持モジュールと、イベントを配信する配信モジュールとが選択される。また、選択された前記配信定義保持モジュールにより保持される配信定義に従って、テスト対象の前記アプリケーションに対して前記配信モジュールによりイベントが配信され、イベントが配信されたテスト対象の前記アプリケーションの状態が評価される。
【発明の効果】
【００１８】
本発明の一側面によれば、複数のプラットフォーム上で動作するアプリケーションの自動テストを行うためのモジュールを、可搬性を有する形で実現することができる。
【発明を実施するための最良の形態】
【００１９】
以下に本発明の実施の形態を説明するが、本発明の構成要件と、明細書又は図面に記載の実施の形態との対応関係を例示すると、次のようになる。この記載は、本発明をサポートする実施の形態が、明細書又は図面に記載されていることを確認するためのものである。従って、明細書又は図面中には記載されているが、本発明の構成要件に対応する実施の形態として、ここには記載されていない実施の形態があったとしても、そのことは、その実施の形態が、その構成要件に対応するものではないことを意味するものではない。逆に、実施の形態が発明に対応するものとしてここに記載されていたとしても、そのことは、その実施の形態が、その構成要件以外には対応しないものであることを意味するものでもない。
【００２０】
本発明の一側面のテスト管理プログラム（例えば、図５のテスト管理モジュール８４）は、プラットフォーム毎に用意されるモジュールのうち、テスト対象のアプリケーション（例えば、図５のメニュー画面表示アプリケーション８２）が動作するプラットフォームに応じた、イベントの配信定義を保持する配信定義保持モジュール（例えば、図５のイベント配信定義保持モジュール８６Ａ）と、イベントを配信する配信モジュール（例えば、図５のイベント配信モジュール８７Ａ）とを選択し（例えば、図６のステップＳ２）、選択した前記配信定義保持モジュールにより保持される配信定義に従って、テスト対象の前記アプリケーションに対して前記配信モジュールによりイベントを配信させ（例えば、図６のステップＳ１２）、イベントが配信されたテスト対象の前記アプリケーションの状態を評価する（例えば、図６のステップＳ１９）ステップを含む。
【００２１】
このテスト管理プログラムには、アプリケーションの状態を評価するモジュールとしてアプリケーション毎に用意される評価モジュールのうち、テスト対象の前記アプリケーション用の評価モジュール（例えば、図５のメニュー画面表示アプリケーション評価用モジュール８３）を選択するステップ（例えば、図６のステップＳ４）をさらに含ませることができる。
【００２２】
前記テスト管理プログラム自身はテスト対象の前記アプリケーションの開発ホストとしてのコンピュータ（例えば、図１のPC２）に用意され、前記アプリケーションを搭載する電気機器（例えば、図１のDTV１）において実行させることができる。
【００２３】
本発明の一側面のテスト管理方法は、プラットフォーム毎に用意されるモジュールのうち、テスト対象のアプリケーション（例えば、図５のメニュー画面表示アプリケーション８２）が動作するプラットフォームに応じた、イベントの配信定義を保持する配信定義保持モジュール（例えば、図５のイベント配信定義保持モジュール８６Ａ）と、イベントを配信する配信モジュール（例えば、図５のイベント配信モジュール８７Ａ）とを選択し（例えば、図６のステップＳ２）、選択した前記配信定義保持モジュールにより保持される配信定義に従って、テスト対象の前記アプリケーションに対して前記配信モジュールによりイベントを配信させ（例えば、図６のステップＳ１２）、イベントが配信されたテスト対象の前記アプリケーションの状態を評価する（例えば、図６のステップＳ１９）ステップを含む。
【００２４】
以下、本発明の実施の形態について図を参照して説明する。
【００２５】
図１は、本発明の一実施形態に係るアプリケーション（アプリケーションプログラム）のテストが実行される環境の例を示す図である。
【００２６】
図１に示されるように、このテストは、例えば、DTV(Digital Television)１とPC(Personal Computer)２がネットワーク３を介して接続される環境において実行される。
【００２７】
DTV１は、テストの対象となるアプリケーションが搭載される機器である。DTV１は、PC２に用意されている実行ファイルをネットワーク３を介してロードし、それを実行することによって、搭載する所定のアプリケーションを対象としてテストを開始する。テストに用いられるDLL(Dynamic Link Library)や各種のデータは、適宜、PC２から、あるいは、DTV１に用意されているデータ領域からロードされることによって取得される。
【００２８】
例えば、アプリケーションの開発時には、搭載される予定のアプリケーション自体も、PC２から読み込まれ、DTV１上で、アプリケーションのテストが行われる。
【００２９】
DTV１には、各種の機能をユーザが利用するために用いられるメニュー画面を表示するアプリケーションや、放送波を受信することによって取得されたEPG(Electronic Program Guide)データに基づいて番組表を表示するアプリケーションなどが出荷時には搭載されるため、これらのアプリケーションがテストの対象とされる。なお、メニュー画面を表示するアプリケーションや番組表を表示するアプリケーションは、DTV１以外にも移植され、他の機器のプラットフォーム上でも動作するものである。
【００３０】
例えば、はじめに、メニュー画面を表示するアプリケーションがPC２から読み込まれてテストが行われた後、番組表を表示するアプリケーションがPC２から読み込まれてテストが行われるといったように、それぞれのアプリケーションを分けてテストを行うことができるようになされている。すなわち、搭載される予定の全てのアプリケーションをDTV１に組み込んだ形でテストを行う必要がない。
【００３１】
DTV１においては、テスト対象のアプリケーションがイベントに応じて想定される動作を行っているか否かが評価され、評価結果を表すログが所定のタイミングでネットワーク３を介してPC２に送信される。
【００３２】
PC２は、DTV１に搭載されるアプリケーションの開発ホストの機器である。PC２には、テスト対象のアプリケーション（DTV１に搭載される、開発中のアプリケーション）の他、テストに用いられる各種のデータが用意されており、それらのデータは、DTV１からの要求などに応じて、適宜、ネットワーク３を介してDTV１に提供される。
【００３３】
このように、人によるリモートコントローラなどの操作によらずに、イベントが自動的に配信され（DTV１の内部において発生されたイベントが、テスト対象のアプリケーションに配信され）、それに基づいてアプリケーションの評価が行われるため、DTV１に搭載されるアプリケーションのテストを人の手によらずに行うことが可能となる。
【００３４】
また、PC２には、テストに用いられるデータとして、DTV１に搭載されるアプリケーション全体の動作を評価するような粒度の粗いものではなく、メニュー画面を表示するアプリケーションの動作を評価するだけ、または、番組表を表示するアプリケーションの動作を評価するだけといった、粒度の細かいアプリケーションの動作を評価するためのデータが用意されるから、それぞれのアプリケーションのテストを複数人で分担して行うことができ、作業効率が高い。
【００３５】
さらに、イベントを実際に配信するモジュールが、テスト全体を管理するモジュールとは分離してPC２に用意され、また、イベントを実際に配信するモジュールは、複数の異なるプラットフォームに対応したものがそれぞれPC２に用意されるから、テスト全体を管理するモジュールなどはプラットフォームの違いによらずに流用することができる。
【００３６】
すなわち、テスト対象のアプリケーションを搭載する機器が、図１に示されるようなDTV１であっても、DTV１とは異なるプラットフォームを有する携帯機器のような機器であっても、イベントを配信するモジュールをそれぞれのプラットフォームに応じて使い分けることにより、テスト全体を管理するモジュールなどの一部のデータは流用することができる。
【００３７】
また、後に詳述するように、イベントの定義を解釈してイベント配信モジュール（イベントを実際に配信するモジュール）にイベントを投入するモジュールと、プラットフォーム特有のイベント定義を解釈するモジュールとを、テスト全体を管理するモジュールとは分離して設計することにより、テストの自動実行定義（自動的に行われるテストの内容）の再利用性を最大限に高め、イベント定義の自由度を高めることができる。
【００３８】
また、どのイベントをどのタイミングで配信するのかが記述されるイベントの配信定義が、例えば、XML(eXtensible Markup Language)形式で、人間が理解しやすい構造で内容を記述することができるようになされているから、テストの管理者は、イベント配信のタイミングと、それぞれのタイミングで配信されるイベントの内容を表すIDなどによってイベントの配信定義を用意する場合に較べて、イベント配信の定義を容易に行うことができ、イベント配信定義にかかるコストを低減させることができる。
【００３９】
PC２に用意され、アプリケーションのテストのときにDTV１において用いられるモジュールなどについては後述する。
【００４０】
図２は、図１のDTV１のハードウエア構成例を示すブロック図である。
【００４１】
DTV１は、CPU(Central Processing Unit)，ROM(Read Only Memory)，RAM(Random Access Memory)などにより構成される制御部１１に対して、各処理部がバス１２を介して接続されることによって構成される。
【００４２】
地上アナログ放送受信部１３は、制御部１１による制御に従って地上アナログテレビジョン放送信号を受信し、復調して得られた画像信号（映像信号）と音声信号をインタフェース１４を介してバス１２に出力する。制御部１１から地上アナログ放送受信部１３に対しては、リモートコントローラ３１が操作されることによってユーザにより選択されたチャンネルを受信することの指示が行われる。他の放送受信部に対しても同様に、ユーザによる操作に応じた指示が制御部１１から行われる。
【００４３】
地上ディジタル放送受信部１５は、ディジタルテレビジョン放送、データ放送に対応しており、制御部１１による制御に従って地上ディジタル放送を受信する。地上ディジタル放送受信部１５は、放送信号をデコードすることによって得られた番組の画像信号と音声信号、EPGデータ等を、インタフェース１６を介してバス１２に出力する。
【００４４】
BS(Broadcasting Satellite)放送受信部１７は、BSテレビジョン放送、BS音声放送（ラジオ放送）、およびデータ放送に対応しており、制御部１１による制御に従ってBSディジタル放送を受信する。BS放送受信部１７は、放送信号をデコードすることによって得られた番組の画像信号と音声信号、EPGデータ等を、インタフェース１８を介してバス１２に出力する。
【００４５】
CS(Communications Satellite)放送受信部１９は、CSテレビジョン放送、CS音声放送、およびデータ放送に対応しており、制御部１１による制御に従ってCSディジタル放送を受信する。CS放送受信部１９は、放送信号をデコードすることによって得られた番組の画像信号と音声信号、EPGデータ等を、インタフェース２０を介してバス１２に出力する。
【００４６】
表示画像生成出力部２１は、制御部１１による制御に従って各種の画像をディスプレイ２２に表示させる。例えば、表示画像生成出力部２１は、バス１２を介して地上アナログ放送受信部１３、地上ディジタル放送受信部１５、BS放送受信部１７、CS放送受信部１９から供給された画像データに基づいて番組の画像をディスプレイ２２に表示させる。
【００４７】
また、表示画像生成出力部２１は、OSD(On Screen Display)機能を有しており、制御部１１による制御に従って、ユーザがDTV１を用いて各種の操作を行うためのGUI(Graphical User Interface)であるメニュー画面をディスプレイ２２に表示させる。メニュー画面に並べられる文字や記号などのアイコンのデータは、メモリ３２の表示用データ記憶部４１に記憶されている。
【００４８】
ディスプレイ２２はLCD(Liquid Crystal Display)などより構成され、バス１２、ディスプレイインタフェース２３を介して行われる表示画像生成出力部２１による制御に従って、番組の画像、メニュー画面などを表示する。
【００４９】
スピーカ２４は、制御部１１などによる制御に従って、地上アナログ放送受信部１３、地上ディジタル放送受信部１５、BS放送受信部１７、CS放送受信部１９からバス１２、音声出力インタフェース２５を介して供給された音声データに対応する音声を出力する。
【００５０】
メモリカードドライブ２６は、DTV１の筐体に形成されたスロットに挿入されたメモリカード２７からのデータの読み出し、メモリカード２７に対するデータの書き込みを行う。メモリカード２７からは、例えば、ディジタルカメラなどにより撮影された静止画のデータなどが読み出される。
【００５１】
外部入出力インタフェース２８は、DTV１の筐体に形成された映像入出力端子、音声入出力端子、USB(Universal Serial Bus)端子、IEEE(Institute of Electrical and Electronics Engineers)1394端子、HDMI(High-Definition Multimedia Interface)端子などの外部入出力端子２８−１乃至２８−ｎに各種のケーブルを介して接続された機器との間でデータ（信号）の送受信を行う。
【００５２】
通信インタフェース２９は、ネットワーク３を介して、PC２を含む各種の機器との間でデータの送受信を行う。
【００５３】
受光部３０は、リモートコントローラ３１からの赤外線を受光し、復調して得られたユーザ操作に対応する信号をバス１２を介して制御部１１に出力する。リモートコントローラ３１には、十字キー、決定キーの他、例えば、メニュー画面を表示するときに操作されるホームキーなども設けられる。
【００５４】
メモリ３２はフラッシュメモリなどよりなり、そこには、表示用データ記憶部４１とEPGデータ記憶部４２が形成される。表示用データ記憶部４１には、メニュー画面を表示するためのアイコンのデータなどが記憶され、EPGデータ記憶部４２には、地上アナログ放送受信部１３、地上ディジタル放送受信部１５、BS放送受信部１７、CS放送受信部１９により取得されたEPGデータが記憶される。
【００５５】
図３は、図１のPC２の構成例を示すブロック図である。
【００５６】
CPU５１は、ROM５２、または記憶部５８に記憶されているプログラムに従って各種の処理を実行する。RAM５３には、CPU５１が実行するプログラムやデータなどが適宜記憶される。これらのCPU５１、ROM５２、およびRAM５３は、バス５４により相互に接続されている。
【００５７】
CPU５１にはまた、バス５４を介して入出力インタフェース５５が接続されている。入出力インタフェース５５には、キーボード、マウス、マイクロホンなどよりなる入力部５６、ディスプレイ、スピーカなどよりなる出力部５７が接続されている。CPU５１は、入力部５６から入力される指令に対応して各種の処理を実行する。そして、CPU５１は、処理の結果を出力部５７に出力する。
【００５８】
入出力インタフェース５５に接続されている記憶部５８は、例えばハードディスクからなり、CPU５１が実行するプログラムや、テストのためにDTV１に提供される各種のデータを記憶する。通信部５９は、インターネットやローカルエリアネットワークなどのネットワーク３を介して例えばDTV１と通信を行う。
【００５９】
入出力インタフェース５５に接続されているドライブ６０は、メモリカード６１が装着されたとき、そこに記録されているプログラムやデータなどを取得したり、所定のプログラムやデータなどを記録させたりする。
【００６０】
図４は、以上のような構成を有するPC２に用意されるデータの例を示す図である。
【００６１】
図４に示されるように、PC２には、メイン関数保持モジュール８１、メニュー画面表示アプリケーション８２、メニュー画面表示アプリケーション評価用モジュール８３、テスト管理モジュール８４、セット状態管理モジュール８５、イベント配信定義保持モジュール８６Ａ（プラットフォームＡ用）、イベント配信定義保持モジュール８６Ｂ（プラットフォームＢ用）、イベント配信モジュール８７Ａ（プラットフォームＡ用）、イベント配信モジュール８７Ｂ（プラットフォームＢ用）、および各種のデータ８８が用意される。
【００６２】
メイン関数保持モジュール８１は、DTV１に搭載される複数のアプリケーションに共通の関数を保持するモジュールである。上述したように、DTV１には、メニュー画面を表示するアプリケーション、番組表を表示するアプリケーションなどが搭載されるが、それらのアプリケーションに共通の関数が保持される。後述するテスト管理モジュール８４も、例えば、このメイン関数保持モジュール８１の一部として用意される。
【００６３】
メニュー画面表示アプリケーション８２は、DTV１に搭載される、メニュー画面を表示するアプリケーションであり、DTV１上で実行されることによってテストの対象とされる。すなわち、図４は、DTV１に搭載される各種のアプリケーションのうち、メニュー画面表示アプリケーションの動作をテストするときにPC２に用意されるデータの例を示している。EPGデータに基づいて番組表を表示するアプリケーション（番組表表示アプリケーション）のテストを行う場合、PC２には、番組表表示アプリケーションが用意される。
【００６４】
メニュー画面表示アプリケーション評価用モジュール８３は、メニュー画面表示アプリケーション８２のテストケースのまとまりである。
【００６５】
テスト管理モジュール８４は、DTV１においてロードされることによってテスト全体を管理するモジュールである。
【００６６】
セット状態管理モジュール８５は、セット（DTV１）の状態を管理し、アプリケーションを起動させたり、起動させたアプリケーションに対してイベントを配信するモジュールである。
【００６７】
イベント配信定義保持モジュール８６Ａは、テスト対象のメニュー画面表示アプリケーション８２がプラットフォームＡの上で動作するものである場合のイベント配信定義情報を保持するモジュールである。イベントの中には、同じイベントでもプラットフォームの違いによって配信先が異なったり、配信順序が異なったりするものがあり、このイベント配信定義保持モジュール８６Ａにより、プラットフォームＡの上で動作するメニュー画面表示アプリケーション８２をテスト対象としたときに、どのイベントをどの順序で配信するのかを表す配信定義情報が保持される。
【００６８】
イベント配信定義保持モジュール８６Ｂは、テスト対象のメニュー画面表示アプリケーション８２がプラットフォームＢの上で動作するものである場合のイベント配信定義情報を保持するモジュールである。
【００６９】
このように、PC２には、イベント配信定義情報を保持するモジュールがプラットフォーム毎に用意され、テスト対象のアプリケーションが動作するプラットフォームに応じて適宜選択可能になされている。
【００７０】
イベント配信モジュール８７Ａは、プラットフォームＡの上で動作するテスト対象のメニュー画面表示アプリケーション８２に対して直接に、または他のモジュールを介して間接的に、イベントを配信するモジュールである。
【００７１】
イベント配信モジュール８７Ｂは、プラットフォームＢの上で動作するテスト対象のメニュー画面表示アプリケーション８２に対して直接に、または他のモジュールを介して間接的に、イベントを配信するモジュールである。
【００７２】
このように、PC２には、イベントを実際に配信するモジュールもプラットフォーム毎に用意され、テスト対象のアプリケーションが動作するプラットフォームに応じて適宜選択可能になされている。
【００７３】
各種のデータ８８は、レジストリ情報や画像ファイルなど、それぞれのモジュールが必要とするデータである。
【００７４】
図５は、図４に示されるモジュールのうちの所定のモジュールがロードされることによってDTV１において実現される機能的な構成の例を示すブロック図である。
【００７５】
図５において、図２と図４に示した部分と同じ部分には同じ符号を付してある。また、それぞれの機能部間を結ぶ矢印に付されている数字（数字や「*」）は多重度を表す。なお、図５においては、テストの対象となるアプリケーションを搭載するDTV１のプラットフォームはプラットフォームＡであるものとする。DTV１のプラットフォームがプラットフォームＡであるから、イベント配信モジュールとイベント配信定義保持モジュールとしてはプラットフォームＡ用のものが選択される。
【００７６】
メイン関数保持モジュール８１は、例えば、テストの開始時、Update配信モジュール９１を起動させる。
【００７７】
メニュー画面表示アプリケーション８２は、この例においてはテスト対象のモジュールであり、配信されたイベントに応じて処理を行い、例えばメニュー画面の表示状態を変化させる。この状態の変化がメニュー画面表示アプリケーション評価用モジュール８３により評価される。
【００７８】
メニュー画面表示アプリケーション評価用モジュール８３は、テスト管理モジュール８４によりロードされ、あるイベントがイベント配信モジュール８７Ａからメニュー画面表示アプリケーション８２に対して配信されたときに、それに応じてメニュー画面表示アプリケーション８２が適切な状態になっているか否かを監視し、メニュー画面表示アプリケーション８２の状態を評価する。例えば、メニュー画面表示アプリケーション評価用モジュール８３は、１つのイベントが配信される毎に、その評価結果をPC２に通知する。
【００７９】
また、メニュー画面表示アプリケーション評価用モジュール８３は、テスト管理モジュール８４に対してイベント配信の中断／再開を適宜要求したり、テスト管理モジュール８４のインタフェースを設定したりする。
【００８０】
このような機能を有するメニュー画面表示アプリケーション評価用モジュール８３は、メニュー画面表示アプリケーション８２に対して配信されるイベントに応じて取り替えられる。すなわち、メニュー画面表示アプリケーション評価用モジュール８３はテスト管理モジュール８４に対して着脱可能になされている。
【００８１】
テスト管理モジュール８４は、メイン関数保持モジュール８１からロードされ、Update配信モジュール９１による駆動に従ってテスト全体を管理する。例えば、テスト管理モジュール８４は、自身のロード時に、メニュー画面表示アプリケーション評価用モジュール８３、イベント配信定義保持モジュール８６Ａ、イベント配信モジュール８７ＡのDLLファイルのパスをレジストリ９２から取得し、それを設定することによってそれらのモジュールをロードする。
【００８２】
テスト管理モジュール８４は、次に配信するイベントをイベント配信定義保持モジュール８６Ａから取得し、取得したイベントの配信をイベント配信モジュール８７Ａに要求する。メニュー画面表示アプリケーション評価用モジュール８３が評価可能な全てのイベントの配信を終えたとき、テスト管理モジュール８４は、次のメニュー画面表示アプリケーション評価用モジュール８３をロードし、それを順次繰り返す。
【００８３】
なお、テスト管理モジュール８４は、イベント配信定義保持モジュール８６Ａの実装に依存しておらず、XML形式のイベント配信定義ファイルを読み込み、次のイベントのインスタンスを生成するイベント配信定義保持モジュール８６Ａを利用したり、既存の実行ログを読み込み、次のイベントのインスタンスを生成するイベント配信定義保持モジュール８６Ａを利用するなど、利用するイベント配信定義保持モジュール８６Ａを付け替えることができる。
【００８４】
また、テスト管理モジュール８４は、イベント配信モジュール８７Ａの実装にも依存しておらず、DTV１が１つのマイクロコンピュータから構成されるセットである場合は自身のマイクロコンピュータ上のシステムに対してイベント配信を行うイベント配信モジュール８７Ａを利用したり、２つのマイクロコンピュータから構成されるセットである場合は他のマイクロコンピュータへのイベント配信要求を行うイベント配信モジュール８７Ａを利用するといったように、利用するイベント配信モジュール８７Ａを付け替えることができる。
【００８５】
イベント配信定義保持モジュール８６Ａは、プラットフォームＡの上で動作するメニュー画面表示アプリケーション８２に対して、どのイベントをどの順序で配信するのかを表すイベント配信定義情報を保持しており、テスト管理モジュール８４からの問い合わせに応じて次に配信するイベントを返す。
【００８６】
なお、テスト対象のアプリケーションが、プラットフォームＡの上ではなくプラットフォームＢの上で動作するものである場合、イベント配信定義保持モジュール８６Ａに替えてイベント配信定義保持モジュール８６Ｂが用いられる。
【００８７】
イベント配信モジュール８７Ａは、テスト管理モジュール８４からの要求に従って、プラットフォームＡの上で動作するメニュー画面表示アプリケーション８２に対してイベントを配信したり、セット全体に対してイベントを配信したりする。テスト管理モジュール８４からの要求には、イベント配信定義保持モジュール８６Ａにより取得された、どのイベントを配信するのかを表す情報などが含まれている。メニュー画面表示アプリケーション８２に対するイベントの配信は、例えば、リモートコントローラ受信部９３を介して行われる。
【００８８】
なお、テスト対象のアプリケーションが、プラットフォームＡの上ではなくプラットフォームＢの上で動作するものである場合、イベント配信モジュール８７Ａに替えてイベント配信モジュール８７Ｂが用いられる。
【００８９】
Update配信モジュール９１は、タイマとしての機能を有しており、テスト管理モジュール８４により登録された関数に従ってコールバック（Update配信）を定期的に繰り返すことによって、配信されたイベントがテスト対象のモジュールであるメニュー画面表示アプリケーション８２に伝えられるようにする。
【００９０】
リモートコントローラ受信部９３は、イベント配信モジュール８７Ａからの指示に従って、あるいは、リモートコントローラ３１からの信号を受信する受光部３０からの指示に従ってイベントを配信する。
【００９１】
ここで、図６を参照して、各機能部により行われる一連の処理について説明する。
【００９２】
ステップＳ１において、テスト管理モジュール８４はメイン関数保持モジュール８１からロードされ、ステップＳ２に進み、イベント配信モジュールのDLLファイルのパスをレジストリ９２から取得する。プラットフォームＡの上で動作するメニュー画面表示アプリケーション８２をテスト対象とする場合、イベント配信モジュール８７Ａを指定するパスがレジストリ９２に設定されている。
【００９３】
ステップＳ３において、テスト管理モジュール８４はイベント配信モジュール８７Ａをロードし、ステップＳ４に進み、評価用モジュールのDLLファイルのパスをレジストリ９２から取得する。
【００９４】
ステップＳ５において、テスト管理モジュール８４はメニュー画面表示アプリケーション評価用モジュール８３をロードし、ステップＳ６に進み、自身のインタフェースを公開する。例えば、メニュー画面表示アプリケーション評価用モジュール８３とテスト管理モジュール８４は双方がインタフェースを有しており、テスト管理モジュール８４は、メニュー画面表示アプリケーション評価用モジュール８３により登録されたインタフェース越しに自身のインタフェースを公開することによって、双方で情報のやりとりを行うことができるようにする。
【００９５】
ステップＳ７において、メニュー画面表示アプリケーション評価用モジュール８３は、イベント配信定義保持モジュールのDLLファイルのパスと、イベント配信定義保持モジュールの初期化用のデータを指定する。
【００９６】
ステップＳ８において、テスト管理モジュール８４は、メニュー画面表示アプリケーション評価用モジュール８３からの指定に従ってイベント配信定義保持モジュール８６Ａをロードし、ステップＳ９に進み、メニュー画面表示アプリケーション評価用モジュール８３から指定されたデータを用いてイベント配信定義保持モジュール８６Ａを初期化する。例えば、イベントが定義されたファイルのパスなどが初期化用のデータとして用いられる。このように、イベント配信定義保持モジュール８６ＡのDLLファイルのパスは、レジストリ９２から取得されるのではなく、メニュー画面表示アプリケーション評価用モジュール８３から指定されることによって取得されるようにしてもよい。
【００９７】
ステップＳ１０においてUpdate配信モジュール９１からUpdate配信が行われたとき、ステップＳ１１において、テスト管理モジュール８４は、イベント配信定義保持モジュール８６Ａに問い合わせることによって次のイベントを取得する。
【００９８】
テスト管理モジュール８４は、次のイベントがnormalイベント、またはdirectイベントである場合、ステップＳ１２に進み、イベント配信モジュール８７Ａにイベントのポスト（イベントを渡すこと）を要求する。
【００９９】
イベントの種類には、normalイベント、directイベント、otherイベントの３つが例えば規定されており、次のイベントがどの種類のイベントであるのかを表す情報も、イベント配信定義保持モジュール８６Ａに対する問い合わせにより取得される。ここで、normalイベントは、テスト対象のアプリケーションに配信されるイベントであり、directイベントはリモートコントローラ受信部９３が処理するイベントである。また、otherイベントは評価用のイベントである。
【０１００】
ステップＳ１３において、イベント配信モジュール８７Ａは、次のイベントがnormalイベント、またはdirectイベントである場合、イベントをリモートコントローラ受信部９３にポストする。
【０１０１】
ステップＳ１４において、リモートコントローラ受信部９３は、次のイベントがnormalイベント、またはotherイベントである場合、イベントの配信をセット状態管理モジュール８５に要求する。otherイベントは、例えば、図５に示されるように、受光部３０からリモートコントローラ受信部９３に対してポストされる。
【０１０２】
ステップＳ１５において、セット状態管理モジュール８５は、セットの状態を元に、イベントをメニュー画面表示アプリケーション８２に配信するか、自身で処理するかを判断し、要求されたイベントがotherイベントである場合、ステップＳ１６に進み、メニュー画面表示アプリケーション８２を起動させるなどしてセットの状態を変更する。
【０１０３】
例えば、リモートコントローラ３１に設けられるホームキーを押したことに相当するイベントが渡された場合、セット状態管理モジュール８５はメニュー画面表示アプリケーション８２を起動させ、イベントをメニュー画面表示アプリケーション８２に配信することができる状態にする。
【０１０４】
一方、ステップＳ１５において、セット状態管理モジュール８５は、要求されたイベントがnormalイベントであると判断した場合、ステップＳ１７に進み、メニュー画面表示アプリケーション８２にイベントを配信する。
【０１０５】
ステップＳ１８において、テスト管理モジュール８４は、メニュー画面表示アプリケーション８２に対してイベントが配信されたことをメニュー画面表示アプリケーション評価用モジュール８３に通知する。
【０１０６】
ステップＳ１９において、メニュー画面表示アプリケーション評価用モジュール８３は、メニュー画面表示アプリケーション８２の状態を評価し、評価結果を取得する。取得された評価結果は、所定のタイミングでPC２に提供される。
【０１０７】
以上のような一連の処理のうちのステップＳ１０乃至Ｓ１９の処理はイベントが取得される毎に繰り返され、ステップＳ１１においてイベントを取得することができなかったとき（全てのイベントを処理したとき）、そのときロードされているメニュー画面表示アプリケーション評価用モジュール８３は破棄される。また、メニュー画面表示アプリケーション８２を評価するための次の評価用モジュールがある場合には、その評価用モジュールを用いて、ステップＳ５以降の処理が順次行われる。
【０１０８】
なお、ステップＳ１３乃至Ｓ１７の処理は、イベント配信モジュール８７Ａの設計により、適宜、イベントの配信に至る他の処理に置き換えられる。
【０１０９】
以上のような処理が行われることにより、プラットフォームの違いにかかわらず、自動テストを行う上で中心となるテスト管理モジュール８４を流用することが可能となり、複数のプラットフォーム上で動作するアプリケーションの自動テストを行うためのモジュールを、可搬性を有する形で実現することができる。
【０１１０】
また、DTV１に搭載されるアプリケーション全体の動作をテストするためのイベント配信定義を用意する必要がなく、その一部を対象としたものだけを用意すれば済む。
【０１１１】
なお、イベント配信定義ファイル（XML形式のファイル）中では、各イベントの種類は、基本的に、複数プラットフォームに移植されるシステムで汎用的に定義されたイベント定義名により指定される。プラットフォーム特有なイベントに関しては、別途、イベント定義がなされることになる。
【０１１２】
このプラットフォーム特有なイベントが記述されたイベント配信定義ファイルの解釈もプラットフォーム毎に変えることができるようにすることで、イベント配信定義ファイルにも可搬性を与えることができる。
【０１１３】
例えば、イベント配信定義ファイルに記述されているイベント内容をイベント配信モジュールが解釈できるコードに翻訳するための辞書の役割をする翻訳モジュールが別に用意され、その翻訳モジュールがイベント配信定義保持モジュールにより用いられることによって、イベント配信定義ファイルの解釈をプラットフォーム毎に変えることが実現される。
【０１１４】
なお、この場合、イベント配信定義保持モジュールは翻訳モジュールの実装に依存せず、イベント配信定義保持モジュールに対して翻訳モジュールの着脱が可能とされる。
【０１１５】
また、以上においては、アプリケーションのテストに用いられる各種のデータは、ネットワーク３を介してPC２からDTV１に提供されるものとしたが、図３のメモリカード６１を介して提供されるようにしてもよい。この場合、各種のデータがPC２により書き込まれたメモリカード６１がDTV１の筐体に形成されるスロットに挿入され、記憶されているデータがDTV１により読み出されることによってデータの提供が行われる。
【図面の簡単な説明】
【０１１６】
【図１】本発明の一実施形態に係るアプリケーションのテストが実行される環境の例を示す図である。
【図２】図１のDTVのハードウエア構成例を示すブロック図である。
【図３】図１のPCの構成例を示すブロック図である。
【図４】PCに用意されるデータの例を示す図である。
【図５】DTVにおいて実現される機能的な構成の例を示すブロック図である。
【図６】各機能部により行われる一連の処理について説明する図である。
【符号の説明】
【０１１７】
１  DTV，  ２  PC，  ３  ネットワーク，  ８１  メイン関数保持モジュール，  ８２  メニュー画面表示アプリケーション，  ８３  メニュー画面表示アプリケーション評価用モジュール，  ８４  テスト管理モジュール，  ８５  セット状態管理モジュール，  ８６ＡおよびＢ  イベント配信定義保持モジュール，  ８７ＡおよびＢ  イベント配信モジュール，  ８８  各種データ
【図１】
2007072827.tif 000003
【図２】
2007072827.tif 000004
【図３】
2007072827.tif 000005
【図４】
2007072827.tif 000006
【図５】
2007072827.tif 000007
【図６】
2007072827.tif 000008