JP3415310B2 - テストケース作成装置 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、コンピュータ応用製品
の開発において、その動作試験に使用されるテストケー
スを作成するテストケース作成装置に関する。

【０００２】

【従来の技術】現在利用されているほとんどの機器類
に、コンピュータが利用されている。例えば、日常利用
される電化製品から交通手段まで、更に工場や発電所等
の、ほとんどの機器にコンピュータが利用されている。
これらのコンピュータが利用（応用）された製品を便宜
上コンピュータ応用製品と呼ぶ。このように、コンピュ
ータ応用製品が社会生活と密接な関係を有するにつれ、
コンピュータ応用製品の誤動作が社会にもたらす影響は
非常に大きくなるので、コンピュータ応用製品に対する
信頼性の要求はますます大きくなっている。

【０００３】コンピュータ応用製品の信頼性を確保する
ためには、試験工程が重要である。その製品が満足すべ
き機能仕様及び性能仕様等のすべての項目について実際
に動作確認を実施し、不具合があれば修正することによ
って、当該製品がいかなる状況においても正しく動作す
ることを保証しなければならない。従って、どのような
試験をどれだけ行なうかという問題（試験の方法及び回
数（量）等を定めたものを以下「テストケース」と称す
る）は、製品の信頼性を確保する上で非常に重要であ
る。限られた時間及び作業量の範囲内で実施可能な試験
を行って、製品の信頼性を確保するためには、効率的な
テストケースを作成することが不可欠である。

【０００４】従来の試験作業においては、その製品の満
足すべき機能及び性能を一覧表にしたチェックリストが
テストケースとして用られ、試験者が手作業で操作しな
がらチェック項目を一つ一つ確認することにより、製品
の信頼性を確保している。この場合に、チェックリスト
は一応の製品動作を確認するという点では有効である。
しかし、実際にそのチェックリストによって、製品の取
り得る動作のうちどれだけを網羅して確認できたは定か
ではない。一般に、製品の取り得る動作を全て網羅して
その動作を確認できるようなテストケースをチェックリ
ストという形で実現することは、かなりの熟練者にとっ
ても非常に困難である。従って、従来の試験では、熟練
技術者が固有の製品知識と経験に基づいて、与えられた
時間内で考えられる動作を確認するという形がとられ
る。しかし、近年のコンピュータ応用製品の複雑化及び
大規模化に伴い、熟練者であっても、上記のような経験
と勘に頼った方法では、製品の信頼性を確保することは
困難となりつつある。

【０００５】また、手作業操作による試験では、製品に
対するセンサ入力等を何らかの機器（例えば可変抵抗器
等）を用いて作り出す必要がある。しかし、この方法で
は、実際には、試験対象に対する入力が所望の試験を行
うための入力となっていることを保証することは容易で
はない。更に、手作業による試験では、上記のように一
つ一つの入力信号を作ってテストケースに対応する試験
条件を設定することは非常に手間がかかる。従って、従
来では、試験作業に大きな工数を要するか又は定められ
た時間内でこなせるテストケース数が少なくなるかのい
ずれかとなり、それによって製品の生産性及び／又は品
質に悪影響を及ぼす可能性がある。

【０００６】以上のように、従来のような試験方法で
は、コンピュータ応用製品の信頼性を十分に保証するこ
とは非常に難しい。試験の対象であるコンピュータ応用
製品に組み込まれるプログラムの構造を解析した上で、
そのプログラムを構成する各部分を網羅するような試験
入力を作成する手段を用いる方法も考えられている。し
かし、この方法はプログラムの複雑さや規模を考慮する
と、せいぜいプログラム・モジュールを対象とした単体
試験どまりであり、製品の統合試験、システム試験段階
で用いることは困難である。

【０００７】いくつかの製品分野においては、製品の仕
様を形式的に記述し、その仕様記述に基づいてテストケ
ースを網羅的に作成するという試みも行なわれている。
例えば、電子回路や通信プロトコル等の分野では、状態
遷移図を用いて仕様を記述して、その仕様に記述されて
いる動作をもれなく実行させるテストケースを自動的に
作成する方法が提案されている。Ｕ．Ｓ．Ｐａｔ．Ｎ
ｏ．４，６９２，９２１は、その１つの例である。しか
し、この方法においても、製品仕様の複雑化及び大規模
化に伴い、１つの状態遷移図で製品の全仕様を記述する
ことが困難であるので、この方法でもテストケースを自
動的に作成することは不可能といえる。

【０００８】上記のように、プログラムの取り得る動作
を網羅して、コンピュータ応用製品の信頼性を十分に確
保できるテストケースを作成することは、非常に困難で
ある。

【０００９】チェックリストを用いた試験では、その試
験の十分性はテストケースそのものの出来によって決ま
ってしまう。テストケースは、製品の仕様書等を参考に
して、人手によって作成しなければならないので、非常
に手間がかかる。また、テストケースの出来は、その元
になる仕様書に大きく依存するため、現在の自然言語を
用いた仕様書ではその曖昧さゆえに、十分に信頼できる
チェックリストを作成することは、非常に困難である。

【００１０】更に、上記の問題を解決するための形式的
な仕様記述からのテストケースの作成も、仕様そのもの
が大規模かつ複雑になるにつれて、仕様そのものを記述
すること、及び、抜けのないようにテストケースを作成
することの両者が困難になる。

【００１１】

【発明が解決しようとする課題】上記のように、従来
は、大規模かつ複雑な仕様を有するコンピュータ応用製
品の信頼性を十分に確保できるテストケースを作成する
ことは、非常に困難である。

【００１２】本発明の目的は、大規模かつ複雑な仕様を
有する製品に対しても、その仕様を容易に記述し、その
仕様から抜けのない製品動作を効率的に網羅し得るテス
トケースを自動的に作成することにより、製品信頼性を
十分確保することができるテストケース作成装置を提供
することである。

【００１３】

【課題を解決するための手段】本発明は、上記の課題を
解決するために次のような手段を講じた。本発明に係る
テストケース作成装置は、対象物の動作検証を行うため
のテストケースを作成するテストケース作成装置であっ
て、前記対象物の動作仕様を並行化（及び／又は階層
化）された複数の状態遷移図を用いて記述する動作仕様
記述手段と、前記動作仕様記述手段で記述された複数の
状態遷移図を探索して所定の状態からの状態遷移図上の
状態の遷移を選択し、その結果を出力する状態遷移図探
索手段と、アクションとイベントとの関係を記憶し、禁
止された遷移を管理して前記状態遷移図探索手段での遷
移選択の操作を制御するアクション／イベント関係管理
手段と、を具備する。更に、本発明装置は、前記動作仕
様記述手段で記述された階層化された前記複数の状態遷
移図の探索順序（及び遷移網羅の十分性）を管理して、
前記状態遷移図探索手段での遷移選択の操作を制御する
並行（及び／又は階層）関係管理手段を更に具備する。

【００１４】更に、本発明に係るテストケース作成装置
は、前記状態遷移図探索手段から順次出力される遷移を
生起させるイベント情報をテストケースとして格納する
テストケース格納手段を更に具備する。本発明装置の望
ましい実施態様は以下の通りである。 （１） 前記テストケース格納手段は、前記前記状態遷
移図探索手段で選択されたイベントを時系列順に管理す
る手段を含むこと。 （２） 前記状態遷移図探索手段は、階層間の状態組合
せを考慮して、選択可能な遷移が未選択の遷移かどうか
を判定する手段を含むこと。 （３） 前記状態遷移図探索手段は、前記アクション／
イベント管理手段を参照して、発生するイベントをチェ
ックする手段を含むこと。

【００１５】また、本発明のテストケース作成方法は、
対象物の動作検証を行うためのテストケースを作成する
方法において、前記対象物の動作仕様を並行化及び階層
化の少なくとも一方の形式の複数の状態遷移図を用いて
記述するステップと、前記複数の状態遷移図を探索し
て、所定の状態からの状態遷移図上の状態の遷移を選択
し、その結果を出力するステップと、アクションとイベ
ントとの関係を記憶し、禁止された遷移を管理して前記
遷移の選択の操作を制御するステップと、を具備する。
更に、前記探索ステップは、記憶された前記アクション
とイベントとの関係を参照して、発生イベントをチェッ
クするステップを含む。

【００１６】本発明方法は、前記複数の状態遷移図の探
索順序を管理して、前記状態遷移図探索手段での遷移選
択の操作を制御するステップを更に具備する。前記制御
ステップは、遷移網羅の十分性を管理するステップを含
み、加えて、階層間の状態組合せを考慮した上で、選択
可能な遷移が未選択の遷移かどうかを判定するステップ
を含む。

【００１７】

【作用】上記手段を講じた結果、次のような作用が生じ
る。本発明では、動作仕様記述手段が並行化及び階層化
の少なくとも一方の概念を取り入れて製品の動作仕様を
記述するので、大規模かつ複雑な動作仕様の記述が極め
て容易になる。

【００１８】動作仕様記述手段によって記述された対象
物の動作仕様は、各状態遷移図毎に状態遷移図探索手段
によって探索処理される。状態遷移図探索手段は、例え
ば状態をノード、遷移をその遷移の向きに方向付けられ
たアークとする有向グラフとみなし、アークの向きにノ
ードをたどりながら状態遷移図を探索し、状態遷移図に
おける有向グラフの一連のパスとして動作を特定してい
く。

【００１９】並行関係管理部は並行に動作する状態遷移
図の探索実行順序を管理される。階層関係管理手段は階
層化された状態遷移図の探索実行順序を管理すると共
に、階層を考慮した上での遷移網羅の十分性を判定し、
探索を行なうかどうかを管理する。アクション／イベン
ト関係管理手段は、アクションとイベントの関係を保持
して現実に発生しないような事象に対応する探索を回避
する。

【００２０】上記の構成により、対象物の動作検証とし
て信頼性を確保することができ、しかも抜けのない製品
動作を網羅できるテストケースを作成することが可能に
なる。

【００２１】上記のように、本発明を用いることによっ
て、製品のシステム試験用に、抜けのないテストケース
を、容易に作成することができる。また、本発明によっ
て作成されたテストケースを用いることより、製品プロ
グラムを網羅した試験を行なうことができ、製品の信頼
性を十分に確保することが実現される。

【００２２】

