JP2009294846A - テストケース生成装置、テストケース生成プログラム、およびテストケース生成方法 - Google Patents

Abstract

【課題】モデルからテストケースを生成する技術において、モデルの複雑度が大きくなってもカバレッジ率の低下を抑える。
【解決手段】テストケース生成装置は、モデル２０中の１つのブロックの出力データ（すなわち検査項目）に対して目標値が定められている場合において、ブロックを含むサブシステム４０と、サブシステム４０の前段のサブシステム３０との境界７０を特定し、検査項目が当該目標値となるように、当該境界７０におけるサブシステム４０に対する入力データの設定値を算出する。さらに、算出した設定値を、当該境界７０における新たな目標値として設定し、さらに、境界７０における出力データを新たな検査項目として設定した上で、モデル２０のテストケースを生成する。
【選択図】図７

Description

本発明は、入力データに応じた制御処理を複数の処理要素間のデータの入出力によって記述するモデルについての、テストケース生成装置、テストケース生成プログラム、およびテストケース生成方法に関するものである。

従来、入力データに応じた制御処理（例えば、エンジン制御、ブレーキ制御等の車両制御）のためのソースコード（例えばＣソースコード）を生成する際に、複数の処理要素間のデータの入出力の仕様として制御処理を記述するモデルをまず作成し、そのモデルからソースコードを生成する技術が知られている。

このような技術において、モデルからテストケースを作成することが一般的に行われている（例えば、特許文献１参照）。テストケースとは、検査対象としてのモデルまたはモデルから作成されたソースコードに対して、入力データとして与えるデータをいう。

テストケースを生成するソフトウェアとしては、例えば、Ｓｉｍｕｌｉｎｋ（登録商標）で作成されるモデルに対するテストケースを生成するためのＳｉｍｕｌｉｎｋ Ｄｅｓｉｇｎ Ｖｅｒｉｆｉｅｒ（登録商標）、Ｔ−ＶＥＣ（登録商標）が市販されている。テストケースを生成する従来のソフトウェアの典型的な機能を、図８を用いて説明する。

図８中のモデルにおいては、処理要素８１〜９３間のデータの入出力関係が記述されている。処理要素間の矢印が、データの入出力の方向を示している。各処理要素には、それぞれ特定の演算機能が割り当てられている。例えば、処理要素９１は、２つの入力値を受け付け、それらのうち第１の入力値の方が大きければ１を出力し、そうでなければゼロを出力する。

このモデルの実行において、処理要素９１の出力９５として特定の目標値（例えば１という値）が出力されるようにしたい場合がある。このような場合に、出力９５が検査項目として指定され、さらに指定された検査項目に対する目標値が指定されると、テストケース生成ソフトウェアを実行するコンピュータは、検査項目９５における目標値を起点として、順次処理要素を入力側（すなわち前段側）方向９８に向って、当該目標値を実現することのできる値を逆算していき、最終的には、入力された値を出力する入力処理要素８１、８２に与えるべき値を算出するようになっている。
特開２００６−２４００６号公報

しかし、従来のテストケースの生成技術においては、テストケース生成対象のモデルの複雑度（例えば、処理要素の数、入出力の分岐の数等）の上昇と共に、検査対象のモデル内に設定された各検査項目に対するテストケースの生成が困難になる（すなわち、カバレッジ率が低下する）という傾向がある。このような傾向は、対象となるモデルの複雑度が大きくなると、入力側に向かって逆算して行く範囲が大きくなり、その結果逆算の処理内容が複雑になってしまうことで発生すると考えられる。

本発明は上記点に鑑み、モデルからテストケースを生成する技術において、モデルの複雑度が大きくなってもカバレッジ率の低下を抑えることを目的とする。

上記目的を達成するための請求項１に記載の発明は、入力データに応じた制御処理を複数の処理要素間のデータの入出力の仕様として記述するモデルの当該制御処理を実行するモデル実行装置用に、当該入力データとして用いるためのテストケースを生成するテストケース生成装置についてのものである。

このテストケース生成装置は、モデル中の１つの処理要素の出力データに対して目標値が定められている場合、当該１つの処理要素を含む一連の後段処理要素群と、上記テストケースの入力データを受けて後段処理要素群にデータを出力する一連の前段処理要素群との境界を決定し、当該１つの処理要素の出力データが当該目標値となるように、境界における後段処理要素群に対する入力データの設定値を算出する。

