JP2015079484A - 情報処理装置、情報処理システム、情報処理方法、及び情報処理プログラム - Google Patents

Abstract

【課題】模倣する対象の機器における各種の状態を容易に再現可能とすること。
【解決手段】情報処理装置は、第一の定義情報に定義された操作手順に応じて、機器が実行する処理を模倣する模倣部と、前記処理の模倣に応じて発生する事象を監視して、第二の定義情報において指定された時期の到来を検知し、該検知に応じて前記模倣部の状態を、前記第二の定義情報において指定された状態に変更する状態変更部とを有し、前記模倣部は、前記状態変更部によって変更された状態において、前記機器に処理を実行させるプログラムからの要求に応じて、前記機器によって実行される処理を模倣する。
【選択図】図２

Description

本発明は、情報処理装置、情報処理システム、情報処理方法、及び情報処理プログラムに関する。

複合機等の画像形成装置においては、アプリケーションプラットフォームを有し、当該アプリケーションプラットフォームが提供するＡＰＩ（Application Program Interface）を利用したアプリケーションプログラム（以下、「アプリ」という。）の実装が可能とされているものがある。斯かるＡＰＩが公開されることにより、画像形成装置を製造する企業のみならず、当該企業外のサードベンダ等によっても、アプリの開発を行うことが可能となる。

開発中のアプリの動作確認等は、画像形成装置を用いて行われるのが望ましい。しかし、開発者ごとに画像形成装置を用意するのは経済的ではない。また、一台の画像形成装置を複数の開発者で利用するのは効率的ではない。そこで、画像形成装置のハードウェアや、アプリケーションプラットフォーム等の動作をエミュレート又はシミュレート等（以下、「エミュレート」で統一する。）するソフトウェア（以下「エミュレータ」という。）が利用されている。例えば、エミュレータを、各開発者のＰＣ（Personal Computer）等にインストールすることで、各開発者は、開発中のアプリの動作確認等を効率的に行うことができる。また、新機種の画像形成装置のエミュレータを用意することで、画像形成装置自体の開発と、アプリの開発とを並行して行うことも可能となる。

しかしながら、従来のエミュレータでは、エミュレート対象の画像形成装置が有する各種の状態を、ユーザの任意のタイミングで変更するのは困難であった。したがって、例えば、画像形成装置においてジャムが発生している状態、トナー切れの状態、又は用紙切れの状態等、各種の状態におけるアプリの動作を確認するのは困難であった。斯かる問題は、画像形成装置以外の機器においても同様であると考えられる。

本発明は、上記の点に鑑みてなされたものであって、模倣する対象の機器における各種の状態を容易に再現可能とすることを目的とする。

そこで上記課題を解決するため、情報処理装置は、第一の定義情報に定義された操作手順に応じて、機器が実行する処理を模倣する模倣部と、前記処理の模倣に応じて発生する事象を監視して、第二の定義情報において指定された時期の到来を検知し、該検知に応じて前記模倣部の状態を、前記第二の定義情報において指定された状態に変更する状態変更部とを有し、前記模倣部は、前記状態変更部によって変更された状態において、前記機器に処理を実行させるプログラムからの要求に応じて、前記機器によって実行される処理を模倣する。

模倣する対象の機器における各種の状態を容易に再現可能とすること。

本発明の実施の形態における情報処理装置のハードウェア構成例を示す図である。 本発明の実施の形態における情報処理装置の機能構成例を示す図である。 情報処理装置がテスト定義データに基づいて実行する処理手順の一例を説明するためのフローチャートである。 テスト定義データの一例を示す図である。 生成されるタスクの一例を示す図である。 タスク管理部が実行する処理手順の一例を説明するためのフローチャートである。 タスクが実行する処理手順の一例を説明するためのフローチャートである。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における情報処理装置のハードウェア構成例を示す図である。図１の情報処理装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、インタフェース装置１０５、表示装置１０６、及び入力装置１０７等を有する。

情報処理装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って情報処理装置１０に係る機能を実現する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１０６はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置１０７はキーボード及びマウス等で構成され、様々な操作指示を入力させるために用いられる。

なお、情報処理装置１０は、図１に示される構成を有する１以上の集合であるコンピュータシステムであってもよい。

図２は、本発明の実施の形態における情報処理装置の機能構成例を示す図である。図２において、情報処理装置１０は、模倣部１１、操作実行部１２、イベント通知部１３、タスク生成部１４、及びタスク管理部１５等を有する。これら各部は、情報処理装置１０にインストールされたプログラムがＣＰＵ１０４に実行させる処理により実現される。また、情報処理装置１０は、定義データ記憶部１６を利用する。定義データ記憶部１６は、例えば、補助記憶装置１０２、又は情報処理装置１０にネットワークを介して接続されて記憶される記憶装置等を用いて実現可能である。更に、情報処理装置１０には、１以上のアプリ２０がインストールされる。

