JPH02103644A - ソフトウエア・モジュール・テスト方法 - Google Patents
ソフトウエア・モジュール・テスト方法Info
- Publication number
- JPH02103644A JPH02103644A JP63256476A JP25647688A JPH02103644A JP H02103644 A JPH02103644 A JP H02103644A JP 63256476 A JP63256476 A JP 63256476A JP 25647688 A JP25647688 A JP 25647688A JP H02103644 A JPH02103644 A JP H02103644A
- Authority
- JP
- Japan
- Prior art keywords
- sut
- test
- module
- information
- data
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title description 48
- 238000012360 testing method Methods 0.000 claims abstract description 100
- 230000003993 interaction Effects 0.000 claims description 5
- 238000010998 test method Methods 0.000 claims 1
- 230000006870 function Effects 0.000 description 12
- 241001208007 Procas Species 0.000 description 5
- 230000004044 response Effects 0.000 description 4
- 238000011161 development Methods 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 238000004088 simulation Methods 0.000 description 3
- 238000012937 correction Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 101100489313 Caenorhabditis elegans sut-2 gene Proteins 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 235000008429 bread Nutrition 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000008676 import Effects 0.000 description 1
- 238000010348 incorporation Methods 0.000 description 1
- 238000012805 post-processing Methods 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 238000013102 re-test Methods 0.000 description 1
- 238000013522 software testing Methods 0.000 description 1
Landscapes
- Debugging And Monitoring (AREA)
Abstract
(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。
め要約のデータは記録されません。
Description
【発明の詳細な説明】
〔発明の技術分野〕
本発明はソフトウェアのテスト方法に関し、特にモジュ
ール単位でのテスト方法に関する。
ール単位でのテスト方法に関する。
ソフトウェアの信頼性を高めるための一つの手段として
、充分なテストを開発のライフサイクル中でできるだけ
早期に行うことが挙げられる。
、充分なテストを開発のライフサイクル中でできるだけ
早期に行うことが挙げられる。
ある程度以上大規模なソフトウェアは階層構造をなす多
くのモジュールから構成されている。このような構造を
有するソフトウェアのテストを行う手法として、トップ
ダウン法、ボトムアップ法、サンドインチ法、ビッグパ
ン法(big−bangtesting)などがある。
くのモジュールから構成されている。このような構造を
有するソフトウェアのテストを行う手法として、トップ
ダウン法、ボトムアップ法、サンドインチ法、ビッグパ
ン法(big−bangtesting)などがある。
トップダウン法は、最上位のモジュールを先ずテストし
、その後はその直下のモジュールをテストが終わったモ
ジュールに付加してテストを行うという手続きを最下位
のモジュールの付加・テストまで繰り返す。すなわち、
このテストが終了した時点で、全モジュールのインテグ
レーションも終わっている。
、その後はその直下のモジュールをテストが終わったモ
ジュールに付加してテストを行うという手続きを最下位
のモジュールの付加・テストまで繰り返す。すなわち、
このテストが終了した時点で、全モジュールのインテグ
レーションも終わっている。
ボトムアップ法は、トップダウン法とは逆に、最下位の
モジュールから始めて、上位のモジュールを付加しなが
らテストを進めるものである。
モジュールから始めて、上位のモジュールを付加しなが
らテストを進めるものである。
サンドインチ法は、トップダウン法とボトムアップ法の
折衷的なものであり、両方法を同時に進める。
折衷的なものであり、両方法を同時に進める。
これら3種類のテストにおいては、モジュールの作成と
テストを並行して行うためには、モジュールを作成する
順序が決まってしまう。例えば、トップダウン法では上
位のモジュールができない限り、下位のモジュールのテ
ストができない。そのため、一部のモジュールのスケジ
ュールの遅れが全体に影響しやすい。また、このように
インテグレーションとテストが同時進行する方法では、
インテグレーションが進んでくると大きくかつ複雑な動
作をするソフトウェアをテストすることになるので、障
害の発見やその切り分けが次第に困難になるという問題
がある。
テストを並行して行うためには、モジュールを作成する
順序が決まってしまう。例えば、トップダウン法では上
位のモジュールができない限り、下位のモジュールのテ
ストができない。そのため、一部のモジュールのスケジ
ュールの遅れが全体に影響しやすい。また、このように
インテグレーションとテストが同時進行する方法では、
インテグレーションが進んでくると大きくかつ複雑な動
作をするソフトウェアをテストすることになるので、障
害の発見やその切り分けが次第に困難になるという問題
がある。
これに対して、ビッグパン法では一つ一つのモジュール
について単体でテストを行うので、上述の開発スケジュ
ールの自由度や障害の発見・切り分けの問題は解消され
る。しかしながら、この方法には以下で説明するような
問題点があるため、多数のモジュールを含むソフトウェ
アの開発に適用するのには適さなかった。
について単体でテストを行うので、上述の開発スケジュ
ールの自由度や障害の発見・切り分けの問題は解消され
る。しかしながら、この方法には以下で説明するような
問題点があるため、多数のモジュールを含むソフトウェ
アの開発に適用するのには適さなかった。
ソフトウェアを構成するモジュールは上位側のモジュー
ルから呼び出され、また下位のモジュールを呼び出す、
すなわち他のモジュールと関連しながら動作している。
ルから呼び出され、また下位のモジュールを呼び出す、
すなわち他のモジュールと関連しながら動作している。
ビッグパン法ではモジュール単体でのテストを全てのモ
ジュールについて行うので、モジュール毎に当該モジュ
ールを直接呼び出すあるいはそれから呼び出されるモジ
ュールに代わるダミーのモジュール群等のテスト環境を
用意する必要がある。準備しなければならないテスト環
境はモジュール数が多くなると膨大なものとなり、テス
トに要するコストや時間が許容しかいはどのものになっ
てしまう。
ジュールについて行うので、モジュール毎に当該モジュ
ールを直接呼び出すあるいはそれから呼び出されるモジ
ュールに代わるダミーのモジュール群等のテスト環境を
用意する必要がある。準備しなければならないテスト環
境はモジュール数が多くなると膨大なものとなり、テス
トに要するコストや時間が許容しかいはどのものになっ
てしまう。
また、従来のモジュール・テストでは、そのモジュール
の機能の代用特性として、モジュール内部の制御の流れ
の径路や分岐に関する情報を取得するという、いわゆる
ホワイトボックス・テストが採用されることが多かった
。しかし、ホワイトボックス・テストでは制御の流れは
見えるが情報の流れは見えないので、必ずしも満足でき
るものではなかった。一方、従来のモジュールに対する
ブラックボックス・テストでは、上位側から被試験モジ
ュール(以下、SUTと称する)を呼び出したときのこ
のSUTからの応答を記録してそれを期待される応答と
比較していたが、SUTからのその下位側に対する呼び
出しに関する情報については特に記録する等の処理はな
されていなかった。そのため、SUTの挙動を外部から
観測して正しい動きをしているかを調べるブラックボッ
クス・テストとしては不充分なものであらた。
の機能の代用特性として、モジュール内部の制御の流れ
の径路や分岐に関する情報を取得するという、いわゆる
ホワイトボックス・テストが採用されることが多かった
。しかし、ホワイトボックス・テストでは制御の流れは
見えるが情報の流れは見えないので、必ずしも満足でき
るものではなかった。一方、従来のモジュールに対する
ブラックボックス・テストでは、上位側から被試験モジ
ュール(以下、SUTと称する)を呼び出したときのこ
のSUTからの応答を記録してそれを期待される応答と
比較していたが、SUTからのその下位側に対する呼び
出しに関する情報については特に記録する等の処理はな
されていなかった。そのため、SUTの挙動を外部から
観測して正しい動きをしているかを調べるブラックボッ
クス・テストとしては不充分なものであらた。
本発明は上述した従来技術の問題点を解消し、SUTの
環境に対する挙動をできるだけ多く調べることができる
モジュール・テスト方法を提供することを目的とする。
環境に対する挙動をできるだけ多く調べることができる
モジュール・テスト方法を提供することを目的とする。
また、このようなモジュール・テスト方法において、テ
スト環境を自動的に生成してテスト・コストを低減する
ことも目的とする。
スト環境を自動的に生成してテスト・コストを低減する
ことも目的とする。
本発明の一実施例によれば、上述の目的を達成するため
のモジュール・テスト方法が提供される。
のモジュール・テスト方法が提供される。
このため、実施例においては、SUTを呼び出すために
そのインターフェースへ渡された情報およびSUTが他
のモジュールに対して行う呼び出しの情報の両者をSU
Tの挙動を表す情報とする。
そのインターフェースへ渡された情報およびSUTが他
のモジュールに対して行う呼び出しの情報の両者をSU
Tの挙動を表す情報とする。
これによって、テスト環境から与えられるテスト・デー
タ等に対するSUTの挙動を従来のテスト方法よりも充
分に把握することができる。
タ等に対するSUTの挙動を従来のテスト方法よりも充
分に把握することができる。
更に、上述のようなテストのためのテスト環境を自動的
に作成′するため、この実施例ではSUTのインターフ
ェース情報(SUTが呼び出す下位のモジュールとのイ
ンターフェース情報も含む)からテスト・ドライバ(テ
スト環境のうちのSUTを呼び出す側)とスタブ(SU
Tから呼び出される側)を自動的に作成する。シミュレ
ート・モードではS U Tを実際に動作させる代わり
に、SUTとテスト環境との間の入出力や他のモジュー
ルの呼び出し等の相互作用のテスト・データ(インター
フェースを介してSUTへ与える値−3UTへの入力)
および期待データ(StJTがインターフェースを介し
て外部へ渡す値=SUTからの出力)を使用者が与える
。実行モードでは先に与えられたテスト・データに基づ
いてSUTを実行し、そのテスト環境に対する作用(出
力、他のモジュールの呼び出し等)をやはり先に与えら
れた期待データと比較する。期待データと異なる場合に
はSUTを修正したのち再度実行モードで動作させると
いうサイクルを、一致がとられるまで繰り返す。
に作成′するため、この実施例ではSUTのインターフ
ェース情報(SUTが呼び出す下位のモジュールとのイ
ンターフェース情報も含む)からテスト・ドライバ(テ
スト環境のうちのSUTを呼び出す側)とスタブ(SU
Tから呼び出される側)を自動的に作成する。シミュレ
ート・モードではS U Tを実際に動作させる代わり
に、SUTとテスト環境との間の入出力や他のモジュー
ルの呼び出し等の相互作用のテスト・データ(インター
フェースを介してSUTへ与える値−3UTへの入力)
および期待データ(StJTがインターフェースを介し
て外部へ渡す値=SUTからの出力)を使用者が与える
。実行モードでは先に与えられたテスト・データに基づ
いてSUTを実行し、そのテスト環境に対する作用(出
力、他のモジュールの呼び出し等)をやはり先に与えら
れた期待データと比較する。期待データと異なる場合に
はSUTを修正したのち再度実行モードで動作させると
いうサイクルを、一致がとられるまで繰り返す。
第1図に本発明の一実施例を概念的に示す。また、これ
と比較するために従来方法に基づいた場合のモジュール
・テストを第3図に概念的に示す。
と比較するために従来方法に基づいた場合のモジュール
・テストを第3図に概念的に示す。
第3図の従来例において、テスト担当者301は自分で
テスト・ドライバおよびスタブ303を作成し、これを
5tJT305とともにコンパイル/リンクして実行可
能なテスト・プログラム307を作成する。次にテスト
・プログラム307にテスト・データ309を与えて実
行させる。テスト・プログラム307中にリンクされて
いるテスト・ドライバは同じくそこにリンクされている
SUTからの出力(関数の戻り値や参照渡しパラメータ
・グローバル変数への書き込み等)を実行結果としてフ
ァイルへ書き込む。テスト担当者311はこの実行結果
を期待データと照合し、不一致があれば5UT305に
不具合があるものとしてデバッグを行う。デバッグ完了
後、上述の過程を実行結果と期待データの一致がとれる
まで繰り返す。
テスト・ドライバおよびスタブ303を作成し、これを
5tJT305とともにコンパイル/リンクして実行可
能なテスト・プログラム307を作成する。次にテスト
・プログラム307にテスト・データ309を与えて実
行させる。テスト・プログラム307中にリンクされて
いるテスト・ドライバは同じくそこにリンクされている
SUTからの出力(関数の戻り値や参照渡しパラメータ
・グローバル変数への書き込み等)を実行結果としてフ
ァイルへ書き込む。テスト担当者311はこの実行結果
を期待データと照合し、不一致があれば5UT305に
不具合があるものとしてデバッグを行う。デバッグ完了
後、上述の過程を実行結果と期待データの一致がとれる
まで繰り返す。
これに対して、第1図に示す本発明の一実施例では、テ
スト担当者101はテスト・ドライバやスタブを自分で
作成する代わりに、5UT109のインターフェース情
報103をドライバ・スタブ自動生成プログラム105
へ与える。インターフェース情報103はSUTを呼び
出す際のパラメータのリスト、SUTがどのようなグロ
ーバル変数を使用するか、またSUTが呼び出すモジュ
ールのパラメータのリスト等を含んでおり、SUTとそ
の上位および下位のモジュールとの間で行われる入出力
のインターフェースを記述するものである。
スト担当者101はテスト・ドライバやスタブを自分で
作成する代わりに、5UT109のインターフェース情
報103をドライバ・スタブ自動生成プログラム105
へ与える。インターフェース情報103はSUTを呼び
出す際のパラメータのリスト、SUTがどのようなグロ
ーバル変数を使用するか、またSUTが呼び出すモジュ
ールのパラメータのリスト等を含んでおり、SUTとそ
の上位および下位のモジュールとの間で行われる入出力
のインターフェースを記述するものである。
次に自動生成されたテスト・ドライバおよびスタブ10
7と5UT109をコンパイル・リンクしてテスト・プ
ログラム111を作成する。テスト・プログラム111
の内部の動作の概略を説明する図面を第2図に示す。テ
スト・プログラム110は第3図に示した従来技術とは
異なり、シミュレート・モードと実行モードの2つの動
作モードを持つ。
7と5UT109をコンパイル・リンクしてテスト・プ
ログラム111を作成する。テスト・プログラム111
の内部の動作の概略を説明する図面を第2図に示す。テ
スト・プログラム110は第3図に示した従来技術とは
異なり、シミュレート・モードと実行モードの2つの動
作モードを持つ。
シミュレート・モードではテスト・プログラム111は
第2図(a)で説明されるような動作をする。同図にお
いて、テスト・ドライバ201はテスト担当者に対して
5UT109” (コンパイル・リンクされたSUTと
いうことを示すため、゛を参照番号に付加する)を呼び
出すためのSUTへの入力、およびSUTがその実行結
果として戻す出力の入力を要求する。テスト担当者はS
UTへの入力のデータの要求に対しては対応するテスト
・データ113を、またSUTからの出力のデータの要
求に対しては期待データ115を例えばコンソールから
与える。これらはそれぞれテスト・データ・ファイル1
19と期待データ・ファイル117へ書き込まれる。
第2図(a)で説明されるような動作をする。同図にお
いて、テスト・ドライバ201はテスト担当者に対して
5UT109” (コンパイル・リンクされたSUTと
いうことを示すため、゛を参照番号に付加する)を呼び
出すためのSUTへの入力、およびSUTがその実行結
果として戻す出力の入力を要求する。テスト担当者はS
UTへの入力のデータの要求に対しては対応するテスト
・データ113を、またSUTからの出力のデータの要
求に対しては期待データ115を例えばコンソールから
与える。これらはそれぞれテスト・データ・ファイル1
19と期待データ・ファイル117へ書き込まれる。
次にテスト・ドライバ201はテスト・ドライバの一部
分であるダミー・モジュール201−1に制御を移す。
分であるダミー・モジュール201−1に制御を移す。
ここでは、5UT109’がどのモジュールを呼び出す
かについてテスト担当者への問い合わせが行われる。最
初に呼び出されるべきモジュールをテスト担当者が指定
すると、ダミ−・モジュールはそれに対応するスタブ2
03〜207を呼び出す。呼び出されたスタブは、シミ
ュレート・モードでは、丁度テスト・ドライバ201が
先に行ったように、SUTから呼び出されるべきモジュ
ールへ渡されるべきデータ(SUTからの出力データ)
とそのときそのモジュールがSUTへ戻すデータ(SU
Tへの入力データ)をテスト担当者がコンソール等から
与えるように要求し、その入力が終わるとダミー・モジ
ュールへ制御を戻す。このとき、呼び出されるべきモジ
ュールを識別する情報およびSUTからそのモジュール
へ渡されるべきものとしてテスト担当者から与えられた
データは期待データ・ファイル117へ、またこのモジ
ュールがSUTへ渡すものとして与えられたデータはテ
スト・データ・ファイル119へ書き込まれる。
かについてテスト担当者への問い合わせが行われる。最
初に呼び出されるべきモジュールをテスト担当者が指定
すると、ダミ−・モジュールはそれに対応するスタブ2
03〜207を呼び出す。呼び出されたスタブは、シミ
ュレート・モードでは、丁度テスト・ドライバ201が
先に行ったように、SUTから呼び出されるべきモジュ
ールへ渡されるべきデータ(SUTからの出力データ)
とそのときそのモジュールがSUTへ戻すデータ(SU
Tへの入力データ)をテスト担当者がコンソール等から
与えるように要求し、その入力が終わるとダミー・モジ
ュールへ制御を戻す。このとき、呼び出されるべきモジ
ュールを識別する情報およびSUTからそのモジュール
へ渡されるべきものとしてテスト担当者から与えられた
データは期待データ・ファイル117へ、またこのモジ
ュールがSUTへ渡すものとして与えられたデータはテ
スト・データ・ファイル119へ書き込まれる。
ダミー・モジュール201−1へ制御が戻ると、その次
に呼び出されるべきモジュールの指定の要求がテスト担
当者に対してなされ、上述のような動作が繰り返される
。このような手順を呼び出されるべきモジュール全てに
ついて行った後、モジュール呼び出しに関する情報の入
力の終了をダミー・モジュールへ通知する。これでシミ
ュレート・モードでの動作が完了する。
に呼び出されるべきモジュールの指定の要求がテスト担
当者に対してなされ、上述のような動作が繰り返される
。このような手順を呼び出されるべきモジュール全てに
ついて行った後、モジュール呼び出しに関する情報の入
力の終了をダミー・モジュールへ通知する。これでシミ
ュレート・モードでの動作が完了する。
次に、第2図(b)に示すような実行モードに入る。こ
のモードでは、5UT109’に入力すべきデータをテ
スト・ドライバ201がテスト・データ・ファイル11
9から読み出して設定し、実際に5UT109’へ制御
を渡す。SUTの動作中に下位のモジュールを呼び出す
ことになると、SUTからはその呼び出すべきモジュー
ルと全く同じものに見える対応するスタブ203〜20
7へ制御が移る。
のモードでは、5UT109’に入力すべきデータをテ
スト・ドライバ201がテスト・データ・ファイル11
9から読み出して設定し、実際に5UT109’へ制御
を渡す。SUTの動作中に下位のモジュールを呼び出す
ことになると、SUTからはその呼び出すべきモジュー
ルと全く同じものに見える対応するスタブ203〜20
7へ制御が移る。
実行モードで呼び出されたスタブは、SUTから渡され
たデータを実行結果ファイル121へ書き込むとともに
、SUTへ渡すべきデータをテスト・データ・ファイル
119から読み出して所要のパラメータや変数等への設
定を行った後に、SUTへ制御を移す。
たデータを実行結果ファイル121へ書き込むとともに
、SUTへ渡すべきデータをテスト・データ・ファイル
119から読み出して所要のパラメータや変数等への設
定を行った後に、SUTへ制御を移す。
このような5UT109’の内部動作および他のモジュ
ールの呼び出しが全て終了すると、制御がテスト・ドラ
イバ201へ戻る。テスト・ドライバは必要な後処理を
行った後、その動作を停止するか、あるいは制御を次の
段階の処理を行うルーチンへ移す。
ールの呼び出しが全て終了すると、制御がテスト・ドラ
イバ201へ戻る。テスト・ドライバは必要な後処理を
行った後、その動作を停止するか、あるいは制御を次の
段階の処理を行うルーチンへ移す。
もし5UT109”が期待通りの動作をしたのであれば
、この時点での期待データ・ファイル117と実行結果
ファイル121の内容は同一になっているはずであるの
で、両者を比較することにより、5UT109が正しく
作成されているか否かが判断できる(第1図123)。
、この時点での期待データ・ファイル117と実行結果
ファイル121の内容は同一になっているはずであるの
で、両者を比較することにより、5UT109が正しく
作成されているか否かが判断できる(第1図123)。
あるいは、この比較を完全一致か否かではなく、必要に
応じである範囲内に収まっているか否かの判定としても
よい。
応じである範囲内に収まっているか否かの判定としても
よい。
以下ではSUTが一部仕様の拡張されたPa5ca 1
の手続きあるいは関数であるとして、更に具体的な説明
を行う。勿論能の言語に対しても本発明は同様に適用し
うるし、またモジュールとしては、個々の手続き/関数
以外の別の独立してテストしうる単位でも良いことを注
意しておく。
の手続きあるいは関数であるとして、更に具体的な説明
を行う。勿論能の言語に対しても本発明は同様に適用し
うるし、またモジュールとしては、個々の手続き/関数
以外の別の独立してテストしうる単位でも良いことを注
意しておく。
SOTとして以下の手続き頭部を持った手続きを考える
。
。
procedure GetADC12(pinLis
t : PinListType;offset :
integer; resultNun+ : int
egerHvar resultArray :
Re5ultArrayType);ここで、Pin
ListTypeはユーザが定義した型であって、配列
やポインタ型以外のものである。また、Re5ultA
rrayTypeはやはりユーザがrea lの配列と
して定義している型である。また、3番目のパラメータ
resultNu−は配列resultArrayのサ
イズを表している。
t : PinListType;offset :
integer; resultNun+ : int
egerHvar resultArray :
Re5ultArrayType);ここで、Pin
ListTypeはユーザが定義した型であって、配列
やポインタ型以外のものである。また、Re5ultA
rrayTypeはやはりユーザがrea lの配列と
して定義している型である。また、3番目のパラメータ
resultNu−は配列resultArrayのサ
イズを表している。
この手続きGetADC12のインターフェース情報(
含インターフェース上で使用されている型の定義情報な
ど)をドライバ・スタブ自動生成プログラムに通すこと
によって、モジュール・テスト用のテスト・ドライバお
よびもしこの手続きが他のモジュールを呼び出す場合に
はそのモジュールの代用となるスタブが自動的に生成さ
れる。表1にこの手続きに対して生成されるテスト・ド
ライバの主要部である手続きのソース・コードを示す。
含インターフェース上で使用されている型の定義情報な
ど)をドライバ・スタブ自動生成プログラムに通すこと
によって、モジュール・テスト用のテスト・ドライバお
よびもしこの手続きが他のモジュールを呼び出す場合に
はそのモジュールの代用となるスタブが自動的に生成さ
れる。表1にこの手続きに対して生成されるテスト・ド
ライバの主要部である手続きのソース・コードを示す。
1:PROCEDtlRE
表 1
proc539;
EGIN
pros+ptln(″====GetA口Cl2==
==’);pfistReadln (’pinList’、 PIist[1]);1va
rReadln (’offset’、 1var[1]);1var
Readln (’resultNus+ber’、 1var[2
コ);IF simulateMode <>
I THENGetADC12(P1istL1]、
1var[1]。
==’);pfistReadln (’pinList’、 PIist[1]);1va
rReadln (’offset’、 1var[1]);1var
Readln (’resultNus+ber’、 1var[2
コ);IF simulateMode <>
I THENGetADC12(P1istL1]、
1var[1]。
1var[2]、 rvararray[13) ;I
F simulateMode = I TH
ENdums+yModule; IF simulateMode = I T
HENrvararrayReadIn (’ res
uI tArray15: 1var[2]、 rvararray(−1]);r
vararrayWritelnResult(’re
sultArray’、 1var[21゜rvar
array(月): 16: END。
F simulateMode = I TH
ENdums+yModule; IF simulateMode = I T
HENrvararrayReadIn (’ res
uI tArray15: 1var[2]、 rvararray(−1]);r
vararrayWritelnResult(’re
sultArray’、 1var[21゜rvar
array(月): 16: END。
なお、このようなテスト・ドライバを生成する際、SU
TであるGetADC12を呼び出すためのインターフ
ェースを指示するため、表2に示すような形のパラメー
タ情報をドライバ・スタブ自動生成プログラムに与える
。
TであるGetADC12を呼び出すためのインターフ
ェースを指示するため、表2に示すような形のパラメー
タ情報をドライバ・スタブ自動生成プログラムに与える
。
539 GetADC12
PinList 1
offset T
resultNua+ T
resultArray 0
表2
procedure PASCAL 4a
tom PinListType Btt)lIIinteger atO@ integer array real 316384表2に示す
パラメータ情報において、 最初の行 に置かれている項目は左からSUTに与えられた識別番
号、SUTの名前、SUTが手続きが関数かを示す識別
子(もし関数ならここはfunctionとなる)、S
UTの記述言語、パラメータの個数である。2行目から
5行目は個々のパラメータに関する情報である。左から
パラメータであることを示す識別子(もし値の引き渡し
が手続き頭部中のパラメータ以外に、グローバル変数を
介して行われる場合はここがPではなくGとなっている
行もここに含まれる)、手続き頭部でこのパラメータが
何番目に位置するかを示すシーケンス番号、このパラメ
ータを介して値を入力するのか(T)それとも値を出力
するのか(0)を示す識別子、パラメータの名前、この
パラメータが単一の変数か(atom)配列か(arr
ay )それともポインタが(pointer )を示
す識別子、パラメータ(配列の場合はその要素)の型で
ある。パラメータが任意のサイズをとることができる配
列の場合は更にその配列の実行時のサイズを指定する数
がパラメータ・リストの何番目に置かれているかを示す
指示子および配列の最大サイズを示す指示子が置かれる
。
tom PinListType Btt)lIIinteger atO@ integer array real 316384表2に示す
パラメータ情報において、 最初の行 に置かれている項目は左からSUTに与えられた識別番
号、SUTの名前、SUTが手続きが関数かを示す識別
子(もし関数ならここはfunctionとなる)、S
UTの記述言語、パラメータの個数である。2行目から
5行目は個々のパラメータに関する情報である。左から
パラメータであることを示す識別子(もし値の引き渡し
が手続き頭部中のパラメータ以外に、グローバル変数を
介して行われる場合はここがPではなくGとなっている
行もここに含まれる)、手続き頭部でこのパラメータが
何番目に位置するかを示すシーケンス番号、このパラメ
ータを介して値を入力するのか(T)それとも値を出力
するのか(0)を示す識別子、パラメータの名前、この
パラメータが単一の変数か(atom)配列か(arr
ay )それともポインタが(pointer )を示
す識別子、パラメータ(配列の場合はその要素)の型で
ある。パラメータが任意のサイズをとることができる配
列の場合は更にその配列の実行時のサイズを指定する数
がパラメータ・リストの何番目に置かれているかを示す
指示子および配列の最大サイズを示す指示子が置かれる
。
なお、表2に示すような情報を人間が作って与える代わ
りに、被試験副プログラム(SUT)の副プログラム頭
部の構文解析などを行うことにより、それに相当する情
報をドライバ・スタブ自動生成プログラム自身がSUT
から抽出してもよい。
りに、被試験副プログラム(SUT)の副プログラム頭
部の構文解析などを行うことにより、それに相当する情
報をドライバ・スタブ自動生成プログラム自身がSUT
から抽出してもよい。
なお、これを行う際には、ユーザが定義した型やグロー
バル変数等に関する情報はSOTの外部にあるので、こ
れらの外部定義情報だけを含んだダミーのプログラム中
にSOTを埋め込んだ形のものをドライバ・スタブ自動
生成プログラムに与えたりあるいはそのような情報だけ
を表2のような形で与える等の方法を用いることができ
る。
バル変数等に関する情報はSOTの外部にあるので、こ
れらの外部定義情報だけを含んだダミーのプログラム中
にSOTを埋め込んだ形のものをドライバ・スタブ自動
生成プログラムに与えたりあるいはそのような情報だけ
を表2のような形で与える等の方法を用いることができ
る。
上述のように、ドライバ・スタブ自動生成プログラムは
スタブの自動生成も行う。SUTであるGetADC1
2が、その頭部が以下のようになっている2つの副プロ
グラムProcA 、 FuncBを呼び出すものとす
る: procedure ProcA(paraml、pa
ram2:integer);function
FuncB(param3:integer):rea
l;このとき、SUTの場合と同様に例えば表3に示す
ようなパラメータ情報を与える。
スタブの自動生成も行う。SUTであるGetADC1
2が、その頭部が以下のようになっている2つの副プロ
グラムProcA 、 FuncBを呼び出すものとす
る: procedure ProcA(paraml、pa
ram2:integer);function
FuncB(param3:integer):rea
l;このとき、SUTの場合と同様に例えば表3に示す
ようなパラメータ情報を与える。
$ 601
pH
2T
表3
ProcA procedure PASCA
L 2paraml atom integer
paraw2 atom integer宰602
FuncB function PASCA
L IP 1 1 paraIII3 ato
m integerP OOFuncB atom
realここで、FuncBのパラメータ情報の3
行目でそのシーケンス番号が0であるのは、これがこの
関数の戻り値であることを示すためである。GetAD
C12のパラメータ情報の与え方に関して述べたように
、スタブを作成するための情報についてもこのような表
の形ではなく、例えば副プログラム頭部だけをSUTの
ソースコードファイル中に書き込む等してもよい。
L 2paraml atom integer
paraw2 atom integer宰602
FuncB function PASCA
L IP 1 1 paraIII3 ato
m integerP OOFuncB atom
realここで、FuncBのパラメータ情報の3
行目でそのシーケンス番号が0であるのは、これがこの
関数の戻り値であることを示すためである。GetAD
C12のパラメータ情報の与え方に関して述べたように
、スタブを作成するための情報についてもこのような表
の形ではなく、例えば副プログラム頭部だけをSUTの
ソースコードファイル中に書き込む等してもよい。
このようにパラメータ情報を与えることによりスタブが
生成される。FuncB用のスタブの主要部の例を表4
に示す。なお、ProcAについて生成されるスタブも
同様であるので、その具体例は省略する。
生成される。FuncB用のスタブの主要部の例を表4
に示す。なお、ProcAについて生成されるスタブも
同様であるので、その具体例は省略する。
表4
FUCNCTION FuncB(param3 :
integer) : real;AR ReturnValue : real;BEGIN promptIn (’ ====FuncB====
’ ) ;IP (simulateMode <>
1) THEN BEGINivarWriteRe
sult(’param3’、 para+*3);E
ND ELSE BEGIN ivarReadln(’param3″、 par
am3):1varWriteResult(’par
as+3’、 param3);END 。
integer) : real;AR ReturnValue : real;BEGIN promptIn (’ ====FuncB====
’ ) ;IP (simulateMode <>
1) THEN BEGINivarWriteRe
sult(’param3’、 para+*3);E
ND ELSE BEGIN ivarReadln(’param3″、 par
am3):1varWriteResult(’par
as+3’、 param3);END 。
rvarReadln(’ReturnVarRetu
rnValue); FuncB := ReturnValue; END。
rnValue); FuncB := ReturnValue; END。
また上述のようなインターフェース情報に基づいて生成
されるテスト ドライバの別の一部分を 構成するダミー・モジュールは例えば以下の表5のよう
になる。
されるテスト ドライバの別の一部分を 構成するダミー・モジュールは例えば以下の表5のよう
になる。
表
procedure dun+wyModule;AR
procID :
integer;
BEGIN
EPEAT
ivarReadln
(’Dummy
odule
No。
9′
proclD);
ASE
procID 0F
601 :
ProcA (ivar[1]+
1var[2J);
602 : rvar[1] := func
B(ivar(1コ);0THERWISE : IF proclD > OTHEN promptln(’ Wrong nu++ber!’); END。
B(ivar(1コ);0THERWISE : IF proclD > OTHEN promptln(’ Wrong nu++ber!’); END。
UNTIL proclD <= 0;END。
なお、これらインターフェース情報を用いてテスト・ド
ライバおよびテスト・スタブを自動生成すること自体は
コンパイラ、インタープリタ、トランスレータにおける
構文解析、解釈、コード生成等の技術そのものであって
当業者にとっては周知の事項であるので、テスト・ドラ
イバ・スタブ自動生成プログラムの実現手法についての
説明は省略する。
ライバおよびテスト・スタブを自動生成すること自体は
コンパイラ、インタープリタ、トランスレータにおける
構文解析、解釈、コード生成等の技術そのものであって
当業者にとっては周知の事項であるので、テスト・ドラ
イバ・スタブ自動生成プログラムの実現手法についての
説明は省略する。
以下では、このようにして生成されたテスト・ドライバ
、スタブを使用してテストを行う手順を上述の表を参照
して説明する。
、スタブを使用してテストを行う手順を上述の表を参照
して説明する。
表1のコードで、シミュレート・モードのときはグロー
バル変数s imu la teModeの値を1にセ
ットし、実行モードのときには1以外にセットする。
バル変数s imu la teModeの値を1にセ
ットし、実行モードのときには1以外にセットする。
このセット動作はテスト・ドライバ中の表1に示した手
続きproc539の外側にある部分で行う。
続きproc539の外側にある部分で行う。
表1の行3の手続きpromptInは、そのパラメー
タの文字列および復帰/改行コードを期待データ・ファ
イルへ格納する。
タの文字列および復帰/改行コードを期待データ・ファ
イルへ格納する。
行4の手続きplistReadlnはSUTであるG
etADC12の最初のパラメータであるpinLis
tの取り込みに関するものである。この手続きは、その
最初のパラメータを含むプロンプト: pinList ? をコンソールへ出力して(シミュレート・モードでは)
テスト担当者にどのテスト・データを入力すべきかを指
示した後、標準入力からの入力を型がPinLisTy
peである2番目のパラメータにセットする。標準入力
は、シミュレート・モードではコンソールへ、また実行
モードではテスト・データ・ファイルへ接続されている
。また、1番目のパラメータの文字列、および2番目の
パラメータにセットされた値の文字列表現が出力される
。なおシミュレート・モードにおいては、1番目のパラ
メータの文字列および2番目のパラメータにセットされ
たデータの文字列表現は同時にテスト・データ・ファイ
ルにも書き込まれる。
etADC12の最初のパラメータであるpinLis
tの取り込みに関するものである。この手続きは、その
最初のパラメータを含むプロンプト: pinList ? をコンソールへ出力して(シミュレート・モードでは)
テスト担当者にどのテスト・データを入力すべきかを指
示した後、標準入力からの入力を型がPinLisTy
peである2番目のパラメータにセットする。標準入力
は、シミュレート・モードではコンソールへ、また実行
モードではテスト・データ・ファイルへ接続されている
。また、1番目のパラメータの文字列、および2番目の
パラメータにセットされた値の文字列表現が出力される
。なおシミュレート・モードにおいては、1番目のパラ
メータの文字列および2番目のパラメータにセットされ
たデータの文字列表現は同時にテスト・データ・ファイ
ルにも書き込まれる。
行5.6の手続き1varRead Inも、取り扱う
変数の型がintegerである点を除いては、pli
stReadlnと全く同様の動作であり、GetAD
Cの2番目、3番目のパラメータの値の取り込みを行う
。他のxxxReadlnという名前の手続きも同様の
動作をする。なお、配列について同様の動作を行う手続
きrvararrayRead Inでは、その2番目
のパラメータで値が取り込まれる配列のサイズを指定す
る。
変数の型がintegerである点を除いては、pli
stReadlnと全く同様の動作であり、GetAD
Cの2番目、3番目のパラメータの値の取り込みを行う
。他のxxxReadlnという名前の手続きも同様の
動作をする。なお、配列について同様の動作を行う手続
きrvararrayRead Inでは、その2番目
のパラメータで値が取り込まれる配列のサイズを指定す
る。
シミュレート・モードの場合は行12でダミー・モジュ
ールdus++syModuleが呼ばれ、上述のよう
に、SUTから呼び出される下位のモジュールの識別番
号の入力を要求し、その指定されたモジュールに対応す
るスタブを呼び出してそのモジュールに期待値データお
よびテスト・データの収集・蓄積を行わせる。このdu
mmyModuleの動作、およびシミュレート・モー
ドにおけるスタブの動作は夫々表4、表5から明らかで
ある。
ールdus++syModuleが呼ばれ、上述のよう
に、SUTから呼び出される下位のモジュールの識別番
号の入力を要求し、その指定されたモジュールに対応す
るスタブを呼び出してそのモジュールに期待値データお
よびテスト・データの収集・蓄積を行わせる。このdu
mmyModuleの動作、およびシミュレート・モー
ドにおけるスタブの動作は夫々表4、表5から明らかで
ある。
また、SUTからの出力については、シミュレート・モ
ードでは行14でその出力(ここでは参照渡しされた4
番目のパラメータである配列中にGetADC12が書
き込むデータ)となるはずのデータの入力をテスト担当
者に要求する。これにより与えられたデータを行15で
パラメータ名とともに期待データ・ファイルへ書き込む
。
ードでは行14でその出力(ここでは参照渡しされた4
番目のパラメータである配列中にGetADC12が書
き込むデータ)となるはずのデータの入力をテスト担当
者に要求する。これにより与えられたデータを行15で
パラメータ名とともに期待データ・ファイルへ書き込む
。
シミュレート・モードの動作は以上の通りである。なお
、何通りかのテスト・データを一度にセットすることも
、表1の手続きproc539を必要な回数だけ繰り返
す等すれば簡単にできる。
、何通りかのテスト・データを一度にセットすることも
、表1の手続きproc539を必要な回数だけ繰り返
す等すれば簡単にできる。
上述のようにテスト・データおよび期待データの蓄積が
終わった後、実行モードでテスト・プログラムを動作さ
せる。
終わった後、実行モードでテスト・プログラムを動作さ
せる。
このモードでは、表1の行1において、このSUTが試
験されたことを示すためpromptInにより文字列
GetADC12を実行結果ファイルへ格納する。
験されたことを示すためpromptInにより文字列
GetADC12を実行結果ファイルへ格納する。
その後、行4〜行6により、先にテスト・データ・ファ
イルにセットされたテスト・データが読み出され、行9
でこれらの値が実パラメータとしてセットされたGet
ADC12が実際に呼び出される。
イルにセットされたテスト・データが読み出され、行9
でこれらの値が実パラメータとしてセットされたGet
ADC12が実際に呼び出される。
GetADC12からの出力(resultArray
)は行15で実行結果ファイルへ記憶される。
)は行15で実行結果ファイルへ記憶される。
実行モードでGetADC12が下位のモジュールを呼
び出そうとすると、実際にはそれに対応するスタブが呼
び出される。実行モードにおけるスタブの動作は表4か
られかるように、引き渡されたデータ(パラメータや、
場合によってはグローバル変数等)を実行結果ファイル
へ記憶するものである。
び出そうとすると、実際にはそれに対応するスタブが呼
び出される。実行モードにおけるスタブの動作は表4か
られかるように、引き渡されたデータ(パラメータや、
場合によってはグローバル変数等)を実行結果ファイル
へ記憶するものである。
また、SUTであるGetADC12へ入力すべき値(
ここでは関数FuncBO値)をテスト・データ・ファ
イルから読み出してセットすることも行われる。
ここでは関数FuncBO値)をテスト・データ・ファ
イルから読み出してセットすることも行われる。
SUTへ入力すべき値は、グーパル変数や参照渡しのパ
ラメータによって引き渡すこともあるが、その場合の値
のセットのやり方も同様である。
ラメータによって引き渡すこともあるが、その場合の値
のセットのやり方も同様である。
以上のようにして実行モードの動作の終了後、期待デー
タ・ファイルと実行結果ファイルを比較することにより
、SUTが期待通りの動作をしているか否かがわかる。
タ・ファイルと実行結果ファイルを比較することにより
、SUTが期待通りの動作をしているか否かがわかる。
なお、全ての実行動作が終了した後に比較する代わりに
、個々の実行結果データが得られる毎に比較を行っても
よい。
、個々の実行結果データが得られる毎に比較を行っても
よい。
比較の結果不一致があれば、SUTに修正を加える。こ
こでSUTのインターフェースに変更がない限り、次回
のモジュール・テストに必要なことは、新しいSUTを
コンパイルし、以前のテスト・ドライバおよびスタブと
リンクしたあと、既に作成されているテスト・データ・
ファイルおよび期待データ・ファイルを用いて直ちに実
行モードでテスト・プログラムを走らせることだけであ
る。これを期待データと実行結果の一致がとれるまで繰
り返すことにより、テストが完了する。
こでSUTのインターフェースに変更がない限り、次回
のモジュール・テストに必要なことは、新しいSUTを
コンパイルし、以前のテスト・ドライバおよびスタブと
リンクしたあと、既に作成されているテスト・データ・
ファイルおよび期待データ・ファイルを用いて直ちに実
行モードでテスト・プログラムを走らせることだけであ
る。これを期待データと実行結果の一致がとれるまで繰
り返すことにより、テストが完了する。
以上説明したように、本発明によれば、SUT自体は何
ら変更せずに、その上位側に加えて下位側のインターフ
ェースから見た挙動も観測できるので、より完全なモジ
ュール・テストを行うことができる。更に、テスト・ド
ライバおよびスタブの自動生成により、従来困難と考え
られていた、大規模なプログラムのモジュール単位のテ
ストが容易に行えるようになる。また、テスト・プログ
ラムをシミュレーション・モードで動作させている間に
それからの質問に順番に答えて必要なデータを入力して
いくことにより、これら入力されたデータをテスト・デ
ータ・ファイルと期待データ・ファイルに自動的に振り
分けて夫々正しい順序で書き込むため、これらのデータ
の入力間違いが低減される。また、両ファイルを一度作
っておけば、SUTの修正とテストを繰り返す際に同じ
ものを毎回使用できるので、再テストを自動的に行うこ
とができる。再テストを行うことにより、不具合が正し
く修正されたかをチエツクするのみならず、その修正が
他の機能に影響を与えていないかも検査できる。これに
よりソフトウェアの信頼性が全体的に向上する。更に、
両ファイルに正しい順序でデータが書き込まれるため、
実行結果と期待データの照合も自動化することができる
。
ら変更せずに、その上位側に加えて下位側のインターフ
ェースから見た挙動も観測できるので、より完全なモジ
ュール・テストを行うことができる。更に、テスト・ド
ライバおよびスタブの自動生成により、従来困難と考え
られていた、大規模なプログラムのモジュール単位のテ
ストが容易に行えるようになる。また、テスト・プログ
ラムをシミュレーション・モードで動作させている間に
それからの質問に順番に答えて必要なデータを入力して
いくことにより、これら入力されたデータをテスト・デ
ータ・ファイルと期待データ・ファイルに自動的に振り
分けて夫々正しい順序で書き込むため、これらのデータ
の入力間違いが低減される。また、両ファイルを一度作
っておけば、SUTの修正とテストを繰り返す際に同じ
ものを毎回使用できるので、再テストを自動的に行うこ
とができる。再テストを行うことにより、不具合が正し
く修正されたかをチエツクするのみならず、その修正が
他の機能に影響を与えていないかも検査できる。これに
よりソフトウェアの信頼性が全体的に向上する。更に、
両ファイルに正しい順序でデータが書き込まれるため、
実行結果と期待データの照合も自動化することができる
。
第1図および第2図は本発明の一実施例を説明するため
の図、第3図は従来技術を説明する図である。 105:テスト・ドライバ・スタブ自動生成プログラム 107:テスト・ドライバ/スタブ 109:被試験モジュール 117:期待データ・ファイル 119:テスト・データ・ファイル 121:実行結果ファイル 201:テスト・ドライバ 201−1:ダミー・モジュール 203.205.207:スタブ
の図、第3図は従来技術を説明する図である。 105:テスト・ドライバ・スタブ自動生成プログラム 107:テスト・ドライバ/スタブ 109:被試験モジュール 117:期待データ・ファイル 119:テスト・データ・ファイル 121:実行結果ファイル 201:テスト・ドライバ 201−1:ダミー・モジュール 203.205.207:スタブ
Claims (3)
- (1)被試験モジュールが他のモジュールを呼び出すこ
とに関する情報を含むテスト環境との相互作用情報を被
試験モジュールから取得することを特徴とするソフトウ
ェア・モジュール・テスト方法。 - (2)第1のモードと第2のモードを有するテスト・ド
ライバおよび前記被試験モジュールが呼び出す前記他の
モジュールの代わりに用いられるスタブとを設け、 前記第1のモードでは前記相互作用情報を使用者に入力
せしめ、 前記第2のモードでは前記相互作用情報に基づいて前記
被試験モジュールを実行し、この実行中に前記テスト環
境に対してなした作用を記録しまたは前記相互作用情報
と比較する請求項1記載のソフトウェア・モジュール・
テスト方法。 - (3)前記被試験モジュールのインターフェース情報に
基づいて前記テスト・ドライバおよび前記スタブを自動
的に作成する手段を設けることを特徴とする 請求項2記載のソフトウェア・モジュール・テスト方法
。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP63256476A JPH02103644A (ja) | 1988-10-12 | 1988-10-12 | ソフトウエア・モジュール・テスト方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP63256476A JPH02103644A (ja) | 1988-10-12 | 1988-10-12 | ソフトウエア・モジュール・テスト方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JPH02103644A true JPH02103644A (ja) | 1990-04-16 |
Family
ID=17293166
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP63256476A Pending JPH02103644A (ja) | 1988-10-12 | 1988-10-12 | ソフトウエア・モジュール・テスト方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JPH02103644A (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH04149646A (ja) * | 1990-10-09 | 1992-05-22 | Nec Corp | スタブ部品記述によるプログラム展開方式 |
JP2004133739A (ja) * | 2002-10-11 | 2004-04-30 | Nec Engineering Ltd | クライアント・サーバプログラムのシミュレータシステム及びシミュレーション方法 |
JP2008262510A (ja) * | 2007-04-13 | 2008-10-30 | Fuji Xerox Co Ltd | 電子回路装置、故障診断装置、故障診断システム、及び故障診断プログラム。 |
-
1988
- 1988-10-12 JP JP63256476A patent/JPH02103644A/ja active Pending
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH04149646A (ja) * | 1990-10-09 | 1992-05-22 | Nec Corp | スタブ部品記述によるプログラム展開方式 |
JP2004133739A (ja) * | 2002-10-11 | 2004-04-30 | Nec Engineering Ltd | クライアント・サーバプログラムのシミュレータシステム及びシミュレーション方法 |
JP2008262510A (ja) * | 2007-04-13 | 2008-10-30 | Fuji Xerox Co Ltd | 電子回路装置、故障診断装置、故障診断システム、及び故障診断プログラム。 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6721922B1 (en) | System for electronic circuit characterization, analysis, modeling and plan development | |
US6061643A (en) | Method for defining durable data for regression testing | |
CN101739339B (zh) | 一种基于程序动态依赖关系的软件故障定位方法 | |
US7917895B2 (en) | Automated software testing and validation system | |
US4727545A (en) | Method and apparatus for isolating faults in a digital logic circuit | |
US6986125B2 (en) | Method and apparatus for testing and evaluating a software component using an abstraction matrix | |
CA2391125C (en) | Method for computer-assisted testing of software application components | |
Zage et al. | Evaluating design metrics on large-scale software | |
US7895575B2 (en) | Apparatus and method for generating test driver | |
CN113742215A (zh) | 一种自动配置和调用测试工具进行测试分析的方法及*** | |
JPH02103644A (ja) | ソフトウエア・モジュール・テスト方法 | |
US20070220338A1 (en) | Method and system for generating checkpoints of hardware description language simulations that include a specific model state together with a software testcase state | |
Bergmann | PHPUnit Pocket Guide: Test-Driven Development in PHP | |
Graf et al. | Gaining insight into executable models during runtime: Architecture and mappings | |
US6961887B1 (en) | Streamlined LASAR-to-L200 post-processing for CASS | |
Stumptner et al. | A model-based tool for finding faults in hardware designs | |
Tsiatsoulis et al. | Testing and debugging message passing programs in synergy with their specifications | |
US20070220390A1 (en) | Method and system for verifying equivalence of two representations of a stimulus pattern for testing a design | |
Donnelly | Evaluating the IOBIDS specification using gate-level system simulation | |
Raina | QuickCheck-Style Testing of Embedded Software using the PropEr Framework | |
CN118171613A (zh) | 一种复位树的自动化验证方法、装置及介质 | |
Zander-Nowicka et al. | Model driven testing of real-time embedded systems-from object oriented towards function oriented development | |
CN116090387A (zh) | 芯片设计的仿真验证方法、装置、计算机设备及存储介质 | |
Wiberg | Running BASIC test programs in a C/ATLAS test environment | |
Feitelson | Improvement of test program set development and customer compliance using the interactive test step generator (ITSG) |