さらにテストケース生成装置は、算出した設定値を、当該境界における新たな目標値として設定し、境界における前段処理要素群から後段処理要素群への入力データの値が、設定した新たな目標値となるよう、上記テストケースを生成する。

このようにすることで、モデル中のテストケースを受け付ける部分から、検査項目としての上記１つの処理要素までが、検査項目を含む後段処理要素群と、データの入出力の観点からそれよりも前段にある前段処理要素群に分けられる。

そして、検査項目を含む後段処理要素群という、モデルの一部分を対象として、目標値を実現する入力データの設定値（後段処理要素群についてのテストケースでもある）を先に算出し、その後に、この設定値を目標値としてモデルのテストケースが算出される。したがって、テストケースの算出が複数段階に分けられ、各段階におけるテストケース算出対象の複雑度が低下する。

このように、より複雑度の低い単位でテストケース生成を行った結果を利用することにより、カバレッジ率の低下を抑えることができる。すなわち、カバレッジ性能を向上できる。

なお、モデルの制御処理の実行方法としては、例えば、モデルからソースコードを生成し、そのソースコードからオブジェクトコードを生成し、当該オブジェクトコードを制御ＥＣＵ（例えば、エンジンＥＣＵ、ブレーキＥＣＵ等の車両制御用ＥＣＵ）に組み込み、当該制御ＥＣＵにおいて当該制御処理を実行させる方法を採用してもよい。この場合、当該制御ＥＣＵがモデル実行装置の一例に相当する。

あるいは、モデルの制御処理の実行方法としては、モデルそのものを汎用のコンピュータ（例えば、パーソナルコンピュータ、ワークステーション）においてシミュレーションする方法を採用してもよい。この場合、当該汎用コンピュータがモデル実行装置の一例に相当する。

モデル中の検査項目（すなわち、上記の１つの処理要素）の出力データに対して目標値が定められる場合としては、例えば、ユーザの指定操作に基づいて、当該検査項目、および、目標値が定められる場合があってもよいし、あるいは、自動的に（すなわち、ユーザの指定操作を必要とせず）当該１つの検査項目、および、目標値が定められる場合があってもよい。

また、請求項２に記載のように、テストケース生成装置は、ユーザによってモデルに記述されたモデル中の区分けのデータに基づいて、境界を決定するようになっていてもよい。このように、あらかじめ記述された区切りに基づいて境界を決定することで、境界の決定が容易になる。

また、請求項３に記載のように、テストケース生成装置は、決定した前記境界のデータを記憶媒体（１３、１５）に記録し、また、記憶媒体（１３、１５）に記録された境界のデータに基づいて設定値を算出し、算出した設定値を記憶媒体（１３、１５）に記録し、また、記憶媒体（１３、１５）に記録された設定値を記憶媒体（１３、１５）中の新たな目標値用のデータとして記録することで、当該設定値を当該新たな目標値として設定し、また、記憶媒体（１３、１５）に記録された新たな目標値に基づいて、テストケースを生成し、生成したテストケースを記憶媒体（１３、１５）に記録するようになっていてもよい。

このように、設定値が記憶媒体（１３、１５）に一旦記録されることで、１つの段階における検査項目を含む要素群のテストケースが確定し、その上で、次の段階におけるモデルのテストケースの生成が行われる。したがって、従来のようにモデルのテストケースを１段階で算出する場合に比べ、カバレッジ性が向上する。

また、請求項１に記載の発明の特徴は、請求項４に記載のように、テストケース生成プログラムも捉えることができ、また、請求項５に記載のように、テストケース生成方法としても捉えることができる。

なお、境界決定手順（１３２）および設定手順（１３６）のそれぞれは、コンピュータが自動的に実行するようになっていてもよいし、ユーザがコンピュータに手入力することで実現するようになっていてもよい。

なお、上記および特許請求の範囲における括弧内の符号は、特許請求の範囲に記載された用語と後述の実施形態に記載される当該用語を例示する具体物等との対応関係を示すものである。

