JP2008299502A - テストケース妥当性自動検証プログラムおよびテストケース妥当性自動検証結果表示方法 - Google Patents

Abstract

【課題】適切にテストケース妥当性を検証することができるテストケース妥当性自動検証プログラムおよびテストケース妥当性自動検証結果表示方法を提供する。
【解決手段】複数のブロックから構成されるモデルを仕様として作成したソフトウェアに対するテストケースの妥当性を自動検証すべく、妥当性検証処理プログラム１７は、モデルシミュレーションプログラム１４と協動してテストケースによるモデルのシミュレーションを行って当該シミュレーションにより得られたブロックの入出力情報を用いてテストケースの妥当性を検証する。
【選択図】図２

Description

本発明は、モデルベース開発におけるソフトウェア検査でのテストケースの妥当性検証に関するものである。

実行可能であるモデルを参照して、自動または手動でＣソースコードを作成するモデルベース開発において、作成したＣソースコードの検査に対して、自動あるいは手動でテストケースを作成している。そのテストケースの妥当性を検証する方法として、図１４に示すように、カバレッジ（ソフトウェア検査におけるパス網羅性の指標）を基準とする手法がある（例えば、特許文献１）。

カバレッジ１００％を基準とすれば、ソフトウェア上で分岐しうるすべてのパスを網羅的に確認できるため、有効な手段として利用されている。
特開２００５−３０１５６８号公報

しかし、カバレッジ１００％のみを基準とするだけでは、ソフトウェアのバグを発見できない場合がある。
具体例として、図１５に示す検査対象ブロックを用い、Ａｂｓ（絶対値）ブロック、スイッチブロック（分岐）を検査対象としたテストケースを挙げる。

上記テストケースの結果を図１６に示す。このテストケースはＡｂｓブロックに対してカバレッジは１００％である。しかしながら、テストケース１において、入力２がオフとなっているため、観測可能ポイント（図１５参照）で負の入力に対する確認ができない。

また、上記テストケースはスイッチブロックに対してカバレッジは１００％であるが、テストケース２において、切り換える値が共に４であるため、観測可能ポイントで切り換わりを確認することができない。

即ち、図１５において、Ａｂｓブロックについて「正／負」の値を入力すればＡｂｓブロックのカバレッジは１００％となる。また、スイッチブロックについて「オン／オフ」の値を入力すればスイッチブロックのカバレッジは１００％となる。しかしながら、テストケース１，２に対し、観測可能ポイントの値から、Ａｂｓブロックの動作を確認できない、また、スイッチブロックの切り換わりが確認できない。

以上より、カバレッジ１００％を満足するだけでは、有効なテストケースであるとは言えない。
本発明は、上記問題点に着目してなされたものであり、その目的は、適切にテストケース妥当性を検証することができるテストケース妥当性自動検証プログラムおよびテストケース妥当性自動検証結果表示方法を提供することにある。

請求項１に記載の発明においては、複数のブロックから構成されるモデルを仕様として作成したソフトウェアに対するテストケースの妥当性を自動検証するプログラムであって、テストケースによるモデルのシミュレーションを行って当該シミュレーションにより得られたブロックの入出力情報を用いてテストケースの妥当性を検証することを要旨とする。

請求項１に記載の発明によれば、テストケースによるモデルのシミュレーションを行って当該シミュレーションにより得られたブロックの入出力情報を用いてテストケースの妥当性を検証することにより、ブロックのつながりを加味して適切にテストケースの妥当性を自動検証することができる。即ち、シミュレーションを実行した結果得られるブロックの入出力情報を用いるのでブロック間の入出力情報の関連性を含めて判断することができる。

請求項２に記載のように、請求項１に記載のテストケース妥当性自動検証プログラムにおいて、テストケースによるモデルのシミュレーションを通して、検査対象ブロックの出力値が観測できるポイントまで有効であるか否かにより妥当性検証を行うようにすると、モデルのシミュレーションを実施することにより、検査対象ブロックから観測可能ポイントまでのデータの流れを確認することができる。

請求項３に記載のように、請求項１に記載のテストケース妥当性自動検証プログラムにおいて、テストケースによるモデルのシミュレーションを通して、検査対象ブロックである分岐を伴うブロックに対する入力値が異なるか否かにより妥当性検証を行うようにすると、モデルのシミュレーションにより分岐を伴うブロックの出力を確認することができる。

請求項４に記載のように、請求項１に記載のテストケース妥当性自動検証プログラムにおいて、テストケースによるモデルのシミュレーションを通して、モデルに設定されている信号線の取り得る範囲内であるか否かにより妥当性検証を行うようにすると、モデルに規定されている実環境では取り得ない範囲となるテストケースを排除することが可能となる。

請求項５に記載の発明においては、複数のブロックから構成されるモデルを仕様として作成したソフトウェアに対するテストケースの妥当性を自動検証した結果を表示する方法であって、テストケースによるモデルのシミュレーションを行って当該シミュレーションにより得られたブロックの入出力情報を用いたテストケースの妥当性検証結果をモデル上で表示するようにしたことを要旨とする。