アプリ２０は、模倣部１１がエミュレートする画像形成装置（以下、「対象機器」という。）が有するアプリケーションプラットフォームにおいて動作可能なアプリケーションプログラムである。すなわち、模倣部１１は、対象機器におけるアプリケーションプラットフォームと同様のＡＰＩ（Application Program Interface）をアプリ２０に提供する。模倣部１１は、アプリ２０による当該ＡＰＩの呼び出しに応じ、当該アプリケーションプラットフォームが実行する処理や、対象機器のハードウェア等の動作をエミュレート（模倣）する。したがって、模倣部１１は、アプリ２０に対して、対象機器と同様の動作環境を提供することができる。なお、当該ＡＰＩは、関数又はメソッドであってもよいし、ＲＥＳＴ（Representational State Transfer）やＳＯＡＰ（Simple Object Access Protocol）等、通信を介したインタフェースであってもよい。なお、本実施の形態において、エミュレート又は模倣には、シミュレートの意味も包含される。

操作実行部１２は、定義データ記憶部１６に記憶されているテスト定義データに含まれているテストシナリオを解釈し、当該テストシナリオにおいて指定された操作手順で、模倣部１１に対して操作指示を入力する。当該操作指示は、ユーザによる対象機器の操作を擬似的又は仮想的に実現するものである。したがって、模倣部１１は、テストシナリオに指定された操作手順に応じて対象機器が実行する処理を、擬似的又は仮想的に実行することになる。なお、テストシナリオとは、ユーザによる対象機器の操作手順を示す定義をいう。

イベント通知部１３は、模倣部１１による、対象機器が実行する処理の模倣の過程において発生するイベントを、タスク管理部１５に通知する。イベントとは、模倣部１１が対象機器の動作を模倣する過程において発生する事象に関する情報、又は当該事象の発生を示す情報である。

タスク生成部１４は、定義データ記憶部１６に記憶されているテスト定義データに含まれている状態変更条件に基づいて、１以上のタスクを生成する。状態変更条件とは、模倣部１１の状態の変更に関する条件をいう。一つの状態変更条件は、状態を変更する時期（タイミング）を指定する情報と、当該変更後の状態を指定する情報とを組とする情報である。タスク生成部１４は、状態変更条件に基づいてタスクを生成する。タスクは、状態変更条件に従って、模倣部１１の状態の変更を行う。模倣部１１の状態の変更とは、擬似的又は仮想的な対象機器の状態の変更に相当する。タスクの実体は、スレッド又はプロセスであってもよいし、オブクト指向プログラミングにおけるオブジェクトであってもよい。

タスク管理部１５は、生成されたタスクの管理や、タスクに対するイベントの配信（通知）等を行う。各タスクは、タスク管理部１５から通知されるイベントに基づいて、当該タスクに対応する状態変更条件に指定された変更する時期（以下、「変更時期」という。）の到来を検知する。

以下、情報処理装置１０が実行する処理手順について説明する。図３は、情報処理装置がテスト定義データに基づいて実行する処理手順の一例を説明するためのフローチャートである。

例えば、ユーザによって、テストの開始指示が入力されると、タスク生成部１４は、定義データ記憶部１６に記憶されている１以上のテスト定義データのうち、テストの開始指示において指定された識別名に対応するテスト定義データから、状態変更条件に関する定義を読み込む（Ｓ１０１）。当該識別名は、例えば、テスト定義データを格納するファイル名であってもよい。

図４は、テスト定義データの一例を示す図である。図４に示されるテスト定義データ５００は、次のようなユースケースにおけるテストを可能とするものである。

３００ページの文書の印刷を実行する過程において、９９枚目の印刷時にジャムが発生する。ユーザがジャム状態を解除すると、印刷が再開され、１９８枚目の印刷時に、トナー切れが発生する。メモリ消費量が、２０Ｍｂｙｔｅを超えるページの解析時にメモリフルが発生する。

図４において、テスト定義データ５００は、ＸＭＬ（eXtensible Markup Language）形式で記述されている。そこで、テスト定義データ５００の内容については、ＸＭＬに関する用語を用いて説明する。なお、ＸＭＬ以外の形式によって、テスト定義データ５００が定義されてもよい。

テスト定義データ５００は、＜ｃｏｎｄｉｔｉｏｎ＞タグで囲まれたｃｏｎｄｉｔｉｏｎ要素５１０と、＜ｓｃｅｎａｒｉｏ＞タグで囲まれたｓｃｅｎａｒｉｏ要素５２０とを含む。ｃｏｎｄｉｔｉｏｎ要素５１０は、状態変更条件に関する定義に相当し、ｓｃｅｎａｒｉｏ要素５２０は、テストシナリオに関する定義に相当する。したがって、ステップＳ１０１では、ｃｏｎｄｉｔｉｏｎ要素５１０が読み込まれる。

図４において、ｃｏｎｄｉｔｉｏｎ要素５１０は、ｊａｍ要素５１１、ｔｏｎｅｒｅｎｄ要素５１２、及びｍｅｍｏｒｙｆｕｌｌ要素５１３を子要素として含む。ｊａｍ要素５１１、ｔｏｎｅｒｅｎｄ要素５１２、及びｍｅｍｏｒｙｆｕｌｌ要素５１３は、それぞれ一つの状態変更条件に相当する。

ｊａｍ要素５１１は、模倣部１１においてジャムを発生させる時期（模倣部１１をジャム状態に移行させる時期）を規定する定義である。ｊａｍ要素５１１は、ａｎｄ要素を子要素として含む。ａｎｄ要素は、当該ａｎｄ要素に含まれる複数の子要素が示す条件に関する論理演算を意味する。すなわち、ａｎｄ要素は、当該複数の子要素の全ての条件が満たされることが必要であることを示す。なお、図示されていないが、ｏｒ要素は、当該ｏｒ要素に含まれる複数の子要素のいずれかが示す条件が満たされれば十分であることを示す。その他の論理演算に対応する要素が、ａｎｄ要素の代わりに用いられてもよい。