【実施例】図面を参照して本発明の実施例を説明する。
本発明の第１実施例を説明する前に、本発明において試
験対象製品の製品仕様の記述に用いられ、階層化・並行
化の概念を有する状態遷移図を説明する。

【００２３】コンピュータ応用製品の動作仕様は、状態
遷移図を用いて記述することができる。これは、多くの
場合コンピュータ応用製品の動作が、外部からの入力や
要求に応じて何らか処理を実行する性質を持つからであ
る。

【００２４】状態遷移図においては、 入力（条件）×内部状態 → 出力（処理）×次状態 のように、外部からの入力とその時の製品の内部状態か
ら、出力と新たな内部状態を決定するというサイクルを
繰り返す形で、製品動作が記述されていく。実際の状態
遷移図上では、製品の取り得る複数の内部状態がそれぞ
れ丸印（○）によって表現され、ある内部状態から次の
内部状態への状態遷移が矢印（→）として表現される。
更に、その状態遷移の条件となる入力及び状態遷移に伴
って実行される処理による出力は、矢印上に「入力／出
力」のように記載される。以後、入力・条件を「イベン
ト」、出力・処理を「アクション」と呼ぶ。

【００２５】本発明は、大規模かつ複雑な仕様に対応す
るために、並行化及び階層化の少なくとも一方の概念を
状態遷移図に導入する。以下、「並行化」及び「階層
化」について簡単に説明する。

【００２６】「階層化」とは、動作仕様をその抽象度に
従ってレベル分けすることである。レベル分けされた動
作仕様に応じて階層化された複数の状態遷移図が作られ
る。これらの階層化された状態遷移図は、次のような関
係を有する。

【００２７】ある状態遷移図（上位層の状態遷移図）に
記述されたある状態を詳細化（具体化）した状態遷移図
が他の状態遷移図（下位層の状態遷移図）である。そし
て、上位層の状態遷移図がある状態にある間は、当該状
態に対応する下位層の状態遷移図も同時に実行され、上
位層の状態遷移図において、当該状態から他の状態に遷
移した時点で、対応する下位層の状態遷移図の実行は終
了する。このように、本発明は、状態遷移図の階層化に
より、階層化された複数の状態遷移図が同時に実行され
る特徴を有する。

【００２８】「並行化」とは、複数の動作を並行な関係
で同時に実行することである。並行化された複数の状態
遷移図（階層化された状態遷移図群を含む）は、階層関
係ではなく、並行（独立）な関係で同時に実行される。
従って、並行に実行される状態遷移図間では、階層化さ
れた状態遷移図とは異なり基本的には関係は有しない。
しかし、仕様上で並行関係にある状態遷移図間に何らか
の同期等をとる必要が生じた場合には、イベントとアク
ションを用いてその関係を仕様上に記述する必要があ
る。

【００２９】なお、本発明においては上記の状態遷移図
の並行化及び階層化の概念が同時に利用可能であること
は云うまでもない。図１は、本発明のテストケース作成
装置でテストケース作成の対象となる並行化及び階層化
された状態遷移図の一例を示す図である。

【００３０】図１の複数の状態遷移図は、自動空調シス
テムの仕様を示す。なお、図１では、イベント及びアク
ションの記述を省略している。以下、図１の自動空調シ
ステム（以下、単に「システム」と称する）の仕様を簡
単に説明する。

【００３１】システムが起動すると、システムは外気温
の監視を開始する。システムは、外気温がある温度を越
えると冷房動作を開始し、ある温度を下回ると暖房動作
を開始する。なお、暖房動作を開始した場合に限り、暖
気を循環させるために、一定周期で天井ファンを回転／
停止させる。それぞれの暖房動作（又は冷房動作）中に
は、室内温度を監視して、所定温度をしきい値にして、
ヒータ（又はクーラ）運転を行なう。また、外気温があ
る範囲内に戻ったら、暖房又は冷房の動作を停止する。

【００３２】図１では、状態遷移図ＳＤ１がシステムの
最上位の階層である。図１において、並行関係にあるの
は、例えば、状態遷移図ＳＤ２と状態遷移図ＳＤ３とで
あり、階層関係にあるのは、例えば、状態遷移図ＳＤ２
と状態遷移図ＳＤ４、状態遷移図ＳＤ２と状態遷移図Ｓ
Ｄ５等である。

【００３３】システムは、空調開始の指示を受けると、
システムの状態を動作中に変えると共に、状態遷移図Ｓ
Ｄ１の下位層の状態遷移図ＳＤ２を展開する。状態遷移
図ＳＤ２は外気温を監視して、暖房及び冷房の開始と停
止のコントロールを行なう動作仕様を記述した状態遷移
図である。状態遷移図ＳＤ２において、暖房（又は冷
房）を開始する時は、状態を暖房（又は冷房）に移し、
暖房（又は冷房）の下位層の暖房（又は冷房）の状態遷
移図ＳＤ４（又はＳＤ５）を展開する。

【００３４】天井ファン制御の動作を記述した状態遷移
図ＳＤ３は、暖房開始と共に状態遷移図ＳＤ２と並行な
状態遷移図として起動される。状態遷移図ＳＤ３の起動
はアクションＡ１によって行なわれ、天井ファンは、ア
クションＡ１によって引き起こされるイベントＥ１によ
って待機状態からファンオン状態に状態を遷移し、動作
を開始する。

【００３５】更に、天井ファンは、起動時と同様に、状
態遷移図ＳＤ２において暖房を終了する遷移に伴うアク
ション（図示しない）によって発生されるイベント（図
示しない）により終了し、状態遷移図ＳＤ３は待機中の
状態になる。

【００３６】以上、単純な例であるが、上記のように並
行化及び階層化の概念を導入することにより、仕様を理
解し易くかつコンパクトに記述できることが分かる。図
１のような状態遷移図において、状態の遷移によって隣
あった状態を初期状態からたどっていくことは、その製
品動作の１つの流れを追うことに対応する。更に、製品
動作の流れは、その時実際にたどられた遷移の列（遷移
系列）によって特定される。ここで、テストケースとは
試験すべき製品の動作の流れであるから、テストケース
はその状態遷移図の遷移系列として表現される。更に、
遷移系列はその遷移系列をたどるイベントの列によって
も表現されるので、テストケースはイベント系列である
ともいえる。

【００３７】本発明では、テストケースをイベント系列
という形で自動的に作成する。図２は、本発明の第１実
施例に係るテストケース作成装置の構成を示すブロック
図である。

【００３８】第１実施例のテストケース作成装置は、製
品仕様記述部１と、複数の状態遷移図探索部２と、並行
関係管理部３と、アクション／イベント関係管理部５
と、テストケース格納部６とを具備する。

【００３９】製品仕様記述部１は、テストケース作成の
対象となる製品の動作仕様を形式的に記述する。この場
合において、製品仕様記述部１は、並行化の概念を有す
る状態遷移図として動作仕様（すなわち製品仕様）を記
述する。このように状態遷移図の記述に並行化の概念を
取り入れることにより、大規模化する仕様を容易に記述
できる。

【００４０】状態遷移図探索部２は、テストケース作成
のために状態遷移図を有向グラフとして探索する。具体
的には、状態遷移図探索部２は、状態遷移情報を製品仕
様記述部１から読み込み、状態遷移図における有向グラ
フの一連のパスとして製品の動作を特定しながらテスト
ケースを作成する。これらの状態遷移図探索部２は、実
行時には、一枚の状態遷移図に対し１つの状態遷移図探
索部２が割り当てられる。各状態遷移図探索部２は対応
するそれぞれの状態遷移図の現在の状態を常に管理して
おり、詳細は後述するアクション／イベント関係管理部
５から通知される発生／非発生イベントを参照しなが
ら、現在の状態からの遷移を１つずつ選択して、現在の
状態を次の状態に移すという方法で、探索を進める。状
態遷移図探索部２によって選択された遷移の情報は、そ
れを生起させるイベントという形でテストケース格納部
６に時々刻々伝達され、イベント列として格納される。

【００４１】並行関係管理部３は、並行に動作する複数
の状態遷移図の関係を管理する。具体的には、並行関係
管理部３は、複数の並行な状態遷移図の探索を実行する
順序を管理する。何故ならば、並行化された状態遷移図
は見かけ上は並行関係にあるが、実際には一連の順序で
探索されるからである。

【００４２】アクション／イベント関係管理部５は、ア
クションとイベントの関係を管理する。このアクション
とイベントとの関係は、通常は並行に動作する状態遷移
図間での通信に用いられ、アクション／イベント関係管
理部５は、あるアクションが実行されると、その結果、
あるイベントが発生する（又は発生しなくなる）という
関係を管理する。アクション／イベント関係管理部５
は、例えば、「フラグをセットしろ」というアクション
を実行することにより、「フラグをセット状態」という
イベントが発生するというような関係を管理する。この
ように、アクション／イベント関係管理部５が、発生／
非発生イベント情報を状態遷移図探索部２に提供するこ
とで、現実に起こらないような事象に対応したテストケ
ースを作成してしまうことを回避できる。

【００４３】テストケース格納部６は、状態遷移図探索
部２による作成中（又は作成済）のテストケースを保持
（格納）する。状態遷移図探索部２が時々刻々選択し、
通知してくる遷移（実際にはその遷移を生起させるイベ
ント情報）を受信して蓄積する。状態遷移図探索部２に
よる探索の終了時には、それらの遷移（イベント情報）
の時系列が、テストケース格納部６にテストケースとし
て格納されている。

【００４４】上記のように構成された第１実施例に係る
テストケース作成装置の動作を説明する。製品仕様記述
部１によって製品の動作仕様を形式的に記述する。製品
仕様の記述方式は、状態遷移図とする。この場合におい
て、本発明では、近年の複雑化・大規模化する仕様を記
述できるだけの記述力を持たせるために、通常の状態遷
移図に並行化の概念を取り入れている。このように、動
作仕様の記述に並行化の概念を用い、動作仕様を構造化
して考えることにより、動作仕様を容易に記述すること
が可能になる。