請求項５に記載の発明によれば、請求項１に記載の発明の作用効果に加え、テストケースによるモデルのシミュレーションを行って当該シミュレーションにより得られたブロックの入出力情報を用いたテストケースの妥当性検証結果をモデル上で表示しモデルに反映することにより、モデル上でテストケースの妥当性検証結果を確認でき、これにより、修正することが可能となる。

請求項６に記載のように、請求項５に記載のテストケース妥当性自動検証結果表示方法において、テストケースの妥当性検証結果をモデル上で表示する際に、テストケースの番号も表示してもよいし、あるいは、請求項７に記載のように、請求項５に記載のテストケース妥当性自動検証結果表示方法において、テストケースの妥当性検証結果をモデル上で表示する際に、検査対象としたブロック名も表示するようにしてもよい。

以下、本発明を具体化した一実施形態を図面に従って説明する。
図１には、本実施形態に係るパーソナルコンピュータ１の構成を示す。このパーソナルコンピュータ１は、モデルベース開発の工程の各段階において用いられ、複数のブロックから構成される実行可能なモデルを仕様として作成したソフトウェアに対するテストケースの妥当性を自動検証することができるようになっている。このパーソナルコンピュータ１は、ディスプレイ２、入力装置３、ＲＡＭ４、ＲＯＭ５、ＨＤＤ（ハードディスクドライブ）６、ＣＰＵ７等から構成されている。

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

ＲＡＭ４は読み出し、書き込み可能な揮発性メモリであり、ＲＯＭ５は読み出し専用の不揮発性メモリであり、ＨＤＤ６は読み出し、書き込み可能な不揮発性メモリである。ＲＯＭ５、ＨＤＤ６には、ＣＰＵ７が読み出して実行するプログラム等が予め記憶されている。ＲＡＭ４は、ＣＰＵ７がＲＯＭ５、ＨＤＤ６に記憶されたプログラムを実行する際に、そのプログラムを一時的に保存するための記憶領域、および作業用のデータを一時的に保存するための記憶領域として用いられる。

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

パーソナルコンピュータ１のＣＰＵ７が実行するプログラムの構成を図２に示す。
ＣＰＵ７は、抽出プログラム１１、モデルシミュレーションプログラム１４、妥当性検証処理プログラム１７、モデルによる妥当性検証結果表示プログラム１９、表による妥当性検証結果表示プログラム２０、不足テストケース抽出処理プログラム２１等を実行する。これらプログラムは、ユーザが入力装置３に対して所定の操作をすることにより、または、他のプログラムから読み出されることにより、その実行が開始される。

なお、モデル収納部１０、情報収納部１２、テストケース収納部１３、シミュレーション結果収納部１５、妥当性判断基準収納部１６、妥当性検証結果収納部１８、テストケース不足の検査対象ブロック情報収納部２２は、ＨＤＤ６の記憶領域の一部である。

モデルは、図示しないモデルエディタ等のオペレーティングシステム上で実行されるプログラムをユーザが利用することにより作成され、さらに、モデル収納部１０に記憶されるようになっている。モデルエディタとしては、例えばＭＡＴＬＡＢ（登録商標）上で動作するＳＩＭＵＬＩＮＫ（登録商標）と呼ばれるソフトウェアを用いることができる。モデルは、例えば図３のごとくブロック５０，６０を有し、あるブロックの出力を他のブロックの入力にリンク（信号線）でつないでいる。図３においては、モデルはＡｂｓブロック５０とスイッチブロック６０から構成され、詳しくは、入力１がＡｂｓブロック５０を介してスイッチブロック６０のＡ端子に入力され、入力２がスイッチブロック６０の切換端子Ｂに入力され、入力３がスイッチブロック６０のＣ端子に入力され、スイッチブロック６０の出力端子が観測可能ポイントとなっている。以下、図３のモデルについてテストケースの妥当性を自動検証する場合を説明する。

図２において、抽出プログラム１１においてはモデル収納部１０のモデルにおける検査対象ブロックの抽出、および、当該ブロックから観測可能ポイントまでのつながりを示す情報を抽出する。図３のモデルにおいては、検査対象ブロックはＡｂｓブロック５０とスイッチブロック６０である。そして、図２の抽出プログラム１１は情報収納部１２に、モデルにおける検査対象ブロック名と、当該ブロックから観測可能ポイントまでのつながりを示す情報を収納する。

一方、モデルシミュレーションプログラム１４は、モデル収納部１０のモデル（図３）に対し、情報収納部１２における、モデルでの検査対象ブロック名と、当該ブロックから観測可能ポイントまでのつながりを示す情報から、テストケース収納部１３に用意されたテストケースを用いてモデルのシミュレーションを実行する。図３においては、入力１，２，３として所定の値を設定して（テストケースを用いて）シミュレーションする。このテストケースによるモデルのシミュレーションの実行により、シミュレーション結果としてブロックの入出力情報が得られる（後記する図６参照）。シミュレーション結果は図２のシミュレーション結果収納部１５に収納する。