ａｎｄ要素は、ｃｏｕｎｔ要素及びｔｉｍｉｎｇ要素を子要素として含む。ｃｏｕｎｔ要素の値は、印刷対象のページ番号を示す。したがって、図４の例において、当該ｃｏｕｎｔ要素は、９９枚目の印刷時を示す。ｔｉｍｉｎｇ要素の値は、印刷処理の過程における、特定のタイミング、又は印刷処理の過程において遷移する模倣部１１の状態を示す。

本実施の形態において、印刷処理に関するｔｉｍｉｎｇ要素には、例えば、「ｉｎｉｔｉａｌｉｚｉｎｇ」、「ｒｅａｄｙ」、「ｒｅｃｅｉｖｉｎｇ」、「ｐａｒｓｉｎｇ」、「ｌｏａｄｉｎｇ」、「ｐｒｉｎｔｉｎｇ」等の値が指定可能である。

「ｉｎｉｔｉａｌｉｚｉｎｇ」は、印刷処理を対象機器に実行させるプログラムの初期化処理の状態を示す。「ｒｅａｄｙ」は、印刷データの受け付けが可能な待機状態を示す。「ｒｅｃｅｉｖｉｎｇ」は、印刷データの受信を開始してから終了するまでの状態を示す。「ｐａｒｓｉｎｇ」は、印刷データの１ページ分の解析中の状態を示す。「ｌｏａｄｉｎｇ」は、１枚分の印刷用紙の給紙中の状態を示す。「ｐｒｉｎｔｉｎｇ」は、１ページ分の印刷データを印刷用紙に転写し、印刷用紙の排出を開始する状態を示す。

上記より、ｊａｍ要素５１１は、９９枚目の給紙時に模倣部１１をジャム状態に移行させるという条件を示す。

また、ｔｏｎｅｒｅｎｄ要素５１２は、模倣部１１においてトナー切れを発生させる時期（模倣部１１をトナー切れ状態に移行させる時期）を規定する定義である。ｔｏｎｅｒｅｎｄ要素５１２の子要素であるａｎｄ要素は、ｃｏｕｎｔ要素とｔｉｍｉｎｇ要素を子要素として含む。ｃｏｕｎｔ要素及びｔｉｍｉｎｇ要素の意味は上記した通りである。但し、ｔｏｎｅｒｅｎｄ要素５１２内のｔｉｍｉｎｇ要素の値は、「ｐｒｉｎｔｉｎｇ」である。

上記より、ｔｏｎｅｒｅｎｄ要素５１２は、１９８枚目の転写時に模倣部１１をトナー切れ状態に移行させるという条件を示す。

更に、ｍｅｍｏｒｙｆｕｌｌ要素５１３は、模倣部１１において、メモリの消費量が上限に達した状態（メモリフルの状態）を発生させる時期を規定する定義である。ｍｅｍｏｒｙｆｕｌｌ要素５１３要素の子要素であるａｎｄ要素は、ｌｉｍｉｔ要素とｔｉｍｉｎｇ要素を子要素として含む。ｌｉｍｉｔ要素の値は、メモリの消費量に対する上限値を示す。「２０ｍ」は、２０Ｍｂｙｔｅを示す。すなわち、メモリの消費量が２０Ｍｂｙｔｅに達すると、メモリフルとなることが示されている。ｔｉｍｉｎｇ要素については上述した通りである。

上記より、ｍｅｍｏｒｙｆｕｌｌ要素５１３は、或るページの印刷データの解析中に、メモリの消費量が２０Ｍｂｙｔｅに達したら（すなわち、２０Ｍｂｙｔｅを超えるページが読み込まれたら）、模倣部１１をメモリフル状態に移行させるという条件を示す。本実施の形態では、印刷処理に関するプログラムの起動に５Ｍｂｙｔｅを消費する。また、印刷データの各ページの処理には５Ｍｂｙｐｔｅ〜１０Ｍｂｙｔｅのメモリが消費されるが、２２０ページに限って１７Ｍｂｙｔｅのメモリが消費されるように設定されていることとする。すなわち、２２０ページ目において、プログラムの起動分のメモリの消費量と当該ページにおけるメモリの消費量との合計が上限値である２０Ｍｂｙｔｅを超え、メモリフルが発生する。

なお、用紙切れや、何らかの部品の故障等、対象機器で実際に発生しうる各種の状態が、ｔｉｍｉｎｇ要素の値として指定可能とされてもよい。また、実行する処理の種類によって、ｔｉｍｅｉｎｇ要素に指定可能な値が異なってもよい。例えば、スキャン処理に関しては、「ｉｎｉｔｉａｌｉｚｉｎｇ」、「ｒｅａｄｙ」、「ｌｏａｄｉｎｇ」、「ｐｒｏｃｅｓｓｉｎｇ」、及び「ｗａｉｔｉｎｇ」等の値が、ｔｉｍｉｎｇ要素に指定可能とされてもよい。ここで、「ｉｎｉｔｉａｌｉｚｉｎｇ」は、スキャン処理を対象機器に実行させるプログラムの初期化処理の状態を示す。「ｒｅａｄｙ」は、スキャンデータの受け付けが可能な待機状態を示す。「ｌｏａｄｉｎｇ」は、スキャンされる用紙を給紙中の状態を示す。「ｐｒｏｃｅｓｓｉｎｇ」は、スキャン中を示す。「ｗａｉｔｉｎｇ」は、或るページのスキャンが完了してから次のページに関してｒｅａｄｙ状態になるまでの待機状態を示す。

