JP2016012274A - テストケース生成システム及びテストケースを記録した記録媒体 - Google Patents

Abstract

【課題】オブジェクトコードをテストする際に、時相論理式を用いて合否基準を表現することができる技術を提供する。
【解決手段】テストケース生成システムは、検査対象となるオブジェクトコードまたは実行可能形式ファイルのモデルから探索された実行経路情報から、テスト実行制御内容に関する情報を生成する制御内容生成部２４０と、検査対象に対する、時間要素を含む検査式と、実行経路情報から、時間要素のない判定式とその判定式を実行するタイミングの組からなる合否条件に関する情報を生成する合否条件生成部２５０と、テスト実行制御内容に関する情報と、合否条件に関する情報とから、検査式に対応する合否条件を有するテストケースを生成するテストケース生成部２６０と、を備える。
【選択図】図２

Description

本発明は、ソフトウェアの検査を行うためのテストケース生成システム及びテストケースを記録した記録媒体に関する。

システムに搭載されるソフトウェアの規模増大に伴い、ソフトウェアの仕様やコードの全てについてレビューで確認することや、テストを実施することが困難になりつつある。また、並行動作するソフトウェアでは、処理のタイミングにより不具合が発生する場合があり、このような不具合はテストで発見することが困難である。このような問題への対処として、形式検証技術の１つであるモデル検査を適用する方法がある。

モデル検査では、検査対象である設計、具体的にはソフトウェア仕様やソースコードを形式仕様記述言語を用いて表現する（以下、これを「検証モデル」と呼ぶ）。また検査対象に求められる性質を、時間の概念と演算子を持つ論理式である時相論理式を用いてプロパティとして表現するか、時間の概念のない論理式によりアサーションとして表現する。これら検証モデルと、プロパティまたはアサーションで示される検査式とを、コンピュータ上で動作するツールであるモデル検査器に入力することで、検査対象が求められる性質を満たすか否かが、網羅的な状態探索などの数理的技法により判定される。また求められる性質が満たされない場合には、反例が導出される。

一方で、ソースコードはコンパイルされてオブジェクトコードに変換され、さらに特定の形式で結合された実行可能形式として、システムに搭載される。この過程でソースコードに不具合がなくても、コンパイラのバグや最適化の影響により、オブジェクトコードに不具合が発生することがありうる。また製品の開発者には、ソフトウェアの最終的な形であるオブジェクトコードに不備がないかを確認したいという要望がある。このため、オブジェクトコードについてもモデル検査を適用できれば有用である。しかし、オブジェクトコードに対するモデル検査は、オブジェクトコードが動作するコンピュータに応じてコードの表現が異なるため技術的な困難さがあり、一般的ではなく実現するツールも多くない。

この問題に対する方策として、モデル検査を応用してテストケースを生成する技術がある。モデル検査器は検証モデルを通して検査対象の実行経路や取りうる振る舞いを網羅的に探索する機能があるため、テストケース生成技術ではこの機能を活用している。仕組みは以下の通りである。

検査対象とするオブジェクトコードの元になるソースコードから検証モデルを作成し、ソースコードにおいてテストしたい実行経路の終点に対して「その終点には到達しない」というプロパティまたはアサーションを定義する。このプロパティまたはアサーションの入力に関して、モデル検査器は、その終点に至る実行経路を反例として出力する。例えば、モデル検査器にＳＰＩＮ（Ｓｉｍｐｌｅ Ｐｒｏｍｅｌａ Ｉｎｔｅｒｐｒｅｔｅｒ）を利用し、検証モデルにおいて最後に実行される点にａｓｓｅｒｔ（ｆａｌｓｅ）と記述して検査を実行する。前記のアサーションを記述した点が実行されるケースが存在する場合、実行が開始される点から、実行が終了する点までの実行経路に関する情報であるトレースが１ないし複数の反例として出力される。１トレースが１テストケースに対応する（実行条件を振った複数のテストケースにすることもできる）。このトレースには、途中で非決定的に選択された変数への代入、つまり入力値決定や、プロセスが複数ある場合にはその実行順序も含まれる。このトレースを、テストを実行するためのデータに変換して、検査対象のオブジェクトコードを実機またはシミュレータ上で実行するシステムの入力とする。このデータがテストケースまたはその一部となる。テストケースとは、テスト条件を示すデータである。ここで、「テストケースの一部」と表現する理由は、トレースから変換されたデータが合否基準や、検査対象とするプログラムのいくつかの実行条件を含まないためである。