【００４５】各状態遷移図探索部２は、並行化された複
数の状態遷移図をそれぞれ格納する。次に、各状態遷移
図探索部２は、個々の状態遷移図に対し、有向グラフの
探索の手法等を用いることによって、テストケースを探
索する。すなわち、各状態遷移図探索部２は、状態遷移
図における有向グラフの一連のパスとして動作を特定し
ながらテストケースを探索する。複数の状態遷移図が並
行関係にあるために、同時に複数の状態遷移図が動作す
るような場合には、状態遷移図探索部２は、並行関係管
理部３によるそれぞれの状態遷移図に対する探索順序の
指示に従って探索を行ない、製品全体に対するテストケ
ースを作成する。

【００４６】状態遷移図探索部２が状態遷移図を探索し
ていく際に、単に有向グラフとしてのみの探索を行なう
ならば、どのような遷移も可能である。しかし、各遷移
にはイベントとアクションが付随しており、イベントは
遷移発生の条件を、アクションは遷移発生時の処理を意
味しているので、実際にはアクションとイベントの組合
わせにより、ある状態で発生するイベントと発生しない
イベントの区別がつく場合がある。このような状況は、
特に並行に動作する複数の状態遷移図間で情報をやりと
りする場合に多く見られる。

【００４７】そこで、アクション／イベント関係管理部
５は、アクションとイベントの関係を管理し、ある状態
で発生可能（又は不可能）なイベントを識別する。状態
遷移図探索部２は、探索中に遷移を選択する際に、アク
ション／イベント関係管理部５に問い合わせを行なっ
て、イベントの発生可能性を調べ、現実には有り得ない
動作（禁止された動作）に対応したテストケースを作成
しない。

【００４８】状態遷移図探索部２で選択された各状態遷
移図に対応するそれぞれの遷移（より正確には遷移を発
生させるイベント）は、時間経過毎に一列に並べられ
る。これによって、その製品仕様全体に対するテストケ
ースを構成する。それぞれの状態遷移図探索部２は、選
択した遷移（イベント）をその都度、テストケース格納
部６に通知する。テストケース格納部６は通知された一
つ一つの遷移（イベント）を時系列順に管理し、全ての
探索が終了した段階で、１つのテストケースとして格納
する。

【００４９】以上のようにして、システム試験工程にお
いて、製品動作の信頼性を確保するのに十分かつ抜けの
ないテストケースを作成することが実現される。図３
は、上記の動作を実現して、実際のテストケースを作成
する方法を示すフローチャートである。

【００５０】図示しない制御部がテストケースの作成作
業に伴う作業用のデータ領域を初期化する（ステップＳ
１）。この記憶領域は、テストケースの十分性を各遷移
毎に記憶する領域及びアクション／イベント関係部の発
生／非発生イベントの記憶領域等である。この場合に、
テストケースの十分性とは、状態遷移図に記述された動
作仕様における状態遷移を全て網羅しているかどうかを
いう。従って、テストケースの十分性が１００％とは、
テストケースが状態遷移図に記述された動作仕様におけ
る状態遷移を全て網羅していることをいう。

【００５１】状態遷移図探索部２が、製品仕様記述部１
によって記述された製品仕様を、読み込む（ステップＳ
２）。この場合に、状態遷移図の情報は、各遷移毎に状
態、イベント、アクション及び次状態の四つの情報の組
の集まりとして表現されるので、例えば、図４に示すよ
うに表形式で格納する。

【００５２】ステップＳ３から、探索処理（すなわちテ
ストケースの作成）に入る。ステップＳ３では、１つの
テストケースの終了の判断を行う。この場合に、１つの
テストケースの作成終了判定には、すべての遷移の十分
性が１００％になった時、現在の状態からの到達範囲内
のすべての遷移について十分性が１００％になった時、
状態遷移図の現在の状態からの遷移先がなくなった時又
は（無限に長い系列を作成するのを防ぐために）テスト
ケースが一定の長さを越えた時等といった条件を用い
る。

【００５３】並行関係管理部３は、状態遷移図探索部２
が探索するプロセスを決定する（ステップＳ４）。ここ
で、プロセスとは、並行に実行され得る状態遷移図の単
位を示す。１つのプロセスは１枚以上の状態遷移図によ
って構成される。

【００５４】並行関係管理部３は、探索するプロセスの
決定に際し、疑似的に並行な動作を実現するために、一
般にオペレーティングシステムの世界で用いられるスケ
ジューリングアルゴリズム等を使って、スケジューリン
グを行なう。最も単純なスケジュールングは、それぞれ
のプロセスを順番に探索し、最後まで終ったら又はじめ
のプロセスに戻るというものである。このスケジューリ
ングは、並行関係管理部内に、図５のような構造のデー
タを保持させることによって実現できる。

【００５５】状態遷移図探索部２は、ステップＳ４で指
定されたプロセスを構成する状態遷移図で探索を実行
し、遷移を選択する（ステップＳ５）。状態遷移図探索
部２による遷移探索の方法を、図６に示す。

【００５６】現在の状態からの遷移のうち、アクション
／イベント関係管理部５が提示する発生するイベントの
みによって遷移できるものであるかを調べる（ステップ
Ｓ５１）。遷移できるものがある場合には（ステップＳ
５２）、その遷移を選択して（ステップＳ５８）、ステ
ップＳ６に進む。ない場合には、ステップＳ５３に進
む。アクション／イベント関係管理部５が提示する発生
しないイベントをチェックする（ステップＳ５３）。そ
して、発生しないイベントの条件の下でも遷移可能な遷
移を、つまり発生しないイベントのために遷移不可能に
ならない遷移を探し（ステップＳ５４）、遷移可能な遷
移がない場合（ステップＳ５５）、ステップＳ６に進
む。ステップＳ５５において、遷移可能な遷移がある場
合には、それらの遷移が今までに選択されたことがある
かをチェックし（ステップＳ５６）、すべて選択済みの
場合にはステップＳ６に進む。ステップＳ５６におい
て、選択したことのないものがある場合には、それらの
中から１つの遷移を選ぶ（ステップＳ５７）。その選び
方は、例えば等確率で乱数によって決める等の方法が考
えられる。ステップＳ５７で決められた遷移はステップ
Ｓ５８にて選択され、ステップＳ６へ進む。

【００５７】ステップＳ５の探索実行の結果遷移が選択
されたかどうかを判定し（ステップＳ６）、遷移が選択
された場合にはステップＳ７に進み、ステップＳ５で選
択された遷移を実行する（ステップＳ７）。ステップＳ
５において、遷移が選択されなかった場合にはステップ
Ｓ１０へ進む。ステップＳ７において、遷移の実行は、
アクションの実行と状態の遷移とによって構成されてい
る。

【００５８】アクションの実行において、状態遷移図探
索部２が遷移に伴うアクションをアクション／イベント
関係管理部５に通知し、アクション／イベント関係管理
部５がそのアクションをキーにして、発生する（しなく
なる）イベントを予め登録されているデータから検索す
る。そして、検索されたイベントは、アクション／イベ
ント関係管理部５に発生／非発生イベントとして登録さ
れ、以後の探索に用いられる。

【００５９】具体的なアクション／イベント関係の管理
方法を図７に示す。アクション／イベント関係管理部５
は、状態遷移図探索部２が参照するための、その時点で
発生するイベントリスト及び発生しないイベントリスト
と、イベントとアクションとの関係を記録するアクショ
ン／イベント関係テーブルとを有する。例えば図７で
は、フラグがリセットされている時は、「フラグリセッ
ト中」が発生するイベント、「フラグセット中」が発生
しないイベントのリストに入っている。ここで、状態遷
移図探索部２の遷移選択の結果、「フラグセットしろ」
というアクションが実行されると、その情報がアクショ
ン／イベント関係管理部５に通信される。そして、アク
ション／イベント関係管理部５はアクション／イベント
関係テーブルを参照し、「フラグセットしろ」の結果
「フラグセット中」が発生し、「フラグリセット中」が
発生しなくなることを知る。そして、それぞれ発生する
イベントリスト、発生しないイベントリストを図７のよ
うに更新する。

【００６０】状態の遷移とは、選択された遷移に従って
現在の状態を新しい状態に移す動作である。状態遷移図
探索部２は、現在の状態を選択された遷移先の次状態に
移す。これにより、次回の探索からは、新しい現在の状
態（すなわち次状態）から探索する。

【００６１】テストケース格納部６に、テストケースを
構成するイベントが登録される（ステップＳ８）。この
場合に、状態遷移図探索部２は、ステップＳ５で選択さ
れた遷移を生起させるためのイベント情報を、テストケ
ース格納部６に通信する。テストケース格納部６は、通
信されたイベント情報を、探索の履歴として蓄え、探索
終了時には、蓄えられた探索の履歴が１つのテストケー
スを構成する。

【００６２】テストケース格納部６に、テストケースの
局所的な十分性の情報が登録される（ステップＳ９）。
十分性の管理の方法としては、各遷移の選択された回数
を記憶する方法がある。これにより、まだ選択されてい
ない遷移が識別可能となる。また、複数回遷移を選択す
る場合にも、選択される遷移が１つに集中することを避
ける。或いは、遷移を重要な遷移に集中させる等の調整
が可能となる。

【００６３】ステップＳ６の判定で、遷移が選択されて
いなかった場合には、ステップＳ１０の処理が行われ
る。ステップＳ１０では、探索のデッドロックの発生の
有無がチェックされる。複数のテストケースを作成して
いくと、探索の途中で十分性を満足し、局所的にはそれ
以上の遷移の選択を必要としなくなるため、遷移図にお
いてそれより先の部分において選択しなければならない
遷移があっても、そこまでたどり着けなくなる場合があ
る。例えば図８において、「Ａ」のようなパスに対応す
るテストケースを作成した後では、「ａ」の遷移はすで
に十分性を満足している。しかし、そこで探索を打ち切
ってしまうと、「ｂ」の遷移を試験することができな
い。このような状況を探索の「デッドロック」と呼ぶ。
並行な関係にある状態遷移図の探索順序は並行関係管理
部３によって管理されているが、この探索が各状態遷移
図に対してひとまわり実行されても、どの状態遷移図探
索部２においても遷移が選択されなかった場合に、デッ
ドロックが発生していると解釈する。

【００６４】ステップＳ１０においてデッドロックの発
生の有無で処理を振り分ける（ステップＳ１１）。ステ
ップＳ１１において、デッドロックが発生していない場
合には、ステップＳ３へ進む。デッドロックが発生して
いる場合には、ステップＳ１２へ進む。