妥当性判断基準収納部１６には妥当性判断基準が格納されている。図４には図３のモデルについての妥当性判断基準を示す。図４において、Ａｂｓブロック５０についての判断基準として、「入力値に正または負が入力されるか」という基準が用意されている。これを、判断基準（Ｉ）という。また、スイッチブロック６０についての判断基準として、「入力Ｂがオンまたはオフか」という基準が用意されている。これを、判断基準（ＩＩ）という。また、スイッチブロック６０についての判断基準として、「目的の入力（ＡまたはＢ）側に切り換えられるように入力Ｂがなっているか」という基準が用意されている。これを、判断基準（ＩＩＩ）という。また、スイッチブロック６０についての判断基準として、「入力Ａと入力Ｃとは異なるか」という基準が用意されている。これを、判断基準（ＩＶ）という。

図２の妥当性検証処理プログラム１７は、シミュレーション結果収納部１５のシミュレーション結果と、情報収納部１２のモデルにおける検査対象ブロック名と、当該ブロックから観測可能ポイントまでのつながりを示す情報と、妥当性判断基準収納部１６の妥当性判断基準から、テストケースの妥当性検証処理を行う。このとき、シミュレーションの実行により得られたブロックの入出力情報を用いてテストケースの妥当性が検証される。妥当性検証結果は妥当性検証結果収納部１８に収納する（後記する図６の「可観測性」、「パス識別性」、「妥当性検証結果」を参照）。

図２のモデルによる妥当性検証結果表示プログラム１９は、妥当性検証結果収納部１８の妥当性検証結果によりモデルによる妥当性検証結果表示を行う。また、表による妥当性検証結果表示プログラム２０は、妥当性検証結果収納部１８の妥当性検証結果により表による妥当性検証結果表示を行う。モデルによる妥当性検証結果表示と表による妥当性検証結果表示は、図１のディスプレイ２を用いて行われる（画面表示される）。

図２における妥当性検証処理プログラム１７の処理の流れを図５に示す。図５の処理は各検査対象ブロックについて各テストケース毎に実施される。
図３のモデルにおいて、まず、Ａｂｓブロック５０を検査対象ブロックとして図５の処理が実行される。

図５において、ステップ１０１で検査対象ブロックについての関連するデータを収集する。具体的には、図３におけるＡｂｓブロック５０を検査対象ブロックとして、Ａｂｓブロック５０から観測可能ポイントまでのつながりを示す情報と、図４におけるＡｂｓブロック５０についての判断基準（Ｉ）を収集する。

そして、図５のステップ１０２でテストケースのデータが検査対象ブロックに対して有効なデータであるか否か判定する。具体的には、図３のＡｂｓブロック５０を検査対象ブロックとしたとき、Ａｂｓブロックに対する入力が「０」であると、図４の判断基準（Ｉ）を用いて入力値が正でも負でもないので条件を満たさず、無効なデータであると判定される。

この図５のステップ１０２において対象ブロックに対して有効なデータでないと、ステップ１１１に移行して無効なテストケースと判定する（検査対象を確認できない）。
一方、図５のステップ１０２において対象ブロックに対して有効なデータであると、ステップ１０３で接続先のブロックを探索する。具体的には、図３におけるＡｂｓブロック５０に対する接続先のスイッチブロック６０を検索する。続いて、図５のステップ１０４でブロック（接続先ブロック）についての関連するデータを収集する。具体的には、図４におけるスイッチブロック６０についての判断基準（ＩＩＩ），（ＩＶ）を収集する。

引き続き、図５のステップ１０５で出力データは観測可能か否か判定する。つまり、接続先ブロックであるスイッチブロック６０から前段の検査対象ブロックであるＡｂｓブロック５０の出力データが観測できるかどうかを判断する。具体的には、図３のスイッチブロック６０について図４の判断基準（ＩＩＩ）を用いて図３の入力Ａ側に切り換えられるように入力Ｂがなっているかを判定する。図３において、スイッチブロック６０の入力Ｂがオン側となっているとＡｂｓブロック５０の出力データは観測可能であり（可観測性を満たし）、また、入力Ｂがオフ側となっているとＡｂｓブロック５０の出力データは観測可能でない（可観測性を満たさない）ことになる。図５のステップ１０５において条件を満たさないと（出力データは観測可能でないと）、ステップ１１０に移行して無効なテストケースと判定する（検査対象を確認できるが可観測性を満たさない）。

一方、図５のステップ１０５において出力データは観測可能であると（可観測性を満たすと）、ステップ１０６でパス識別可能か否か判断する。具体的には、図３のスイッチブロック６０について図４の判断基準（ＩＶ）を用いて図３の入力Ａと入力Ｃとは異なるか否かを判定する。図３において、スイッチブロック６０の入力Ａと入力Ｃが異なればパス識別可能であり（パス識別性を満たし）、入力Ａと入力Ｃが同じであればパス識別可能でない（パス識別性を満たさない）ことになる。図５のステップ１０６において判断基準（ＩＶ）の条件を満たさないと（パス識別可能でないと）、図５のステップ１０９に移行して無効なテストケースと判定（検査対象を確認できるが、パス識別性を満たさない）と判定する。

図５のステップ１０６においてパス識別可能であるとステップ１０７に移行する。ステップ１０７で、出力が観測可能ポイントか判定する。即ち、接続先が出力ポートなどの外部に値を出力するブロックかどうかを評価する。具体的には、図３のモデルでは、スイッチブロック６０の出力は観測可能ポイントとなっている。そして、条件を満たすと（出力が観測可能ポイントとなっていると）、図５のステップ１０８に移行して有効なテストケースと判定する（検査対象を確認でき、可観測性、パス識別性を満たす）。