このテストケース生成技術は実行経路を網羅できるため、オブジェクトコードに対してモデル検査を実施しているのと同様な効果が期待できる。モデル検査を応用したテストケース生成を行う先行技術として、特許文献１がある。

特開２０１０−１０２６２４号公報

ソースコードのモデル検査では、合否基準は時相論理式を用いて表現できる。しかし、オブジェクトコードの検査時には、１つ１つのテストは実機またはシミュレータでの実行となるため、合否基準は時相論理式を用いて表現することができない。モデル検査では、時相論理式の演算子である「いつも」や「将来」を扱うために、全ての制御点（モデル検査における実行ステップ）において論理式が評価される。しかし、オブジェクトコードのテストでは、合否判定は予め決められたタイミングでの論理式の評価となる。通常、実行後の１点のみにおいて合否判定の論理式が評価されることが多い。このため、実機やシミュレータを用いてテストを実行するシステムに合否基準として時相論理式を入力することができず、時相論理式で表現されるような時間の概念を含む性質の評価を実施することができない。

本発明の目的は、オブジェクトコードをテストする際に、時相論理式を用いて合否基準を表現することができる技術を提供することにある。

上記課題を解決する為に、例えば特許請求の範囲に記載の構成を採用する。本願は上記課題を解決する手段を複数含んでいるが、その一例をあげるならば、検査対象となるオブジェクトコードまたは実行可能形式ファイルのモデルから探索された実行経路情報から、テスト実行制御内容に関する情報を生成する制御内容生成部と、前記検査対象に対する、時間要素を含む検査式と、前記実行経路情報から、時間要素のない判定式とその判定式を実行するタイミングの組からなる合否条件に関する情報を生成する合否条件生成部と、前記テスト実行制御内容に関する情報と、前記合否条件に関する情報とから、前記検査式に対応する合否条件を有するテストケースを生成するテストケース生成部と、を備えるテストケース生成システムが提供される。

また、他の例によれば、コンピュータに、検査対象となるオブジェクトコードまたは実行可能形式ファイルを検査する処理を実行させるために用いられるテストケースのデータ構造であって、テスト実行制御内容に関する情報と、時間要素のない判定式とその判定式を実行するタイミングの組からなる合否条件に関する情報と、を含むデータ構造を有するデータを記録したコンピュータ読み取り可能な記録媒体が提供される。

本発明によれば、オブジェクトコードをテストする際に、時相論理式を用いて合否基準を表現することができる。これにより、検査できる内容が、時間の概念のない論理式のみのときよりも広がる。この合否基準の表現に、モデル検査を応用して生成したテストケースでオブジェクトコードを検査することを合わせることで、オブジェクトコードに対してモデル検査により時相論理で記述されたプロパティを検査するのと同様のことを実現することができる。

本発明に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、上記した以外の、課題、構成及び効果は、以下の実施例の説明により明らかにされる。

本発明のテストケース生成システムを実現するシステムの構成図である。 本発明の実施例におけるテストケース生成プログラムの機能と関連するプログラムの構成を示す図である。 本発明の実施例におけるテストケース生成プログラムの処理フローである。 本発明の実施例における制御内容生成部の処理フローである。 本発明の実施例における合否条件生成部の処理フローである。 プロパティの構文パターンに関するデータベースの一例である。 検査対象とするサンプルプログラムと、その検証モデルと、トレースの一例を示す図である。 本発明の実施例におけるテスト実行制御内容情報及び合否判定情報の一例を示す図である。 本発明の実施例において出力されるテストケースの一例を示す図である。

以下、添付図面を参照して本発明の実施例について説明する。なお、添付図面は本発明の原理に則った具体的な実施例を示しているが、これらは本発明の理解のためのものであり、決して本発明を限定的に解釈するために用いられるものではない。また、各図において共通の構成については同一の参照番号が付されている。

図１は、本発明のテストケース生成システムを実現するシステムの構成図である。本発明は、ソースコードからコンパイルされたオブジェクトコードや実行可能形式を検査するテストシステムに用いられるテストケースを生成するシステムである。テストケースとは、上述した通り、テスト条件を示すデータである。

本発明はソフトウェアツールとして実現されている。テストケース生成システムの各機能はソフトウェアとして実装される。テストケース生成システム１００は、コンピュータ１１０を備える。コンピュータ１１０は、主演算装置（ＣＰＵ）１１１と、主記憶装置（ＲＡＭ）１１２と、記憶媒体（ＲＯＭ）１１３と、補助記憶装置（ハードディスク）１１４と、入力装置（キーボードやポインティングデバイスなど）１３０と、表示装置（ディスプレイ、プリンタなど）１４０とを備える。

