JP5176869B2 - テストケース生成プログラムとテストケース生成装置およびテストケース生成方法 - Google Patents
テストケース生成プログラムとテストケース生成装置およびテストケース生成方法 Download PDFInfo
- Publication number
- JP5176869B2 JP5176869B2 JP2008275432A JP2008275432A JP5176869B2 JP 5176869 B2 JP5176869 B2 JP 5176869B2 JP 2008275432 A JP2008275432 A JP 2008275432A JP 2008275432 A JP2008275432 A JP 2008275432A JP 5176869 B2 JP5176869 B2 JP 5176869B2
- Authority
- JP
- Japan
- Prior art keywords
- state
- path
- test case
- test
- extracted
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Landscapes
- Debugging And Monitoring (AREA)
Description
本発明は、外部モジュールとの接続をテストする実機(接続)テストにおいて、モデル検査技術による網羅的な実行結果を用いてテストケース(テストシナリオと予想されるテスト結果)を生成する技術に関する。
従来、プログラムを対象とするモデル検査は、テスト対象システムの振舞いを設計書・仕様書からプロパティとして取り出し、テスト対象システムの実装プログラムにテストデータを入力することで実施するテストである。そして、プログラムの実行に基づき、状態遷移の各状態が取りうる全ての組み合わせを抽出し、これらの組み合わせに対して上記プロパティを満たすかどうかを検査するものである。
一般にプログラムモデル検査に基づくテストでは、データベースやネットワーク通信などの外部モジュールを直接利用できたいため、外部モジュールをスタブ化して、スタブを使用したテスト（第１のテスト）を実施し、次にスタブを実機に置き換えて再度テスト（第２のテスト）を行う。つまり、プログラムモデル検査では、データベースやネットワーク通信などの外部モジュールをスタブ化して行うため、モデル検査対象外となる外部モジュール接続部分を試験する実機テストが別途必要となる。
ところが、モデル検査では、基本的には各オブジェクトが取りうる全ての状態の組み合わせを網羅的に検査するものであるため、第１のテストにおいても第２のテストにおいても、全ての組み合わせに対する検査を行うこととなる。
図１４を用いて第１のテストと第２のテストを説明する。図１４はモデル検査とテスト技術について示した図である。図１４のＡはモデル検査（第１のテスト：網羅的な検査）を実施するときに用いる構成例を示す図である。クライアントの代わりにドライバ１４１から検査対象プログラム１４２に対してユーザ操作を模倣したデータが入力される。図１４のＡでは検査対象プログラム１４２と検査対象プログラム１４２に接続されているデータベーススタブ１４３とネットワークスタブ１４４に対して網羅的な検査が行われる。なお、第１のテストはプログラムの重要な部分にのみ適用可能である（部分的もしくは抽象化したものに対して有効）。
図１４のＢは実環境に則した検査（第２のテスト）を実施するときに用いる構成例を示す図である。クライアント１４５から検査対象プログラム１４２に対して実環境を確実に再現したテストケース（テストケース１、２）が入力される。図１４のＢでは検査対象プログラム１４２と検査対象プログラム１４２に接続されているデータベース１４６とネットワーク１４７に対して検査が行われる。
また、特許文献１によれば、対象プログラム(もしくは仕様)の網羅的な実行結果から外部モジュールを呼び出す全てのパスを列挙することで外部モジュールの接続テストのためのテストケースを漏れなく生成する提案がされている。
しかしながら、本来第２のテストでは第１のテストで実施したテストのうち、スタブが関係するテストのみを実施すれば十分である。図１４のＣに示す第２のテストにおいて、検査対象プログラム１４２（コア部分）のみのテスト（テストケース３）は不要である。
また、特許文献１においてもプログラムの網羅的な実行空間をそのまま利用しているため、漏れはないが実機テスト（第２のテスト）として外部モジュールを呼びだすため、同じようなテストケースを複数列挙してしまう。つまり、テスト内容が同じようなテストケースをひとつのテストケースとして判断することができないため、同じようなテストを複数回行ってしまい、テスト効率が悪くなってしまうという問題がある。また、特許文献２、３のような提案がされている。
特開２００７−１２８１３８号公報
特開平１１−３０６０４６号公報
特開平２−２８７７３７号公報
上記のような実情に鑑みてなされたものであり、モデル検査を網羅的に実行した結果を用いて、実機テストケース(テストシナリオと予想されるテスト結果)を生成することによりテスト効率を向上させるテストケース生成装置とテストケース生成方法およびテストケース生成プログラムを提供することを目的とする。
態様のひとつである、プログラムをモデル検査するためにテストケースを生成するテストケース生成は、状態特定処理、パス抽出処理、プロパティ適用処理、シナリオ分類処理、テストケース生成処理により実行する。状態特定処理は、前記モデル検査により出力された状態と前記状態の遷移により表される状態空間が記録されたメモリを参照して、外部モジュールを呼び出す状態を特定する。パス抽出処理は、前記状態特定処理が特定した前記外部モジュールを呼び出す状態から初期状態へのパスを、前記メモリに記録した前記状態の遷移を参照して抽出する。プロパティ適用処理は、前記パス抽出処理によって抽出したパスに対して、前記メモリに記録されている前記プログラムの仕様に基づいて「Ａ（条件）ならばＢ（帰結）である」の形式で作成されたプロパティの前記条件を比較して、前記条件を満たす前記抽出したパスを検出する。シナリオ分類処理は、前記条件ごとに前記抽出したパスを分類する。テストケース生成処理は、前記シナリオ分類処理により分類された前記抽出したパスと、前記抽出したパスに対応する前記プロパティの前記帰結を期待される結果を、テストケースとして生成する。
上記のように、網羅的に行なうモデル検査の状態空間から生成された状態と状態遷移がプログラムの仕様を示すプロパティ群により分類されるため、網羅的でかつ重複のない効率的なテストケースが生成可能となる。また、期待されるテスト結果においても、プロパティから生成するため、テスト設計者による間違いが入らない。このことにより、実機テストにおいて、テスト設計者に依存しない、漏れのなく正確なテストケース(シナリオ+期待される結果)が作成可能となる。
モデル検査を網羅的に実行した結果を用いて、実機テストケース(テストシナリオと予想されるテスト結果)を生成することによりテスト効率を向上させることができる。
以下図面に基づいて、本発明の実施形態について詳細を説明する。
（実施例１）
図１は、モデル検査を行うときに用いるモデル検査装置１、テストケース生成装置２、入出力装置３（ＰＣなど）を示す構成図である。なお、外部モジュールとの接続をテストする実機(接続)テストにおいて、モデル検査とは、テスト対象システムの振舞いを設計書・仕様書から取り出し、モデル検査の専用言語で記述したソフトウェア（擬似システム）を作成し、当該擬似システムにテストデータを入力することで実施するテストのことである。ここで、モデル検査の擬似システムは「Ａ（条件）ならばＢ（帰結）」というプロパティの組み合わせの状態空間で構成されている。また、設計書・仕様書に基づき、状態遷移の各状態が取りうる全ての組み合わせを抽出し、これらの組み合わせに対してテストデータを入力する。
（実施例１）
図１は、モデル検査を行うときに用いるモデル検査装置１、テストケース生成装置２、入出力装置３（ＰＣなど）を示す構成図である。なお、外部モジュールとの接続をテストする実機(接続)テストにおいて、モデル検査とは、テスト対象システムの振舞いを設計書・仕様書から取り出し、モデル検査の専用言語で記述したソフトウェア（擬似システム）を作成し、当該擬似システムにテストデータを入力することで実施するテストのことである。ここで、モデル検査の擬似システムは「Ａ（条件）ならばＢ（帰結）」というプロパティの組み合わせの状態空間で構成されている。また、設計書・仕様書に基づき、状態遷移の各状態が取りうる全ての組み合わせを抽出し、これらの組み合わせに対してテストデータを入力する。
モデル検査装置１は、入出力装置３からプログラム、プロパティを取得してモデル検査を行い、そのモデル検査の結果（状態空間、プロパティ）を出力する。
テストケース生成装置２は、状態空間とプロパティに基づいてパス抽出をし（パス抽出４）、抽出したパスから関連するパスをプロパティに基づいて分類し（パス分類５）、テスト結果を導出する（テスト結果導出６）。そのテスト結果（テストケース：シナリオと期待される結果）を入出力装置３に転送する。テストケース生成装置２はＣＰＵやメモリなどにより構成される。
テストケース生成装置２は、状態空間とプロパティに基づいてパス抽出をし（パス抽出４）、抽出したパスから関連するパスをプロパティに基づいて分類し（パス分類５）、テスト結果を導出する（テスト結果導出６）。そのテスト結果（テストケース：シナリオと期待される結果）を入出力装置３に転送する。テストケース生成装置２はＣＰＵやメモリなどにより構成される。
パス抽出４では、当該状態空間のうち、初期状態からスタブに関連する実行状態への実行パスを全て抽出する。
パス分類５では、抽出された実行パスの各実行状態におけるプロパティによって各実行パスをグルーピングする。パス分類５では、プロパティ(プログラムが満たすべき性質)を用いて同様の意味合いのテストケースを分類する。プロパティは「Ａ（条件）ならばＢ（帰結）」の形をしており、あるテストケースがどのプロパティの条件部にマッチするかにより分類する。プロパティが同一である実行パスは、同一の仕様をたどる実行パスであるため、テストとしては重複するものである。そのため、ひとつのグループに属する実行パスをひとつだけ残して他を削除する。
パス分類５では、抽出された実行パスの各実行状態におけるプロパティによって各実行パスをグルーピングする。パス分類５では、プロパティ(プログラムが満たすべき性質)を用いて同様の意味合いのテストケースを分類する。プロパティは「Ａ（条件）ならばＢ（帰結）」の形をしており、あるテストケースがどのプロパティの条件部にマッチするかにより分類する。プロパティが同一である実行パスは、同一の仕様をたどる実行パスであるため、テストとしては重複するものである。そのため、ひとつのグループに属する実行パスをひとつだけ残して他を削除する。
テスト結果導出６では、関係付くプロパティから期待される結果を抽出し、テストケースを生成する。上記のようにすることで、外部モジュール呼び出しのパターンとして、網羅的でかつ重複のないテストケースの生成ができる。
テストケース生成装置２について説明する。
図２はテストケース生成装置２の構成を示す図である。テストケース生成装置２は、パス抽出器７、パス分類器８、テストシナリオ生成器９、プロパティ格納部１０、状態空間格納部１１、パス格納部１２、シナリオ格納部１３を備えている。なお、パス抽出器７、パス分類器８、テストシナリオ生成器９はＣＰＵやプログラマブルデバイスを用いて実現することが可能である。
図２はテストケース生成装置２の構成を示す図である。テストケース生成装置２は、パス抽出器７、パス分類器８、テストシナリオ生成器９、プロパティ格納部１０、状態空間格納部１１、パス格納部１２、シナリオ格納部１３を備えている。なお、パス抽出器７、パス分類器８、テストシナリオ生成器９はＣＰＵやプログラマブルデバイスを用いて実現することが可能である。
パス抽出器７は、状態特定部１４とパス抽出部１５を備え、モデル検査による網羅的な実行空間からスタブを利用する状態を特定し、初期状態から特定した状態への実行パスを全て列挙する。状態特定部１４はスタブを利用している状態を特定する。パス抽出部１５は初期状態から特定したパスを抽出する。
パス分類器８は、プロパティ適用部１６とシナリオ分類部１７を備え、抽出したパスをモデル検査時に利用されたプロパティにより分類する。パスで特定される状態が前提条件にマッチするプロパティを列挙し、その列挙されたプロパティによりパスをグルーピングする。このグループからひとつのパスを、グループを代表するパスとして抽出する。プロパティ適用部１６は抽出したパスに対して、条件にマッチするプロパティを抽出する。シナリオ分類部１７は、パスを対応付けられたプロパティにより分類する。さらに、各分類からひとつのパスを抽出する。
テストシナリオ生成器９は、対応するプロパティの帰結部分より期待されるテスト結果を導出し、導出した結果に基づいてテストケースを生成する。
プロパティ格納部１０、状態空間格納部１１、パス格納部１２、シナリオ格納部１３はメモリである。プロパティ格納部１０は、パス抽出器７、パス分類器８、テストシナリオ生成器９と接続されている。状態空間格納部１１は、パス抽出器７と接続されている。パス格納部１２は、パス抽出器７、パス分類器８と接続されている。シナリオ格納部１３は、パス分類器８と接続されている。
プロパティ格納部１０、状態空間格納部１１、パス格納部１２、シナリオ格納部１３はメモリである。プロパティ格納部１０は、パス抽出器７、パス分類器８、テストシナリオ生成器９と接続されている。状態空間格納部１１は、パス抽出器７と接続されている。パス格納部１２は、パス抽出器７、パス分類器８と接続されている。シナリオ格納部１３は、パス分類器８と接続されている。
テストケース生成装置２の動作について説明する。
テストケース生成装置２は、モデル検査装置１の出力である状態空間（状態と、状態の遷移により表される）とプロパティを表すデータをプロパティ格納部１０、状態空間格納部１１に記録する。状態空間格納部１１には状態空間を表すデータを状態テーブルとイベントテーブルに記録する。またプロパティを表すデータプロパティ格納部１０に記録する。
テストケース生成装置２は、モデル検査装置１の出力である状態空間（状態と、状態の遷移により表される）とプロパティを表すデータをプロパティ格納部１０、状態空間格納部１１に記録する。状態空間格納部１１には状態空間を表すデータを状態テーブルとイベントテーブルに記録する。またプロパティを表すデータプロパティ格納部１０に記録する。
状態空間について説明する。図３は、次のようなＷｅｂショッピングシステムの仕様に基づいて生成された状態空間を示す図である。
（Ｗｅｂショッピングシステムの仕様）
・客は一般会員かプレミア会員とする。
・取り扱う商品はリンゴ(５０ドル)とバナナ(１００ドル)とする。
・合計が５００ドル以上の注文についてメールを送信する。なお、プレミア会員にはＨＴＭＬメールを送信する。
・在庫切れの場合、客のメーリングリストに在庫切れのメールを送る。
（Ｗｅｂショッピングシステムの仕様）
・客は一般会員かプレミア会員とする。
・取り扱う商品はリンゴ(５０ドル)とバナナ(１００ドル)とする。
・合計が５００ドル以上の注文についてメールを送信する。なお、プレミア会員にはＨＴＭＬメールを送信する。
・在庫切れの場合、客のメーリングリストに在庫切れのメールを送る。
図３に示す状態空間では、まず初期状態「ｉｎｉｔｉａｌ」においてログインをすると、会員種別を判定する状態に移行するパスが発生する（例えば「ｅｖｅｎｔ０１」）。この状態から次の状態に移行するさいに発生するパスをイベントという。次の状態に移行する。その状態（例えば「ｓｔａｔｅ０１」）において「一般会員」が選択されれば次の状態（例えば「ｓｔａｔｅ０２」）に移行する。例えば、「ｓｔａｔｅ０１」において「商品」として「リンゴ」が選択され、その数量として「５」が選択されると「ｓｔａｔｅ０２」に移行する。このときの「ｓｔａｔｅ０２」に移行するイベントを「ｅｖｅｎｔ０２」とする。次に、「ｓｔａｔｅ０２」において「商品」として「バナナ」が選択され、その数量として「３」が選択されると「ｓｔａｔｅ０３」に移行する。このときの「ｓｔａｔｅ０３」へのイベントを「ｅｖｅｎｔ０３」とする。このように状態空間は、状態（ｓｔａｔｅ××）とイベント（ｅｖｅｎｔ××）により表すことができる。
上記のような状態空間は、図４のＡとＢに示すテーブルに変換することができる。
図４のＡは状態テーブルの例を示す図である。「状態ＩＤ」「Ｖ会員種別」「Ｖ商品」「Ｖ数量」「Ｖｓｔｕｂ」・・・などから構成されている。「状態ＩＤ」には図３に示されている「ｉｎｉｔｉａｌ」「ｓｔａｔｅ０１」「ｓｔａｔｅ０２」「ｓｔａｔｅ０３」「ｓｔａｔｅ０４」「ｓｔａｔｅ０５」などの状態を識別する識別番号が付されている。
図４のＡは状態テーブルの例を示す図である。「状態ＩＤ」「Ｖ会員種別」「Ｖ商品」「Ｖ数量」「Ｖｓｔｕｂ」・・・などから構成されている。「状態ＩＤ」には図３に示されている「ｉｎｉｔｉａｌ」「ｓｔａｔｅ０１」「ｓｔａｔｅ０２」「ｓｔａｔｅ０３」「ｓｔａｔｅ０４」「ｓｔａｔｅ０５」などの状態を識別する識別番号が付されている。
「Ｖ会員種別」にはその状態において、「一般会員」が選択されたか「プレミア会員」が選択されたかを識別するため「一般」または「プレミア」を記録する。「一般会員」であれば「一般」が記録され、「プレミア会員」であれば「プレミア」が記録される。ただし、「ｉｎｉｔｉａｌ」ではログインをするだけなので「“”」としている。
「Ｖ商品」にはその状態において、「リンゴ」が選択されたか「バナナ」が選択されたかを識別するため、「リンゴ」または「バナナ」が記録される。「リンゴ」が選択されれ
ば「リンゴ」が記録され、「バナナ」が選択されれば「バナナ」が記録される。「ｉｎｉｔｉａｌ」には「“”」が記録されている。
ば「リンゴ」が記録され、「バナナ」が選択されれば「バナナ」が記録される。「ｉｎｉｔｉａｌ」には「“”」が記録されている。
「Ｖ数量」にはその状態において、「リンゴ」または「バナナ」の数量が入力される。
スタブ呼び出し変数「Ｖｓｔｕｂ」にはスタブを利用したかを示すため識別番号を記録する。図４のＡの例はスタブを利用した場合には「１」が記録される。図３において「ｓｔａｔｅ０５」の状態はメールを送信しているためネットワークスタブを使用しているため「１」が記録されている。
スタブ呼び出し変数「Ｖｓｔｕｂ」にはスタブを利用したかを示すため識別番号を記録する。図４のＡの例はスタブを利用した場合には「１」が記録される。図３において「ｓｔａｔｅ０５」の状態はメールを送信しているためネットワークスタブを使用しているため「１」が記録されている。
図４のＢはイベントテーブルの例を示す図である。「イベントＩＤ」「遷移元」「遷移先」から構成されている。「イベントＩＤ」には図３に示されている「ｅｖｅｎｔ０１」「ｅｖｅｎｔ０２」「ｅｖｅｎｔ０３」「ｅｖｅｎｔ０４」「ｅｖｅｎｔ０５」などのイベントを識別する識別番号が付されている（図３参照）。
「遷移元」には、そのイベントが発生した状態が記録される。例えば、「ｅｖｅｎｔ０１」へ移行する状態として「ｉｎｉｔｉａｌ」が記録され、同様にイベントに対応する「ｓｔａｔｅ０１」「ｓｔａｔｅ０２」・・・が記録されている（図３参照）。
「遷移先」には、そのイベントが発生後に遷移した状態が記録される。例えば、「ｅｖｅｎｔ０１」が発生後遷移する「ｓｔａｔｅ０１」が記録され、同様にイベントに対応する「ｓｔａｔｅ０２」「ｓｔａｔｅ０３」・・・が記録されている（図３参照）。
パス抽出器７の状態特定部１４は、状態空間格納部１１の状態テーブルの「Ｖｓｔｕｂ」に「１」が記録されている「状態ＩＤ」を特定する。図３の例では２重線楕円で示される「メール送信」(ネットワークスタブ)を行なう状態を特定する。
次に、パス抽出部１５により初期状態「ｉｎｉｔｉａｌ」から特定した状態（メール送信）へのパスを抽出する。例えば、図５に示した状態空間の例であれば以下のように抽出する（太線矢印）。
パス１：
（１）ログイン（“ｕｓｅｒ１”，“ｐａｓｓ１”）， ←「一般」
（２）商品選択（リンゴ，５），
（３）商品選択（バナナ，３），
（４）商品選択（バナナ，５０），
（５）注文 ←「メール送信」
パス２：
（１）ログイン（“ｕｓｅｒ１”，“ｐａｓｓ１”）， ←「一般」
（２）商品選択（リンゴ，５），
（３）商品選択（バナナ，３），
（４）注文 ←「メール送信」
パス３：
（１）ログイン（“ｕｓｅｒ１”，“ｐａｓｓ１”）， ←「一般」
（２）商品選択（リンゴ，１０），
（３）注文 ←「メール送信」
パス４：
（１）ログイン（“ｕｓｅｒ１”，“ｐａｓｓ１”）， ←「一般」
（２）商品選択（リンゴ，１０），
（３）商品選択（リンゴ，５０），
（４）注文 ←「メール送信」
パス５：
（１）ログイン（“ｕｓｅｒ２”，“ｐａｓｓ２”）， ←「プレミア」
（２）商品選択（リンゴ，１０），
（３）注文 ←「メール送信」
パス６：
（１）ログイン（“ｕｓｅｒ２”，“ｐａｓｓ２”）， ←「プレミア」
（２）商品選択（リンゴ，１０），
（３）商品選択（リンゴ，５０），
（４）注文 ←「メール送信」
（１）ログインの（“ｕｓｅｒ１”，“ｐａｓｓ１”）は一般会員を示している。（“ｕｓｅｒ２”，“ｐａｓｓ２”）はプレミア会員を示している。
パス１：
（１）ログイン（“ｕｓｅｒ１”，“ｐａｓｓ１”）， ←「一般」
（２）商品選択（リンゴ，５），
（３）商品選択（バナナ，３），
（４）商品選択（バナナ，５０），
（５）注文 ←「メール送信」
パス２：
（１）ログイン（“ｕｓｅｒ１”，“ｐａｓｓ１”）， ←「一般」
（２）商品選択（リンゴ，５），
（３）商品選択（バナナ，３），
（４）注文 ←「メール送信」
パス３：
（１）ログイン（“ｕｓｅｒ１”，“ｐａｓｓ１”）， ←「一般」
（２）商品選択（リンゴ，１０），
（３）注文 ←「メール送信」
パス４：
（１）ログイン（“ｕｓｅｒ１”，“ｐａｓｓ１”）， ←「一般」
（２）商品選択（リンゴ，１０），
（３）商品選択（リンゴ，５０），
（４）注文 ←「メール送信」
パス５：
（１）ログイン（“ｕｓｅｒ２”，“ｐａｓｓ２”）， ←「プレミア」
（２）商品選択（リンゴ，１０），
（３）注文 ←「メール送信」
パス６：
（１）ログイン（“ｕｓｅｒ２”，“ｐａｓｓ２”）， ←「プレミア」
（２）商品選択（リンゴ，１０），
（３）商品選択（リンゴ，５０），
（４）注文 ←「メール送信」
（１）ログインの（“ｕｓｅｒ１”，“ｐａｓｓ１”）は一般会員を示している。（“ｕｓｅｒ２”，“ｐａｓｓ２”）はプレミア会員を示している。
パス抽出部１５は、上記の抽出したパス１〜６をパス格納部１２のパステーブルに記録する。図６に示すパステーブルは「パスＩＤ」「Ｎｏ」「イベント」「ラベル」から構成されている。「パスＩＤ」には抽出したパスを識別するための識別番号が付されている。上記パス１の場合、「パスＩＤ」に「ｐａｔｈ０１」が記録され、パス１の（１）〜（５）対応する「イベント」に「ｅｖｅｎｔ０１」〜「ｅｖｅｎｔ０５」が（１）〜（５）の順に記録される。「Ｎｏ」は初期状態からイベントが発生した順に、同じ「パスＩＤ」のイベントに対応するよう数字が割り振られている。図６ではログインに近い順に「Ｎｏ」に１〜５が割り振られている。
パス抽出処理が完了すると、次にパス分類器８のプロパティ適用部１６によりパス分類を行う。メール送信に関係するプロパティの例を示す。プロパティは通常、Ａ−＞Ｂの形をしており、「Ａ(条件)ならばＢ(帰結)である」と表すことができる。
ｐ０１：合計＞＝５００ドル ａｎｄ お客種別＝＝“一般会員”
−＞メール種別＝＝“一般注文メール”
ｐ０２：合計＞＝５００ドル ａｎｄ お客種別＝＝“プレミア会員”
−＞メール種別＝＝“ＨＴＭＬメール”
ｐ０３：商品在庫数＝＜０
−＞在庫切れＭＬ＝＝“ｙｅｓ”
ｐ０４：商品在庫数＞０
−＞在庫切れＭＬ＝＝“ｎｏ”
ｐ０１：合計＞＝５００ドル ａｎｄ お客種別＝＝“一般会員”
−＞メール種別＝＝“一般注文メール”
ｐ０２：合計＞＝５００ドル ａｎｄ お客種別＝＝“プレミア会員”
−＞メール種別＝＝“ＨＴＭＬメール”
ｐ０３：商品在庫数＝＜０
−＞在庫切れＭＬ＝＝“ｙｅｓ”
ｐ０４：商品在庫数＞０
−＞在庫切れＭＬ＝＝“ｎｏ”
図７は、上記ｐ０１〜ｐ０４に示したプロパティがプロパティ格納部１０のプロパティテーブルに記録されたときの図である。プロパティテーブルは「プロパティＩＤ」「プロパティ式」により構成されている。「プロパティＩＤ」にはプロパティを識別するための識別番号が記録される。上記メール送信に関係するプロパティの例であれば「ｐ０１」「ｐ０２」「ｐ０３」「ｐ０４」が記録されている。「プロパティ式」には「Ａ(条件)ならばＢ(帰結)である」とかかれたプロパティが記録されている。上記メール送信に関係するプロパティの例であれば「ｐ０１」「ｐ０２」「ｐ０３」「ｐ０４」に対応するプロパティが記録されている。ただし、図７では説明を分かりやすくするためにプロパティを専用の記述にしていないが、実際にはＬＴＬ（Linear Temporal Logic）やＣＴＬ（Computational Tree Logic）で記述されている。
プロパティ適用部１６は、抽出したパスに対して、プロパティの条件部分にマッチするプロパティを抽出する。例えば、「ｐ０１」に対応するプロパティであれば条件部分は「
合計＞＝５００ドル ａｎｄ お客種別＝＝“一般会員”」であるので、この条件部分にマッチする上記パス（パス１〜パス６）を探す。その結果パス１〜パス４にマッチすることが検出される。このように全てのプロパティの条件部分とパスとを比較し、比較した結果、パスとマッチしたプロパティを検出する。次のような結果が得られる。
パス１：ｐ０１，ｐ０３
パス２：ｐ０１
パス３：ｐ０１
パス４：ｐ０１，ｐ０３
パス５：ｐ０２
パス６：ｐ０２，ｐ０３
図６に示すようにパステーブルの「ラベル」の対応する部分に、上記プロパティ識別番号「ｐ０１」〜「ｐ０４」を記録する。
合計＞＝５００ドル ａｎｄ お客種別＝＝“一般会員”」であるので、この条件部分にマッチする上記パス（パス１〜パス６）を探す。その結果パス１〜パス４にマッチすることが検出される。このように全てのプロパティの条件部分とパスとを比較し、比較した結果、パスとマッチしたプロパティを検出する。次のような結果が得られる。
パス１：ｐ０１，ｐ０３
パス２：ｐ０１
パス３：ｐ０１
パス４：ｐ０１，ｐ０３
パス５：ｐ０２
パス６：ｐ０２，ｐ０３
図６に示すようにパステーブルの「ラベル」の対応する部分に、上記プロパティ識別番号「ｐ０１」〜「ｐ０４」を記録する。
次に、シナリオ分類部１７によりプロパティによる分類を行う。パスを対応付けられたプロパティにより分類する。
分類１（Ｐ１） :パス２，パス３
分類２（Ｐ１，Ｐ３）:パス１，パス４
分類３（Ｐ２） :パス５
分類４（Ｐ２，Ｐ３）:パス６
シナリオ１：（Ｐ１）
（１）ログイン（“ｕｓｅｒ１”，“ｐａｓｓ１”)，
（２）商品選択（リンゴ，５），
（３）商品選択（バナナ，３），
（４）商品選択（バナナ，５０），
（５）注文
シナリオ２：（Ｐ１，Ｐ３）
（１）ログイン（“ｕｓｅｒ１”，“ｐａｓｓ１”)，
（２）商品選択（リンゴ，５），
（３）商品選択（バナナ，３），
（４）注文
シナリオ５：（Ｐ２）
（１）ログイン（“ｕｓｅｒ２”，“ｐａｓｓ２”），
（２）商品選択（リンゴ，１０），
（３）注文
シナリオ６：（Ｐ２，Ｐ３）
（１）ログイン（“ｕｓｅｒ２”，“ｐａｓｓ２”），
（２）商品選択（リンゴ，１０），
（３）商品選択（リンゴ，５０），
（４）注文
分類１（Ｐ１） :パス２，パス３
分類２（Ｐ１，Ｐ３）:パス１，パス４
分類３（Ｐ２） :パス５
分類４（Ｐ２，Ｐ３）:パス６
シナリオ１：（Ｐ１）
（１）ログイン（“ｕｓｅｒ１”，“ｐａｓｓ１”)，
（２）商品選択（リンゴ，５），
（３）商品選択（バナナ，３），
（４）商品選択（バナナ，５０），
（５）注文
シナリオ２：（Ｐ１，Ｐ３）
（１）ログイン（“ｕｓｅｒ１”，“ｐａｓｓ１”)，
（２）商品選択（リンゴ，５），
（３）商品選択（バナナ，３），
（４）注文
シナリオ５：（Ｐ２）
（１）ログイン（“ｕｓｅｒ２”，“ｐａｓｓ２”），
（２）商品選択（リンゴ，１０），
（３）注文
シナリオ６：（Ｐ２，Ｐ３）
（１）ログイン（“ｕｓｅｒ２”，“ｐａｓｓ２”），
（２）商品選択（リンゴ，１０），
（３）商品選択（リンゴ，５０），
（４）注文
分類にパスが複数対応する場合は、スタブ呼び出しパターンとして同等とみなす。例えば、上記分類１にはパス２、３が対応し、分類２にはパス１、４が対応しているので、分類１は代表するパスとしてパス２を選択し、分類２は代表するパスとしてパス１を選択する（条件に複数の抽出したパスがあるとき、抽出したパスの中からひとつを選ぶ）。
図８に、シナリオ格納部１３のシナリオテーブルにプロパティ分類結果を記録した例を示す。「シナリオＩＤ」には上記分類に対応する「ｓｃｅｎａｒｉｏ０１」〜「ｓｃｅｎａｒｉｏ０４」が記録されている。「ラベル」には「プロパティＩＤ」が記録され、「パスＩＤ」には「シナリオＩＤ」に対応する代表するパスが記録されている。図８では「ｓｃｅｎａｒｉｏ０１」に「ｐａｔｈ０２」、「ｓｃｅｎａｒｉｏ０２」に「ｐａｔｈ０１」、「ｓｃｅｎａｒｉｏ０３」に「ｐａｔｈ０５」、「ｓｃｅｎａｒｉｏ０４」に「ｐａｔｈ０６」が記録される。
次に、対応するプロパティから期待される結果を導出する。つまり、対応付くプロパティの帰結部分より期待されるテスト結果を導出する。また、抽出したパスに対応するプロパティが複数あるときは、帰結の論理積（ａｎｄ）にする。
シナリオ１（Ｐ１）：
メール種別＝“一般注文メール”
シナリオ２（Ｐ１，Ｐ３）：
メール種別＝“一般注文メール” ａｎｄ 在庫切れＭＬ＝“ｙｅｓ”
シナリオ５（Ｐ２）：
メール種別＝＝“ＨＴＭＬメール”
シナリオ６：（Ｐ２，Ｐ３)：
メール種別＝＝“ＨＴＭＬメール” ａｎｄ 在庫切れＭＬ＝“ｙｅｓ”
シナリオ１（Ｐ１）：
メール種別＝“一般注文メール”
シナリオ２（Ｐ１，Ｐ３）：
メール種別＝“一般注文メール” ａｎｄ 在庫切れＭＬ＝“ｙｅｓ”
シナリオ５（Ｐ２）：
メール種別＝＝“ＨＴＭＬメール”
シナリオ６：（Ｐ２，Ｐ３)：
メール種別＝＝“ＨＴＭＬメール” ａｎｄ 在庫切れＭＬ＝“ｙｅｓ”
テストケースの生成は、テストケース生成器９によりテストケース(シナリオ＋期待される結果)を生成する。
テストケース１
シナリオ１：
（１）ログイン（“ｕｓｅｒ１”，“ｐａｓｓ１”），
（２）商品選択（リンゴ，５），
（３）商品選択（バナナ，３），
（４）注文
期待される結果：一般注文メールが送信される
テストケース２
シナリオ２：
（１）ログイン（“ｕｓｅｒ１”，“ｐａｓｓ１”），
（２）商品選択（リンゴ，５），
（３）商品選択（バナナ，３），
（４）商品選択（バナナ，５０），
（５）注文
期待される結果：一般注文メールが送信され、在庫切れメールがMLに送信される
テストケース３
シナリオ５：
（１）ログイン（“ｕｓｅｒ２”，“ｐａｓｓ２”），
（２）商品選択（リンゴ，１０），
（３）注文
期待される結果：ＨＴＭＬ注文メールが送信される
テストケース４
シナリオ６：
（１）ログイン（“ｕｓｅｒ２”，“ｐａｓｓ２”），
（２）商品選択（リンゴ，１０），
（３）商品選択（リンゴ，５０），
（４）注文
期待される結果：ＨＴＭＬ注文メールが送信され、在庫切れメールがＭＬに送信される
テストケース１
シナリオ１：
（１）ログイン（“ｕｓｅｒ１”，“ｐａｓｓ１”），
（２）商品選択（リンゴ，５），
（３）商品選択（バナナ，３），
（４）注文
期待される結果：一般注文メールが送信される
テストケース２
シナリオ２：
（１）ログイン（“ｕｓｅｒ１”，“ｐａｓｓ１”），
（２）商品選択（リンゴ，５），
（３）商品選択（バナナ，３），
（４）商品選択（バナナ，５０），
（５）注文
期待される結果：一般注文メールが送信され、在庫切れメールがMLに送信される
テストケース３
シナリオ５：
（１）ログイン（“ｕｓｅｒ２”，“ｐａｓｓ２”），
（２）商品選択（リンゴ，１０），
（３）注文
期待される結果：ＨＴＭＬ注文メールが送信される
テストケース４
シナリオ６：
（１）ログイン（“ｕｓｅｒ２”，“ｐａｓｓ２”），
（２）商品選択（リンゴ，１０），
（３）商品選択（リンゴ，５０），
（４）注文
期待される結果：ＨＴＭＬ注文メールが送信され、在庫切れメールがＭＬに送信される
図８に示すシナリオテーブルの「ｓｃｅｎａｒｉｏ０１」〜「ｓｃｅｎａｒｉｏ０４」に対応する「結果式」に対して期待される結果をそれぞれ記録する。「ｓｃｅｎａｒｉｏ０１」には「メール種別＝“一般注文メール”」、「ｓｃｅｎａｒｉｏ０２」には「メール種別＝“一般注文メール” ａｎｄ 在庫切れＭＬ＝“ｙｅｓ”」、「ｓｃｅｎａｒｉｏ０３」には「メール種別＝“ＨＴＭＬメール”」、「ｓｃｅｎａｒｉｏ０４」には「メール種別＝“ＨＴＭＬメール” ａｎｄ 在庫切れＭＬ＝“ｙｅｓ”」を記録する。
上記構成により、網羅的に行なうモデル検査の状態空間から生成されたテストケースがプログラムの仕様を示すプロパティ群から分類されるため、網羅的でかつ重複のない効率的なテストケースが生成可能となる。
また、期待されるテスト結果も、プロパティから生成するため、テスト設計者による間違いが入らない。このことにより、実機テストにおいて、テスト設計者に依存しない、漏れのなく正確なテストケース(シナリオ+期待される結果)が作成可能となる。
（動作説明）
図９ではパス抽出の動作について説明する。
図９のステップＳ１（状態特定処理）では、状態テーブル内に処理すべき状態が残っているかを判定し、残っていればステップＳ２に移行し、残っていなければステップＳ６に移行する。例えば、状態空間格納部１１（メモリ）の状態テーブルをパス抽出器７の状態特定部１４により参照し、状態テーブル内に処理すべき状態が残っているかを判定する。処理が完了したことを示すフラグを「状態ＩＤ」ごとに対応させて設け、そのフラグを監視して判定を行う。
図９ではパス抽出の動作について説明する。
図９のステップＳ１（状態特定処理）では、状態テーブル内に処理すべき状態が残っているかを判定し、残っていればステップＳ２に移行し、残っていなければステップＳ６に移行する。例えば、状態空間格納部１１（メモリ）の状態テーブルをパス抽出器７の状態特定部１４により参照し、状態テーブル内に処理すべき状態が残っているかを判定する。処理が完了したことを示すフラグを「状態ＩＤ」ごとに対応させて設け、そのフラグを監視して判定を行う。
ステップＳ２（状態特定処理）では、当該状態のスタブ呼び出し変数（Ｖｓｔｕｂ）のフラグが立っているかを判定する。フラグが立っていればステップＳ３に移行し、フラグが立っていなければステップＳ１に移行する。例えば、図４に示す状態空間格納部１１（メモリ）の状態テーブルのスタブ呼び出し変数（Ｖｓｔｕｂ）が「１」であるかを判定する。図３の例では２重線楕円で示される「メール送信」(ネットワークスタブ)を行なう状態を特定する。
ステップＳ３（状態特定処理）では当該状態が初期状態かを判定する。当該状態が初期状態であればステップＳ１に移行し、初期状態であればステップＳ４に移行する。
ステップＳ４（パス抽出処理）では、イベントテーブルから遷移先が当該状態となっているイベントＩＤを抽出し、パステーブルに記録する。
ステップＳ４（パス抽出処理）では、イベントテーブルから遷移先が当該状態となっているイベントＩＤを抽出し、パステーブルに記録する。
ステップＳ５（パス抽出処理）では、イベントテーブルから当該イベントＩＤの遷移元の状態を抽出する。
ステップＳ３〜Ｓ５について図４のＡ、Ｂ、図６を用いて説明する。ステップＳ２で状態テーブル（図４のＡ）の「ｓｔａｔｅ０５」でスタブ呼び出し変数（Ｖｓｔｕｂ）に「１」が立っていることを検出する。ステップＳ３で初期状態であるかを判定する。しかし、「ｓｔａｔｅ０５」は「ｉｎｉｔｉａｌ」（初期状態）ではないためステップＳ４に移行する。ステップＳ４ではイベントテーブル（図４のＢ）の「遷移先」から「ｓｔａｔｅ０５」を検出し、「ｓｔａｔｅ０５」に対応する「ｅｖｅｎｔ０５」を、パステーブル（図６）の「イベント」に記録する。次に、イベントテーブルの「ｅｖｅｎｔ０５」に対応する「遷移元」を抽出する。
ステップＳ３〜Ｓ５について図４のＡ、Ｂ、図６を用いて説明する。ステップＳ２で状態テーブル（図４のＡ）の「ｓｔａｔｅ０５」でスタブ呼び出し変数（Ｖｓｔｕｂ）に「１」が立っていることを検出する。ステップＳ３で初期状態であるかを判定する。しかし、「ｓｔａｔｅ０５」は「ｉｎｉｔｉａｌ」（初期状態）ではないためステップＳ４に移行する。ステップＳ４ではイベントテーブル（図４のＢ）の「遷移先」から「ｓｔａｔｅ０５」を検出し、「ｓｔａｔｅ０５」に対応する「ｅｖｅｎｔ０５」を、パステーブル（図６）の「イベント」に記録する。次に、イベントテーブルの「ｅｖｅｎｔ０５」に対応する「遷移元」を抽出する。
次に抽出した「ｅｖｅｎｔ０５」の遷移元「ｅｖｅｎｔ０４」が、初期状態であるかを判定し、ステップＳ３〜Ｓ５の処理を行う。同様の処理を何回か繰り返し「状態ＩＤ」が「ｉｎｉｔｉａｌ」であることを検出するとステップＳ１に移行して、他のパスを抽出処理に移行する。
ここで、「イベント」に「ｅｖｅｎｔ０１」〜「ｅｖｅｎｔ０５」を記録するときに、パステーブルの「パスＩＤ」に、同じパスであることを示すため「ｐａｔｈ０１」を記録する。
図１０のステップＳ６（プロパティ適用処理）では、パステーブル（図６）内に処理すべきパスが残っているかを判定する。残っていればステップＳ７に移行し、残っていなければステップＳ１１に移行する。例えば、パス格納部１２（メモリ）のパステーブルをパス分類器８のプロパティ適用部１６により参照し、パステーブル内に処理すべきパスが残っているかを判定する。処理が完了したことを示すフラグを「パスＩＤ」ごとに対応させて設け、そのフラグを監視して判定を行う。
ステップＳ７（プロパティ適用処理）では、プロパティテーブル（図７）内に適用するプロパティが残っているかを判定する。残っていればステップＳ８に移行し、残っていなければステップＳ６に移行する。例えば、プロパティ格納部１０（メモリ）のプロパティテーブルをパス分類器８のプロパティ適用部１６により参照し、プロパティテーブル内に処理すべきプロパティが残っているかを判定する。処理が完了したことを示すフラグを「プロパティＩＤ」ごとに対応させて設け、そのフラグを監視して判定を行う。
ステップＳ８（プロパティ適用処理）では、プロパティテーブルの「プロパティ式」の事前条件部を当該パスの最終状態に適用する。例えば、「プロパティＩＤ」が「ｐ０１」であれば事前条件部「合計＞＝５００ドル ａｎｄ お客種別＝＝“一般会員”」と、抽出したパスの最終状態を比較する。パスの最終状態は、状態テーブルとパステーブルから導出する。
ステップＳ９（プロパティ適用処理）では、ステップＳ８の適用結果が真であるかを判定する。事前条件部がパスの最終状態を満たしていればステップＳ１０に移行し、満たしていなければステップＳ７に移行する。
ステップＳ１０（プロパティ適用処理）では、条件を満たした当該プロパティの「プロパティＩＤ」をパステーブルの「ラベル」に記録する。
ステップＳ１０（プロパティ適用処理）では、条件を満たした当該プロパティの「プロパティＩＤ」をパステーブルの「ラベル」に記録する。
図１１のステップＳ１１（シナリオ分類処理）では、パステーブル内に処理すべきパスが残っているかを判定する。残っていればステップＳ１２に移行し、残っていなければステップＳ１４に移行する。例えば、パス格納部１２（メモリ）のパステーブルをパス分類器８のシナリオ分類部１７により参照し、パステーブル内に処理すべきパスが残っているかを判定する。処理が完了したことを示すフラグを「パスＩＤ」ごとに対応させて設け、そのフラグを監視して判定を行う。
ステップＳ１２（シナリオ分類処理）では、パステーブルの「ラベル」に既に当該パスがシナリオとして登録されているかを判定する。登録されていなければステップＳ１３に移行し、登録されていればステップＳ１１に移行する。
ステップＳ１３（シナリオ分類処理）では、当該パスをシナリオテーブル（図８）の「ラベル」に追加する。
ステップＳ１３（シナリオ分類処理）では、当該パスをシナリオテーブル（図８）の「ラベル」に追加する。
図１２のステップＳ１４（テストケース生成処理）では、シナリオテーブル内に処理すべきシナリオが残っているかを判定する。例えば、シナリオ格納部１３（メモリ）のシナリオテーブルをテストケース生成器９により参照し、シナリオテーブル内に処理すべきシナリオが残っているかを判定する。処理が完了したことを示すフラグを「シナリオＩＤ」ごとに対応させて設け、そのフラグを監視して判定を行う。
ステップＳ１５（テストケース生成処理）では、シナリオテーブルの「ラベル」に記録されたプロパティを、プロパティテーブルからプロパティ式を抽出する。
ステップＳ１６（テストケース生成処理）では、抽出したプロパティの帰結部分の式をシナリオテーブルの「結果式」に「シナリオＩＤ」に対応するように記録する。
ステップＳ１６（テストケース生成処理）では、抽出したプロパティの帰結部分の式をシナリオテーブルの「結果式」に「シナリオＩＤ」に対応するように記録する。
上記処理により、網羅的に行なうモデル検査の状態空間から生成されたテストケースがプログラムの仕様を示すプロパティ群から分類されるため、網羅的でかつ重複のない効率的なテストケースが生成可能となる。
また、期待されるテスト結果も、プロパティから生成するため、テスト設計者による間違いが入らない。このことにより、実機テストにおいて、テスト設計者に依存しない、漏れのなく正確なテストケース(シナリオ+期待される結果)が作成可能となる。
（上記本発明の実施形態の装置を実現できるコンピュータのハードウェア構成）
図１３は本発明を実現するためのシステム構成を示すブロック図である。
図１３において、テストケース生成をする装置１３０は、ＣＰＵ１３１、ＲＯＭ１３２、ＲＡＭ１３３、ハードディスクドライブ（ＨＤＤ）１３４、フレキシブルディスクドライブ（ＦＤＤ）１３５、入力インタフェース（入力Ｉ／Ｆ）１３６、通信インタフェース（通信Ｉ／Ｆ）１３７、出力インタフェース（出力Ｉ／Ｆ）１３９、グラッフィック処理部１３１０などを備えている。また、上記各構成部はバス１３１１によってそれぞれ接続されている。
図１３は本発明を実現するためのシステム構成を示すブロック図である。
図１３において、テストケース生成をする装置１３０は、ＣＰＵ１３１、ＲＯＭ１３２、ＲＡＭ１３３、ハードディスクドライブ（ＨＤＤ）１３４、フレキシブルディスクドライブ（ＦＤＤ）１３５、入力インタフェース（入力Ｉ／Ｆ）１３６、通信インタフェース（通信Ｉ／Ｆ）１３７、出力インタフェース（出力Ｉ／Ｆ）１３９、グラッフィック処理部１３１０などを備えている。また、上記各構成部はバス１３１１によってそれぞれ接続されている。
ＣＰＵ１３１は、ＲＯＭ１３２、ＲＡＭ１３３、ＨＤＤ１３４、ＦＤＤ１３５に格納されているプログラムやデータに応じた処理を実行し、装置１３０の全体の制御などをする。ＲＯＭ１３２は、ＣＰＵ１３１が実行する基本的なプログラム（ブートプログラムなど）やデータを記録する。ＲＡＭ１３３は、ＣＰＵ１３１が実行途中のプログラムやデータを記録し、ワークエリアなどとして使用される。
ＨＤＤ１３４には、ＣＰＵ１３１が実行するＯＳ（Operation System）やアプリケーションプログラムなどが記録され、ＣＰＵ１３１の制御にしたがいハードディスクにデータのリード／ライトを実行する。ＦＤＤ１３５は、ＣＰＵ１３１の制御にしたがってＦＤ１３５ａに対するデータのリード／ライトを制御する。ＦＤ１３５ａは、ＦＤＤ１３５の制御で書き込まれたデータを記憶したり、ＦＤ１３５ａに記憶されたデータを装置１３０に読み取らせたりする。また、着脱可能な記録媒体としてＦＤ１３５ａのほか、コンピュータで読み取り可能な記録媒体として、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ(DigitalVersatileDisc)、ＤＶＤ−ＲＡＭ(RandomAccessMemory)、ＣＤ−ＲＯＭ(CompactDiscReadOnlyMemory)、ＣＤ−Ｒ(Recorda
ble)／ＲＷ(ReWritable)などがある。光磁気記録媒体には、ＭＯ(Magneto-Opticaldisk)などがある。
ble)／ＲＷ(ReWritable)などがある。光磁気記録媒体には、ＭＯ(Magneto-Opticaldisk)などがある。
入力Ｉ／Ｆ１３６は、マウスやキーボードが接続され、ユーザが入力した情報を受信し、バス１３１１を介してＣＰＵ１３１に送信する。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウスは、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などを行う。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。
通信Ｉ／Ｆ１３７は、必要に応じ、他のコンピュータとの間のＬＡＮ接続やインターネット接続や無線接続のためのインタフェースである。通信回線を通じてインターネットなどのネットワークを介して他の装置に接続される。そして、ネットワーク１３８と内部のインタフェースは、外部装置からのデータの入出力を制御する。例えば、モデムやＬＡＮアダプタなどを採用することができる。
出力Ｉ／Ｆ１３９は、プリンタなどの出力装置１３９ａを制御するために備える。また、グラフィック処理部１３１０には、ディスプレイなどの表示装置１３１０ａが接続され、グラフィック処理部１３１０は、ＣＰＵ１３１からの描画命令に従って表示装置１３１０ａの画面上に操作情報、論理シミュレーション後のログやカバレッジの集計結果、信号波形等を表示する。例えば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。なお、グラフィック処理部１３１０を介さずに、出力Ｉ／Ｆ１３９から表示装置と接続してもよい。
このようなハードウェア構成を有するコンピュータを１台または２台以上用いることによって、上記説明した各種処理機能（図９〜１２に示したフローチャート）が実現される。その場合システムが有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
また、本発明は、上記実施の形態に限定されるものでなく、本発明の要旨を逸脱しない範囲内で種々の改良、変更が可能である。
以上実施例を含む実施形態に関し、更に以下の付記を開示する。
（付記１）
プログラムモデル検査後の実機テストにおけるテストケースを生成するテストケース生成プログラムであって、
コンピュータに、
前記モデル検査により出力された状態と前記状態の遷移により表される状態空間が記録されたメモリを参照して、外部モジュールを呼び出す状態を特定する状態特定処理と、
前記状態特定処理が特定した前記外部モジュールを呼び出す状態から初期状態へのパスを、前記メモリに記録した前記状態の遷移を参照して抽出するパス抽出処理と、
前記パス抽出処理によって抽出したパスに対して、前記メモリに記録されている前記プ
ログラムの仕様に基づいて「Ａ（条件）ならばＢ（帰結）である」の形式で作成されたプロパティの前記条件を比較して、前記条件を満たす前記抽出したパスを検出するプロパティ適用処理と、
前記条件ごとに前記抽出したパスを分類するシナリオ分類処理と、
前記シナリオ分類処理により分類された前記抽出したパスと、前記抽出したパスに対応する前記プロパティの前記帰結から導出される期待されるテスト結果とを、テストケースとして生成するテストケース生成処理と、
を実行させることを特徴とするテストケース生成プログラム。
（付記２）
前記シナリオ分類処理は、
前記条件に複数の前記抽出したパスがあるとき、前記抽出したパスの中からひとつを選ぶことを特徴とする付記１に記載のテストケース生成プログラム。
（付記３）
前記テストケース生成処理は、
前記抽出したパスに対応するプロパティが複数あるときは、前記帰結の論理積を前記期待される結果とすることを特徴とする付記１に記載のテストケース生成プログラム。
（付記４）
プログラムモデル検査後の実機テストにおけるテストケースを生成するテストケース生成装置であって、
前記モデル検査により出力された状態と前記状態の遷移により表される状態空間が記録されたメモリを参照して、外部モジュールを呼び出す状態を特定する状態特定部と、
前記状態特定部が特定した前記外部モジュールを呼び出す状態から初期状態へのパスを、前記メモリに記録した前記状態の遷移を参照して抽出するパス抽出部と、
前記パス抽出部によって抽出したパスに対して、前記メモリに記録されている前記プログラムの仕様に基づいて「Ａ（条件）ならばＢ（帰結）である」の形式で作成されたプロパティの前記条件を比較して、前記条件を満たす前記抽出したパスを検出するプロパティ適用部と、
前記条件ごとに前記抽出したパスを分類するシナリオ分類部と、
前記シナリオ分類部により分類された前記抽出したパスと、前記抽出したパスに対応する前記プロパティの前記帰結から導出される期待されるテスト結果とを、テストケースとして生成するテストケース生成部と、
を具備することを特徴とするテストケース生成装置。
（付記５）
テストケース生成装置によって実行される、プログラムモデル検査後の実機テストにおけるテストケースを生成するテストケース生成方法であって、
前記テストケース生成装置が、
前記モデル検査により出力された状態と前記状態の遷移により表される状態空間が記録されたメモリを参照して、外部モジュールを呼び出す状態を特定する状態特定し、
前記特定した前記外部モジュールを呼び出す状態から初期状態へのパスを、前記メモリに記録した前記状態の遷移を参照して抽出するパス抽出し、
前記抽出したパスに対して、前記メモリに記録されている前記プログラムの仕様に基づいて「Ａ（条件）ならばＢ（帰結）である」の形式で作成されたプロパティの前記条件を比較して、前記条件を満たす前記抽出したパスを検出し、
前記条件ごとに前記抽出したパスを分類し、
前記分類された前記抽出したパスと、前記抽出したパスに対応する前記プロパティの前記帰結から導出される期待されるテスト結果とを、テストケースとして生成する、
ことを特徴とするテストケース生成方法。
（付記６）
前記シナリオ分類部は、
前記条件に複数の前記抽出したパスがあるとき、前記抽出したパスの中からひとつを選
ぶことを特徴とする付記４に記載のテストケース生成装置。
（付記７）
前記テストケース生成部は、
前記抽出したパスに対応するプロパティが複数あるときは、プロパティ前記帰結の論理積を前記期待される結果とすることを特徴とする付記１に記載のテストケース生成装置。（付記８）
前記条件に複数の前記抽出したパスがあるとき、前記抽出したパスの中からひとつを選ぶことを特徴とする付記５に記載のテストケース生成方法。
（付記９）
前記抽出したパスに対応するプロパティが複数あるときは、前記帰結の論理積を前記期待される結果とすることを特徴とする付記５に記載のテストケース生成方法。
（付記１）
プログラムモデル検査後の実機テストにおけるテストケースを生成するテストケース生成プログラムであって、
コンピュータに、
前記モデル検査により出力された状態と前記状態の遷移により表される状態空間が記録されたメモリを参照して、外部モジュールを呼び出す状態を特定する状態特定処理と、
前記状態特定処理が特定した前記外部モジュールを呼び出す状態から初期状態へのパスを、前記メモリに記録した前記状態の遷移を参照して抽出するパス抽出処理と、
前記パス抽出処理によって抽出したパスに対して、前記メモリに記録されている前記プ
ログラムの仕様に基づいて「Ａ（条件）ならばＢ（帰結）である」の形式で作成されたプロパティの前記条件を比較して、前記条件を満たす前記抽出したパスを検出するプロパティ適用処理と、
前記条件ごとに前記抽出したパスを分類するシナリオ分類処理と、
前記シナリオ分類処理により分類された前記抽出したパスと、前記抽出したパスに対応する前記プロパティの前記帰結から導出される期待されるテスト結果とを、テストケースとして生成するテストケース生成処理と、
を実行させることを特徴とするテストケース生成プログラム。
（付記２）
前記シナリオ分類処理は、
前記条件に複数の前記抽出したパスがあるとき、前記抽出したパスの中からひとつを選ぶことを特徴とする付記１に記載のテストケース生成プログラム。
（付記３）
前記テストケース生成処理は、
前記抽出したパスに対応するプロパティが複数あるときは、前記帰結の論理積を前記期待される結果とすることを特徴とする付記１に記載のテストケース生成プログラム。
（付記４）
プログラムモデル検査後の実機テストにおけるテストケースを生成するテストケース生成装置であって、
前記モデル検査により出力された状態と前記状態の遷移により表される状態空間が記録されたメモリを参照して、外部モジュールを呼び出す状態を特定する状態特定部と、
前記状態特定部が特定した前記外部モジュールを呼び出す状態から初期状態へのパスを、前記メモリに記録した前記状態の遷移を参照して抽出するパス抽出部と、
前記パス抽出部によって抽出したパスに対して、前記メモリに記録されている前記プログラムの仕様に基づいて「Ａ（条件）ならばＢ（帰結）である」の形式で作成されたプロパティの前記条件を比較して、前記条件を満たす前記抽出したパスを検出するプロパティ適用部と、
前記条件ごとに前記抽出したパスを分類するシナリオ分類部と、
前記シナリオ分類部により分類された前記抽出したパスと、前記抽出したパスに対応する前記プロパティの前記帰結から導出される期待されるテスト結果とを、テストケースとして生成するテストケース生成部と、
を具備することを特徴とするテストケース生成装置。
（付記５）
テストケース生成装置によって実行される、プログラムモデル検査後の実機テストにおけるテストケースを生成するテストケース生成方法であって、
前記テストケース生成装置が、
前記モデル検査により出力された状態と前記状態の遷移により表される状態空間が記録されたメモリを参照して、外部モジュールを呼び出す状態を特定する状態特定し、
前記特定した前記外部モジュールを呼び出す状態から初期状態へのパスを、前記メモリに記録した前記状態の遷移を参照して抽出するパス抽出し、
前記抽出したパスに対して、前記メモリに記録されている前記プログラムの仕様に基づいて「Ａ（条件）ならばＢ（帰結）である」の形式で作成されたプロパティの前記条件を比較して、前記条件を満たす前記抽出したパスを検出し、
前記条件ごとに前記抽出したパスを分類し、
前記分類された前記抽出したパスと、前記抽出したパスに対応する前記プロパティの前記帰結から導出される期待されるテスト結果とを、テストケースとして生成する、
ことを特徴とするテストケース生成方法。
（付記６）
前記シナリオ分類部は、
前記条件に複数の前記抽出したパスがあるとき、前記抽出したパスの中からひとつを選
ぶことを特徴とする付記４に記載のテストケース生成装置。
（付記７）
前記テストケース生成部は、
前記抽出したパスに対応するプロパティが複数あるときは、プロパティ前記帰結の論理積を前記期待される結果とすることを特徴とする付記１に記載のテストケース生成装置。（付記８）
前記条件に複数の前記抽出したパスがあるとき、前記抽出したパスの中からひとつを選ぶことを特徴とする付記５に記載のテストケース生成方法。
（付記９）
前記抽出したパスに対応するプロパティが複数あるときは、前記帰結の論理積を前記期待される結果とすることを特徴とする付記５に記載のテストケース生成方法。
１ モデル検査装置
２ テストケース生成装置
３ 入出力装置
４ パス抽出
５ パス分類
６ テスト結果導出
７ パス抽出器
８ パス分類器
９ テストシナリオ生成器
１０ プロパティ格納部
１１ 状態空間格納部
１２ パス格納部
１３ シナリオ格納部
１４ 状態特定部
１５ パス抽出部
１６ プロパティ適用部
１７ シナリオ分類部
１３０ 装置
１３１ ＣＰＵ
１３２ ＲＯＭ
１３３ ＲＡＭ
１３４ ハードディスクドライブ（ＨＤＤ）
１３５ フレキシブルディスクドライブ（ＦＤＤ）
１３５ａ 記録媒体（ＦＤ）
１３６ 入力インタフェース（入力Ｉ／Ｆ）
１３７ 通信インタフェース（通信Ｉ／Ｆ）
１３８ ネットワーク
１３９ 出力インタフェース（出力Ｉ／Ｆ）
１３１０ グラッフィック処理部
１３１０ａ 表示装置
２ テストケース生成装置
３ 入出力装置
４ パス抽出
５ パス分類
６ テスト結果導出
７ パス抽出器
８ パス分類器
９ テストシナリオ生成器
１０ プロパティ格納部
１１ 状態空間格納部
１２ パス格納部
１３ シナリオ格納部
１４ 状態特定部
１５ パス抽出部
１６ プロパティ適用部
１７ シナリオ分類部
１３０ 装置
１３１ ＣＰＵ
１３２ ＲＯＭ
１３３ ＲＡＭ
１３４ ハードディスクドライブ（ＨＤＤ）
１３５ フレキシブルディスクドライブ（ＦＤＤ）
１３５ａ 記録媒体（ＦＤ）
１３６ 入力インタフェース（入力Ｉ／Ｆ）
１３７ 通信インタフェース（通信Ｉ／Ｆ）
１３８ ネットワーク
１３９ 出力インタフェース（出力Ｉ／Ｆ）
１３１０ グラッフィック処理部
１３１０ａ 表示装置
Claims (5)
- プログラムモデル検査後の実機テストにおけるテストケースを生成するテストケース生成プログラムであって、
コンピュータに、
前記モデル検査により出力された状態と前記状態の遷移により表される状態空間が記録されたメモリを参照して、外部モジュールを呼び出す状態を特定する状態特定処理と、
前記状態特定処理が特定した前記外部モジュールを呼び出す状態から初期状態へのパスを、前記メモリに記録した前記状態の遷移を参照して抽出するパス抽出処理と、
前記パス抽出処理によって抽出したパスに対して、前記メモリに記録されている前記プログラムの仕様に基づいて「Ａ（条件）ならばＢ（帰結）である」の形式で作成されたプロパティの前記条件を比較して、前記条件を満たす前記抽出したパスを検出するプロパティ適用処理と、
前記条件ごとに前記抽出したパスを分類するシナリオ分類処理と、
前記シナリオ分類処理により分類された前記抽出したパスと、前記抽出したパスに対応する前記プロパティの前記帰結から導出される期待されるテスト結果とを、テストケースとして生成するテストケース生成処理と、
を実行させることを特徴とするテストケース生成プログラム。 - 前記シナリオ分類処理は、
前記条件に複数の前記抽出したパスがあるとき、前記抽出したパスの中からひとつを選ぶことを特徴とする請求項１に記載のテストケース生成プログラム。 - 前記テストケース生成処理は、
前記抽出したパスに対応するプロパティが複数あるときは、前記帰結の論理積を前記期待される結果とすることを特徴とする請求項１に記載のテストケース生成プログラム。 - プログラムモデル検査後の実機テストにおけるテストケースを生成するテストケース生成装置であって、
前記モデル検査により出力された状態と前記状態の遷移により表される状態空間が記録されたメモリを参照して、外部モジュールを呼び出す状態を特定する状態特定部と、
前記状態特定部が特定した前記外部モジュールを呼び出す状態から初期状態へのパスを、前記メモリに記録した前記状態の遷移を参照して抽出するパス抽出部と、
前記パス抽出部によって抽出したパスに対して、前記メモリに記録されている前記プログラムの仕様に基づいて「Ａ（条件）ならばＢ（帰結）である」の形式で作成されたプロパティの前記条件を比較して、前記条件を満たす前記抽出したパスを検出するプロパティ適用部と、
前記条件ごとに前記抽出したパスを分類するシナリオ分類部と、
前記シナリオ分類部により分類された前記抽出したパスと、前記抽出したパスに対応する前記プロパティの前記帰結から導出される期待されるテスト結果とを、テストケースとして生成するテストケース生成部と、
を具備することを特徴とするテストケース生成装置。 - テストケース生成装置によって実行される、プログラムモデル検査後の実機テストにおけるテストケースを生成するテストケース生成方法であって、
前記テストケース生成装置が、
前記モデル検査により出力された状態と前記状態の遷移により表される状態空間が記録されたメモリを参照して、外部モジュールを呼び出す状態を特定する状態特定し、
前記特定した前記外部モジュールを呼び出す状態から初期状態へのパスを、前記メモリに記録した前記状態の遷移を参照して抽出するパス抽出し、
前記抽出したパスに対して、前記メモリに記録されている前記プログラムの仕様に基づいて「Ａ（条件）ならばＢ（帰結）である」の形式で作成されたプロパティの前記条件を比較して、前記条件を満たす前記抽出したパスを検出し、
前記条件ごとに前記抽出したパスを分類し、
前記分類された前記抽出したパスと、前記抽出したパスに対応する前記プロパティの前記帰結から導出される期待されるテスト結果とを、テストケースとして生成する、
ことを特徴とするテストケース生成方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008275432A JP5176869B2 (ja) | 2008-10-27 | 2008-10-27 | テストケース生成プログラムとテストケース生成装置およびテストケース生成方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008275432A JP5176869B2 (ja) | 2008-10-27 | 2008-10-27 | テストケース生成プログラムとテストケース生成装置およびテストケース生成方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2010102624A JP2010102624A (ja) | 2010-05-06 |
| JP5176869B2 true JP5176869B2 (ja) | 2013-04-03 |
Family
ID=42293198
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008275432A Expired - Fee Related JP5176869B2 (ja) | 2008-10-27 | 2008-10-27 | テストケース生成プログラムとテストケース生成装置およびテストケース生成方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP5176869B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5629239B2 (ja) | 2011-05-23 | 2014-11-19 | インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ | ソフトウェアの動作をテストする装置及び方法 |
| JP6316120B2 (ja) | 2014-06-30 | 2018-04-25 | 日立オートモティブシステムズ株式会社 | テストケース生成システム及びテストケースを記録した記録媒体 |
| CN111158656B (zh) * | 2019-12-31 | 2023-05-02 | 中国银行股份有限公司 | 基于因果树法的测试代码生成方法及装置 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008071135A (ja) * | 2006-09-14 | 2008-03-27 | Nec Corp | 検証処理装置 |
-
2008
- 2008-10-27 JP JP2008275432A patent/JP5176869B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2010102624A (ja) | 2010-05-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Shankar et al. | Operationalizing machine learning: An interview study | |
| US7788086B2 (en) | Method and apparatus for processing sentiment-bearing text | |
| US8650143B2 (en) | Determination of document credibility | |
| US11650579B2 (en) | Information processing device, production facility monitoring method, and computer-readable recording medium recording production facility monitoring program | |
| US20070226222A1 (en) | Computer-readable recording medium having recorded system development support program, system development support apparatus, and system development support method | |
| Strandberg et al. | Information flow in software testing–an interview study with embedded software engineering practitioners | |
| JP2018147280A (ja) | データ分析装置及びデータ分析方法 | |
| JP5176869B2 (ja) | テストケース生成プログラムとテストケース生成装置およびテストケース生成方法 | |
| Corea et al. | A taxonomy of business rule organizing approaches in regard to business process compliance | |
| JP6695835B2 (ja) | 機械学習を利用したｆａｑ登録支援方法、及びコンピュータシステム | |
| JP5672165B2 (ja) | テストデータ生成プログラム、テストデータ生成方法、テストデータ生成装置 | |
| CN109376152A (zh) | 大数据系统文件数据准备方法和系统 | |
| JP6508327B2 (ja) | テキスト可視化システム、テキスト可視化方法、及び、プログラム | |
| JP2013077124A (ja) | ソフトウェアテストケース生成装置 | |
| JP2010128870A (ja) | データ処理装置 | |
| US20140152668A1 (en) | Information processing apparatus and method and non-transitory computer readable medium | |
| JP5321286B2 (ja) | プログラムモデル検査方法、プログラムモデル検査プログラム | |
| WO2021186706A1 (ja) | 修理支援システムおよび修理支援方法 | |
| JP2007115080A (ja) | 経営管理システム、経営管理方法および経営管理プログラム | |
| JP2020101898A (ja) | 設計図作成支援方法、設計図作成支援装置、及び設計図作成支援プログラム | |
| JP6520246B2 (ja) | 情報処理装置及び情報処理プログラム | |
| JP7499138B2 (ja) | 判定装置、判定プログラム及び情報生成方法 | |
| JP5900197B2 (ja) | 経路条件選択装置、該プログラム、及び該方法 | |
| JP5304470B2 (ja) | モデル検査プログラム、モデル検査方法、モデル検査装置 | |
| JP5228794B2 (ja) | モデル検査実施のための環境生成支援装置、環境生成支援方法、環境生成支援プログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20110808 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20121205 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20121211 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20121224 |
|
| LAPS | Cancellation because of no payment of annual fees |