(57)【要約】【課題】詳細な単体テストを効率的に行えるようにすること。【解決手段】記憶手段１ａは、所定のプログラムの処理経過に応じた所定の条件と当該プログラムに対して所定の例外を発生させるための例外用プログラム部品とを当該プログラムに対応付けて定義した定義情報を記憶する。特定手段１ｃは、実行手段１ｂによるプログラムの実行が開始されると、記憶手段１ａに格納された定義情報を参照して、当該プログラムに対応する条件を特定する。テスト処理手段１ｄは、当該プログラムの実行中に、特定した条件が満たされたかを監視し、当該条件が満たされると、定義情報を参照して、当該プログラムに対応する例外用プログラム部品を呼び出すことで当該プログラムの動作テストを行う。【選択図】図１
2012108692.tif 000002
【特許請求の範囲】
【請求項１】
所定のプログラムの実行が開始されると、記憶手段に格納され、前記プログラムの処理経過に応じた所定の条件と前記プログラムに対して所定の例外を発生させるための例外用プログラム部品とを前記プログラムに対応付けて定義した定義情報を参照して、前記プログラムに対応する前記条件を特定し、
前記プログラムの実行中に、特定した前記条件が満たされたかを監視し、当該条件が満たされると、前記定義情報を参照して、前記プログラムに対応する前記例外用プログラム部品を呼び出すことで前記プログラムの動作テストを行う、
処理をコンピュータに実行させることを特徴とするソフトウェア開発支援プログラム。
【請求項２】
前記条件には、前記プログラムに対応付けて当該プログラムの実行に利用される第１のプログラム部品と、当該第１のプログラム部品を呼び出す第２のプログラム部品と、が定義されており、
前記プログラムの実行中に、前記定義情報を参照して、前記第２のプログラム部品が前記第１のプログラム部品を呼び出した際に、前記条件が満たされたことを検出する、
ことを特徴とする請求項１記載のソフトウェア開発支援プログラム。
【請求項３】
前記条件には、前記プログラムに対応付けて前記第１のプログラム部品が前記第２のプログラム部品を呼び出した回数を示す指定回数が定義されており、
前記プログラムの実行中に、前記定義情報を参照して、前記第２のプログラム部品による前記第１のプログラム部品の呼び出しが行われるたびに当該呼び出しの回数を計数し、
前記呼び出しの回数が前記指定回数に達すると前記条件が満たされたことを検出する、
ことを特徴とする請求項２記載のソフトウェア開発支援プログラム。
【請求項４】
前記定義情報には、前記プログラムに対応付けて前記例外用プログラム部品に入力するための所定のパラメータが定義されており、
前記例外用プログラム部品を呼び出す際に、前記定義情報を参照して前記パラメータを前記例外用プログラム部品に入力する、
ことを特徴とする請求項１乃至３の何れか一項に記載のソフトウェア開発支援プログラム。
【請求項５】
前記条件には、第１のプログラム部品がブレークポイントとして定義されており、
前記条件を特定すると、前記ブレークポイントを所定のデバッガに設定し、
前記デバッガの出力内容に基づいて、前記条件が満たされたかを監視し、
前記デバッガにより前記ブレークポイントで前記プログラムの実行が中断されるたびに、前記条件が満たされたかを判定し、
前記条件が満たされると、前記デバッガに前記プログラム部品を用いて前記例外を発生させることで前記プログラムの前記動作テストを行う、
ことを特徴とする請求項１乃至４の何れか一項に記載のソフトウェア開発支援プログラム。
【請求項６】
所定のプログラムの処理経過に応じた所定の条件と前記プログラムに対して所定の例外を発生させるための例外用プログラム部品とを前記プログラムに対応付けて定義した定義情報を記憶する記憶手段と、
実行手段による前記プログラムの実行が開始されると、前記記憶手段に格納された前記定義情報を参照して、前記プログラムに対応する前記条件を特定する特定手段と、
前記プログラムの実行中に、特定した前記条件が満たされたかを監視し、当該条件が満たされると、前記定義情報を参照して、前記プログラムに対応する前記例外用プログラム部品を呼び出すことで前記プログラムの動作テストを行うテスト処理手段と、
を有することを特徴とするソフトウェア開発支援装置。
【請求項７】
コンピュータのソフトウェア開発支援方法であって、
所定のプログラムの実行が開始されると、記憶手段に格納され、前記プログラムの処理経過に応じた所定の条件と前記プログラムに対して所定の例外を発生させるための例外用プログラム部品とを前記プログラムに対応付けて定義した定義情報を参照して、前記プログラムに対応する前記条件を特定し、
前記プログラムの実行中に、特定した前記条件が満たされたかを監視し、当該条件が満たされると、前記定義情報を参照して、前記プログラムに対応する前記例外用プログラム部品を呼び出すことで前記プログラムの動作テストを行う、
ことを特徴とするソフトウェア開発支援方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はソフトウェア開発支援プログラム、ソフトウェア開発支援装置およびソフトウェア開発支援方法に関する。
【背景技術】
【０００２】
ソフトウェア開発では、ソフトウェアの品質向上を図るためソフトウェアを構成するプログラムにつき単体テストが行われる。単体テストでは、プログラムが予め設計された動作を適正に実行できるかをテストする。例えば、予定する入力データに対して正常に処理を完了できるか、異常時の処理が適正か、を検証する。プログラムが想定外の処理を行えば、プログラム中から原因のステップを特定して、改修（デバッグ）できる。
【０００３】
ここで、異常時のテストを行うために、プログラム実行中に所定のステップの実行を検出し、当該ステップにおいてテスト用のイベントを発生させて、プログラムの出力結果を確認することが考えられる。
【０００４】
例えば、解析対象プロセスで所定の命令が実行された時に、当該命令の次に実行される命令の読込を停止させて、解析対象プロセスの解析を行う方法が知られている（例えば、特許文献１参照）。また、例えば、オブジェクト指向プログラミング言語を用いて作成されたプログラムの例外処理のテストにおいて、所定のメソッドが実行された場合に、当該メソッドに対応する例外発生スタブクラスを作成して、例外を発生させる方法が知られている（例えば、特許文献２参照）。
【０００５】
更に、デバッグを支援するツールとして、デバッガと呼ばれるプログラムが利用されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１０−９２１７８号公報
【特許文献２】特開２００６−１９０３２５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ここで、あるプログラムの処理を行う上で、他の汎用的なプログラムに含まれるステップ（あるいは当該ステップを含むプログラム部品）を呼び出して処理を実行することがある。その場合、同一のプログラム部品であっても、処理の呼出関係によって処理結果が異なることがある。また、処理内容によっては所定のステップが複数回実行されることもあり、各回につき処理結果が異なることもある。このため、プログラムの単体テストの信頼性の観点からは、このようなプログラムの処理経過を追って、各処理経過に応じた検証を行えることが望ましい。
【０００８】
これに対し、詳細な単体テストを行うために処理の呼出関係を明示して例外を発生させるようなテスト用のプログラムを別途作成することが考えられる。しかしながら、複数のプログラムの各ステップにつき、個々に具体的な状況を記述したプログラムを作成するには多大な工数を要するという問題がある。
【０００９】
一方、一般的に用いられるデバッガでは、任意のステップを指定して例外を発生できるものの、任意のステップにつき所定の呼出関係や実行回数等を考慮して例外を発生させることが困難であるという問題がある。
【００１０】
本発明はこのような点に鑑みてなされたものであり、詳細な単体テストを効率的に行えるようにしたソフトウェア開発支援プログラム、ソフトウェア開発支援装置およびソフトウェア開発支援方法を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記課題を解決するために、ソフトウェア開発支援プログラムが提供される。このソフトウェア開発支援プログラムは、所定のプログラムの実行が開始されると、記憶手段に格納され、プログラムの処理経過に応じた所定の条件とプログラムに対して所定の例外を発生させるための例外用プログラム部品とをプログラムに対応付けて定義した定義情報を参照して、当該プログラムに対応する当該条件を特定する。プログラムの実行中に、特定した条件が満たされたかを監視し、当該条件が満たされると、定義情報を参照して、当該プログラムに対応する例外用プログラム部品を呼び出すことで当該プログラムの動作テストを行う。
【００１２】
また、上記課題を解決するために、ソフトウェア開発支援装置が提供される。このソフトウェア開発支援装置は、記憶手段、特定手段およびテスト処理手段を有する。記憶手段は、所定のプログラムの処理経過に応じた所定の条件と当該プログラムに対して所定の例外を発生させるための例外用プログラム部品とを当該プログラムに対応付けて定義した定義情報を記憶する。特定手段は、実行手段によるプログラムの実行が開始されると、記憶手段に格納された定義情報を参照して、当該プログラムに対応する条件を特定する。テスト処理手段は、プログラムの実行中に、特定した条件が満たされたかを監視し、当該条件が満たされると、定義情報を参照して、当該プログラムに対応する例外用プログラム部品を呼び出すことで当該プログラムの動作テストを行う。
【００１３】
また、上記課題を解決するために、ソフトウェア開発支援プログラムの処理を行うソフトウェア開発支援方法が提供される。
【発明の効果】
【００１４】
上記ソフトウェア開発支援プログラム、ソフトウェア開発支援装置およびソフトウェア開発支援方法によれば、詳細な単体テストを効率的に行える。
【図面の簡単な説明】
【００１５】
【図１】第１の実施の形態に係るソフトウェア開発支援装置を示す図である。
【図２】第２の実施の形態のソフトウェア開発支援装置のハードウェア構成を示す図である。
【図３】第２の実施の形態のソフトウェア開発支援装置の機能構成を示すブロック図である。
【図４】コンテキストファイルのデータ構造例を示す図である。
【図５】指定条件発生回数管理テーブルのデータ構造例を示す図である。
【図６】全体の処理を示すフローチャートである。
【図７】初期化処理を示すフローチャートである。
【図８】テスト準備処理を示すフローチャートである。
【図９】テスト処理を示すフローチャートである。
【図１０】初期化処理を行う第１のプログラムの具体例を示す図である。
【図１１】初期化処理を行う第２のプログラムの具体例を示す図である。
【図１２】初期化処理を行う第２のプログラムの具体例を示す図である。
【図１３】テスト準備処理を行う第１のプログラムの具体例を示す図である。
【図１４】テスト準備処理を行う第２のプログラムの具体例を示す図である。
【図１５】テスト準備処理を行う第３のプログラムの具体例を示す図である。
【図１６】テスト準備処理を行う第３のプログラムの具体例を示す図である。
【図１７】テスト準備処理を行う第３のプログラムの具体例を示す図である。
【図１８】例外発生用ライブラリの具体例を示す図である。
【図１９】テスト対象プログラムの具体例を示す図である。
【図２０】テストケースの具体例を示す図である。
【図２１】単体テストにおいて例外を発生させる処理の流れの具体例を示す図である。
【発明を実施するための形態】
【００１６】
以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態に係るソフトウェア開発支援装置を示す図である。ソフトウェア開発支援装置１は、記憶手段１ａ、実行手段１ｂ、特定手段１ｃおよびテスト処理手段１ｄを有する。
【００１７】
記憶手段１ａは、テスト対象のプログラムの処理経過に応じた所定の条件と、当該プログラムに対して所定の例外を発生させるための例外用プログラム部品とを、当該プログラムに対応付けて定義した定義情報を記憶する。また、記憶手段１ａは、テスト対象のプログラムのデータ本体を記憶する。
【００１８】
ここで、処理経過に応じた条件とは、テストを行うステップを特定するための情報である。すなわち、当該条件が満たされるステップが実行されると、そのステップ直後の状態でテストを行える。特に、当該条件は単にステップのみを特定する情報だけでなく、同ステップが何回実行されたか、同ステップが過去にどのようなステップを経て実行されているか、等を特定する情報を含む。また、テストを行うステップを特定するための情報は、例えば当該ステップにおいて呼び出し対象とされる所定のプログラム部品を識別する情報によって指定できる。
【００１９】
また、所定の例外を発生させるための例外用プログラム部品とは、例えば例外発生用のライブラリに用意された例外を発生させるための関数などである。また、定義情報には、当該関数に入力する情報を定義することもできる。
【００２０】
なお、記憶手段１ａは、ソフトウェア開発支援装置１の外部の記憶装置であってもよい。例えば、記憶手段１ａは、ソフトウェア開発支援装置１が接続されたネットワーク上のデータベース装置により実現されてもよい。
【００２１】
実行手段１ｂは、テスト対象のプログラムを実行する。実行手段１ｂは、テスト対象のプログラムが記述されたデータ本体を、例えば記憶手段１ａから取得する。
特定手段１ｃは、実行手段１ｂによるテスト対象のプログラムの実行開始を検出すると、記憶手段１ａに格納された定義情報を参照して、当該プログラムに対応する条件を特定する。
【００２２】
テスト処理手段１ｄは、実行手段１ｂによるテスト対象のプログラムの実行中に、特定手段１ｃが特定した条件が満たされたかを監視する。テスト処理手段１ｄは、当該条件が満たされると、定義情報を参照して、当該プログラムに対応する例外用プログラム部品を呼び出すことで当該プログラムの動作テストを行う。
【００２３】
ここで、動作テストとは、発生させた例外に対するテスト対象のプログラムの出力結果を取得する、例外に対してテスト対象のプログラムの出力結果を記録する等、の処理を行うことを意味する。
【００２４】
ソフトウェア開発支援装置１によれば、実行手段１ｂにより所定のプログラムの実行が開始される。すると、特定手段１ｃにより、記憶手段１ａに格納された定義情報が参照されて、当該プログラムの処理経過に応じた所定の条件が特定される。テスト処理手段１ｄにより、当該プログラムの実行中に特定手段１ｃが特定した条件が満たされたかが監視される。当該条件が満たされると、テスト処理手段１ｄにより、定義情報が参照されて、当該プログラムに対応する例外用プログラム部品が呼び出され、当該プログラムの動作テストが行われる。
【００２５】
これにより、詳細な単体テストを効率的に行える。具体的には以下の通りである。
定義情報に設定された条件には、処理経過を示す情報が含まれる。処理経過を示す情報とは、テスト対象のプログラムの処理において、所定のステップと当該ステップに至るまでの経過を示す情報である。例えば、テスト対象とする関数が何れの関数により呼び出されたものか、当該関数が過去に何回呼び出されたか、等を示す情報である。
【００２６】
テスト処理手段１ｄは、実行手段１ｂによるプログラムの実行を監視して、当該条件が満たされた場合にテストを行うので、従来よりも例外を発生させる状況を細かく設定できる。これによって、テスト対象のプログラムの実際の動作をより反映したテストを行える。よって、当該プログラムにつき、より詳細なテストを行えるようになる。
【００２７】
また、ソフトウェアの品質向上の観点からは、単体テストにおいて、可能な限り多くの状況を想定して網羅的にテストを行うことが望ましい。そのために、例えば単一のプログラムに含まれる複数のステップにつき、種々の状況を想定したイベントを発生させてテストを行うことが考えられる。
【００２８】
しかしながら、ソフトウェア開発者が、想定すべきイベントを個別に設定しながら網羅的にテストを行うとすると、その作業コストが問題となる。なぜなら、例えば処理経過に応じた各種イベントを発生させるプログラムを作り込む、デバッガにおいてそのようなタイミングを個々に手動で指定してテストを行う、等の作業が発生するためである。特に、単体テストの対象とするプログラムの数が多くなるほど、この問題は顕著となる。
【００２９】
これに対し、ソフトウェア開発支援装置１では、記憶手段１ａに定義情報を予め格納しておくことができる。このため、実行手段１ｂがテスト対象のプログラムを実行する際に、特定手段１ｃが定義情報から当該プログラムの実行を中断させる条件と、単体テストに用いるプログラム部品とを特定できる。このため、ソフトウェア開発者は、テスト対象のプログラムにおいて、単体テスト用の各ケースを想定した作り込みを行わずに済む。
【００３０】
また、テスト対象のプログラムが複数存在する場合にも、各プログラムに対応付けて予め条件およびプログラム部品を定義情報に設定しておけば、各プログラムの設定を当該プログラムの実行時に順次呼び出して単体テストを行える。よって、ソフトウェア開発者が単体テスト用の各ケースを、テストを行うごとに切り替えてテスト処理手段１ｄに設定するよりも、効率的にテストを行える。
【００３１】
このように、ソフトウェア開発支援装置１によれば、単体テストを詳細に行えるとともに、複数のプログラムの単体テストを効率的に行う仕組みを容易に実現できる。
以下では、テスト対象のプログラムがＣ＋＋言語で記述される場合を例に採り、ソフトウェア開発支援装置１の機能を更に詳細に説明する。ただし、他のプログラム言語で記述されたプログラムについて単体テストを行う場合にも、同様にしてソフトウェア開発支援装置１を適用できる。
【００３２】
［第２の実施の形態］
図２は、第２の実施の形態のソフトウェア開発支援装置のハードウェア構成を示す図である。ソフトウェア開発支援装置１００は、ソフトウェアを構成する複数のプログラムの開発を支援するコンピュータである。ソフトウェア開発者は、ソフトウェア開発支援装置１００を操作して、各プログラムを作成し、ソフトウェアの開発を行える。特に、ソフトウェア開発支援装置１００は、ソフトウェア開発者によるプログラムの効率的なデバッグ作業を支援する。
【００３３】
ソフトウェア開発支援装置１００は、ＣＰＵ（Central Processing Unit）１０１、ＲＯＭ（Read Only Memory）１０２、ＲＡＭ（Random Access Memory）１０３、ＨＤＤ（Hard Disk Drive）１０４、グラフィック処理装置１０５、入力インタフェース１０６、記録媒体読取装置１０７および通信インタフェース１０８を有する。
【００３４】
ＣＰＵ１０１は、ＯＳ（Operating System）プログラムやアプリケーションプログラムを実行して、ソフトウェア開発支援装置１００全体を制御する。
ＲＯＭ１０２は、ソフトウェア開発支援装置１００の起動時に実行されるＢＩＯＳ（Basic Input / Output System）プログラムなどの所定のプログラムを記憶する。ＲＯＭ１０２は、書き換え可能な不揮発性メモリであってもよい。
【００３５】
ＲＡＭ１０３は、ＣＰＵ１０１が実行するＯＳプログラムやアプリケーションプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０３は、ＣＰＵ１０１の処理に用いられるデータの少なくとも一部を一時的に記憶する。
【００３６】
ＨＤＤ１０４は、ＯＳプログラムやアプリケーションプログラムを記憶する。また、ＨＤＤ１０４は、ＣＰＵ１０１の処理に用いられるデータを記憶する。なお、ＨＤＤ１０４に代えて（または、ＨＤＤ１０４と併せて）、ＳＳＤ（Solid State Drive）など他の種類の不揮発性の記憶装置を用いてもよい。
【００３７】
グラフィック処理装置１０５は、モニタ１１に接続される。グラフィック処理装置１０５は、ＣＰＵ１０１からの命令に従って、画像をモニタ１１に表示させる。
入力インタフェース１０６は、キーボード１２やマウス１３などの入力デバイスに接続される。入力インタフェース１０６は、入力デバイスから送られる入力信号をＣＰＵ１０１に出力する。
【００３８】
記録媒体読取装置１０７は、記録媒体１４に格納されたデータを読み取る読取装置である。記録媒体１４には、例えば、ソフトウェア開発支援装置１００に実行させるプログラムが記録されている。ソフトウェア開発支援装置１００は、例えば、記録媒体１４に記録されたソフトウェア開発支援プログラムを実行することで、後述するようなソフトウェア開発支援の機能を実現することができる。すなわち、ソフトウェア開発支援の処理内容を記述したソフトウェア開発支援プログラムは、コンピュータ読み取り可能な記録媒体１４に記録して配布することが可能である。
【００３９】
記録媒体１４としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリを使用できる。磁気記録装置には、ＨＤＤ、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＣＤ（Compact Disc）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−Ｒ／ＲＷ／ＲＡＭなどがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。半導体メモリには、ＵＳＢ（Universal Serial Bus）メモリなどのフラッシュメモリがある。
【００４０】
通信インタフェース１０８は、ネットワーク１０に接続される。通信インタフェース１０８は、ネットワーク１０を介して他の情報処理装置とデータ通信を行える。
なお、ネットワーク１０に接続された他の情報処理装置（図示せず）にソフトウェア開発支援プログラムを格納しておいてもよい。その場合、ソフトウェア開発支援装置１００は、当該情報処理装置からソフトウェア開発支援プログラムをダウンロードして実行することもできる。
【００４１】
図３は、第２の実施の形態のソフトウェア開発支援装置の機能構成を示すブロック図である。ソフトウェア開発支援装置１００は、コンテキスト記憶部１１０、テスト支援部１２０、初期化部１３０、テストケース１４０，１４０ａ，１４０ｂ、コンテキスト取得部１５０、監視部１６０、デバッガ１７０およびプログラム群１８０，１８０ａ，１８０ｂを有する。
【００４２】
コンテキスト記憶部１１０、テスト支援部１２０、初期化部１３０、コンテキスト取得部１５０、監視部１６０、デバッガ１７０およびテストケース１４０，１４０ａ，１４０ｂの各ユニットの機能は、ＣＰＵ１０１が所定のプログラムを実行することにより、ソフトウェア開発支援装置１００上に実現される。ただし、これらのユニットの機能の全部または一部を専用のハードウェアで実現してもよい。プログラム群１８０，１８０ａ，１８０ｂは、単体テスト時にＣＰＵ１０１によって実行されるプログラムの集合である。
【００４３】
コンテキスト記憶部１１０は、コンテキストファイルを記憶する。コンテキストファイルには、テストを行う状況を定義したコンテキストが設定される。コンテキストは、ブレークポイント（Break point）を指定する情報、特定の処理経過を経て発生したブレークポイントを特定するための条件および当該条件が満たされたタイミングで呼び出す例外発生用のプログラム部品を指定する情報等を含む。コンテキストは、テスト対象のプログラムごとに用意される。
【００４４】
ここで、ブレークポイントとは、デバッガ１７０にテスト対象プログラムの実行を中断させるステップを示すものである。ブレークポイントは、例えば、任意の関数の識別情報（関数の名称）によって指定できる。
【００４５】
テスト支援部１２０は、単体テストの実行を支援する。テスト支援部１２０は、モニタ１１に単体テストの実行を開始するためのＧＵＩ（Graphical User Interface）を表示する。ソフトウェア開発者は、ＧＵＩに応じてキーボード１２やマウス１３を操作することで、コンテキスト記憶部１１０に格納された定義情報の追加・変更を行える。また、ソフトウェア開発者は、ＧＵＩに応じてキーボード１２やマウス１３を操作することで、１またはそれ以上のテストケースを指定して、テスト対象の各プログラムの単体テストの実行をテスト支援部１２０に指示できる。テスト支援部１２０は、単体テストの実行指示を受けると、指定されたプログラムにつき単体テストを開始する。まず、テスト支援部１２０は、当該指示があった旨を初期化部１３０に通知する。そして、テスト支援部１２０は、初期化部１３０による初期化処理が完了すると、テストケース１４０，１４０ａ，１４０ｂを順次実行して、各テスト対象プログラムの単体テストを開始する。
【００４６】
初期化部１３０は、テスト支援部１２０により単体テストの開始を指示された旨の通知を受けると、初期化処理を行う。具体的には、初期化部１３０は、コンテキスト取得部１５０および監視部１６０の機能を実現するプログラムを呼び出して、これらユニットの機能をソフトウェア開発支援装置１００上に実現する。
【００４７】
テストケース１４０，１４０ａ，１４０ｂは、単体テストの実行を制御するテストドライバである。具体的には、単体テストごとに次の処理を行う。
（１）単体テストに用いるコンテキストを指定する情報（コンテキストパターン名と称する）をコンテキスト取得部１５０に出力する。
【００４８】
（２）テスト対象プログラムを指定して実行開始する。
（３）テスト対象プログラムの実行結果を取得する。
（４）単体テストが適正に行われたか否かを判断する。
【００４９】
コンテキスト取得部１５０は、テストケース１４０，１４０ａ，１４０ｂからコンテキストパターン名を取得すると、コンテキスト記憶部１１０に格納されたコンテキストファイルを参照して、コンテキストを取得する。コンテキスト取得部１５０は、取得したコンテキストを監視部１６０に出力する。
【００５０】
ここで、コンテキスト取得部１５０は、第１の実施の形態で説明した特定手段１ｃの一例である。
監視部１６０は、コンテキスト取得部１５０から取得したコンテキストからブレークポイントの情報を抽出してデバッガ１７０に設定する。
【００５１】
また、監視部１６０は、デバッガ１７０がブレークポイントで処理を中断するたびに、デバッガ１７０の出力内容を監視して、コンテキストに設定された条件が満たされたか否かを判定する。監視部１６０は、条件が満たされた場合には、デバッガ１７０に例外の発生を指示する。
【００５２】
デバッガ１７０は、ブレークポイントでテスト対象プログラムの実行を中断させる。その際、監視部１６０から例外を発生させる旨の指示を受けると、デバッガ１７０は、例外発生用ライブラリを呼び出して、コンテキストで指定された例外を発生させる。デバッガ１７０は、ブレークポイントによる中断後、監視部１６０から例外を発生させる旨の指示を受けない場合にはテスト対象プログラムの実行を再開させる。また、デバッガ１７０は、テスト対象プログラム１８１によって実行されたステップの履歴（関数の名称を含む）を記録する。
【００５３】
ここで、デバッガ１７０としては、一般的に用いられているデバッガを利用できる。代表的なデバッガとして、例えば、ＧＮＵデバッガ（ＧＤＢ：GNU DeBugger）がある。デバッガ１７０は、テスト対象プログラム内で実行されたステップの内容（例えば、関数の名称）を逐次出力できる。監視部１６０は、当該出力を参照することで、ブレークポイントがどのような処理経過によって発生したものかを特定できる。
【００５４】
ここで、監視部１６０およびデバッガ１７０は、第１の実施の形態で説明したテスト処理手段１ｄの一例である。
プログラム群１８０，１８０ａ，１８０ｂは、テスト対象プログラム、テスト対象プログラムが呼び出す汎用ライブラリおよびテスト対象プログラムに対して例外を発生させる例外発生用ライブラリを含む。以下では、プログラム群１８０について説明するがプログラム群１８０ａ，１８０ｂについても同様である。プログラム群１８０は、テスト対象プログラム１８１、ライブラリ１８２および例外発生用ライブラリ１８３を含む。
【００５５】
テスト対象プログラム１８１は、ソフトウェア開発者によって作成されたプログラムであり、単体テストの対象である。ライブラリ１８２は、テスト対象プログラム１８１が処理を行う際に呼び出す汎用的なライブラリである。ライブラリ１８２は、汎用的な関数（汎用プログラム部品）の集合である。例外発生用ライブラリ１８３は、テスト対象プログラム１８１に対して例外を発生させる際に呼び出す例外発生用のライブラリである。例外発生用ライブラリ１８３は、例外発生用の関数（例外用プログラム部品）の集合である。なお、テストケース１４０は、テスト対象プログラム１８１の単体テストの実行ユニットであるとする。
【００５６】
図４は、コンテキストファイルのデータ構造例を示す図である。コンテキストファイル１１１は、コンテキスト記憶部１１０に予め格納される。コンテキストファイル１１１には、単体テストにおいて、例外を発生させるべき条件および発生させる例外が定義される。以下、コンテキストファイル１１１に便宜的に付した行番号に沿って、各定義内容を説明する。
【００５７】
２行目では、コンテキストパターン名が設定される。具体的には、“ＰＡＴＴＥＲＮ＿０００１”である。コンテキストファイル１１１では、２２行目にもコンテキストパターン名“ＰＡＴＴＥＲＮ＿０００２”が設定されている。この場合、２行目〜１７行目までが“ＰＡＴＴＥＲＮ＿０００１”の定義内容となる。なお、“［］”の記号は、当該設定がコンテキストパターン名であることを示している。
【００５８】
４行目では、変数“ＳＲＣ＿ＮＡＭＥ”にソースファイル名が設定される。本例では、“ＳＲＣ＿ＮＡＭＥ＝”と記述され、右辺が空欄となっている。これは、ソースファイル名を特定していないことを示している。ただし、本項目を設定することで、以下に示すトラップ対象の関数を含むプログラム（例えば、ライブラリ１８２）のソースファイルの名称を例外の発生条件として設定することもできる。
【００５９】
６行目では、変数“ＴＲＡＰ＿ＦＵＮＣ”にトラップ対象とする関数名が設定される。本例では、“ＴＲＡＰ＿ＦＵＮＣ＝Ｌｉｂ＿Ｏｕｔｅｒ＿Ｖｅｎｄｅｒ＿Ｆｕｎｃ”と記述されている。これは、“Ｌｉｂ＿Ｏｕｔｅｒ＿Ｖｅｎｄｅｒ＿Ｆｕｎｃ”をトラップ対象の関数として指定していることを示している。当該関数は、ブレークポイントとしてデバッガ１７０に設定される。なお、“Ｌｉｂ＿Ｏｕｔｅｒ＿Ｖｅｎｄｅｒ＿Ｆｕｎｃ”は、ライブラリ１８２に含まれる関数であるとする。
【００６０】
８行目では、変数“ＣＡＬＬＥＲ＿ＦＵＮＣ”にトラップ対象の関数を呼び出す関数（呼出元関数）の名称が設定される。本例では、“ＣＡＬＬＥＲ＿ＦＵＮＣ＝Ｔｅｓｔｃａｓｅ１：：ＴｅｓｔＸ”が記述されている。これは、“Ｔｅｓｔｃａｓｅ１：：ＴｅｓｔＸ”を呼出元関数として指定していることを示している。なお、“Ｔｅｓｔｃａｓｅ１：：ＴｅｓｔＸ”は、テストケース１４０のプログラムに記述された関数であるとする。ただし、テスト対象プログラム１８１に記述された関数を呼出元関数として定義してもよい。
【００６１】
１０行目では、変数“ＣＡＬＬＥＲ＿ＬＩＮＥ”に呼出元関数内の呼出元行番号が設定される。本例では、“ＣＡＬＬＥＲ＿ＬＩＮＥ＝”と記述され、右辺が空欄となっている。これは、呼出元行番号を特定していないことを示している。このように、呼出元関数名に加えて、更にその呼出元関数名内の任意の行番号を呼出元の情報として指定することもできる。
【００６２】
１２行目では、変数“ＳＴＯＰ＿ＣＯＵＮＴ”に例外を発生させるまでの指定回数が設定される。本例では、“ＳＴＯＰ＿ＣＯＵＮＴ＝５０”と記述されている。これは、“ＳＲＣ＿ＮＡＭＥ”、“ＴＲＡＰ＿ＦＵＮＣ”、“ＣＡＬＬＥＲ＿ＦＵＮＣ”および“ＣＡＬＬＥＲ＿ＬＩＮＥ”の全ての要件（ただし、設定なしの項目を除く）を満たしたブレークが“５０”回発生した場合に例外を発生させることを示している。
【００６３】
１４行目では、変数“ＲＥＤＩＲＥＣＴ＿ＦＵＮＣ”に発生させたい例外が設定される。本例では、“ＲＥＤＩＲＥＣＴ＿ＦＵＮＣ＝ＬｉｂＸ＿ＦｕｎｃＸ”と記述されている。これは、１２行目で指定された回数だけ上記ブレークが発生した場合に例外発生用ライブラリ１８３に含まれる“ＬｉｂＸ＿ＦｕｎｃＸ”を用いて例外を発生させることを示している。当該設定は、監視部１６０からデバッガ１７０に指示されるものである。
【００６４】
１６行目では、１４行目で発生させる例外に対して入力したい変数の情報が設定される。本例では、入力したい変数が存在しないため、空欄となっている。これは、設定なしであることを意味する。コンテキストファイル１１１では、３６行目にも同様の定義内容が記述されている。具体的には、“ｓｅｔ  ｐａｒａｍ１＝０ｘｆｆｆｆｆｆｆｆ”および“ｓｅｔ  ｐａｒａｍ２［５］＝０ｘ３１”と記述されている。これは、発生させる例外“ＬｉｂＸ＿ＦｕｎｃＸ”に対し、第１の変数“ｐａｒａｍ１”として“０ｘｆｆｆｆｆｆｆｆ”を、第２の変数“ｐａｒａｍ２［５］”として“０ｘ３１”を設定することを示す。
【００６５】
１８行目では、変数“ＯＴＨＥＲ＿ＣＭＤ”にデバッガ１７０に実行させるコマンドが設定される。例えば、監視部１６０は、デバッガ１７０に発生させる例外を指定する際に、当該コマンドを同時に指示して、デバッガ１７０に所定の処理を実行させることもできる。
【００６６】
図５は、指定条件発生回数管理テーブルのデータ構造例を示す図である。指定条件発生回数管理テーブル１１２は、コンテキスト記憶部１１０に格納されている。指定条件発生回数管理テーブル１１２は、監視部１６０によって更新される。指定条件発生回数管理テーブル１１２には、コンテキストパターン名および回数累計の項目が設けられている。各項目の横方向に並べられた情報同士が互いに関連付けられて、１つのコンテキストに関する情報を示す。
【００６７】
コンテキストパターン名には、コンテキストパターン名を示す情報が設定される。回数累計には、当該コンテキストパターン名で指定される条件でブレークポイントが発生した累計の回数が設定される。
【００６８】
例えば、指定条件発生回数管理テーブル１１２には、コンテキストパターン名が“ＰＡＴＴＥＲＮ＿０００１”、回数累計が“１５”という情報が設定される。これは、“ＰＡＴＴＥＲＮ＿０００１”で指定される“ＳＲＣ＿ＮＡＭＥ”、“ＴＲＡＰ＿ＦＵＮＣ”、“ＣＡＬＬＥＲ＿ＦＵＮＣ”および“ＣＡＬＬＥＲ＿ＬＩＮＥ”の各条件（ただし、設定なしの項目を除く）を満たすブレークが現在までに１５回発生していることを示す。監視部１６０は、デバッガ１７０がブレークポイントでテスト対象プログラム１８１の実行を中断させるたびに、当該ブレークポイントが当該条件を満たすものであれば、回数累計をインクリメント（１加算）する。
【００６９】
次に、以上のような構成のソフトウェア開発支援装置１００の処理手順を説明する。ここで、テストケース１４０，１４０ａ，１４０ｂはこの順序で実行されるものとする。更に、以下の説明では主にテストケース１４０を例示して説明するが、テストケース１４０ａ，１４０ｂに関しても同様である。
【００７０】
図６は、全体の処理を示すフローチャートである。以下、図６に示す処理をステップ番号に沿って説明する。
（ステップＳ１）テスト支援部１２０は、ソフトウェア開発者による単体テストの実行開始の操作入力を受け付ける。すると、テスト支援部１２０は、初期化処理の開始を初期化部１３０に指示する。
【００７１】
（ステップＳ２）テスト支援部１２０は、次に実行するテストケース１４０の実行を開始させる。すると、テストケース１４０は、テスト準備処理を行う。テスト準備処理では、コンテキスト取得部１５０により当該単体テストに用いるコンテキストが取得され、当該コンテキストの定義内容が監視部１６０、デバッガ１７０および例外発生用ライブラリ１８３に提供される。
【００７２】
（ステップＳ３）テストケース１４０は、テスト対象プログラム１８１の実行を開始させる。すると、監視部１６０およびデバッガ１７０は、テスト処理を行う。テスト処理では、テスト対象プログラム１８１の実行中にコンテキストで指定された条件が満たされた場合に、例外を発生させ、当該例外に対するテスト対象プログラム１８１の出力結果を記録する。
【００７３】
（ステップＳ４）テスト支援部１２０は、全テストケースを実行済か否かを判定する。実行済である場合、処理を完了する。未実行のテストケースが存在する場合、処理をステップＳ２に進める。本例の場合、テストケース１４０の実行が完了すると、次にテストケース１４０ａの実行を開始すべく処理をステップＳ２に進める。また、テストケース１４０ｂの実行が完了したとすると、全テストケースを実行済となり、本処理を完了する。
【００７４】
このようにして、テスト支援部１２０は、テストケース１４０，１４０ａ，１４０ｂを順次実行してテスト対象プログラムの単体テストを行う。その際、テストケース１４０，１４０ａ，１４０ｂの切り替えが行われるたびに、各テストケースに対応するコンテキストを取得して、監視部１６０およびデバッガ１７０に提供する。
【００７５】
次に、図６のステップＳ１に示した初期化処理の手順を詳細に説明する。
図７は、初期化処理を示すフローチャートである。以下、図７に示す処理をステップ番号に沿って説明する。
【００７６】
（ステップＳ１１）初期化部１３０は、テスト支援部１２０から初期化開始の指示を受け付ける。
（ステップＳ１２）初期化部１３０は、コンテキスト取得部１５０を起動する。
【００７７】
（ステップＳ１３）コンテキスト取得部１５０は、初期化ファイルを生成する。初期化ファイルとは、デバッガ１７０の基本動作を設定するためのコマンドを定義したファイルである。具体的には、実行するテストケースを切り替えた際に、使用するコンテキストを変更するための動作を定義したものである。
【００７８】
（ステップＳ１４）コンテキスト取得部１５０は、監視部１６０を起動する。
（ステップＳ１５）監視部１６０は、コンテキスト取得部１５０が生成した初期化ファイルを用いてデバッガ１７０を起動する。
【００７９】
このようにして、監視部１６０およびデバッガ１７０が起動され、単体テストの開始が可能な状態となる。以後、テストケース１４０，１４０ａ，１４０ｂの実行が順次開始され、各テストケースの開始の都度、監視部１６０およびデバッガ１７０にコンテキストが設定される。
【００８０】
次に、図６のステップＳ２に示したテスト準備処理の手順を詳細に説明する。
図８は、テスト準備処理を示すフローチャートである。以下、図８に示す処理をステップ番号に沿って説明する。
【００８１】
（ステップＳ２１）テスト支援部１２０は、テストケース１４０を呼び出して実行を開始する。
（ステップＳ２２）コンテキスト取得部１５０は、テストケース１４０からコンテキストパターン名を取得する。ここで、コンテキスト取得部１５０は、テストケース１４０からコンテキストパターン名として、“ＰＡＴＴＥＲＮ＿０００１”を取得したとする。
【００８２】
（ステップＳ２３）コンテキスト取得部１５０は、コンテキスト記憶部１１０に格納されたコンテキストファイル１１１を参照して、コンテキストパターン名に対応するコンテキストを取得する。具体的には、コンテキスト取得部１５０は、コンテキストファイル１１１を参照することで、コンテキストパターン名“ＰＡＴＴＥＲＮ＿０００１”に対応する行（２〜１８行目）における“ＳＲＣ＿ＮＡＭＥ”、“ＴＲＡＰ＿ＦＵＮＣ”等の設定を特定する。
【００８３】
（ステップＳ２４）コンテキスト取得部１５０は、取得したコンテキストを監視部１６０に出力する。監視部１６０は、当該コンテキストに基づいて、テスト対象プログラム１８１の実行状況の監視を行う。
【００８４】
（ステップＳ２５）監視部１６０は、コンテキストからブレークポイントに対応する“ＴＲＡＰ＿ＦＵＮＣ”の設定を取得し、デバッガ１７０に設定する。
このようにして、コンテキスト取得部１５０は、テストケースの実行開始のたびに、当該テストケースに対応するコンテキストパターン名を取得して、コンテキストを取得する。監視部１６０およびデバッガ１７０は、コンテキスト取得部１５０が取得したコンテキストに基づいてテスト対象プログラムの単体テストを行う。
【００８５】
次に、図６のステップＳ３に示したテスト処理の手順を詳細に説明する。
図９は、テスト処理を示すフローチャートである。以下、図９に示す処理をステップ番号に沿って説明する。
【００８６】
（ステップＳ３１）テストケース１４０は、テスト対象プログラム１８１の実行を開始させる。
（ステップＳ３２）監視部１６０は、デバッガ１７０の標準出力を監視する。
【００８７】
（ステップＳ３３）監視部１６０は、デバッガ１７０がテスト対象プログラム１８１の実行をブレークポイントで停止したか否かを判定する。ブレークポイントで停止した場合、処理をステップＳ３４に進める。ブレークポイントで停止していない場合、処理をステップＳ３２に進める。
【００８８】
（ステップＳ３４）監視部１６０は、デバッガ１７０の標準出力を参照して、関数の呼出関係の条件がコンテキストに設定された条件を満たすか否かを判定する。満たす場合、処理をステップＳ３５に進める。満たさない場合、処理をステップＳ３２に進める（デバッガ１７０は、テスト対象プログラム１８１の実行を再開する）。ここで、監視部１６０は、デバッガ１７０の標準出力の内容につき、次の項目を特定することで、コンテキストに設定された条件を満たすか判定できる。
【００８９】
（１）ライブラリ１８２のソースファイル名が“ＳＲＣ＿ＮＡＭＥ”に設定された名称であること。ただし、“ＰＡＴＴＥＲＮ＿０００１”の例では、設定なしであるため、条件判定の対象外となる。
【００９０】
（２）ブレークポイントが“ＴＲＡＰ＿ＦＵＮＣ”に設定されたトラップ対象関数で発生していること。“ＰＡＴＴＥＲＮ＿０００１”の例では、“Ｌｉｂ＿Ｏｕｔｅｒ＿Ｖｅｎｄｅｒ＿Ｆｕｎｃ”である。
【００９１】
（３）トラップ対象関数の直前で“ＣＡＬＬＥＲ＿ＦＵＮＣ”に設定された呼出元関数が実行されていること。“ＰＡＴＴＥＲＮ＿０００１”の例では、“Ｔｅｓｔｃａｓｅ１：：ＴｅｓｔＸ”がトラップ対象関数“Ｌｉｂ＿Ｏｕｔｅｒ＿Ｖｅｎｄｅｒ＿Ｆｕｎｃ”の前に実行されていることを特定する。
【００９２】
（４）呼出元関数の“ＣＡＬＬＥＲ＿ＬＩＮＥ”に設定された行番号のステップからトラップ対象関数が呼び出されていること。ただし、“ＰＡＴＴＥＲＮ＿０００１”の例では、設定なしであるため、条件判定の対象外となる。
【００９３】
監視部１６０は、上記（１）〜（４）の全ての条件（設定なしのため条件判定の対象外のものを除く）を満たす場合、関数の呼出関係の条件がコンテキストに設定された条件を満たすと判定できる。
【００９４】
（ステップＳ３５）監視部１６０は、コンテキスト記憶部１１０を参照して、指定条件発生回数管理テーブル１１２の該当コンテキストパターン名に設定された累積回数をインクリメント（１加算）する。なお、監視部１６０は、テスト実行後に初めて指定条件が発生した場合など、コンテキストパターン名に対応するレコードが存在しない場合には、新たにコンテキストパターン名に対応するレコードを生成して、指定条件発生回数管理テーブル１１２に追加する。なお、新たに生成したレコードには累積回数“１”を設定する。
【００９５】
（ステップＳ３６）監視部１６０は、当該コンテキストにつきインクリメント後の累積回数がコンテキストの“ＳＴＯＰ＿ＣＯＵＮＴ”に設定された指定回数と等しいか否かを判定する。等しい場合、処理をステップＳ３７に進める。等しくない場合、処理をステップＳ３２に進める（デバッガ１７０は、テスト対象プログラム１８１の実行を再開する）。“ＰＡＴＴＥＲＮ＿０００１”のコンテキストでは、指定回数は“５０”回である。よって、累積回数が“５０”回に達するまで、処理をステップＳ３２に進める。累積回数が“５０”回に達すると、処理をステップＳ３７に進める。
【００９６】
（ステップＳ３７）監視部１６０は、発生させる例外を指定する情報をデバッガ１７０に出力する。具体的には、コンテキストの“ＲＥＤＩＲＥＣＴ＿ＦＵＮＣ”に設定された例外発生用の関数の名称である。このときデバッガ１７０に対して指定したいコマンドや例外に入力したいパラメータが“ＯＴＨＥＲ＿ＣＭＤ”等に設定されていれば、デバッガ１７０に当該コマンド等も出力できる。デバッガ１７０は、例外発生用ライブラリ１８３を呼び出して、指定された例外を発生させる。例外発生用ライブラリ１８３は、生成した例外オブジェクトをスロー（throw）する。
【００９７】
（ステップＳ３８）テスト対象プログラム１８１は、例外オブジェクトをキャッチ（catch）して例外処理を実行する。
（ステップＳ３９）テスト対象プログラム１８１は、例外処理の結果をテストケース１４０に出力する。
【００９８】
このようにして、監視部１６０は、指定条件が指定回数発生したタイミングで例外発生用ライブラリ１８３を呼び出して、テスト対象プログラム１８１に対する例外を発生させることができる。
【００９９】
以下では、図６〜図９に示した処理手順を実現するプログラムの具体例を説明する。ここで、以下の説明では各プログラム例に便宜的に付した行番号に沿って説明を行う。更に、以下に示すプログラム例では、説明を容易にするために所定の内容（ヘッダ等）については図示を省略している。更に、デバッガ１７０としてＧＤＢを想定する。
【０１００】
図１０は、初期化処理を行う第１のプログラムの具体例を示す図である。プログラム２１０は、テスト支援部１２０の処理の一部を記述したものである。テスト支援部１２０は、ソフトウェア開発者による単体テストの開始操作を受け付けると、コンテキストファイル１１１を指定して初期化部１３０の機能を実現するライブラリ“ＬｉｂＺ”内の関数“ＬｉｂＺ＿Ｉｎｉｔ＿Ｆｕｎｃ”を呼び出す（４行目）。
【０１０１】
ここで、ライブラリ“ＬｉｂＺ”は、初期化部１３０およびコンテキスト取得部１５０の機能を実現するライブラリである。ライブラリ“ＬｉｂＺ”内の関数“ＬｉｂＺ＿Ｉｎｉｔ＿Ｆｕｎｃ”は、初期化部１３０の機能を実現する。また、“ＰＡＴＴＥＲＮ＿ＦＩＬＥ＿ＮＡＭＥ”は、コンテキストファイル１１１のパスを指定する文字列である。
【０１０２】
次に、“ＬｉｂＺ＿Ｉｎｉｔ＿Ｆｕｎｃ”について説明する。
図１１，１２は、初期化処理を行う第２のプログラムの具体例を示す図である。プログラム２２０は、初期化部１３０の処理の一部を記述したものである。初期化部１３０は、テスト支援部１２０により指定されたコンテキストファイルを読み込む（１６行目）。また、自プロセスのプロセスＩＤ（IDentifier）を取得する（２２行目）。更に、デバッガ１７０に出力するためのコマンド文字列を編集する（２５行目）。コマンド文字列“ｃｍｄ＿ｓｔｒｉｎｇ”には、９〜１１行目に示される文字列が含まれる。１０行目の“ｂｒｅａｋ  ＬｉｂＺ＿ＦｕｎｃＷ”のコマンドは、関数“ＬｉｂＺ＿ＦｕｎｃＷ”が実行された際に、デバッガ１７０によって単体テストを中断させることを意味する。
【０１０３】
ここで、関数“ＬｉｂＺ＿ＦｕｎｃＷ”は、他のテストケースの実行を開始する際に実行されるブレークポイント用の関数である。すなわち、“ＬｉｂＺ＿ＦｕｎｃＷ”を呼び出すことでデバッガ１７０に単体テストを中断させ、当該テストケース用のコンテキストの取得およびデバッガ１７０に対するテスト用のブレークポイントの設定を行える。
【０１０４】
初期化部１３０は、“ｇｄｂ＿ｃｏｍｍａｎｄ＿ｆｉｌｅ”で指定される初期化ファイルに上記コマンド文字列の内容を記述する（２８〜３３行目）。当該初期化ファイルによって、デバッガ１７０に対し、アタッチ対象（プロセスＩＤ）、テストごとの設定を行うためのブレークポイント（ＬｉｂＺ＿ＦｕｎｃＷ）および中断したプログラムの再開コマンド（ｃｏｎｔｉｎｕｅ）を指定できる。
【０１０５】
次に、図１２に示す記述内容を説明する。
初期化部１３０は、コンテキスト取得部１５０、監視部１６０、デバッガ１７０およびプログラム群１８０，１８０ａ，１８０ｂで利用できるプロセス間通信用のチャネルを生成する（３６行目）。初期化部１３０は、監視部１６０（監視プロセス“Ｗａｔｃｈｐｒｏｃ”）を起動する（５１行目）。その際、引数“ｇｄｂ＿ｃｏｍｍａｎｄ＿ｆｉｌｅ”によって、初期化ファイルを指定する。
【０１０６】
図１３は、テスト準備処理を行う第１のプログラムの具体例を示す図である。プログラム２３０は、コンテキスト取得部１５０の処理を記述したものである。コンテキスト取得部１５０は、テストケース１４０からコンテキストパターン名を取得する。すると、コンテキスト記憶部１１０に格納されたコンテキストファイル１１１を参照し、取得したコンテキストパターン名に対応するコンテキストを取得する（７行目）。更に、コンテキスト取得部１５０は、取得したコンテキストに含まれるパラメータを、監視部１６０に出力する。
【０１０７】
そして、コンテキスト取得部１５０は、“ＬｉｂＺ＿ＦｕｎｃＷ”を呼び出す。
図１４は、テスト準備処理を行う第２のプログラムの具体例を示す図である。プログラム２４０は、コンテキスト取得部１５０の処理を記述したものである。関数“ＬｉｂＺ＿ＦｕｎｃＷ”はデバッガ１７０にテスト処理を中断させるためのダミー関数である。
【０１０８】
図１５〜図１７は、テスト準備処理を行う第３のプログラムの具体例を示す図である。プログラム２５０は、監視部１６０の処理を記述したものである。
監視部１６０は、デバッガ１７０の出力を参照して以下の処理を実行する。監視部１６０につき、以下の（１）〜（６）を実現する機能を監視スレッドと呼ぶこととする。
【０１０９】
（１）デバッガ１７０の標準出力を読み取る（１２行目）。
（２）ブレークポイントでの中断を検知する（１５行目）。
（３）ブレークポイントでの中断が、コンテキストに設定された条件を満たすものか判定する（１７行目）。
【０１１０】
（４）（３）でコンテキストに設定された条件を満たすものである場合、累積回数をインクリメントする（２０行目）。
（５）累積回数が指定回数に達したか判定する（２２行目）。
【０１１１】
（６）（５）で累積回数が指定回数に達した場合、発生させる例外を指定するパラメータをデバッガ１７０に出力する（２５行目）。
次に、図１６に示す記述内容を説明する。図１６に示す記述内容の処理は、コンテキスト取得部１５０によって、監視部１６０の起動が行われた際に実行される。
【０１１２】
監視部１６０は、図１５で説明した監視スレッドを起動する（３９行目）。また、監視部１６０は、デバッガ１７０の出力を参照するために、デバッガ１７０との間の通信用のチャネルを生成する（４５行目）。監視部１６０は、デバッガ１７０を起動する（６０行目）。その際、引数“ｇｄｂ＿ｃｏｍｍａｎｄ＿ｆｉｌｅ”によって、初期化ファイルを指定し、デバッガ１７０に当該初期化ファイルに記述されたコマンドを読み込ませる。
【０１１３】
次に、図１７に示す記述内容を説明する。図１７に示す記述内容の処理は、コンテキスト取得部１５０からコンテキストに設定されたパラメータを取得した際に実行される。
監視部１６０は、コンテキスト取得部１５０からコンテキストに設定されたパラメータを受け付ける（６９行目）。監視部１６０は、各パラメータの内容を解析し、その結果、デバッガ１７０および例外発生用ライブラリ１８３の処理に必要な情報をデバッガ１７０および例外発生用ライブラリ１８３に出力する（７２行目〜８１行目）。
【０１１４】
ここで、プログラム２５０中、関数“ＬｉｂＸ”は、例外発生用ライブラリ１８３を示す。次に、例外発生用ライブラリ１８３のプログラム例を説明する。
図１８は、例外発生用ライブラリの具体例を示す図である。プログラム２６０は、例外発生用ライブラリ１８３の内容を記述したものである。例外発生用ライブラリ１８３では、変数“ＬｉｂＸ＿ｅｘｃｅｐｔｉｏｎ”が定義されている（６行目）。当該変数は、デバッガ１７０によって設定される。具体的には、監視部１６０のプログラム２５０の“ｊｕｍｐ＿ＬｉｂＸ（ｐＣｏｎｔｒｏｌ）”（プログラム２５０の２５行目）において、当該変数に対する情報の設定や発生させる例外をデバッガ１７０に指示する。その内容は、例えば次の通りである。
【０１１５】
（１）監視部１６０は、デバッガ１７０に“ＬｉｂＸ＿ｅｘｃｅｐｔｉｏｎ  ＝  （ｖｏｉｄ＊）＿＿ｃｘａ＿ａｌｌｏｃａｔｅ＿ｅｘｃｅｐｔｉｏｎ（例外の型サイズ）”を実行させる。そして、単体テストの内容に応じて、“ＬｉｂＸ＿ｅｘｃｅｐｔｉｏｎ”に情報を設定させる。
【０１１６】
（２）その後、監視部１６０は例外発生用ライブラリ１８３のプログラム２６０から関数“ＬｉｂＸ＿ＦｕｎｃＸ”を呼び出すようデバッガ１７０に指示する。
関数“ＬｉｂＸ＿ＦｕｎｃＸ”では、デバッガ１７０によって設定された変数を用いて、例外（＿＿ｃｘａ＿ｔｈｒｏｗ（ＬｉｂＸ＿ｅｘｃｅｐｔｉｏｎ），＆ｔｙｐｅｉｄ（ＬｉｂＸ＿ｅｘｃｅｐｔｉｏｎ），ＮＵＬＬ）を発生（スロー）させる（１６行目）。
【０１１７】
なお、プログラム２６０の例では、変数として“ＬｉｂＸ＿ｅｘｃｅｐｔｉｏｎ”のみを利用することとしたが、更に複数の情報を用いてもよい。また、当該情報を用いた他の復帰情報を設定することもできる。
【０１１８】
図１９は、テスト対象プログラムの具体例を示す図である。プログラム２７０は、テスト対象プログラム１８１の内容を記述したものである。テスト対象プログラム１８１では、クラス“ＣｌａｓｓＸ”のメソッド“ＭｅｔｈｏｄＡ”が定義されている（１行目）。
【０１１９】
“ＭｅｔｈｏｄＡ”では、外部ライブラリの関数“＿Ｌｉｂ＿Ｏｕｔｅｒ＿Ｖｅｎｄｅｒ＿Ｆｕｎｃ”を呼び出している（５行目）。この関数の処理時に例外を捕捉（キャッチ）すると、例外処理を行う（６，７行目）。
【０１２０】
図２０は、テストケースの具体例を示す図である。プログラム２８０は、テストケース１４０の内容を記述したものである。テストケース１４０では、テスト対象プログラム１８１の単体テストを行うメソッドとしてクラス“Ｔｅｓｔｃａｓｅ１”のメソッド“ＴｅｓｔＸ（）”が定義されている（１行目）。更に、テスト対象プログラム１８１内のクラス“ＣｌａｓｓＸ”を宣言している（３行目）。
【０１２１】
テストケース１４０では、単体テストを行う前に、コンテキストパターン名“ＰＡＴＴＥＲＮ＿０００１”を指定している（７行目）。
また、テストケース１４０では、テスト対象のメソッドを実行し、当該コンテキストパターン名で指定されるコンテキストによって、正しく例外が発生されたかを検査する処理が定義されている（１４〜２８行目）。当該処理には、次のプログラムのテストに備えて、現在使用中のコンテキストの設定をクリアする処理“ＬｉｂＺ＿ＦｕｎｃＢ（）”が含まれている（２０，２７行目）。更に、テストを正常に実行できた場合の処理（１８行目）およびテストを正常に実行できなかった場合の処理（２８行目）が含まれている。
【０１２２】
以上、図１０〜図２０に例示したプログラムを用いて、図６〜図９に示した処理を実現することができる。次に、単体テストにおいて例外を発生させる処理の具体例を説明する。
【０１２３】
図２１は、単体テストにおいて例外を発生させる処理の流れの具体例を示す図である。以下、図２１に示す処理をステップ番号に沿って説明する。なお、以下の説明では、コンテキストパターン名として“ＰＡＴＴＥＲＮ＿０００１”が指定された場合を例示する。
【０１２４】
まず、テストケース１４０がテスト対象プログラム１８１の実行を開始する（ステップＳＴ１１）。
次に、テスト対象プログラム１８１の処理が開始される。テスト対象プログラム１８１の処理では、ライブラリ１８２の関数“＿Ｌｉｂ＿Ｏｕｔｅｒ＿Ｖｅｎｄｅｒ＿Ｆｕｎｃ”が呼び出される（ステップＳＴ１２）。
【０１２５】
ステップＳＴ１２において、デバッガ１７０は、当該関数が呼び出されたのでブレークポイントとしてテスト対象プログラム１８１の処理を中断させる。デバッガ１７０は、テスト対象プログラム１８１による処理経過を標準出力用のファイルに記録している。監視部１６０は、当該標準出力用のファイルを参照し、当該コンテキストに設定された関数の呼出関係等が満たされていれば、指定条件発生回数管理テーブル１１２を更新する（回数累計に１加算する）。満たされていなければ、更新しない。監視部１６０は、回数累計に基づいて現ブレークポイントで例外を発生させるかを判定する。ここでは、コンテキストに設定された条件が満たされてないため、例外を発生させないと判定する。
【０１２６】
そして、デバッガ１７０によりライブラリ１８２の処理が継続される。その結果、ライブラリ１８２の当該関数による処理が完了される。テスト対象プログラム１８１は、その処理結果を取得して、処理を継続する（ステップＳＴ１３）。
【０１２７】
以後、上記ステップＳＴ１２，ＳＴ１３と同様の処理が繰り返し実行される（ステップＳＴ１４，ＳＴ１５，・・・）。監視部１６０は、デバッガ１７０によりブレークポイントが発生するたびに、指定条件発生回数管理テーブル１１２を更新する。
【０１２８】
更にその後、テスト対象プログラム１８１の処理において、ライブラリ１８２の上記関数が呼び出される（ステップＳＴ２１）。監視部１６０は、指定条件発生回数管理テーブル１１２を更新後、回数累計に基づき現ブレークポイントで例外を発生させるかを判定する。ここでは、コンテキストに設定された指定回数に達し、例外を発生させると判定する。すると、監視部１６０は、デバッガ１７０に例外の発生を指示する。発生を指示する例外は、コンテキストに設定された“ＬｉｂＸ＿ＦｕｎｃＸ”である。このとき、例外の発生に用いるパラメータがコンテキストに設定されている場合には、監視部１６０は、当該パラメータの内容もデバッガ１７０に通知できる。例えば、その内容は、プログラム２６０で示した“ＬｉｂＸ＿ｅｘｃｅｐｔｉｏｎ”に設定されてデバッガ１７０に渡される。
【０１２９】
デバッガ１７０は、監視部１６０の指示に基づいて、例外発生用ライブラリ１８３の“ＬｉｂＸ＿ＦｕｎｃＸ”を呼び出し、例外を発生させる（ステップＳＴ２２）。
例外発生用ライブラリ１８３の処理により当該例外がスローされる。テスト対象プログラム１８１の処理により例外がキャッチされる（ステップＳＴ２３）。
【０１３０】
テスト対象プログラム１８１は、テストケース１４０に処理結果を応答する（ステップＳＴ２４）。テストケース１４０は、コンテキストの設定に応じた単体テストが適正に行われたか否かを判定する。そして、単体テストの実行結果をソフトウェア管理者に通知する。ソフトウェア管理者は、例えばモニタ１１に表示された実行結果を参照して、単体テストの結果を確認できる。また、例えば、当該実行結果をログファイルに出力しておき、当該ログファイルを後から参照することで、単体テストの結果を確認することもできる。
【０１３１】
このようにして、ソフトウェア開発支援装置１００は、コンテキストファイル１１１に設定されたコンテキストに基づいて、テスト対象プログラムの処理経過に応じた詳細な単体テストを効率的に行えるようになる。
【０１３２】
例えば、監視部１６０が当該コンテキストに基づいて、例外を発生させるタイミングを特定し、デバッガ１７０に例外の発生を指示することで、テストを行いたい事象を詳細に特定してテストを行える。具体的には、監視部１６０は、関数間の呼出関係や当該呼出関係により対象の関数が何回呼び出されたかを判断する。
【０１３３】
ここで、従来の方法のように、例えばデバッガ１７０のみを用いてテストを行うとすると、デバッガ１７０はブレークポイントとして指定したタイミングで例外を発生させることとなる。すると、テスト対象の関数につき、本来テストしたい呼出元以外の呼出元から呼び出された場合でも例外を発生させてテストを行ってしまうことも考えられる。なぜなら、テスト対象プログラムが汎用的なライブラリを用いる場合、当該ライブラリ内の同一の関数が、テスト対象プログラム内の複数の関数によって呼び出されることもあるからである。
【０１３４】
これに対して、ソフトウェア開発支援装置１００では、関数間の呼出関係に基づいて、例外を発生させることができる。このため、ライブラリ内の関数につき、テストしたい状況を適切に指定してテストを行うことができる。
【０１３５】
また、関数呼出の回数に応じて例外を発生できるので、テスト対象プログラム１８１の処理の進行に応じて、当該プログラムの内部で管理される変数等の変化に追随したテストを容易に行える。例えば、当該関数において処理が所定回数だけ正常終了した後に、例外が発生するようなケースをテストしたい場合が考えられる。その場合にも、コンテキストに指定回数を設定することで、当該テストを容易に行える。
【０１３６】
また、コンテキストファイル１１１にコンテキストを設定しておけば、テストケースからの指定に応じて、順次コンテキストを読み出してテストを実行できる。このため、従来のように、テスト内容に応じた状況を記述したプログラムを別途作成しなくてもよい。よって、単体テストに要する作業工数を低減できる。
【０１３７】
更に、第２の実施の形態では、監視部１６０とデバッガ１７０とを別個に設け、デバッガ１７０が提供する機能を利用可能とした。このようにデバッガ１７０の機能を流用することで、ソフトウェア開発支援装置１００の機能を容易に実現できる。
【０１３８】
また、コンテキストファイル１１１をコンテキスト記憶部１１０に格納することで、コンテキストの内容を容易に管理できる。例えば、テストケースごとにコンテキストの内容に合わせてテストケースのプログラム内に作り込みを行うよりも、コンテキストの内容の変更や追加を容易に行える。
【０１３９】
なお、上記の例では各テストケースで使用するコンテキストを各テストケースの実行開始時に、コンテキスト取得部１５０に通知するものとした。これに対し、コンテキスト取得部１５０が、各テストケースまたは各テスト対象プログラムの実行開始を検知して、各テストケースに応じたコンテキストをコンテキストファイル１１１から取得してもよい。例えば、コンテキスト取得部１５０がテストケース１４０のメソッド“Ｔｅｓｔｃａｓｅ１：：ＴｅｓｔＸ（）”の実行開始を検知して、コンテキストパターン“ＰＡＴＴＥＲＮ＿０００１”を取得するようにしてもよい。このようにすれば、各テストケース内で特に明示しなくても、適切なコンテキストを自動的に選択して単体テストを行える。よって、複数のプログラムについての単体テストを一層効率化できる。
【０１４０】
以上、本発明のソフトウェア開発支援プログラム、ソフトウェア開発支援装置およびソフトウェア開発支援方法を図示の実施の形態に基づいて説明したが、これらに限定されるものではなく、各部の構成は同様の機能を有する任意の構成のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。更に、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。
【符号の説明】
【０１４１】
１  ソフトウェア開発支援装置
１ａ  記憶手段
１ｂ  実行手段
１ｃ  特定手段
１ｄ  テスト処理手段
【図１】
2012108692.tif 000003
【図２】
2012108692.tif 000004
【図３】
2012108692.tif 000005
【図４】
2012108692.tif 000006
【図５】
2012108692.tif 000007
【図６】
2012108692.tif 000008
【図７】
2012108692.tif 000009
【図８】
2012108692.tif 000010
【図９】
2012108692.tif 000011
【図１０】
2012108692.tif 000012
【図１１】
2012108692.tif 000013
【図１２】
2012108692.tif 000014
【図１３】
2012108692.tif 000015
【図１４】
2012108692.tif 000016
【図１５】
2012108692.tif 000017
【図１６】
2012108692.tif 000018
【図１７】
2012108692.tif 000019
【図１８】
2012108692.tif 000020
【図１９】
2012108692.tif 000021
【図２０】
2012108692.tif 000022
【図２１】
2012108692.tif 000023