続いて、タスク生成部１４は、読み込まれた状態変更条件に関する定義（ｃｏｎｄｉｔｉｏｎ要素５１０）に基づいて、タスクを生成する（Ｓ１０２）。本実施の形態において、ｃｏｎｄｉｔｉｏｎ要素５１０に基づいて生成されるタスクは、図５に示される通りである。

図５は、生成されるタスクの一例を示す図である。図５には、ジャム発生タスクｔ１、ジャム復帰タスクｔ１１、トナー切れ発生タスクｔ２、トナー切れ復帰タスクｔ２１、及びメモリフル発生タスクｔ３が示されている。

ジャム発生タスクｔ１及びジャム復帰タスクｔ１１は、ｊａｍ要素５１１に基づいて生成されるタスクである。ジャム発生タスクｔ１は、９９枚目の給紙時にジャムを発生させる（模倣部１１をジャム状態に移行させる）タスクである。ジャム復帰タスクｔ１１は、ジャムの原因の除去作業が行われた後に、模倣部１１の状態をジャムの発生していない状態に復帰させるタスクである。

トナー切れ発生タスクｔ２及びトナー切れ復帰タスクｔ２１は、ｔｏｎｅｒｅｎｄ要素５１２に基づいて生成されるタスクである。トナー切れ発生タスクｔ２は、１９８枚目の給紙時にトナー切れを発生させる（模倣部１１をトナー切れ状態に移行させる）タスクである。トナー切れ復帰タスクｔ２１は、トナーの交換作業が行われた後に、模倣部１１の状態をトナー切れの発生していない状態に復帰させるタスクである。

メモリフル発生タスクｔ３は、ｍｅｍｏｒｙｆｕｌｌ要素５１３に基づいて生成されるタスクである。メモリフル発生タスクｔ３は、メモリの消費量が２０Ｍｂｙｔｅを超えたときにメモリフルを発生させる（模倣部１１をメモリフル状態に移行させる）タスクである。

なお、ｊａｍ要素５１１とｔｏｎｅｒｅｎｄ要素５１２については、一つの状態変更条件に基づいて、或る状態へ移行させるタスクと、当該状態から復帰させるタスクとの二つのタスクが生成される。または、ｊａｍ要素５１１及びｔｏｎｅｒｅｎｄ要素５１２には、或る状態への変更と、当該状態からの復帰とに関する二つの状態変更条件が含まれていると考えられてもよい。

本実施の形態では、一つの状態変更条件に基づいて生成される、或る状態へ移行させるタスクと、当該状態から復帰させるタスクとの二つのタスクとは、親子関係を有する。親子関係とは、親の（前段の）タスクが終了した後に、子のタスクが開始されるといった、実行順における直列的な関係をいう。親のタスクが終了しなければ、子のタスクにとって前提となる状態が発生しないため、子のタスクを開始する意義が希薄であるからである。なお、親のタスクの終了は、親のタスクに設定された条件が満たされ、親のタスクによる状態の変更が行われることによって実現される。図５では、ジャム発生タスクｔ１とジャム復帰タスクｔ１１とが親子関係を有し、トナー切れ発生タスクｔ２とトナー切れ復帰タスクｔ２１とが親子関係を有する。

一方、各親のタスクは、兄弟関係を有する。兄弟関係を有するタスクは、実行順に関して並列的な関係を有する。但し、ここでいう並列的な関係とは、完全に並列に実行されることまで要求されない。ここでいう並列的な関係とは、当該関係に有る各タスクの実行の開始が、他のタスクの終了まで制限されない関係を意味する。図５では、ジャム発生タスクｔ１、トナー切れ発生タスクｔ２、及びメモリフル発生タスクｔ３が、兄弟関係を有する。

なお、生成された各タスクには、当該タスクに対応する条件と、当該条件が満たされた場合に実行すべき処理を示す情報が設定される。ジャム発生タスクｔ１に対応する条件は、９９枚目の給紙である。当該条件が満たされた場合にジャム発生タスクｔ１が実行すべき処理は、模倣部１１をジャム状態に移行させることである。ジャム復帰タスクｔ１１に対応する条件は、ジャムの原因の除去である。当該条件が満たされた場合にジャム復帰タスクｔ１１が実行すべき処理は、模倣部１１をジャム状態から復帰させることである。トナー切れ発生タスクｔ２に対応する条件は、１９９枚目の排紙である。当該条件が満たされた場合にトナー切れ発生タスクｔ２が実行すべき処理は、模倣部１１をトナー切れ状態に移行させることである。トナー切れ復帰タスクｔ２１に対応する条件は、トナーの交換である。当該条件が満たされた場合にトナー切れ復帰タスクｔ２１が実行すべき処理は、模倣部１１をトナー切れ状態から復帰させることである。なお、各タスクに設定された条件を、以下、「タスクの条件」という。また、生成されたタスクは、タスク管理部１５に渡され、タスク管理部１５によって管理される。

