(57)【特許請求の範囲】
【請求項１】
検査対象のプログラムを実行し、前記プログラムの状態に応じて、所定のイベントデータ群に含まれるイベントデータを発行して、該状態の遷移を検証する検査部として機能するコンピュータに、
前記プログラムの状態を基に、前記プログラムの状態を有効条件とする前記プログラムへの入力イベントを示す入力イベントデータが記憶された記憶部を参照して、前記プログラムの状態を有効条件とする入力イベントデータを抽出し、
抽出した前記入力イベントデータに、前記プログラムが参照する日時情報の変更を示す所定の日時遷移イベントデータを追加して、前記所定のイベントデータ群を生成し、
前記生成した所定のイベントデータ群を前記検査部に通知し、前記検査部が発行したイベントデータを取得し、
前記取得したイベントデータが前記日時遷移イベントデータであるか否かを判定し、
前記判定において前記日時遷移イベントデータであると判定した場合に、前記記憶部に記憶された遷移前の日時情報と遷移後の日時情報との対応情報を参照して、前記日時情報を、該日時情報と一致する遷移前の日時情報に対応付けて前記記憶部に記憶された遷移後の日時情報に変更し、
前記判定において前記日時遷移イベントデータでないと判定した場合に、当該イベントデータを前記プログラムに入力する
処理を実行させるプログラム検査プログラム。
【請求項２】
前記日時情報を変更する処理は、前記プログラムによる日時情報の取得要求の入力先プログラムが管理する第２の日時情報とは異なる、前記記憶部に記憶された前記日時情報を変更し、
前記プログラムによる、前記入力先プログラムに対する日時情報の取得要求に応じ、前記記憶部に記憶された前記日時情報を前記プログラムに応答する
処理を前記コンピュータに実行させる請求項１記載のプログラム検査プログラム。
【請求項３】
前記検査部が発行したイベントデータごとに、当該イベントデータの発行前後の前記検査対象のプログラムの状態をイベント履歴記憶部に記憶し、
前記イベント履歴記憶部を参照して、前記日時遷移イベントデータが連続するかを判定して、前記入力イベントデータへの前記日時遷移イベントデータの追加の要否を判断する処理を前記コンピュータに実行させ、
前記所定のイベントデータ群を生成する処理は、前記判断する処理において前記日時遷移イベントデータの追加が必要であると判断された場合に、前記入力イベントデータに、前記日時遷移イベントデータを追加して、前記所定のイベントデータ群を生成する請求項１又は２記載のプログラム検査プログラム。
【請求項４】
前記判断する処理は、更に、前記イベント履歴記憶部を参照して、最後に前記日時遷移イベントデータが発行された後に、前記プログラムの状態を有効条件とする全ての前記入力イベントデータが発行されているか否かに基づいて、前記入力イベントデータへの前記日時遷移イベントデータの追加の要否を判断する請求項３記載のプログラム検査プログラム。
【請求項５】
検査対象のプログラムを実行し、前記プログラムの状態に応じて、所定のイベントデータ群に含まれるイベントデータを発行して、該状態の遷移を検証する検査部と、
前記プログラムの状態を基に、前記プログラムの状態を有効条件とする前記プログラムへの入力イベントを示す入力イベントデータが記憶された記憶部と、
前記記憶部を参照して、前記プログラムの状態を有効条件とする入力イベントデータを抽出し、抽出した前記入力イベントデータに、前記プログラムが参照する日時情報の変更を示す所定の日時遷移イベントデータを追加して、前記所定のイベントデータ群を生成する生成部と、
前記生成した所定のイベントデータ群を前記検査部に通知し、前記検査部が発行したイベントデータを取得し、前記取得したイベントデータが前記日時遷移イベントデータであるか否かを判定し、前記判定において前記日時遷移イベントデータでないと判定した場合に、当該イベントデータを前記プログラムに入力する入力部と、
前記判定において前記日時遷移イベントデータであると判定された場合に、前記記憶部に記憶された遷移前の日時情報と遷移後の日時情報との対応情報を参照して、前記日時情報を、該日時情報と一致する遷移前の日時情報に対応付けて前記記憶部に記憶された遷移後の日時情報に変更する変更部とを有するプログラム検査装置。
【請求項６】
検査対象のプログラムを実行し、前記プログラムの状態に応じて、所定のイベントデータ群に含まれるイベントデータを発行して、該状態の遷移を検証する検査部として機能するコンピュータが、
前記プログラムの状態を基に、前記プログラムの状態を有効条件とする前記プログラムへの入力イベントを示す入力イベントデータが記憶された記憶部を参照して、前記プログラムの状態を有効条件とする入力イベントデータを抽出し、
抽出した前記入力イベントデータに、前記プログラムが参照する日時情報の変更を示す所定の日時遷移イベントデータを追加して、前記所定のイベントデータ群を生成し、
前記生成した所定のイベントデータ群を前記検査部に通知し、前記検査部が発行したイベントデータを取得し、
前記取得したイベントデータが前記日時遷移イベントデータであるか否かを判定し、
前記判定において前記日時遷移イベントデータであると判定した場合に、前記記憶部に記憶された遷移前の日時情報と遷移後の日時情報との対応情報を参照して、前記日時情報を、該日時情報と一致する遷移前の日時情報に対応付けて前記記憶部に記憶された遷移後の日時情報に変更し、
前記判定において前記日時遷移イベントデータでないと判定した場合に、当該イベントデータを前記プログラムに入力する
処理を実行するプログラム検査方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラム検査プログラム、プログラム検査装置、及びプログラム検査方法に関する。
【背景技術】
【０００２】
日時情報に応じて振る舞いが異なるアプリケーションのテストは、単純に行うとすると、一つのシナリオに関して多くの日数を要してしまう。したがって、全てのシナリオを網羅的にテストするのは困難である。「単純に」とは、アプリケーションにとって日時情報の参照先となる、ＯＳ（Operating System）等のアプリケーションの実行環境における日時情報を操作することなく、という意味である。
【０００３】
そこで、従来、テストドライバ等を用いた自動的なテスト方法が採用されている。例えば、シナリオ生成技術によって生成されたテストシナリオが、テストドライバに対して入力情報として与えられる。当該テストシナリオは、アプリケーションが有する機能の実行順と日時情報を変更するタイミングとを示す情報である。例えば、アプリケーションが、Ａ、Ｂ、及びＣの機能を有するとき、「Ａ→（日時情報の変更）→Ｂ→Ｃ」は、一つのテストシナリオとなる。テストドライバは、テストシナリオに指定された順番に従ってアプリケーションの機能を呼び出したり、アプリケーションの実行環境の日時情報を変更したりする。その結果、現実の日時と異なる日時を示す日時情報をアプリケーションに対して与えることができ、現実の日時の変化を待機する必要性は低減される。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００７−１８３７８号公報
【特許文献２】特開２００９−２４５３８３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、シナリオ生成技術では、機能の実行順及び日時情報の変更のタイミングの組み合わせが単純に洗い出されるため、アプリケーションの機能数が多くなると、テストシナリオの数が膨大となるという問題がある。また、異なるテストシナリオであっても、実質的に意味は同じであるテストシナリオが生成され、無駄なテストが行われることも多い。
【０００６】
本発明は、上記の点に鑑みてなされたものであって、日時情報の変更を要するプログラム検査を効率化することのできるプログラム検査プログラム、プログラム検査装置、及びプログラム検査方法の提供を目的とする。
【課題を解決するための手段】
【０００７】
そこで上記課題を解決するため、プログラム検査プログラムは、検査対象のプログラムを実行し、前記プログラムの状態に応じて、所定のイベントデータ群に含まれるイベントデータを発行して、該状態の遷移を検証する検査部として機能するコンピュータに、前記プログラムの状態を基に、前記プログラムの状態を有効条件とする前記プログラムへの入力イベントを示す入力イベントデータが記憶された記憶部を参照して、前記プログラムの状態を有効条件とする入力イベントデータを抽出し、抽出した前記入力イベントデータに、前記プログラムが参照する日時情報の変更を示す所定の日時遷移イベントデータを追加して、前記所定のイベントデータ群を生成し、前記生成した所定のイベントデータ群を前記検査部に通知し、前記検査部が発行したイベントデータを取得し、前記取得したイベントデータが前記日時遷移イベントデータであるか否かを判定し、前記判定において前記日時遷移イベントデータであると判定した場合に、前記記憶部に記憶された遷移前の日時情報と遷移後の日時情報との対応情報を参照して、前記日時情報を、該日時情報と一致する遷移前の日時情報に対応付けて前記記憶部に記憶された遷移後の日時情報に変更し、前記判定において前記日時遷移イベントデータでないと判定した場合に、当該イベントデータを前記プログラムに入力する処理を実行させる。
【発明の効果】
【０００８】
日時情報の変更を要するプログラム検査を効率化することができる。
【図面の簡単な説明】
【０００９】
【図１】第一の実施の形態におけるプログラム検査装置のハードウェア構成例を示す図である。
【図２】第一の実施の形態におけるプログラム検査装置のソフトウェア構成例を示す図である。
【図３】第一の実施の形態におけるプログラムモデル検査部を説明するための図である。
【図４】第一の実施の形態のプログラム検査装置による検査処理の概要を説明するための図である。
【図５】第一の実施の形態の検査処理の処理手順の一例を説明するためのフローチャートである。
【図６】検査対象イベント記憶部からの有効イベントの抽出例を示す図である。
【図７】検査対象イベント記憶部からの有効イベントの第二の抽出例を示す図である。
【図８】有効なイベント群への日時遷移イベントの追加を説明するための図である。
【図９】イベントの実行処理の処理手順の一例を説明するためのフローチャートである。
【図１０】日時遷移モデル記憶部の構成例を示す図である。
【図１１】日時情報の取得要求に応じて実行される処理手順の一例を説明するためのフローチャートである。
【図１２】第一の実施の形態の実行ステップ数の一例を説明するための図である。
【図１３】本発明の実施の形態におけるプログラム検査装置の第二のソフトウェア構成例及び第二の処理概要を説明するための図である。
【図１４】冗長な検査パスを発生させる日時遷移イベントの発行例を示す図である。
【図１５】第二の実施の形態におけるプログラム検査装置のソフトウェア構成例を示す図である。
【図１６】日時遷移要否判断部の機能構成例を示す図である。
【図１７】第二の実施の形態の検査処理の処理手順の一例を説明するためのフローチャートである。
【図１８】イベント履歴記録処理の処理手順の一例を説明するためのシーケンス図である。
【図１９】イベント履歴記憶部の構成例を示す図である。
【図２０】一例としてのイベント履歴記憶部に記憶された状態遷移を示す図である。
【図２１】日時遷移イベントの追加の要否の判断処理の概要を説明するためのシーケンス図である。
【図２２】日時遷移イベントの追加の要否の判断処理の処理手順の一例を説明するためのフローチャートである。
【発明を実施するための形態】
【００１０】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、第一の実施の形態におけるプログラム検査装置のハードウェア構成例を示す図である。図１のプログラム検査装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。
【００１１】
プログラム検査装置１０での処理を実現するプログラムは、記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００１２】
メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってプログラム検査装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。
【００１３】
なお、記録媒体１０１の一例としては、ＣＤ−ＲＯＭ、ＤＶＤディスク、又はＵＳＢメモリ等の可搬型の記録媒体が挙げられる。また、補助記憶装置１０２の一例としては、ＨＤＤ（Hard Disk Drive）又はフラッシュメモリ等が挙げられる。記録媒体１０１及び補助記憶装置１０２のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。
【００１４】
図２は、第一の実施の形態におけるプログラム検査装置のソフトウェア構成例を示す図である。同図において、プログラム検査装置１０は、プログラムモデル検査部１１、検査対象プログラム１２、プログラム実行環境部１３、日時情報管理部１４、検査対象統合部１５、及び検査対象イベント記憶部１６等を有する。プログラムモデル検査部１１、プログラム実行環境部１３、日時情報管理部１４、検査対象統合部１５は、プログラム検査装置１０にインストールされたプログラムがＣＰＵ１０４に実行させる処理により実現される。検査対象イベント記憶部１６は、例えば、補助記憶装置１０２を用いて実現可能である。
【００１５】
プログラムモデル検査部１１は、検査（テスト）の対象とされたプログラムの各状態において当該プログラムに関して有効なイベント（イベントデータ）を発行し（又は発生させ）、当該プログラムの状態の遷移を検証することにより、当該プログラムの検査を行う。プログラムの状態とは、プログラムのメモリの状態（メモリイメージの内容）をいう。イベントとは、検査対象のプログラムの状態に影響を与えうるイベント（事象）をいう。例えば、検査対象のプログラムに対する要求又はデータ等の入力がイベントの一例として挙げられる。より具体的には、検査対象プログラム１２が有するインタフェース（関数又はメソッド等）の呼び出しがイベントの一例である。「有効な」イベントとは、検査対象のプログラムの或る状態において、検査として意味の有るイベントをいう。検査として意味の有るイベントは、検査対象のプログラムの或る状態において実行可能なイベントに限られない。実行可能でないイベントが実行可能でないことを確認することも検査として意味が有るからである。なお、有効なイベントは、プログラムの状態に応じて変化しうる。
【００１６】
図３は、第一の形態におけるプログラムモデル検査部を説明するための図である。同図において、プログラムＰ１は、検査対象のプログラムである。プログラムモデル検査部１１を示すブロック内の各楕円は、プログラムＰ１の状態を示す。各楕円から伸びる矢印ａ、ｂ、又はｃは、各状態において有効なイベントである。また、プログラムＰ１から各状態に伸びる太線の矢印は、プログラムモデル検査部１１が、プログラムＰ１のメモリの内容を各状態として抽出（又は監視）していることを示す。なお、各状態において有効なイベント群は、プログラムＰ１よりプログラムモデル検査部１１に通知される。
【００１７】
まず、上段のプログラムモデル検査部１１を参照すると、プログラムＰ１の初期状態は、状態ｓｔ１である。状態ｓｔ１において有効なイベントは、イベントａ及びｂである。プログラムモデル検査部１１は、有効なイベントのうちのいずれかを発行する。同図では、イベントａが発行されている。イベントａに応じた機能（又は処理）の実行により、プログラムＰ１は、状態ｓｔ２に遷移している。状態ｓｔ２において有効なイベントは、イベントａ及びｂである。状態ｓｔ２において、プログラムモデル検査部１１は、イベントｂを発行している。その結果、プログラムＰ１は、状態ｓｔ３に遷移している。状態ｓｔ３では、イベントｃのみが有効である。そこで、プログラムモデル検査部１１は、イベントｃを実行している。状態ｓｔ３において有効な全てのイベントの実行が完了すると、プログラムモデル検査部１１は、プログラムＰ１のメモリの状態を一つ前の状態に戻す。したがって、同図では、状態ｓｔ２に戻される。
【００１８】
状態ｓｔ２において有効なイベントのうち、発行されていないイベントは、イベントａである。したがって、同図下段に示されるように、プログラムモデル検査部１１は、イベントａを発行する。その結果、プログラムＰ１は、状態ｓｔ４に遷移する。以降、プログラムモデル検査部１１は、上記において説明した処理を繰り返す。すなわち、プログラムモデル検査部１１は、或る状態において有効なイベントを全て実行し終えたら、プログラムＰ１を一つ前の状態に戻す。最終的に、初期状態ｓｔ１に戻ると、プログラムモデル検査部１１による、プログラムＰ１の検査（テスト）は終了する。
【００１９】
なお、プログラムモデル検査部１１は、プログラムＰ１の状態の遷移を検証することで、プログラムＰ１が正しい動作をしているか否かを確認する。状態の遷移の検証とは、イベントの発行に応じた遷移先の状態が、予め期待されている状態であるか否かを確認することをいう。
【００２０】
以上のような検査方法は、プログラムモデル検査とも呼ばれる。プログラムモデル検査に関しては、例えば、特開２０１０−１９１５０８号公報、特開２０１０−１９１５０７号公報、及び特開２００９−８７３５２号公報等に開示されている。
【００２１】
図２に戻る。検査対象プログラム１２は、検査（テスト）の対象とされるプログラムである。検査対象プログラム１２の機能は所定のものに限定されない。但し、検査対象プログラム１２の振る舞い（処理内容）は、日時情報によって影響を受ける。プログラム実行環境部１３は、ＯＳ（Operating System）等、プログラムの実行環境を実現するプログラムである。本実施の形態において、プログラム実行環境部１３は、検査対象プログラム１２による日時情報の取得先（日時情報の取得要求の入力先）として位置付けられる。
【００２２】
日時情報管理部１４は、プログラム実行環境部１３が管理する日時情報とは別に、日時情報を管理する。同図において、日時情報管理部１４は、日時遷移実行部１４１及び日時遷移モデル記憶部１４２等を含む。日時遷移モデル記憶部１４２は、日時情報遷移モデルを記憶する。日時情報遷移モデルとは、遷移前の日時情報と遷移後の日時情報との対応情報である。日時遷移実行部１４１は、検査対象統合部１５からの日時遷移イベントの入力に応じ、日時情報遷移モデルにしたがって日時情報を遷移させる（日時情報を更新する）。すなわち、日時遷移イベントとは、プログラム実行環境部１３が管理する日時情報とは別に日時情報管理部１４が管理する日時情報に関して、日時情報遷移モデルを基づく遷移（変更又は更新）の実行を、日時遷移実行部１４１に実行させるためのイベントである。
【００２３】
日時情報管理部１４が、検査対象のプログラムが参照する日時情報を、プログラム実行環境部１３が管理する日時情報とは別に管理することで、検査対象のプログラム以外のプログラムに、検査のための日時情報の変更の影響を及ぼすことを防ぐことが出来る。
【００２４】
検査対象統合部１５は、プログラムモデル検査部１１に対し、検査対象統合部１５、検査対象プログラム１２、及び日時情報管理部１４を一つの検査対象として見せるための処理を実行する。すなわち、本来であれば、検査対象プログラム１２が検査対象である。但し、検査対象統合部１５が実行する処理により、プログラムモデル検査部１１から見た場合、検査対象統合部１５、検査対象プログラム１２、及び日時情報管理部１４が、図３におけるプログラムＰ１の位置付けとして見える。より詳しくは、検査対象統合部１５は、自らが検査対象であるかのようにプログラムモデル検査部１１に対して振る舞うことにより、結果的に、検査対象統合部１５、検査対象プログラム１２、及び日時情報管理部１４を一つの検査対象のプログラムとして見せる（偽装する）。または、検査対象統合部１５は、検査対象プログラム１２及び日時情報管理部１４を、プログラムモデル検査部１１に対してラッピングするともいえる。以下、検査対象統合部１５が有する斯かる機能を、便宜上「ラッピング機能」という。
【００２５】
ラッピング機能を実現するため、検査対象統合部１５は、日時遷移イベント追加部１５１及びイベント分配部１５２等を有する。日時遷移イベント追加部１５１は、検査対象プログラム１２の各状態において有効なイベント群をプログラムモデル検査部１１に通知する。すなわち、図３では、プログラムＰ１が、自らの各状態に対して有効なイベント群をプログラムモデル検査部１１に通知する旨を説明した。本実施の形態では、日時遷移イベント追加部１５１が、斯かる役割を担う。イベント群の通知に際し、日時遷移イベント追加部１５１は、日時遷移イベントを有効なイベント群に含める（追加する）。その結果、プログラムモデル検査部１１は、日時遷移イベントを、検査対象に対して有効なイベントの一つとして認識する。
【００２６】
イベント分配部１５２は、日時遷移イベント追加部１５１によって通知されたイベント群の中からプログラムモデル検査部１１によって発行されるイベントを、日時情報管理部１４又は検査対象プログラム１２に分配する。すなわち、日時遷移イベントに関しては、日時情報管理部１４に入力される。日時遷移イベント以外のイベントに関しては、検査対象プログラム１２に入力される。
【００２７】
検査対象イベント記憶部１６は、検査対象プログラム１２の状態に応じて有効なイベントを示す情報を記憶する。検査対象イベント記憶部１６は、例えば、補助記憶装置１０２を用いて実現可能である。
【００２８】
続いて、本実施の形態の検査対象プログラム１２の機能について説明する。検査対象プログラム１２は、説明の便宜上、所定の商品の注文の受け付け処理及び支払処理を実行するアプリケーションであり、機能Ａ、機能Ｂ、及び機能Ｃを有することとする。
【００２９】
機能Ａは、電子メールによって注文を受け付け、注文の内容（注文情報）をデータベース（以下、「注文ＤＢ」という。）に登録する機能である。機能Ｂは、Ｗｅｂページを介して注文を受け付け、注文情報を注文ＤＢに登録する機能である。機能Ｃは、Ｗｅｂページを介して支払いを受け付け、注文ＤＢに登録されている注文情報を削除する機能である。なお、注文された月に支払いが行われた場合、１０％の割り引きが行われる。したがって、検査対象プログラム１２は、注文に対する支払いが注文当月内に行われたか否かによって振る舞いが異なる。
【００３０】
以上のような検査対象プログラム１２に関して、機能Ａを起動させるイベントは、電子メールによる注文である。以下、当該イベントを「イベントＡ」という。機能Ｂを起動させるイベントは、Ｗｅｂページを介した注文である。以下、当該イベントを「イベントＢ」という。機能Ｃを起動させるイベントは、Ｗｅｂを介した支払いである。以下、当該イベントを「イベントＣ」という。
【００３１】
上記のような機能を有する検査対象プログラム１２に関して、プログラム検査装置１０が実行する検査処理の概要について説明する。
【００３２】
図４は、第一の実施の形態のプログラム検査装置による検査処理の概要を説明するための図である。
【００３３】
検査の開始に応じ、プログラムモデル検査部１１により、検査対象統合部１５がプロセスとして起動される。プログラムモデル検査部１１に対しては、検査対象統合部１５に係るプログラムが検査対象として指定されているからである。検査対象統合部１５は、検査対象プログラム１２及び日時情報管理部１４を、自らのプロセス空間内において起動する。例えば、検査対象プログラム１２及び日時情報管理部１４は、それぞれスレッドとして起動される。その結果、プログラムモデル検査部１１にとって、検査対象のメモリの状態は、検査対象統合部１５に係るプロセスの状態となる。当該プロセスの範囲は、同図において破線によって示されている。以下、当該プロセスを「検査対象プロセス」という。プログラムモデル検査部１１からは、検査対象プロセスが検査対象として見えるからである。
【００３４】
同図には、検査対象プロセスの状態遷移モデルｍ１が示されている。すなわち、状態遷移モデルｍ１は、検査対象プログラム１２の状態だけでなく、日時情報管理部１４の状態をも含む状態遷移モデルである。
【００３５】
検査対象プログラム１２（厳密には、検査対象プロセス）が或る状態に遷移すると、検査対象統合部１５は、当該状態において有効なイベント群（イベントＡ、Ｂ、Ｃ）と、日時遷移イベントとをプログラムモデル検査部１１に通知する（Ｓ１１）。なお、同図において、「Ｎｅｘｔ」は、日時遷移イベントを示す。
【００３６】
プログラムモデル検査部１１は、通知されたイベント群の中から一つのイベントを選択し、当該イベント（イベントＡ、Ｂ、Ｃ、又はＮｅｘｔ）を検査対象統合部１５に入力する（Ｓ１２）。検査対象統合部１５は、イベントＡ、Ｂ、又はＣについては、検査対象プログラム１２に入力し（Ｓ１３）、日時遷移イベントＮｅｘｔについては、日時情報管理部１４に入力する（Ｓ１４）。
【００３７】
日時遷移イベントＮｅｘｔを入力された日時情報管理部１４は、日時情報遷移モデルに基づいて自らが管理している日時情報を遷移させる。
【００３８】
一方、イベントＡ、Ｂ、又はＣを入力された検査対象プログラム１２は、イベントに応じた機能Ａ、Ｂ、又はＣを実行する。この際、検査対象プログラム１２は、プログラム実行環境部１３に対して日時情報の取得要求を入力する（Ｓ１５）。日時情報の取得要求は、日時情報管理部１４によってフックされる。したがって、検査対象プログラム１２には、日時情報管理部１４が管理する日時情報が返却される。なお、通常、ＯＳ（Operating System）は、ＯＳが有するＡＰＩ（Application Program Interface）に対する機能を拡張するための機構を備える。斯かる機構の一例として、各ＡＰＩに対する呼び出しを、他のプログラムにフックさせる機構が挙げられる。日時情報管理部１４を当該他のプログラムとして、プログラム実行環境としてのＯＳに登録しておくことにより、日時情報の取得要求に係るＡＰＩの呼び出しを、日時情報管理部１４にフックさせることができる。
【００３９】
なお、状態遷移モデルｍ１では、状態ＳＴ１において、日時情報は「５／１（５月１日）」、注文ＤＢの内容は、空（レコード無し）となっている。ここで、日時情報は、日時情報管理部１４が管理する変数の内容である。注文ＤＢは、検査対象プログラム１２が管理する変数の内容である。但し、日時情報管理部１４及び検査対象プログラム１２は、同一のプロセスに含まれるため、日時情報と注文ＤＢとは、当該プロセスのメモリの状態を構成する。
【００４０】
同図では、初期状態ＳＴ１において、イベントＡが発行され、その結果として状態ＳＴ２に遷移した例が示されている。イベントＡは、検査対象プログラム１２の機能Ａを起動させる。その結果、注文ＤＢにレコードが登録される。なお、状態ＳＴ２では、日時情報は更新されない。続いて、日時遷移イベントＮｅｘｔが発行され、状態ＳＴ３に遷移している。状態ＳＴ３では、日時情報が更新されている。
【００４１】
このように、検査対象統合部１５によって、検査対象プログラム１２の状態（注文ＤＢの内容）と、日時情報管理部１４の状態（現在の日時情報）とを一単位のメモリの状態としてプログラムモデル検査部１１に見せることができる。
【００４２】
以下、プログラム検査装置１０の処理手順について更に詳しく説明する。図５は、第一の実施の形態の検査処理の処理手順の一例を説明するためのフローチャートである。同図のフローチャートの開始時において、検査対象プロセスは初期状態ＳＴ１（図４参照）であるとする。
【００４３】
ステップＳ１０１において、検査対象統合部１５の日時遷移イベント追加部１５１は、現在の状態（例えば、初期状態ＳＴ１）において、検査対象プログラム１２にとって有効なイベント群を検査対象イベント記憶部１６より抽出する。
【００４４】
図６は、検査対象イベント記憶部からの有効イベントの抽出例を示す図である。同図において、検査対象イベント記憶部１６は、検査対象プログラム１２に対して入力可能なイベントごとに、有効条件を記憶する。有効条件とは、イベントが有効となる条件である。検査対象プロセスの状態の構成情報に対する条件を有効条件として指定することができる。例えば、「現在の日時情報が月末である」ことを有効条件とすることができる。または、「注文ＤＢが空ではない」ことを有効条件とすることもできる。すなわち、有効条件は、イベントが有効な状態を示す情報であるといえる。ステップＳ１０１では、現在の状態に照らして、有効条件が満たされているイベントが抽出される。同図の検査対象イベント記憶部１６では、有効条件が指定されているイベントはない。したがって、ステップＳ１０１では、同図に示されるように、全てのイベント（Ａ、Ｂ、及びＣ）が抽出される。
【００４５】
なお、図７に示されるように、イベントＣに関して「注文ＤＢが空ではない」ことが、有効条件として登録されている場合、注文ＤＢにレコードが登録されていなければ、イベントＣは抽出されない。
【００４６】
続いて、日時遷移イベント追加部１５１は、日時遷移イベントＮｅｘｔを、ステップＳ１０１において抽出された有効なイベント群に追加する（Ｓ１０２）。
【００４７】
図８は、有効なイベント群への日時遷移イベントの追加を説明するための図である。同図に示されるように、ステップＳ１０２では、日時遷移イベントＮｅｘｔが、有効なイベント群に含められる。
【００４８】
続いて、日時遷移イベント追加部１５１は、有効なイベント群をプログラムモデル検査部１１に通知する（Ｓ１０３）。なお、本実施の形態では、プログラムモデル検査部１１は、検査対象プロセスのメモリの状態（内容）を参照可能であるとする。プログラムモデル検査部１１が、検査対象プロセスのメモリ状態を参照可能であるか否かは、プログラムモデル検査部１１等の実装形態に依存する。プログラムモデル検査部１１が検査対象プロセスのメモリの状態を参照可能でない場合、日時遷移イベント追加部１５１は、有効なイベント群と共に、検査対象プロセスのメモリの状態を示すデータをプログラムモデル検査部１１に通知してもよい。当該データは、当該メモリの内容における代表的な変数の値（本実施の形態では、日時情報の値及び注文ＤＢの値）の集合であってもよいし、当該メモリのイメージのハッシュ値であってもよい。要するに、現在のメモリの状態を他の状態と識別可能なデータであればよい。
【００４９】
続いて、プログラムモデル検査部１１は、通知された有効なイベント群の中から、一つのイベントを選択する（Ｓ１０４）。選択方法は、所定のものに限定されない。いずれかのイベントがランダムに選択されてもよい。プログラムモデル検査部１１は、現在の検査対象プロセスの状態と、当該状態に対して有効なイベント群と、当該イベント群の中で選択されたイベントとを関連付けて、例えばメモリ装置１０３に記録しておく。以下、現在の検査対象プロセスの状態と、当該状態に対して有効なイベント群と、当該イベント群の中で選択されたイベントとの組み合わせの履歴を、「検査実行履歴」という。
【００５０】
続いて、プログラムモデル検査部１１は、選択したイベントを検査対象統合部１５に入力する（Ｓ１０５）。その結果、イベントに応じた機能が実行される。以下、イベントに応じた機能の実行を、「イベントの実行」という。
【００５１】
イベントの実行が終了すると、プログラムモデル検査部１１は、当該イベントの実行結果を検証する（Ｓ１０６）。イベントの実行結果の検証は、例えば、イベントの実行後の検査対象プログラム１２の状態と、検証用に予め作成されているデータ（以下、「検証用データ」という。）とを照合することにより行われる。検証用データは、検査対象プログラム１２の状態とイベントとの組み合わせごとに、当該状態において当該イベントが実行された場合に期待される遷移先の状態を示す情報が記録されたデータである。したがって、プログラムモデル検査部１１は、検査対象プログラム１２に関して、イベントの実行前と一致する状態と実行されたイベントとの組み合わせに対して検証用データに記録されている遷移先の状態と、イベントの実行後の検査対象プログラム１２の状態とが一致するか否かを判定する。プログラムモデル検査部１１は、比較された双方の状態が一致する場合、検査結果は合格であると判定し、一致しない場合、検査結果は、不合格であると判定する。
【００５２】
なお、本実施の形態において、検査対象プログラム１２の状態を示す情報は、例えば、注文ＤＢの内容を示す情報である。
【００５３】
検査結果が不合格である場合（Ｓ１０７でＮｏ）、プログラムモデル検査部１１は、検査結果は不合格であることを示す情報を出力し（Ｓ１０８）、検査処理を終了させる。但し、検査結果が不合格である場合に、以降の検査処理が継続されてもよい。
【００５４】
検査結果が合格である場合（Ｓ１０７でＹｅｓ）、プログラムモデル検査部１１は、検査対象プロセスの現在の状態を抽出（又は取得）する（Ｓ１０９）。ここで抽出される状態は、ステップＳ１０５におけるイベントの実行後の遷移先の状態である。続いて、プログラムモデル検査部１１は、検査実行履歴に記録されている状態と、抽出された状態（現在の状態）とを照合して、現在の状態は、既に検査を実行済みの状態であるか否かを判定する（Ｓ１１０）。すなわち、現在の状態と一致する状態が検査実行履歴に含まれている場合、現在の状態は既に検査を実行済みであると判定される。現在の状態と一致する状態が検査実行履歴に含まれていない場合、現在の状態はまだ検査が実行されていないと判定される。
【００５５】
現在の状態が検査を実行済みの状態でない場合（Ｓ１１０でＮｏ）、プログラムモデル検査部１１は、検査対象プロセスは、終了状態であるか否かを判定する（Ｓ１１１）。終了状態とは、例えば、プロセスが終了してしまった状態である。検査対象プロセスが終了状態でない場合（Ｓ１１１でＮｏ）、プログラムモデル検査部１１は、ステップＳ１０３における、有効なイベント群の通知に対する応答を検査対象統合部１５に返却する。その結果、検査対象統合部１５に制御が戻り、ステップＳ１０１以降が繰り返される。
【００５６】
一方、検査対象プロセスが終了状態である場合（Ｓ１１１でＹｅｓ）、又は現在の状態が検査を実行済みの状態である場合（Ｓ１１０でＹｅｓ）、プログラムモデル検査部１１は、検査対象とする状態（検査対象プロセスの状態）を、現在の状態の一つ前の状態に戻す（Ｓ１１２）。一つ前の状態とは、現在の状態に遷移する直前の状態をいう。なお、検査実行履歴は、例えば、スタック構造によって各状態とイベントとの組み合わせを記憶してもよい。スタック構造であれば、一つ前の状態を容易の特定することができる。以降、当該一つ前の状態が、「現在の状態」となる。
【００５７】
続いて、プログラムモデル検査部１１は、検査実行履歴を参照して、現在の状態に関して有効なイベントは、全て実行されたか否かを判定する（Ｓ１１３）。すなわち、検査実行履歴において、現在の状態に関して記録されている有効なイベント群の全てのイベントが選択済であるか否かが判定される。
【００５８】
現在の状態に関して未実行のイベントが有る場合（Ｓ１１３でＮｏ）、プログラムモデル検査部１１は、ステップＳ１０４以降を繰り返す。この際、現在の状態に関して未実行のイベントのうちの一つが実行対象として選択される。
【００５９】
一方、現在の状態に関して有効なイベントが全て実行されている場合（Ｓ１１３でＹｅｓ）、プログラムモデル検査部１１は、検査対象プロセスが初期状態であるか否かを判定する（Ｓ１１４）。例えば、スタック構造の検査実行履歴において、現在の状態が、最上位に記録されている状態であるか否かが判定される。現在の状態が初期状態でない場合、プログラムモデル検査部１１は、ステップＳ１１２以降を繰り返す。現時の状態が初期状態である場合、プログラムモデル検査部１１は、検査処理を終了させる。この場合は、検査対象プロセスの状態遷移モデルにおける全ての遷移パスが実行された場合だからである。
【００６０】
続いて、ステップＳ１０５の詳細について説明する。図９は、イベントの実行処理の処理手順の一例を説明するためのフローチャートである。
【００６１】
検査対象統合部１５のイベント分配部１５２は、プログラムモデル検査部１１からの入力イベントが日時遷移イベントＮｅｘｔであるか否かを判定する（Ｓ２０１）。入力イベントが日時遷移イベントＮｅｘｔである場合（Ｓ２０１でＹｅｓ）、イベント分配部１５２は、日時情報管理部１４に日時遷移イベントＮｅｘｔを入力する（Ｓ２０２）。
【００６２】
日時情報管理部１４の日時遷移実行部１４１は、日時遷移イベントＮｅｘｔの入力に応じ、日時遷移モデル記憶部１４２を参照して、現在の日時情報を更新する（遷移させる）（Ｓ２０３）。
【００６３】
図１０は、日時遷移モデル記憶部の構成例を示す図である。同図において、日時遷移モデル記憶部１４２は、遷移前日時及び遷移後日時の組み合わせの一覧を記憶する。或るレコードの遷移後日時は、他のレコード（同図では、次のレコード）の遷移前日時と一致する。したがって、日時遷移モデル記憶部１４２に記憶された日時遷移モデルは、日時の遷移を継続的に示すことができる。但し、同じ日時が繰り返される日時遷移モデルが日時遷移モデル記憶部１４２に登録されてもよい。同図の場合、遷移前日時が６／１であるレコードに関して、遷移後日時が５／１とされてもよい。そうすることにより、５／１と６／１が交互に遷移する日時遷移モデルを作成することができる。なお、日時遷移モデル記憶部１４２の最初のレコードの遷移前日時情報（５／１）は、日時情報管理部１４の初期化時において日時情報に設定される日時情報である。
【００６４】
ステップＳ２０３において、日時遷移実行部１４１は、遷移前日時が現在の日時情報と一致するレコードを日時遷移モデル記憶部１４２より検索し、検索されたレコードの遷移後日時によって現在の日時情報を更新する。
【００６５】
一方、プログラムモデル検査部１１からの入力イベントが日時遷移イベントでない場合（すなわち、イベントＡ、Ｂ、又はＣである場合）（Ｓ２０１でＮｏ）、イベント分配部１５２は、検査対象プログラム１２に当該イベントを入力する（Ｓ２０４）。検査対象プログラム１２は、当該イベントに応じた機能を実行する（Ｓ２０５）。その結果、本実施の形態においては、注文ＤＢの内容が更新される。この際、検査対象プログラム１２は、必要に応じて、プログラム実行環境部１３に対して日時情報の取得要求を行う。例えば、機能Ａ又は機能Ｂの実行時には、注文の日時を注文ＤＢに記録するために、日時情報の取得要求が行われる。また、機能Ｃの実行時には、支払いの日時が、注文当月内であるか否かを判定するため、日時情報の取得要求が行われる。
【００６６】
続いて、プログラム実行環境部１３に対する日時情報の取得要求に応じて実行される処理について説明する。
【００６７】
図１１は、日時情報の取得要求に応じて実行される処理手順の一例を説明するためのフローチャートである。
【００６８】
ステップＳ３０１において、プログラム実行環境部１３は、日時情報管理部１４に対して日時情報の取得要求を転送する。上記したように、日時情報の取得要求の転送は、日時情報管理部１４による、日時情報の取得要求のフックという形態によって実現されてもよい。
【００６９】
続いて、日時情報管理部１４の日時遷移実行部１４１は、現在の日時情報の値をプログラム実行環境部１３に返却する（Ｓ３０２）。続いて、プログラム実行環境部１３は、当該日時情報の値を検査対象プログラム１２に返却する（Ｓ３０３）。その結果、日時情報管理部１４によって管理される日時情報が検査対象プログラム１２に伝達される。
【００７０】
なお、検査対象プログラム１２が日時情報管理部１４に対して日時情報の取得要求を行わないのは、検査対象プログラム１２は、日時情報管理部１４の存在を認識していないからである。すなわち、日時情報管理部１４は、検査対象プログラム１２の検査用に実装されている機能であり、検査対象プログラム１２の本番運用時において、検査対象プログラム１２が日時情報の取得先とするのは、プログラム実行環境部１３であるからである。
【００７１】
なお、日時情報の管理は、日時情報管理部１４ではなく、プログラム実行環境部１３に任せてもよい。すなわち、日時情報管理部１４は、日時遷移イベントの入力に応じ、日時遷移モデル記憶部１４２に基づいて。プログラム実行環境部１３が管理する日時情報を更新してもよい。この場合、プログラム実行環境部１３に対する日時情報の取得要求は、日時情報管理部１４によってフックされる必要はない。すなわち、プログラム実行環境部１３が管理する日時情報が検査対象プログラム１２に返却されればよい。
【００７２】
但し、プログラム実行環境部１３は、検査対象プログラム１２以外の非図示の各種のプログラムからも共用されうる。したがって、検査対象プログラム１２の検査の都合によってプログラム実行環境部１３の日時情報が更新された場合、他のプログラムに予期しない影響を与える可能性がある。本実施の形態では、斯かる可能性を回避するため、日時情報管理部１４が現在の日時情報を管理するようにしている。
【００７３】
換言すれば、斯かる可能性を考慮する必要が無い場合、日時情報の管理は、日時情報管理部１４ではなく、プログラム実行環境部１３に任せてもよい。
【００７４】
また、日時情報管理部１４は、検査対象統合部１５の一部として実装されてもよい。すなわち、検査対象統合部１５が、日時情報管理部１４の機能を有していてもよい。
【００７５】
上述したように、第一の実施の形態によれば、検査対象プログラム１２の状態遷移と日時情報の遷移とを含む状態遷移モデルに基づいて、プログラムモデル検査技術を利用して検査対象プログラム１２の検査（テスト）を実行することができる。したがって、検査対象プログラム１２の機能と、日時情報の遷移のタイミングとの順列を洗い出し、当該順列に基づくテストシナリオによって検査を行う場合に比べて、検査の実行ステップ数を削減することができる。
【００７６】
例えば、図１２は、第一の実施の形態の実行ステップ数の一例を説明するための図である。同図において、（Ａ）は、本実施の形態の検査対象プログラム１２と日時情報の変更のタイミングとの順列の一覧である。検査対象プログラム１２の機能は３つである。日時情報の変更のタイミングが１回であるとすると、順列の要素は４つである。したがって、（Ａ）の一覧における順列数（シナリオ数）は、４の階乗＝２４である。また、各シナリオは、３つの機能のそれぞれを実行する３ステップと、日時情報を５／１に初期化するステップと、日時情報を変更するステップとの５つのステップを含む。したがって、（Ａ）における実行ステップ数は、２４×５＝１２０ステップとなる。
【００７７】
一方、（Ｂ）は、検査対象プロセスの状態遷移を洗い出した結果である。当該状態遷移に含まれる遷移数は３１である。当該遷移数が、（Ｂ）における実行ステップ数ということになる。したがって、（Ｂ）における実行ステップ数は、３１ステップとなる。
【００７８】
このように、本実施の形態によれば、検査の実行ステップ数を削減することができる。すなわち、検査対象プログラム１２の検査を効率化することができる。
【００７９】
なお、プログラム検査装置１０は、図１３に示されるような構成を有していてもよい。図１３は、本発明の実施の形態におけるプログラム検査装置の第二のソフトウェア構成例及び第二の処理概要を説明するための図である。同図において、図２と同一又は対応する部分には、図２と同一符号が付されている。
【００８０】
同図のプログラム検査装置１０ａは、検査対象統合部１５を有していない。したがって、プログラムモデル検査部１１は、検査対象プログラム１２を検査対象のプログラムとして認識する。すなわち、上記において「検査対象プロセス」として説明したプロセスは、検査対象プログラムのプロセスとなる。その結果、同図の構成では、例えば、次のような処理手順が実行される。
【００８１】
検査対象プログラム１２が或る状態に遷移すると、検査対象プログラム１２は、当該状態において有効なイベント群（イベントＡ、Ｂ、Ｃ）をプログラムモデル検査部１１に通知する（Ｓ２１）。
【００８２】
続いて、プログラムモデル検査部１１は、日時情報の遷移要求を日時情報管理部１４に入力する（Ｓ２２）。プログラムモデル検査部１１は、また、日時情報の遷移要求に同期させて、ステップＳ２１において通知されたイベント群の中から一つのイベントを選択し、当該イベント（イベントＡ、Ｂ、又はＣ）を検査対象プログラム１２に入力する（Ｓ２３）。
【００８３】
日時情報の遷移要求を入力された日時情報管理部１４は、プログラム実行環部１３の日時情報を更新する（Ｓ２４）。但し、図４の構成の場合と同様に、日時情報管理部１４が管理する日時情報が更新されてもよい。
【００８４】
イベントＡ、Ｂ，又はＣを入力された検査対象プログラム１２は、イベントに応じた機能Ａ、Ｂ、又はＣを実行する。この際、検査対象プログラム１２は、プログラム実行環境より日時情報の取得を要求する（Ｓ２５）。当該取得要求に応じて、プログラム実行環境部１３又は日時情報管理部１４が管理する日時情報が検査対象プログラム１２に返却される。
【００８５】
このように、図１３に示されるような構成を有するプログラム検査装置１０ａにおいても、検査対象プログラム１２の状態を遷移させつつ、日時情報を更新することができる。但し、図１３においては、プログラムモデル検査部１１が、日時情報の遷移を意識する必要がある。また、ステップＳ２２より明らかなように、プログラムモデル検査部１１は、検査対象プログラム１２以外に、日時情報管理部１４の存在を意識し、日時情報管理部１４とのインタフェースを有する必要がある。
【００８６】
一方、図２におけるプログラムモデル検査部１２は、日時情報の遷移や、日時情報管理部１４の存在等を意識する必要性は低い。したがって、図２の構成によれば、プログラムモデル検査部１２に関して、汎用的な製品を利用することができるという利点がある。このことは、換言すれば、検査対象統合部１５及び日時情報管理部１４の汎用性が確保されることを意味する。すなわち、検査対象統合部１５及び日時情報管理部１４が、特定の製品に係るプログラムモデル検査部１２に依存する必要性を低減させることができる。
【００８７】
ところで、第一の実施の形態において、日時遷移イベントＮｅｘｔは、有効なイベント群に対して無条件に（又は常に）追加される（図５のステップＳ１０２、図８等参照）。したがって、検査対象プロセスが日時遷移イベントＮｅｘｔの発行を受けても意味の無い場合においても、日時遷移イベントＮｅｘｔが発行されてしまう。すなわち、第一の実施の形態における検査の実行ステップ（図１２（Ｂ）参照）には、冗長又は無駄な検査パスを構成する可能性がある。
【００８８】
図１４は、冗長な検査パスを発生させる日時遷移イベントの発行例を示す図である。
【００８９】
同図において、各楕円は、検査対象プログラム１２を含む検査対象プロセスの状態を示す。検査対象プログラム１２は、機能Ａ、Ｂ、Ｃを有し、各機能を起動させるイベントを、イベントＡ、Ｂ、Ｃという。イベントＡの有効条件は無いこととする。イベントＢの有効条件は、日時情報が示す日時が月末であることとする。イベントＣの有効条件は、日時情報が示す日時が月初であることであるとする。
【００９０】
同図において、状態ＳＴ１０における日時情報が示す日時は、６／１５である。すなわち、状態ＳＴ１０における日時は、月末でも月初でもない。したがって、状態ＳＴ１０において有効なイベントはイベントＡである。また、日時遷移イベントＮｅｘｔも、有効なイベントに追加される。したがって、状態ＳＴ１０では、イベントＡ及び日時遷移イベントＮｅｘｔが発行される。
【００９１】
状態ＳＴ１０に対して日時遷移イベントＮｅｘｔが発行された場合の遷移先の状態は、状態ＳＴ１２である。状態ＳＴ１２における日時情報が示す日時は、６／３０である。したがって、状態ＳＴ１２において有効なイベントは、イベントＡ及びＢである。また、日時遷移イベントＮｅｘｔも有効なイベントに追加される。したがって、状態ＳＴ１２では、イベントＡ、Ｂ、及び日時遷移イベントＮｅｘｔが発行される。状態ＳＴ１２において、日時遷移イベントＮｅｘｔが発行された場合、検査対象プロセスの状態は、日時情報が７／１（すなわち、月初）である状態ＳＴ１５へ遷移する。
【００９２】
ここで、状態ＳＴ１０→状態ＳＴ１２→状態ＳＴ１５への状態遷移パス（検査パス）においては、日時遷移イベントＮｅｘｔが連続して発行されることになる。その結果、状態ＳＴ１５では、６／３０（すなわち、月末）において実行されているべき機能Ｂは実行されない状態において、機能Ｃが実行されてしまう。
【００９３】
このような、検査パスは、異常系の検査として意味を有する場合も有るが、正常系の検査としては必要な検査パスではない。すなわち、冗長な検査パスである。
【００９４】
そこで、上記のような冗長性を除去した例を、第二の実施の形態として説明する。第二の実施の形態では、第一の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第一の実施の形態と同様でよい。
【００９５】
図１５は、第二の実施の形態におけるプログラム検査装置のソフトウェア構成例を示す図である。図１５中、図２と同一部分には同一符号を付し、その説明は省略する。
【００９６】
図１５において、検査対象統合部１５は、日時遷移要否判断部１５３を更に有する。日時遷移要否判断部１５３は、日時遷移イベントＮｅｘｔの追加の要否を判断する。すなわち、第二の実施の形態において、日時遷移イベント追加部１５１は、日時遷移イベントＮｅｘｔを有効なイベント群に無条件に追加するのではなく、日時遷移イベントＮｅｘｔの追加の要否を日時遷移要否判断部１５３に問い合わせる。日時遷移イベント追加部１５１は、日時遷移要否判断部１５３によって日時遷移イベントＮｅｘｔの追加が必要であると判断された場合に、日時遷移イベントＮｅｘｔを有効なイベント群に追加する。
【００９７】
図１６は、日時遷移要否判断部の機能構成例を示す図である。同図において、日時遷移要否判断部１５３は、受付部１７１、判断部１７２、イベント履歴管理部１７３、及びイベント履歴記憶部１７４等を有する。
【００９８】
受付部１７１は、日時遷移イベント追加部１５１より、日時遷移イベントＮｅｘｔの追加の要否の問い合わせを受け付ける。受付部１７１は、また、当該問い合わせに対する応答を、日時遷移イベント追加部１５１に出力する。
【００９９】
イベント履歴管理部１７３は、検査対象プロセスの状態遷移が発生するたびに、遷移元の状態の識別情報、遷移先の状態の識別情報、及び状態遷移のきっかけ（原因）となったイベントの識別情報とを関連付けてイベント履歴記憶部１７４に記録する。
【０１００】
判断部１７２は、受付部１７１によって受け付けられた問い合わせに応じ、イベント履歴記憶部１７４が記憶する情報に基づいて、日時遷移イベントＮｅｘｔの追加の要否を判断する。
【０１０１】
以下、第二の実施の形態のプログラム検査装置１０の処理手順について説明する。図１７は、第二の実施の形態の検査処理の処理手順の一例を説明するためのフローチャートである。図１７中、図５と同一ステップには同一ステップ番号を付し、その説明は省略する。
【０１０２】
図１７では、ステップＳ１０１及びステップＳ１０２の間に、ステップＳ１０１ａ及びＳ１０１ｂが追加されている。また、ステップＳ１０５及びＳ１０６の間に、ステップＳ１０５ａが追加されている。
【０１０３】
ステップＳ１０１ａにおいて、日時遷移要否判断部１５３は、日時遷移イベント追加部１５１からの問い合わせに応じて、日時遷移イベントＮｅｘｔの追加の要否の判断処理を実行する。当該判断処理において、日時遷移イベントＮｅｘｔの追加は必要であると判断された場合（Ｓ１０１ｂでＹｅｓ）、日時遷移イベント追加部１５１は、日時遷移イベントＮｅｘｔを、ステップＳ１０１において抽出された有効なイベント群に追加する（Ｓ１０２）。一方、当該判断処理において、日時遷移イベントＮｅｘｔの追加は不要であると判断された場合（Ｓ１０１ｂでＮｏ）、日時遷移イベント追加部１５１は、ステップＳ１０２を実行しない。
【０１０４】
また、ステップＳ１０５ａにおいて、イベント履歴管理部１７３は、プログラムモデル検査部１１からの通知に応じ、実行されたイベントと、当該イベントの実行前の状態の識別情報、及び当該イベントの実行後の状態の識別情報をイベント履歴記憶部１７４に記録する。
【０１０５】
続いて、図１７のステップＳ１０５ａの詳細について説明する。図１８は、イベント履歴記録処理の処理手順の一例を説明するためのシーケンス図である。
【０１０６】
イベントの実行後、プログラムモデル検査部は、実行したイベントの識別情報（以下、「イベント名」という。）と、当該イベント実行前後のそれぞれの検査対象プロセスの状態を示す情報とを含むイベント履歴情報を、イベント履歴管理部１７３に通知する（Ｓ５０１）。
【０１０７】
続いて、イベント履歴管理部１７３は、通知されたイベント履歴情報を、イベント履歴記憶部１７４の新たなレコードとして記録する（Ｓ５０２）。
【０１０８】
図１９は、イベント履歴記憶部の構成例を示す図である。同図において、イベント履歴記憶部１７４の各レコードは、一つのイベントの実行に関して、検査対象プロセスの状態遷移前の状態を示す情報、状態遷移後の状態を示す情報、及び当該イベントのイベント名等を記憶する。同図では、各状態を示す情報は、数値（０〜３等）によって示されているが、これは便宜的なものである。また、最初のレコードは、検査対象プロセスの初期状態を記憶するためのレコードであるため、最初のレコードの遷移後状態及びイベント名の値は空となっている。すなわち、最初のレコードの遷移前状態は、検査対象プロセスの初期状態を示す。
【０１０９】
図１９の記憶内容は、図２０に示される状態遷移（イベントの履歴）に対応する。図２０は、一例としてのイベント履歴記憶部に記憶された状態遷移を示す図である。図２０における、状態ＳＴ１０、ＳＴ１１、ＳＴ１２、ＳＴ１３、ＳＴ１４は、図１９において、順番に、０、１、２、３、４によって示されている状態に相当する。
【０１１０】
続いて、図１７のステップＳ１０１ａについて説明する。図２１は、日時遷移イベントの追加の要否の判断処理の概要を説明するためのシーケンス図である。
【０１１１】
ステップＳ６０１において、日時遷移イベント追加部１５１は、日時遷移イベントＮｅｘｔの追加の要否を受付部１７１に問い合わせる（Ｓ６０１）。この際、日時遷移イベント追加部１５１は、図２２のステップＳ１０１において抽出された有効なイベント群のイベント名の一覧を問い合わせ内容に含める。
【０１１２】
受付部１７１は、日時遷移イベント追加部１５１からの問い合わせ内容を判断部１７２に通知する（Ｓ６０２）。判断部１７２は、当該通知に応じ、イベント履歴記憶部１７４の記憶内容（イベント履歴情報）を、イベント履歴管理部１７３を介して取得する（Ｓ６０３〜Ｓ６０６）。続いて、判断部１７２は、問い合わせ内容と、イベント履歴情報とに基づいて、日時遷移イベントＮｅｘｔの追加の要否を判断する（Ｓ６０７）。続いて、判断部１７２は、判断結果を受付部１７１に応答する（Ｓ６０８）。受付部１７１は、当該判断結果を日時遷移イベント追加部１５１に応答する（Ｓ６０９）。
【０１１３】
続いて、図２１のステップＳ６０２〜Ｓ６０８において、判断部１７２又はイベント履歴管理部１７３によって実行される処理の詳細について説明する。
【０１１４】
図２２は、日時遷移イベントの追加の要否の判断処理の処理手順の一例を説明するためのフローチャートである。
【０１１５】
ステップＳ７０１において、判断部１７２は、受付部１７１より、問い合わせ内容を受け付ける。続いて、判断部１７２は、検査対象プロセスの現在の状態（以下、「現状態」という。）への遷移のきっかけ（原因）となったイベント名を、イベント履歴管理部１７３に問い合わせる（Ｓ７０２）。
【０１１６】
続いて、イベント履歴管理部１７３は、現状態への遷移のきっかけとなったイベント名を、イベント履歴記憶部１７４より取得する（Ｓ７０３）。検査対象プロセスの現状態は、イベント履歴記憶部１７４の最後のレコードの遷移後状態に記録されている情報に基づいて特定される。したがって、現状態への遷移のきっかけとなったイベント名は、当該最後のレコードに記録されているイベント名である。続いて、イベント履歴管理部１７３は、当該イベント名を判断部１７２に返却する（Ｓ７０３）。
【０１１７】
続いて、判断部１７２は、返却されたイベント名が「Ｎｅｘｔ」であるか、すなわち、日時遷移イベントＮｅｘｔを示すイベント名であるか否かを判定する（Ｓ７０４）。返却されたイベント名が「Ｎｅｘｔ」である場合（Ｓ７０４でＹｅｓ）、判断部１７２は、日時遷移イベントＮｅｘｔの追加は不要である旨を、受付部１７１に対して応答する（Ｓ７０５）。すなわち、この場合、日時遷移イベントＮｅｘｔが連続して発生する検査パスが形成されてしまうことになる。したがって、現状態への遷移のきっかけとなったイベントが日時遷移イベントＮｅｘｔである場合は、日時遷移イベントＮｅｘｔの追加は不要であると判断される。
【０１１８】
一方、現状態への遷移のきっかけとなったイベント名が「Ｎｅｘｔ」でない場合（Ｓ７０４でＮｏ）、判断部１７２は、最後（最新）の日時遷移イベントＮｅｘｔから、現状態に至るまでの全てのイベントのイベント名の一覧を、イベント履歴管理部１７３に問い合わせる（Ｓ７０６）。最後の日時遷移イベントＮｅｘｔから、現状態に至るまでの全てのイベントとは、最後の日時遷移イベントＮｅｘｔから、現状態に至るまでの状態遷移のパスにおいて、直系の（又は直列の）のパスに含まれる全てのイベントをいう。
【０１１９】
当該問い合わせに応じ、イベント履歴管理部１７３は、まず、イベント履歴記憶部１７４における最後のレコードを注目レコードとする（Ｓ７０７）。
【０１２０】
続いて、イベント履歴管理部１７３は、注目レコードのイベント名をイベント履歴記憶部１７４より取得する（Ｓ７０８）。続いて、イベント履歴管理部１７３は、取得されたイベント名は「Ｎｅｘｔ」であるか否かを判定する（Ｓ７０９）。当該イベント名が「Ｎｅｘｔ」でない場合（Ｓ７０９でＮｏ）、イベント履歴管理部１７３は、イベント履歴記憶部１７４において、注目レコードの遷移前状態と一致する状態が遷移後状態であるレコードを、新たに注目レコードとする（Ｓ７１０）。すなわち、状態遷移のパスが遡られる。イベント履歴管理部１７３は、注目レコードのイベント名が「Ｎｅｘｔ」となるまで、ステップＳ７０８〜Ｓ７１０を繰り返す。
【０１２１】
注目レコードのイベント名が「Ｎｅｘｔ」である場合（Ｓ７０９でＹｅｓ）、イベント履歴管理部１７３は、ステップＳ７０８において取得された全てのイベント名の一覧から、最後に取得されたイベント名（すなわち、「Ｎｅｘｔ」）を除いた一覧を、判断部１７２に返却する（Ｓ７１１）。すなわち、当該一覧が、最後（最新）の日時遷移イベントＮｅｘｔから、現状態に至るまでの全てのイベントのイベント名の一覧である。なお、当該イベント名の一覧は、現状態の日時において、実行された全てのイベントのイベント名の一覧に相当する。
【０１２２】
続いて、判断部１７２は、返却されたイベント名の一覧を、問い合わせ内容に含まれている、有効なイベント群のイベント名の一覧と比較する（Ｓ７１２）。続いて、判断部１７２は、返却されたイベント名の一覧に関して、有効なイベント群のイベント名の一覧に対する不足分の有無を判定する（Ｓ７１３）。すなわち、返却されたイベント名の一覧に含まれておらず、有効なイベント群のイベント名の一覧に含まれているイベント名の有無が判定される。当該判定は、現状態において有効なイベント群に係るすべての機能が、現状態の日時において実行されたか否かの判定に相当する。
【０１２３】
不足分が有る場合（Ｓ７１３でＹｅｓ）、判断部１７２は、日時遷移イベントＮｅｘｔの追加は不要である旨を、受付部１７１に対して応答する（Ｓ７１４）。不足分が無い場合（Ｓ７１３でＮｏ）、判断部１７２は、日時遷移イベントＮｅｘｔの追加は必要である旨を、受付部１７１に対して応答する（Ｓ７１５）。
【０１２４】
すなわち、日時遷移イベントＮｅｘｔは、各日時において、有効な全てのイベントが実行された後に実行される。そうすることで、或る日時において実行されるべき一部又は全部の機能が実行されないまま、日時が遷移してしまうといったケース（検査パス）の発生が回避される。
【０１２５】
図１７、図１８、及び図２２において説明したような処理が実行されることにより、例えば、図１４における、状態ＳＴ１２から状態ＳＴ１５への遷移の発生は抑制される。すなわち、状態ＳＴ１２への遷移のきっかけとなったイベントは日時遷移イベントＮｅｘｔである。したがって、図２２のステップＳ７０４及びＳ７０５の判断により、有効なイベント群に対する日時遷移イベントの追加は回避される。
【０１２６】
また、状態ＳＴ１３及び状態ＳＴ１４における、日時遷移イベントＮｅｘｔの追加も抑制される。すなわち、状態ＳＴ１３及び状態ＳＴ１４のそれぞれにおいて有効なイベントは、イベントＡ及びＢである。しかしながら、状態ＳＴ１３及び状態ＳＴ１４では、最後の日時遷移イベントＮｅｘｔの実行後からイベントＢ又はイベントＡが実行されていない。したがって、図２２のステップ７０６以降の判断により、有効なイベント群に対する日時遷移イベントの追加は抑制される。
【０１２７】
なお、図１４の状態ＳＴ１３においてイベントＢが発生した場合の遷移先の非図示の状態においては、日時遷移イベントＮｅｘｔが有効なイベント群に追加される。また、状態ＳＴ１４においてイベントＡが発生した場合の遷移先の非図示の状態においても、日時遷移イベントＮｅｘｔが有効なイベント群に追加される。図１４に関して説明した有効条件によれば、６／３０（すなわち、月末）において、有効なイベント群は、イベントＡ及びＢである。そして、上記した各非図示の遷移先の状態は、６／３０において、イベントＡ及びＢの双方が発生した状態（すなわち、機能Ａ及びＢの双方が実行された状態）である。また、当該各非図示の状態への遷移へのきっかけとなったイベントは、日時遷移イベントＮｅｘｔではない。したがって、当該各非図示の状態では、日時遷移イベントの追加が許容される。
【０１２８】
上述したように、第二の実施の形態によれば、日時遷移イベントが無条件に追加されることによる、冗長な検査パスの発生を抑制することができる。したがって、検査の実行ステップを、更に削減することができる。
【０１２９】
また、日時の遷移前に或る機能が実行されていることを前提とした他の機能の実行に関して、例えば、注文ＤＢのデータ内容の矛盾等に基づく異常の発生を防止することができる。換言すれば、正しいテストシナリオの実行が可能になり、テスト精度を向上させることができる。
【０１３０】
なお、本実施の形態において、プログラムモデル検査部１１は、検査部の一例である。日時遷移イベント追加部１５１は、生成部の一例である。イベント分配部１５２は、入力部の一例である。日時遷移実行部１４１は、変更部の一例である。
【０１３１】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【０１３２】
以上の説明に関し、更に以下の項を開示する。
（付記１）
検査対象のプログラムを実行し、前記プログラムの状態に応じて、所定のイベントデータ群に含まれるイベントデータを発行して、該状態の遷移を検証する検査部として機能するコンピュータに、
前記プログラムの状態を基に、前記プログラムの状態を有効条件とする前記プログラムへの入力イベントを示す入力イベントデータが記憶された記憶部を参照して、前記プログラムの状態を有効条件とする入力イベントデータを抽出し、
抽出した前記入力イベントデータに、前記プログラムが参照する日時情報の変更を示す所定の日時遷移イベントデータを追加して、前記所定のイベントデータ群を生成し、
前記生成した所定のイベントデータ群を前記検査部に通知し、前記検査部が発行したイベントデータを取得し、
前記取得したイベントデータが前記日時遷移イベントデータであるか否かを判定し、
前記判定において前記日時遷移イベントデータであると判定した場合に、前記記憶部に記憶された遷移前の日時情報と遷移後の日時情報との対応情報を参照して、前記日時情報を、該日時情報と一致する遷移前の日時情報に対応付けて前記記憶部に記憶された遷移後の日時情報に変更し、
前記判定において前記日時遷移イベントデータでないと判定した場合に、当該イベントデータを前記プログラムに入力する
処理を実行させるプログラム検査プログラム。
（付記２）
前記日時情報を変更する処理は、前記プログラムによる日時情報の取得要求の入力先プログラムが管理する第２の日時情報とは異なる、前記記憶部に記憶された前記日時情報を変更し、
前記プログラムによる、前記入力先プログラムに対する日時情報の取得要求に応じ、前記記憶部に記憶された前記日時情報を前記プログラムに応答する
処理を前記コンピュータに実行させる付記１記載のプログラム検査プログラム。
（付記３）
前記検査部が発行したイベントデータごとに、当該イベントデータの発行前後の前記検査対象のプログラムの状態をイベント履歴記憶部に記憶し、
前記イベント履歴記憶部を参照して、前記日時遷移イベントデータが連続するかを判定して、前記入力イベントデータへの前記日時遷移イベントデータの追加の要否を判断する処理を前記コンピュータに実行させ、
前記所定のイベントデータ群を生成する処理は、前記判断する処理において前記日時遷移イベントデータの追加が必要であると判断された場合に、前記入力イベントデータに、前記日時遷移イベントデータを追加して、前記所定のイベントデータ群を生成する付記１又は２記載のプログラム検査プログラム。
（付記４）
前記判断する処理は、更に、前記イベント履歴記憶部を参照して、最後に前記日時遷移イベントデータが発行された後に、前記プログラムの状態を有効条件とする全ての前記入力イベントデータが発行されているか否かに基づいて、前記入力イベントデータへの前記日時遷移イベントデータの追加の要否を判断する付記３記載のプログラム検査プログラム。
（付記５）
検査対象のプログラムを実行し、前記プログラムの状態に応じて、所定のイベントデータ群に含まれるイベントデータを発行して、該状態の遷移を検証する検査部と、
前記プログラムの状態を基に、前記プログラムの状態を有効条件とする前記プログラムへの入力イベントを示す入力イベントデータが記憶された記憶部と、
前記記憶部を参照して、前記プログラムの状態を有効条件とする入力イベントデータを抽出し、抽出した前記入力イベントデータに、前記プログラムが参照する日時情報の変更を示す所定の日時遷移イベントデータを追加して、前記所定のイベントデータ群を生成する生成部と、
前記生成した所定のイベントデータ群を前記検査部に通知し、前記検査部が発行したイベントデータを取得し、前記取得したイベントデータが前記日時遷移イベントデータであるか否かを判定し、前記判定において前記日時遷移イベントデータでないと判定した場合に、当該イベントデータを前記プログラムに入力する入力部と、
前記判定において前記日時遷移イベントデータであると判定された場合に、前記記憶部に記憶された遷移前の日時情報と遷移後の日時情報との対応情報を参照して、前記日時情報を、該日時情報と一致する遷移前の日時情報に対応付けて前記記憶部に記憶された遷移後の日時情報に変更する変更部とを有するプログラム検査装置。
（付記６）
前記変更部は、前記プログラムによる日時情報の取得要求の入力先プログラムが管理する第２の日時情報とは異なる、前記記憶部に記憶された前記日時情報を変更し、前記プログラムによる、前記入力先プログラムに対する日時情報の取得要求に応じ、前記記憶部に記憶された前記日時情報を前記プログラムに応答する付記５記載のプログラム検査装置。
（付記７）
前記検査部が発行したイベントデータごとに、当該イベントデータの発行前後の前記検査対象のプログラムの状態を記憶するイベント履歴記憶部と、
前記イベント履歴記憶部を参照して、前記日時遷移イベントデータが連続するかを判定して、前記入力イベントデータへの前記日時遷移イベントデータの追加の要否を判断する判断部とを有し、
前記生成部は、前記判断部によって前記日時遷移イベントデータの追加が必要であると判断された場合に、前記入力イベントデータに、前記日時遷移イベントデータを追加して、前記所定のイベントデータ群を生成する付記５又は６記載のプログラム検査装置。
（付記８）
前記判断部は、更に、前記イベント履歴記憶部を参照して、最後に前記日時遷移イベントデータが発行された後に、前記プログラムの状態を有効条件とする全ての前記入力イベントデータが発行されているか否かに基づいて、前記入力イベントデータへの前記日時遷移イベントデータの追加の要否を判断する付記７記載のプログラム検査装置
（付記９）
検査対象のプログラムを実行し、前記プログラムの状態に応じて、所定のイベントデータ群に含まれるイベントデータを発行して、該状態の遷移を検証する検査部として機能するコンピュータが、
前記プログラムの状態を基に、前記プログラムの状態を有効条件とする前記プログラムへの入力イベントを示す入力イベントデータが記憶された記憶部を参照して、前記プログラムの状態を有効条件とする入力イベントデータを抽出し、
抽出した前記入力イベントデータに、前記プログラムが参照する日時情報の変更を示す所定の日時遷移イベントデータを追加して、前記所定のイベントデータ群を生成し、
前記生成した所定のイベントデータ群を前記検査部に通知し、前記検査部が発行したイベントデータを取得し、
前記取得したイベントデータが前記日時遷移イベントデータであるか否かを判定し、
前記判定において前記日時遷移イベントデータであると判定した場合に、前記記憶部に記憶された遷移前の日時情報と遷移後の日時情報との対応情報を参照して、前記日時情報を、該日時情報と一致する遷移前の日時情報に対応付けて前記記憶部に記憶された遷移後の日時情報に変更し、
前記判定において前記日時遷移イベントデータでないと判定した場合に、当該イベントデータを前記プログラムに入力する
処理を実行するプログラム検査方法。
（付記１０）
前記日時情報を変更する処理は、前記プログラムによる日時情報の取得要求の入力先プログラムが管理する第２の日時情報とは異なる、前記記憶部に記憶された前記日時情報を変更し、
前記プログラムによる、前記入力先プログラムに対する日時情報の取得要求に応じ、前記記憶部に記憶された前記日時情報を前記プログラムに応答する
処理を前記コンピュータに実行させる付記９記載のプログラム検査方法。
（付記１１）
前記検査部が発行したイベントデータごとに、当該イベントデータの発行前後の前記検査対象のプログラムの状態をイベント履歴記憶部に記憶し、
前記イベント履歴記憶部を参照して、前記日時遷移イベントデータが連続するかを判定して、前記入力イベントデータへの前記日時遷移イベントデータの追加の要否を判断する処理を前記コンピュータが実行し、
前記所定のイベントデータ群を生成する処理は、前記判断する処理において前記日時遷移イベントデータの追加が必要であると判断された場合に、前記入力イベントデータに、前記日時遷移イベントデータを追加して、前記所定のイベントデータ群を生成する付記９又は１０記載のプログラム検査方法。
（付記１２）
前記判断する処理は、更に、前記イベント履歴記憶部を参照して、最後に前記日時遷移イベントデータが発行された後に、前記プログラムの状態を有効条件とする全ての前記入力イベントデータが発行されているか否かに基づいて、前記入力イベントデータへの前記日時遷移イベントデータの追加の要否を判断する付記１１記載のプログラム検査方法。
【符号の説明】
【０１３３】
１０          プログラム検査装置
１１          プログラムモデル検査部
１２          検査対象プログラム
１３          プログラム実行環境部
１４          日時情報管理部
１５          検査対象統合部
１６          検査対象イベント記憶部
１００        ドライブ装置
１０１        記録媒体
１０２        補助記憶装置
１０３        メモリ装置
１０４        ＣＰＵ
１０５        インタフェース装置
１４１        日時遷移実行部
１４２        日時遷移モデル記憶部
１５１        日時遷移イベント追加部
１５２        イベント分配部
１５３        日時遷移要否判断部
１７１        受付部
１７２        判断部
１７３        イベント履歴管理部
１７４        イベント履歴記憶部
Ｂ            バス
【図１】
0005652329.tif 000002
【図２】
0005652329.tif 000003
【図３】
0005652329.tif 000004
【図４】
0005652329.tif 000005
【図５】
0005652329.tif 000006
【図６】
0005652329.tif 000007
【図７】
0005652329.tif 000008
【図８】
0005652329.tif 000009
【図９】
0005652329.tif 000010
【図１０】
0005652329.tif 000011
【図１１】
0005652329.tif 000012
【図１２】
0005652329.tif 000013
【図１３】
0005652329.tif 000014
【図１４】
0005652329.tif 000015
【図１５】
0005652329.tif 000016
【図１６】
0005652329.tif 000017
【図１７】
0005652329.tif 000018
【図１８】
0005652329.tif 000019
【図１９】
0005652329.tif 000020
【図２０】
0005652329.tif 000021
【図２１】
0005652329.tif 000022
【図２２】
0005652329.tif 000023