(57)【要約】【課題】プラグインモジュールからの情報を受けてテストケースを構築するために未知なる機能が発生したとしても、容易にテストの実施が可能となるテストケース動的構築装置を提供することを課題とする。【解決手段】本発明は、機器の状態に合わせて実行するテストケースを動的に再構成する、ソフトウェアのテストアプリケーションと、ＡＰＩモジュールと、ソフトウェアとを少なくとも備えて構成される。ソフトウェアをプラグインする事で、機器の構成が変わる。【選択図】        図１
2009223700.tif 000002
【特許請求の範囲】
【請求項１】
機器の状態に合わせて実行するテストケースを動的に再構成する、ソフトウェアのテストアプリケーションを搭載したことを特徴とする、テストケース動的構築装置。
【請求項２】
請求項１に記載のテストケース動的構築装置において、
上記ソフトウェアをプラグインする事で、上記機器の構成が変わることを特徴とする、テストケース動的構築装置。
【請求項３】
請求項１または２に記載のテストケース動的構築装置において、
上記テストアプリケーションは、テストケース収集部とテスト実行部とＧＵＩ表示部からなり、上記ＧＵＩ表示部は、ＭＦＰ用パネルに表示するためのＧＵＩを作成するＭＦＰ用ＧＵＩ表示部と、ＰＣに表示するためのＧＵＩを作成するＰＣ用ＧＵＩ表示部の少なくとも一つを保有することを特徴とする、テストケース動的構築装置。
【請求項４】
請求項３に記載のテストケース動的構築装置において、
上記テストアプリケーションは、テスト実行環境に応じて、上記ＧＵＩ表示部に、上記ＭＦＰ用ＧＵＩ表示部と、上記ＰＣ用ＧＵＩ表示部とを使い分けさせることを特徴とする、テストケース動的構築装置。
【請求項５】
請求項２〜４のいずれか一つに記載のテストケース動的構築装置において、
上記プラグインする上記ソフトウェアには、実行すべき上記テストケースが含まれており、プラグイン時に上記テストアプリケーションに上記テストケースを登録する事で、テストを実行することを特徴とする、テストケース動的構築装置。
【請求項６】
請求項２〜５のいずれか一つに記載のテストケース動的構築装置において、
上記プラグインした上記ソフトウェアから、提供するＩ／Ｆ情報を取得し、当該提供する上記Ｉ／Ｆ情報に応じて実行する上記テストケースを再構成することを特徴とする、テストケース動的構築装置。
【請求項７】
請求項２〜６のいずれか一つに記載のテストケース動的構築装置において、
上記ソフトウェアに含まれる各プラグインモジュールは、ＡＰＩモジュールを経由して上記Ｉ／Ｆ情報を提供することを特徴とする、テストケース動的構築装置。
【請求項８】
請求項７に記載のテストケース動的構築装置において、
上記各プラグインモジュールは、上記ＡＰＩモジュールを経由して上記Ｉ／Ｆ情報を提供し、当該ＡＰＩモジュールが上記テストケースを登録することを特徴とする、テストケース動的構築装置。
【請求項９】
請求項１〜８のいずれか一つに記載のテストケース動的構築装置において、
上記テストケースは、Ｉ／Ｆテストと、機能テストの２種類をサポートすることを特徴とする、テストケース動的構築装置。
【請求項１０】
請求項９に記載のテストケース動的構築装置において、
上記２種類の上記テストケースのうち、上記Ｉ／Ｆテスト用の上記テストケースは、上記プラグインした上記ソフトウェアから取得し、上記機能テスト用の上記テストケースは、上記テストアプリケーション内であらかじめ用意しておいたものを使うことを特徴とする、テストケース動的構築装置。
【請求項１１】
請求項１０に記載のテストケース動的構築装置において、
上記機能テスト用の上記テストケースは、上記テストアプリケーション内であらかじめ用意しておいたもののうち、上記プラグインする上記ソフトウェアから機能を実現するために必要なＡＰＩが全て提供されている場合に、テスト対象とすることを特徴とする、テストケース動的構築装置。
【請求項１２】
請求項２〜１１のいずれか一つに記載のテストケース動的構築装置において、
上記プラグインする上記ソフトウェアが有効になっている時のみ、上記テストを実行することを特徴とする、テストケース動的構築装置。
【請求項１３】
請求項１〜１２のいずれか一つに記載のテストケース動的構築装置において、
上記テストアプリケーションは、動作タイミングを切り替えられることを特徴とする、テストケース動的構築装置。
【請求項１４】
請求項１３に記載のテストケース動的構築装置において、
上記切り替えられる上記動作タイミングは、コピーやＦＡＸなどの標準的なアプリケーションが動作中に、上記テストを実行するかどうかを切り替えられることを特徴とする、テストケース動的構築装置。
【請求項１５】
請求項１４に記載のテストケース動的構築装置において、
上記標準的な上記アプリケーションがジョブを実行開始した通知をもって、上記テストを自動的に開始することを特徴とする、テストケース動的構築装置。
【請求項１６】
請求項１３〜１５のいずれか一つに記載のテストケース動的構築装置において、
上記ＧＵＩ表示部から指示されたタイミングで上記テストを実行することを特徴とする、テストケース動的構築装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、テストケース動的構築装置に関し、特に、ソフトウェア構成に応じて動的にテストを実行するテストアプリケーションを提供するテストケース動的構築装置に関する。
【背景技術】
【０００２】
従来から、ソフトウェアの分野では、ソフトウェアの検証やデバック作業を効率的に行うために、様々なソフトウェアのテスト方法が報告されている。
【０００３】
例えば、特許文献１の技術は、組み込みシステムのハードウェア構成を模擬するシミュレータを用いて、ソフトウェアの検証を行うものである。
【０００４】
また、例えば、特許文献２の技術は、情報格納サーバと情報処理装置との接続情報に基づいて、接続テスト行い両者の接続状況を検証するものである。
【０００５】
【特許文献１】特開２００１−３１８８０５号公報
【特許文献２】特開２００４−２８８１７１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、これらの従来技術（特許文献１および特許文献２）のように、あらかじめ決められたシステム構成に対してテストを実施する方法は数多く存在するが、これから発生する未知なるソフトウェアのテストに対応することが困難であるという問題がある。
【０００７】
例えば、機器構成が動的に変化するプラガブルな機器では、従来技術をそのまま使うとテストアプリケーションを組み合わせの数だけ開発する必要があるため、品質保証が困難で膨大な開発コストが必要となるという問題点があった。
【０００８】
本発明は、上記に鑑みてなされたもので、プラグインモジュールからの情報を受けてテストケースを構築するために未知なる機能が発生したとしても、容易にテストの実施が可能となるテストケース動的構築装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上述した課題を解決し、目的を達成するために、本発明のテストケース動的構築装置は、機器の状態に合わせて実行するテストケースを動的に再構成する、ソフトウェアのテストアプリケーションを搭載したことを特徴とする。
【００１０】
また、本発明のテストケース動的構築装置は、上記記載のテストケース動的構築装置において、上記ソフトウェアをプラグインする事で、上記機器の構成が変わることを特徴とする。
【００１１】
また、本発明のテストケース動的構築装置は、上記記載のテストケース動的構築装置において、上記テストアプリケーションは、テストケース収集部とテスト実行部とＧＵＩ表示部からなり、上記ＧＵＩ表示部は、ＭＦＰ用パネルに表示するためのＧＵＩを作成するＭＦＰ用ＧＵＩ表示部と、ＰＣに表示するためのＧＵＩを作成するＰＣ用ＧＵＩ表示部の少なくとも一つを保有することを特徴とする。
【００１２】
また、本発明のテストケース動的構築装置は、上記記載のテストケース動的構築装置において、上記テストアプリケーションは、テスト実行環境に応じて、上記ＧＵＩ表示部に、上記ＭＦＰ用ＧＵＩ表示部と、上記ＰＣ用ＧＵＩ表示部とを使い分けさせることを特徴とする。
【００１３】
また、本発明のテストケース動的構築装置は、上記記載のテストケース動的構築装置において、上記プラグインする上記ソフトウェアには、実行すべき上記テストケースが含まれており、上記プラグイン時に上記テストアプリケーションに上記テストケースを登録する事で、テストを実行することを特徴とする。
【００１４】
また、本発明のテストケース動的構築装置は、上記記載のテストケース動的構築装置において、上記プラグインした上記ソフトウェアから、提供するＩ／Ｆ情報を取得し、当該提供する上記Ｉ／Ｆ情報に応じて実行する上記テストケースを再構成することを特徴とする。
【００１５】
また、本発明のテストケース動的構築装置は、上記記載のテストケース動的構築装置において、上記ソフトウェアに含まれる各プラグインモジュールは、ＡＰＩモジュールを経由して上記Ｉ／Ｆ情報を提供することを特徴とする。
【００１６】
また、本発明のテストケース動的構築装置は、上記記載のテストケース動的構築装置において、上記各プラグインモジュールは、上記ＡＰＩモジュールを経由して上記Ｉ／Ｆ情報を提供し、当該ＡＰＩモジュールが上記テストケースを登録することを特徴とする。
【００１７】
また、本発明のテストケース動的構築装置は、上記記載のテストケース動的構築装置において、上記テストケースは、Ｉ／Ｆテストと、機能テストの２種類をサポートすることを特徴とする。
【００１８】
また、本発明のテストケース動的構築装置は、上記記載のテストケース動的構築装置において、上記２種類の上記テストケースのうち、上記Ｉ／Ｆテスト用の上記テストケースは、上記プラグインした上記ソフトウェアから取得し、上記機能テスト用の上記テストケースは、上記テストアプリケーション内であらかじめ用意しておいたものを使うことを特徴とする。
【００１９】
また、本発明のテストケース動的構築装置は、上記記載のテストケース動的構築装置において、上記機能テスト用の上記テストケースは、上記テストアプリケーション内であらかじめ用意しておいたもののうち、上記プラグインする上記ソフトウェアから機能を実現するために必要なＡＰＩが全て提供されている場合に、テスト対象とすることを特徴とする。
【００２０】
また、本発明のテストケース動的構築装置は、上記記載のテストケース動的構築装置において、上記プラグインする上記ソフトウェアが有効になっている時のみ、上記テストを実行することを特徴とする。
【００２１】
また、本発明のテストケース動的構築装置は、上記記載のテストケース動的構築装置において、上記テストアプリケーションは、動作タイミングを切り替えられることを特徴とする。
【００２２】
また、本発明のテストケース動的構築装置は、上記記載のテストケース動的構築装置において、上記切り替えられる上記動作タイミングは、コピーやＦＡＸなどの標準的なアプリケーションが動作中に、上記テストを実行するかどうかを切り替えられることを特徴とする。
【００２３】
また、本発明のテストケース動的構築装置は、上記記載のテストケース動的構築装置において、上記標準的な上記アプリケーションがジョブを実行開始した通知をもって、上記テストを自動的に開始することを特徴とする。
【００２４】
また、本発明のテストケース動的構築装置は、上記記載のテストケース動的構築装置において、上記ＧＵＩ表示部から指示されたタイミングで上記テストを実行することを特徴とする。
【発明の効果】
【００２５】
本発明によれば、機器の状態に合わせて実行するテストケースを動的に再構成する、ソフトウェアのテストアプリケーションを搭載するので、これから発生する未知なるソフトウエアのテストに対応することが容易であり、また、品質保証が容易で、開発コストを抑えることをできるという効果を奏する。
【発明を実施するための最良の形態】
【００２６】
以下に添付図面を参照して、この発明にかかるテストケース動的構築装置の最良な実施の形態を詳細に説明する。
【００２７】
［本発明の概要］
以下、本発明の概要について説明し、その後、本発明の構成および処理等について詳細に説明する。
【００２８】
（発明１）
本発明は、概略的に、以下の基本的特徴を有する。すなわち、本発明は、機器の状態に合わせて実行するテストケースを動的に再構成する、ソフトウェアのテストアプリケーションを搭載する。
【００２９】
すなわち、後述する図３に示すように、印刷モジュール２０１やコピーモジュール２０２などのプラグインモジュール（機器に動的に追加する事で、機器が保有する機能を追加するためのプログラム）からの情報を受けて、実行対象となるテストケースを作る点が従来にはない新しい点である。なお、従来型のテストアプリケーションは、あらかじめ保有しているテストケースを、機器の構成とは無関係に実行するものであった。また、機器のソフトウェア構成が動的に変わるシステムでは、機器毎に搭載している機能が異なる。そのため、従来型のテストアプリケーションを搭載すると、機器に機能が搭載していないためにテスト実行結果がエラーとなってしまう事があり、正常にテストを実施するのが難しかった。また、機器があらかじめ想定しているテストケースしか実施できないため、後から追加された新規機能に対するテストを実施することができないという問題点があった。本発明では、テストケースを動的に構築する事で、不要なテスト実施を抑制する事で正常なテスト実施が可能となり、さらに未知の機能が追加された場合でもテストを可能とする点で、品質向上に大きな効果が期待できる。
【００３０】
（発明２）
ここで、本発明において、ソフトウェアをプラグインする事で、機器の構成が変わってもよい。
【００３１】
すなわち、後述する図１に記載しているプログラム（図１の本体コントローラ（単機能部）および本体コントローラ（複合機能部）内のプログラム）は、全て機器に動的に追加されるプラグインモジュールである。また、図１に示すように、プラグインモジュールの中にテストケースを保有しておき、後述する図４に示すようにプラグインモジュール自身がテストケースを登録する事で、未知なる機能に対するテストが可能となる。
【００３２】
（発明３）
ここで、本発明において、テストアプリケーションは、テストケース収集部とテスト実行部とＧＵＩ表示部からなり、ＧＵＩ表示部は、ＭＦＰ用パネルに表示するためのＧＵＩを作成するＭＦＰ用ＧＵＩ表示部と、ＰＣに表示するためのＧＵＩを作成するＰＣ用ＧＵＩ表示部の少なくとも一つを保有してもよい（後述する図２等を参照）。
【００３３】
すなわち、テストアプリケーションはＭＦＰ（機器内）に搭載して動作しても良いし、ＰＣ上で動作しても良い。ＰＣとＭＦＰとではＧＵＩの表示処理だけが異なり、テストケース収集部とテスト実行部は共通利用できる構成を採用する。この構成をとるために、図１に示すように、テストアプリケーションはＭＦＰ用のＧＵＩ表示処理とＰＣ用のＧＵＩ表示処理を保有する。テストアプリケーションにあらかじめ両方のＧＵＩ表示機能を持たせておき、機器構成に応じて動的に利用するＧＵＩ表示処理部を切り替えても良い（後述する図６を参照）。この構成をとっておけば、テストアプリケーションは自身が動作する環境に合わせて適切なＧＵＩ表示を行う事ができる。テストアプリケーションのプログラムサイズを縮小してメモリ消費コストを下げる必要がある場合などでは、ＰＣ専用のテストアプリケーション、ＭＦＰ専用のテストアプリケーションなど、どちらか一方のＧＵＩ表示機能のみを備えたテストアプリケーションを作る事も当然可能である（後述する図７を参照）。ＭＦＰ上で動作させた場合は、実行速度やメモリ消費量などのパフォーマンス測定が、実機同等レベルで実現可能となるため精度の高いテストが可能となる。ＰＣ上で動作させた場合は、ＪＵｎｉｔなどのＰＣ開発環境に用意されている様々なテストツールと連携する（連携するようなＧＵＩ表示や結果出力を行う）事で、世の中に多数存在する様々な有益なアプリケーションと連携することができる。両方の機能を持たせておけば、両者の利点を活かしながら高度で正確なテストを実施することができ、テスト効率の大幅な向上が期待できる。
【００３４】
（発明４）
ここで、本発明において、テストアプリケーションは、テスト実行環境に応じて、ＧＵＩ表示部に、ＭＦＰ用ＧＵＩ表示部と、ＰＣ用ＧＵＩ表示部とを使い分けさせてもよい。
【００３５】
また、ＧＵＩ表示部を持たずに、ＰＣ上で動作するテストアプリケーションに対して、実行結果のみを渡すことも可能である。なお、発明４は、発明３と同様の効果を有する。
【００３６】
（発明５）
ここで、本発明において、プラグインするソフトウェアには、実行すべきテストケースが含まれており、プラグイン時にテストアプリケーションにテストケースを登録する事で、テストを実行してもよい（後述する図１３を参照）。図１３は、本実施の形態におけるテストケースの一例の概念図である。図１３において、プラグインモジュールが保有するテストケースが、実行するテストケースとして登録されている。
【００３７】
すなわち、発明１の一実施形態であり、図３に示すように、テストケースそのものを登録してもらう。テストアプリケーションがテストケースを保有しないため、ＲＯＭ消費量が軽減でき、その時々のソフトウェア構成に応じて最適なテストを実施することができる。
【００３８】
（発明６）
ここで、本発明において、プラグインしたソフトウェアから、提供するＩ／Ｆ情報を取得し、当該提供するＩ／Ｆ情報に応じて実行するテストケースを再構成してもよい（図１４を参照）。図１４は、本実施の形態におけるテストケースの一例の概念図である。図１４において、プラグインモジュールが保有するテストケースはないが、ＩＦを指定、すなわち、テストケースを指定することにより、テストアプリケーションが保有するテストケースからテストケースを決定し、実行するテストケースとしている。
【００３９】
すなわち、発明１の一実施形態であり、後述する図８に示すように、テストケースそのものはテストアプリケーション内にあらかじめ容易しておき、Ｉ／Ｆ情報のみを登録してもらう事で、利用可能なテストケースを特定する方法である。未知機能に対するテスト実施は実現できないが、実行不可能なテストを実施したためにエラーが発生するケースは、この構成でも抑制できる。
【００４０】
（発明７）
ここで、本発明において、ソフトウェアに含まれる各プラグインモジュールは、ＡＰＩモジュールを経由してＩ／Ｆ情報を提供してもよい。
【００４１】
すなわち、発明１の一実施形態であり、ソフトウェアの中には、図４に示すように、プラグインモジュールとは別にＡＰＩモジュールを用意しておき、各プラグインモジュールが提供するＩ／ＦをＡＰＩとして直接利用するのではなく、ＡＰＩモジュールを通してＡＰＩが提供される構成が考えられる。その場合には、各モジュールからは、自身が提供しているテストケースをテストアプリケーションに登録し、ＡＰＩモジュールを通して自身が利用されるようにする事で、この構成にも対応できる。なお、発明７は、発明５および発明６と同様の効果を有する。
【００４２】
（発明８）
ここで、本発明において、各プラグインモジュールは、ＡＰＩモジュールを経由してＩ／Ｆ情報を提供し、当該ＡＰＩモジュールがテストケースを登録してもよい。
【００４３】
すなわち、本発明の一実施形態であり、後述する図５に示すように、各モジュールからは、自身が提供しているＩ／Ｆを利用するＡＰＩの情報をＡＰＩモジュールに登録し、ＡＰＩモジュールがテストケースを登録する構成にも対応できる。この場合、ＡＰＩモジュールがテストケースを保有する。図５に示していないが、各モジュールがＡＰＩモジュールに対してテストケースを登録する構成でも可能である。なお、発明８は、発明５および発明６と同様の効果を有する。
【００４４】
（発明９）
ここで、本発明において、テストケースは、Ｉ／Ｆテストと、機能テストの２種類をサポートしてもよい。
【００４５】
すなわち、後述する図９に示すように、テストアプリケーションはＩ／Ｆテスト（個々のＡＰＩを単発的にテストする）と、機能テスト（複数のＡＰＩを連動して実行することで「機能」を実現する）の、２種類をサポートする。Ｉ／Ｆテストは、プラグインモジュールの単独動作の品質保証を確認するために有効で、機能テストは複数のプラグインモジュールの連携動作をともなう品質保証に有効なテストである。目的の異なる２種類のテスト方法を備える事で、品質保証レベルを高める事ができる。
【００４６】
（発明１０）
ここで、本発明において、２種類のテストケースのうち、Ｉ／Ｆテスト用のテストケースは、プラグインしたソフトウェアから取得し、機能テスト用のテストケースは、テストアプリケーション内であらかじめ用意しておいたものを使ってもよい。
【００４７】
すなわち、プラグインモジュールは単独機能のみを提供するので、自身が保有するテストケースは自分に関するテストケースのみである。（他のプラグインモジュールとの連携動作は考慮されていない）。しかし、ＭＦＰにおいては複数のプラグインモジュールの処理を連携させた機能（例えば、読み取り処理と印刷処理を連携する事で実現するコピー機能など）が、各種アプリケーションで実現される。このような連携機能に対するテストを実現するためには、あらかじめ想定される連携用のテストケース（機能テストケース）をプラグインモジュールから取得するのではなく、テストアプリケーション内に保有しておく必要がある。Ｉ／Ｆテストケースをプラグインモジュールから取得する事でＲＯＭリソース消費量を軽減し、なおかつ機能テストを実施するためのテストケースをテストアプリケーション内にあらかじめ準備しておく事で、品質保証効果の高いテストが実施で、かつリソース消費的に効率のよいテストアプリケーションを搭載することが可能となる（後述する図１０を参照）。
【００４８】
（発明１１）
ここで、本発明において、機能テスト用のテストケースは、テストアプリケーション内であらかじめ用意しておいたもののうち、プラグインするソフトウェアから機能を実現するために必要なＡＰＩが全て提供されている場合に、テスト対象としてもよい。
【００４９】
具体的には、後述する機能テストケースの構造を示した図１１、および、機能テストのテストケース決定テーブルを示した図１２を参照されたい。なお、発明１１は、発明１０と同様の効果を有する。
【００５０】
（発明１２）
ここで、本発明において、プラグインするソフトウェアが有効になっている時のみ、テストを実行してもよい。
【００５１】
すなわち、プラグインモジュールの中には、機器にプラグインされただけでは、動作せずに、機器上の設定値によって有効と判断されたもののみが搭載されている構成が知られている。（課金処理などにより、プラグインしただけでは有効とならず、正しくお金が支払われた事を確認して初めて動作するプラグインが知られている。）これらの構成に適応するため、有効と判断されているもののみをテスト対象とする。これにより、不必要なテストを実施する事がなくなるため、時間効率の良いテストが実施可能となる。
【００５２】
（発明１３）
ここで、本発明において、テストアプリケーションは、動作タイミングを切り替えてもよい。
【００５３】
すなわち、テストを実施するタイミングは、機器が動作を停止している状況（テストアプリケーションのみが動作している状況）だけとは限らず、むしろ様々なアプリケーションが動作しているタイミングでのテストが重要となる事が多い。特にＭＦＰは、コピー、ファクス、プリンタなど様々な機能が同時に動作する事があり、複数の機能の同時実行時にも機器が正常に動作する事を保証する事が重要である。一方、機器が動作を停止している状況（テストアプリケーションのみが動作している状況）では、ある機能の単独動作自体に異常がある事を簡単に特定できるため、また有効な手段である。通常のソフトウエア開発においては、まずは機能の単独動作のテストを行う、単独テストが確認できたところで、機能を複合させたより複雑なテストを実施する事が多い。本発明のテストアプリケーションは、開発ステージにおける異なる品質保証要望にこたえるために、テストを実施するタイミングを変える事で、より柔軟で使い勝手の良いテストアプリケーションとなる。
【００５４】
（発明１４）
ここで、本発明において、切り替えられる動作タイミングは、コピーやＦＡＸなどの標準的なアプリケーションが動作中に、テストを実行するかどうかを切り替えてもよい。
【００５５】
なお、発明１４は、発明１３と同様の効果を有する。
【００５６】
（発明１５）
ここで、本発明において、標準的なアプリケーションがジョブを実行開始した通知（一般的に機器が備えているイベント通知）をもって、テストを自動的に開始してもよい。
【００５７】
すなわち、テスト実施開始のトリガとして、一般的に発生しているジョブ開始要求を利用する事で、テストアプリケーションとＭＦＰとの親和性を高める（テストアプリケーション専用にイベントを追加しないため、テストアプリケーションを搭載することによる不具合発生リスクを軽減できる）。また、テストを自動的に実行する事ができるので、テストアプリケーションを常駐させる事が可能で、テスト実施効率が高くなる。なお、発明１５は、発明１３と同様の効果を有する。
【００５８】
（発明１６）
ここで、本発明において、ＧＵＩ表示部から指示されたタイミングでテストを実行してもよい。
【００５９】
すなわち、発明１４および発明１５が、テストアプリケーションが保有する動作タイミング設定値を利用して動作するのに対して、テスト実行者が任意のタイミングでテストを実行できるようになる。テスト方法のバリエーションが拡がり、より多角的なテストが可能となる。なお、発明１６は、発明１３と同様の効果を有する。
【００６０】
［本テストケース動的構築装置１００の構成］
次に、本テストケース動的構築装置１００の構成について、図１、図２、図１１、および、図１２を参照して説明する。ここで、図１は、本テストケース動的構築装置の構成の一例を示すブロック図である。図２は、本実施の形態における表示部の構成の一例を示すブロック図である。図１１および図１２は、本実施の形態における機能テストケースの構造の一例である。なお、この実施の形態によりこの発明が限定されるものではない。
【００６１】
図１に示すように、本テストケース動的構築装置１００は、テストアプリケーション１３０と、アプリケーション開発用Ｉ／Ｆ（ＡＰＩモジュール）１４０と、本体コントローラソフトウェア（ソフトウェア）１５０を少なくとも備えて構成される。テストアプリケーション１３０は、テストケースを収集するテストケース収集部１３１とテストを実行するテスト実行部１３２とＧＵＩを表示するＧＵＩ表示部１３３とを更に備える。テストケース収集部１３１は、Ｉ／Ｆテストケース１３１ａと機能テストケース１３１ｂとを更に備える。ＧＵＩ表示部１３３は、ＭＦＰ用ＧＵＩ表示部１３３ａとＰＣ用ＧＵＩ表示部１３３ｂとを更に備える。また、プラグインモジュール２００は、プログラム本体２１０とテストケース２２０とプラグイン識別情報２３０とＡＰＩ提供部２４０とを備えて構成される。本体コントローラソフトウェア（ソフトウェア）１５０は、本体コントローラ（単機能部）１５０ａと本体コントローラ（複合機能部）１５０ｂから構成される。これら本体コントローラ１５０ａ，１５０ｂは、複数のプラグインモジュール２００から構成される。
【００６２】
図２に示すように、ＰＣ用ディスプレイ１００−１を用いる場合は、テストケース動的構築装置１００−１は、図１のテストケース動的構築装置１００の構成と同様であるが、ＶＭ１６０−１、ＰＣ用ＯＳ１７０−１、ＰＣ用ＧＵＩ表示部１３３ｂをさらに備えて構成される。同様に、ＭＦＰ用ディスプレイ１００−２を用いる場合は、テストケース動的構築装置１００−２は、図１のテストケース動的構築装置１００の構成に加え、ＶＭ１６０−２、ＭＦＰ用ＯＳ１７０−２、ＭＦＰ用ＧＵＩ表示部１３３ａを備えて構成される。
【００６３】
図１１に示すように、機能テストケース１３１ｂの構造は、機能テスト名、必要なＩ／Ｆ名、Ｉ／Ｆ実行順仕様（テスト仕様）から構成され、各項目に対応する機能テストケースの記述例を示している。また、図１２に示すように、プラグインされたモジュールから、ＩＦ利用登録（もしくはテストケースの登録）が実施された場合には、対応する機能テストの必要なインターフェースが全て登録されたら、当該機能テストケースは実行可能とみなす。
【００６４】
本実施の形態のテストケース動的構築装置は、ＣＰＵなどの制御装置と、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）やＲＡＭなどの記憶装置と、ＨＤＤ、ＣＤドライブ装置などの外部記憶装置と、ディスプレイ装置などの表示装置と、キーボードやマウスなどの入力装置を備えており、通常のコンピュータを利用したハードウェア構成となっている。
【００６５】
本実施形態のテストケース動的構築装置で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。
【００６６】
［テストケース動的構築処理］
最後に、このように構成された本実施の形態における本テストケース動的構築装置の処理の一例について、以下に図３〜図１０を参照して説明する。図３〜図１０は、本テストケース動的構築装置の処理の一例を示すシーケンス図である。
【００６７】
まず、図３を参照して、各モジュールが直接ＡＰＩを提供する構成においてテストケースを動的に構築する処理について以下に説明する。
【００６８】
図３に示すように、印刷モジュール２０１が起動されると、印刷モジュール２０１は、テストケース収集部１３１にテストケースの登録を要求する（ステップＳＡ−１）。そして、テストケース収集部１３１は、テストケースを記憶する（ステップＳＡ−２）。そして、コピーモジュール２０２が起動されると、コピーモジュール２０２は、テストケース収集部１３１にテストケースの登録を要求する（ステップＳＡ−３）。そして、テストケース収集部１３１は、テストケースを記憶する（ステップＳＡ−４）。そして、ＧＵＩ表示部１３３は、テスト実行指示が入力されると、テスト実行部１３２に対して、テスト実行指示イベントを発生させる（ステップＳＡ−５）。そして、テスト実行部１３２は、テストケース収集部１３１に対して、テストケースの取得を要求する（ステップＳＡ−６）。そして、テストケース収集部１３１は、テストケース実行部のテストケース取得要求に応答し、テスト実行部１３２に対してテストケースを送信する（ステップＳＡ−７）。そして、テスト実行部１３２は、印刷モジュール２０１に対して、印刷モジュール２０１のＩ／Ｆの実行を要求し（ステップＳＡ−８）、印刷モジュール２０１は、実行結果をテスト実行部１３２に対して送信する（ステップＳＡ−９）。すなわち、テスト実行部１３２は、印刷モジュール２０１に関するテストを実行し、実行結果を元にテストの成功または失敗を判定する（ステップＳＡ−８〜９）。そして、テスト実行部１３２は、コピーモジュール２０２に対して、コピーモジュール２０２のＩ／Ｆの実行を要求し（ステップＳＡ−１０）、コピーモジュール２０２は、実行結果をテスト実行部１３２に対して送信する（ステップＳＡ−１１）。すなわち、テスト実行部１３２は、コピーモジュール２０２に関するテストを実行し、実行結果を元にテストの成功または失敗を判定する（ステップＳＡ−１０〜１１）。そして、テスト実行部１３２は、ＧＵＩ表示部１３３にテスト結果を表示させる（ステップＳＡ−１２）。
【００６９】
続いて、図４を参照して、各モジュールがＡＰＩモジュール１４０を経由してＩ／Ｆを提供する構成においてテストケースを動的に構築する処理について以下に説明する。
【００７０】
図４に示すように、印刷モジュール２０１が起動されると、印刷モジュール２０１は、テストケース収集部１３１にテストケースの登録を要求する（ステップＳＢ−１）。そして、テストケース収集部１３１は、テストケースを記憶する（ステップＳＢ−２）。そして、コピーモジュール２０２が起動されると、コピーモジュール２０２は、テストケース収集部１３１にテストケースの登録を要求する（ステップＳＢ−３）。そして、テストケース収集部１３１は、テストケースを記憶する（ステップＳＢ−４）。そして、ＧＵＩ表示部１３３は、テスト実行指示が入力されると、テスト実行部１３２に対して、テスト実行指示イベントを発生させる（ステップＳＢ−５）。そして、テスト実行部１３２は、テストケース収集部１３１に対して、テストケースの取得を要求する（ステップＳＢ−６）。そして、テストケース収集部１３１は、テストケース実行部のテストケース取得要求に応答し、テスト実行部１３２に対してテストケースを送信する（ステップＳＢ−７）。そして、テスト実行部１３２は、ＡＰＩモジュール１４０に対して、Ｉ／Ｆの実行を要求し（ステップＳＢ−８）、ＡＰＩモジュール１４０は、印刷モジュール２０１に対して、印刷モジュール２０１のＩ／Ｆの実行を要求する（ステップＳＢ−９）。そして、印刷モジュール２０１は、実行結果をＡＰＩモジュール１４０に対して送信し（ステップＳＢ−１０）、ＡＰＩモジュール１４０は、受信した実行結果をテスト実行部１３２に対して送信する（ステップＳＢ−１１）。すなわち、テスト実行部１３２は、印刷モジュール２０１に関するテストを実行し、実行結果を元にテストの成功または失敗を判定する（ステップＳＢ−８〜１１）。そして、テスト実行部１３２は、ＡＰＩモジュール１４０に対して、Ｉ／Ｆの実行を要求する（ステップＳＢ−１２）。そして、ＡＰＩモジュール１４０は、コピーモジュール２０２に対して、コピーモジュール２０２のＩ／Ｆの実行を要求し（ステップＳＢ−１３）、コピーモジュール２０２は、印刷モジュール２０１に対して実行を要求する（ステップＳＢ−１４）。そして、印刷モジュール２０１は、実行結果をコピーモジュール２０２に対して送信し（ステップＳＢ−１５）、コピーモジュール２０２は、受信した実行結果をＡＰＩモジュール１４０に対して送信し（ステップＳＢ−１６）、ＡＰＩモジュール１４０は、受信した実行結果をテスト実行部１３２に対して送信する（ステップＳＢ−１７）。すなわち、テスト実行部１３２は、コピーモジュール２０２に関するテストを実行し、実行結果を元にテストの成功または失敗を判定する（ステップＳＢ−１２〜１７）。ここで、ステップＳＢ−１４〜１５に示すように、Ｉ／Ｆの種類によっては、上位のモジュール（例えば、コピーモジュール２０２）が下位のモジュール（例えば、印刷モジュール２０１）を内部的に利用することがある。これにより、ＡＰＩを経由して直接実行された場合と、他のＡＰＩを通して間接的に利用される場合の両方のテストが実行され、テスト効果の向上が期待できる。そして、テスト実行部１３２は、ＧＵＩ表示部１３３にテスト結果を表示させる（ステップＳＢ−１８）。
【００７１】
続いて、図５を参照して、ＡＰＩモジュール１４０がテストケースを登録する構成においてテストケースを動的に構築する処理について以下に説明する。
【００７２】
図５に示すように、印刷モジュール２０１が起動されると、印刷モジュール２０１は、ＡＰＩモジュール１４０にＩ／Ｆ利用登録を要求する（ステップＳＣ−１）。そして、ＡＰＩモジュール１４０は、テストケース収集部１３１にテストケースの登録を要求する（ステップＳＣ−２）。そして、テストケース収集部１３１は、テストケースを記憶する（ステップＳＣ−３）。そして、コピーモジュール２０２が起動されると、コピーモジュール２０２は、ＡＰＩモジュール１４０にＩ／Ｆ利用登録を要求する（ステップＳＣ−４）。そして、ＡＰＩモジュール１４０は、テストケース収集部１３１にテストケースの登録を要求する（ステップＳＣ−５）。そして、テストケース収集部１３１は、テストケースを記憶する（ステップＳＣ−６）。そして、ＧＵＩ表示部１３３は、テスト実行指示が入力されると、テスト実行部１３２に対して、テスト実行指示イベントを発生させる（ステップＳＣ−７）。そして、テスト実行部１３２は、テストケース収集部１３１に対して、テストケースの取得を要求する（ステップＳＣ−８）。そして、テストケース収集部１３１は、テストケース実行部のテストケース取得要求に応答し、テスト実行部１３２に対してテストケースを送信する（ステップＳＣ−９）。そして、テスト実行部１３２は、ＡＰＩモジュール１４０に対して、Ｉ／Ｆの実行を要求し（ステップＳＣ−１０）、ＡＰＩモジュール１４０は、印刷モジュール２０１に対して、印刷モジュール２０１のＩ／Ｆの実行を要求する（ステップＳＣ−１１）。そして、印刷モジュール２０１は、実行結果をＡＰＩモジュール１４０に対して送信し（ステップＳＣ−１２）、ＡＰＩモジュール１４０は、受信した実行結果をテスト実行部１３２に対して送信する（ステップＳＣ−１３）。すなわち、テスト実行部１３２は、印刷モジュール２０１に関するテストを実行し、実行結果を元にテストの成功または失敗を判定する（ステップＳＣ−１０〜１３）。そして、テスト実行部１３２は、ＡＰＩモジュール１４０に対して、Ｉ／Ｆの実行を要求する（ステップＳＣ−１４）。そして、ＡＰＩモジュール１４０は、コピーモジュール２０２に対して、コピーモジュール２０２のＩ／Ｆの実行を要求し（ステップＳＣ−１５）、コピーモジュール２０２は、印刷モジュール２０１に対して実行を要求する（ステップＳＣ−１６）。そして、印刷モジュール２０１は、実行結果をコピーモジュール２０２に対して送信し（ステップＳＣ−１７）、コピーモジュール２０２は、受信した実行結果をＡＰＩモジュール１４０に対して送信し（ステップＳＣ−１８）、ＡＰＩモジュール１４０は、受信した実行結果をテスト実行部１３２に対して送信する（ステップＳＣ−１９）。すなわち、テスト実行部１３２は、コピーモジュール２０２に関するテストを実行し、実行結果を元にテストの成功または失敗を判定する（ステップＳＣ−１４〜１９）。ここで、ステップＳＣ−１６〜１７に示すように、Ｉ／Ｆの種類によっては、上位のモジュール（例えば、コピーモジュール２０２）が下位のモジュール（例えば、印刷モジュール２０１）を内部的に利用することがある。これにより、ＡＰＩを経由して直接実行された場合と、他のＡＰＩを通して間接的に利用される場合の両方のテストが実行され、テスト効果の向上が期待できる。そして、テスト実行部１３２は、ＧＵＩ表示部１３３にテスト結果を表示させる（ステップＳＣ−２０）。
【００７３】
続いて、図６を参照して、テストアプリケーションをＭＦＰに搭載する構成においてテストケースを動的に構築する処理について以下に説明する。
【００７４】
図６に示すように、印刷モジュール２０１が起動されると、印刷モジュール２０１は、ＡＰＩモジュール１４０にＩ／Ｆ利用登録を要求する（ステップＳＤ−１）。そして、ＡＰＩモジュール１４０は、テストケース収集部１３１にテストケースの登録を要求する（ステップＳＤ−２）。そして、テストケース収集部１３１は、テストケースを記憶する（ステップＳＤ−３）。そして、ＭＦＰ用ＧＵＩ表示部１３３ａは、ＰＣからのテスト実行指示が入力されると、ＧＵＩ表示部１３３に対して、テスト実行指示を送信する（ステップＳＤ−４）。そして、ＧＵＩ表示部１３３は、テスト実行指示を受信すると、テスト実行部１３２に対して、テスト実行指示イベントを発生させる（ステップＳＤ−５）。そして、テスト実行部１３２は、テストケース収集部１３１に対して、テストケースの取得を要求する（ステップＳＤ−６）。そして、テストケース収集部１３１は、テストケース実行部のテストケース取得要求に応答し、テスト実行部１３２に対してテストケースを送信する（ステップＳＤ−７）。そして、テスト実行部１３２は、ＡＰＩモジュール１４０に対して、Ｉ／Ｆの実行を要求し（ステップＳＤ−８）、ＡＰＩモジュール１４０は、印刷モジュール２０１に対して、印刷モジュール２０１のＩ／Ｆの実行を要求する（ステップＳＤ−９）。そして、印刷モジュール２０１は、実行結果をＡＰＩモジュール１４０に対して送信し（ステップＳＤ−１０）、ＡＰＩモジュール１４０は、受信した実行結果をテスト実行部１３２に対して送信する（ステップＳＣ−１１）。すなわち、テスト実行部１３２は、印刷モジュール２０１に関するテストを実行し、実行結果を元にテストの成功または失敗を判定する（ステップＳＤ−８〜１１）。そして、テスト実行部１３２は、ＧＵＩ表示部１３３にテスト結果を表示するよう要求する（ステップＳＤ−１２）。そして、ＧＵＩ表示部１３３は、テスト結果の表示方法を決定し（ステップＳＤ−１３）、ＭＦＰ用ＧＵＩ表示部１３３ａにテスト結果を表示させる（ステップＳＤ−１４）。
【００７５】
続いて、図７を参照して、テストアプリケーションをＰＣに搭載する構成においてテストケースを動的に構築する処理について以下に説明する。
【００７６】
図７に示すように、印刷モジュール２０１が起動されると、印刷モジュール２０１は、ＡＰＩモジュール１４０にＩ／Ｆ利用登録を要求する（ステップＳＥ−１）。そして、ＡＰＩモジュール１４０は、テストケース収集部１３１にテストケースの登録を要求（ステップＳＥ−２）。そして、テストケース収集部１３１は、テストケースを記憶する（ステップＳＥ−３）。そして、ＰＣ用ＧＵＩ表示部１３３ｂは、ＰＣからのテスト実行指示が入力されると、ＧＵＩ表示部１３３に対して、テスト実行指示を送信する（ステップＳＥ−４）。そして、ＧＵＩ表示部１３３は、テスト実行指示を受信すると、テスト実行部１３２に対して、テスト実行指示イベントを発生させる（ステップＳＥ−５）。そして、テスト実行部１３２は、テストケース収集部１３１に対して、テストケースの取得を要求する（ステップＳＥ−６）。そして、テストケース収集部１３１は、テストケース実行部のテストケース取得要求に応答し、テスト実行部１３２に対してテストケースを送信する（ステップＳＥ−７）。そして、テスト実行部１３２は、ＡＰＩモジュール１４０に対して、Ｉ／Ｆの実行を要求し（ステップＳＥ−８）、ＡＰＩモジュール１４０は、印刷モジュール２０１に対して、印刷モジュール２０１のＩ／Ｆの実行を要求する（ステップＳＥ−９）。そして、印刷モジュール２０１は、実行結果をＡＰＩモジュール１４０に対して送信し（ステップＳＥ−１０）、ＡＰＩモジュール１４０は、受信した実行結果をテスト実行部１３２に対して送信する（ステップＳＣ−１１）。すなわち、テスト実行部１３２は、印刷モジュール２０１に関するテストを実行し、実行結果を元にテストの成功または失敗を判定する（ステップＳＥ−８〜１１）。そして、テスト実行部１３２は、ＧＵＩ表示部１３３にテスト結果を表示するよう要求する（ステップＳＥ−１２）。そして、ＰＣ用ＧＵＩ表示部１３３ｂにテスト結果を表示するよう要求し（ステップＳＥ−１３）、ＰＣ用ＧＵＩ表示部１３３ｂは、ＰＣからのテスト実行指示に対するＰＣへの結果応答を行う（ステップＳＥ−１４）。
【００７７】
続いて、図８を参照して、テストケースそのものではなくＩ／Ｆ情報のみを取得する処理について以下に説明する。
【００７８】
図８に示すように、印刷モジュール２０１が起動されると、印刷モジュール２０１は、ＡＰＩモジュール１４０にＩ／Ｆ利用登録を要求する（ステップＳＦ−１）。そして、ＡＰＩモジュール１４０は、テストケース収集部１３１にＩ／Ｆの登録を要求（ステップＳＦ−２）。そして、テストケース収集部１３１は、テストケースを作成する（ステップＳＦ−３）。そして、コピーモジュール２０２が起動されると、コピーモジュール２０２は、ＡＰＩモジュール１４０にＩ／Ｆ利用登録を要求する（ステップＳＦ−４）。そして、ＡＰＩモジュール１４０は、テストケース収集部１３１にＩ／Ｆの登録を要求（ステップＳＦ−５）。そして、テストケース収集部１３１は、テストケースを作成する（ステップＳＦ−６）。そして、ＧＵＩ表示部１３３は、テスト実行指示が入力されると、テスト実行部１３２に対して、テスト実行指示イベントを発生させる（ステップＳＦ−７）。そして、テスト実行部１３２は、テストケース収集部１３１に対して、テストケースの取得を要求する（ステップＳＦ−８）。そして、テストケース収集部１３１は、テストケース実行部のテストケース取得要求に応答し、テスト実行部１３２に対してテストケースを送信する（ステップＳＦ−９）。そして、テスト実行部１３２は、ＡＰＩモジュール１４０に対して、Ｉ／Ｆの実行を要求し（ステップＳＦ−１０）、ＡＰＩモジュール１４０は、印刷モジュール２０１に対して、印刷モジュール２０１のＩ／Ｆの実行を要求する（ステップＳＦ−１１）。そして、印刷モジュール２０１は、実行結果をＡＰＩモジュール１４０に対して送信し（ステップＳＦ−１２）、ＡＰＩモジュール１４０は、受信した実行結果をテスト実行部１３２に対して送信する（ステップＳＦ−１３）。すなわち、テスト実行部１３２は、印刷モジュール２０１に関するテストを実行し、実行結果を元にテストの成功または失敗を判定する（ステップＳＦ−１０〜１３）。そして、テスト実行部１３２は、ＡＰＩモジュール１４０に対して、Ｉ／Ｆの実行を要求する（ステップＳＦ−１４）。そして、ＡＰＩモジュール１４０は、コピーモジュール２０２に対して、コピーモジュール２０２のＩ／Ｆの実行を要求し（ステップＳＦ−１５）、コピーモジュール２０２は、印刷モジュール２０１に対して実行を要求する（ステップＳＦ−１６）。そして、印刷モジュール２０１は、実行結果をコピーモジュール２０２に対して送信し（ステップＳＦ−１７）、コピーモジュール２０２は、受信した実行結果をＡＰＩモジュール１４０に対して送信し（ステップＳＦ−１８）、ＡＰＩモジュール１４０は、受信した実行結果をテスト実行部１３２に対して送信する（ステップＳＦ−１９）。すなわち、テスト実行部１３２は、コピーモジュール２０２に関するテストを実行し、実行結果を元にテストの成功または失敗を判定する（ステップＳＦ−１４〜１９）。ここで、ステップＳＦ−１６〜１７に示すように、Ｉ／Ｆの種類によっては、上位のモジュール（例えば、コピーモジュール２０２）が下位のモジュール（例えば、印刷モジュール２０１）を内部的に利用することがある。これにより、ＡＰＩを経由して直接実行された場合と、他のＡＰＩを通して間接的に利用される場合の両方のテストが実行され、テスト効果の向上が期待できる。そして、テスト実行部１３２は、ＧＵＩ表示部１３３にテスト結果を表示させる（ステップＳＦ−２０）。
【００７９】
続いて、図９を参照して、Ｉ／Ｆテストと機能テストの処理について以下に説明する。
【００８０】
図９に示すように、印刷モジュール２０１が起動されると、印刷モジュール２０１は、ＡＰＩモジュール１４０にＩ／Ｆ利用登録を要求する（ステップＳＧ−１）。そして、ＡＰＩモジュール１４０は、テストケース収集部１３１にＩ／Ｆの登録を要求（ステップＳＧ−２）。そして、テストケース収集部１３１は、テストケースを作成する（ステップＳＧ−３）。そして、読取モジュール２０３が起動されると、読取モジュール２０３は、ＡＰＩモジュール１４０にＩ／Ｆ利用登録を要求する（ステップＳＧ−４）。そして、ＡＰＩモジュール１４０は、テストケース収集部１３１にＩ／Ｆの登録を要求（ステップＳＧ−５）。そして、テストケース収集部１３１は、テストケースを作成する（ステップＳＧ−６）。そして、ＧＵＩ表示部１３３は、テスト実行指示が入力されると、テスト実行部１３２に対して、テスト実行指示イベントを発生させる（ステップＳＧ−７）。そして、テスト実行部１３２は、テストケース収集部１３１に対して、テストケースの取得を要求する（ステップＳＧ−８）。そして、テストケース収集部１３１は、テストケース実行部のテストケース取得要求に応答し、テスト実行部１３２に対してテストケースを送信する（ステップＳＧ−９）。そして、テスト実行部１３２は、ＡＰＩモジュール１４０に対して、読取実行を要求し（ステップＳＧ−１０）、ＡＰＩモジュール１４０は、読取モジュール２０３に対して、読取モジュール２０３のＩ／Ｆの実行を要求する（ステップＳＧ−１１）。そして、読取モジュール２０３は、実行結果をＡＰＩモジュール１４０に対して送信し（ステップＳＧ−１２）、ＡＰＩモジュール１４０は、受信した実行結果をテスト実行部１３２に対して送信する（ステップＳＧ−１３）。そして、テスト実行部１３２は、テスト結果を判定することにより、ＩＦテストを行い、Ｉ／Ｆテストの結果をＧＵＩ表示部１３３に表示させる（ステップＳＧ−１４）。そして、テスト実行部１３２は、ＡＰＩモジュール１４０に対して、印刷実行を要求し（ステップＳＧ−１５）、ＡＰＩモジュール１４０は、印刷モジュール２０１に対して、印刷モジュール２０１のＩ／Ｆの実行を要求する（ステップＳＧ−１６）。そして、印刷モジュール２０１は、実行結果をＡＰＩモジュール１４０に対して送信し（ステップＳＧ−１７）、ＡＰＩモジュール１４０は、受信した実行結果をテスト実行部１３２に対して送信する（ステップＳＧ−１８）。そして、テスト実行部１３２は、テスト結果を判定することにより、ＩＦテストを行い、Ｉ／Ｆテストの結果をＧＵＩ表示部１３３に表示させる（ステップＳＧ−１９）。ここで、Ｉ／Ｆテストとは、個々のＩＦを対象にしてテストを実施することをいう。そして、テスト実行部１３２は、ＡＰＩモジュール１４０に対して、読取実行を要求し（ステップＳＧ−２０）、ＡＰＩモジュール１４０は、読取モジュール２０３に対して、読取モジュール２０３のＩ／Ｆの実行を要求する（ステップＳＧ−２１）。そして、読取モジュール２０３は、実行結果をＡＰＩモジュール１４０に対して送信し（ステップＳＧ−２２）、ＡＰＩモジュール１４０は、受信した実行結果をテスト実行部１３２に対して送信する（ステップＳＧ−２３）。そして、テスト実行部１３２は、ＡＰＩモジュール１４０に対して、印刷実行を要求し（ステップＳＧ−２４）、ＡＰＩモジュール１４０は、印刷モジュール２０１に対して、印刷モジュール２０１のＩ／Ｆの実行を要求する（ステップＳＧ−２５）。そして、印刷モジュール２０１は、実行結果をＡＰＩモジュール１４０に対して送信し（ステップＳＧ−２６）、ＡＰＩモジュール１４０は、受信した実行結果をテスト実行部１３２に対して送信する（ステップＳＧ−２７）。そして、テスト実行部１３２は、テスト結果を判定することにより、機能テストを行い、機能テストの結果をＧＵＩ表示部１３３に表示させる（ステップＳＧ−２８）。ここで、機能テストとは、読み取った結果を利用して、例えば、印刷を実行すること（コピー機能）をテストすることをいう。
【００８１】
続いて、図１０を参照して、Ｉ／Ｆテストと機能テストのテストケースの準備処理について以下に説明する。
【００８２】
図１０に示すように、印刷モジュール２０１が起動されると、印刷モジュール２０１は、テストケース収集部１３１にテストケースの登録を要求する（ステップＳＨ−１）。そして、テストケース収集部１３１は、Ｉ／Ｆ用テストケースを記憶する（ステップＳＨ−３）。そして、読取モジュール２０３が起動されると、読取モジュール２０３は、テストケース収集部１３１にテストケースの登録を要求する（ステップＳＨ−３）。そして、テストケース収集部１３１は、Ｉ／Ｆ用テストケースを記憶する（ステップＳＨ−４）。そして、ＧＵＩ表示部１３３は、テスト実行指示が入力されると、テスト実行部１３２に対して、テスト実行指示イベントを発生させる（ステップＳＨ−５）。そして、テスト実行部１３２は、テストケース収集部１３１に対して、テストケースの取得を要求する（ステップＳＨ−６）。そして、テストケース収集部１３１は、テストケース実行部のテストケース取得要求に応答し、テスト実行部１３２に対してテストケースを送信する（ステップＳＨ−７）。そして、テスト実行部１３２は、読取モジュール２０３に対して、読取実行を要求し（ステップＳＨ−８）、読取モジュール２０３は、実行結果をテスト実行部１３２に対して送信する（ステップＳＨ−９）。そして、テスト実行部１３２は、テスト結果を判定することにより、ＩＦテストを行い、Ｉ／Ｆテストの結果をＧＵＩ表示部１３３に表示させる（ステップＳＨ−１０）。そして、テスト実行部１３２は、印刷モジュール２０１に対して、印刷実行を要求し（ステップＳＨ−１１）、印刷モジュール２０１は、実行結果をテスト実行部１３２に対して送信する（ステップＳＨ−１２）。そして、テスト実行部１３２は、テスト結果を判定することにより、ＩＦテストを行い、Ｉ／Ｆテストの結果をＧＵＩ表示部１３３に表示させる（ステップＳＨ−１３）。ここで、Ｉ／Ｆテストとは、個々のＩＦを対象にしてテストを実施することをいう。またここで、ＩＦテストは、各モジュールから通知されたテストケースを元に実行される。そして、テスト実行部１３２は、読取モジュール２０３に対して、読取実行を要求し（ステップＳＨ−１４）、読取モジュール２０３は、実行結果をテスト実行部１３２に対して送信する（ステップＳＨ−１５）。そして、テスト実行部１３２は、印刷モジュール２０１に対して、印刷実行を要求し（ステップＳＨ−１６）、印刷モジュール２０１は、実行結果をテスト実行部１３２に対して送信する（ステップＳＨ−１７）。そして、テスト実行部１３２は、テスト結果を判定することにより、機能テストを行い、機能テストの結果をＧＵＩ表示部１３３に表示させる（ステップＳＨ−１８）。ここで、機能テストとは、読み取った結果を利用して、例えば、印刷を実行すること（コピー機能）をテストすることをいう。またここで、機能テストは、テストケース収集部１３１があらかじめ用意しておいたテストケースを利用する。
【図面の簡単な説明】
【００８３】
【図１】本テストケース動的構築装置の構成の一例を示すブロック図である。
【図２】本実施の形態における表示部の構成の一例を示すブロック図である。
【図３】本テストケース動的構築装置の処理の一例を示すシーケンス図である。
【図４】本テストケース動的構築装置の処理の一例を示すシーケンス図である。
【図５】本テストケース動的構築装置の処理の一例を示すシーケンス図である。
【図６】本テストケース動的構築装置の処理の一例を示すシーケンス図である。
【図７】本テストケース動的構築装置の処理の一例を示すシーケンス図である。
【図８】本テストケース動的構築装置の処理の一例を示すシーケンス図である。
【図９】本テストケース動的構築装置の処理の一例を示すシーケンス図である。
【図１０】本テストケース動的構築装置の処理の一例を示すシーケンス図である。
【図１１】本実施の形態における機能テストケースの構造の一例を示す図である。
【図１２】本実施の形態における機能テストケースの構造の一例を示す図である。
【図１３】本実施の形態におけるテストケースの一例の概念図である。
【図１４】本実施の形態におけるテストケースの一例の概念図である。
【符号の説明】
【００８４】
１００  テストケース動的構築装置
１３０  テストアプリケーション
１３１  テストケース収集部
１３１ｂ  機能テストケース
１３２  テスト実行部
１３３  ＧＵＩ表示部
１３３ａ  ＭＦＰ用ＧＵＩ表示部
１３３ｂ  ＰＣ用ＧＵＩ表示部
１４０  ＡＰＩモジュール
２００  プラグインモジュール
２２０  テストケース
２０１  印刷モジュール２０１
２０２  コピーモジュール２０２
２０３  読取モジュール２０３
【図１】
2009223700.tif 000003
【図２】
2009223700.tif 000004
【図３】
2009223700.tif 000005
【図４】
2009223700.tif 000006
【図５】
2009223700.tif 000007
【図６】
2009223700.tif 000008
【図７】
2009223700.tif 000009
【図８】
2009223700.tif 000010
【図９】
2009223700.tif 000011
【図１０】
2009223700.tif 000012
【図１１】
2009223700.tif 000013
【図１２】
2009223700.tif 000014
【図１３】
2009223700.tif 000015
【図１４】
2009223700.tif 000016