JP2009169828A - テストケース生成装置及びテストケース生成プログラム - Google Patents

Abstract

【課題】自動テストケース生成の性能限界を緩和する。
【解決手段】テストケースを生成する対象のモデルにソースコードの検査が完了している検査済部分が存在するか否かを、検査済部分を識別可能な検査情報に基づき判定し（Ｓ１０１）、検査済部分が存在すると判定した場合には（Ｓ１０１：ＹＥＳ）、その検査済部分を簡略化することで検査対象のモデルを簡略化し（Ｓ１０２）、簡略化したモデルに基づいてテストケースを生成する（Ｓ１０３）。このため、生成するテストケースのパターン数を減らすことができ、その結果、自動テストケース生成の性能限界を緩和することができる。
【選択図】図３

Description

本発明は、テストケースを自動的に生成するためのテストケース生成装置に関するものである。

従来、例えば車両のエンジンＥＣＵの作動等、信号入出力制御のためのプログラムにおいては、開発者が直接そのプログラムのソースコードを記述せず、目的とするプログラムの機能を、より作成が簡易で視認性の良い「モデル」という形態で記述する場合がある。

開発者は、このモデルに対応したプログラム開発環境がインストールされたワークステーションやパーソナルコンピュータ等を用い、このモデルによって定義されたデータの入出力のシミュレーションを行い、モデルに基づきソースコードを生成する。

モデルからソースコードを生成するようなプログラム開発は、モデルベース開発と呼ばれる。モデルベース開発に対応したプログラム開発環境としては、例えば、ＭａｔｈＷｏｒｋｓ社のＭＡＴＬＡＢ（登録商標）がある。ＭＡＴＬＡＢ（登録商標）においては、開発者はＭＡＴＬＡＢ（登録商標）に対する付加機能を提供するソフトウェアであるＳｉｍｕｌｉｎｋ（登録商標）を用いて、目的とするデータ入出力を表現するモデルを記述する。

モデルは、データ演算、データ入力及びデータ出力のうち少なくともいずれか１つの機能を実現する機能単位としてのブロック、及びブロック間の入出力関係を示す結線の組合せとして記述される。すなわち、複数のブロックが結線によってつなぎ合わされることにより、車両制御等のデータ入出力を表現する集合体がモデルである。

このようなモデルベース開発環境においては、モデルからソースコードへの変換が意図したとおり適正に行われているか、すなわち、モデルの表す処理内容がソースコードに正しく反映されているかを判断するための検査が行われる。この検査には、モデルの表す処理内容（例えば命令分岐の条件等）に基づき、できるだけ多くの命令分岐先の処理が実行されるようなテスト用入力データ（テストケース）が用いられる。

そして、こうしたテストケースを自動的に生成する技術が既に知られている（特許文献１参照）。この技術では、モデルを入力し、そのロジック中の分岐条件等を解析してテストケースを自動的に生成する。このとき、テストケースはすべてのロジックを通過することを目標として生成される。
特開２００６−２４００６号公報

しかしながら、テストケースを生成する対象のモデルが複雑な場合、コンピュータで解析できる限界を超え、有効なテストケースが得られなかったり、テストケースの生成に多大な時間を要したりする場合がある。この場合、人手によりテストケースを補う必要があり、自動テストケース生成が本来ねらうソフトウェア開発の効率化効果が著しく損なわれてしまう。

本発明は、こうした問題にかんがみてなされたものであり、自動テストケース生成の性能限界を緩和することを目的としている。

上記目的を達成するためになされた本発明の請求項１に記載のテストケース生成装置は、処理内容を表すモデルに基づき生成されたソースコードを検査するためのテストケースを、モデルに基づいて生成するものである。そして、このテストケース生成装置では、判定手段が、テストケースを生成する対象のモデルにソースコードの検査が完了している検査済部分が存在するか否かを、検査済部分を識別可能な検査情報に基づき判定し、判定手段により検査済部分が存在すると判定された場合には、生成手段が、その検査済部分を簡略化したモデルに基づいてテストケースを生成する。