【００６５】デッドロックを回避可能な遷移の探索を行
なう（ステップＳ１２）。この場合、すべての状態遷移
図探索部２の現在の状態からの遷移を対象にして、それ
らの中から１つの遷移を選択する。この時、アクション
／イベント関係管理部５を参照して、発生しないイベン
トをチェックし、その条件の下で遷移し得ない遷移は選
択できない。選択できる遷移の候補が複数存在する場合
には、それらの中から１つの遷移を選択する。選択の方
法としては、未選択の遷移が多く残っている状態遷移図
探索部２の遷移を優先させる、これまでの選択回数の少
ないものを選ぶ、条件が同じ場合には等確率で乱数によ
って決める等が考えられる。

【００６６】ステップＳ１２の結果、デッドロック回避
可能な遷移が発見できたら（ステップＳ１３）、その遷
移を選択してテストケース作成を継続するために、ステ
ップＳ７へ進む。ステップＳ１２において、デッドロッ
ク回避可能な遷移が発見できなかった場合には（ステッ
プＳ１３）、製品仕様自体がデッドロックを引き起こす
誤った仕様である可能性があるので、ステップＳ１４へ
進み、製品仕様自体にエラーが発生していることを開発
者にメッセージとして提示した上で、テストケース作成
を終了する（ステップＳ１４）。

【００６７】ステップＳ３の結果、１つのテストケース
が作成終了した場合には、ステップＳ１５へ進み、テス
トケースを作成する（ステップＳ１５）。なお、テスト
ケース格納部６に蓄えられている一連のイベント履歴
が、製品に与えるべきテストケースとなる。テストケー
スは、例えば図９のようなフォーマットのファイルとし
て出力することができる。他にも、試験信号を作成する
ためのシステムにデータを渡して、自動試験を実現する
こともできる。

【００６８】テストケース作成の完了を判定する（ステ
ップＳ１６）。完了の条件としては、すべての遷移の十
分性が１００％になった時、テストケース数が一定の値
を越えた時、等が考えられる。判定の結果、テストケー
ス作成が完了した場合には、処理を終了する。未完の場
合には、ステップＳ１７へ進み、次のテストケース作成
を行なうための、作業用のデータ領域の再初期化を行な
う（ステップＳ１７）。すなわち、状態遷移図探索部２
の現在の状態を初期状態に戻す、アクション／イベント
関係管理部５の発生／非発生イベントの記憶状態を初期
状態に戻す等を行う。また、遷移の十分性に関する情報
は、ここでは保存される。なお、再初期化後には、ステ
ップＳ３へ戻る。

【００６９】図１０は本発明の第２実施例に係るテスト
ケース作成装置の構成を示すブロック図である。図１０
において、図２と同じ部分には同じ符号を付す。第２実
施例のテストケース作成装置は、製品仕様記述部１と、
複数の状態遷移図探索部２と、階層関係管理部４と、ア
クション／イベント関係管理部５と、テストケース格納
部６とを具備する。

【００７０】製品仕様記述部１は、テストケース作成の
対象となる製品の動作仕様を形式的に記述する。この場
合において、製品仕様記述部１は、階層化の概念を有す
る状態遷移図として動作仕様（すなわち製品仕様）を記
述する。このように状態遷移図の記述に階層化の概念を
取り入れることにより、大規模化する仕様を容易に記述
できる。

【００７１】状態遷移図探索部２は、テストケース作成
のために状態遷移図を有向グラフとして探索する。具体
的には、状態遷移図探索部２は、状態遷移情報を製品仕
様記述部１から読み込み、状態遷移図における有向グラ
フの一連のパスとして製品の動作を特定しながらテスト
ケースを作成する。これらの状態遷移図探索部２は、実
行時には、一枚の状態遷移図に対し１つの状態遷移図探
索部２が割り当てられる。各状態遷移図探索部２は対応
するそれぞれの状態遷移図の現在の状態を常に管理して
おり、詳細は後述するアクション／イベント関係管理部
５から通知される発生／非発生イベントを参照しなが
ら、現在の状態からの遷移を１つずつ選択して、現在の
状態を次の状態に移すという方法で、探索を進める。状
態遷移図探索部２によって選択された遷移の情報は、そ
れを生起させるイベントという形でテストケース格納部
６に時々刻々伝達され、イベント列として格納される。

【００７２】階層関係管理部４は、動作仕様の階層化の
結果として上下関係を持ちながら並行に動作する複数の
状態遷移図を管理する。階層関係管理部４の第１の役割
は、階層化されている複数の状態遷移図の実行順序の管
理である。そして、階層関係管理部４の第２の役割は、
状態遷移図探索部２の遷移選択のための遷移網羅の十分
性の監視である。

【００７３】状態遷移図が階層化されることにより、単
純に１つの遷移は最低一回通過すればよいということで
は、製品の信頼性を確保するテストケースを作成するこ
とはできない。

【００７４】例えば図１において、現在の状態がそれぞ
れ、動作中（状態遷移図ＳＤ１）、冷房（状態遷移図Ｓ
Ｄ２）、クーラオン（状態遷移図ＳＤ４）の時に、状態
遷移図ＳＤ１にて動作停止のイベントが発生し、停止状
態への遷移が発生したとする。この状況を試験して、動
作が正常であった場合、従来の考え方でいうと、停止状
態への遷移は確認されたということになる。しかし、製
品の信頼性を確保するためには、これだけの試験では不
十分である。同じ停止状態への遷移にしても、動作中
（状態遷移図ＳＤ１）、暖房（状態遷移図ＳＤ２）、ヒ
ータオン（状態遷移図ＳＤ５）の時に停止要求があった
場合には、当然製品の振舞も異なるわけであり、試験を
省略することはできない。動作を停止しても、ヒータは
オンのままでつきっぱなしというような状況を見逃して
しまうかもしれないからである。

【００７５】上記のように、単純なケースにおいても、
階層を考慮しないと抜けのないテストケースを自動的に
作成することは困難である。アクション／イベント関係
管理部５は、アクションとイベントの関係を管理する。
このアクションとイベントとの関係は、通常は並行に動
作する状態遷移図間での通信に用いられ、アクション／
イベント関係管理部５は、あるアクションが実行される
と、その結果、あるイベントが発生する（又は発生しな
くなる）という関係を管理する。アクション／イベント
関係管理部５は、例えば、「フラグをセットしろ」とい
うアクションを実行することにより、「フラグをセット
状態」というイベントが発生するというような関係を管
理する。このように、アクション／イベント関係管理部
５が、発生／非発生イベント情報を状態遷移図探索部２
に提供することで、現実に起こらないような事象に対応
したテストケースを作成してしまうことを回避できる。

【００７６】テストケース格納部６は、状態遷移図探索
部２による作成中（又は作成済）のテストケースを保持
（格納）する。状態遷移図探索部２が時々刻々選択し、
通知してくる遷移（実際にはその遷移を生起させるイベ
ント情報）を受信して蓄積する。状態遷移図探索部２に
よる探索の終了時には、それらの遷移（イベント情報）
の時系列が、テストケース格納部６にテストケースとし
て格納されている。

【００７７】上記のように構成された第２実施例に係る
テストケース作成装置の動作を説明する。製品仕様記述
部１によって製品の動作仕様を形式的に記述する。製品
仕様の記述方式は、状態遷移図とする。この場合におい
て、本発明では、近年の複雑化・大規模化する仕様を記
述できるだけの記述力を持たせるために、通常の状態遷
移図に階層化の概念を取り入れている。このように、動
作仕様の記述に階層化の概念を用い、動作仕様を構造化
して考えることにより、動作仕様を容易に記述すること
が可能になる。

【００７８】各状態遷移図探索部２は、階層化された複
数の状態遷移図をそれぞれ格納する。次に、各状態遷移
図探索部２は、個々の状態遷移図に対し、有向グラフの
探索の手法等を用いることによって、テストケースを探
索する。すなわち、各状態遷移図探索部２は、状態遷移
図における有向グラフの一連のパスとして動作を特定し
ながらテストケースを探索する。複数の状態遷移図が階
層関係にあるために、同時に複数の状態遷移図が動作す
るような場合には、状態遷移図探索部２は、階層関係管
理部４によるそれぞれの状態遷移図に対する探索順序の
指示に従って探索を行ない、製品全体に対するテストケ
ースを作成する。

【００７９】状態遷移図探索部２が状態遷移図を探索し
ていく際の、ある遷移を選択するかしないかの判断は、
通常の網羅の考え方、つまり各遷移は最低１度通過すれ
ば良いという考え方では不十分であり、階層化の結果生
じる複数の状態の組合せを考慮する必要がある。階層関
係管理部４は、階層間での状態の組合せを考慮した上
で、状態遷移図探索部２からの問い合わせに応じて、各
遷移を選択するかどうかの十分性の情報を状態遷移図探
索部２に渡す。これにより、製品動作に対して抜けのな
いような状態遷移図の探索を実行する。

【００８０】状態遷移図探索部２が状態遷移図を探索し
ていく際に、単に有向グラフとしてのみの探索を行なう
ならば、どのような遷移も可能である。しかし、各遷移
にはイベントとアクションが付随しており、イベントは
遷移発生の条件を、アクションは遷移発生時の処理を意
味しているので、実際にはアクションとイベントの組合
わせにより、ある状態で発生するイベントと発生しない
イベントの区別がつく場合がある。

【００８１】そこで、アクション／イベント関係管理部
５は、アクションとイベントの関係を管理し、ある状態
で発生可能（又は不可能）なイベントを識別する。状態
遷移図探索部２は、探索中に遷移を選択する際に、アク
ション／イベント関係管理部５に問い合わせを行なっ
て、イベントの発生可能性を調べ、現実には有り得ない
動作に対応したテストケースを作成しない。

【００８２】状態遷移図探索部２で選択された各状態遷
移図に対応するそれぞれの遷移（より正確には遷移を発
生させるイベント）は、時間経過毎に一列に並べられ
る。これによって、その製品仕様全体に対するテストケ
ースを構成する。それぞれの状態遷移図探索部２は、選
択した遷移（イベント）をその都度、テストケース格納
部６に通知する。テストケース格納部６は通知された一
つ一つの遷移（イベント）を時系列順に管理し、全ての
探索が終了した段階で、１つのテストケースとして格納
する。