以下、本発明の一実施形態について説明する。図１に、本実施形態に係るパーソナルコンピュータ１（テストケース生成装置の一例に相当する）の構成を示す。このパーソナルコンピュータ１は、ディスプレイ１１、入力装置１２、ＲＡＭ１３、ＲＯＭ１４、ＨＤＤ（ハードディスクドライブ）１５、ＣＰＵ（コンピュータに相当する）１６等から構成される。

ディスプレイ１１は、ＣＰＵ１６から受けた映像信号を、ユーザ（開発者）に対して映像として表示する。

入力装置１２は、キーボード、マウス等から構成され、ユーザが操作することにより、その操作に応じた信号をＣＰＵ１６に出力する。

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

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

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

本実施形態のＣＰＵ１６は、車両制御のためのＥＣＵにおいて実行させるソースコードをモデルから生成するための統合開発環境として、後述するプログラム群を実行するようになっている。

以下、ＣＰＵ１６がプログラムを実行することによって行う処理を、そのプログラム自体が行う処理であるとして説明を行う。

図２に、この統合開発環境としてのモデルベース開発プログラム１００の構成を示す。モデルベース開発プログラム１００は、自動コード生成プログラム１１０、自動テストケース生成プログラム１３０、Ｃソースコード実行プログラム１４０、モデルシミュレーションプログラム１５０、実行結果比較プログラム１７０、および結果表示プログラム１８０のプログラム群から構成される。これらプログラム群は、それぞれユーザの入力装置１２を用いた実行開始の操作に基づいて、その実行が開始される。

自動コード生成プログラム１１０は、ユーザによってよって作成され、ＨＤＤ１５に記憶されているモデル２１０を読み出し、この読み出したモデル２１０の示すデータ入出力処理を実現するための処理が記述されたＣソースコードを生成する。自動コード生成プログラムの例としては、Ｍａｔｈｗｏｒｋｓ（登録商標）社のＲｅａｌ Ｔｉｍｅ Ｗｏｒｋｓｈｏｐ（登録商標）がある。なお、モデルは、モデルエディタ等のモデル作成用プログラムをＣＰＵ１６が実行し、その実行時にユーザがモデル作成のための作業を入力装置１２を用いて行うことで、作成されるようなっていてもよい。このようなモデルエディタもモデルベース開発プログラム１００に含まれていてもよい。

ここで、モデルについて説明する。モデルは、時系列の中でのデータ演算、データ入力およびデータ出力のうち少なくともいずれか１つの機能を表す処理要素（以下、ブロックという）、およびブロック間の入出力関係の仕様（すなわち、どのブロックからどのブロックにデータが渡されるか）を示す結線の組み合わせとして記述される。これらブロックおよび結線の組み合わせによって、入力データに応じた当該モデルの処理内容が記述される。処理の内容としては、例えば、エンジン制御、ブレーキ制御等の車載装置の制御処理がある。

モデルの例としては、Ｍａｔｈｗｏｒｋｓ（登録商標）社のＳｉｍｕｌｉｎｋ（登録商標）モデルがある。図３および図４に、モデルの一部を成すサブシステムを例示する。なお、図３に例示するＡサブシステム２０は、さらに複数（具体的には２つ）の結線で繋がるＡ−１サブシステム３０およびＡ−２サブシステム４０を含んでいる。

また、Ａ−２サブシステム４０について図４に例示するように、各サブシステム３０、４０も、結線で繋がれた一連の（すなわち、直接的または間接的に結線を介して１まとまりに繋がっている）ブロック（図４の例ではブロック４１〜５３）を含んでいる。

このように、モデルには、サブシステムのカバー範囲（すなわち、サブシステムがどのブロックを含むか）についての情報も記述されている。なお、各サブシステムは、当該サブシステムを含むモデルの一部を構成すると共に、それ自体もブロックと結線の組み合わせによって構成されているので、モデルである。

また、サブシステムには、関数サブシステムと非関数サブシステムとがある。関数サブシステムとは、モデルからコードを生成したときに、Ｃソースコード上で関数となるようなサブシステムをいい、非関数サブシステムとは、それ以外のサブシステムをいう。図３、４の例においては、Ａサブシステム２０が関数サブシステムであり、Ａ−１サブシステム３０およびＡ−２サブシステム４０が非関数サブシステムである。モデルには、モデルに含まれる各サブシステムが関数サブシステムであるか否かについての情報も記述されている。