本発明を実現するソフトウェアは、テストケース生成プログラム１２０として、コンピュータ１１０のＲＯＭ１１３に格納されており、ＣＰＵ１１１により読み出されて実行される。コンピュータ１１０のＣＰＵ１１１は、テストケース生成プログラム１２０によって規定された処理を実行する。

検査対象であるオブジェクトコードの元になるソースコードのファイルや、そのソースコードを元に作成された検証モデルのファイルは、コンピュータ１１０上のハードディスク１１４に格納されている。テストケース生成プログラム１２０に対するユーザ操作は、キーボードなどの入力装置１３０から行うことができる。テストケース生成プログラム１２０による出力は、ディスプレイなどの表示装置１４０への表示や、ハードディスク１１４へデータファイル生成として成される。別の例として、テストケース生成プログラム１２０による出力は、図示しない外部コンピュータへのネットワークを介した出力、ＣＤ−ＲＯＭなどの外部記憶媒体へのデータファイル形式での書き込みによる出力であってもよい。また、他のプログラムもテストケース生成プログラム１２０と同様に扱われ、ＣＰＵ１１１がその他のプログラム実行し、出力を行ってもよい。

図２は、ＲＯＭ１１３に格納されたテストケース生成プログラム１２０の構成、及び、テストケース生成プログラム１２０に関連する他のプログラムの構成を示す。検証モデル生成プログラム２１０は、検査対象とするオブジェクトコードの元となるソースコード２００を入力として、検証モデル２１５を生成する。ここでの検証モデル２１５は、上述した通り、ソフトウェア仕様またはソースコードを形式仕様記述言語を用いて表現したものである。

実行経路探索プログラム２２０は、検査対象についての検証モデル２１５を探索し、実行経路情報（例えば、以下で説明するトレース２２５）を出力する。より詳細には、実行経路探索プログラム２２０は、検証モデル２１５にテストケース生成用（狭義にはトレース生成用）のプロパティまたはアサーションを追加したファイルを入力として、テストケースの元となるトレース群２２５を反例として１ないし複数生成する。実行経路探索プログラム２２０は、反例の生成に公知のモデル検査器を利用している。本実施例では、モデル検査器としてＳＰＩＮを利用する。反例の生成数は、モデル検査器へのオプション指定により調整することができる。

テストケース生成プログラム１２０は、トレース群２２５と、時相論理式２３５を入力として、テストケース群２８０を生成する。ここで、時相論理式２３５は、検査対象とするオブジェクトコードまたは実行可能形式に対するプロパティであり、時間要素を含む検査式である。テストケース生成プログラム１２０は、以下の構成を取っている。テストケース生成プログラムは、実行経路解析部２３０と、制御内容生成部２４０と、合否条件生成部２５０と、テストケース生成部２６０とを備える。

実行経路解析部２３０は、検証モデル２１５を入力として受け取り、検証モデル２１５が表現するソースコード２００内の処理呼び出し関係を含む制御フローを解析する。ソースコード２００がＣ言語で記述されている場合には、処理呼び出し関係は関数コールツリーのことである。実行経路解析部２３０は、解析結果として制御フローの情報を出力し、この制御フローの情報は、テストケース生成プログラム１２０内で利用される。なお、トレース群２２５が制御フローの情報を含んでいれば、検証モデル２１５からではなく、トレース群２２５から制御フローを解析してもよい。すなわち、トレース群２２５を実行経路解析部２３０の入力としてもよい。

制御内容生成部２４０は、トレース群２２５を入力とし、トレース群２２５の各トレースに対してテスト実行を制御する内容に関する情報（以下、これを「テスト実行制御内容情報」と呼ぶ）を生成する。ここで、テスト実行の制御内容とは、具体的には変数やマイコンのレジスタ等のデータを操作することや、割込みやリアルタイムＯＳ（Ｏｐｅｒａｔｉｏｎ Ｓｙｓｔｅｍ）におけるタスク起動などの処理実行、検査対象とするプログラムの実行状態を条件にしたトリガ（指定条件の成立までの待機）など、検査対象のプログラムの挙動を含むテストの実行内容に影響を与える操作の情報である。また、テスト実行の制御内容は、その操作を実行するタイミングの情報と組にされる。テスト実行制御内容情報は、１つのトレースに対し、１ないし複数のイベント列として規定される。