【００８３】以上のようにして、システム試験工程にお
いて、製品動作の信頼性を確保するのに十分かつ抜けの
ないテストケースを作成することが実現される。図１１
は、上記の動作を実現して、実際のテストケースを作成
する方法を示すフローチャートである。

【００８４】図示しない制御部がテストケースの作成作
業に伴う作業用のデータ領域を初期化する（ステップＳ
１）。この記憶領域は、テストケースの十分性を各遷移
毎に記憶する領域及びアクション／イベント関係部の発
生／非発生イベントの記憶領域等である。この場合に、
テストケースの十分性とは、状態遷移図に記述された動
作仕様における状態遷移を全て網羅しているかどうかを
いう。従って、テストケースの十分性が１００％とは、
テストケースが状態遷移図に記述された動作仕様におけ
る状態遷移を全て網羅していることをいう。

【００８５】状態遷移図探索部２が、製品仕様記述部１
によって記述された製品仕様を、読み込む（ステップＳ
２）。状態遷移図の情報は、第１実施例と同様に、図４
のように表形式で格納する。

【００８６】ステップＳ３から、探索処理（すなわちテ
ストケースの作成）に入る。ステップＳ３では、１つの
テストケースの終了の判断を行う。この場合に、１つの
テストケースの作成終了判定には、階層間の状態の組合
わせを考慮した上で、すべての遷移の十分性が１００％
になった時、現在の状態からの到達範囲内のすべての遷
移について十分性が１００％になった時、状態遷移図の
現在の状態からの遷移先がなくなった時又は（無限に長
い系列を作成するのを防ぐために）テストケースが一定
の長さを越えた時等といった条件を用いる。

【００８７】階層関係管理部４が探索する階層を決定す
る（ステップＳ４）。階層がひとつしか存在しない場合
には、その階層の状態遷移図を探索すれば良い。階層関
係にある複数枚の状態遷移図が存在する場合には、各階
層はそれぞれ、概念的には同時に実行されるが、実際は
一定の順序でそれぞれの階層の状態遷移図を探索してい
かなければならない。通常は、下位層から上位層に向か
うという順序で、それぞれの状態遷移図を探索する。こ
のような階層実行は、階層関係管理部４において図１２
のようなリンク関係を有するスタック構造のデータを保
持することによって実現できる。

【００８８】状態遷移図探索部２は、指定された状態遷
移図において探索を実行し、遷移を選択する（ステップ
Ｓ５）。遷移の選択は、図１３に示すようなフローチャ
ートによって実行される。

【００８９】現在の状態からの遷移のうち、アクション
／イベント関係管理部５が提示する発生するイベントの
みによって遷移できるものであるかを調べる（ステップ
Ｓ５１）。遷移できるものがある場合には（ステップＳ
５２）、その遷移を選択して（ステップＳ５８）、ステ
ップＳ６に進む。ない場合には、ステップＳ５３に進
む。アクション／イベント関係管理部５が提示する発生
しないイベントをチェックする（ステップＳ５３）。そ
して、発生しないイベントの条件の下でも遷移可能な遷
移を、つまり発生しないイベントのために遷移不可能に
ならない遷移を探し（ステップＳ５４）、遷移可能な遷
移がない場合（ステップＳ５５）、ステップＳ６に進
む。ステップＳ５５において、遷移可能な遷移がある場
合には、階層化の結果生じる状態の組合せを考慮した上
で、それらの遷移が今までに選択されたことがあるかを
チェックし（ステップＳ５６）、すべて選択済みの場合
にはステップＳ６に進む。ステップＳ５６において、選
択したことのないものがある場合には、それらの中から
１つの遷移を選ぶ（ステップＳ５７）。その選び方は、
例えば等確率で乱数によって決める等の方法が考えられ
る。ステップＳ５７で決められた遷移はステップＳ５８
にて選択され、ステップＳ６へ進む。

【００９０】ステップＳ５の探索実行の結果遷移が選択
されたかどうかを判定し（ステップＳ６）、遷移が選択
された場合にはステップＳ７に進み、ステップＳ５で選
択された遷移を実行する（ステップＳ７）。ステップＳ
５において、遷移が選択されなかった場合にはステップ
Ｓ１０へ進む。ステップＳ７において、遷移の実行は、
アクションの実行と状態の遷移とによって構成されてい
る。

【００９１】アクションの実行では、第１実施例でのア
クション実行と全く同様に、アクション／イベント関係
管理部５に、発生するイベントと、発生しないイベント
とを登録する。

【００９２】状態の遷移とは、選択された遷移に従っ
て、現在の状態を新しい状態に移す動作である。状態遷
移図探索部２は、現在の状態を新しい状態に移し、階層
関係管理部４に制御を渡す。階層関係管理部４は、その
遷移によって階層関係がどのように変わるかを判断す
る。そして、状態遷移の結果下位層の状態遷移図の実行
が終了する場合には、階層関係管理部４は、その状態遷
移図の状態遷移図探索部２に探索終了要求を行ない、階
層関係管理部４の管理下から当該状態遷移図探索部２を
外す。また、新たな階層が下に展開される場合には、階
層関係管理部４は、その状態遷移図の状態遷移図探索部
２に探索開始要求を行ない、階層関係管理部４の管理下
に当該状態遷移図探索部２を組み込む。

【００９３】テストケース格納部６に、テストケースを
構成するイベントが登録される（ステップＳ８）。この
場合に、状態遷移図探索部２は、ステップＳ５で選択さ
れた遷移を生起させるためのイベント情報を、テストケ
ース格納部６に通信する。テストケース格納部６は、通
信されたイベント情報を、探索の履歴として蓄え、探索
終了時には、蓄えられた探索の履歴が１つのテストケー
スを構成する。

【００９４】テストケース格納部６に、テストケースの
局所的な十分性の情報が登録される（ステップＳ９）。
十分性の管理方法としては、階層間の状態の組合せを考
慮するために、試験の網羅度合を記録する特殊なデータ
構造を利用する。このデータ構造を「十分性−木」と称
する。以下、「十分性−木」を簡単に説明する。

【００９５】「十分性−木」は、図１４に示すような状
態の階層関係を示す木構造図である。図１４は図１の仕
様に対する十分性−木を示す。「十分性−木」は、最上
位に１つの仮想的な状態を設定し、その下に階層を展開
していくことによって現れる状態の上下関係を木の形で
表現する。

【００９６】「十分性−木」におけるある遷移に対する
網羅の度合（すなわち十分性）は、その遷移の出ている
状態を「十分性−木」上でポイントし、それより下にあ
る部分木の葉（末端のノード）に至るすべてのパスのう
ち、どれだけのパスを網羅しているかによって測定す
る。葉に至るパスは、階層関係を考慮した状態の組合せ
に相当し、１つの遷移を探索する時に、製品がどのよう
な状態の組合わせになっているかが葉に至るパスによっ
て表現される。従って、ある部分木の葉に至るすべての
パスが、ある遷移について試験しなければならない製品
の状態のすべての組合わせに対応する。網羅した遷移に
対しては、この「十分性−木」のパスに対して網羅済み
の属性を与えていくことで、テストケースの抜けや重複
を防ぐ。例えば図１４においてａの状態からの遷移に関
しては、パスＰ１〜Ｐ５の５つの組合わせすべてに関す
る動作が確認できなければ、テストケースとして十分と
は言えない。同様に、ｂの状態からの遷移に関しては、
パスＰ２及びＰ３の組合わせが必要である。

【００９７】ステップＳ６の判定で、遷移が選択されて
いなかった場合には、ステップＳ１０の処理が行なわれ
る。ステップＳ１０では、探索のデッドロックの発生の
有無がチェックされる。デッドロックの内容は第１実施
例と同様である。階層関係にある状態遷移図の探索順序
は階層関係管理部４によって管理されているが、この探
索が各状態遷移図に対してひとまわり実行されても、ど
の状態遷移図探索部２においても遷移が選択されなかっ
た場合には、デッドロックが発生していると解釈する。

【００９８】ステップＳ１０においてデッドロックの発
生の有無で処理を振り分ける（ステップＳ１１）。ステ
ップＳ１１において、デッドロックが発生していない場
合には、ステップＳ３へ進む。デッドロックが発生して
いる場合には、ステップＳ１２へ進む。

【００９９】デッドロックを回避可能な遷移の探索を行
なう（ステップＳ１２）。この場合、すべての状態遷移
図探索部２の現在の状態からの遷移を対象にして、それ
らの中から１つの遷移を選択する。この時、アクション
／イベント関係管理部５を参照して、発生しないイベン
トをチェックし、その条件の下で遷移し得ない遷移は選
択できない。選択できる遷移の候補が複数存在する場合
には、それらの中から１つの遷移を選択する。選択の方
法としては、十分性−木を参照して階層間の状態組合せ
を考慮した上で、未選択の遷移が多く残っている状態遷
移図探索部２の遷移を優先させる、これまでの選択回数
の少ないものを選ぶ、条件が同じ場合には等確率で乱数
によって決める等が考えられる。

【０１００】ステップＳ１２の結果、デッドロック回避
可能な遷移が発見できたら（ステップＳ１３）、その遷
移を選択してテストケース作成を継続するために、ステ
ップＳ７へ進む。ステップＳ１２において、デッドロッ
ク回避可能な遷移が発見できなかった場合には（ステッ
プＳ１３）、製品仕様自体がデッドロックを引き起こす
誤った仕様である可能性があるので、ステップＳ１４へ
進み、製品仕様自体にエラーが発生していることを開発
者にメッセージとして提示した上で、テストケース作成
を終了する（ステップＳ１４）。

【０１０１】ステップＳ３の結果、１つのテストケース
が作成終了した場合には、ステップＳ１５へ進み、テス
トケースを作成する（ステップＳ１５）。なお、テスト
ケース格納部６に蓄えられている一連のイベント履歴
が、製品に与えるべきテストケースとなる。テストケー
スは、例えば図９のようなフォーマットのファイルとし
て出力することができる。他にも、試験信号を作成する
ためのシステムにデータを渡して、自動試験を実現する
こともできる。