すなわち、例えば車載ソフトウェアなどのように、既存のソフトウェアからの変更による開発（差分開発）が行われるものでは、過去の開発で既にソースコードの検査が完了している検査済部分が存在する場合がある。この場合、検査済部分を簡略化することによって、自動テストケース生成時間の短縮・性能限界の補完を図ることが可能となる。

したがって、本発明のテストケース生成装置によれば、テストケースを生成する対象のモデルをあらかじめ簡略化することで、生成するテストケースのパターン数を減らすことができる。この結果、自動テストケース生成の性能限界を緩和することができ、複雑なモデルについてもテストケースを自動的に生成することが可能となる。

ところで、モデルにおける検査済部分の判定は、例えば請求項２に記載のように行うことができる。すなわち、請求項２に記載のテストケース生成装置では、判定手段は、モデルにその属性情報として埋め込まれた検査情報に基づき検査済部分が存在するか否かを判定する。このようなテストケース生成装置によれば、検査済部分を容易かつ確実に判定することができる。

そして、このような検査情報は、例えば請求項３に記載のように書き込まれるようにするとよい。すなわち、請求項３に記載のテストケース生成装置では、検査手段が、生成手段により生成されたテストケースを用いてソースコードの検査を行い、検査手段による検査結果が合格の場合に、書込手段が、モデルの属性情報として検査済であることを示す検査情報を書き込む。このようなテストケース生成装置によれば、検査情報がモデルの属性情報として自動的に書き込まれるようにすることができる。

一方、請求項４に記載のテストケース生成装置では、判定手段は、データベースに記憶された検査情報に基づき検査済部分が存在するか否かを判定する。このようなテストケース生成装置によれば、モデル自体に検査情報を埋め込むことなく、検査済部分を容易かつ確実に判定することができる。

ここで、検査情報は、例えば請求項５に記載のように、モデルの検査済部分の識別情報とすることができる。このようにすれば、モデルの検査済部分のデータ自体を記憶するのに比べ、検査情報として記憶するデータ量を小さくすることができる。

一方、例えば請求項６に記載のように、モデルの検査済部分のデータ自体を検査情報として記憶するようにすれば、例えば、モデルのデータの一部（識別情報等）が変更された場合にも、実質的な内容に基づき同一のモデルであると判定するといったように、柔軟な判定が可能となる。

また、検査情報は、例えば請求項７に記載のように、モデルの検査済部分に対応するソースコードとすることもできる。このようにしても、請求項６と同様、柔軟な判定が可能となる。

そして、このような検査情報は、例えば請求項８に記載のように記憶されるようにするとよい。すなわち、請求項８に記載のテストケース生成装置では、検査手段が、生成手段により生成されたテストケースを用いてソースコードの検査を行い、検査手段による検査結果が合格の場合に、書込手段が、モデルについての検査情報をデータベースに書き込む。このようなテストケース生成装置によれば、検査情報がデータベースに自動的に書き込まれるようにすることができる。

ところで、検査済部分の簡略化は、例えば請求項９や請求項１０に記載のように行うことができる。
すなわち、請求項９に記載のテストケース生成装置では、生成手段は、モデルの検査済部分の分岐処理を１つの経路に固定することでモデルを簡略化する。このようなテストケース生成装置によれば、モデルの構成を大きく変更することなくモデルを簡略化することができる。

また、請求項１０に記載のテストケース生成装置では、生成手段は、モデルの検査済部分を削除することでモデルを簡略化する。このようなテストケース生成装置によれば、モデルを効率よく簡略化することができる。

次に、請求項１１に記載のテストケース生成プログラムは、処理内容を表すモデルに基づき生成されたソースコードを検査するためのテストケースを、モデルに基づいて生成するテストケース生成装置としてコンピュータを機能させるためのものである。そして、このテストケース生成プログラムは、テストケースを生成する対象のモデルにソースコードの検査が完了している検査済部分が存在するか否かを、検査済部分を識別可能な検査情報に基づき判定する判定手段と、判定手段により検査済部分が存在すると判定された場合には、その検査済部分を簡略化したモデルに基づいてテストケースを生成する生成手段としてコンピュータを機能させる。

