(57)【要約】【課題】ＯＳＧｉ上で動作中のアプリケーションのシステムテストをプログラマブルに行う。【解決手段】テストケース群に記述されているクラスを抽出し、ターゲットソース群から前記抽出したクラスを宣言している箇所を検索すると共に、前記クラスを生成している生成元クラスを検索する検索手段と、前記検索手段により検索された前記クラスの宣言をしている箇所に、前記クラスのインスタンス、前記クラスのクラス名、前記クラスを生成している生成元クラス名、前記クラスをテストするテストケース名の情報を埋め込む埋め込み手段と、前記埋め込み手段により埋め込まれた前記情報を含むターゲットソース群に基づいて、前記テストケース群を実行可能な実行可能ファイルを生成する生成手段と、前記生成手段により生成された実行可能ファイルを、ネットワークを介して通信可能な画像処理装置に送信する送信手段と、を有することによって課題を解決する。【選択図】図７
2014048836.tif 000002
【特許請求の範囲】
【請求項１】
テストケース群に記述されているクラスを抽出し、ターゲットソース群から前記抽出したクラスを宣言している箇所を検索すると共に、前記クラスを生成している生成元クラスを検索する検索手段と、
前記検索手段により検索された前記クラスの宣言をしている箇所に、前記クラスのインスタンス、前記クラスのクラス名、前記クラスを生成している生成元クラス名、前記クラスをテストするテストケース名の情報を埋め込む埋め込み手段と、
前記埋め込み手段により埋め込まれた前記情報を含むターゲットソース群に基づいて、前記テストケース群を実行可能な実行可能ファイルを生成する生成手段と、
前記生成手段により生成された実行可能ファイルを、ネットワークを介して通信可能な画像処理装置に送信する送信手段と、
を有する情報処理装置。
【請求項２】
前記生成手段により前記ターゲットソースに基づいて、前記実行可能ファイルが生成された後に、前記埋め込み手段により埋め込まれた前記情報を、前記ターゲットソースから削除する削除手段を更に有する請求項１記載の情報処理装置。
【請求項３】
ネットワークを介して通信可能な情報処理装置から、テストケース群に記述されているクラスのインスタンス、前記クラスのクラス名、前記クラスを生成している生成元クラス名、前記クラスをテストするテストケース名の情報を含む前記テストケース群を実行可能な実行可能ファイルを受信する受信手段と、
前記受信手段により受信された前記実行可能ファイルをインストールするインストール手段と、
前記インストール手段によりインストールされた前記実行可能ファイルを起動させる起動手段と、
前記起動手段により起動された前記実行可能ファイルに含まれる前記クラスのクラス名、前記クラスを生成している生成元クラス名、前記クラスをテストするテストケース名の情報に基づいて各テストケースのコール順番をソートするソート手段と、
前記ソート手段によりソートされた順番で各テストケースを実行する実行手段と、
を有する画像処理装置。
【請求項４】
前記ソート手段は、前記クラスのクラス名と前記生成元クラス名とに基づいて生成元をたどっていくことにより起点となるクラスを特定し、前記起点のクラスから順に、前記クラスをテストするテストケース名のテストケースをコールするようにコール順番をソートする請求項３記載の画像処理装置。
【請求項５】
前記実行手段は、前記テストケースを実行する際、前記テストケース名に対応する前記クラスのインスタンスを取得し、前記インスタンスを用いて前記テストケースを実行し、前記クラスのインスタンスを取得できない場合は、前記テストケースを遅延させる登録を行う登録手段を更に有する請求項３又は４記載の画像処理装置。
【請求項６】
前記登録手段で登録された前記テストケースを実行する遅延テストケース実行手段を更に有する請求項５記載の画像処理装置。
【請求項７】
情報処理装置と、画像処理装置とを含むシステムであって、
前記情報処理装置は、
テストケース群に記述されているクラスを抽出し、ターゲットソース群から前記抽出したクラスを宣言している箇所を検索すると共に、前記クラスを生成している生成元クラスを検索する検索手段と、
前記検索手段により検索された前記クラスの宣言をしている箇所に、前記クラスのインスタンス、前記クラスのクラス名、前記クラスを生成している生成元クラス名、前記クラスをテストするテストケース名の情報を埋め込む埋め込み手段と、
前記埋め込み手段により埋め込まれた前記情報を含むターゲットソース群に基づいて、前記テストケース群を実行可能な実行可能ファイルを生成する生成手段と、
前記生成手段により生成された実行可能ファイルを、ネットワークを介して通信可能な画像処理装置に送信する送信手段と、
を有し、
前記画像処理装置は、
前記情報処理装置から、前記実行可能ファイルを受信する受信手段と、
前記受信手段により受信された前記実行可能ファイルをインストールするインストール手段と、
前記インストール手段によりインストールされた前記実行可能ファイルを起動させる起動手段と、
前記起動手段により起動された前記実行可能ファイルに含まれる前記クラスのクラス名、前記クラスを生成している生成元クラス名、前記クラスをテストするテストケース名の情報に基づいて各テストケースのコール順番をソートするソート手段と、
前記ソート手段によりソートされた順番で各テストケースを実行する実行手段と、
を有するシステム。
【請求項８】
情報処理装置が実行する情報処理方法であって、
テストケース群に記述されているクラスを抽出し、ターゲットソース群から前記抽出したクラスを宣言している箇所を検索すると共に、前記クラスを生成している生成元クラスを検索する検索ステップと、
前記検索ステップにより検索された前記クラスの宣言をしている箇所に、前記クラスのインスタンス、前記クラスのクラス名、前記クラスを生成している生成元クラス名、前記クラスをテストするテストケース名の情報を埋め込む埋め込みステップと、
前記埋め込みステップにより埋め込まれた前記情報を含むターゲットソース群に基づいて、前記テストケース群を実行可能な実行可能ファイルを生成する生成ステップと、
前記生成ステップにより生成された実行可能ファイルを、ネットワークを介して通信可能な画像処理装置に送信する送信ステップと、
を含む情報処理方法。
【請求項９】
画像処理装置が実行する情報処理方法であって、
ネットワークを介して通信可能な情報処理装置から、テストケース群に記述されているクラスのインスタンス、前記クラスのクラス名、前記クラスを生成している生成元クラス名、前記クラスをテストするテストケース名の情報を含む前記テストケース群を実行可能な実行可能ファイルを受信する受信ステップと、
前記受信ステップにより受信された前記実行可能ファイルをインストールするインストールステップと、
前記インストールステップによりインストールされた前記実行可能ファイルを起動させる起動ステップと、
前記起動ステップにより起動された前記実行可能ファイルに含まれる前記クラスのクラス名、前記クラスを生成している生成元クラス名、前記クラスをテストするテストケース名の情報に基づいて各テストケースのコール順番をソートするソートステップと、
前記ソートステップによりソートされた順番で各テストケースを実行する実行ステップと、
を含む情報処理方法。
【請求項１０】
情報処理装置と、画像処理装置とを含むシステムの情報処理方法であって、
前記情報処理装置が、テストケース群に記述されているクラスを抽出し、ターゲットソース群から前記抽出したクラスを宣言している箇所を検索すると共に、前記クラスを生成している生成元クラスを検索する検索ステップと、
前記情報処理装置が、前記検索ステップにより検索された前記クラスの宣言をしている箇所に、前記クラスのインスタンス、前記クラスのクラス名、前記クラスを生成している生成元クラス名、前記クラスをテストするテストケース名の情報を埋め込む埋め込みステップと、
前記情報処理装置が、前記埋め込みステップにより埋め込まれた前記情報を含むターゲットソース群に基づいて、前記テストケース群を実行可能な実行可能ファイルを生成する生成ステップと、
前記情報処理装置が、前記生成ステップにより生成された実行可能ファイルを、ネットワークを介して通信可能な画像処理装置に送信する送信ステップと、
前記画像処理装置が、前記情報処理装置から、前記実行可能ファイルを受信する受信ステップと、
前記画像処理装置が、前記受信ステップにより受信された前記実行可能ファイルをインストールするインストールステップと、
前記画像処理装置が、前記インストールステップによりインストールされた前記実行可能ファイルを起動させる起動ステップと、
前記画像処理装置が、前記起動ステップにより起動された前記実行可能ファイルに含まれる前記クラスのクラス名、前記クラスを生成している生成元クラス名、前記クラスをテストするテストケース名の情報に基づいて各テストケースのコール順番をソートするソートステップと、
前記画像処理装置が、前記ソートステップによりソートされた順番で各テストケースを実行する実行ステップと、
を含む情報処理方法。
【請求項１１】
コンピュータに、
テストケース群に記述されているクラスを抽出し、ターゲットソース群から前記抽出したクラスを宣言している箇所を検索すると共に、前記クラスを生成している生成元クラスを検索する検索ステップと、
前記検索ステップにより検索された前記クラスの宣言をしている箇所に、前記クラスのインスタンス、前記クラスのクラス名、前記クラスを生成している生成元クラス名、前記クラスをテストするテストケース名の情報を埋め込む埋め込みステップと、
前記埋め込みステップにより埋め込まれた前記情報を含むターゲットソース群に基づいて、前記テストケース群を実行可能な実行可能ファイルを生成する生成ステップと、
前記生成ステップにより生成された実行可能ファイルを、ネットワークを介して通信可能な画像処理装置に送信する送信ステップと、
を実行させるプログラム。
【請求項１２】
コンピュータに、
ネットワークを介して通信可能な情報処理装置から、テストケース群に記述されているクラスのインスタンス、前記クラスのクラス名、前記クラスを生成している生成元クラス名、前記クラスをテストするテストケース名の情報を含む前記テストケース群を実行可能な実行可能ファイルを受信する受信ステップと、
前記受信ステップにより受信された前記実行可能ファイルをインストールするインストールステップと、
前記インストールステップによりインストールされた前記実行可能ファイルを起動させる起動ステップと、
前記起動ステップにより起動された前記実行可能ファイルに含まれる前記クラスのクラス名、前記クラスを生成している生成元クラス名、前記クラスをテストするテストケース名の情報に基づいて各テストケースのコール順番をソートするソートステップと、
前記ソートステップによりソートされた順番で各テストケースを実行する実行ステップと、
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、画像処理装置、システム、情報処理方法、及びプログラムに関する。
【背景技術】
【０００２】
従来技術として、テストケース内でテストターゲットのインスタンスを生成し、インスタンスのＡＰＩに対するテストを任意の順序で実行する仕組みがある。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−５５０９６３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来技術では、複合機等の組み込み機器内のＯＳＧｉ（登録商標）上で動作しているア
プリケーションに対するシステムテストをテストケースからプログラマブルに実行することが困難であった。なお、ここで言う「プログラマブル」とは、ソフトウェアプログラムによって、一連の作業指示を与えられることを意味する。
第一の理由として、テストケースから実行中のアプリケーションのインスタンスを取得することが困難であった。
第二の理由として、どのテストケースから実行すればよいか、自動で判別することが困難であった。
特に、第二の理由は、テストケースの作成及び実行者がアプリケーション開発者でない場合等に顕著になる。より具体的には、ロールチェンジによる担当者変更や、品質保証部門等でテストを行うような場合、アプリケーションの詳細なクラス構成を把握していないテスターがテストケースの生成及び実行を担当することになるためである。そのため、テスターは、どのテストケースからコールすべきかわからないという問題があった。
この問題は、例えば、テストケースＡを実行するためにはテストケースＢを先に実行する、という条件判断が必要になることに起因する。つまり、テスターは、動作中のアプリケーション内で生成されるインスタンスの順番を考慮してテストケースを実行しないと、テスト対象のインスタンスが存在しない際にテストが失敗する。そのため、ＯＳＧｉ上で
動作中のアプリケーションに対して、システムテストをプログラマブルに行うことができないという問題があった。
【課題を解決するための手段】
【０００５】
そこで、本発明は、テストケース群に記述されているクラスを抽出し、ターゲットソース群から前記抽出したクラスを宣言している箇所を検索すると共に、前記クラスを生成している生成元クラスを検索する検索手段と、前記検索手段により検索された前記クラスの宣言をしている箇所に、前記クラスのインスタンス、前記クラスのクラス名、前記クラスを生成している生成元クラス名、前記クラスをテストするテストケース名の情報を埋め込む埋め込み手段と、前記埋め込み手段により埋め込まれた前記情報を含むターゲットソース群に基づいて、前記テストケース群を実行可能な実行可能ファイルを生成する生成手段と、前記生成手段により生成された実行可能ファイルを、ネットワークを介して通信可能な画像処理装置に送信する送信手段と、を有する。
【発明の効果】
【０００６】
本発明によれば、ＯＳＧｉ上で動作中のアプリケーションに対して、システムテストを
プログラマブルに行うことができる。
【図面の簡単な説明】
【０００７】
【図１】テストケースの実行順序の一例を示す図である。
【図２】システム構成の一例を示す図である。
【図３】クライアントＰＣのハードウェア構成の一例を示す図である。
【図４】デバイスのハードウェア構成の一例を示す図である。
【図５】クライアントＰＣ及びデバイスの機能構成の一例を示す図である。
【図６】ＴｅｓｔＢｕｎｄｌｅの構成の一例を示す図である。
【図７】実施形態１の処理の一例を示すフローチャートである。
【図８】テストケースクラス、ターゲットクラス及びターゲットソースの記述の一例を示す図である。
【図９】テストケースの記述の一例を示す図である。
【図１０】ターゲットクラス、生成元クラス及びテストケースの記述の一例を示す図である。
【図１１】図１０のターゲットクラス、生成元クラス及びテストケースの関係をまとめた図である。
【発明を実施するための形態】
【０００８】
以下、本発明の実施形態について図面に基づき説明する。
【０００９】
＜実施形態１＞
図１は、テストケースの実行順序の一例を示す図である。
デバイスの操作パネル部に表示されている「ようこそ！」の文字列が中央に表示されているパネル部品１００は、ＣｌａｓｓＣのインスタンスを生成した結果表示されるパネルである。ユーザが、このパネルをタッチすると、画面中央に「コピー実行」ボタン部品１０１が表示されるが、これは前述のタッチ操作により、ＣｌａｓｓＣ内からＣｌａｓｓＢのインスタンスが生成された結果表示されるボタンである。同様に、「コピー中」と表示されたテキストフィールド部品１０２は、前述のボタン部品１０１をユーザが押下したことによってＣｌａｓｓＢ内からＣｌａｓｓＡのインスタンスが生成された結果表示されるテキストフィールド及び文字列である。
つまり、クラスの生成順序は、１０３に示すように、テキストフィールドＣｌａｓｓＡを生成するには、ボタンＣｌａｓｓＢが生成されている必要があり、ボタンＣｌａｓｓＢを生成するには、パネルＣｌａｓｓＣが生成されている必要がある。
以上のように、アプリケーション内のインスタンス生成順序に合わせて、各クラスに対するテストケースを実行する必要がある。実行順序が異なる場合、テスト対象のインスタンスが存在しないため、テストケースは正常に実行できない。
【００１０】
図２は、本実施形態のシステム構成２００の一例を示す図である。
テストの生成及び実行を行うテスター２０２は、クライアントＰＣ２０１を利用して、クライアントＰＣ２０１とネットワーク２０３を介して通信可能な複合機等の組み込みデバイス２０４に対してテスト実行操作等を行う。クライアントＰＣ２０１は、キーボード及びマウスを有している。なお、キーボードのキー配列や、マウスのクリック可能なボタン数等、ハードウェアの形態は問わない。なお、クライアントＰＣ２０１は、情報処理装置の一例である。また、デバイス２０４は、画像処理装置の一例である。
【００１１】
図３は、クライアントＰＣ２０１のハードウェア構成の一例を示す図である。
クライアントＰＣ２０１は、キーボード３１１やマウス３１２のようなポインティングデバイス等の入力装置及びディスプレイ装置３１３と接続されている。また、クライアントＰＣ２０１は、Ｉ／Ｏインターフェース３０８を介してネットワーク２０３と接続されることにより、システム上の他のコンピュータ装置やプリンタ３１４等のデバイスと接続されている。なお、ネットワーク２０３の例は、ローカルエリアネットワーク（ＬＡＮ）やワイドエリアネットワーク（ＷＡＮ）等である。
クライアントＰＣ２０１は、少なくとも１つ以上のＣＰＵ３０１、メモリ３０２、記憶装置３０３、ビデオインターフェース３０７、Ｉ／Ｏインターフェース３０８、Ｉ／Ｏインターフェース３０９、ＣＤ−ＲＯＭドライブ３０６及びバス３１０を含む。
ＣＰＵ３０１は、記憶装置３０３に格納されているプログラムに基づいて処理を実行することにより、後述するクライアントＰＣ２０１の機能（ソフトウェアの機能）及びクライアントＰＣ２０１に関するフローチャートに係る処理を実現する。
メモリ３０２は、例えばＲＡＭやＲＯＭ等を含む。
記憶装置３０３は、例えばＨＤＤ３０４やＦＤＤ３０５等を含む。また、記憶装置３０３は、その他に磁気テープドライブ等を含んでいてもよい。
ＣＤ−ＲＯＭドライブ３０６は、不揮発性のデータソースである。
ビデオインターフェース３０７は、クライアントＰＣ２０１と、ディスプレイ装置３１３との接続におけるインターフェースである。
Ｉ／Ｏインターフェース３０８は、クライアントＰＣ２０１と、ネットワーク２０３との接続におけるインターフェースである。
Ｉ／Ｏインターフェース３０９は、クライアントＰＣ２０１と、キーボード３１１及びマウス３１２との接続におけるインターフェースである。
バス３１０は、クライアントＰＣ２０１の各コンポーネントを相互に接続させる相互接続バスである。
なお、ＣＰＵ３０１は、ＬＩＮＵＸ（登録商標）やウィンドウズ（登録商標）等のＯＳに基づいて、Ｉ／Ｏインターフェース３０９を介したキーボード３１１、マウス３１２等からの入力を制御する。
【００１２】
図４は、デバイス２０４のハードウェア構成の一例を示す図である。
ＣＰＵ４０５は、ＲＯＭ４０６に格納されているプログラムに基づいて処理を実行することにより、後述するデバイス２０４の機能（ソフトウェアの機能）及びデバイス２０４に関するフローチャートに係る処理を実現する。
制御部４０４は、後述するようにデバイス２０４全体の動作を制御する。なお、制御部４０４は、ＣＰＵ４０５、ＲＯＭ４０６及びＲＡＭ４０７を含む。
ＲＯＭ４０６は、ＣＰＵ４０５が実行するプログラム等を格納する。
ＲＡＭ４０７は、ＣＰＵ４０５の主メモリ、ワークエリア等の一時記憶領域として用いられる。
ＨＤＤ４０３は、画像データや、各種プログラムを格納する。
制御部４０４は、操作部４０８、スキャナ部４０９及びプリンタ部４１０の動作を制御する。
操作部４０８は、タッチパネル機能を有する液晶表示部やキーボード等を含み、液晶表示部に画像を表示させたり、キーボードからの入力を受け付けたりする。
スキャナ部４０９は、原稿上の画像を読み取って画像データを生成し、制御部４０４に入力する。
プリンタ部４１０は、制御部４０４から入力された印刷すべき画像データを記録媒体上に印刷する。
インターフェース部４０１は、制御部４０４をネットワーク２０３に接続させ、ネットワーク上の図外の情報処理装置等から印刷用の画像データを受信したり、操作部４０８で表示する画面データを受信したりする。また、インターフェース部４０１は、ＵＳＢインターフェース４１１を介して、ＩＣカードリーダーやメモリスティック等に接続され、認証情報や画像データ等を受信することもある。なお、制御部４０４は、インターフェース部４０１が図外の情報処理装置等から受信した印刷画像等を、画像メモリ４０２に一時的に格納し、更にプリンタ部４１０で印刷出力する。
【００１３】
図５は、クライアントＰＣ２０１及びデバイス２０４の機能構成の一例を示す図である。
以下、クライアントＰＣ２０１の機能構成について説明する。
クライアントＰＣ２０１内には、統合開発環境であるＥｃｌｉｐｓｅ５００がインストールされており、Ｅｃｌｉｐｓｅ５００のプラグインとして、ＴｅｓｔＦｒａｍｅｗｏｒｋ５０１がインストールされている。
ＴｅｓｔＦｒａｍｅｗｏｒｋ５０１は、図８で後述するテストケースの生成、図６で後述するＴｅｓｔＢｕｎｄｌｅ５０３の生成及びデバイス２０４へのインストール、更にテストケースの実行命令等を行う。
以下、デバイス２０４の機能構成について説明する。
デバイス２０４内では、ＯＳ５０６が動作している。
ＯＳ５０６上では、Ｊａｖａ（登録商標）ＶＭ（ＶｉｒｔｕａｌＭａｃｈｉｎｅ）５０５が動作している。
ＪａｖａＶＭ５０５上では、ＯＳＧｉ（ＯｐｅｎＳｅｒｖｉｃｅｓＧａｔｅｗａｙｉｎ
ｉｔｉｔａｔｉｖｅ）５０４が動作している。
ＯＳＧｉ５０４上では、ＴｅｓｔＢｒｏｋｅｒ５０２と、ＴｅｓｔＢｕｎｄｌｅ５０３
とが動作している。
ＴｅｓｔＢｒｏｋｅｒ５０２は、クライアントＰＣ２０１内のＥｃｌｉｐｓｅ５００上で動作するＴｅｓｔＦｒａｍｅｗｏｒｋ５０１と通信する。また、ＴｅｓｔＢｒｏｋｅｒ５０２は、図６で後述するＴｅｓｔＢｕｎｄｌｅ５０３のＴｅｓｔＡｇｅｎｔ６０１と通信し、テストケースクラス群６００を呼び出す。
ＴｅｓｔＢｕｎｄｌｅ５０３は、ＴｅｓｔＦｒａｍｅｗｏｒｋ５０１により生成され、デバイス２０４にインストールされ、実行される。
【００１４】
図６は、デバイス２０４内に配置されたＴｅｓｔＢｕｎｄｌｅ５０３の内部構成図である。なお、ＴｅｓｔＢｕｎｄｌｅは、デバイスによるテストケースが実行可能な実行可能ファイルの一例である。
ＴｅｓｔＡｇｅｎｔ６０１は、ＴｅｓｔＢｒｏｋｅｒ５０２と通信を行い、テスト結果やテスト順序を制御する。
テストケースクラス群６００は、ＴｅｓｔＡｇｅｎｔ６０１により、テスト順序に従って各テストケースクラスが呼び出される。
ターゲットクラス群６０２は、ＯＳＧｉ５０４上で動作しているアプリケーションであり、テストケースクラス群６００から呼び出される。
【００１５】
次に、本実施形態における処理についてフローチャート及び関連図を用いて説明する。
図７は、本実施形態におけるクライアントＰＣ２０１及びデバイス２０４の処理の一例を示すフローチャートである。
以下、Ｓ７０１からＳ７０７までの処理は、クライアントＰＣ２０１のＣＰＵ３０１がプログラムに基づいて処理を実行することにより実現される処理である。
Ｓ７０１で、ＣＰＵ３０１は、テストケースを作成し、処理をＳ７０２に進める。なお、テストケースは、図８に示されるような形式である。
【００１６】
図８は、本実施形態におけるテストケースクラス、ターゲットクラス及びターゲットソースの記述の一例を示す図である。
以下、テストケースクラス及びテストケースについて詳述する。なお、本文では、テストケースはＪａｖａ（登録商標）言語で記載されることを前提に説明するが、他の言語であってもよい。
テストケースクラス８００は、ｐｕｂｌｉｃ  ｃｌａｓｓ  ＣｌａｓｓＡＴｅｓｔＣａｓｅ  ｅｘｔｅｎｄｓ  ＴｅｓｔＣａｓｅ｛｝のように、図９で後述する親クラスのＴｅｓｔＣａｓｅ９００を継承したクラスとして記述される。なお、テストケースクラス８００が記載されているソースファイル名は、クラス名と同一となるものであり、ＣｌａｓｓＡＴｅｓｔＣａｓｅ．ｊａｖａとなる。
テストケース８０１は、Ｊａｖａ言語におけるメソッドであり、ｔｅｓｔから始まる命名規則の記述である。テストケースクラス８００は、複数のテストケース８０１の記載を含んでいる場合もある。なお、テストケース８０１で宣言された、ｐｕｂｌｉｃ  ｖｏｉｄ  ｔｅｓｔＡ（）｛｝が、テストケースの１単位となる。
ＣＰＵ３０１は、テストケース８０１に基づいて、テスト対象のクラスのインスタンスを取得し、取得したインスタンスをＣｌａｓｓＡ型のｃｌａｓｓＡ変数８０２へ格納する。
ＣｌａｓｓＡは、テスト対象のアプリケーションを構成するクラスの１つであり、例えば図８の８０４に示されるように、ｐｕｂｌｉｃ  ｃｌａｓｓ  ＣｌａｓｓＡ｛｝とクラス宣言される。ＣｌａｓｓＡの宣言８０４は、コンストラクタ８０５の記述を含んでいる。ＣＰＵ３０１は、ＣｌａｓｓＡのインスタンスを生成すると、まずＣｌａｓｓＡからコンストラクタ８０５を呼び出す。
図８の８０３に示される２つのクラスＵｔｉｌＡと、ＵｔｉｌＢとは、ＣＰＵ３０１がテストケース８０１を実行する際に利用するユーティリティクラスである。図８においては、ＵｔｉｌＡと、ＵｔｉｌＢとは、テスト対象のアプリケーションを構成するクラスでない例として記載されている。
【００１７】
Ｓ７０２で、ＣＰＵ３０１は、テストケース（テストケース群）に記述されたクラスを抽出し、処理をＳ７０３に進める。例えば、前述のテストケース８０１の場合におけるクラスは、ＣｌａｓｓＡ、ＵｔｉｌＡ及びＵｔｉｌＢの３つである。
Ｓ７０３で、ＣＰＵ３０１は、Ｓ７０２で抽出したクラスＣｌａｓｓＡ、ＵｔｉｌＡ及びＵｔｉｌＢのクラス宣言をターゲットクラス群６０２の元となるターゲットソース群から検索し、処理をＳ７０４に進める。ここで、ターゲットソースとは、テストケースがターゲットとするデバイス２０４のＣＰＵ４０５で実行されるソフトウェアに係るプログラムのソースである。ＣｌａｓｓＡは、図８の８０４に示されるようにｐｕｂｌｉｃ  ｃｌａｓｓ  ＣｌａｓｓＡとしてクラス宣言が存在する。一方、ＵｔｉｌＡ及びＵｔｉｌＢは、前述の通りテスト対象のアプリケーションを構成するクラスではないため、ターゲットクラス群６０２内にクラス宣言は存在しない。したがって、テストケース８０１内に記述されているクラスの中で、ＣＰＵ３０１によるターゲットソース群からの検索でヒットしたターゲットクラスはＣｌａｓｓＡのみとなる。
Ｓ７０４で、ＣＰＵ３０１は、Ｓ７０３で検索ヒットしたクラスＣｌａｓｓＡを生成しているクラスを、ターゲットクラス群６０２の元となるターゲットソース群から検索し、処理をＳ７０５に進める。より具体的には、図８の８０６に示されるＣｌａｓｓＢのターゲットソース内から、８０７に示されるようなＣｌａｓｓＡのインスタンスを生成している箇所を検索する。
【００１８】
Ｓ７０５で、ＣＰＵ３０１は、Ｓ７０３で検索ヒットしたクラスＣｌａｓｓＡのコンストラクタ８０５に対して、８０９に示されるように、ＴｅｓｔＡｇｅｎｔ６０１のメソッドｓｅｔＴｅｓｔＩｎｆｏ（）の引数にコードを埋め込み、処理をＳ７０６に進める。より具体的には、ＣＰＵ３０１は、以下の４つのコードを埋め込む。４つのコードは、ＣｌａｓｓＡ自身のインスタンス、自身のクラスＣｌａｓｓＡ、Ｓ７０４で検索したＣｌａｓｓＡを生成しているクラスＣｌａｓｓＢ（生成元クラス名）、ＣｌａｓｓＡが記述されているテストケース８０１のテストケース名ｔｅｓｔＡである。
上記のＳ７０２からＳ７０５までの処理は、Ｓ７０１で、ＣＰＵ３０１が作成したテストケース全てに対して同様に行われる。
Ｓ７０６で、ＣＰＵ３０１は、ＴｅｓｔＢｕｎｄｌｅ５０３を生成し、処理をＳ７０７に進める。ＴｅｓｔＢｕｎｄｌｅ５０３の構成は、図６を用いて上述した通りであり、ＯＳＧｉ５０４上で動作可能な形式としてＣＰＵ３０１により生成される。なお、ＴｅｓｔＢｕｎｄｌｅ５０３は、公知の技術であるため詳細な説明を省略する。
Ｓ７０７で、ＣＰＵ３０１は、Ｓ７０５で埋め込んだ上記４つのコードを削除し、処理をＳ７０８に進める。なお、Ｓ７０７の処理は、ターゲットクラス群６０２の元となるターゲットソース群が多数存在する場合、かつ、テスト実行と、テストケース作成とを交互に行う場合は、パフォーマンス的にオーバーヘッドになるため、必須の処理ではない。但し、Ｓ７０５でＣＰＵ３０１によりコードを埋め込まれたターゲットクラス群６０２の元となるターゲットソース群は、埋め込み前のターゲットソース群とは異なる。そのため、可能な限り自動で埋め込まれたコードを削除する本ステップを実施することが望ましい。テスター２０２が、誤ってソースコードの構成管理システム等へチェックインを行いソースコードのバージョンアップが発生する場合や、開発元へソースコードを渡した際にオリジナルのソースコードとの差異を指摘される等の不都合が発生し得るからである。
以上のＳ７０１からＳ７０７までの処理により、デバイス２０４側でテストを実行する準備が完了する。
【００１９】
以下、Ｓ７０８からＳ７２１までの処理は、デバイス２０４のＣＰＵ４０５がプログラムに基づいて処理を実行することにより実現される処理である。
Ｓ７０８で、ＣＰＵ４０５は、ＴｅｓｔＢｒｏｋｅｒ５０２を介してクライアントＰＣ２０１のＣＰＵ３０１から受け取ったＴｅｓｔＢｕｎｄｌｅ５０３をＯＳＧｉ５０４上に
インストールし、処理をＳ７０９に進める。
Ｓ７０９で、ＣＰＵ４０５は、Ｓ７０８でインストールしたＴｅｓｔＢｕｎｄｌｅ５０３を起動させ、処理をＳ７１０に進める。
Ｓ７１０で、ＣＰＵ４０５は、ターゲットクラス群６０２から渡された情報８０９を基に、テストケースクラス群６００におけるテストケースのコール順番をソートし、処理をＳ７１１に進める。
【００２０】
以下、ＣＰＵ４０５によるテストケースの実行順序の決定方法について、図１０、１１を用いて説明する。
図１０は、本実施形態におけるターゲットクラス、生成元クラス及びテストケースの記述の一例を示す図である。
図１０に示される、ＣｌａｓｓＡＴｅｓｔＣａｓｅ１０００内のｔｅｓｔＡ１００６は、ＣｌａｓｓＡ１００３に対するテストケースである。同様に、ＣｌａｓｓＢＴｅｓｔＣａｓｅ１００１内のｔｅｓｔＢ１００７、ＣｌａｓｓＣＴｅｓｔＣａｓｅ１００２内のｔｅｓｔＣ１００８は、各々ＣｌａｓｓＢ１００４、ＣｌａｓｓＣ１００５に対するテストケースである。
図１０では、ＣｌａｓｓＣ１００５は、Ａｃｔｉｖａｔｏｒクラスからインスタンス生成される記載となっている。Ａｃｔｉｖａｔｏｒクラスは、ＯＳＧｉ５０４上で動作するアプリケーションが起動した際に、ＣＰＵ４０５により最初に生成されるクラスであり、アプリケーション内のインスタンス生成における起点クラスとなる。ＣｌａｓｓＢ１００４は、ＣｌａｓｓＣ１００５からインスタンス生成される記載となっている。同様に、ＣｌａｓｓＡ１００３は、ＣｌａｓｓＢ１００４からインスタンス生成される記載となっている。
図１１は、図１０のターゲットクラス、生成元クラス、テストケースの関係をまとめた図である。
図１１の１１００は、ターゲットクラスと、生成元クラスとの関係を示している。
図１１の１１０１は、ターゲットクラスと、テストケースとの関係を示している。
つまり、ＣｌａｓｓＡ１００３のインスタンス生成はＣｌａｓｓＢ１００４、ＣｌａｓｓＢ１００４のインスタンス生成はＣｌａｓｓＣ１００５、ＣｌａｓｓＣ１００５のインスタンス生成はＡｃｔｉｖａｔｏｒクラスである。Ａｃｔｉｖａｔｏｒクラスは起点クラスであるため、ＣＰＵ４０５によるインスタンスの生成順序はＣｌａｓｓＣ１００５、ＣｌａｓｓＢ１００４、ＣｌａｓｓＡ１００３の順となる。したがって、ＣＰＵ４０５は、ＣｌａｓｓＣ１００５をテストするｔｅｓｔＣ１００８、ＣｌａｓｓＢ１００４をテストするｔｅｓｔＢ１００７、ＣｌａｓｓＡ１００３をテストするｔｅｓｔＡ１００６の順にテストケースを実行すればよい。ＣＰＵ４０５は、この順番を保持し、順次テストを実行する。
【００２１】
Ｓ７１１で、ＣＰＵ４０５は、Ｓ７１０でソートした順番でテストケースを実行し、処理をＳ７１２に進める。
Ｓ７１２で、ＣＰＵ４０５は、テストケース内でターゲットクラスのインスタンスが取得できたか否かを判断し、取得できたと判断した場合、処理をＳ７１３に進める。一方、Ｓ７１２で、ＣＰＵ４０５は、テストケース内でターゲットクラスのインスタンスを取得できなかったと判断した場合、処理をＳ７１４に進める。
より具体的な例について、上述した図８及び図９を用いて説明する。
ＣＰＵ４０５は、テストケースｔｅｓｔＡ８０１を実行する際、テストケースクラスＣｌａｓｓＡＴｅｓｔＣａｓｅの親クラスであるＴｅｓｔＣａｓｅ９００に記述されているｇｅｔＩｎｓｔａｎｃｅメソッド９０１をコールする。更に、ＣＰＵ４０５は、ｇｅｔＩｎｓｔａｎｃｅメソッド９０１内で、ＴｅｓｔＡｇｅｎｔ６０１のｇｅｔＩｎｓｔａｎｃｅメソッドをコールする。ＣＰＵ４０５は、ＣｌａｓｓＡを生成した際、ＴｅｓｔＡｇｅｎｔ６０１のｓｅｔＴｅｓｔＩｎｆｏ（）からＣｌａｓｓＡ自身のインスタンスを第１引数で受け取る。ＣＰＵ４０５は、ＣｌａｓｓＡ自身のインスタンスが存在する場合、インスタンスをテストケースｔｅｓｔＡ８０１側に返却する。一方、ＣＰＵ４０５は、インスタンスが存在しない場合、後述するｄｅｌａｙＴｅｓｔＣａｓｅメソッド９０２にターゲットクラスとテストケース名とを登録し、テストケースｔｅｓｔＡ８０１側にｎｕｌｌを返却する。
【００２２】
Ｓ７１３で、ＣＰＵ４０５は、Ｓ７１２で取得したインスタンスを用いてテストケースｔｅｓｔＡ８０１を実行し、テストケースを終了させると処理をＳ７１５に進める。
Ｓ７１４で、ＣＰＵ４０５は、上述のｄｅｌａｙＴｅｓｔＣａｓｅメソッド９０２をｇｅｔＩｎｓｔａｎｃｅメソッド９０１経由で呼び出す。更に、ＣＰＵ４０５は、ハッシュテーブルｄｅｌａｙＴｅｓｔＣａｓｅＴａｂｌｅ９０５に、ターゲットクラスと、テストケース名とを登録し、処理をＳ７１３に進めテストケースを終了させる。
Ｓ７１５で、ＣＰＵ４０５は、ＴｅｓｔＣａｓｅ９００で遅延登録したテストケースがあるか否かを判断し、遅延登録したテストケースがあると判断した場合、処理をＳ７１６に進める。一方、Ｓ７１５で、ＣＰＵ４０５は、遅延登録したテストケースがないと判断した場合、処理をＳ７１７に進める。より具体的には、Ｓ７１４で、ＣＰＵ４０５によりｄｅｌａｙＴｅｓｔＣａｓｅメソッド９０２がコールされたテストケースが、遅延登録したテストケースに該当する。各テストケースの実行終了後に、ＣＰＵ４０５は、遅延登録したテストケースがあるか否かを判断するｃｈｅｃｋＳｔａｒｔｉｎｇＴｅｓｔＣａｓｅメソッド９０３を呼び出す。ＣＰＵ４０５は、ハッシュテーブルｄｅｌａｙＴｅｓｔＣａｓｅＴａｂｌｅ９０５に登録されているターゲットクラスが、現時点のＴｅｓｔＡｇｅｎｔ６０１内にインスタンスとして保持されているか否かを確認する。なお、ＣＰＵ４０５は、遅延登録したターゲットクラスと、テストケース名とを保持しているハッシュテーブルｄｅｌａｙＴｅｓｔＣａｓｅＴａｂｌｅ９０５を基に、ＴｅｓｔＡｇｅｎｔ６０１のｇｅｔＩｎｓｔａｎｃｅメソッドで上記の取得確認を行う。ＣＰＵ４０５は、インスタンスを取得できた場合、現時点でターゲットクラスに対するテストケースを実行できるため、ｒｅｔｒｙＴｅｓｔＣａｓｅメソッド９０４を呼び出し、対象のテストケースを再度実行する。一方、ＣＰＵ４０５は、インスタンスを取得できなかった場合、現時点で遅延登録したテストケースを実行できないため、何もせずにｃｈｅｃｋＳｔａｒｔｉｎｇＴｅｓｔＣａｓｅメソッド９０３の処理を終了する。
【００２３】
Ｓ７１６で、ＣＰＵ４０５は、Ｓ７１５の処理で遅延登録したテストケースがあり、インスタンスがＴｅｓｔＡｇｅｎｔ６０１で保持されている場合は、前述の通り、遅延登録したテストケースを実行し、処理をＳ７１７に進める。より具体的には、Ｓ７１６で、ＣＰＵ４０５は、前記テストケース名に対応するクラスのインスタンスを保持していれば、前記インスタンスを用いて前記テストケースを実行する。なお、Ｓ７１６におけるＣＰＵ４０５の処理は、遅延テストケース実行処理の一例である。
Ｓ７１７で、ＣＰＵ４０５は、Ｓ７１０でソートしたテストケースが全て終了したか否かを判断し、終了したと判断した場合は、処理をＳ７１８に進める。一方、Ｓ７１７で、ＣＰＵ４０５は、遅延登録したテストケースを含め、未実行のテストケースが存在すると判断した場合は、処理をＳ７１１に進め、未実行のテストケースを実行する。なお、ＣＰＵ４０５は、遅延登録したテストケースを含め、未実行のテストケース情報を管理している。
Ｓ７１８で、ＣＰＵ４０５は、ＴｅｓｔＢｕｎｄｌｅ５０３を停止し、処理をＳ７１９に進める。
Ｓ７１９で、ＣＰＵ４０５は、ＴｅｓｔＢｕｎｄｌｅ５０３をアンインストールし、処理をＳ７２０に進める。
Ｓ７２０で、ＣＰＵ４０５は、上記で実行したテスト結果をレポートとして出力し、処理をＳ７２１に進める。テスト結果、レポートの形式及び生成方法は、公知の技術であるため詳細な説明を省略する。
Ｓ７２１でＣＰＵ４０５は、Ｓ７２０で出力したテストレポートをクライアントＰＣ２０１へ送信し、処理をＳ７２２へ進める。
【００２４】
以下、Ｓ７２２からＳ７２３までの処理は、クライアントＰＣ２０１のＣＰＵ３０１がプログラムに基づいて処理を実行することにより実現される処理である。
Ｓ７２２で、ＣＰＵ３０１は、Ｓ７２１でデバイス２０４のＣＰＵ４０５により送信されたテストレポートを受信し、処理をＳ７２３に進める。
Ｓ７２３で、ＣＰＵ３０１は、Ｓ７２２で受信したテストレポートをＴｅｓｔＦｒａｍｅｗｏｒｋ５０１で表示し、処理を終了する。なお、ＴｅｓｔＦｒａｍｅｗｏｒｋ５０１の表示形式や方法については、公知の技術であるため、詳細な説明を省略する。
【００２５】
＜その他の実施形態＞
本実施形態は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【００２６】
以上、上述した実施形態の処理によれば、ＯＳＧｉ上で動作中のアプリケーションに対
して、システムテストをプログラマブルに行うことができる。
【００２７】
以上、本発明の好ましい形態について詳述したが、本実施形態は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【図１】
2014048836.tif 000003
【図２】
2014048836.tif 000004
【図３】
2014048836.tif 000005
【図４】
2014048836.tif 000006
【図５】
2014048836.tif 000007
【図６】
2014048836.tif 000008
【図７】
2014048836.tif 000009
【図８】
2014048836.tif 000010
【図９】
2014048836.tif 000011
【図１０】
2014048836.tif 000012
【図１１】
2014048836.tif 000013