合否条件生成部２５０は、トレース群２２５と、時相論理式２３５とを入力として受け取り、トレース群２２５の各トレースに対して、合否条件に関する情報（以下、これを「合否条件情報」と呼ぶ）を出力する。この合否条件情報は、時間要素のない判定式と、その判定式を実行するタイミングの組からなる。また、合否条件情報では、１つのトレースに対し、１ないし複数の合否判定のイベント列が規定される。

テストケース生成部２６０は、制御内容生成部２４０が出力するテスト実行制御内容情報と、合否条件生成部２５０が出力する合否条件情報とから、テストケース群２８０を出力する。テストケース群２８０は、テストシステム２９０に入力可能な形式となっている。テストケース生成部２６０は、実行経路解析部２３０からの制御フローの情報を用いて、テスト実行制御内容情報と合否条件情報のイベント列を、１つのイベント列として実行順に整列する。その後、テストケース生成部２６０は、実行順に整列されたイベント列をテストシステムに入力するフォーマットに変換することにより、テストケース群２８０を作成する。

テストケース群２８０は、ハードディスク１１４などの記憶装置、または、所定のコンピュータ読み取り可能な記録媒体に記録される。テストシステム２９０は、ソースコード２００からコンパイルされたオブジェクトコードや実行可能形式ファイルの検査を実行するシステムである。テストシステム２９０は、テストケース群２８０を用いて、上記オブジェクトコードや実行可能形式ファイルを検査する。これにより、時相演算子の表現を合否条件に取り入れたテストケース群２８０で、検査対象のオブジェクトコードや実行可能形式を検査することができる。

図３は、テストケース生成プログラム１２０が実行する処理フローである。まず、ステップ３００で処理が開始される。次に、ステップ３１０において、実行経路解析部２３０が、検証モデル２１５の制御フローを解析し、制御フローの情報を出力する。

ステップ３２０からステップ３４０は、繰り返し実行される。ステップ３２０からステップ３４０は、トレース群２２５の各トレースに対して実行されるので、トレース群２２５に含まれるトレースの数だけ繰り返される。ステップ３２０では、制御内容生成部２４０が、トレース群２２５を解析してテスト実行制御内容情報を出力する。ステップ３３０では、合否条件生成部２５０が、トレース群２２５と時相論理式２３５とから合否条件情報を出力する。ステップ３４０では、テストケース生成部２６０が、テスト実行制御内容情報と合否条件情報とからテストケース群２８０の１テストケースを出力する。以上を繰り返し、ステップ３９０で処理を終了する。

図４は、制御内容生成部２４０によるステップ３２０の処理フローを詳細化したものである。ステップ４００で処理を開始する。ステップ４１０からステップ４４０は、トレース群２２５の各トレースに含まれる処理のステップ数だけ繰り返される。ステップ４１０では、制御内容生成部２４０が、処理対象とする各トレースに含まれるステップを先頭から１つずつ抽出する。ここでは、未抽出な処理のステップのうち次に実行される処理のステップの１つが１回の実行で抽出され、内容が解釈される。

ステップ４２０では、制御内容生成部２４０が、ステップ４１０で抽出された処理の種類を判定する。処理が変数（マイコンのレジスタを含む）への値代入による入力値設定であれば、ステップ４３０に進む。処理がプロセス起動であればステップ４４０に進む。入力値設定と判定する条件は、処理が代入文であることと、代入される変数が入力値として設定されているものであることである。プロセス起動と判定する条件は、当該処理がプロセスの起点として指定されている関数の最初の処理であること、である。関数の最初の処理か否かは、実行経路解析部２３０からの制御フロー情報を用いて判定できる。

ステップ４３０では、制御内容生成部２４０が、出力するテスト実行制御内容情報に、変数へ値を代入する処理を追加する。実行タイミングの情報としては、当該処理の記述位置（関数や行など）が付与される。処理の記述位置は、トレースから取得するか、実行経路解析部２３０からの制御フロー情報を辿ることで取得できる。

ステップ４４０では、ステップ４３０と同様にして、制御内容生成部２４０が、テスト実行制御内容情報に、トレースの処理が示す割込みやタスク起動を発生させるための制御処理を追加する。検証モデルの各プロセスが検査対象のプログラムにおいて相当する処理（割り込みやタスク起動など）の情報が制御内容生成部２４０に設定されているものとし、処理に応じた制御処理が選択される。以上を繰り返し、ステップ４９０で処理を終了する。