【０１０２】テストケース作成の完了を判定する（ステ
ップＳ１６）。完了の条件としては、すべての遷移の十
分性が１００％になった時、テストケース数が一定の値
を越えた時、等が考えられる。判定の結果、テストケー
ス作成が完了した場合には、処理を終了する。未完の場
合には、ステップＳ１７へ進み、次のテストケース作成
を行なうための、作業用のデータ領域の再初期化を行な
う（ステップＳ１７）。すなわち、状態遷移図探索部２
の現在の状態を初期状態に戻す、アクション／イベント
関係管理部５の発生／非発生イベントの記憶状態を初期
状態に戻す等を行う。また、遷移の十分性に関する情報
は、ここでは保存される。なお、再初期化後には、ステ
ップＳ３へ戻る。

【０１０３】図１５は本発明の第３実施例に係るテスト
ケース作成装置の構成を示すブロック図である。第３実
施例のテストケース作成装置は製品仕様記述部１と、複
数の状態遷移図探索部２と、並行関係管理部３と、階層
関係管理部４と、アクション／イベント関係管理部５
と、テストケース格納部６とを具備する。

【０１０４】製品仕様記述部１は、テストケース作成の
対象となる製品の動作仕様を形式的に記述する。この場
合において、製品仕様記述部１は、並行化及び階層化の
概念を有する状態遷移図として動作仕様（すなわち製品
仕様）を記述する。このように状態遷移図の記述に並行
化及び階層化の概念を取り入れることにより、大規模化
する仕様を容易に記述できる。

【０１０５】状態遷移図探索部２は、テストケース作成
のために状態遷移図を有向グラフとして探索する。具体
的には、状態遷移図探索部２は、状態遷移情報を製品仕
様記述部１から読み込み、状態遷移図における有向グラ
フの一連のパスとして製品の動作を特定しながらテスト
ケースを作成する。これらの状態遷移図探索部２は、実
行時には、一枚の状態遷移図に対し１つの状態遷移図探
索部２が割り当てられる。各状態遷移図探索部２は対応
するそれぞれの状態遷移図の現在の状態を常に管理して
おり、詳細は後述するアクション／イベント関係管理部
５から通知される発生／非発生イベントを参照しなが
ら、現在の状態からの遷移を１つずつ選択して、現在の
状態を次の状態に移すという方法で、探索を進める。状
態遷移図探索部２によって選択された遷移の情報は、そ
れを生起させるイベントという形でテストケース格納部
６に時々刻々伝達され、イベント列として格納される。

【０１０６】並行関係管理部３は、並行に動作する複数
の状態遷移図の関係を管理する。具体的には、並行関係
管理部３は、複数の並行な状態遷移図の探索を実行する
順序を管理する。何故ならば、並行化された状態遷移図
は見かけ上は並行関係にあるが、実際には一連の順序で
探索されるからである。

【０１０７】階層関係管理部４は、動作仕様の階層化の
結果として上下関係を持ちながら並行に動作する複数の
状態遷移図を管理する。階層関係管理部４の第１の役割
は、階層化されている複数の状態遷移図の実行順序の管
理である。そして、階層関係管理部４の第２の役割は、
状態遷移図探索部２の遷移選択のための遷移網羅の十分
性の監視である。

【０１０８】アクション／イベント関係管理部５は、ア
クションとイベントの関係を管理する。このアクション
とイベントとの関係は、通常は並行に動作する状態遷移
図間での通信に用いられ、アクション／イベント関係管
理部５は、あるアクションが実行されると、その結果、
あるイベントが発生する（又は発生しなくなる）という
関係を管理する。アクション／イベント関係管理部５
は、例えば、「フラグをセットしろ」というアクション
を実行することにより、「フラグをセット状態」という
イベントが発生するというような関係を管理する。この
ように、アクション／イベント関係管理部５が、発生／
非発生イベント情報を状態遷移図探索部２に提供するこ
とで、現実に起こらないような事象に対応したテストケ
ースを作成してしまうことを回避できる。

【０１０９】テストケース格納部６は、状態遷移図探索
部２による作成中（又は作成済）のテストケースを保持
（格納）する。状態遷移図探索部２が時々刻々選択し、
通知してくる遷移（実際にはその遷移を生起させるイベ
ント情報）を受信して蓄積する。状態遷移図探索部２に
よる探索の終了時には、それらの遷移（イベント情報）
の時系列が、テストケース格納部６にテストケースとし
て格納されている。

【０１１０】上記のように構成された第３実施例に係る
テストケース作成装置の動作を説明する。製品仕様記述
部１によって製品の動作仕様を形式的に記述する。製品
仕様の記述方式は、状態遷移図とする。この場合におい
て、本発明では、近年の複雑化・大規模化する仕様を記
述できるだけの記述力を持たせるために、通常の状態遷
移図に並行化及び階層化の概念を取り入れている。この
ように、動作仕様の記述に並行化及び階層化の概念を用
い、動作仕様を構造化して考えることにより、動作仕様
を容易に記述することが可能になる。

【０１１１】各状態遷移図探索部２は、並行化された複
数の状態遷移図をそれぞれ格納する。次に、各状態遷移
図探索部２は、個々の状態遷移図に対し、有向グラフの
探索の手法等を用いることによって、テストケースを探
索する。すなわち、各状態遷移図探索部２は、状態遷移
図における有向グラフの一連のパスとして動作を特定し
ながらテストケースを探索する。複数の状態遷移図が並
行関係及び階層関係にあるために、同時に複数の状態遷
移図が動作するような場合には、状態遷移図探索部２
は、並行関係管理部３及び階層関係管理部４によるそれ
ぞれの状態遷移図に対する探索順序の指示に従って探索
を行ない、製品全体に対するテストケースを作成する。

【０１１２】状態遷移図探索部２が状態遷移図を探索し
ていく際の、ある遷移を選択するかしないかの判断は、
通常の網羅の考え方、つまり各遷移は最低１度通過すれ
ば良いという考え方では不十分であり、階層化の結果生
じる複数の状態の組合せを考慮する必要がある。階層関
係管理部４は、階層間での状態の組合せを考慮した上
で、状態遷移図探索部２からの問い合わせに応じて、各
遷移を選択するかどうかの十分性の情報を状態遷移図探
索部２に渡す。これにより、製品動作に対して抜けのな
いような状態遷移図の探索を実行する。

【０１１３】状態遷移図探索部２が状態遷移図を探索し
ていく際に、単に有向グラフとしてのみの探索を行なう
ならば、どのような遷移も可能である。しかし、各遷移
にはイベントとアクションが付随しており、イベントは
遷移発生の条件を、アクションは遷移発生時の処理を意
味しているので、実際にはアクションとイベントの組合
わせにより、ある状態で発生するイベントと発生しない
イベントの区別がつく場合がある。このような状況は、
特に並行に動作する複数の状態遷移図間で情報をやりと
りする場合に多く見られる。

【０１１４】そこで、アクション／イベント関係管理部
５は、アクションとイベントの関係を管理し、ある状態
で発生可能（又は不可能）なイベントを識別する。状態
遷移図探索部２は、探索中に遷移を選択する際に、アク
ション／イベント関係管理部５に問い合わせを行なっ
て、イベントの発生可能性を調べ、現実には有り得ない
動作に対応したテストケースを作成しない。

【０１１５】状態遷移図探索部２で選択された各状態遷
移図に対応するそれぞれの遷移（より正確には遷移を発
生させるイベント）は、時間経過毎に一列に並べられ
る。これによって、その製品仕様全体に対するテストケ
ースを構成する。それぞれの状態遷移図探索部２は、選
択した遷移（イベント）をその都度、テストケース格納
部６に通知する。テストケース格納部６は通知された一
つ一つの遷移（イベント）を時系列順に管理し、全ての
探索が終了した段階で、１つのテストケースとして格納
する。

【０１１６】以上のようにして、システム試験工程にお
いて、製品動作の信頼性を確保するのに十分かつ抜けの
ないテストケースを作成することが実現される。図１６
は、上記の動作を実現して、実際のテストケースを作成
する方法を示すフローチャートである。

【０１１７】図示しない制御部がテストケースの作成作
業に伴う作業用のデータ領域を初期化する（ステップＳ
１）。この記憶領域は、テストケースの十分性を各遷移
毎に記憶する領域及びアクション／イベント関係部の発
生／非発生イベントの記憶領域等である。この場合に、
テストケースの十分性とは、状態遷移図に記述された動
作仕様における状態遷移を全て網羅しているかどうかを
いう。従って、テストケースの十分性が１００％とは、
テストケースが状態遷移図に記述された動作仕様におけ
る状態遷移を全て網羅していることをいう。

【０１１８】状態遷移図探索部２が、製品仕様記述部１
によって記述された製品仕様を、読み込む（ステップＳ
２）。状態遷移図の情報は、第１実施例と同様に、図４
のように表形式で格納する。

【０１１９】ステップＳ３から、探索処理（すなわちテ
ストケースの作成）に入る。ステップＳ３では、１つの
テストケースの終了の判断を行う。この場合に、１つの
テストケースの作成終了判定には、すべての遷移の十分
性が１００％になった時、現在の状態からの到達範囲内
のすべての遷移について十分性が１００％になった時、
状態遷移図の現在の状態からの遷移先がなくなった時又
は（無限に長い系列を作成するのを防ぐために）テスト
ケースが一定の長さを越えた時等といった条件を用い
る。

【０１２０】探索される状態遷移図が決定される（ステ
ップＳ４）。 並行関係管理部３は、状態遷移図探索部
２が探索するプロセスを決定する。ここで、プロセスと
は、並行に実行され得る状態遷移図の単位を示す。１つ
のプロセスは１枚以上の状態遷移図又は１枚の状態遷移
図とそれから展開される下位層の複数枚の状態遷移図に
よって構成される。

【０１２１】例えば図１は、２つのプロセスから構成さ
れており、１つのプロセスは状態遷移図ＳＤ１、状態遷
移図ＳＤ２、状態遷移図ＳＤ４及び状態遷移図ＳＤ５か
ら、もう１つのプロセスは状態遷移図ＳＤ３の１枚から
なっている。

【０１２２】探索するプロセスの決定は、第１実施例と
同様の方法で行なうことができる。１つのプロセスが複
数の階層によって構成される場合には、全階層にわたっ
て探索が実施された後で、次のプロセスに移るように制
御される。

【０１２３】プロセスが決定された後は、指定されたプ
ロセスに対して、階層関係管理部４が探索する階層を決
定する。階層の決定方法は、第２実施例と同様である。
状態遷移図探索部２は、指定された状態遷移図において
探索を実行し、遷移を選択する（ステップＳ５）。遷移
探索の方法は、第２実施例と同様である。