Ａ−２サブシステム４０においては、ブロック４３〜５３は、入力ポートおよび出力ポートの両方または一方のみを有し、両方を有している場合は、入力ポートから入力されたデータに対して所定の演算（比較演算、四則演算等）を行い、その結果の信号を出力ポートから出力する機能を表す。また、入力ブロック４１、４２は、それぞれ出力ポートを１つ有し、指定された入力値を出力ポートから出力する。

なお、入力ブロック４１、４２に対する入力値の指定は、ユーザが入力装置１２を操作して行う場合もあれば、当該入力ブロック４１、４２を含むサブシステムの前段のサブシステムの出力値となるようにＣＰＵ１６が指定する場合もある。

自動テストケース生成プログラム１３０は、自動コード生成プログラム１１０によって生成されたモデル２１０に基づいて、テストケース２３０を生成し、ＨＤＤ１５に記憶させる。なお、テストケースは、上述のようにモデル２１０のみに基づいて生成してもよいし、あるいは、モデル２１０のソースコードに基づいて生成してもよいし、またあるいは、モデル２１０とソースコード２１０の両方に基づいて生成してもよい。

テストケースとは、モデルの品質、および、自動コード生成プログラム１１０によって当該モデルから生成されたＣソースコードの品質を検査するための処理（例えばカバレッジテスト）の実行において、その品質検査が十分となるよう、当該モデルやＣソースコードに入力するテスト用データである。例えば、後述するＣソースコード実行プログラム１４０およびモデルシミュレーションプログラム１５０の実行の際にも、このテストケースをＣＰＵ１６が使用する。

品質検査が十分となるようなテストケースとは、例えば、できる限りそのモデルの全てのブロックまたはＣソースコードの全ての命令文が実行されるようなバラエティを持った入力データである。

なお、品質検査は、生成されたＣソースコード（またはモデル）全体について行う場合と、そのＣソースコード（またはモデル）に含まれる関数等の所定の実行単位部分毎に独立に行われる場合がある。ここでいう入力データとは、品質検査が行われる対象の部分に入力されるデータをいう。この自動テストケース生成プログラム１３０の処理の詳細については後述する。

Ｃソースコード実行プログラム１４０は、自動コード生成プログラム１１０によって生成されたＣソースコードの実行単位に記載された制御処理内容を実行する。この実行の目的の１つは、上記の品質検査である。そして、その実行の際、入力データは自動テストケース生成プログラム１３０によって生成されたテストケース２３０を用いる。そしてＣソースコード実行プログラム１４０は、実行したＣソースコードの実行単位による出力データ、および実行した命令文の時系列的なリストを、実行結果データ２４０として、ＨＤＤ１５に記憶させる。

モデルシミュレーションプログラム１５０は、自動コード生成プログラム１１０によって生成されたＣソースコードの元となるモデル２１０をＨＤＤ１５から読み出し、そのモデルのシミュレーションを実行する。シミュレーションとは、そのモデルの表現するデータの入出力の時間変化をパーソナルコンピュータ１上で仮想的に再現する処理をいう。なお、モデルのシミュレーションにおいても、モデル全体ではなく、その実行単位毎にシミュレーションを行ってもよい。

なお、Ｃソースコード実行プログラム１４０で実行するソースコードの実行単位は、モデルシミュレーションプログラム１５０で実行するモデルの実行単位部分から生成されるソースコードである。すなわち、Ｃソースコード実行プログラム１４０で実行されるＣソースコードの実行単位と、モデルシミュレーションプログラム１５０で実行されるモデルの実行単位とは対応している。

このシミュレーションにおいて、外部からのデータの入力としては、自動テストケース生成プログラム１３０によって生成されたテストケース２３０を用いる。そしてモデルシミュレーションプログラム１５０は、そのモデルのシミュレーションによる外部への出力データ、ならびにブロック毎の実行時間および入出力データを、実行結果データ２４０として、ＨＤＤ１５に記憶させる。

このようなＣソースコード実行プログラム１４０またはモデルシミュレーションプログラム１５０をＣＰＵ１６が実行する際には、パーソナルコンピュータ１がモデルの制御処理を実行するモデル実行装置として機能することになる。

