(57)【要約】【課題】  画像形成装置ではジョブ動作などのプラットフォーム処理がアプリケーションの処理とは非同期に実行されるため、自動テストのためのフレームワークを用いてリソースのリークを検出しようとしても、リソースリークしている処理を特定することが難しいという問題があった。【解決手段】  プラットフォーム処理が存在する場合はプラットフォーム処理が完了してからテストケース実行を行うように制御する。また、テストケース実行前後のリソースの変化量からリークの疑いのある処理を絞り込み、リークの疑いのあるテストケースをデバッグ用のファームウェアで再実行する。【選択図】  図８
2013149026.tif 000002
【特許請求の範囲】
【請求項１】
提供されたアプリケーションをインストールして実行可能な装置と通信可能な情報処理装置であって、
前記装置で実行するためのアプリケーションを作成する指示を受けたことに応じて、前記アプリケーションの機能を実現するモジュールと、前記モジュールにより実現される機能をテストするためのテストケースと、を含むテストアプリケーションを作成する作成手段と、
作成された前記テストアプリケーションを前記装置へ送信するとともに、前記テストケースの処理の開始を指示する指示手段と、
前記指示の後、前記テストアプリケーションの動作中におけるリソース使用量と、前記テストケースの処理を開始した時間を含む時間情報と、を取得する取得手段と、
取得された前記リソース使用量と前記時間情報とを基に、テストケースを開始する時点において使用したリソース使用量と、該テストケースを終了する時点において使用したリソース使用量との差異を各テストケース毎に認識できるようなリソースモニタを表示する表示手段と、を有する情報処理装置。
【請求項２】
前記表示手段により表示されるリソースモニタは、テストケースを処理している際に使用したリソース使用量をテストケースの実行順毎に時系列で表示することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記装置はスキャナユニット、および／またはプリントユニットを含む画像処理ユニットを備えた画像形成装置であって、
前記リソース使用量とは、前記画像処理ユニットを制御するためのアプリケーションを動作させる際に使用したメモリの使用量であることを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記取得手段は、前記画像処理ユニットを利用するジョブの実行状況に関するジョブ情報を取得し、
前記表示手段は、取得された前記ジョブ情報と前記リソース使用量と前記時間情報とを基に、テストケースを処理している際に使用したリソース使用量と、前記ジョブの実行状況との関係性が認識できるようなリソースモニタを表示することを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記作成手段は、取得された前記リソース使用量と前記時間情報とを基にリークの疑いがあるテストケースが存在すると判定された場合は、リークの疑いがあるテストケースを含みリークの疑いがないテストケースを含まないデバッグ用アプリケーションを作成し、
前記指示手段は、作成された前記デバッグ用アプリケーションと、前記アプリケーションの動作中におけるデバッグ情報を取得するためのデバッグモードへ切り替えるための要求と、を前記装置へ送信するとともに、再度、テスト実行を指示することを特徴とする請求項１乃至４の何れか１項に記載の情報処理装置。
【請求項６】
提供されたアプリケーションをインストールして実行可能な装置と通信可能な情報処理装置であって、
前記装置で実行するためのアプリケーションを作成する指示を受けたことに応じて、前記アプリケーションの機能を実現するモジュールと、前記モジュールにより実現される機能をテストするためのテストケースと、を含むテストアプリケーションを前記装置へ送信するとともに、前記テストケースの処理の開始を指示する指示手段と、
前記指示の後、テストケースを開始する時点において使用したリソース使用量と、該テストケースを終了する時点において使用したリソース使用量との差異を各テストケース毎に認識できるようなリソースモニタを表示する表示手段と、を有する情報処理装置。
【請求項７】
提供されたアプリケーションをインストールして実行可能な装置と通信可能な情報処理装置を制御する制御方法であって、
作成手段は、前記装置で実行するためのアプリケーションを作成する指示を受けたことに応じて、前記アプリケーションの機能を実現するモジュールと、前記モジュールにより実現される機能をテストするためのテストケースと、を含むテストアプリケーションを作成し、
指示手段は、作成された前記テストアプリケーションを前記装置へ送信するとともに、前記テストケースの処理の開始を指示し、
取得手段は、前記指示の後、前記テストアプリケーションの動作中におけるリソース使用量と、前記テストケースの処理を開始した時間を含む時間情報と、を取得し、
表示手段は、取得された前記リソース使用量と前記時間情報とを基に、テストケースを開始する時点において使用したリソース使用量と、該テストケースを終了する時点において使用したリソース使用量との差異を各テストケース毎に認識できるようなリソースモニタを表示することを特徴とする制御方法。
【請求項８】
請求項７に記載の制御方法を情報処理装置に実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションを作成することが可能な情報処理装置、制御方法、およびそのプログラムに関する。
【背景技術】
【０００２】
従来、画像形成装置においては、リアルタイムＯＳ上にさらに別の組み込みシステム向けの実行環境（例えばＪａｖａ（登録商標）など）を構築することを可能にしている。さらには、画像形成装置の制御を行うことのできるアプリケーションを外部からダウンロードして、後から機能を追加可能なアプリケーションプラットフォームが搭載されるようになった。
【０００３】
また、このようなアプリケーションプラットフォーム上で動作するアプリケーションを開発するための開発環境も提供されている。たとえば、アプリケーションのビルドからテスト結果の取得まで自動的に行い、アプリケーションプラットフォームの状態を記憶して、デバッグ作業を容易にするような仕組みが特許文献１に開示されている。
【０００４】
また、このような画像形成装置では、アプリケーションプラットフォーム上で動作するアプリケーションのデバッグのためのデバッグ用ファームウェアも提供されている。デバッグ用ファームウェアを使うと、アプリケーションの実行速度は著しく遅くなるが、より詳細な内部情報を取得可能になるため、詳細な解析に有用である。例えば、ヒープダンプに関する情報を取得することが可能である。
【０００５】
一方、ネットワークを介してデバイスと通信し、デバイスのリソース使用量（例えばメモリ使用量など）をリアルタイムに監視するためのツールが存在する。このようなツールと前述の開発環境を組み合わせることで、アプリケーションの自動テストを行いながらリソースの監視を行うことができるようになり、一連の自動テストを実行した時のリソースリークの検出が可能となる。ここで、リソースリークとはプログラム上の欠陥の一種で、開放すべきリソースを解放しない欠陥のことである。例えば、ファイルを使い終わってもファイルをクローズしないファイルディスクリプタリークや、メモリを使い終わってもメモリを解放しないメモリリークなどがある。リソースリークが存在するとそのうちリソースが枯渇してアプリケーションが動作不能な状態に陥る。またメモリリークの原因分析を行うためにヒープダンプを用いて詳細なデータを取得して原因を絞り込む技術が公開されている（特許文献２）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特願２００８−５４５６８８
【特許文献２】特開２００６−３５０８７６
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、前述の方法ではリソースリークが発生しているという事実は確認できても、どのようなテストを実行した時にリソースのリークが発生しているのかが認識しづらいという問題があった。
【０００８】
また、アプリケーションのテスト実行中にアプリケーションの処理とは非同期にジョブ実行などが実行されることがある。このため、プラットフォーム要因で一時的にリソースを消費しているだけなのかアプリケーションがリソースリークしているのかが判別しづらいという問題もあった。
【０００９】
また、デバッグ用ファームウェアで解析を行う場合、画像形成装置のＣＰＵやメモリは一般的なＰＣと比べて貧弱であるため、実行に非常に時間がかかり、常時デバッグ用ファームウェアを利用してデバッグを行うことは現実的でないという問題があった。
【００１０】
本願発明の目的は、上述した課題の内、少なくとも１つの課題を解決するための情報処理装置を提供することにある。
【課題を解決するための手段】
【００１１】
本発明の一実施形に係る情報処理装置は、提供されたアプリケーションをインストールして実行可能な装置と通信可能な情報処理装置であって、前記装置で実行するためのアプリケーションを作成する指示を受けたことに応じて、前記アプリケーションの機能を実現するモジュールと、前記モジュールにより実現される機能をテストするためのテストケースと、を含むテストアプリケーションを作成する作成手段と、作成された前記テストアプリケーションを前記装置へ送信するとともに、前記テストケースの処理の開始を指示する指示手段と、前記指示の後、前記テストアプリケーションの動作中におけるリソース使用量と、前記テストケースの処理を開始した時間を含む時間情報と、を取得する取得手段と、取得された前記リソース使用量と前記時間情報とを基に、テストケースを開始する時点において使用したリソース使用量と、該テストケースを終了する時点において使用したリソース使用量との差異を各テストケース毎に認識できるようなリソースモニタを表示することを特徴とする。
【発明の効果】
【００１２】
本発明によれば、テストケースとリソースの変化の対応をグラフィカルに表示することにより、どのテストケースでリソースリークが発生しているのかを判別することが容易になる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施形態に係る画像形成装置の内部構成の一例を示すブロック図である
【図２】本発明の画像形成装置の一例である画像形成装置１のＨＤＤ１０４に記憶されたソフトウェア構造図である
【図３】画像形成装置１とネットワークで接続された開発用ＰＣ３００のハードウェア構成を示す図である
【図４】本発明の統合開発システムの一例である統合開発システム４００のソフトウェア構成図である
【図５】統合開発環境システム４００を利用してテストを行う場合の画像形成装置１のソフトウェアブロック図である
【図６】テスト用アプリケーション５０２の構成を示すブロック図である
【図７】表示部３０６に表示される統合開発環境システム４００の操作画面の一例である
【図８】図７（ａ）のプルダウンメニュー７０３の何れかが選択された場合の組み込みアプリケーション開発支援ツール４０５の処理の流れを示すフローチャートである
【図９】図８のフローチャートを実行後の組み込みアプリケーション開発支援ツール４０５の処理の流れを示すフローチャートである
【図１０】デバイス状態監視要求を受けた際のテストブローカ内のモジュールの処理の流れを示すフローチャートである
【図１１】テスト用アプリケーションを受信した際のテストブローカの処理の流れを示したフローチャートである
【図１２】デバッグモードへの切り替え要求を受けた際のテストブローカの処理の流れを示したフローチャートである
【図１３】画像形成装置の電源を入れた際の起動プログラム２０７の処理の流れを示すフローチャートである
【発明を実施するための形態】
【００１４】
以下、図面を参照して本発明の実施の形態を詳しく説明する。尚、以下の実施の形態は特許請求の範囲に係る発明を限定するものでなく、また実施の形態で説明されている特徴の組み合わせの全てが発明の解決手段に必須のものとは限らない。
【００１５】
以下、本発明の実施の形態について図面を参照して詳細に説明する。図１は、本発明の実施形態に係る画像形成装置の内部構成の一例を示すブロック図である。
【００１６】
図１に示す画像形成装置１は、基本的な構成として、画像形成装置１内の各部を制御するコントローラユニット１００と、操作部１１２と、スキャナ部１２３と、プリンタ部１２５とを備える。操作部１１２は、例えば、数字を入力するためのテンキーや処理の実行を行うためのスタートキーなどのハードキーや液晶タッチパネルで構成され、ユーザが画像形成装置１を操作するためのユーザインタフェースを提供する。操作部１１２のタッチパネルに表示される各設定項目を表すアイコンやボタン（もしくはハードキー）をタッチ（押下）することで、画像形成装置１に設定や情報の入力を行うことが可能である。
【００１７】
スキャナユニットであるスキャナ部１２３は、原稿等の画像を画像データとして読み取る。プリントユニットであるプリンタ部１２５は、記録用紙を搬送し、その記録用紙に画像データを可視画像として印刷する。コントローラユニット１００は、バス１２２を介してスキャナ部１２３に接続され、またバス１２４を介してプリンタ部１２５に接続される。また、コントローラユニット１００は、ＬＡＮ１１３や公衆回線（ＷＡＮ）１１４や無線１１５を介して他の機器に接続して、画像情報やデバイス情報の入出力制御を行う。なお、画像処理ユニットとしてスキャナユニットとプリンタユニット以外のものを搭載していても良い。
【００１８】
ＣＰＵ１０１は、システム全体を制御するコントローラである。ＲＡＭ１０２は、ＣＰＵ１０１が動作するためのシステムワークメモリであり、画像データを一時記憶するための画像メモリでもある。ＲＯＭ１０３はブートＲＯＭである。ＲＯＭ１０３には、システムのブートプログラムが格納されている。ＨＤＤ１０４は、ハードディスクドライブであり、システムソフトウェアや画像データ、後述する通信部１１１が有するすべての無線通信に関する情報（無線通信の仕様）を格納する。
【００１９】
画像形成装置では、使用したい機能を実装したアプリケーションをインストールすることで機能を増やすことができる。アプリケーションには、アプリケーションの機能を実現するモジュールが含まれエチル。アプリケーションのインストールにより、画像形成装置上で各種機能を動かすためのアプリケーションプログラムがＲＡＭ１０２やＨＤＤ１０４に記憶される。
【００２０】
操作部Ｉ／Ｆ１０６は、ユーザインターフェース（ＵＩ）である操作部１１２との間のインターフェース部であり、操作部１１２に表示すべきデータを操作部１１２に対して出力する。また、操作部１１２からユーザが入力した情報を、ＣＰＵ１０１に伝える役割を行う。Ｎｅｔｗｏｒｋ部１０９は、ＬＡＮ１１３に接続され、情報の入出力を行う。ＭＯＤＥＭ１１０は、公衆回線１１４に接続され、情報の入出力を行う。
【００２１】
通信部１１１は、不図示のアンテナを介して無線（ＷＩＲＥＬＥＳＳ）１１５に接続され、情報の入出力を行う。また、通信部１１１は、複数種類の無線通信を行うことが可能である。上記各デバイスがシステムバス１０７上に配置される。イメージバス（ＩｍａｇｅＢｕｓ）Ｉ／Ｆ１０５は、システムバス１０７と、画像データを高速で転送する画像バス１０８とを接続し、データ構造を変換するバスブリッジである。画像バス１０８は、ＰＣＩバスまたはＩＥＥＥ１３９４等で規定されるバスである。画像バス１０８上に配置される各デバイスにおいて、ラスターイメージプロセッサ（ＲＩＰ）１１６は、ＰＤＬコードをビットマップイメージに展開する。デバイスＩ／Ｆ部１１７は、スキャナ部１２３またはプリンタ部１２５をコントローラユニット１００に接続し、画像データの同期系／非同期系の変換を行う。
【００２２】
スキャナ画像処理部１１８は、入力画像データに対して補正、加工、または編集を行う。プリンタ画像処理部１１９は、プリント出力画像データに対して、プリンタ部１２５に合った補正、解像度変換等を行う。画像回転部１２０は、画像データの回転を行う。画像処理部１２１は、画像データに対する、ＪＰＥＧ、ＪＢＩＧ、ＭＭＲ、ＭＨ等の圧縮伸張処理や、ＰＤＦ、ＴＩＦＦ、ＯＣＲ、暗号化等のフォーマット変換処理を行う。
【００２３】
図２は本発明の画像形成装置の一例である画像形成装置１のＨＤＤ１０４に記憶されたソフトウェア構造図である。ＣＰＵ１０１により、これらの構成を実現するためのプログラムが実行されることによって各種機能が実現される。
【００２４】
２０１は、ＯＳ層であり、一般的にはリアルタイムＯＳが使用されるが、昨今ではＬｉｎｕｘ（登録商標）等の汎用ＯＳが使用されることもある。２０２は、Ｊａｖａ（登録商標）に代表される仮想マシンであり、アプリケーションの実行環境を提供するものである。２０３は、アプリケーションフレームワークであり、アプリケーションのライフサイクルを管理する機能を提供するものである。２０４は、インストーラサービスであり、後述のアプリケーションＡ，Ｂなど複数のアプリケーションを、アプリケーションフレームワーク２０３に登録することでインストール処理を行うものである。
【００２５】
２０５，２０６は、インストーラサービス２０４によってインストールされたアプリケーションであり、画像形成装置１上で様々な機能提供するものである。アプリケーション２０５，２０６は図外のＩ／Ｆを使用して、操作部１１２を介してユーザとやり取りを行うことが可能である。また、Ｎｅｔｗｏｒｋ部１０９を介して、ＰＣなどからデータを受信し、プリンタ部１２５を使って印刷することも可能である。なお、インストーラサービス２０４はＷｅｂアプリを備えており、ＰＣからブラウザでアクセスすることにより、ブラウザ上にアプリケーションのインストールページが表示される。インストールページには、インストールするアプリケーションを指定するためのテキストボックスおよびインストールボタンが備えられている。インストールページにてアプリケーションファイルを指定してインストールボタンを押すことによりアプリケーションファイルがＰＣからインストーラサービス２０４に転送される。インストーラサービス２０４はアプリケーションファイルを受信するとアプリケーションフレームワーク２０３にアプリケーションファイルを登録してインストールを行う。
【００２６】
また、２０２は通常利用される通常用仮想マシンとアプリケーションの詳細デバッグ時に利用されるデバッグ用仮想マシンの２種類が存在する。通常用仮想マシンはアプリケーションを実行できるだけであるが、デバッグ用仮想マシンは、より詳細なデバッグ情報を取得できる。ただし、デバッグ用仮想マシンを利用するとアプリケーションの動作速度は著しく低下する。ここで、デバッグ情報とは、具体的には仮想マシン上に存在するオブジェクトの数やそれぞれの参照関係を示す情報のことである。なお、オブジェクトとは、クラスをメモリ上に展開したインスタンスのことであり、クラスとは属性（データ）と操作（メソッド）の集合を定義したものである。アプリケーションは複数のクラスを定義することにより実装され、複数のオブジェクトが相互作用することにより所望の機能を実現する。
【００２７】
また、相互作用するオブジェクト間の関連は仮想マシンの内部的に参照情報として保持されている。どこからも参照されていないオブジェクトはガベージコレクションという仕組みにより自動的に解放される。しかし、アプリケーションの欠陥により不要な参照が残ったままになっていると、メモリが解放されないことになり、そのうちメモリが枯渇しアプリケーションが動作不能になることがある。デバッグ用仮想マシンを使うことにより、画像形成装置上に存在するオブジェクトの数を確認することができるようになるため、解放されるべきオブジェクトが残っていないかを容易に確認することができるようになる。通常用仮想マシンとデバッグ用仮想マシンは排他的に動作し、切り替えて動作させることが可能である。起動プログラム２０７は、起動する仮想マシン切り分けるためのものであり、起動モードに応じた仮想マシンを起動する。起動モードには通常モードとデバッグモードがあり、通常モード時は通常用仮想マシンが起動し、デバッグモードではデバッグ用仮想マシンが起動するように制御する。デバッグ用仮想マシンにより、アプリケーション動作中におけるデバッグ情報を取得することが可能となり、例えば、ヒープダンプの調査を行うことが可能となる。ヒープダンプについては後述する。
【００２８】
図３は、画像形成装置１とネットワークで接続され通信可能な情報処理装置である開発用ＰＣ３００のハードウェア構成を示す図である。画像形成装置用アプリケーションの開発を行う場合、通常、開発用ＰＣ３００にて統合開発環境を動作させてプログラム作成・テスト・デバッグなどを行う。また、アプリケーションのテストを行う場合は、開発ＰＣ３００から画像形成装置１００にＮｅｔｗｏｒｋ部１０９経由でアプリケーションをインストールして画像形成装置１上でアプリケーションを動作させてテストを行う。
【００２９】
ＣＰＵ３０１は開発ＰＣ３００上の各処理をつかさどる中央演算装置である。ＲＯＭ３０２は開発ＰＣ３００の各処理に関わるプログラムやデータを記憶する。ＲＡＭ３０３は、開発ＰＣ３００の各処理に関わる一時的なデータを記憶する。ＨＤＤ３０４は、開発ＰＣ３００の各処理に関わるプログラムやデータ、および一時的なデータ、本発明に関わるプログラムモジュールが格納される。入力装置３０５は、開発ＰＣ３００への指示入力を受け付けるキーボードやポインティングデバイスである。表示部３０６は、開発ＰＣ３００の動作状況や、開発ＰＣ３００上で動作する各プログラムが出力する情報を表示する。ネットワークＩ／Ｆ３０７は、ネットワーク経由でＬＡＮおよびインタネットに接続し、外部と情報交換を行う。それらの要素がシステムバス３０８により結び付き、データをやりとりしている。
【００３０】
図４は本発明の統合開発システムの一例である統合開発システム４００のソフトウェア構成図である。統合開発システム４００は、開発ＰＣ３００上で動作するアプリケーション開発のためのシステムである。統合開発環境システム４００は、統合開発基盤４０１と、統合開発基盤４０１に利用される内部ツールＡ４０２並びに外部ツールＢ４０４と連携する内部ツールＢ４０３を有する。さらには、これら内部ツールと同様の位置づけで組み込みアプリケーション開発支援ツール４０５を有する。
【００３１】
統合開発環境システム４００は、例えば、Ｅｃｌｉｐｓｅが利用できるが、これに限定されない。なお、Ｅｃｌｉｐｓｅとは、オープンソースの統合ソフトウェア開発環境であり、ソフトウェア開発の共通プラットフォームである。Ｅｃｌｉｐｓｅは、２種類のツールを利用することで様々な機能を提供する。Ｅｃｌｉｐｓｅにプラグインとして登録・提供されている内部ツールと、Ｗｉｎｄｏｗｓ（登録商標）、ＵＮＩＸ（登録商標）などが提供するデバッガやコンパイラといったＥｃｌｉｐｓｅ内には存在しない外部ツールとの２種類である。
【００３２】
統合開発基盤４０１は、開発しているアプリケーションの管理や各ツールを連携させるためのインターフェースなどを含んでいる。外部ツールの例としては、Ｊａｖａ（登録商標）のコンパイルやデバッグを行うために用いられるＪＤＫ（Ｊａｖａ  Ｄｅｖｅｌｏｐｍｅｎｔ  ｋｉｔ）がある。内部ツールは、統合開発基盤４０１が提供するインターフェースを介して、外部ツールの機能を利用することもできる。図４で示している統合開発環境システム４００が持つ内部ツールや外部ツールの構成などは、１つの例にすぎず、これに限定されない。
【００３３】
組み込みアプリケーション開発支援ツール４０５は、画像形成装置との各種要求の通信を行い、後述する４０６〜４１０の各手段を使用して、画像形成装置で動作可能なアプリケーションの生成やテスト支援機能を実現する。ここで、テスト支援機能とは、テスト用アプリケーション生成、実行、テスト結果の表示までを自動で行うことができる機能のことである。アプリケーション開発者は、テストケースを実装することで、画像形成装置上において自動でテストが実行され、テストの実行結果を得ることができるようになる。テストケースには１つ以上のテストプログラムが含まれており、個々のテストプログラムはメソッドとして実装される。操作手段４０６は、開発しているアプリケーションを画像形成装置へインストールする機能を有する。その他、画像形成装置上で動作しているアプリケーションの開始、停止、デバッグ機能も有する。
【００３４】
アプリケーション生成手段４０７は、リリース用のアプリケーションを生成する機能や、テスト用のプログラムを含んだテスト用アプリケーションを生成する機能を有する。テスト用アプリケーションには、機能を実現するためのモジュールと、その機能をテストするためのテストケースの２つが少なくとも含まれる。リソースモニタ手段４０８は、画像形成装置から送られてくるメモリ情報を基に画像形成装置のメモリ状況をグラフ表示する機能を有する。また、後述するテストケースの実行状況を受信してグラフにテストケースの開始時点がわかるように図示する機能も有する。さらに、画像形成装置上のジョブ動作状況も合わせて表示する機能を有する。
【００３５】
リソース異常検出手段４０９は、テストケースの実行開始時および終了時の使用リソース量の差を計算してリソースリークの疑いのあるテストケースを抽出する機能を有する。再テスト実行手段４１０は、画像形成装置に対して起動モードの切り替え要求を出す機能を有する。また、アプリケーション生成手段４０７を使ってメモリリークの疑いのあるテストケースのみを含むテスト用アプリケーションを作成し、デバッグモードに切り替えた画像形成装置でテスト再実行を行う機能を有する。
【００３６】
ワークスペース４１１は、統合開発環境システム４００が参照するものであり、プロジェクトと呼ばれる単位でアプリケーションやテストアプリケーションを管理する領域である。ワークスペース４１１には複数のプロジェクトが格納されても構わない。ここで、プロジェクト４１２は、マニフェストファイル４１３、ソースファイル４１４から構成される。マニフェストファイル４１３とは、アプリケーションの持つ各種情報が記載されたファイルであり、ソースファイル４１４はアプリケーションの機能を実現するためのプログラムファイルである。
【００３７】
統合開発環境システム４００を使ってアプリケーションのテストを行いたい場合は、テスト用のプロジェクトを作成する。テスト用のプロジェクト４１５は、テスト設定ファイル４１６、マニフェストファイル４１３、ソースファイル４１４から構成される。テスト設定ファイル４１６には、テスト対象のアプリケーションのプロジェクト情報が保存されている。テスト対象のアプリケーションはテスト用のプロジェクトを作成する時にユーザによって指定される。テスト用のプロジェクト４１５に含まれるソースファイルは、一つ以上のアプリケーションをテストするためのプログラム（テストケース）を含む。テストを実行する際は、テスト対象アプリケーションのプロジェクトとテスト用プロジェクトとから一つのテスト用アプリケーションを生成する。生成したテスト用アプリケーションを画像形成装置上で動作させてテストを実行する。
【００３８】
図５は、統合開発環境システム４００を利用してテストを行う場合の画像形成装置１のソフトウェアブロック図である。図２の状態の画像形成装置１に対してアプリケーション開発者がインストーラサービス２０４経由でテストブローカ５０１をインストールすることで統合開発環境システム４００を利用したテストを行うことができるようになる。テストブローカ５０１は、開発ＰＣ３００から、テスト用アプリケーション５０２を受信してテストを実行したり、テスト結果を開発ＰＣ３００に送信したり、テスト完了後にテスト用アプリ５０２をアンインストールしたりするためのモジュールである。
【００３９】
本実施例のシステムにおいては、ＪＵｎｉｔなどのテストフレームワークを用いる場合と同様で、テストケースの実行順序はランダムになっている。そのため、従来のリソースモニタでメモリ状況を監視しながら自動テストを実行しても、どのテストケースを実行している時にリークが発生しているか特定することは困難であった。また、テストブローカ５０１はデバイス監視モジュール５０３を含んでいる。デバイス監視モジュール５０３は画像形成装置上のメモリの使用状況やジョブの状況を監視して統合開発環境システム上に情報を定期的に送信する機能も持つ。テスト用アプリケーション５０２は、ユーザが開発したアプリケーションとテストのためのプログラムを含むテストのためのアプリケーションであることはご理解頂けると思う。
【００４０】
図６は、図５におけるテスト用アプリケーション５０２の構成を示すブロック図である。テスト用アプリケーション５０２は、アプリケーション６０１とテストケース６０２とテストエージェント６０３とアプリケーション情報６０４から構成される。アプリケーション６０１は開発者が開発しているアプリケーションの実体であり、アプリケーションの機能を実現するモジュールでもあり、テスト対象アプリケーションのプロジェクト４１２に含まれるソースファイルから生成される。このアプリケーションは、画像形成装置１上で動作し、ユーザに対して、認証機能を提供したり、スキャナやプリンタを使った機能を提供したりする。テストケース６０２はアプリケーション６０１をテストするためのプログラムであり、アプリケーション６０１により実現される機能をテストするためのテストケースであり、テスト用プロジェクト４１５に含まれるソースファイルから生成される。
【００４１】
テストケースの例としては、
・プリント設定の組み合わせを判定するメソッドにていろいろな設定の組み合わせでメソッドを実行し正しい判定が行われるかをチェックするテストケース
・ジョブ投入メソッドを実行した時にメソッドが正常終了するかをチェックするテストケース
などがあげられる。一般にアプリケーションの規模が大きくなるとテストケースの数も膨大となるため、規模の大きなアプリケーションのテストを実行するには時間がかかる。テストエージェント６０３はテストブローカ５０１から指示を受けてテストケース６０２の実行を行う。アプリケーション情報６０４は、テスト用プロジェクト４１５に含まれるマニフェストファイルであり、テスト用アプリケーションの識別情報やアプリケーション名称やバージョン情報を含んでいる。
【００４２】
図７は、表示部３０６に表示される統合開発環境システム４００の操作画面の一例である。図７（ａ）は統合開発環境システム４００のメイン画面の一例を示す図である。ソースファイル編集画面７０１では、プロジェクト内のソースファイルが表示される。プロジェクト・エクスプローラ７０２には、開発中のアプリの一覧がプロジェクトの単位で表示されている。また、入力装置３０５を介してプロジェクト・エクスプローラ７０２内のテスト用プロジェクトを選択するとプルダウンメニュー７０３が表示される。プルダウンメニューには「テスト実行」および「テスト実行とメモリリークチェック」および「テスト実行とメモリリークチェック（詳細）」の項目が表示される。
【００４３】
プルダウンメニュー７０３にて「テスト実行」が選択されると、テスト対象アプリケーションのプロジェクトおよびテスト用プロジェクトからテスト用アプリケーションを生成する。そして、画像形成装置に生成したテスト用アプリケーションを送信してテストを実行し、テストが完了するとテスト結果がテスト結果表示領域７０５に表示される。
【００４４】
またプルダウンメニュー７０３にて「テスト実行とメモリリークチェック」が選択されると、リソースモニタ画面（図７（ｂ））およびリーク候補リスト画面（図７（ｃ））が表示される。リソースモニタ画面（図７（ｂ））では、テスト実行中のメモリ状況や画像形成装置上のジョブの状況を確認することができる。グラフ表示領域７１０には画像形成装置のメモリ使用量がグラフとして表示される。ジョブ状況表示領域７１１は、画像形成装置のジョブの実行状況が表示される。ジョブが実行中の区間はバー７１２が表示される。ボタン７１４はリソースモニタ画面を閉じるためのボタンである。７１３はテストケース名であり、テストケースの実行が開始されるタイミングで縦線と合わせて描画される。
【００４５】
テストケース名および縦線が描画されるため、グラフ表示領域７１０に表示されるメモリ使用量のグラフとの対応関係が分かりやすくなる。横軸は時間を示しており、全ての領域で共通である。このためテストケース、メモリ、ジョブ状況の関係性を一目で理解することが可能である。テストケースの開始時と終了時の消費メモリ差分を計算し所定の閾値を超える場合は、メモリリークの疑いがあるためテストケース名を強調表示する。（図７（ｂ））は、テストケースを処理している際に使用したリソース使用量をテストケースの実行順毎に時系列で表示する例である。テストケースの開始時間は各テストケース毎に異なるので、このように時系列で表示することでどのテストケースの処理に問題があるかをより正確に認識することができる。ジョブ状況を表示する理由は、リークによりリソースの使用量に差異が発生しているのか、リークは発生していないがジョブの実行によって一時的にメモリが使用されているだけなのかを認識できるようにするためである。
【００４６】
また、リーク候補リスト画面（図７（ｃ））ではリソースリークの疑いのあるテストケースの一覧がリーク量とともに表示される。図７（ｃ）中の７２０はリークの疑いのある処理を実行したテストケースのメソッド名である。テストケースには複数のメソッドが実装されており、各メソッドの中でテスト対象のクラスに対するテスト処理が実装される。７２１はテストの実行前と後のメモリ使用量の差である。閉じるボタン７２２はリーク候補リスト画面を閉じるためのボタンである。
【００４７】
またプルダウンメニュー７０３にて「テスト実行とメモリリークチェック（詳細）」が選択されると、「テスト実行とメモリリークチェック」の処理を行った後に、リークの疑いのあるテストケースについてより詳細に解析を実行する。そして、リーク要因詳細リスト画面（図７（ｄ））を表示する。具体的には、画像形成装置のデバッグ用仮想マシンに切り替えて、リークの疑いのあるテストケースのみを含んだテスト用アプリケーションを実行することにより詳細な情報を取得し、結果を別ウインドウに表示する。デバッグ用仮想マシンには、メモリ内容をダンプする機能等デバッグに有用な機能が備わっているため詳細な情報を取得して解析することが可能になる。
【００４８】
７３０は、リークの疑いのある処理を実行したテストケースのメソッド名である。７３１はリークの疑いのあるオブジェクトのクラス名である。７３２はテストの実行前と後のオブジェクト数の差分である。閉じるボタン７３３はリーク要因詳細リスト画面を閉じるためのボタンである。
【００４９】
図８は、図７（ａ）のプルダウンメニュー７０３の何れかが選択された場合の組み込みアプリケーション開発支援ツール４０５の処理の流れを示すフローチャートである。
【００５０】
組み込みアプリケーション開発支援ツール４０５がプルダウンメニュー７０３の選択を検知すると、アプリケーション生成手段４０７は、Ｓ８０１にてテスト用アプリケーションを作成する。具体的には、テスト情報ファイルからテスト対象プロジェクトを特定し、テスト対象のプロジェクトに含まれるソースファイルおよびテスト用プロジェクトに含まれるソースファイルをコンパイルしてアプリケーションを作成する。
【００５１】
次にＳ８０２に進み、組み込みアプリケーション開発支援ツール４０５は、どのメニューが選択されたかを判定する。「テスト実行」が選択されたと判定された場合は、Ｓ８０５に進む。それ以外のメニューが選択されたと判定した場合はＳ８０３に進む。Ｓ８０３において、組み込みアプリケーション開発支援ツール４０５は、画像形成装置上のテストブローカ５０１にデバイス状態監視要求を送信する。次にＳ８０４に進み、リソースモニタ手段４０８が、リソースモニタ画面（図７（ｂ））およびメモリリーク候補リスト画面（図７（ｃ））を表示する。次にＳ８０５に進み、操作手段４０６がＳ８０１で生成したテスト用アプリケーションをテストブローカ５０１に送信し、テスト実行要求を送信する。テスト実行要求を受け取った画像形成装置は、テストアプリケーションに含まれるテストケースの処理を開始する。
【００５２】
次にＳ８０６において、組み込みアプリケーション開発支援ツール４０５はテストブローカ５０１からデータを受信する。次にＳ８０７に進み、組み込みアプリケーション開発支援ツール４０５は、受信したデータがテスト終了通知であったかどうかを判定する。もしテスト終了通知であった場合はＳ８２３に進む。Ｓ８２３において、リソースモニタ手段４０８はテスト結果を受信してテスト結果表示領域に結果を表示する。次にＳ８２４に進み、操作手段４０６はテスト用アプリケーションのアンインストール要求をテストブローカに送信して処理を終了する。
【００５３】
一方、Ｓ８０７にてテスト終了通知でないと判定された場合はＳ８０８に進む。Ｓ８０８において、組み込みアプリケーション開発支援ツール４０５は受信したデータがテストケース実行開始通知であったかどうかを判定する。もしテストケース実行開始通知であった場合、Ｓ８０９に進む。Ｓ８０９において、リソースモニタ手段４０８はテストケース開始時情報を受信する。テストケース開始時情報には開始したテストケース名とテストケースの開始時刻が格納されている。次にＳ８１０に進み、リソースモニタ手段４０８は、受信した情報を基にリソースモニタ画面上にテストケース名を表示し、テストケースが開始された時刻が分かるように縦線を描画する。次にＳ８１１に進み、リソースモニタ手段４０８は、テストケース開始時情報およびその時点のメモリ使用量（Ｓ８２１で受信）を記憶媒体上に記憶して、Ｓ８０６に戻る。
【００５４】
一方、Ｓ８０８にテストケース実行開始通知でないと判定された場合はＳ８１２に進む。Ｓ８１２において、組み込みアプリケーション開発支援ツール４０５はＳ８０６にて受信したデータがテストケース実行終了通知であったかどうかを判定する。テストケース実行終了通知であった場合、Ｓ８１３に進む。Ｓ８１３において、リソースモニタ手段４０８はテストケース実行終了時情報を受信する。テストケース実行終了時情報には実行終了したテストケースのテストケース名とテストケース終了時刻が格納されている。次にＳ８１４に進み、リソース異常検出手段４０９は、テストケース開始時のメモリ使用量と終了時のメモリ使用量の差分を算出する。次にＳ８１５に進み、リソース異常検出手段４０９は、算出した差分が所定の閾値を超えているかどうかを判断する。もし閾値を超えていない場合はＳ８０６に戻り、閾値を超えておりリソースの使用量に差異があると判断された場合はＳ８１６に進む。Ｓ８１６において、リソースモニタ手段４０８はテストケース名を強調表示し、リーク候補リスト画面にテストケース名およびメモリ使用量差分の情報を追加してＳ８０６に戻る。開始時情報、および実行終了通知は時間情報の一部であり、時間情報の形式、内容に制限はない。
【００５５】
一方、Ｓ８１２にて受信データがテストケース実行終了通知でないと判定された場合は、Ｓ８１７に進む。Ｓ８１７において、組み込みアプリケーション開発支援ツール４０５はＳ８０６で受信したデータがジョブ状態変化通知であるかどうかを判定する。ジョブ状態変化通知である場合はＳ８１８に進む。Ｓ８１８において、リソースモニタ手段４０８はジョブ情報を受信してＳ８１９に進む。ジョブ情報にはジョブ種別およびジョブの状態（生成・消滅）が格納されている。Ｓ８１９において、リソースモニタ手段４０８は受信したジョブ情報を基にメモリ情報画面のジョブ状況領域の描画内容を更新しＳ８０６に戻る。
【００５６】
一方、Ｓ８１７にて受信データがジョブ状態変化通知でないと判定された場合は、Ｓ８２０に進む。Ｓ８２０において、組み込みアプリケーション開発支援ツール４０５はＳ８０６で受信したデータがリソース情報通知であるかどうかを判定する。もしリソース情報通知でない場合は、データを無視してＳ８０６に戻る。Ｓ８２０にてリソース情報通知であると判定された場合はＳ８２１に進む。Ｓ８２１において、リソースモニタ手段４０８はリソース情報を受信し記憶してＳ８２２に進む。なお、リソース情報にはテストアプリケーションの動作中におけるリソース使用量が含まれている。Ｓ８２２において、リソースモニタ手段４０８はメモリ状況画面（図７（ｂ））の描画更新を行う。具体的には受信したリソース情報内のリソース使用量を基にグラフ表示領域７１０を更新、ジョブ状況表示領域７１１の表示更新、画面に収まらなくなった場合のスクロール制御を行う。
【００５７】
図９は、図８のフローチャートを実行後の組み込みアプリケーション開発支援ツール４０５の処理の流れを示すフローチャートである。組み込みアプリケーション開発支援ツール４０５は、Ｓ９０１にてプルダウンメニュー７０３の選択時に「テスト実行およびメモリリーク解析（詳細）」が選択されていたかどうかを判定する。もし「テスト実行およびメモリリーク解析（詳細）」が選択されていない場合は処理を終了する。もし「テスト実行およびメモリリーク解析（詳細）」が選択されたと判定された場合、Ｓ９０２に進む。Ｓ９０２において、再テスト実行手段４１０はリーク候補リストに情報が存在するかどうかを判定する。もしリーク候補リスト内に情報がなければ処理を終了する。もしリーク候補リスト内に情報が存在した場合はＳ９０３に進む。Ｓ９０３において、再テスト実行手段４１０は、テストブローカにデバッグモードへの切り替え要求を送信し、テストブローカへの再接続を行う。デバッグモードへの切り替えは画像形成装置の再起動を伴うため、再接続が成功するまでリトライを繰り返す。テストブローカへの再接続が完了したらＳ９０４に進み、アプリケーション生成手段４０７はリーク候補リスト内に存在するテストケースのみを含むテスト用アプリケーションを生成する。即ち、リークの疑いがあるテストケースを含みリークの疑いがないテストケースを含まないテスト用アプリケーションを生成するということであり、このようなアプリケーションをデバッグ用アプリケーションと称する。
【００５８】
次にＳ９０５に進み、操作手段４０６がＳ９０４で生成したテスト用アプリケーションを送信し、再度、テスト実行要求を出す。次にＳ９０６に進み、組み込みアプリケーション開発支援ツール４０５は、テストブローカからデータを受信する。次にＳ９０７に進み、組み込みアプリケーション開発支援ツール４０５は、受信したデータがテスト終了通知であったかどうかを判定する。もしテスト終了通知であった場合はＳ９１６に進む。Ｓ９１６では組み込みアプリケーション開発支援ツール４０５は、テスト結果を受信してテスト結果表示領域に結果を表示する。次にＳ９１７に進み、操作手段４０６はテスト用アプリケーションのアンインストール要求をテストブローカに送信して処理を終了する。
【００５９】
一方、Ｓ９０７においてテスト終了通知でないと判定された場合は、Ｓ９０８に進む。Ｓ９０８において、組み込みアプリケーション開発支援ツール４０５は、テストケース実行開始通知であるかどうかを判定する。テストケース実行開始通知であると判定された場合、Ｓ９０９に進み、リソースモニタ手段４０８はテストケース実行開始時情報およびヒープダンプ情報を受信する。ヒープダンプとは仮想マシン上のメモリ内容のダンプであり、どのクラスのオブジェクトが何個存在しているか等の詳細な情報を解析可能なデータである。次にＳ９１０に進み、リソースモニタ手段４０８はヒープダンプから存在するオブジェクト数をクラス毎に算出して記憶媒体に記憶し、Ｓ９０６に戻る。テストケース処理終了時点のオブジェクト数が開始時点のオブジェクト数よりも増えている場合、リークの疑いがあると判断できる。
【００６０】
一方、Ｓ９０８においてテストケース実行開始通知でないと判定された場合はＳ９１１に進む。Ｓ９１１において、組み込みアプリケーション開発支援ツール４０５はＳ９０６で受信したデータがテストケース実行終了通知であるかどうかを判定する。もしテストケース実行終了通知でないと判定された場合は、何もせずにＳ９０６に戻る。もしＳ９１１にてテストケース実行終了通知であると判定された場合はＳ９１２に進む。Ｓ９１２において、リソースモニタ手段４０８はテストケース終了時情報およびヒープダンプ情報を受信する。次にＳ９１３に進み、リソースモニタ手段４０８はヒープダンプ情報から存在するオブジェクト数をクラス毎に算出して記憶媒体上に記憶し、Ｓ９１４に進む。Ｓ９１４において、リソース異常検出手段４０９はテストケース開始時とテストケース終了時のオブジェクト数の差をクラス毎に算出する。次にＳ９１５に進み、リソース異常検出手段４０９は差分が閾値以上のものがあるかどうかを判定する。もし閾値以上のものが存在しないと判定された場合はＳ９０６に戻る。閾値以上のものが存在する場合はＳ９１６に進みリソースモニタ手段４０８はリーク要因詳細リストに情報を追加してＳ９０６に戻る。
【００６１】
図１０は、デバイス状態監視要求を受けた際のテストブローカ内のデバイス監視モジュール５０３の処理の流れを示すフローチャートである。デバイス状態監視要求を受けるとデバイス監視モジュール５０３は、まずＳ１００１にて画像形成装置上のメモリ情報取得を行う。次にＳ１００２に進み、デバイス監視モジュール５０３は組み込みアプリケーション開発支援ツールにリソース情報通知およびメモリ情報を渡す。次にＳ１００３に進み、デバイス監視モジュール５０３はジョブ状況を取得する。次にＳ１００４に進み、ジョブ状況に変化があったかどうかを判定する。なお、初回のジョブ状況取得時はジョブ状況に変化があったと判定される。それ以降は直前に取得した状況から変化があるかによって判定が行われる。
【００６２】
もしジョブ状況に変化がないと判定された場合はＳ１００６に進む。ジョブ状況に変化があると判定された場合はＳ１００５に進む。Ｓ１００５において、デバイス監視モジュール５０３はジョブ状態変化通知およびジョブ状態情報を送信して組み込みアプリケーション開発支援ツールに情報を渡す。次にＳ１００６に進み、デバイス監視モジュール５０３は所定時間スリープする。本実施例では２００ｍｓスリープするようにしている。次にＳ１００７に進みテストが終了したかどうかを判定する。もしテストが終了していない場合はデバイス監視モジュール５０３はＳ１００１に戻り、テストが終了している場合は処理を終了する。
【００６３】
図１１は、テスト用アプリケーションを受信した際のテストブローカの処理の流れを示したフローチャートである。テストブローカ５０１はＳ１１０１にてテスト用アプリケーションファイルを受信する。次にテストブローカ５０１はＳ１１０２にてインストーラサービス２０４を利用してテスト用アプリケーションをインストールする。次にテストブローカ５０１はＳ１１０３でテスト用アプリケーションを開始する。次にテストブローカ５０１はＳ１１０４にて実行すべきテストケースが存在するかを判定する。テスト用アプリケーションに含まれるテストケースで未実行のものがあれば実行すべきテストケースが存在すると判定される。もし実行すべきテストケースが存在すると判定された場合はＳ１１０５に進む。Ｓ１１０５ではテストブローカ５０１は画像形成装置のジョブ状況を取得してジョブの存在有無を判定する。もしジョブが存在した場合はＳ１１０５に戻る。Ｓ１１０５にてジョブが存在しないと判定されるとＳ１１０６に進む。
【００６４】
Ｓ１１０６において、テストブローカ５０１はテストケース実行開始通知およびテストケース実行時情報を組み込みアプリケーション開発支援ツール４０５に送信する。次にＳ１１０７に進み、テストブローカ５０１は起動モードがデバッグモードか否かを判定する。もしデバッグモードでないと判定された場合はＳ１１０９に進む。一方、Ｓ１１０７にてデバッグモードであると判定された場合はＳ１１０８に進む。Ｓ１１０８において、テストブローカ５０１はヒープダンプを取得して組み込みアプリケーション開発支援ツール４０５に送信し、Ｓ１１０９に進む。Ｓ１１０９ではテストブローカ５０１はテストケースを実行する。テストケースが実行されるとアプリケーションのテストが行われテスト結果が記憶媒体上に蓄積される。テストケースが終了するとＳ１１１０に進む。
【００６５】
Ｓ１１１０において、テストブローカ５０１は画像形成装置のジョブ状況を取得してジョブの存在有無を判定する。もしジョブが存在した場合はＳ１１１０に戻る。Ｓ１１１０にてジョブが存在しないと判定されるとＳ１１１１に進む。Ｓ１１１１において、テストブローカ５０１はテストケース終了通知とテストケース終了時情報を組み込みアプリケーション開発支援ツール４０５に送信する。次にＳ１１１２に進み、テストブローカ５０１は起動モードがデバッグモードか否かを判定する。もしデバッグモードでないと判定された場合はＳ１１０４に戻る。一方、Ｓ１１１２にてデバッグモードであると判定された場合はＳ１１１３に進む。Ｓ１１１３ではテストブローカ５０１はヒープダンプを取得して組み込みアプリケーション開発支援ツール４０５に送信しＳ１１０４に戻る。
【００６６】
一方、Ｓ１１０４にて実行すべきテストケースが存在しないと判定された場合はＳ１１１４に進む。Ｓ１１１４ではテストブローカ５０１は組み込みアプリケーション開発支援ツール４０５にテスト終了通知を送信する。次にＳ１１１５に進み、テストブローカ５０１はＳ１１０９のテスト実行時に蓄積していたテスト結果をまとめて組み込みアプリケーション開発支援ツール４０５に送信して、処理を終了する。
【００６７】
図１２は、デバッグモードへの切り替え要求を受けた際のテストブローカ５０１の処理の流れを示したフローチャートである。テストブローカ５０１は、まずＳ１２０１にて起動モード変更要求を受信する。次にＳ１２０２に進み、テストブローカ５０１は起動モード設定を要求に応じて変更する。起動モード設定は不揮発メモリ上に記憶される。次にＳ１２０３に進み、テストブローカ５０１は画像形成装置を再起動して処理を終了する。
【００６８】
図１３は、画像形成装置の電源を入れた際の起動プログラム２０７の処理の流れを示すフローチャートである。まずＳ１３０１にて起動プログラム２０７は内部で保持している起動モード設定を取得する。次にＳ１３０２に進み、起動プログラム２０７は起動モードがデバッグモードであるかを判定する。もし起動モードがデバッグモードであると判定された場合はＳ１３０３に進み、デバッグ用のファームウェアを起動して処理を終了する。もしＳ１３０２にて起動モードがデバッグモードでないと判定された場合はＳ１３０４に進み、起動プログラム２０７は通常用のファームウェアを起動して処理を終了する。
【００６９】
以上、説明したように、本発明によれば、画像形成装置のジョブ実行中は新たなテストケースを実行しないように制御したことにより、アプリケーション以外の要因のメモリ変動を排除して解析することができるようになる。これにより、アプリケーションのメモリリークを判別することが容易となる。また、テストケースとメモリ変化の対応をグラフで表示できるため、どのテストケースを実行した場合にメモリリークが発生するのかが容易に判別可能になる。例えば、図７（ｂ）のようにテストケースの開始タイミングで縦の線が表示され開始時点と終了時点のメモリ使用量を容易に判別できる。即ち、本願発明により、テストケースを開始する時点において使用したリソース使用量と、該テストケースを終了する時点において使用したリソース使用量との差異を各テストケース毎に認識できるようになる。この例ではＰｒｉｎｔＴｅｓｔ２のｔｅｓｔＧｅｔＩｎｆｏ実行時およびＳｅｎｄＴｅｓｔ１のｔｅｓｔＷｅｂＤＡＶを実行した際にメモリリークが発生しているということが一目でわかる。また、メモリリークの疑いのあるテストケースのみをデバッグ用のファームウェアで再実行可能とすることにより、詳細解析にかかる時間を短縮することができるという効果がある。
【００７０】
なお、本実施例ではメモリリークについて検出を行っているが、メモリに限定されるものではなく、ファイルディスクリプタやソケットやスレッドのリーク検出を行うようにしてもよい。また、本実施例では画像形成装置のジョブ実行中は新たなテストケースを実行しないように制御を行っているが、例えばログイン処理や定期的に状態を初期化するためのオートクリア処理が実行中はテストケースを実行しないように制御してもよい。また微量のリークも検出できるようにするためテストケースの実行を複数回繰り返してからリソースの差分を取得するようにしてもよい。
【符号の説明】
【００７１】
１  画像形成装置
３００  開発用ＰＣ
４００  統合開発環境
４０５  組み込みアプリケーション開発支援ツール
５０１  テストブローカ
５０２  テスト用アプリケーション
８０２  テストケース
【図１】
2013149026.tif 000003
【図２】
2013149026.tif 000004
【図３】
2013149026.tif 000005
【図４】
2013149026.tif 000006
【図５】
2013149026.tif 000007
【図６】
2013149026.tif 000008
【図７】
2013149026.tif 000009
【図８】
2013149026.tif 000010
【図９】
2013149026.tif 000011
【図１０】
2013149026.tif 000012
【図１１】
2013149026.tif 000013
【図１２】
2013149026.tif 000014
【図１３】
2013149026.tif 000015