【０１２４】ステップＳ５の探索実行の結果遷移が選択
されたかどうかを判定し（ステップＳ６）、遷移が選択
された場合にはステップＳ７に進み、ステップＳ５で選
択された遷移を実行する（ステップＳ７）。ステップＳ
５において、遷移が選択されなかった場合にはステップ
Ｓ１０へ進む。ステップＳ７において、遷移の実行は、
アクションの実行と状態の遷移とによって構成されてい
る。

【０１２５】アクションの実行では、第１実施例でのア
クション実行と全く同様に、アクション／イベント関係
管理部５に、発生するイベントと、発生しないイベント
とを登録する。

【０１２６】もうひとつの状態の遷移は、第２実施例と
同様である。テストケース格納部６に、テストケースを
構成するイベントが登録される（ステップＳ８）。この
場合に、状態遷移図探索部２は、ステップＳ５で選択さ
れた遷移を生起させるためのイベント情報を、テストケ
ース格納部６に通信する。テストケース格納部６は、通
信されたイベント情報を、探索の履歴として蓄え、探索
終了時には、蓄えられた探索の履歴が１つのテストケー
スを構成する。

【０１２７】テストケース格納部６に、テストケースの
局所的な十分性の情報が登録される（ステップＳ９）。
十分性の管理方法としては、階層間の状態の組合せを考
慮するために、第２実施例と同様に「十分性−木」を用
いる。網羅した遷移に対しては、この「十分性−木」の
根（木の最上位のノード）から葉へのパスに対して網羅
済みの属性を与えていくことで、テストケースの抜けや
重複を防ぐ。

【０１２８】ステップＳ６の判定で、遷移が選択されて
いなかった場合には、ステップＳ１０の処理が行われ
る。ステップＳ１０では、探索のデッドロックの発生の
有無がチェックされる。デッドロックの内容は第１実施
例と同様である。階層関係にある状態遷移図の探索順序
は並行関係管理部３と階層関係管理部４とによって管理
されているが、この探索が各状態遷移図に対してひとま
わり実行されても、どの状態遷移図探索部２においても
遷移が選択されなかった場合、デッドロックが発生して
いると解釈する。

【０１２９】ステップＳ１０においてデッドロックの発
生の有無で処理を振り分ける（ステップＳ１１）。ステ
ップＳ１１において、デッドロックが発生していない場
合には、ステップＳ３へ進む。デッドロックが発生して
いる場合には、ステップＳ１２へ進む。

【０１３０】デッドロックを回避可能な遷移の探索を行
なう（ステップＳ１２）。この場合、すべての状態遷移
図探索部２の現在の状態からの遷移を対象にして、それ
らの中から１つの遷移を選択する。この時、アクション
／イベント関係管理部５を参照して、発生しないイベン
トをチェックし、その条件の下で遷移し得ない遷移は選
択できない。選択できる遷移の候補が複数存在する場合
には、それらの中から１つの遷移を選択する。選択の方
法としては、十分性−木を参照して階層間の状態組合せ
を考慮した上で、未選択の遷移が多く残っている状態遷
移図探索部２の遷移を優先させる、これまでの選択回数
の少ないものを選ぶ、条件が同じ場合には等確率で乱数
によって決める等が考えられる。

【０１３１】ステップＳ１２の結果、デッドロック回避
可能な遷移が発見できたら（ステップＳ１３）、その遷
移を選択してテストケース作成を継続するために、ステ
ップＳ７へ進む。ステップＳ１２において、デッドロッ
ク回避可能な遷移が発見できなかった場合には（ステッ
プＳ１３）、製品仕様自体がデッドロックを引き起こす
誤った仕様である可能性があるので、ステップＳ１４へ
進み、製品仕様自体にエラーが発生していることを開発
者にメッセージとして提示した上で、テストケース作成
を終了する（ステップＳ１４）。

【０１３２】ステップＳ３の結果、１つのテストケース
が作成終了した場合には、ステップＳ１５へ進み、テス
トケースを作成する（ステップＳ１５）。なお、テスト
ケース格納部６に蓄えられている一連のイベント履歴
が、製品に与えるべきテストケースとなる。テストケー
スは、例えば図９のようなフォーマットのファイルとし
て出力することができる。他にも、試験信号を作成する
ためのシステムにデータを渡して、自動試験を実現する
こともできる。

【０１３３】テストケース作成の完了を判定する（ステ
ップＳ１６）。完了の条件としては、すべての遷移の十
分性が１００％になった時、テストケース数が一定の値
を越えた時、等が考えられる。判定の結果、テストケー
ス作成が完了した場合には、処理を終了する。未完の場
合には、ステップＳ１７へ進み、次のテストケース作成
を行なうための、作業用のデータ領域の再初期化を行な
う（ステップＳ１７）。すなわち、状態遷移図探索部２
の現在の状態を初期状態に戻す、アクション／イベント
関係管理部５の発生／非発生イベントの記憶状態を初期
状態に戻す等を行う。また、遷移の十分性に関する情報
は、ここでは保存される。なお、再初期化後には、ステ
ップＳ３へ戻る。

【０１３４】図１に示した階層化及び並行化された状態
遷移図の１部を用いて、本発明によるテストケース作成
の例を示す。図１７に、階層化及び並行化された状態遷
移図を示す。

【０１３５】第３実施例のフローチャートに従って、テ
ストケース作成を行う。初期化（ステップＳ１）におい
て、アクション／イベント関係管理部５は、イベントと
アクションの関係定義を読み込む。この例では、アクシ
ョン：ヒータＯＮの実行によってイベント：ヒータ＝Ｏ
Ｎが発生し、イベント：ヒータ＝ＯＦＦは発生しなくな
り、アクションヒータＯＦＦによってイベント：ヒータ
＝ＯＦＦが発生し、イベント：ヒータ＝ＯＮが発生しな
い。初期状態として、ヒータ＝ＯＦＦ発生し、ヒータ＝
ＯＮ発生しない。階層関係管理部４は、「十分性−木」
を作成した上で、状態の組合せに対応する各パスの属性
を初期化する。この場合、階層関係にあるのは状態遷移
図ＳＤ１と状態遷移図ＳＤ２であり、図１８のような十
分性−木が作成される。図１８において、枝が点線で示
されているのは、まだテストケースによって遷移が網羅
されていないことを示す。

【０１３６】状態遷移図探索部２が、状態遷移図の仕様
記述を読み込む（ステップＳ２）。本例では、３つの状
態遷移図が存在するので、状態遷移図探索部２が３つ割
り当てられる。状態遷移図探索部２として、状態遷移図
ＳＤ１用、状態遷移図ＳＤ２用、状態遷移図ＳＤ３用の
３つが用意される。

【０１３７】状態遷移図探索部２で探索する状態遷移図
が指定される（ステップＳ４）。探索の順序は階層関係
と並行関係を考慮して、本例においては、状態遷移図Ｓ
Ｄ２→状態遷移図ＳＤ１→状態遷移図ＳＤ３→状態遷移
図ＳＤ２→…の順とする。ただし、この時点でアクティ
ブでない状態遷移図については、探索は行なわないで次
の状態遷移図へ進む。従って、探索開始時には状態遷移
図ＳＤ２はまだアクティブではないので、状態遷移図Ｓ
Ｄ１の探索を行なう。

【０１３８】発生するイベントはヒータ＝ＯＦＦのみで
あり（ステップＳ５）、遷移は選択されない（ステップ
Ｓ５２）。そこで、遷移１が未チェックなため遷移１が
選択される。

【０１３９】ステップＳ５８で遷移１が選択されたた
め、ステップＳ７へ進む（ステップＳ６）。状態遷移の
実行では、アクションの初期化処理によりヒータ＝ＯＦ
Ｆが発生し、ヒータ＝ＯＮが発生しなくなる（ステップ
Ｓ７）。この情報がアクション／イベント関係管理部５
において管理される。更に状態の遷移では、現在の状態
を「動作中」状態に移す。更に、下位層の状態遷移図Ｓ
Ｄ２がアクティブとし、状態遷移図ＳＤ２の現在の状態
を初期状態である「暖房待機」にする。

【０１４０】遷移１のイベントである起動をテストケー
ス格納部６に通知し、登録する（ステップＳ８）。遷移
１に関し、「十分性−木」の根から停止へのパスに対応
した組合せについて、選択済みの属性を記録する（ステ
ップＳ９）。

【０１４１】ステップＳ５における状態遷移図ＳＤ３の
探索では、遷移５のヒータ＝ＯＮは発生不可能であり、
この遷移は指定されず、ステップＳ１０へ進む。状態遷
移図ＳＤ１では直前に遷移１が選択されていたので、探
索デッドロックは発生しておらず、ステップＳ３へ進む
（ステップＳ１０、ステップＳ１１）。

【０１４２】更に、次の探索に状態遷移図ＳＤ２が指定
され（ステップＳ４）、遷移３が選択される（ステップ
Ｓ５）。この結果、状態遷移図ＳＤ２の状態は暖房中に
遷移する。イベントは、ヒータ＝ＯＮが発生し、ヒータ
＝ＯＦＦが発生しなくなる。

【０１４３】続いて、状態遷移図ＳＤ１が探索され、遷
移２が選択される。この時、十分性−木は図１９のよう
になる。ここまでの動作で、遷移１、遷移３、遷移２が
選択され、テストケースとしては、起動→暖房開始温度
→停止、までが生成された。

【０１４４】以上のような処理を継続することで、テス
トケースを作成することができる。本発明は、上記実施
例に限定されない。上記実施例では、テストケース作成
装置単体のみを説明したが、他の装置と適宜組み合わせ
て使用することもできる。

【０１４５】例えば、システム試験レベルでの信頼性確
保のために、手作業操作による試験作業を機械化する試
験装置が知られている。これは、各入力信号を、一定サ
ンプリング周期での信号値の並びとして与えると、自動
的にその入力値を試験対象製品に与え、入出力をモニタ
して、予め状態遷移図で与えられた仕様とその入出力の
履歴を比較して、製品が仕様通りに動いているかという
観点から、試験の合否を自動的に判定する装置である。
この試験装置により、手作業に伴う試験の不正確さや工
数の問題は解消される。本発明のテストケース作成装置
を上記の試験装置に適用することにより、テストケース
の作成から動作試験までの一連の作業を自動的に行うこ
とができる。