なお、自動コード生成プログラム１１０によって生成されたＣソースコードは、当該Ｃソースコードが記述する制御を実現する制御ＥＣＵ（例えばエンジンＥＣＵ、ブレーキＥＣＵ）で作動するオブジェクトコードに変換され、当該オブジェクトコードは当該制御ＥＣＵに実装される。

そして、当該オブジェクトコードが実装された制御ＥＣＵにおいて、当該オブジェクトコードを実行すると共に、当該制御ＥＣＵに対して、自動テストケース生成プログラム１３０によって生成されたテストケース２３０を入力するようになっていてもよい。この場合には、当該制御ＥＣＵがモデルの制御処理を実行するモデル実行装置として機能することになる。

実行結果比較プログラム１７０は、Ｃソースコード実行プログラム１４０およびモデルシミュレーションプログラム１５０によってＨＤＤ１５に記憶された実行結果データ２４０を読み出し、その実行結果を比較し、その比較結果を結果表示プログラム１８０に渡す。なお、比較とは、モデルシミュレーションプログラム１５０がシミュレーションを行ったモデルと、自動コード生成プログラム１１０がそのモデルに基づいて生成したＣソースコードの、それぞれの実行結果のデータの比較をいう。比較項目としては、同じ入力データに対してそれぞれのモデル、Ｃソースコードが出力したデータがある。そして実行結果比較プログラム１７０は、比較の結果、それぞれが合致しているか否かの合否判定を行い、その合否判定の情報も結果表示プログラム１８０に渡す。

結果表示プログラム１８０は、実行結果比較プログラム１７０およびモデルシミュレーション状況解析プログラム１６０から渡されたデータをディスプレイ１１に出力する。

次に、上述の自動テストケース生成プログラム１３０の具体的な処理内容について、図３、４に示したＡサブシステム２０を例に挙げて説明する。図５に、自動テストケース生成プログラム１３０のためにＣＰＵ１６が実行する処理のフローチャートを示す。

自動テストケース生成プログラム１３０の実行において、ＣＰＵ１６は、入力装置１２に対する検査対象モデルの指定操作を受け付け、受け付けた検査対象モデルに入力するためのテストケースを後述のように算出するようになっている。ここでは、検査対象モデルとしてＡサブシステム２０が指定されたとする。

また、自動テストケース生成プログラム１３０の実行においてＣＰＵ１６は、ユーザの検査項目指定操作を受け付けることができるようになっている。検査項目指定操作とは、検査項目および検査項目の目標値を指定する操作である。

検査項目は、検査対象モデル中で、どのブロックのどの出力データを目標値の指定対象とするかを示す情報である。目標値は、当該検査項目としての出力データに対して要求すべき具体的な値である。

このように、検査対象モデル、検査項目、目標値の指定をユーザから受け付けると、ＣＰＵ１６は、自動テストケース生成プログラム１３０の一部の処理として、図５の処理を開始する。

そしてまずステップ１３２で、検査対象モデル内に複数の内部構成要素が存在するか否かを判定する。本実施形態においては、内部構成要素とは、サブシステムをいう。Ａサブシステム２０は、Ａ−２サブシステム４０、および、上記テストケースの入力データを受けてＡ−２サブシステム４０にデータを出力するＡ−１サブシステム３０という、２つのサブシステムを有している。

検査対象モデル内に複数の内部構成要素が存在する場合、それら内部構成要素の境界（具体的には、Ａ−１サブシステム３０とＡ−２サブシステム４０との間の境界７０）を特定してＲＡＭ１３に記録し、続いてステップ１３４を実行する。

検査対象モデル内に複数の内部構成要素が存在しない場合、続いてステップ１３８で、検査対象モデル全体を１つの単位として、まとめてテストケース生成処理を行い、それによって得たテストケースをＨＤＤ１５に記録する。

例えば、Ｓｉｍｕｌｉｎｋ Ｄｅｓｉｇｎ Ｖｅｒｉｆｉｅｒ（登録商標）、Ｔ−ＶＥＣ（登録商標）等の既存のテストケース生成プログラムに、検査対象モデル全体、および、検査項目５５、および検査項目５５における目標値を引数として渡すことで、検査項目５５からＡサブシステム２０全体を逆算してテストケースを生成させる。