ステップ１０７において出力が観測可能ポイントでないとステップ１０３に戻り、ステップ１０３で更なる接続先を検索し、ステップ１０４，１０５，１０６，１０７の処理を実行して出力が観測可能ポイントとなるまでこれを繰り返す。

よって、図５のステップ１０３→１０４→１０５→１０７→１０３→…を繰り返すことにより、テストケースによるモデルのシミュレーションを通して、検査対象ブロックとしてのＡｂｓブロック５０の出力値が観測できるポイント（観測可能ポイント）まで有効であるか否か判定され、これにより妥当性検証が行われる。

このようにして、Ａｂｓブロック５０を検査対象ブロックとし、かつ、各テストケースについての図５の処理が行われる。
次に、図３のモデルにおいて、スイッチブロック６０を検査対象ブロックとして図５の処理が実行される。

図５において、ステップ１０１で、図３におけるスイッチブロック６０を検査対象ブロックとして、スイッチブロック６０から観測可能ポイントまでのつながりを示す情報と、図４におけるスイッチブロック６０についての判断基準（ＩＩ）を収集する。

そして、図５のステップ１０２で、図３のスイッチブロック６０の入力Ｂがオンまたはオフであるか否か判定する。この図５のステップ１０２において対象ブロックに対して有効なデータでないと、ステップ１１１に移行して無効なテストケースと判定する（検査対象を確認できない）。

一方、図５のステップ１０２において対象ブロックに対して有効なデータであると、ステップ１０３で、図３におけるスイッチブロック６０には接続先が無く、図５のステップ１０４において図４におけるスイッチブロック６０についての判断基準（ＩＩＩ），（ＩＶ）を収集する。

図５のステップ１０５で、図３のスイッチブロック６０について図４の判断基準（ＩＩＩ）を用いて目的の入力（ＡまたはＣ）側に切り換えられるように入力Ｂがなっており、これにより目的の入力（ＡまたはＣ）に対応する出力が得られるか判定する。図５のステップ１０５において条件を満たさないと（出力データは観測可能でないと）、ステップ１１０に移行して無効なテストケースと判定する（検査対象を確認できるが可観測性を満たさない）。

一方、図５のステップ１０５において出力データは観測可能であると、ステップ１０６でパス識別可能か否か、即ち、分岐を伴うブロックとしてのスイッチブロックにおいてＡ，Ｃに入力する値が異なるか否かを判断する。具体的には、図３のスイッチブロック６０について図４の判断基準（ＩＶ）を用いて図３の入力Ａと入力Ｃとは異なるか否かを判定する。そして、判断基準（ＩＶ）の条件を満たさずパス識別可能でないとステップ１０９に移行して無効なテストケースと判定（検査対象を確認できるが、パス識別性を満たさない）と判定する。

図５のステップ１０６においてパス識別可能であるとステップ１０７に移行する。ステップ１０７で、図３のモデルでは、スイッチブロック６０の出力は観測可能ポイントとなっているので、ステップ１０８に移行して有効なテストケースと判定する（検査対象を確認でき、可観測性、パス識別性を満たす）。

このようにして、スイッチブロック６０を検査対象ブロックとし、かつ、各テストケースについての図５の処理が行われる。
次に、妥当性検証処理プログラム１７による妥当性検証結果を説明する。図６にはその一例を示す。

図６において、テストケースの番号と、検査対象ブロック名と、検査項目と、テストケースのデータと、シミュレーション結果のデータと、可観測性と、パス識別性と、トータルの妥当性検証結果を示している。図６のテストケースのデータおよびシミュレーション結果のデータの詳細について、図３のように、テストケースのデータとして、入力１，２，３を示し、また、シミュレーション結果としてＡｂｓブロックの入力１（ｉｎ１）と、スイッチブロックの入力１（ｉｎ１）と、スイッチブロックの入力２（ｉｎ２）と、スイッチブロックの入力３（ｉｎ３）と、出力１を示している。

図６の可観測性について、図５のステップ１０５でＹＥＳならば「○」を付し、ＮＯならば「×」を付している。図６のパス識別性について、図５のステップ１０６でＹＥＳならば「○」を付し、ＮＯならば「×」を付している。

図６の各テストケースにおいて、トータルの妥当性検証結果として、「Ａ」，「Ｂ」，「Ｃ」，「Ｄ」で評価している。「Ａ」は有効なテストケースと判定した場合（検査対象を確認でき、可観測性、パス識別性を満たす場合）、即ち、図５のステップ１０８の処理である。図６の「Ｂ」は無効なテストケースと判定した場合（検査対象を確認できるが、パス識別性を満たさない場合）、即ち、図５のステップ１０９の処理である。図６の「Ｃ」は無効なテストケースと判定した場合（検査対象を確認できるが、可観測性を満たさない場合）、即ち、図５のステップ１１０の処理である。図６の「Ｄ」は無効なテストケースと判定した場合（検査対象を確認できない場合）、即ち、図５のステップ１１１の処理である。