このようなテストケース生成プログラムによれば、請求項１のテストケース生成装置としてコンピュータを機能させることができ、これにより前述した効果を得ることができる。

以下、本発明が適用された実施形態について、図面を用いて説明する。
［第１実施形態］
図１は、第１実施形態のテストケース生成装置としてのパーソナルコンピュータ１の構成を示すブロック図である。

同図に示すように、このパーソナルコンピュータ１は、ディスプレイ１１、入力装置１２、ＲＡＭ１３、ＲＯＭ１４、ＨＤＤ（ハードディスクドライブ）１５、ＣＰＵ（演算装置）１６を備える。

ディスプレイ１１は、ＣＰＵ１６から受けた映像信号を、ユーザに対して映像として表示する。
入力装置１２は、キーボード、マウス等から構成され、ユーザが操作することにより、その操作に応じた信号をＣＰＵ１６に出力する。

ＲＡＭ１３は読み出し、書き込み可能な揮発性メモリであり、ＲＯＭ１４は読み出し専用の不揮発性メモリであり、ＨＤＤ１５は読み出し、書き込み可能な不揮発性メモリである。ＲＯＭ１４、ＨＤＤ１５には、ＣＰＵ１６が読み出して実行するプログラム等があらかじめ記憶されている。またＨＤＤ１５には、後述するモデルが記憶されている。

ＲＡＭ１３は、ＣＰＵ１６がＲＯＭ１４、ＨＤＤ１５に記憶されたプログラムを実行する際に、そのプログラムを一時的に保存するための記憶領域、及び作業用のデータを一時的に保存するための記憶領域として用いられる。

ＣＰＵ１６は、パーソナルコンピュータ１に電源が投入されることによって起動すると、ＲＯＭ１４から所定のブートプログラムを読み出して実行し、このブートプログラムに規定されるオペレーティングシステム（ＯＳ）その他のプログラムをＨＤＤ１５から読み出して実行することにより、起動処理を行う。起動処理以後、電源が遮断されるまで、ＣＰＵ１６は、入力装置１２からの信号や、ＯＳによってあらかじめ定められたスケジュール等に基づいて、ＨＤＤ１５に記録されている各種プログラムをＯＳ上のプロセスとして実行する。また、上記の起動処理及びプロセスにおいて、ＣＰＵ１６は必要に応じて入力装置１２から信号の入力を受け付け、またディスプレイ１１に映像信号を出力し、またＲＡＭ１３、ＨＤＤ１５に対してデータの読み出し／書き込みの制御を行う。

次に、パーソナルコンピュータ１によって実行される処理の概要について説明する。
パーソナルコンピュータ１は、処理内容を表すモデルに基づき生成されたソースコード（例えば、車両制御用のＥＣＵで実行させるＣ言語のソースコード）を検査するためのテストケースを、そのモデルに基づいて生成するためのものである。

モデルは、時系列の中でのデータ演算、データ入力及びデータ出力のうち少なくともいずれか１つの機能を表すブロック（サブシステム）、及びブロック間の入出力関係を示す結線の組合せとして記述される。モデルの例としては、ＭａｔｈＷｏｒｋｓ社のＳｉｍｕｌｉｎｋ（登録商標）モデルがある。

図２（ａ）に、モデルの一例を示す。このモデルにおいて、図形３１〜３８がブロックを表し、これらブロック間を繋ぐ線が結線を表す。なお、入力ブロック３１〜３５は、外部からのデータの入力を受け、その受けたデータを結線の後段に出力する機能を表す。また、スイッチブロック３６，３７は、入力される選択信号が「１」の場合には出力信号として選択１の値を出力し、入力される選択信号が「０」の場合には出力信号として選択２の値を出力する。このモデルにおいては、スイッチブロック３６，３７への入力の結線のうち、上段、中段、下段の各結線から選択１、選択信号、選択２の各値が入力される。一方、出力ブロック３８は、結線を介して受けたデータを外部に出力する機能を有する。