続いて、操作実行部１２は、テストの開始指示において指定された識別名に対応するテスト定義データに含まれている、テストシナリオに関する定義を読み込む（Ｓ１０３）。図４の例によれば、ｓｃｅｎａｒｉｏ要素５２０が読み込まれる。

図４において、ｓｃｅｎａｒｉｏ要素５２０は、５つのｓｔｅｐ要素を含む。一つのｓｔｅｐ要素は、ｓｃｅｎａｒｉｏ要素５２０が表現する、対象機器に対する操作手順のうちの一つの操作に対応する。すなわち、各ｓｔｅｐ要素の子要素は、対象機器に対する操作の種別を示す。例えば、ｐｒｉｎｔ要素は、当該要素の値が示すデータの印刷指示を示す。ｗａｉｔ要素は、当該要素の値が示す時間だけ待機することを示す。ｒｅｍｏｖｅｊａｍ要素は、ジャムの原因となっている用紙の除去操作を示す。ｃｈａｎｇｅｔｏｎｅｒ要素は、トナーの交換を示す。

上記より、ｓｃｅｎａｒｉｏ要素５２０は、ｔｅｓｔｄａｔａ．ｐｒｎというデータの印刷指示がユーザによって入力され、１０分経過後、ユーザによってジャムが除去され、更に、１０分経過後、ユーザによってトナーが交換される、という操作手順を示す。

なお、ｔｅｓｔｄａｔａ．ｐｒｎは、３００ページのデータである。また、２番目のステップでの１０分間の待機は、ジャムが発生するまでの９９枚の印刷に要する時間＋αに対応する。本実施の形態において、対象機器の印刷性能は、５０ｐｐｍ（１分間あたり５０枚）であるとする。そうすると、対象機器は、９９枚の印刷に２分弱を要する。更に、ユーザがジャムの原因の除去を完了するまでの時間を考慮して、２番目のステップでは１０分間の待機時間が設けられている。４番目のステップにおいても、９９枚目から１９８枚目までの印刷時間と、トナーの交換に要する時間を考慮して、１０分間の待機時間が設けられている。

続いて、操作実行部１２は、テストシナリオにしたがった手順で、模倣部１１に対して操作指示を入力する（Ｓ１０４）。その結果、模倣部１１は、当該操作指示に応じて対象機器によって実行される処理を模倣する。

続いて、タスク管理部１５が実行する処理手順について説明する。図６は、タスク管理部が実行する処理手順の一例を説明するためのフローチャートである。

タスク管理部１５は、イベント通知部１３からのイベントの通知を待機している（Ｓ２０１）。すなわち、イベント通知部１３は、テストシナリオに従った操作指示の入力に応じて模倣部１１が対象機器による処理を模倣する過程において発生するイベントをタスク管理部１５に通知する。例えば、印刷の実行に関しては、１枚ごとの給紙又は排紙を示すイベントが通知される。ジャムの原因の除去に関しては、ジャムの原因の除去を示すイベントが通知される。トナーの交換に関しては、トナーの交換を示すイベントが通知される。その他、ｔｉｍｉｎｇ要素に指定可能な値に対応するイベントが通知される。

タスク管理部１５は、イベントを受信すると（Ｓ２０１でＹｅｓ）、有効なタスクの有無を判定する（Ｓ２０２）。有効なタスクとは、終了していないタスクの中で、現時点において、親のタスクが存在しないタスクをいう。例えば、図５に示されるタスクの中では、ジャム発生タスクｔ１、トナー切れタスクｔ２、及びメモリフル発生タスクｔ３が有効なタスクとなる。

有効なタスクが存在する場合（Ｓ２０２でＹｅｓ）、タスク管理部１５は、有効なタスクのうちの一つを処理対象とし（Ｓ２０３）、処理対象とされたタスクにイベントを通知する（Ｓ２０４）。タスクにイベントが通知されると、後述されるように、当該タスクの条件が満たされたか否かを示す応答が当該タスクから返信される。

続いて、タスク管理部１５は、当該タスクの条件が満たされたか否かを判定する（Ｓ２０５）。当該タスクの条件が満たされた場合（Ｓ２０５でＹｅｓ）、タスク管理部１５は、当該タスクを終了させる（Ｓ２０６）。続いて、タスク管理部１５は、当該タスクに子のタスクが有るか否かを判定する（Ｓ２０７）。当該タスクに子のタスクが有る場合（Ｓ２０７でＹｅｓ）、タスク管理部１５は、当該子のタスクを有効なタスクとする（Ｓ２０８）。なお、当該タスクに子のタスクが無い場合（Ｓ２０７でＮｏ）、ステップＳ２０８は実行されない。また、当該タスクの条件が満たされない場合（Ｓ２０５でＮｏ）、ステップＳ２０６〜Ｓ２０８は実行されない。

続いて、タスク管理部１５は、当該タスクの兄弟タスクの有無を確認する（Ｓ２０９）。兄弟タスクが有る場合（Ｓ２０９でＹｅｓ）、当該兄弟タスクに関してステップＳ２０３以降が実行される。兄弟タスクが無い場合（Ｓ２０９でＮｏ）、ステップ２０２以降が実行される。