ステップ１３４では、ＲＡＭ１３に記録された境界７０のデータによって分けられた複数の内部構成要素のうち、検査項目を含む内部構成要素のみを対象として、テストケース生成処理を行い、それによって得たテストケースをＲＡＭ１３に記録する。

具体的には、Ａ−１サブシステム３０およびＡ−２サブシステム４０のうち、検査項目５５を含むＡ−２サブシステム４０を１つの単位として、まとめてテストケース生成処理を行う。

例えば、上述の既存のテストケース生成プログラムに、Ａ−２サブシステム４０、検査項目５５、および検査項目５５における目標値を引数として渡すことで、検査項目５５からＡ−２サブシステム４０を逆算してテストケースを生成させる。

これによって、検査項目５５における目標値を実現することのできる値として、入力ブロック４１、４２における入力データ（すなわち境界７０におけるＡ−１サブシステム３０からの出力データ）の設定値が決まる。

図６に、Ａ−２サブシステム４０に対するテストケースの一例を表形式で示す。この例では、検査項目５５における目標値を実現することのできる２つの入力Ｉｎ１、Ｉｎ２に対するテストケースとして、２種類（すなわち、テストケース１およびテストケース２）が算出されている。

続いてステップ１３６では、図７に示すように、ステップ１３４で決定された設定値を新たな目標値としてＲＡＭ１３に記録し、さらに、ＲＡＭ１３中の境界７０を新たな検査項目としてＲＡＭ１３に記録する。

続いてステップ１３８では、Ａサブシステム２０全体を対象とし、かつ、直前のステップ１３６でＲＡＭ１３に記録された新たな検査項目７０および新たな目標値を実現するためのテストケースの生成処理を行い、それによって得たテストケースをＨＤＤ１５に記録する。

例えば、上述の既存のテストケース生成プログラムに、Ａサブシステム２０全体、新たな検査項目７０、および新たな検査項目７０における新たな目標値を引数として渡すことで、検査項目７０からＡサブシステム２０を逆算してテストケースを生成させる。

これによって、検査項目７０における新たな目標値を実現することのできる値として、Ａ−１サブシステム３０への入力データの設定値が決まる。この設定値はまた、検査項目５５における当初の目標値を実現することのできる、Ａサブシステム２０への入力データの設定値である。すなわち、検査項目５５における目標値を実現するためのＡサブシステム２０のテストケースである。ステップ１３８の後、自動テストケース生成プログラム１３０の実行が終了する。

このように、ＣＰＵ１６は、Ａサブシステム２０（モデルの一例に相当する）中の比較ブロック５０（１つの処理要素の一例に相当する）の出力データ（すなわち検査項目）に対して目標値が定められている場合において、当該比較ブロック５０を含むＡ−２サブシステム４０（一連の後段処理要素群の一例に相当する）とＡ−１サブシステム３０（一連の前段処理要素群の一例に相当する）との境界を特定し（ステップ１３２参照）、検査項目が当該目標値となるように、当該境界におけるＡ−２サブシステム４０に対する入力データの設定値を算出する（ステップ１３４参照）。

さらにＣＰＵ１６は、算出した設定値を、当該境界における新たな目標値として設定し、（ステップ１３６参照）、さらに、境界におけるＡサブシステム２０からの出力データを新たな検査項目として設定した上で、Ａサブシステム２０のテストケースを生成する。すなわち、境界におけるＡ−１サブシステム３０からＡ−２サブシステム４０への入力データの値が、設定した新たな目標値となるよう、テストケースを生成する（ステップ１３８参照）。

このようにすることで、Ａサブシステム２０中のテストケースを受け付ける部分から、検査項目５５としての比較ブロック５０までが、検査項目５５を含むＡ−２サブシステム４０と、データの入出力の観点からそれよりも前段にあるＡ−１サブシステム３０に分けられる。

そして、検査項目５５を含むＡ−２サブシステム４０という、Ａサブシステム２０の一部分を対象として、目標値を実現するための境界における入力データの設定値（Ａ−２サブシステム４０についてのテストケースでもある）を先に算出し、その後に、この設定値を目標値としてＡサブシステム２０のテストケースが算出される。したがって、テストケースの算出が複数段階（具体的には２段階）に分けられ、各段階におけるテストケース算出対象の複雑度が低下する。