このようなモデルに基づき、そのモデルの表すデータ入出力処理を実現するための処理が記述されたソースコードが生成される。なお、ソースコードの生成は、モデルに基づき自動で行うことも、プログラマが手動で行うことも可能である。

そして、生成したソースコードを、テストケース（モデルのすべてのブロック又はソースコードのすべての命令文ができる限り実行されるようなバラエティを持った入力データ）を用いて検査する。例えば、図２（ａ）のモデルは、図２（ｂ）に示すようなテストケースを用いて検査を行うことができる。このテストケースでは、スイッチブロック３６，３７の各選択信号となる入力２及び入力４の４とおりの組合せをそれぞれテストする。

このようなテストケースを用いて、モデルに基づき生成されたソースコードの検査を行う。具体的には、テストケースを用いて、モデルのシミュレーションを実行するとともにソースコード（そのモデルに基づき生成されたソースコード）を実行し、各実行結果（出力値）が一致していれば合格とする。なお、モデルのシミュレーションとは、そのモデルの表現するデータの入出力の時間変化をパーソナルコンピュータ１上で再現する処理をいう。

次に、本実施形態のテストケース生成装置でテストケースを生成するためにＣＰＵ１６が実行する自動テストケース生成処理について、図３のフローチャートを用いて説明する。なお、この自動テストケース生成処理は、ユーザによって入力装置１２を用いた実行開始の操作が行われることにより開始される。

ＣＰＵ１６は、自動テストケース生成処理を開始すると、まず、Ｓ１０１で、検査対象（テストケースを生成する対象）のモデルにソースコードの検査が完了している検査済部分が存在するか否かを判定する。本実施形態では、各ブロックの属性情報として、検査済部分を識別可能な検査情報（検査済であるか否かを示す情報）が埋め込まれており、各ブロックの属性情報を参照することにより、検査対象のモデルを構成するブロックに検査済のものが存在するか否かを判定することができる。例えば、図４に示すモデルは、サブシステムＡ〜Ｃからなるものであり、サブシステムＡには属性情報として検査済を示す情報が記憶されており、サブシステムＢ，Ｃには属性情報として未検査を示す情報が記憶されている。なお、検査情報を書き込む処理については後述する（Ｓ１０６）。

そして、Ｓ１０１で、検査対象のモデルに検査済部分が存在すると判定した場合には、Ｓ１０２へ移行し、その検査済部分を簡略化することで検査対象のモデルを簡略化した後、Ｓ１０３へ移行する。具体的には、検査済の分岐処理を１つの経路に固定することで、モデルを簡略化する。例えば、図５に示す例では、入力２（スイッチ１の選択信号）を「１」に固定することでモデルを簡略化している。なお、分岐を固定した代替部分モデルを用意しておき、差し替えるようにしてもよい。

一方、Ｓ１０１で、検査対象のモデルに検査済部分が存在しないと判定した場合には、そのままＳ１０３へ移行する。
Ｓ１０３では、検査対象のモデル（Ｓ１０２で簡略化した場合には、簡略化したモデル）に基づき、テストケースを生成する。

続いて、Ｓ１０４では、Ｓ１０３で生成したテストケースを用いて、検査対象のモデルに基づき別途生成されたソースコードの検査を行う。
続いて、Ｓ１０５では、Ｓ１０４での検査結果が合格であるか否かを判定する。

そして、Ｓ１０５で、検査結果が合格であると判定した場合には、Ｓ１０６へ移行し、検査対象のモデルの属性情報として検査済を示す検査情報を書き込む。その後、本自動テストケース生成処理を終了する。