図５は、合否条件生成部２５０によるステップ３３０の処理フローを詳細化したものである。ステップ５００で処理が開始される。ステップ５１０では、合否条件生成部２５０が、入力された時相論理式２３５の構文を解析する。解析された構文はＡＳＴ（Ａｂｓｔｒａｃｔ Ｓｙｎｔａｘ Ｔｒｅｅ）の形で内部データとして表現される。ステップ５２０では、合否条件生成部２５０が、ステップ５１０により解析された時相論理式２３５の構文を、合否条件生成部２５０が有するプロパティの構文パターンに関するデータベース（検査式解釈情報）と照合して、合致するパターンを抽出する。

ステップ５３０では、合否条件生成部２５０が、ステップ５１０により解析されたプロパティの構文から、テストケースの合否判定に利用する論理式（判定式）を抽出する。また、合否条件生成部２５０が、実行経路解析部２３０からの制御フロー情報と、ステップ５２０にて判定されたプロパティのパターンとから、合否判定を行なうタイミングに関する情報を１ないし複数生成する。最終的に、合否条件生成部２５０が、これら論理式（判定式）と判定タイミングに関する情報とを組にすることにより、合否条件情報を作成する。以上の処理を実行し、ステップ５９０で処理を終了する。

次に、本実施例のテストケース生成システムで扱われる情報について説明する。以下のいくつかの情報については、「テーブル」構造を用いて説明するが、必ずしもテーブルによるデータ構造で表現されていなくても良く、他のデータ構造で表現されていても良い。そのため、データ構造に依存しないことを示すために、以下では、テーブル形式で表現されたデータを単に「情報」と呼ぶことがある。

図６は、プロパティの構文パターンに関するデータベースであるプロパティ解釈テーブル（検査式解釈情報）６００を示す。プロパティ解釈テーブル６００は、図５のステップ５１０において参照される情報である。プロパティ解釈テーブル６００は、プロパティを合否条件に変換するルールを含む。プロパティ解釈テーブル６００は、例えば、ハードディスク１１４などの記憶装置に格納されており、合否条件生成部２５０が、この情報を読み込んで上記の処理を行う。なお、プロパティ解釈テーブル６００に規定されている構文形を持つプロパティだけが、テストケース生成プログラム１２０で扱えることになる。

本実施例では、プロパティ解釈テーブル６００は、プロパティ構文形のパターン毎に付されるルール番号６０１と、プロパティ構文形６０２と、合否条件６０３と、各合否判定間の関係（１テストケース全体としての合否判定に用いる際の各合否判定間の関係）６０４とを構成項目として含む。本例において、プロパティ解釈テーブル６００で扱うプロパティは、ＬＴＬ（Ｌｉｎｅａｒ Ｔｅｍｐｏｒａｌ Ｌｏｇｉｃ）としている。

プロパティ解釈テーブル６００には、２つの時相論理式のパターンが記載されている。１つはＧ（ｅｘｐｒ）、もう１つはＦ（ｅｘｐｒ）である。Ｇは「いつも」を意味する時相演算子であり、Ｆは「将来」を意味する時相演算子である。またｅｘｐｒはここでは論理式を示す抽象表現である。ｅｘｐｒは合否判定に利用する論理式となる。

ルール番号６０１が「Ｒ１」のレコードでは、「Ｇ（ｅｘｐｒ）」がテストケースでは「（実行される）各関数の出入口でｅｘｐｒを判定する」ことに変換されるルールが記述されている。このようなルールは、ルールを記述する言語や、変換を行なうプログラム自体により表現されうる。また、ルール番号６０１が「Ｒ１」のレコードにおいて、ｅｘｐｒによる各判定の結果を、１つのテストケース全体としての合否判定に用いる際には、各判定結果の「ＡＮＤ」を取ることが指定されている。同様に、ルール番号６０１が「Ｒ２」のレコードでは、Ｆ（ｅｘｐｒ）が「各関数の出入口でｅｘｐｒを判定する」ことに変換され、かつ１テストケース全体としての合否判定には、各判定結果の「ＯＲ」を取ることが指定されている。

プロパティ解釈テーブル６００で指定される内容は、利用するテストシステムの機能に応じて変更しうる。例えばテストシステムが検査対象のプログラムの各ステートメントにて合否判定を実施できる場合には、Ｇ（ｅｘｐｒ）は「（実行される）各ステートメントの実行後にｅｘｐｒを判定する」と変換するように指定してもよい。また、プロパティ解釈テーブル６００は図６に示した以外の構文形を扱うこともできる。