図５の例によれば、当初は、ジャム発生タスクｔ１、トナー切れ発生タスクｔ２、及びメモリフル発生タスクｔ３にイベントが通知される。ジャム発生タスクｔ１が終了すると、ジャム復帰タスクｔ１１が有効となる。その結果、ジャム復帰タスクｔ１１にイベントが通知されるようになる。また、トナー切れ発生タスクｔ２が終了すると、トナー切れ復帰タスクｔ２１が有効となる。その結果、トナー切れ復帰タスクｔ２１にイベントが通知されるようになる。

続いて、各タスクが実行する処理について説明する。図７は、タスクが実行する処理手順の一例を説明するためのフローチャートである。

タスクは、生成されると、タスク管理部１５からのイベントの受信を待機している（Ｓ３０１）。タスク管理部１５からのイベントが受信されると（Ｓ３０１でＹｅｓ）、タスクは、当該イベントが監視対象のイベントであるか否かを判定する（Ｓ３０２）。監視対象のイベントは、タスクの条件に基づいて特定される。例えば、ジャム発生タスクｔ１にとって監視対象のイベントは、１枚ごとの給紙である。ジャム復帰タスクｔ１１にとって、監視対象のイベントは、ジャムの原因の除去である。トナー切れ発生タスクｔ２にとって、監視対象のイベントは、１枚ごとの転写及び排紙である。トナー切れ復帰タスクｔ２１にとって、監視対象のイベントは、トナーの交換である。メモリフル発生タスクｔ３にとって、監視対象のイベントは、１枚ごとの印刷データの解析（解釈）とその際に消費されるメモサイズである。なお、イベントには、当該イベントに対応する事象（給紙、排紙、ジャムの原因の除去、トナーの交換、印刷データの解析、メモリの消費量等）を示す情報が含まれている。

受信されたイベントが監視対象である場合（Ｓ３０２でＹｅｓ）、タスクは、当該タスクの監視情報を更新する（Ｓ３０３）。監視情報とは、タスクの条件が満たされたことを検知するために記録される情報である。例えば、ジャム発生タスクｔ１にとって、監視情報は、給紙を示すイベントの受信回数である。ジャム復帰タスクｔ１１にとって、監視情報は、ジャムの原因の除去を示すイベントが受信されたか否かを示す情報である。トナー切れ発生タスクｔ２にとって、監視情報は、排紙を示すイベントの受信回数である。トナー切れ復帰タスクｔ２１にとって、監視情報は、トナーの交換を示すイベントが受信されたか否かを示す情報である。メモリフル発生タスクｔ３にとって、監視情報は、メモリの消費量である。

続いて、タスクは、監視情報と当該タスクの条件とを比較することにより、当該タスクの条件が満たされたか否かを判定する（Ｓ３０４）。例えば、ジャム発生タスクｔ１であれば、９９回の給紙が行われたか否かが判定される。

タスクの条件が満たされた場合（Ｓ３０４でＹｅｓ）、タスクは、模倣部１１の状態を変更する（Ｓ３０５）。具体的には、タスクは、模倣部１１の状態を、当該タスクに設定されている状態へ移行させる。模倣部１１の状態の変更は、例えば、模倣部１１が有する複数のパラメータのうちのいずれかの値を変更することによって実現されてもよい。続いて、タスクは、条件が満たされたことを示す応答をタスク管理部１５に返信する（Ｓ３０６）。なお、模倣部１１は、状態の移行後に、アプリ２０からＡＰＩが呼び出されると、移行後の状態において対象機器が実行する処理を模倣する。

一方、受信されたイベントが監視対象でない場合（Ｓ３０２でＮｏ）、又はタスクの条件が満たされていない場合（Ｓ３０４でＮｏ）は、条件が満たされていないことを示す応答をタスク管理部１５に返信する。

続いて、図４に示したテスト定義データに関して実行される処理について、具体的に説明する。

操作実行部１２は、ｓｃｅｎａｒｉｏ要素５２０の最初のｓｔｅｐ要素（ｎｕｍｂｅｒ属性の値が１であるｓｔｅｐ要素）内のｐｒｉｎｔ要素に基づいて、ｔｅｓｔｄａｔａ．ｐｒｎに関する印刷処理の実行を模倣部１１に指示する。なお、ｔｅｓｔｄａｔａ．ｐｒｎは、例えば、所定のフォルダに保存されている。その後、操作実行部１２は、２番目のｓｔｅｐ要素内のｗａｉｔ要素に基づいて、模倣部１１に対する指示の入力を１０分間待機する。

一方、模倣部１１は、操作実行部１２からの指示に応じ、ｔｅｓｔｄａｔａ．ｐｒｎの印刷処理のエミュレート（以下、単に「印刷処理」という。）を開始する。印刷処理の間、模倣部１１は、自らの状態の変化を示すイベントや、その他のイベントの発行を、イベント通知部１３に要求する。イベント通知部１３は、要求されたイベントをタスク管理部１５に対して通知する。タスク管理部１５は、当該イベントの通知に応じて、図６において説明した処理を実行し、有効なタスクに対してイベントを通知する。

本実施の形態では、ジャム発生タスクｔ１とジャム復帰タスクｔ１１とが親子関係を有し、トナー切れ発生タスクｔ２とトナー切れ復帰タスクｔ２１とが親子関係を有する。また、メモリフル発生タスクｔ３は、ジャム発生タスクｔ１及びトナー切れ発生タスクｔ２と兄弟関係を有する。したがって、当初においては、ジャム発生タスクｔ１、トナー切れ発生タスクｔ２、及びメモリフル発生タスクｔ３にイベントが通知される。各タスクは、イベントの通知に応じて、図７において説明した処理を実行する。