一方、Ｓ１０５で、検査結果が合格でないと判定した場合には、そのまま本自動テストケース生成処理を終了する。
以上説明したように、第１実施形態のパーソナルコンピュータ１は、検査対象のモデルに検査済部分が存在するか否かを判定し（Ｓ１０１）、検査済部分が存在すると判定した場合には（Ｓ１０１：ＹＥＳ）、その検査済部分を簡略化したモデルに基づいてテストケースを生成する（Ｓ１０２，Ｓ１０３）。このため、生成するテストケースのパターン数を減らすことができる。その結果、自動テストケース生成の性能限界を緩和することができる。

また、このパーソナルコンピュータ１では、モデルに埋め込まれた属性情報に基づき検査済部分が存在するか否かを判定するようにしているため、検査済部分を容易かつ確実に判定することができる。特に、このパーソナルコンピュータ１では、生成されたテストケースを用いてソースコードの検査を行い（Ｓ１０４）、その検査結果が合格の場合に（Ｓ１０５：ＹＥＳ）、モデルの属性情報として検査済であることを示す情報を書き込む（Ｓ１０６）。このため、検査済であることを示す情報がモデルの属性情報として自動的に書き込まれるようにすることができる。

さらに、このパーソナルコンピュータ１では、モデルの検査済部分の分岐処理を１つの経路に固定することでモデルを簡略化するようにしているため、モデルの構成を大きく変更することなくモデルを簡略化することができる。

なお、第１実施形態のパーソナルコンピュータ１では、Ｓ１０１の処理を実行するＣＰＵ１６が判定手段に相当し、Ｓ１０２，Ｓ１０３の処理を実行するＣＰＵ１６が生成手段に相当する。また、Ｓ１０４の処理を実行するＣＰＵ１６が検査手段に相当し、Ｓ１０５，Ｓ１０６の処理を実行するＣＰＵ１６が書込手段に相当する。

［第２実施形態］
次に、第２実施形態のパーソナルコンピュータ１について説明する。
第２実施形態のパーソナルコンピュータ１は、基本的な構成は図１に示す第１実施形態のパーソナルコンピュータ１と同一であるが、検査対象のモデルに検査済部分が存在するか否かを判定する方法が異なる。そこで、第１実施形態と共通する部分については同一符号を用いて説明を省略する。

第２実施形態のパーソナルコンピュータ１においても、第１実施形態と同様の自動テストケース生成処理（図３）をＣＰＵ１６が実行する。ただし、Ｓ１０１及びＳ１０６の処理内容が若干異なる。

Ｓ１０１では、検査対象のモデルに検査済部分が存在するか否かを判定する。本第２実施形態では、検査済のモデル（ブロック）の識別情報（例えばサブシステム名）が検査情報（検査実施履歴情報）としてＨＤＤ１５のデータベースに記憶されており、そのデータベースを参照することにより、検査対象のモデルを構成するブロックに検査済のものが存在するか否かを判定する。例えば、図６に示すモデルは、サブシステムＡ〜Ｃからなるものであり、データベースには、サブシステムＡが検査済であることを示す検査情報が記憶されている。

また、Ｓ１０６では、検査対象のモデルの検査情報としてモデル名（サブシステム名）をＨＤＤ１５に書き込む。例えば、既存の表計算ソフトのデータファイルとして記憶させておくことができる。

以上説明したように、第２実施形態のパーソナルコンピュータ１では、データベースに記憶されている検査情報に基づき検査済部分が存在するか否かを判定するようにしているため、モデル自体に余分な情報を埋め込むことなく、検査済部分を容易かつ確実に判定することができる。また、データベースをサーバで集中管理するといったシステムを構築することも可能となる。特に、モデルの識別情報を記憶するようにしているため、検査情報として記憶するデータ量を小さくすることができる。

［第３実施形態］
次に、第３実施形態のパーソナルコンピュータ１について説明する。
第３実施形態のパーソナルコンピュータ１も、基本的な構成は図１に示す第１実施形態のパーソナルコンピュータ１と同一であるが、検査対象のモデルに検査済部分が存在するか否かを判定する方法が異なる。そこで、第１実施形態と共通する部分については同一符号を用いて説明を省略する。