図７は、検査対象とするサンプルプログラムのＣ言語で記述されたソースコード７１０と、それをＳＰＩＮのモデル記述言語Ｐｒｏｍｅｌａで書き表し、さらにテストケース生成用のアサーションａｓｓｅｒｔ（０）を追加した検証モデル７２０と、検証モデル７２０の検査をＳＰＩＮで実行して得られるトレースの一例７３０とを示している。

ソースコード７１０の関数は、検証モデル７２０ではｉｎｌｉｎｅマクロに変換されている。また、ソースコード７１０において、ＤＩ０は、デジタル入力のレジスタを表している。ソースコードにおける変数ａへのＤＩ０の代入は、検証モデル７２０では変数ａへの０か１の非決定的な代入として表現されている。トレース７３０は、変数ａに１が代入されるケースである。ただし説明を容易にするため、実際のトレース（反例）のフォーマットとは異なっている。なお、変数ａはテストケース生成プログラム１２０に対し入力として指定されているものとする。また、テストケース生成プログラム１２０には、プロパティとしてＧ（ｘ＜＝１）が指定されているものとする。

実行経路解析部２３０は、検証モデル７２０をパースしてＡＳＴを生成し、ＡＳＴを探索して、各ｉｎｌｉｎｅの中で他のｉｎｌｉｎｅを利用する記述を発見することで、もとのソースコード７１０の関数コールツリーを解析する。ここではｍａｉｎ→ｆｕｎｃ１という呼び出し関係がわかる。

図８と図９は、検証モデル７２０とトレース７３０を入力として、テストケース生成プログラム１２０が図３の処理を実行して出力するデータを示している。図８は、テスト実行制御内容情報８１０、及び合否条件情報８２０を示す。テスト実行制御内容情報８１０は、番号８１１と、テスト実行制御の処理の種類８１２と、その処理の内容８１３とを構成項目として含む。また、合否条件情報８２０は、番号８２１と、テスト実行制御の処理の種類（合否判定もテスト実行制御の一種としている）８２２と、その処理の内容８２３とを構成項目として含む。図９は、テストケース９００を示す。図８及び図９において、各情報の１行が１つのイベントや、テストシステムが実行する処理の１ステップを示している。なお、テストケース９００は、テストシステムに入力な形式に別途変換されるものとする。

制御内容生成部２４０の処理について説明する。制御内容生成部２４０は、トレース７３０を入力として受け取り、その後、トレース７３０を解析し、入力変数ａに１を代入している処理を抽出する。制御内容生成部２４０は、さらに、トレース７３０に記載された処理の位置（図７の７２０の１２行目に対応する）と制御フローの情報とから、この処理が関数ｍａｉｎの中で実施されていると判定する。この判定結果を用いて、制御内容生成部２４０は、テスト実行制御内容情報８１０を出力する。制御内容生成部２４０が出力するテスト実行制御内容情報８１０では、イベント列の長さは２となる。１つめのイベントは、関数ｍａｉｎに入ることを条件とするトリガである。２つめのイベントは、変数ａに１を代入する処理である。

次に、合否条件生成部２５０の処理について説明する。合否条件生成部２５０が、トレース７３０とプロパティＧ（ｘ＜＝１）を解析し、合否条件情報８２０を出力する。この際、合否条件生成部２５０は、プロパティ解釈テーブル６００に記載されたルールを参照する。この例では、合否条件生成部２５０が、プロパティ解釈テーブル６００においてルール「Ｒ１」を選択（参照）し、その結果、制御フローの情報に沿って、関数ｍａｉｎの入口、関数ｆｕｎｃ１の入口、関数ｆｕｎｃ１の出口、関数ｍａｉｎの出口でトリガを設定し、各トリガの直後に合否判定を設定する。すなわち、出力される合否条件情報８２０は、関数ｍａｉｎの入口、関数ｆｕｎｃ１の入口、関数ｆｕｎｃ１の出口、関数ｍａｉｎの出口でトリガを掛けて、各トリガが掛かった直後にｘ＜＝１を判定する内容となっている。なお、１テストケース全体としての合否判定に各判定結果のＡＮＤを取ることは、図８、図９では省略したが、合否条件情報８２０、テストケース９００にその情報が付与されている。すなわち、合否条件生成部２５０が、１テストケース全体としての合否判定に各判定結果のＡＮＤを取ることを示す情報を、合否条件情報に付加し、最終的に、テストケース生成部２６０は、上記情報を付加してテストケースを生成することになる。