その結果、９９ページ目（９９回目）の給紙イベント時に、ジャム発生タスクｔ１の条件が充足される。そこで、ジャム発生タスクｔ１は、模倣部１１をジャムが発生した状態に移行させる。また、ジャム発生タスクｔ１の条件が充足に伴って、タスク管理部１５は、ジャム発生タスクｔ１を終了させる。その結果、ジャム復帰タスクｔ１１が有効化される。

印刷の開始から１０分が経過すると、操作実行部１２は、３番目のｓｔｅｐ要素内のｒｅｍｏｖｅｊａｍ要素に基づいて、疑似的なジャムの解除操作を模倣部１１に対して実行する。ジャムの解除操作に応じ、模倣部１１は、ジャムの解除イベントの発行を、イベント通知部１３に要求する。イベント通知部１３が、タスク管理部１５に当該イベントを通知すると、タスク管理部１５は、ジャム復帰タスクｔ１１、トナー切れ発生タスクｔ２、及びメモリフル発生タスクｔ３に対してジャムの解除イベントを通知する。ジャムの解除イベントに応じて、ジャム復帰タスクｔ１１の条件が充足される。そこで、ジャム復帰タスクｔ１１は、模倣部１１のジャム状態を解除した後、終了する。

続いて、操作実行部１２は、４番目のｓｔｅｐ要素内のｗａｉｔ要素に基づいて、１０分間待機する。

一方、模倣部１１は、ジャム状態の解除に応じて印刷処理を再開する。再開された印刷処理において、１９８ページ目の排紙イベント時にトナー切れ発生タスクｔ２の条件が充足される。そこで、トナー切れ発生タスクｔ２は、模倣部１１をトナー切れ状態とした後、終了する。トナー切れ発生タスクｔ２の終了に応じ、トナー切れ復帰タスクｔ２１が有効化される。

ジャムの解除から１０分経過すると、操作実行部１２は、５番目のｓｔｅｐ要素内のｃｈａｎｇｅｔｏｎｅｒ要素に基づいて、疑似的なトナーの交換操作を模倣部１１に対して実行する。トナーの交換操作に応じ、模倣部１１は、トナーの交換イベントの発行を、イベント通知部１３に対して要求する。イベント通知部１３が、タスク管理部１５に当該イベントを通知すると、タスク管理部１５は、トナー切れ復帰タスクｔ２１及びメモリフル発生タスクｔ３に対して、トナーの交換イベントを通知する。トナーの交換イベントに応じて、トナー切れ復帰タスクｔ２１の条件が充足される。そこで、トナー切れ復帰タスクｔ２１は、模倣部１１のトナー切れの状態を解除した後、終了する。

トナー切れ状態の解除に応じ、模倣部１１は、印刷処理を再開する。再開された印刷処理において、２２０ページ目の解析イベント時に、メモリフル発生タスクｔ３の条件が充足される。そこで、メモリフル発生タスクｔ３は、模倣部１１をメモリフル状態とした後、終了する。なお、メモリフルに応じて、評価対象のアプリ２０は、例えば、実行中のジョブを中止させる。

上述したように、本実施の形態によれば、模倣部１１は、テストシナリオに指定された操作指示に応じた処理を実行する過程において、状態変更条件に指定されたタイミングで、状態変更条件に指定された状態に移行することができる。すなわち、エミュレートする対象の機器における各種の状態を容易に再現することができる。したがって、ユーザは、例えば、アプリ２０の動作確認を、対象機器において生じうる様々な状態において行うことができる。

なお、本実施の形態では、模倣部１１がエミュレートする機器（対象機器）が、画像形成装置である例について説明したが、模倣部１１がエミュレートする機器は、プロジェクタ、テレビ会議システム、デジタルカメラ等、画像形成装置以外の機器がエミュレートの対象であってもよい。

また、本実施の形態における情報処理装置１０の機能は、クラウドサービス、ＡＳＰ（Application Service Provider）が提供するサービス、又はＷｅｂサービス等、ネットワークを介して利用されるサービスとして提供されてもよい。この場合、アプリ２０は、情報処理装置１０にネットワークを介して接続される、ユーザ側のＰＣ（Personal Computer）等に配置されてもよいし、情報処理装置１０に対してアップロードされてもよい。

なお、本実施の形態において、情報処理装置１０は、情報処理装置及び情報処理システムの一例である。タスクは、状態変更部の一例である。テストシナリオに関する定義は、第一の定義情報の一例である。状態変更条件に関する定義は、第二の定義情報の一例である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０ 情報処理装置
１１ 模倣部
１２ 操作実行部
１３ イベント通知部
１４ タスク生成部
１５ タスク管理部
１６ 定義データ記憶部
２０ アプリ
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
１０６ 表示装置
１０７ 入力装置
Ｂ バス

特開２０１０−０４５７８１号公報

Claims (13)

1. 第一の定義情報に定義された操作手順に応じて、機器が実行する処理を模倣する模倣部と、
   前記処理の模倣に応じて発生する事象を監視して、第二の定義情報において指定された時期の到来を検知し、該検知に応じて前記模倣部の状態を、前記第二の定義情報において指定された状態に変更する状態変更部とを有し、
   前記模倣部は、前記状態変更部によって変更された状態において、前記機器に処理を実行させるプログラムからの要求に応じて、前記機器によって実行される処理を模倣することを特徴とする情報処理装置。