第３実施形態のパーソナルコンピュータ１においても、第１実施形態と同様の自動テストケース生成処理（図３）をＣＰＵ１６が実行する。ただし、Ｓ１０１及びＳ１０６の処理内容が若干異なる。

Ｓ１０１では、検査対象のモデルに検査済部分が存在するか否かを判定する。本第３実施形態では、検査済のモデル（ブロック）のデータ自体が検査情報としてＨＤＤ１５のデータベースに記憶されており、そのデータを参照して例えばパターンマッチングによってサブシステムの内容の一致を確認することにより、検査対象のモデルを構成するブロックに検査済のものが存在するか否かを判定する。例えば、図７に示すモデルは、サブシステムＡ〜Ｃからなるものであり、データベースには、サブシステムＡのデータ自体が検査情報として記憶されている。

また、Ｓ１０６では、検査対象のモデルの検査情報としてモデルのデータ自体をＨＤＤ１５に書き込む。
以上説明したように、第３実施形態のパーソナルコンピュータ１によれば、モデルのデータ自体を記憶するようにしているため、モデルのデータの一部（サブシステム名や、モデルエディタにおけるブロック座標のずれ等）が変更された場合にも、ロジックが同じであれば同一のモデルであると判定するといったように、柔軟な判定が可能となる。加えて、図８に示すように、データベースに記憶された検査済モデルを用いて（ライブラリリンクで参照して）新規モデルの作成を効率よく行うことも可能となる。

［第４実施形態］
次に、第４実施形態のパーソナルコンピュータ１について説明する。
第４実施形態のパーソナルコンピュータ１も、基本的な構成は図１に示す第１実施形態のパーソナルコンピュータ１と同一であるが、検査対象のモデルに検査済部分が存在するか否かを判定する方法が異なる。そこで、第１実施形態と共通する部分については同一符号を用いて説明を省略する。

第４実施形態のパーソナルコンピュータ１においても、第１実施形態と同様の自動テストケース生成処理（図３）をＣＰＵ１６が実行する。ただし、Ｓ１０１及びＳ１０６の処理内容が若干異なる。

Ｓ１０１では、検査対象のモデルに検査済部分が存在するか否かを判定する。本第４実施形態では、検査済のモデル（ブロック）に対応するソースコードが検査情報としてＨＤＤ１５のデータベースに記憶されており、そのソースコードを参照して生成済みのソースコードとの一致を確認することにより、検査対象のモデルを構成するブロックに検査済のものが存在するか否かを判定する。例えば、図９に示すモデルは、サブシステムＡ〜Ｃからなるものであり、データベースには、サブシステムＡのソースコードが検査情報として記憶されている。

また、Ｓ１０６では、検査対象のモデルの検査情報としてモデルのソースコードをＨＤＤ１５に書き込む。
以上説明したように、第４実施形態のパーソナルコンピュータ１によれば、モデルのソースコードを記憶するようにしているため、前述した第３実施形態と同様の効果を得ることができる。

［変形例］
以上、本発明の実施形態について説明したが、本発明は、上記実施形態に限定されることなく、種々の形態を採り得ることは言うまでもない。

上記各実施形態では、検査済の分岐処理を１つの経路に固定することで、モデルを簡略化するようにしているが、これに限定されるものではなく、例えば図１０に示すように、モデルの検査済部分のロジックを削除することでモデルを簡略化するようにしてもよい。このようにすれば、モデルを効率よく簡略化することができる。

また、上記各実施形態では、テストケースの生成後にソースコードの検査を連続して行う処理を例示したが、これに限定されるものではなく、別々に行うようにしてもよい。
さらに、上記各実施形態では、ソースコードの検査結果に基づき検査済の情報を自動的に書き込むようにしているが、これに限定されるものではなく、例えばモデルの作成時などに作成者が手動で書き込むようにしてもよい。