次に、テストケース生成部２６０の処理について説明する。テストケース生成部２６０は、テスト実行制御内容情報８１０と合否条件情報８２０とから、テストケース９００を出力する。図９に示すように、テストケース９００は、ステップ番号９０１と、テスト実行制御の処理種類（合否判定もテスト実行制御の一種としている）９０２と、テスト実行制御の処理内容９０３とを構成項目として含む。ここで、テストケース生成部２６０が出力するテストケース９００では、テスト実行制御内容情報８１０と合否条件情報８２０が合成されて１つ情報になっている。テストケース生成部２６０は、関数ｍａｉｎの入口でのトリガが重複していると判定し、重複している部分を１つに集約する。

図８及び図９の例では、テスト実行の処理種類として、入力値設定、トリガ、合否判定が記されている。この他に割込みやタスク起動を示す記述が用意されているものとする。割込みやタスク起動の処理を実行するタイミングを取る場合にもトリガを利用できる。このトリガ条件には、利用するテストシステムがプログラムのステートメント単位でタイミングを指定できるのであれば、トレースにてプロセスが切り替わる直前に実行されるステートメントの実行完了時を指定すればよい。利用するテストシステムが関数の出入口を検出できる場合には、上記ステートメントの関数の入口と、さらにそこから所定時間の経過をトリガ条件にする方法がありうる。

以上により、プログラムの実行の各所でプロパティの論理式（ｘ＜＝１）が判定されるため、プロパティの「いつも」と同様の合否判定を実現することができる。関数の出入口のみで判定することは、モデル検査の各ステートメントでの判定を完全に再現してはいないが、それに準じた判定がなされる。また利用するテストシステムの機能に応じてプロパティ解釈テーブル６００のルールを変更することで、判定頻度をモデル検査と同等にすることもできる。

次に、プロパティの時相演算子が「将来」である場合について説明する。この例では、合否条件生成部２５０が、プロパティ解釈テーブル６００においてルール「Ｒ２」を選択（参照）し、制御フローの情報に沿って、トリガ及び合否判定を設定した合否条件情報を作成する。その後、テストケース生成部２６０が、この合否条件情報と、制御内容生成部２４０から出力されたテスト実行制御内容情報とから、テストケース９００を出力する。

より詳細には、入力されるプロパティの時相演算子が「将来」のときには、１テストケース全体としての合否判定に各判定結果のＯＲを取ることがテストケース９００にて指定されるほか、最後のイベントとして合否判定のトリガが追加される。ここで、テストケース生成プログラム１２０には、プロパティとしてＦ（ｘ＞１）が指定されているものとする。Ｆ（ｘ＞１）であれば、ｘ＞１を条件とするトリガがテストケース９００の最後に追加される。トリガのタイムアウト時間はテストケース生成プログラム１２０に設定されており、テストケース９００に付与される（図に記載無し）。論理式を条件とするトリガが実行されたか否かは、テストシステム２９０において合否条件と同様に判定および記録される。また、この判定結果は、テストシステム２９０において、１テストケース全体の合否判定にも利用される。以上により、プログラムの実行中に少なくとも１箇所以上でプロパティの論理式（ｘ＞１）が成立した場合にはそのことを検出できるため、プロパティの「将来」と同様の合否判定を実現することができる。

以上により、オブジェクトコードを検査する際に、合否基準として時相論理式を用いることができる。これにより「いつも」や「将来」といった時相演算子の表現を合否条件に取り入れることができる。また、モデル検査を応用したテストケース生成において合否基準に時相論理式を取り入れれば、オブジェクトコードに対してモデル検査を実施するのと同様の検査を実現することができる。これらにより、ソフトウェアの不具合低減とシステムの信頼性向上を達成することができる。

本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。上記実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることもできる。また、ある実施例の構成に他の実施例の構成を加えることもできる。また、各実施例の構成の一部について、他の構成を追加・削除・置換することもできる。

上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム等の情報は、何らかの記録装置あるいは記録媒体に格納することができる。また、図９で例示したようなデータ構造を有するテストケースのデータを、何らかの記録装置あるいは記録媒体に格納することができる。

１００ ：テストケース生成システム
１１０ ：コンピュータ
１１１ ：ＣＰＵ
１１３ ：ＲＯＭ
１１４ ：ハードディスク
１２０ ：テストケース生成プログラム
１３０ ：入力装置
１４０ ：表示装置
２００ ：ソースコード
２１０ ：検証モデル生成プログラム
２１５ ：検証モデル
２２０ ：実行経路探索プログラム
２２５ ：トレース群
２３０ ：実行経路解析部
２３５ ：時相論理式
２４０ ：制御内容生成部
２５０ ：合否条件生成部
２６０ ：テストケース生成部
２８０ ：テストケース群
２９０ ：テストシステム
６００ ：プロパティ解釈テーブル
７１０ ：ソースコード
７２０ ：検証モデル
７３０ ：トレース
８１０ ：テスト実行制御内容情報
８２０ ：合否条件情報
９００ ：テストケース