【０１４６】また、テストケース格納部６は、テストケ
ース作成装置の一部でなく、外部の記憶装置として有し
ていても良い。この場合は、探索結果が出力端子から順
次出力される。

【０１４７】更に、テストケースを作成するために、そ
の並行化又は階層化された状態遷移図を作成する製品仕
様記述部１と、状態遷移図探索部２と、アクション／イ
ベント関係管理部５とを有する構成としても良い。この
場合には、第１〜第３実施例における並行関係管理部３
と階層関係管理部４とが省略されているが、実行順序の
管理を行う必要がない場合又は並行実行可能な計算機を
使用する場合には、特に、必要としない。

【０１４８】また、第１〜第３実施例において、状態遷
移図探索部２が、状態遷移図の数に応じて作成される例
を示したが、これに限らず、１つの状態遷移図探索部２
が、複数の状態遷移図を探索するようにしても良い。

【０１４９】その他、本発明の要旨を変更しない範囲で
種々変形して実施できることは勿論である。本発明は、
上記実施例に限定されるものではなく、本発明の要旨を
変更しない範囲で種々変形して実施できるのは勿論であ
る。

【０１５０】

【発明の効果】本発明によれば次のような効果が得られ
る。本発明では、動作仕様記述手段が並行化及び階層化
の少なくとも一方の概念を取り入れて製品の動作仕様を
記述するので、大規模かつ複雑な動作仕様の記述が極め
て容易になる。

【０１５１】動作仕様記述手段によって記述された対象
物の動作仕様は、各状態遷移図毎に状態遷移図探索手段
によって探索処理される。状態遷移図探索手段は、例え
ば状態をノード、遷移をその遷移の向きに方向付けられ
たアークとする有向グラフとみなし、アークの向きにノ
ードをたどりながら状態遷移図を探索し、状態遷移図に
おける有向グラフの一連のパスとして動作を特定してい
く。

【０１５２】並行関係管理部は並行に動作する状態遷移
図の探索実行順序を管理される。階層関係管理手段は階
層化された状態遷移図の探索実行順序を管理すると共
に、階層を考慮した上での遷移網羅の十分性を判定し、
探索を行なうかどうかを管理する。アクション／イベン
ト関係管理手段は、アクションとイベントの関係を保持
して現実に発生しないような事象に対応する探索を回避
する。

【０１５３】上記の構成により、対象物の動作検証とし
て信頼性を確保することができ、しかも抜けのない製品
動作を網羅できるテストケースを作成することが可能に
なる。

【０１５４】上記のように、本発明を用いることによっ
て、製品のシステム試験用に、抜けのないテストケース
を、容易に作成することができる。また、本発明によっ
て作成されたテストケースを用いることより、製品プロ
グラムを網羅した試験を行なうことができ、製品の信頼
性を十分に確保することが実現される。

【図面の簡単な説明】

【図１】 本発明のテストケース作成装置でテストケー
ス作成の対象となる並行化及び階層化された状態遷移図
の一例を示す図。

【図２】 本発明の第１実施例に係るテストケース作成
装置の概略構成を示すブロック図。

【図３】 図２に示す第１実施例装置の動作を説明する
フローチャート。

【図４】 図２における状態遷移図探索部のデータ格納
方法を説明する図。

【図５】 図２における並行動作管理部の並行実行管理
方式を説明する図。

【図６】 図３における探索の実行の処理を説明するフ
ローチャート。

【図７】 図２におけるアクション／イベント関係管理
部５のアクション／イベント関係管理方式を説明する
図。

【図８】 図２における状態遷移図探索部の探索実行方
式を説明する図。

【図９】 図２に示す装置の出力例の図。

【図１０】 本発明の第２実施例に係るテストケース作
成装置の概略構成を示すブロック図。

【図１１】 第２実施例に係るテストケース作成装置の
動作を説明するフローチャート。

【図１２】 図１０における階層関係管理部の階層実行
管理方式を説明する図。

【図１３】 図１１における探索の実行の処理を説明す
るフローチャート。

【図１４】 図１０におけるテストケース作成装置が試
験の十分性を判定するための、十分性−木を説明する
図。

【図１５】 本発明の第３実施例に係るテストケース作
成装置の概略構成を示すブロック図。

【図１６】 図１５に示す第３実施例に係るテストケー
ス作成装置の動作を説明するフローチャート。

【図１７】 テストケース生成例に用いた状態遷移図仕
様。

【図１８】 テストケース生成例における試験開始時の
十分性−木。

【図１９】 テストケース生成例における途中段階の十
分性−木。

【符号の説明】

１…製品仕様記述部、２…状態遷移図探索部、３…並行
関係管理部 ４…階層関係管理部、５…アクション／イベント関係管
理部、６…テストケース格納部。

フロントページの続き (56)参考文献 特開 平２−127849（ＪＰ，Ａ) 特開 平６−149561（ＪＰ，Ａ) 特開 昭60−77248（ＪＰ，Ａ) 特開 昭63−181041（ＪＰ，Ａ) 特開 昭62−262144（ＪＰ，Ａ) 特開 昭63−228229（ＪＰ，Ａ) 特開 平４−137036（ＪＰ，Ａ) 特開 平６−103051（ＪＰ，Ａ) 特開 平６−103050（ＪＰ，Ａ) 岡安二郎、他３名，状態遷移仕様から のテストデータ生成方式，情報処理学会 全国大会講演論文集，日本，情報処理学 会，1991年 ２月25日，Ｖｏｌ．42，Ｎ ｏ．５，ｐ．５．218−５．219 岸美保子、他３名，状態遷移モデルに 基づくプログラム部品合成システムの開 発，情報処理学会研究報告，日本，情報 処理学会，1991年 ７月19日，Ｖｏｌ. 91，Ｎｏ．66（ＳＥ−80），ｐ．167− 174 (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 11/22 - 11/26 G06F 11/28 - 11/34 G06F 9/06

Claims (9)

(57)【特許請求の範囲】
1. 【請求項１】 対象物の動作検証を行うためのテストケ
   ースを作成するテストケース作成装置において、 前記対象物の動作仕様を並行化された少なくとも第１と
   第２の部分状態遷移図を含む複数の部分状態遷移図であ
   って、第１の状態と第２の状態を含む複数の状態間の遷
   移が記述された部分状態遷移図を含む全体状態遷移図を
   用いて記述する動作仕様記述手段と、 アクションとイベントの関係情報としての前記第１と第
   ２の部分状態遷移図間の関係を管理するアクション／イ
   ベント関係管理手段と、 前記アクション／イベント関係管理手段で管理された関
   係情報に基づいて所定の１つの部分状態遷移図を探索し
   て、前記所定の１つの部分状態遷移図における前記第１
   の状態から前記第２の状態の遷移を選択する状態遷移図
   探索手段と、 前記状態遷移図探索手段によって選択された前記遷移に
   係る情報を、当該遷移を生起させるためのテストに係る
   イベントとして格納する手段と、 を具備することを特徴とするテストケース作成装置。
2. 【請求項２】 前記動作仕様記述手段で記述された並行
   化された前記複数の状態遷移図の探索順序を管理して、
   前記状態遷移図探索手段での遷移選択の操作を制御する
   並行関係管理手段を更に具備することを特徴とする請求
   項１記載のテストケース作成装置。
3. 【請求項３】 対象物の動作検証を行うためのテストケ
   ースを作成するテストケース作成装置において、 前記対象物の動作仕様を階層化された少なくとも第１と
   第２の部分状態遷移図を含む複数の部分状態遷移図であ
   って、第１の状態と第２の状態を含む複数の状態間の遷
   移が記述された部分状態遷移図を含む全体状態遷移図を
   用いて記述する動作仕様記述手段と、 アクションとイベントの関係情報としての前記第１と第
   ２の部分状態遷移図間の関係を管理するアクション／イ
   ベント関係管理手段と、 前記アクション／イベント関係管理手段で管理された関
   係情報に基づいて所定の１つの部分状態遷移図を探索し
   て、前記所定の１つの部分状態遷移図における前記第１
   の状態から前記第２の状態の遷移を選択する状態遷移図
   探索手段と、 前記状態遷移図探索手段によって選択された前記遷移に
   係る情報を、当該遷移を生起させるためのテストに係る
   イベントとして格納する手段と、 を具備することを特徴とするテストケース作成装置。
4. 【請求項４】 前記動作仕様記述手段で記述された階層
   化された前記複数の状態遷移図の探索順序及び遷移網羅
   の十分性を管理して、前記状態遷移図探索手段での遷移
   選択の操作を制御する階層関係管理手段を更に具備する
   ことを特徴とする請求項３記載のテストケース作成装
   置。
5. 【請求項５】 前記動作仕様記述手段は、動作仕様を並
   行化された複数の状態遷移図を用いて記述する手段を更
   に含むことを特徴とする請求項３記載のテストケース作
   成装置。
6. 【請求項６】 前記動作仕様記述手段で記述された階層
   化された前記複数の状態遷移図の探索順序及び遷移網羅
   の十分性を管理して、前記状態遷移図探索手段での遷移
   選択の操作を制御する階層関係管理手段と、 前記動作仕様記述手段で記述された並行化された前記複
   数の状態遷移図の探索順序を管理して、前記状態遷移図
   探索手段での遷移選択の操作を制御する並行関係管理手
   段と、 を更に具備することを特徴とする請求項５記載のテスト
   ケース作成装置。
7. 【請求項７】 前記イベントとして格納する手段は、前
   記前記状態遷移図探索手段で選択されたイベントを時系
   列順に管理する手段を含むことを特徴とする請求項１又
   は請求項３記載のテストケース作成装置。
8. 【請求項８】 前記状態遷移図探索手段は、階層化の結
   果生じる複数の状態における階層間の状態の組合せの十
   分性を考慮して、選択可能な遷移が未選択の遷移かどう
   かを判定する手段を含むことを特徴とする請求項３又は
   請求項５記載のテストケース作成装置。
9. 【請求項９】 前記状態遷移図探索手段は、前記アクシ
   ョン／イベント関係管理手段を参照して、発生するイベ
   ントが遷移できるものかどうかをチェックする手段を含
   むことを特徴とする請求項１又は請求項３記載のテスト
   ケース作成装置。