図６において、具体的には、テストケース番号１〜７については、次のようになる。
［テストケース番号１］：
検査対象ブロック名が「Ａｂｓブロック」、検査項目が「負の値」、テストケースでの入力１が「−５」、入力２が「オン」、入力３が「３」である。シミュレーション結果は、Ａｂｓブロックの入力１が「−５」、スイッチブロックの入力１が「５」、スイッチブロックの入力２が「オン」、スイッチブロックの入力３が「３」、出力１が「５」である。そして、図５のフローにおいてステップ１０１→１０２→１０３→１０４→１０５→１０６→１０７→１０８となり、これにより、可観測性が「○」、パス識別性が「○」、妥当性検証結果が「Ａ」となる。

［テストケース番号２］：
検査対象ブロック名が「Ａｂｓブロック」、検査項目が「負の値」、テストケースでの入力１が「−５」、入力２が「オフ」、入力３が「３」である。シミュレーション結果は、Ａｂｓブロックの入力１が「−５」、スイッチブロックの入力１が「５」、スイッチブロックの入力２が「オフ」、スイッチブロックの入力３が「３」、出力１が「３」である。そして、図５のフローにおいてステップ１０１→１０２→１０３→１０４→１０５→１１０となり、これにより、可観測性が「×」、パス識別性が「−」（即ち、可観測性が無いのでパス識別性を判断しない）、妥当性検証結果が「Ｃ」となる。

［テストケース番号３］：
検査対象ブロック名が「Ａｂｓブロック」、検査項目が「負の値」、テストケースでの入力１が「−５」、入力２が「オン」、入力３が「５」である。シミュレーション結果は、Ａｂｓブロックの入力１が「−５」、スイッチブロックの入力１が「５」、スイッチブロックの入力２が「オン」、スイッチブロックの入力３が「５」、出力１が「５」である。そして、図５のフローにおいてステップ１０１→１０２→１０３→１０４→１０５→１０６→１０９となり、これにより、可観測性が「○」、パス識別性が「×」、妥当性検証結果が「Ｂ」となる。

［テストケース番号４］：
検査対象ブロック名が「Ａｂｓブロック」、検査項目が「正の値」、テストケースでの入力１が「０」、入力２が「オン」、入力３が「３」である。シミュレーション結果は、Ａｂｓブロックの入力１が「０」、スイッチブロックの入力１が「０」、スイッチブロックの入力２が「オン」、スイッチブロックの入力３が「３」、出力１が「０」である。そして、図５のフローにおいてステップ１０１→１０２→１１１となり、これにより、可観測性が「−」、パス識別性が「−」、妥当性検証結果が「Ｄ」となる。

［テストケース番号５］：
検査対象ブロック名が「Ａｂｓブロック」、検査項目が「正の値」、テストケースでの入力１が「５」、入力２が「オン」、入力３が「３」である。シミュレーション結果は、Ａｂｓブロックの入力１が「５」、スイッチブロックの入力１が「５」、スイッチブロックの入力２が「オン」、スイッチブロックの入力３が「３」、出力１が「５」である。そして、図５のフローにおいてステップ１０１→１０２→１０３→１０４→１０５→１０６→１０７→１０８となり、これにより、可観測性が「○」、パス識別性が「○」、妥当性検証結果が「Ａ」となる。

［テストケース番号６］：
検査対象ブロック名が「スイッチブロック」、検査項目が「オン側」、テストケースでの入力１が「１」、入力２が「オン」、入力３が「２」である。シミュレーション結果は、Ａｂｓブロックの入力１が「１」、スイッチブロックの入力１が「１」、スイッチブロックの入力２が「オン」、スイッチブロックの入力３が「２」、出力１が「１」である。そして、図５のフローにおいてステップ１０１→１０２→１０３→１０４→１０５→１０６→１０７→１０８となり、これにより、可観測性が「○」、パス識別性が「○」、妥当性検証結果が「Ａ」となる。

［テストケース番号７］：
検査対象ブロック名が「スイッチブロック」、検査項目が「オフ側」、テストケースでの入力１が「３」、入力２が「オフ」、入力３が「４」である。シミュレーション結果は、Ａｂｓブロックの入力１が「３」、スイッチブロックの入力１が「３」、スイッチブロックの入力２が「オフ」、スイッチブロックの入力３が「４」、出力１が「４」である。そして、図５のフローにおいてステップ１０１→１０２→１０３→１０４→１０５→１０６→１０７→１０８となり、これにより、可観測性が「○」、パス識別性が「○」、妥当性検証結果が「Ａ」となる。

このようにして、テストケース妥当性自動検証プログラム（妥当性検証処理プログラム１７）はモデルシミュレーションプログラム１４と協動して、テストケースによるモデルのシミュレーションを行って当該シミュレーションにより得られたブロックの入出力情報を用いてテストケースの妥当性を検証する。これによって、テストケースによるモデルのシミュレーションを行って当該シミュレーションにより得られたブロックの入出力情報を用いてテストケースの妥当性を検証することにより、ブロックのつながりを加味して適切にテストケースの妥当性を自動検証することができる。即ち、テストケースによるモデルのシミュレーションを行ってそのシミュレーション結果を解析することにより、カバレッジだけでなく、ブロックの入出力情報の関連性等を考慮したテストケースの妥当性を自動検証することが可能となる。