このように、より複雑度の低い単位でテストケース生成を行った結果を利用することにより、カバレッジ率の低下を抑えることができる。すなわち、カバレッジ性能を向上できる。

また、ＣＰＵ１６は、ユーザによってＡサブシステム２０に記述されたＡサブシステム２０中の非関数サブシステムの区分けのデータに基づいて、境界を決定するようになっている。このように、あらかじめ記述されたサブシステムの区切りに基づいて境界を決定するので、境界の決定が容易になる。

（他の実施形態）
以上、本発明の実施形態について説明したが、本発明の範囲は、上記実施形態のみに限定されるものではなく、本発明の各発明特定事項の機能を実現し得る種々の形態を包含するものである。

例えば、上記実施形態においては、検査対象モデルとしては、２つのサブシステム３０、４０を含むＡサブシステム２０が例示されている。しかし、検査対象モデルは、３つ以上のサブシステムを含むようになっていてもよい。

例えば、検査対象モデルにおいてサブシステムが直列に３つ以上連結されている場合には、ＣＰＵ１６は、図５のステップ１３２では、それらサブシステム間の複数の境界を特定してＲＡＭ１３に記録するようになっていてもよい。

この場合ＣＰＵ１６は、ステップ１３４、１３６では、まず、検査項目５５を含む第１サブシステムについて、当該検査項目５５における目標値を実現する第１テストケースを算出する。続いて、第１サブシステムの直接の前段となる第２サブシステムについて、当該第２サブシステムから第１サブシステムへの出力データを検査項目とし、その検査項目における第１テストケースを目標値として、第２テストケースを算出する。続いて、第２サブシステムの直接の前段となる第３サブシステムについて、当該第３サブシステムから第２サブシステムへの出力データを検査項目とし、その検査項目における第２テストケースを目標値として、第３テストケースを算出していく。

このように、各サブシステムを単位として、連続的に後段のサブシステムから前段のサブシステムへと、それぞれのサブシステムのテストケースを算出していくことで、最終的に検査対象モデル全体についてのテストケースを算出するようになっていてもよい。

また、後段処理要素群と前段処理要素群との境界の区切りの単位となる内部構成素は、サブシステムでなくともよい。例えば、ＣＰＵ１６は、特定の種類のブロックの出力部分（または入力部分）を境界とするようになっていてもよい。また例えば、ＣＰＵ１６は、ユーザが入力装置１２を用いた手順で指定したモデル中の位置を境界として決定するようになっていてもよい。

また、上記の実施形態において、ＣＰＵ１６がプログラムを実行することで実現している各機能は、それらの機能を有するハードウェア（例えば回路構成をプログラムすることが可能なＦＰＧＡ）を用いて実現するようになっていてもよい。

本発明の実施形態に係るパーソナルコンピュータ１の構成図である。 モデルベース開発プログラム１００の構成図である。 Ａサブシステム２０の構成を示す図である。 Ａ−２サブシステム４０の内部構成を示す図である。 自動テストケース生成プログラム１３０のフローチャートである。 作成されたテストケースの一例を示す図表である。 作成されたテストケースを境界７０に適用する様子を示す図である。 テストケースを生成する従来のソフトウェアの典型的機能を示す図である。

符号の説明

１ パーソナルコンピュータ
１２ 入力装置
１３ ＲＡＭ
１５ ＨＤＤ
１６ ＣＰＵ
２０ Ａサブシステム
３０ Ａ−１サブシステム
４０ Ａ−２サブシステム
４１〜５３、８１〜９３ ブロック
５５、９５ 検査項目
７０ 境界
１００ モデルベース開発プログラム
１１０ 自動コード生成プログラム
１３０ 自動テストケース生成プログラム
１４０ Ｃソースコード実行プログラム
１５０ モデルシミュレーションプログラム
２１０ モデル
２２０ Ｃソースコード
２３０ テストケース

Claims (5)