実施形態のパーソナルコンピュータの構成を示すブロック図である。 モデル及びテストケースの説明図である。 自動テストケース生成処理のフローチャートである。 属性情報として検査情報が埋め込まれたモデルの説明図である。 検査済の分岐処理を１つの経路に固定するモデルの簡略化の説明図である。 検査情報がデータベースに記憶されたモデルの説明図である。 検査済モデルのデータ自体がデータベースに記憶されたモデルの説明図である。 データベースに記憶された検査済モデルを用いて新規モデルを作成する説明図である。 検査済モデルのソースコードがデータベースに記憶されたモデルの説明図である。 モデルの検査済部分のロジックを削除するモデルの簡略化の説明図である。

符号の説明

１…パーソナルコンピュータ、１１…ディスプレイ、１２…入力装置、１３…ＲＡＭ、１４…ＲＯＭ、１５…ＨＤＤ、１６…ＣＰＵ

Claims (11)

1. 処理内容を表すモデルに基づき生成されたソースコードを検査するためのテストケースを、前記モデルに基づいて生成するテストケース生成装置であって、
   前記テストケースを生成する対象のモデルにソースコードの検査が完了している検査済部分が存在するか否かを、検査済部分を識別可能な検査情報に基づき判定する判定手段と、
   前記判定手段により検査済部分が存在すると判定された場合には、その検査済部分を簡略化したモデルに基づいて前記テストケースを生成する生成手段と、
   を備えることを特徴とするテストケース生成装置。
2. 前記判定手段は、前記モデルにその属性情報として埋め込まれた前記検査情報に基づき検査済部分が存在するか否かを判定すること
   を特徴とする請求項１に記載のテストケース生成装置。
3. 前記生成手段により生成されたテストケースを用いて前記ソースコードの検査を行う検査手段と、
   前記検査手段による検査結果が合格の場合に、前記モデルの属性情報として検査済であることを示す検査情報を書き込む書込手段と、
   を備えることを特徴とする請求項２に記載のテストケース生成装置。
4. 前記判定手段は、データベースに記憶された前記検査情報に基づき検査済部分が存在するか否かを判定すること
   を特徴とする請求項１に記載のテストケース生成装置。
5. 前記データベースには、前記検査情報として前記モデルの検査済部分の識別情報が記憶されること
   を特徴とする請求項４に記載のテストケース生成装置。
6. 前記データベースには、前記検査情報として前記モデルの検査済部分のデータ自体が記憶されること
   を特徴とする請求項４に記載のテストケース生成装置。
7. 前記データベースには、前記検査情報として前記モデルの検査済部分に対応するソースコードが記憶されること
   を特徴とする請求項４に記載のテストケース生成装置。
8. 前記生成手段により生成されたテストケースを用いて前記ソースコードの検査を行う検査手段と、
   前記検査手段による検査結果が合格の場合に、前記モデルについての前記検査情報を前記データベースに書き込む書込手段と、
   を備えることを特徴とする請求項４から請求項７までのいずれか１項に記載のテストケース生成装置。
9. 前記生成手段は、前記モデルの検査済部分の分岐処理を１つの経路に固定することで前記モデルを簡略化すること
   を特徴とする請求項１から請求項８までのいずれか１項に記載のテストケース生成装置。
10. 前記生成手段は、前記モデルの検査済部分を削除することで前記モデルを簡略化すること
    を特徴とする請求項１から請求項８までのいずれか１項に記載のテストケース生成装置。
11. 処理内容を表すモデルに基づき生成されたソースコードを検査するためのテストケースを、前記モデルに基づいて生成するテストケース生成装置としてコンピュータを機能させるためのテストケース生成プログラムであって、
    前記テストケースを生成する対象のモデルにソースコードの検査が完了している検査済部分が存在するか否かを、検査済部分を識別可能な検査情報に基づき判定する判定手段と、
    前記判定手段により検査済部分が存在すると判定された場合には、その検査済部分を簡略化したモデルに基づいて前記テストケースを生成する生成手段
    としてコンピュータを機能させることを特徴とするテストケース生成プログラム。