Claims (13)

1. 検査対象となるオブジェクトコードまたは実行可能形式ファイルのモデルから探索された実行経路情報から、テスト実行制御内容に関する情報を生成する制御内容生成部と、
   前記検査対象に対する、時間要素を含む検査式と、前記実行経路情報から、時間要素のない判定式とその判定式を実行するタイミングの組からなる合否条件に関する情報を生成する合否条件生成部と、
   前記テスト実行制御内容に関する情報と、前記合否条件に関する情報とから、前記検査式に対応する合否条件を有するテストケースを生成するテストケース生成部と、
   を備えることを特徴とするテストケース生成システム。
2. 請求項１に記載のテストケース生成システムにおいて、
   前記検査式の前記時間要素が「いつも」の意味のときに、前記合否条件生成部は、前記合否条件に関する情報に、前記合否条件の判定結果のＡＮＤを取ることを示す第１の情報を付加し、
   前記テストケース生成部は、前記第１の情報を付加して前記テストケースを生成することを特徴とするテストケース生成システム。
3. 請求項１に記載のテストケース生成システムにおいて、
   前記検査式の前記時間要素が「将来」の意味のときに、前記合否条件生成部は、前記合否条件に関する情報に、前記合否条件の判定結果のＯＲを取ることを示す第２の情報を付加し、
   前記テストケース生成部は、前記第２の情報を付加して前記テストケースを生成することを特徴とするテストケース生成システム。
4. 請求項１に記載のテストケース生成システムにおいて、
   前記検査式の前記時間要素が「将来」の意味のときに、前記テストケース生成部は、前記検査式に対応する前記合否条件のトリガが最後のイベントとして追加された前記テストケースを出力することを特徴とするテストケース生成システム。
5. 請求項１に記載のテストケース生成システムにおいて、
   前記合否条件生成部は、前記検査式を前記合否条件に変換するルールを含む検査式解釈情報を参照して、前記合否条件に関する情報を生成することを特徴とするテストケース生成システム。
6. 請求項５に記載のテストケース生成システムにおいて、
   前記検査式解釈情報は、前記検査式の構文形と、前記合否条件と、１つのテストケース全体で合否判定を行う際の合否条件間の関係とを構成項目として含むことを特徴とするテストケース生成システム。
7. 請求項１に記載のテストケース生成システムにおいて、
   前記モデルから制御フローの情報を解析する実行経路解析部をさらに備えることを特徴とするテストケース生成システム。
8. 請求項７に記載のテストケース生成システムにおいて、
   前記テストケース生成部は、前記制御フローの情報を用いて、前記テスト実行制御内容に関する情報と前記合否条件に関する情報とを整列することにより、前記テストケースを生成することを特徴とするテストケース生成システム。
9. 請求項７に記載のテストケース生成システムにおいて、
   前記制御内容生成部は、前記制御フローの情報を用いて、前記テスト実行制御内容に関する情報を生成することを特徴とするテストケース生成システム。
10. 請求項７に記載のテストケース生成システムにおいて、
    前記合否条件生成部は、前記制御フローの情報を用いて、前記合否条件に関する情報を生成することを特徴とするテストケース生成システム。
11. コンピュータに、検査対象となるオブジェクトコードまたは実行可能形式ファイルを検査する処理を実行させるために用いられるテストケースのデータ構造であって、テスト実行制御内容に関する情報と、時間要素のない判定式とその判定式を実行するタイミングの組からなる合否条件に関する情報と、を含むデータ構造を有するデータを記録したコンピュータ読み取り可能な記録媒体。
12. 請求項１１に記載のコンピュータ読み取り可能な記録媒体において、
    前記データ構造に、前記合否条件の判定結果のＡＮＤまたはＯＲを取ることを示す情報が付加されていることを特徴とするコンピュータ読み取り可能な記録媒体。
13. 請求項１２に記載のコンピュータ読み取り可能な記録媒体において、
    前記合否条件の判定結果のＯＲを取ることを示す情報が付加されている場合、前記データ構造において、前記合否条件のトリガが最後のイベントとして追加されていることを特徴とするコンピュータ読み取り可能な記録媒体。

Images