2. 前記第二の定義情報は、前記模倣部の状態を変更する時期を指定する情報と、変更後の状態を指定する情報との組を１以上含み、
   前記組ごとに、１以上の前記状態変更部を有し、
   各状態変更部は、前記処理の模倣に応じて発生する事象を監視して、当該状態変更部に係る前記組において指定された時期の到来を検知し、該検知に応じて前記模倣部の状態を、当該において指定された状態に変更することを特徴とする請求項１記載の情報処理装置。
3. 複数の前記状態変更部の一部又は全部は、前記第二の定義情報における前記組の関係に基づいて、直列的な関係を有し、
   直列的な関係を有する前記状態変更部は、直列的な関係において前段の前記状態変更部が前記模倣部の状態を変更した後に、前記処理の模倣に応じて発生する事象の監視を行うことを特徴とする請求項２記載の情報処理装置。
4. 前記直列的な関係を有する２つの前記状態変更部の一方は、前記模倣部の状態を変更し、他方は、前記状態から前記模倣部を復帰させる請求項３記載の情報処理装置。
5. １以上のコンピュータを含む情報処理システムであって、
   第一の定義情報に定義された操作手順に応じて、機器が実行する処理を模倣する模倣部と、
   前記処理の模倣に応じて発生する事象を監視して、第二の定義情報において指定された時期の到来を検知し、該検知に応じて前記模倣部の状態を、前記第二の定義情報において指定された状態に変更する状態変更部とを有し、
   前記模倣部は、前記状態変更部によって変更された状態において、前記機器に処理を実行させるプログラムからの要求に応じて、前記機器によって実行される処理を模倣することを特徴とする情報処理システム。
6. コンピュータが実行する情報処理方法であって、
   前記コンピュータの模倣部が、第一の定義情報に定義された操作手順に応じて、機器が実行する処理を模倣する模倣手順と、
   前記コンピュータの状態変更部が、前記処理の模倣に応じて発生する事象を監視して、第二の定義情報において指定された時期の到来を検知し、該検知に応じて前記模倣部の状態を、前記第二の定義情報において指定された状態に変更する状態変更手順とを有し、
   前記模倣部は、前記状態変更部によって変更された状態において、前記機器に処理を実行させるプログラムからの要求に応じて、前記機器によって実行される処理を模倣することを特徴とする情報処理方法。
7. 前記第二の定義情報は、前記模倣部の状態を変更する時期を指定する情報と、変更後の状態を指定する情報との組を１以上含み、
   前記コンピュータは、前記組ごとに、１以上の前記状態変更部を有し、
   各状態変更部が、前記処理の模倣に応じて発生する事象を監視して、当該状態変更部に係る前記組において指定された時期の到来を検知し、該検知に応じて前記模倣部の状態を、当該において指定された状態に変更することを特徴とする請求項６記載の情報処理方法。
8. 複数の前記状態変更部の一部又は全部は、前記第二の定義情報における前記組の関係に基づいて、直列的な関係を有し、
   直列的な関係を有する前記状態変更部が、直列的な関係において前段の前記状態変更部が前記模倣部の状態を変更した後に、前記処理の模倣に応じて発生する事象の監視を行うことを特徴とする請求項７記載の情報処理方法。
9. 前記直列的な関係を有する２つの前記状態変更部の一方が、前記模倣部の状態を変更し、他方が、前記状態から前記模倣部を復帰させる請求項８記載の情報処理方法。
10. 第一の定義情報に定義された操作手順に応じて、機器が実行する処理を模倣する模倣部と、
    前記処理の模倣に応じて発生する事象を監視して、第二の定義情報において指定された時期の到来を検知し、該検知に応じて前記模倣部の状態を、前記第二の定義情報において指定された状態に変更する状態変更部としてコンピュータを機能させ、
    前記模倣部は、前記状態変更部によって変更された状態において、前記機器に処理を実行させるプログラムからの要求に応じて、前記機器によって実行される処理を模倣することを特徴とする情報処理プログラム。
11. 前記第二の定義情報は、前記模倣部の状態を変更する時期を指定する情報と、変更後の状態を指定する情報との組を１以上含み、
    前記組ごとに、１以上の前記状態変更部として前記コンピュータを機能させ、
    各状態変更部は、前記処理の模倣に応じて発生する事象を監視して、当該状態変更部に係る前記組において指定された時期の到来を検知し、該検知に応じて前記模倣部の状態を、当該において指定された状態に変更することを特徴とする請求項１０記載の情報処理プログラム。
12. 複数の前記状態変更部の一部又は全部は、前記第二の定義情報における前記組の関係に基づいて、直列的な関係を有し、
    直列的な関係を有する前記状態変更部は、直列的な関係において前段の前記状態変更部が前記模倣部の状態を変更した後に、前記処理の模倣に応じて発生する事象の監視を行うことを特徴とする請求項１１記載の情報処理プログラム。
13. 前記直列的な関係を有する２つの前記状態変更部の一方は、前記模倣部の状態を変更し、他方は、前記状態から前記模倣部を復帰させる請求項１２記載の情報処理プログラム。

Images