図２における、表による妥当性検証結果表示プログラム２０の実行結果として、表による妥当性検証結果表示の一例を、図７に示す。図７においては、図６でのテストケースの番号と、検査対象ブロック名と、検査項目と、テストケースでの入力１，２，３と、トータルの妥当性検証結果を表示している。

図２における、モデルによる妥当性検証結果表示プログラム１９の実行結果として、モデルによる妥当性検証結果表示の一例を、図８に示す。図８においては、図６で妥当性検証結果が「Ｃ」となったテストケース番号２を表示している。図８において太い線で示す信号線は、選択したテストケースを入力した際の有効なパスを表す。また、信号線上の数値は、選択したテストケースにおける信号線の値を表す。なお、選択したテストケースにおいて有効なパスを表す際に、他の線とは異なる色にて示すようにしてもよく、具体的には、有効なパスを赤色で示し、その他のパスを黒色で示すようにしてもよい（赤い信号線にて、選択したテストケースにおいて有効なパスを表すようにしてもよい）。また、図８において符号７０に示す欄において、テストケース番号（＝「２」）と、検査対象ブロック名（＝Ａｂｓブロック）と、検査項目（＝負の値）と、妥当性検証結果（＝Ｃ）と、を表示している。

このように、テストケースの妥当性検証結果をモデル上で表示するための結果表示手段（図２のモデルによる妥当性検証結果表示プログラム１９）を有しており、これにより、テストケースの妥当性の自動検証結果をモデルに反映することにより、モデル上でテストケースの妥当性検証結果を確認（視認）できる。具体的には、不適（ＮＧ）となった検査対象ブロックに対して、モデル上で検査対象ブロック名、テストケース入力ポイントから観測可能ポイントまでの有効パス、信号線の値を表示することにより不適となった原因（図８のスイッチブロックがオフ側になっていること）が明確となり、テストケースの修正（図８の入力２をオンに直すこと）を容易にすることが可能となる。また、例えば、すでにすべての検査対象ブロックに対してテストケースが存在するモデルに対して、そのモデルを変更した場合に、変更後のモデルに対して、変更前のテストケースを入力し、その妥当性検証結果から、有効な（変更後のモデルでも使用できる）テストケースを特定でき、テストケースの再利用性を向上させることが可能となる。

さらに、上述の「テストケースの可観測性」および「テストケースのパス識別性」について、より詳しく説明する。
具体例として、図９に示すように、Ａｂｓ（絶対値）ブロック、スイッチブロック（分岐）を検査対象としたテストケースを挙げる。図１０は、テストケースにおける可観測性、パス識別性情報を追加した例を示す。

図９，１０の場合、スイッチブロックの制御入力（図９の信号Ｂ）の状態（分岐情報）と各入力ポート（図９の信号Ａ、Ｃ）の比較結果（入力データの比較情報）のシミュレーション時の結果を保持し、以下のような判断により妥当性を検証する。

図１０において、各テストケース（テストケース１，２，３，４）についての、入力１、入力２、入力３、分岐情報、入力データ比較結果、出力、テストケースの妥当性（Ａｂｓ、Ｓｗｉｔｃｈ）を示す。

テストケース１は、スイッチブロックの検査としては有効であるが、Ａｂｓブロックの検査としては、分岐情報がオフ側であるため、妥当なテストケースとはならない。また、テストケース２は、入力１が「４」、入力３が「４」であり、入力データ比較結果が同一であるため、テストケースとして妥当ではない。

一方、テストケース３，４は、両ブロックに対して妥当なテストケースである。そして、妥当なテストケースに対してカバレッジ１００％を計測する。
このように、分岐情報、入力データの診断結果を用いることにより、検査対象ブロックに対するテストケースの妥当性を検証することができる。

即ち、図９において、１．シミュレーションでの入出力、２．分岐情報（可観測性を診断）、３．入力データの診断結果（パス識別性を診断）についての情報を元にパスを考慮し、テストケースの妥当性を検証する。

以上のように、テストケースによるモデルのシミュレーション実行中に、カバレッジを計測することに加え、『可観測性』、『パス識別性』の診断に必要な情報（分岐を伴う各ブロックに「分岐情報（可観測性を診断）」「入力データの比較結果（パス識別性を診断）」）を保持することよって、各テストケースに対して入力から観測可能ポイントまでのパス遷移を確認し、テストケースの妥当性を検証する。

なお、分岐を伴うブロックとして、以下のものを挙げることができる。
・ＳＩＭＵＬＩＮＫ（登録商標）におけるスイッチブロック、マルチポートスイッチブロック、Ｅｎａｂｌｅｄ Ｓｕｂｓｙｓｔｅｍなど
観測可能ポイントとして、以下のものを挙げることができる。