1. 入力データに応じた制御処理を複数の処理要素間のデータの入出力の仕様として記述するモデルの前記制御処理を実行するモデル実行装置用に、前記入力データとして用いるためのテストケースを生成するテストケース生成装置であって、
   前記モデル中の１つの処理要素の出力データに対して目標値が定められている場合、前記１つの処理要素を含む一連の後段処理要素群と、前記テストケースの入力データを受けて前記後段処理要素群にデータを出力する一連の前段処理要素群との境界を決定する境界決定手段（１３２）と、
   前記１つの処理要素の出力データが前記目標値となるように、前記境界における前記後段処理要素群に対する入力データの設定値を算出する部分算出手段（１３４）と、
   前記部分算出手段（１３４）が算出した前記設定値を、前記境界における新たな目標値として設定する設定手段（１３６）と、
   前記境界における前記前段処理要素群から前記後段処理要素群への入力データの値が、前記設定手段（１３６）が設定した前記新たな目標値となるよう、前記テストケースを生成する生成手段（１３８）と、を備えたことを特徴とするテストケース生成装置。
2. 前記境界決定手段（１３２）は、ユーザによって前記モデルに記述された前記モデル中の区分けのデータに基づいて、前記境界を決定することを特徴とする請求項１に記載のテストケース生成装置。
3. 前記境界決定手段（１３２）は、決定した前記境界のデータを記憶媒体（１３、１５）に記録し、
   前記部分算出手段（１３４）は、前記記憶媒体（１３、１５）に記録された前記境界のデータに基づいて前記設定値を算出し、算出した設定値を記憶媒体（１３、１５）に記録し、
   前記設定手段（１３６）は、前記記憶媒体（１３、１５）に記録された前記設定値を前記記憶媒体（１３、１５）中の前記新たな目標値用のデータとして記録することで、前記設定値を前記新たな目標値として設定し、
   前記生成手段（１３８）は、前記記憶媒体（１３、１５）に記録された前記新たな目標値に基づいて、前記テストケースを生成し、生成した前記テストケースを前記記憶媒体（１３、１５）に記録することを特徴とする請求項１または２に記載のテストケース生成装置。
4. 入力データに応じた制御処理を複数の処理要素間のデータの入出力の仕様として記述するモデルの前記制御処理を実行するモデル実行装置用に、前記入力データとして用いるためのテストケースを生成するテストケース生成プログラムであって、
   前記モデル中の１つの処理要素の出力データに対して目標値が定められている場合、前記１つの処理要素を含む一連の後段処理要素群と、前記テストケースの入力データを受けて前記後段処理要素群にデータを出力する一連の前段処理要素群との境界を決定する境界決定手段（１３２）、
   前記１つの処理要素の出力データが前記目標値となるように、前記境界における前記後段処理要素群に対する入力データの設定値を算出する部分算出手段（１３４）、
   前記部分算出手段（１３４）が算出した前記設定値を、前記境界における新たな目標値として設定する設定手段（１３６）、および
   前記境界における前記前段処理要素群から前記後段処理要素群への入力データの値が、前記設定手段（１３６）が設定した前記新たな目標値となるよう、前記テストケースを生成する生成手段（１３８）として、コンピュータを機能させるテストケース生成プログラム。
5. 入力データに応じた制御処理を複数の処理要素間のデータの入出力の仕様として記述するモデルの前記制御処理を実行するモデル実行装置用に、前記入力データとして用いるためのテストケースを生成するテストケース生成方法であって、
   前記モデル中の１つの処理要素の出力データに対して目標値が定められている場合、前記１つの処理要素を含む一連の後段処理要素群と、前記テストケースの入力データを受けて前記後段処理要素群にデータを出力する一連の前段処理要素群との境界を決定する境界決定手順（１３２）と、
   前記１つの処理要素の出力データが前記目標値となるように、前記境界における前記後段処理要素群に対する入力データの設定値を算出する部分算出手順（１３４）と、
   前記部分算出手順（１３４）によって算出された前記設定値を、前記境界における新たな目標値として設定する設定手順（１３６）と、
   前記境界における前記前段処理要素群から前記後段処理要素群への入力データの値が、前記設定手順（１３６）によって設定された前記新たな目標値となるよう、前記テストケースを生成する生成手順（１３８）と、を備えたことを特徴とするテストケース生成方法。

Images