・出力ポート、データストアメモリなど
さらに、図２においてテストケース妥当性検証結果に基づいて、不足テストケース抽出処理プログラム２１は次のように処理する。妥当性検証結果収納部１８の妥当性検証結果と、情報収納部１２の情報と、妥当性判断基準収納部１６の妥当性判断基準から、不足テストケース抽出処理を行う。この不足テストケースの抽出結果は、テストケース不足の検査対象ブロック情報収納部２２に格納する。そして、モデルによる妥当性検証結果表示プログラム１９や表による妥当性検証結果表示プログラム２０により表示される。これによって、情報収納部１２の情報（検査対象ブロック名と、当該ブロックから観測可能ポイントまでのつながりを示す情報）と、妥当性判断基準収納部１６における検査対象ブロックに対する妥当性判断基準情報と、妥当性検証結果収納部１８における妥当性検証結果情報から、モデルに対するテストケースとして不足している箇所が判定でき、さらに、妥当性判断基準に基づき、不足しているテストケースの作成を補助することが可能となる。その結果、不足したテストケースを補うのを容易にすることが可能となる。

上記実施形態によれば、以下のような効果を得ることができる。
（１）図２に示すごとく、テストケース妥当性自動検証プログラムとしての妥当性検証処理プログラム１７において、モデルシミュレーションプログラム１４との協動により、テストケースによるモデルのシミュレーションを行って当該シミュレーションにより得られたブロックの入出力情報を用いてテストケースの妥当性を検証する。これにより、ブロックのつながりを加味して適切にテストケースの妥当性を自動検証することができる。つまり、テストケースを検査対象ソフトウェアではなく、モデルに入力して、シミュレーション結果を解析することにより、カバレッジだけでなく、ブロックの入出力情報の関連性を考慮して適切にテストケースの妥当性を自動検証することができる。即ち、実行可能であるモデルを参照してＣソースコードを作成するモデルベース開発において、作成した検査対象ソフトウェアに対しテストケースを入力するのではなくモデルに入力して、シミュレーション結果を解析することにより、適切にテストケースの妥当性を自動検証することができる。

詳しくは、図１６の場合、テストケースはＡｂｓブロックに対してカバレッジは１００％であるが、テストケース１において、入力２がオフとなっているため、観測可能ポイントで負の入力に対する確認ができないことを考慮して、ある検査項目に対して、観測可能ポイントまでパスが有効であることに着目する概念として、「可観測性」を用いる。

また、図１６の場合、テストケースはスイッチブロックに対してカバレッジは１００％であるが、テストケース２において、切り換える値が共に４であるため、観測可能ポイントで切り換わりを確認することができないことを考慮して、ある検査項目に対して、切り換える値が同じでないことに着目する概念として、「パス識別性」を用いる。そして、本実施形態では、図１１に示すように、カバレッジに加え、「可観測性」「パス識別性」という概念を取り入れ、モデルのシミュレーションを通して、各ブロックの入出力をもとにパスを確認することにより、テストケースの妥当性を検証する。

（２）「可観測性」に関して、図５のステップ１０３→１０４→１０５→１０７→１０３→…を繰り返すことにより、テストケースによるモデルのシミュレーションを通して、検査対象ブロックの出力値が観測できるポイントまで有効であるか否かによりテストケースの可観測性を考慮した妥当性検証を行うようにしたので、モデルのシミュレーションを実施することにより、検査対象ブロックから観測可能ポイントまでのデータの流れを確認することができる。換言すると、検査対象ブロック外のパスから出力されたデータが観測可能ポイントにつながるテストケースを排除することが可能となる。

（３）「パス識別性」に関して、図５のステップ１０６の処理を実行することにより、テストケースによるモデルのシミュレーションを通して、検査対象ブロックである分岐を伴うブロックに対する入力値が異なるか否かによりテストケースのパス識別性を考慮した妥当性検証を行うようにしたので、モデルのシミュレーションにより分岐を伴うブロックの出力を確認することができる（モデルのシミュレーションにより分岐しうるすべてのパスの演算結果を確認することができる）。換言すると、検査対象ブロックの出力が、他の分岐パスでの出力に対して同一ではない値であることを確認でき、同一な値をとるテストケースを排除することが可能となる。

（４）複数のブロックから構成されるモデルを仕様として作成したソフトウェアに対するテストケースの妥当性を自動検証した結果を表示する方法において（モデルによる妥当性検証結果表示プログラム１９を用いた結果表示方法として）、テストケースによるモデルのシミュレーションを行って当該シミュレーションにより得られたブロックの入出力情報を用いたテストケースの妥当性検証結果を、図８に示すようにモデル上で表示するようにした。よって、テストケースによるモデルのシミュレーションを行った結果を解析することによるテストケースの妥当性の自動検証結果をモデルに反映することにより、モデル上でテストケースの妥当性検証結果を確認（視認）でき、これにより、テストケースの修正、追加をすることが可能となる。

（５）モデルによる妥当性検証結果表示プログラム１９は、図８のように、テストケースの妥当性検証結果をモデル上で表示する際に、テストケースの番号も表示するようにした（図８では「Ｎｏ２」）。また、テストケースの妥当性検証結果をモデル上で表示する際に、検査対象としたブロック名も表示するようにした（図８では「Ａｂｓブロック」）。これにより、不適となったテストケース番号や検査対象ブロック名を容易に知ることができる。

なお、前記実施形態は以下のように変更してもよい。
テストケースによるモデルのシミュレーションを通して、モデルに設定されている信号線の取り得る範囲内であるか否かにより妥当性検証を行うようにしてもよい。これを、図１２，１３を用いて具体例を挙げながら説明する。

図１２においてはＡｂｓブロック８０と乗算ブロック８１と比較ブロック８２とスイッチブロック８３とを有し、乗算ブロック８１で入力２と入力３を乗算し、比較ブロック８２において乗算ブロック８１の出力が「１００」以下であるとスイッチブロック８３をオフ側に、また、乗算ブロック８１の出力が「１００」より大きいとスイッチブロック８３をオン側にする。スイッチブロック８３がオフ側のときは入力４がスイッチブロック８３を通して出力され、スイッチブロック８３がオン側のときは入力１がＡｂｓブロック８０を介してスイッチブロック８３を通して出力される。

スイッチブロック８３の検査では、入力２，３の値を調整して図１３のような、カバレッジを満たすテストケースを作成する。しかし、実環境における入力２，３の取り得る範囲に、「０≦入力２≦２、０≦入力３≦３０」という制約がある場合、「（入力２）×（入力３）≧１００」が成立することはない。そのため、スイッチブロック８３のオン側は、実環境では通り得ないパスとなる。

このように、ブロックの入力値の取り得る範囲をモデル上で設定した上で、テストケースの妥当性検証処理を実施することにより、図１２の比較ブロック８２の入力値が図１３のテストケース１では「１０２」となり、またテストケース２では「１００」となり、６１以上となっている。つまり、シミュレーションによるブロックの入出力情報としての値、即ち、図１２の比較ブロック８２の入力値が６１以上か否か判定する。そして、図１３のように取り得ない範囲のテストケース１，２では妥当性検証結果（判定）として「×」となる。それゆえ、取り得ない範囲のテストケースを排除することができる。また、実環境では通り得ないパスを発見することが可能となる。

以上のように、モデルに規定されている実環境では取り得ない範囲となるテストケースを排除することが可能となるため、実環境では通り得ないパスを発見することが可能となる。

本実施形態に係るパーソナルコンピュータの構成を示す図。 パーソナルコンピュータのＣＰＵが実行するプログラムの構成図。 説明のために用いたモデル図。 妥当性判断基準を示す図。 妥当性検証処理プログラムの処理の流れを示す図。 妥当性検証結果を示す図。 表による妥当性検証結果表示の一例を示す図。 モデルによる妥当性検証結果表示の一例を示す図。 検査対象ブロックを示す図。 テストケースの例を示す図。 テストケースの評価手順を示す図。 検査対象ブロックを示す図。 テストケースの例を示す図。 従来のテストケースの評価手順を示す図。 検査対象ブロックを示す図。 テストケースの例を示す図。

符号の説明

１…パーソナルコンピュータ、７…ＣＰＵ、１４…モデルシミュレーションプログラム、１７…妥当性検証処理プログラム、１９…モデルによる妥当性検証結果表示プログラム、２０…表による妥当性検証結果表示プログラム。

Claims (7)

1. 複数のブロックから構成されるモデルを仕様として作成したソフトウェアに対するテストケースの妥当性を自動検証するプログラムであって、
   テストケースによる前記モデルのシミュレーションを行って当該シミュレーションにより得られたブロックの入出力情報を用いてテストケースの妥当性を検証することを特徴とするテストケース妥当性自動検証プログラム。
2. 請求項１に記載のテストケース妥当性自動検証プログラムにおいて、
   テストケースによるモデルのシミュレーションを通して、検査対象ブロックの出力値が観測できるポイントまで有効であるか否かにより妥当性検証を行うことを特徴とするテストケース妥当性自動検証プログラム。
3. 請求項１に記載のテストケース妥当性自動検証プログラムにおいて、
   テストケースによるモデルのシミュレーションを通して、検査対象ブロックである分岐を伴うブロックに対する入力値が異なるか否かにより妥当性検証を行うことを特徴とするテストケース妥当性自動検証プログラム。
4. 請求項１に記載のテストケース妥当性自動検証プログラムにおいて、
   テストケースによるモデルのシミュレーションを通して、モデルに設定されている信号線の取り得る範囲内であるか否かにより妥当性検証を行うことを特徴とするテストケース妥当性自動検証プログラム。
5. 複数のブロックから構成されるモデルを仕様として作成したソフトウェアに対するテストケースの妥当性を自動検証した結果を表示する方法であって、
   テストケースによる前記モデルのシミュレーションを行って当該シミュレーションにより得られたブロックの入出力情報を用いたテストケースの妥当性検証結果を前記モデル上で表示するようにしたことを特徴とするテストケース妥当性自動検証結果表示方法。
6. 請求項５に記載のテストケース妥当性自動検証結果表示方法において、
   前記テストケースの妥当性検証結果をモデル上で表示する際に、テストケースの番号も表示するようにしたことを特徴とするテストケース妥当性自動検証結果表示方法。
7. 請求項５に記載のテストケース妥当性自動検証結果表示方法において、
   前記テストケースの妥当性検証結果をモデル上で表示する際に、検査対象としたブロック名も表示するようにしたことを特徴とするテストケース妥当性自動検証結果表示方法。

Images