JP3745968B2 - Test system, test method, test program, and computer-readable recording medium recording the test program - Google Patents

Test system, test method, test program, and computer-readable recording medium recording the test program Download PDF

Info

Publication number
JP3745968B2
JP3745968B2 JP2001062750A JP2001062750A JP3745968B2 JP 3745968 B2 JP3745968 B2 JP 3745968B2 JP 2001062750 A JP2001062750 A JP 2001062750A JP 2001062750 A JP2001062750 A JP 2001062750A JP 3745968 B2 JP3745968 B2 JP 3745968B2
Authority
JP
Japan
Prior art keywords
interrupt
program
file
execution
test
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
Application number
JP2001062750A
Other languages
Japanese (ja)
Other versions
JP2002268918A (en
Inventor
光宏 安田
誠 齊藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mitsubishi Electric Corp
Original Assignee
Mitsubishi Electric Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Mitsubishi Electric Corp filed Critical Mitsubishi Electric Corp
Priority to JP2001062750A priority Critical patent/JP3745968B2/en
Publication of JP2002268918A publication Critical patent/JP2002268918A/en
Application granted granted Critical
Publication of JP3745968B2 publication Critical patent/JP3745968B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Debugging And Monitoring (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Description

【０００１】
【発明の属する技術分野】
本発明は、組込みソフトウェアのモジュールの試験装置及び試験方法に関し、試験パターンとして入力値と出力期待値を用意し、試験対象モジュールの実行前に試験パターンの入力値を自動的に設定し、モジュールを実行し、実際に得られた出力値と試験パターンとして用意した期待値を自動照合して試験結果を出力することを自動化するものである。
【０００２】
【従来の技術】
Ｃ言語やアセンブリ言語等の手続型言語で記述された組込みソフトウェアは、関数やサブルーチンといったモジュールを単位としてプログラムが構成されている。単体試験とは、上記モジュール毎にソフトウェアの機能を検証することである。上記検証はモジュールを実行する前に、入力となる変数（データメモリ）や汎用レジスタ等に値を設定してモジュールを実行させ、モジュールの実行終了時に出力変数（データメモリ）や汎用レジスタの値が期待した値になっているか照合判定を行うことで実施できる。
【０００３】
単体試験を実施するための技術として、代表的な方法を３つ挙げる。
命令セットシミュレータの利用。
インサーキットエミュレータ（Ｉｎ Ｃｉｒｃｕｉｔ Ｅｍｕｌａｔｏｒ、以下、「ＩＣＥ」と称す）の利用。
組込み用自動単体試験ツールの利用。
【０００４】
命令セットシミュレータは、アセンブラ記述または、ターゲット・コンピュータの機械語で書かれたプログラムが正しいかどうかを調べるソフトウェアのデバッグにおいて、ターゲット・コンピュータとは異なるコンピュータで、上記各アセンブラ命令（機械語の１命令）を逐次解釈してシミュレーションするものが知られている。命令セットシミュレータの基本機能としては、（１）メモリや汎用レジスタへの値の読み出し／書き込み、（２）プログラムの実行、（３）指定条件での停止（ブレイクポイント・条件停止）、（４）プログラムカウンタ（以下、「ＰＣ」と記す）に対する実行アドレスの設定等がある。
Ｃ言語で書かれたソフトウェアは、クロスコンパイラを用いてアセンブラ記述を生成し、同様に命令セットシミュレータが利用できる。
【０００５】
第１の従来例として、命令セットシミュレータを利用する方法がある。以下に命令セットシミュレータの利用手順を示す。
（手順１）指定対象モジュールの開始アドレスをＰＣへ設定。
（手順２）指定対象モジュールの終了アドレスへブレイクポイントを設定。
（手順３）入力として変数（データメモリ）や汎用レジスタ等に値を設定し、モジュールを実行する。
（手順４）手順２による実行停止後、出力変数（データメモリ）や汎用レジスタの値を試験者が判定する。
上記１〜４の手順で実行することにより、人手にて単体試験を実施できる。
【０００６】
第２の従来例として、ＩＣＥを利用する方法がある。
ＩＣＥとは、従来例１であげた命令セットシミュレータの代わりに、ターゲットプロセッサにデバッグ機能を加えた装置である。デバッグ機能としては、命令セットシミュレータと等価な機能を有し、高速に実行できる点が異なる。よって、従来例１で示した方法と同じやり方で単体試験を実施できる。
【０００７】
第３の従来例として、命令セットシミュレータを利用した自動単体試験システム（以下、自動単体試験システムを「システム」と記すこともある）を利用する方法がある。
図３３は、市販システムＧＡＩＯ社製の命令セットシミュレータＸＡＳＳ−Ｖを利用して構成される自動単体試験システムＡＭＳ（Ａｄｖａｎｃｅｄ Ｍｏｄｕｌｅ Ｓｉｍｕｌａｔｏｒ）の構成図である。
システム全体の構成図１０、試験対象プログラムのプログラムメモリ１１、試験対象プログラムの開始アドレス１２、試験対象プログラムの終了アドレス１３、試験対象プログラムのデータメモリ１４、汎用レジスタ１５、プログラムカウンタ１６、試験パターンファイル１７、Ｃ言語またはアセンブリ言語で書かれたプログラムソースファイル１８、命令セットシミュレータを使った連続テストパターン実行システム１９、出力ファイル１ａである。試験パターンファイル１７は、試験対象関数の試験パターン（入力値と期待値が書かれた１つの試験項目）が複数個記述されているファイルである。第１の従来例で示した（手順１）〜（手順４）を各試験パターン毎に自動実行し、単体試験を実施している。
【０００８】
第４の従来例として、特開平１１−３０６０４２「ソフトウェア開発支援装置及びデバッグ方法」がある。これは、従来例１で挙げた命令セットシミュレータの実現方法として、試験者が指定する条件（イベント）が成立した場合に試験者が指定する動作を行える方法に関するものである。
【０００９】
第５の従来例として、特開平０５−３１３９４１「コンピュータプログラムのデバッグ方法」がある。
これは、従来例１で挙げた命令セットシミュレータの実現方法として、試験者が指定する割込み（ブレークポイント）により実行制御をデバッグサポート部に移し、デバッグを行う方法に関するものである。
【００１０】
【発明が解決しようとする課題】
第１、第２の従来例では、単体試験を自動化する方法に関して一切述べられていない。また、第４、第５の従来例では、第１の従来例の実現技術となる命令セットシミュレータに対する実行制御コマンドの実現方法を述べたに過ぎず、自動単体試験システムとしてなんら実現方法を述べたものではない。
この発明が対象とする組込みソフトウェア用自動単体試験システムの課題として、第３の従来例で述べた自動単体試験システムを基に、以下へ課題を挙げる。
【００１１】
第３の従来例では、タイマや外部割込みを利用していないモジュールの単体試験は可能である。しかしながら、タイマや外部割込みで変数値が書き換えられて初めてループから抜けるようなモジュールは、無限ループとなり実行完了できず、試験できないという課題があった。
【００１２】
また、第３の従来例では、１ビットの変数を利用していないモジュールの単体試験を行うことは可能である。しかし、１ビットの変数が、ｃｈａｒ型やｉｎｔ型の変数の指定するビット位置に対してビット変数の形で割付けられて直接プログラム中で利用されている場合、ＡＮＳＩ規格のＣ言語では、ｂｉｔ型がサポートされておらず、これを直接読み書きできないといった課題があった。
【００１３】
第３の従来例では、出力変数に必ず値が設定されるモジュールの単体試験は可能であるが、分岐などにより、値が設定されたり／値が設定されなかったりするグローバル変数があるプログラムでは、期待値照合時に不定値となるケースが生じ、一致確認ができないといった課題があった。
【００１４】
第３の従来例では、ターゲットプロセッサのビット幅（例：１６ビットＣＰＵや３２ビットＣＰＵ）が同じ場合、プロセッサを変更してもモジュールの単体試験が可能であるが、プログラム中にｉｎｔ型で宣言された変数に対し、ターゲットプロセッサを１６ビットＣＰＵから３２ビットＣＰＵに変更した場合、メモリ領域自体が変わってしまい、基のプログラムの機能が異なってしまうため、試験データファイルを再作成しなければならないという課題があった。
【００１５】
第３の従来例では、関数内にＣ言語の＃ｄｅｆｉｎｅで書いた変数等で別名付けされた変数が無い場合の単体試験は可能であるが、別名付けされた変数を含む関数に対しては、別名変数の値の読み出し／書き込みができないといった課題があった。
【００１６】
更に、従来のシステムでは単体試験だけが機能として提供されていたが、自動実行時に何命令実行したかという情報によって性能情報を得ることができないという課題があった。
【００１７】
この発明は、上記の問題点を解決し、手続型言語で記述されたプログラムの試験を自動化することを目的とする。
【００１８】
【課題を解決するための手段】
この発明に係る試験システムは、手続型言語で記述されたプログラムを試験する試験システムにおいて、
上記プログラムは、割込みの発生を指定する記述を含み、
上記割込みを擬似発生させる命令を実行する割込み処理を記憶した割込み模擬ファイルと、
上記割込み模擬ファイルに記憶された割込み処理を実行する指示を記述した試験パターンファイルを記憶する試験パターンファイル記憶部と、
上記プログラムを入力し、上記試験パターンファイル記憶部に記憶した試験パターンファイルを読み込み、上記プログラムに含まれる割込みの発生を指定する記述に対応して上記割込み処理を実行させることを設定するコマンド列と、上記プログラムを実行するコマンド列と、実行した実行結果を出力するコマンド列とを記述した実行スクリプトファイルを生成するコマンド列生成部と、
上記コマンド列生成部が生成した実行スクリプトファイルと、上記外部割込み模擬ファイルとを読み込み、上記外部割込み模擬ファイルに記憶された割込み処理を用いて、入力した実行スクリプトファイルを実行し、実行した実行結果を出力する実行部と
を備えることを特徴とする。
【００１９】
この発明に係る試験システムは、手続型言語で記述されたプログラムを試験する試験システムにおいて、
上記プログラムは、１ビットのデータをアクセスする命令を含み、
上記１ビットのデータのデータ型を定義するビット型と、上記ビット型のデータを含む試験用データとを記述した試験パターンファイルを記憶する試験パターンファイル記憶部と、
上記ビット型のデータをアクセスするビットアクセスコマンドを記憶するコマンド定義記憶部と、
上記プログラムを入力し、上記試験パターンファイル記憶部に記憶した試験パターンファイルと、上記コマンド定義記憶部に記憶したビットアクセスコマンドとを読み込み、上記試験パターンファイルに記述された試験用データを上記ビットアクセスコマンドを用いて設定するコマンド列と、上記プログラムを実行するコマンド列と、実行した実行結果を出力するコマンド列とを記述した実行スクリプトファイルを生成するコマンド列生成部と、
上記コマンド定義記憶部に記憶したビットアクセスコマンドと、上記コマンド列生成部が生成した実行スクリプトファイルとを入力し、上記ビットアクセスコマンドを用いて、入力した実行スクリプトファイルを実行し、実行した実行結果を出力する実行部と
を備えることを特徴とする。
【００２０】
この発明に係る試験システムは、手続型言語で記述されたプログラムを試験する試験システムにおいて、
上記プログラムは、グローバル変数を含み、
上記プログラムに記述されたグローバル変数へ設定する初期値を定義する変数初期値を記述した試験パターンファイルを記憶する試験パターンファイル記憶部と、
上記プログラムを入力し、上記試験パターンファイル記憶部に記憶した試験パターンファイルを読み込み、上記試験パターンファイルに記述された変数初期値を上記グローバル変数へ設定するコマンド列と、上記プログラムを実行するコマンド列と、実行した実行結果を出力するコマンド列とを記述した実行スクリプトファイルを生成するコマンド列生成部と、
上記コマンド列生成部が生成した実行スクリプトファイルを入力し、入力した実行スクリプトファイルを実行し、実行した実行結果を出力する実行部と
を備えることを特徴とする。
【００２１】
この発明に係る試験システムは、手続型言語で記述されたプログラムを試験する試験システムにおいて、
上記プログラムは、命令を実行するプロセッサに依存するデータ型を含み、
上記プログラムを実行する場合に使用する試験用データと、上記プログラムに記述されたプロセッサに依存するデータ型を定義するデータ型定義とを記述した試験パターンファイルを記憶する試験パターンファイル記憶部と、
上記プログラムを入力し、上記試験パターンファイル記憶部に記憶した試験パターンファイルを読み込み、上記プログラムで使用する試験用データを上記試験パターンファイルに記述されたデータ型定義を用いて設定するコマンド列と、上記プログラムを実行するコマンド列と、実行した実行結果を出力するコマンド列とを記述した実行スクリプトファイルを生成するコマンド列生成部と、
上記コマンド列生成部が生成した実行スクリプトファイルを入力し、入力した実行スクリプトファイルを実行し、実行した実行結果を出力する実行部と
を備えることを特徴とする。
【００２２】
この発明に係る試験システムは、手続型言語で記述されたプログラムを試験する試験システムにおいて、
上記手続型言語は、一の変数の名称を別名で定義する別名定義が可能であり、
上記プログラムは、上記別名定義された別名定義変数を含み、
上記別名定義変数へ設定する変数値を記述した試験パターンファイルを記憶する試験パターンファイル記憶部と、
上記別名定義された別名定義変数を上記一の変数の名称とを対応付けて記憶する別名定義ファイルと、
上記プログラムを入力し、上記試験パターンファイル記憶部に記憶する試験パターンファイルと、上記別名定義ファイルとを読み込み、上記プログラムソースファイルに記述された別名定義変数を上記一の変数の名称へ書き換え、上記試験パターンファイルに記述された変数値を上記書き換えた一の変数へ設定するコマンド列と、上記プログラムを実行するコマンド列と、実行した実行結果を出力するコマンド列とを記述した実行スクリプトファイルを生成するコマンド列生成部と、
上記コマンド列生成部が生成した実行スクリプトファイルを入力し、入力した実行スクリプトファイルを実行し、実行した実行結果を出力する実行部と
を備えることを特徴とする。
【００２３】
上記試験パターンファイル記憶部は、更に、上記実行結果を予測する期待値を含み、
上記コマンド列生成部は、上記実行スクリプトファイルへ、更に、上記実行結果と上記期待値とを比較して比較結果を出力するコマンド列と、プログラムの性能を測定する性能測定コマンドを実行するコマンド列と、上記性能測定コマンドが測定した性能情報を出力する性能情報出力コマンドを実行するコマンド列とを記述し、
上記実行部は、上記性能測定コマンドと上記性能情報出力コマンドとを実行して、上記実行結果に加え、上記比較結果と性能情報とを出力し、
上記試験システムは、更に、
上記実行部が出力する実行結果と比較結果と性能情報とを入力し、入力した実行結果と比較結果と性能情報とを併せて出力する出力整形部を備えることを特徴とする。
【００２４】
上記プログラムは、１ビットのデータをアクセスする命令を含み、
上記試験システムは、更に、上記ビット型のデータをアクセスするビットアクセスコマンドを記憶するコマンド定義記憶部を備え、
上記試験パターン記憶部は、更に、上記１ビットのデータのデータ型を定義するビット型と、上記ビット型のデータとを含む試験用データとを含む試験パターンファイルを記憶し、
上記コマンド列生成部は、上記コマンド定義記憶部に記憶したビットアクセスコマンドを読み込み、上記試験パターンファイルに記述された試験用データを上記ビットアクセスコマンドを用いて設定するコマンド列を上記実行スクリプトファイルへ記述し、
上記実行部は、上記コマンド定義記憶部に記憶したビットアクセスコマンドを入力し、上記ビットアクセスコマンドを用いて、入力した実行スクリプトファイルを実行することを特徴とする。
【００２５】
上記プログラムは、グローバル変数を含み、
上記試験パターンファイルは、上記プログラムに記述されたグローバル変数へ設定する初期値を定義する変数初期値を含む試験パターンファイルを記憶し、
上記コマンド列生成部は、上記試験パターンファイルに記述された変数初期値を上記グローバル変数へ設定するコマンド列を上記実行スクリプトファイルへ記述することを特徴とする。
【００２６】
上記プログラムは、命令を実行するプロセッサに依存するデータ型を含み、
上記試験パターンファイル記憶部は、上記プログラムを実行する場合に使用する試験用データと、上記プログラムに記述されたプロセッサに依存するデータ型を定義するデータ型定義とを含む試験パターンファイルを記憶し、
上記コマンド列生成部は、上記試験パターンファイルに記述されたデータ型定義を用いて、上記プログラムで使用する試験用データを設定するコマンド列を上記実行スクリプトファイルへ記述することを特徴とする。
【００２７】
上記手続型言語は、一の変数の名称を別名で定義する別名定義が可能であり、
上記プログラムは、別名定義された別名定義変数を含み、
上記試験パターンファイル記憶部は、上記別名定義変数へ設定する変数値を含む試験パターンファイルを記憶し、
上記試験システムは、更に、上記別名定義された別名定義変数を上記一の変数の名称とを対応付ける別名変数ファイルを備え、
上記コマンド列生成部は、上記別名定義ファイルとを入力し、上記プログラムソースファイルに記述された別名定義変数を上記一の変数の名称へ書き換え、上記試験パターンファイルに記述された変数値を上記書き換えた一の変数へ設定するコマンド列を上記実行スクリプトファイルへ記述することを特徴とする。
【００２８】
この発明に係る試験システムは、割込み処理を実施する割込みハンドラ関数を備え、手続型言語で記述されたプログラムを試験する試験システムにおいて、
上記プログラムは、割込みの発生を指定する記述を含み、
上記割込みハンドラ関数を実行する指示を記述した試験パターンファイルを記憶する試験パターンファイル記憶部と、
上記プログラムを入力し、上記試験パターンファイル記憶部に記憶した試験パターンファイルとを読み込み、上記プログラムに含まれる割込みの発生を指定する記述に対応して上記割込みハンドラ関数を実行するコマンド列と、上記プログラムを実行するコマンド列と、実行した実行結果を出力するコマンド列とを生成し、生成したコマンド列を記述した実行スクリプトファイルを生成するコマンド列生成部と、
上記コマンド列生成部が生成した実行スクリプトファイルを入力し、上記割込みハンドラ関数を用いて、入力した実行スクリプトファイルを実行し、実行した実行結果を出力する実行部と
を備えることを特徴とする。
【００２９】
上記実行部は、命令セットシュミレータとインサーキットシュミレータとのいずれか一方であることを特徴とする。
【００３０】
上記手続型言語は、Ｃ言語とアセンブリ言語とのいずれか一方を含むことを特徴とする。
【００３１】
この発明に係る試験方法は、手続型言語で記述されたプログラムを試験する試験方法において、
割込みの発生を指定する記述を上記プログラムへ書き込み、
上記割込みを擬似発生させる命令を実行する割込み処理を生成し、生成した割込み処理を記憶し、
上記割込み処理を実行する指示を記述した試験パターンファイルを生成し、
上記プログラムと、上記試験パターンファイルとを入力し、上記プログラムに書き込まれた割込みの発生を指定する記述に対応して上記割込み処理を実行させることを設定するコマンド列と、上記プログラムを実行するコマンド列と、実行した実行結果を出力するコマンド列とを記述した実行スクリプトファイルを生成し、
上記実行スクリプトファイルを入力し、上記割込み処理を読み込み、読みこんだ割込み処理を用いて、入力した実行スクリプトファイルを実行し、実行した実行結果を出力することを特徴とする。
【００３２】
この発明に係る試験プログラムは、手続型言語で記述されたプログラムの試験を計算機で実現する試験プログラムにおいて、
割込みの発生を指定する記述を上記プログラムに書き込み、
上記割込みを擬似発生させる命令を実行する割込み処理を生成し、生成した割込み処理を記憶する割込み処理生成処理と、
上記割込み処理生成処理で生成された割込み処理を実行する指示を記述した試験パターンファイルを生成し、生成した試験パターンファイルを記憶する試験パターンファイル記憶処理と、
上記プログラムを入力し、上記試験パターンファイル記憶処理で記憶した試験パターンファイルを読み込み、上記プログラムに書き込まれた割込みの発生を指定する記述に対応して上記割込み処理を実行させることを設定するコマンド列と、上記プログラムを実行するコマンド列と、実行した実行結果を出力するコマンド列とを記述した実行スクリプトファイルを生成するコマンド列生成処理と、
上記コマンド列生成処理が生成した実行スクリプトファイルを入力し、上記割込み処理を用いて、入力した実行スクリプトファイルを実行し、実行した実行結果を出力する実行処理と
を備えることを特徴とする。
【００３３】
この発明に係る手続型言語で記述されたプログラムの試験を計算機で実現する試験プログラムを記録する計算機で読み取り可能な記録媒体は、
割込みの発生を指定する記述を上記プログラムに書き込み、
上記割込みを擬似発生させる命令を実行する割込み処理を生成し、生成した割込み処理を記憶する割込み処理生成処理と、
上記割込み処理生成処理で生成された割込み処理を実行する指示を記述した試験パターンファイルを記憶する試験パターンファイル記憶処理と、
上記プログラムを入力し、上記試験パターンファイル記憶処理で記憶した試験パターンファイルを読み込み、上記プログラムに書き込まれた割込みの発生を指定する記述に対応して上記割込み処理を実行させることを設定するコマンド列と、上記プログラムを実行するコマンド列と、実行した実行結果を出力するコマンド列とを記述した実行スクリプトファイルを生成し、生成した実行スクリプトファイルを記憶するコマンド列生成処理と、
上記コマンド列生成処理が生成した実行スクリプトファイルを入力し、上記割込み処理を用いて、入力した実行スクリプトファイルを実行し、実行した実行結果を出力する実行処理と
を備える試験プログラムを記録する計算機で読み取り可能な記録媒体であることを特徴とする。
【００３４】
【発明の実施の形態】
実施の形態１．
図１に、この実施の形態の自動単体試験システム（以下、自動単体試験システムを「システム」、又は、「試験システム」と記すこともある）構成図の一例を示す。
図３３に示された従来例に付加して、下記の機能を有している。
拡張試験パターンファイル（試験パターンファイル）２１は、従来の試験パタンファイルに比べ、機能拡張された試験パターンファイルである。具体的には、ビット対応記述２５、初期値設定記述２７、プロセッサ非依存の型定義２８が含まれる。
ビット対応記述（１ビットのデータの読み出し／書き込み設定記述）２５は、１ビットのデータのアクセスを可能にする。自動単体試験システム内で、１ビットのデータをビット型として定義する。
初期値設定記述（変数初期値）２７は、グローバル変数へ設定する初期値を定義する。初期値設定記述２７は、予め、グローバル変数へ初期値を設定することによって、期待値と実行結果を照合するために用いられる。
プロセッサ非依存の型定義（データ型）２８は、プロセッサに依存するデータの型を定義する。定義したデータ型を用いてデータを設定することによって、プロセッサ依存のデータ型のデータをアクセスする際の不整合を防ぐ。
【００３５】
別名付け変数利用機能として、別名定義ファイル２９を備える。
別名定義ファイル２９は、別名定義された別名定義変数を変数の名称とを対応付けるファイルである。
性能情報出力機能として、下記の機能を備える。
性能情報２ａを出力ファイルへ出力する。
ビットデータ値の直接読み出し／書き込み機能は、上記ビットが他のデータをアクセスする拡張コマンドマクロ（図６等を用いて後述する）を備えることにより実現する。
命令セットシミュレータを使った拡張された連続テストパターン実行システム２ｂは、上記拡張試験パターンファイル２１を処理するコマンド列生成部２ｃを備え、命令セットシミュレータを使って試験を実施することによって、機能を拡張する。連続テストパターン実行システム２ｂは、図６等を用いて後述する。
【００３６】
図１には明記していないが、拡張試験パターンファイル（試験パターンファイル）は、記憶領域である試験パターンファイル記憶部に記憶されている。
同様に、別名定義ファイル２９は、別名定義ファイル記憶部に記憶され、プログラムソースファイルは、プログラムソースファイル記憶部に記憶されている。その他のファイルについても、特に明記していないが、それぞれ記憶領域に記憶されている。
【００３７】
この実施の形態では、手続型言語としてＣ言語を一例として説明する。しかしながら、この発明に係る試験装置は、その他の手続型言語にも適用することが可能である。また、この明細書では、手続型言語は、Ｃ言語、Ｃ＋＋言語、ＦＯＲＴＬＡＮ等の言語、及び、アセンブリ言語を含む。
また、この実施の形態では、ターゲットマシンのプロセッサが命令を実行する動作を模擬する実行部として、命令セットシュミレータを一例として説明する。しかしながら、上記実行部は、命令セットシュミレータに限られることなく、ＩＣＥ等、その他のものであっても構わない。
【００３８】
試験対象関数ｄｅｃｉｄｅを図２のプログラムソースを使って説明する。
変数“ＰＦＬＡＧ”は、１ビットの変数で、変数名“ｃｏｎｄｉｔｉｏｎ”という８ビットメモリ領域の下位３ビット目を指し示した変数であり、関数では入力グローバル変数として使用している。変数“ＳＭ”は、変数名“ｓｙｓｔｅｍ＿ｍｏｄｅ．ａｌｌ”を別名付けした変数であり、関数では出力グローバル変数として使用している。変数“ｒｅｓｕｌｔ”、変数“ｒ”も、この関数でセットされる出力グローバル変数である。変数“ｂａｓｅ”は、入力グローバル変数である。変数“ｒ”は、値を読み出し変更される入出力グローバル変数である。本関数は、戻り値として変数“ｒ”の値を返す。
【００３９】
ここで、第３の従来例の自動単体試験システムを用いて、図２に示すプログラムソースの試験を行った場合の問題点を説明する。
変数“ＰＦＬＡＧ”は、別名付けされた変数であるため、直接、図３３に示す試験パターンファイル１７で使用できないという問題がある。また、変数“ＰＦＬＡＧ”が指し示している変数“ｃｏｎｄｉｔｉｏｎ．ｂｉｔ．ｂ２”は、１ビットを示した変数であるため、第３の従来例の自動単体試験システムでは取り扱うことができないという問題がある。“ｃｏｎｄｉｔｉｏｎ．ｂｉｔ．ｂ２”を検証するには、変数“ｃｏｎｄｉｔｉｏｎ”の３ビット目を試験者により確認する方法しか提供していない。また、別名付け変数“ＳＭ”も試験対象として扱えないため、試験パターンファイル１７では、“ｓｙｓｔｅｍ＿ｍｏｄｅ．ａｌｌ”として置き換えて使用しなければならないという問題がある。また、変数“ｓ”は、関数中の分岐パスの中で、値がセットされないケースがあり、期待値を事前に設定することができない問題がある。本プログラムが、１６ビットＣＰＵをターゲットとしたプログラムの場合、ｉｎｔ型で宣言される変数“ｓ”や変数“ｒ”は、１６ビットとなるが、３２ビットＣＰＵに移した場合、３２ビットの変数として扱われ、試験時に同じ試験パターンファイルが使用できないという問題がある。
【００４０】
これらの問題を解決するため、拡張試験パターンファイル２１と別名定義ファイル２９と命令セットシミュレータを使った拡張された連続テストパターン実行システム２ｂによる実施の形態を説明する。
図３は、上記問題点を解決するために考案した拡張試験パターンファイル２１に格納される試験パターンの一例を示す図である。
“ｆｕｎｃｔｉｏｎ”は試験対象関数名、“ｐｒｏｊｅｃｔ”は本プログラムの対象となるプロジェクト名、“ｓｒｃ”は本関数が記述されているファイル名及び“ｃｌｏｃｋ”はターゲットＣＰＵのクロックサイクルを示す。試験対象変数は、引数、入力変数、戻り値及び出力変数に大別される。内部変数は、プログラム全体の機能に影響しないため、試験対象外となる。
【００４１】
試験対象変数は、各々、引数は＜ａｒｇ＞〜＜／ａｒｇ＞の間（引数部）、入力変数は＜ｉｎ＞〜＜／ｉｎ＞の間（入力変数部）、戻り値は＜ｒｅｔ＞〜＜／ｒｅｔ＞の間（戻り値部）、出力変数は＜ｏｕｔ＞〜＜／ｏｕｔ＞の間（出力変数部）に宣言される。引数部と入力変数部は、同じフォーマットで記述される。本例では引数が無いため、引数部の中身は記述されない。変数（入力変数、出力変数等）は、“変数名／型”のフォーマットで定義される。ここで使用される型は、プロセッサ非依存の型を用いており、図４に示す型を用いる。
図４は、拡張試験パターンファイル２１に格納されるプロセッサ非依存の型定義２８の一覧の一例を示した図である。
図４に示すプロセッサ非依存の型定義２８の一覧では、更に、組込みソフトウェアで多用される１ビット変数をｂｉｔ型として新たに追加している。図４に示すプロセッサ非依存の型定義に含まれるＢｉｔ型は、ビット対応記述２５で用いるデータ型である。
戻り値は、“型”のみを記述する。戻り値がない場合は、戻り値部へ何も書かない又は“ｖｏｉｄ”を記述する。本例では、１６ビットのｉｎｔ型を返す記述になる。
【００４２】
出力変数は、２種類に大別される。１つは読み出した後に書き込まれるもので、もう１つは、書き込みのみのものがある。読み出して書き込む変数は、入力変数部と出力変数部の両方に定義すれば試験可能である。本例では、読み出して書き込む変数は、変数“ｒ”が該当する。また、書き込みのみの変数は、分岐パスにより書き込まれない場合がある。その場合の自動期待値照合を実現するため、初期値設定機能を持たせた。フォーマットは、“変数／型／初期値”で指定する。本例では、書き込みのみの変数は、変数“ｒｅｓｕｌｔ”、変数“ｓ”、別名変数“ＳＭ”が該当する。
【００４３】
＜Ｖｅｃｔｏｒ＞〜＜Ｖｅｃｔｏｒ＞の間に宣言するパターン記述部は、“引数部，入力変数部｜戻り値部，出力変数部”の順に値を記述していく。図３に示すテストベクタ記述部は８行の記述があり、１行の記述が１つの試験パターンを示す。図３の例では、８つの試験パターンを記述している。“｜”以降は、出力期待値を記述しており、自動単体試験システム２０において、実際の実行結果と自動照合される。引数部は行頭から“，”まで宣言部分であり、本例では引数がないため、省略される。入力変数部は、“，”から“｜”までが宣言部分であり、本例では、“ＰＦＬＡＧ，ｒ，ｂａｓｅ”の順で記述される。戻り値は、“｜”から“，”までが宣言部分であり、本例では、１６ビットのｉｎｔ型の期待値が記述される。出力変数部は、“，”から行末までが宣言部分であり、本例では、“ＳＭ”，“ｒｅｓｕｌｔ”，“ｒ”，“ｓ”の順で期待値が記述される。
【００４４】
本例の１行目の試験パターンでは、“ＰＦＬＡＧ＝０，ｒ＝０，ｂａｓｅ＝０”を入力セットし、出力期待値として、“戻り値→０”，“ＳＭ→０”，“ｒｅｓｕｌｔ→０”，“ｒ→０”，“ｓ→０”を確認するパターンが記述されている。
【００４５】
図５は、別名定義ファイル２９の内容の一例を示した図である。
先に述べたように、別名変数“ＳＭ”の実体は、“ｓｙｓｔｅｍ＿ｍｏｄｅ．ａｌｌ”となり、関数内では直接使用されていないため、試験データ作成時に変数“ＳＭ”を、“ｓｙｓｔｅｍ＿ｍｏｄｅ．ａｌｌ”に全て置き換えて作成するという負担が生じる。本例で示したように“別名 型 実際のプログラム変数”のフォーマットで対応づけ、システムで自動的に名前を置換して実現している。本例では、変数“ＰＦＬＡＧ”が別名付けされたビット変数であり、命令セットシミュレータは直接実体である“ｃｏｎｄｉｔｉｏｎ．ｂｉｔ．ｂ２”がｂｉｔ型であるため、扱うことができない。そのためのフォーマットとして、“別名 型 ビット変数の存在する基の変数 ビット位置”を導入することで解決しており、図５のような定義となる。
【００４６】
以下に、拡張試験パターンファイル２１、別名定義ファイル２９、プログラムソースファイル１８を入力とし、命令セットシミュレータを使った拡張された連続テストパターン実行システム２ｂを説明する。
図６は、命令セットシミュレータを使った拡張された連続テストパターン実行システム２ｂの処理構成である。
命令セットシミュレータを使った拡張された連続テストパターン実行システム２ｂは、コマンド列生成部２ｃ、命令セットシミュレータ２ｄ、出力整形部２ｅにより構成される。
図７は、コマンド列生成部２ｃが図３に示した拡張試験パターンファイル２１及び、図５に示した別名定義ファイル２９を用いて命令セットシミュレータ２ｄが自動実行できる実行コマンドスクリプトを自動生成する処理のフローチャート図の一例である。
図７を用いて、コマンド列生成部２ｃが実行コマンドスクリプトを生成する動作を説明する。
【００４７】
コマンド列生成部２ｃは、試験実行前の初期値設定コマンド列と、試験前の出力用コマンド列を生成する（Ｓ７１）。初期値設定コマンド列は、試験実行前に予め変数に設定される初期値を設定するコマンド列である。出力用コマンド列は、試験結果を出力するコマンド列である。
また、このとき、コマンド列生成部２ｃは、その他の初期処理（例えば、実行コマンドスクリプトファイルのヘッダの生成、等）を実施する。
【００４８】
次に、コマンド列生成部２ｃは、入力変数へ値を設定するコマンド列を生成する（Ｓ７２）。対象変数が別名定義変数の場合、コマンド列生成部２ｃは、別名定義ファイルを用いて、別名定義変数を実際の変数名へ置換する。
コマンド列生成部２ｃは、初期値付き出力変数へ値を設定するコマンド列を生成する（Ｓ７３）。Ｓ７２と同様に、対象変数が別名定義変数の場合、コマンド列生成部２ｃは、別名定義ファイル２９を用いて、別名定義変数を実際の変数名へ置換する。
【００４９】
コマンド列生成部２ｃは、対象関数実行用のＣＡＬＬコマンドを生成する（Ｓ７４）。対象関数実行用のＣＡＬＬコマンドは、試験対象となる関数を起動させるコマンドである。
コマンド列生成部２ｃは、実行停止後、出力変数値と期待値の比較結果出力コマンドを生成する（Ｓ７５）。比較結果出力コマンド列は、上記試験対象となる関数の実行結果である出力変数値と予め試験結果を予想した期待値との比較結果を実行結果ファイル３２へ出力するコマンド列である。
次に、コマンド列生成部２ｃは、拡張試験パターンファイル２１に記載された試験パターン総てについて、Ｓ７２〜Ｓ７６の処理を実施したかを判定する。総ての試験パターンについて、上記処理を実施した場合（最終試験パターンである場合）は、Ｓ７７を実行する。まだ、上記処理を実施していない試験パターンが残っている場合は、Ｓ７２〜Ｓ７６の処理を繰り返す。
【００５０】
全ての試験パターンについて、上記処理を実施した場合（最終試験パターンである場合）は、試験終了後の出力用コマンド列を生成する。上記出力用コマンド列は、試験終了時の情報を実行結果ファイル３２へ出力するコマンド列である。上記の手順によって、コマンド列生成部２ｃは、試験パターンファイル２１及び別名定義ファイル２９とプログラムソースファイル１８とを用いて、別名で定義された変数を実際の変数へ置換した実行コマンドスクリプトファイル３１を自動生成する。
【００５１】
実際に、図２のプログラムファイル１８、図３の拡張試験パターンファイル２１、図５の別名定義ファイル２９を基に生成された実行コマンドスクリプトファイル３１の内容を図８〜図１２に示す。
図８に示す実行コマンドスクリプトファイル３１は、別名（＃ｄｅｆｉｎｅ）変数の使用や出力データの初期値設定機能を実現する。１ビットデータの読み出し／書き込み／比較に関しては、図１３〜図１７に示す“ｓｔｏｒｅ＿ｆｌａｇ”（読み出し），“ｐｒｉｎｔ＿ｆｌａｇ”（書き込み），“ｃｍｐ＿ｆｌａｇ”（比較）の拡張コマンドマクロ３３により実現している。
図１３〜図１７は、拡張コマンドマクロ３３の一例を示す図である。
生成された実行コマンドスクリプトファイル３１を入力として、命令セットシミュレータ２ｄを実行する。実行終了後、実行結果ファイル３２が出力される。
図１８、図１９は、出力された実行結果ファイル３２の一例を示す。
【００５２】
試験者に結果を理解しやすくするため、出力整形部２ｅは、実行結果ファイル３２を整形する。
整形された出力ファイル１ａの一例を図２０に示す。
整形された出力ファイルには、各テストパターン毎の性能情報２ｂが含まれている。各テストパターン毎の性能情報は、命令セットシミュレータ２ｄのサイクルカウント機能（“ｒｅｓｅｔ ｃｙｃｌｅ（ｓｅｔ ｃｙｃｌｅ／ｒｅｓｅｔ）”でｃｙｃｌｅを０クリアし、実行後に“ｓｈｏｗ ｃｙｃｌｅ”で表示）を使って実現している。
図８〜図１２の実行コマンドスクリプト内で“ｒｅｓｅｔ ｃｙｃｌｅ（ｓｅｔ ｃｙｃｌｅ／ｒｅｓｅｔ）”及び“ｓｈｏｗ ｃｙｃｌｅ”のコマンド列を生成することによって実現できる。“ｒｅｓｅｔ ｃｙｃｌｅ（ｓｅｔ ｃｙｃｌｅ／ｒｅｓｅｔ）”は性能を測定する性能測定コマンドであり、“ｓｈｏｗ ｃｙｃｌｅ”は測定した性能情報を出力する性能情報出力コマンドである。
図２０に試験の「実行結果」と及び「性能情報」と記載した部分が、それぞれ実行結果、性能情報とを示す部分である。
【００５３】
また、別の試験パターンファイルで試験した結果を図２１、図２２を用いて説明する。この場合、実行結果がＮＧの場合の一例を示す。図２１に試験パターンファイルのデータを示し、図２２に実行結果と性能情報を含む試験結果の一例を示す。図２１に示す例では、試験パターンは、４つである。図２２は、期待値がＮＧである場合を、実行結果及び性能情報の１行目、すなわち、１番目の試験パターンに示している。
また、この例では、試験パターンを減らしたことにより、充分な試験が実施されてない結果、カバレッジが１００％にならない場合を示している。
【００５４】
本実施の形態は、Ｃ言語で書かれたプログラムを対象としたが、コンパイル／リンク後、機械語（アセンブリ言語）にし、プログラムコードと機械語の対応付けが命令セットシミュレータで実現されており、本システムでは、この機能を利用している。対象言語がアセンブリ言語になっても、この命令セットシミュレータの機能を使用することにより容易に実現できる。
【００５５】
以上のように、手続型言語の一例として、組込み用にＣ言語で書かれたプログラムと、その中で試験対象とする関数の試験用データ（入力値と期待値のパターン）を入力し、パターン毎に試験対象関数を自動実行し、実行された変数値とあらかじめ定めた期待値とを自動照合する機能を有した組込みソフトウェア用自動単体試験システムにおいて、以下のような特徴を備える自動単体試験システムを説明した。
対象関数内で１ビットのデータが使われている場合、本システム内でｂｉｔ型を新たに設け、直接ビットデータに対する値の読み出し／書き込み設定が試験用データに記述できることを特徴とする。
また、対象関数内でグローバル変数に対し書き込みのみ行う場合、その変数に対して初期値を試験用データに記述して設定することを特徴とする。
試験対象プログラムが別のプロセッサ（例えば、１６ビットＣＰＵから３２ビットＣＰＵへ変更）に移植して単体試験を行う場合、プロセッサ非依存の型定義を用いて試験用データを記述することで、試験データファイルを共有できることを特徴とする。
対象関数内で使用される変数が別名付けされている（例えば、＃ｄｅｆｉｎｅＳＭ ｓｙｓｔｅｍ＿ｍｏｄｅ．ａｌｌ）場合、別名変数を試験データファイル内で使用しても、変数に対して値の読み出し／書き込みが可能となることを特徴とする。
更に、自動実行時に実行されたアセンブラ命令をカウントすることで、性能見積り情報も出力できることを特徴とする。
【００５６】
実施の形態２．
実施の形態１で示した組込みソフトウェア用自動単体試験システムへ下記に示す機能の追加を行い、タイマや外部割込みによって外部変数が書き換えられる試験対象モジュールを試験可能とする実施の形態を示す。
図２３は、この実施の形態の自動単体試験システム（単体試験システム）の構成の一例を示す。
図１の構成に加え、割込み対応記述２２と、タイマ／外部割込み模擬２３と、割込み発生用プラグマ２４とを追加したものになっている。
【００５７】
割込み対応記述２２は、割込みを発生させる処理を実施することを指示する記述であり、この実施の形態では、拡張試験パターンファイル２１へ記述される。タイマ／外部割込み模擬２３は、割込みを擬似発生させる命令を実行する命令であり、この実施の形態では、コマンドマクロとして記述する。
タイマ／外部割込み模擬２３は、図２３に示すように、独立したファイル（割込み模擬ファイル）として作成してもよいし、拡張試験パターンファイル２１内に記述することも可能である。以下の説明では、割込み定義部として、拡張試験パターンファイル２１内に記述する場合を説明する。
割込み発生プラグマ２４は、上記タイマ／外部割込み模擬２３の実行をプログラム内へ指定する。割込み発生用プラグマ２４によって、割込みを発生させる場所を指定する。割込み発生用プラグマ２４は、プログラム内では、コメントとして取り扱われるため、プログラムのコンパイル・リンクに影響を与えることはない。
【００５８】
試験対象関数“ｓｃａｎ”を図２４のプログラムソースファイル１８を使って説明する。
本関数で使用される変数“ｔｉｍｅ”は、予め所定時間を示す値が設定されている。
“ｔｉｍｅｒ＿ｃｏｕｎｔｅｒ”関数は、タイマ割込み処理関数（ハンドラ）の一例である。“ｔｉｍｅｒ＿ｃｏｕｎｔｅｒ”関数は、１ｍｓ毎のタイマ割込みで起動される。“ｔｉｍｅｒ＿ｃｏｕｎｔｅｒ”関数が１ｍｓ毎に起動されると、変数“ｔｉｍｅ”は設定された値から１ｍｓ毎に１ずつ減じられ、値が“０”になった時に所定時間が経過したことを知らせる。
また、変数“ＳＣＡＮ＿Ｂ”は、割込み処理関数の起動状態を示す。割込み処理関数は、“ｓｃａｎ＿ｂｔｍ＿ｏｎ”，“ｓｃａｎ＿ｂｔｍ＿ｏｆｆ”とを備える。外部割込みポートへ外部信号が入力され、外部信号のＯＮ／ＯＦＦによって、“ｓｃａｎ＿ｂｔｍ＿ｏｎ”，“ｓｃａｎ＿ｂｔｍ＿ｏｆｆ”の割込み処理関数が起動されて変数“ＳＣＡＮ＿Ｂ”に各々１，０の値が設定される。
【００５９】
従来のシステムでは、変数“ｔｉｍｅ”を固定値にセットして試験を実施することは可能であった。しかしながら、“ｔｉｍｅ＝０”の設定では、ｗｈｉｌｅループを処理できなかった。一方、“ｔｉｍｅ≠０”の設定では、ｗｈｉｌｅループが無限にまわり、本モジュールを試験することができなかった。また、変数“ＳＣＡＮ＿Ｂ”に関しても、関数実行中にその値が変化した時を想定してのモジュール単体試験を同様の理由で実施することができなかった。
【００６０】
これらの問題を解決するため、拡張試験パターンファイル２１へ割込み対応記述２２を追加し、プログラムソースファイル１８へ割込み発生用プラグマ２４を追加した拡張組込みソフトウェア用自動単体試験システム２０の実施例を説明する。
図２５は、割込み発生用プラグマ２４を用いて割込み発生箇所を記述した関数“ｓｃａｎ”のプログラムソースファイル１８である。プログラム中のコメント文としてプラグマ（ｐｒａｇｍａ）文（“／／＃ｐｒａｇｍａ ｓｅｔ＿ｄｏ ＜タグ名＞”）を挿入することにより、試験者は任意の場所で割込みを発生させることができる。
【００６１】
図２５のプラグマ文“／／＃ｐｒａｇｍａ ｓｅｔ＿ｄｏ ｐｓｃａｎ１”は“ｐｓｃａｎ１”というタグ名で、実行行“ｔｉｍｅ＝０；”が実行される直前に割込みを発生させることを示した記述である。同様にして、プログラマ文“／／＃ｐｒａｇｍａ ｓｅｔ＿ｄｏ ｐｓｃａｎ２”は、実行行“ｗｈｉｌｅ（ｔｉｍｅ）｛”（ｔｉｍｅが０でないかをチェック）が実行される前に、“ｐｓｃａｎ２”というタグ名で割込みを発生させることを示したものである。タグ名は、後述する拡張試験パターンファイル２１で実際に起動する割込み処理の関数やタイマ／外部割込み模擬２３を割付け、任意の割込み処理を生じさせることに使用される。
【００６２】
図２６は、試験対象関数“ｓｃａｎ”の拡張試験パターンファイル２１である。
実施の形態１で示したフォーマットに加え、パターン記述部“＜ｖｅｃｔｏｒ＞〜＜／ｖｅｃｔｏｒ＞”を拡張し、かつ、割込み模擬定義部“＜ｍａｃｒｏ＞〜＜／ｍａｃｒｏ＞”を追加したものである。割込み模擬定義部は、図２３のタイマ／外部割込み模擬２３の機能を実現するものである。パターン記述部で“ｓｅｔ＿ｄｏ：〜ｅｎｄ＿ｓｅｔ＿ｄｏ：”で示されるパラグラフが、割込み対応記述２２である。“ｓｅｔ＿ｄｏ：”は、以下に割込みを起こすことを示す開始行であり、実際に発生させたい割込みは、図２５の対象関数ソース内に示した割込み発生用プラグマ２４に使ったタグ名（“ｐｓｃａｎ１”又は“ｐｓｃａｎ２”）を用い、“＜タグ名＞／（割込み処理関数名または割込み模擬スクリプト名）”で指定できる。
本例では、“ｐｓｃａｎ１”の場所で割込み模擬スクリプト“ｓｃａｎ＿ｂｔｍ＿ｏｎ”を発生し、“ｐｓｃａｎ２”では、割込み模擬スクリプト“ｃｏｕｎｔ＿ｄｏｗｎ”を発生させる記述である。以下、割込みを発生させて試験パターンを実行させ、“ｅｎｄ＿ｓｅｔ＿ｄｏ：”を見つけたところで割込み発生が中止される。また、“ｓｅｔ＿ｄｏ：〜ｅｎｄ＿ｓｅｔ＿ｄｏ：”の間に書かれていない試験パターンは、実施の形態１と同様の処理となる。
【００６３】
タイマ／外部割込み模擬２３は、“ｓｃａｎ＿ｂｔｍ＿ｏｎ”，“ｃｏｕｎｔ＿ｄｏｗｎ”を定義する。この実施の形態では、割込み模擬定義部に相当する。命令セットシミュレータ２ｄは、コマンド列生成部２ｃが生成する実行コマンドファイルに記述されたコマンドスクリプトに基づいて、上記タイマ／外部割込み模擬２３を実行する。
図２７は、割込みハンドラ関数を用いて、試験パターンを記述したものである。図２７は、図２６に示した拡張試験パターンファイル２１のパターン記述部に代わって、割込みハンドラ関数として実際のプログラムで記述されたＣ関数を使って記述したものである。図２７では、実際のタイマ割込みハンドラ関数が１００００回ループし、試験時間が大きくなる。一方、図２６のように割込み模擬定義部（あるいは、タイマ／外部割込み模擬２３）を使ったパターン記述部では、１０回ループに機能縮退して単体試験時間を短くなる。これは、割込み模擬定義部は、１００００回のループを１０回へ削減するようにコマンドを生成しているからである。
【００６４】
以下に、拡張試験パターンファイル２１、別名定義ファイル２９、プログラムソースファイル１８を入力とした命令セットシミュレータを使った拡張された連続テストパターン実行システム２ｂを説明する。
図６に、命令セットシミュレータを使った拡張された連続テストパターン実行システム２ｂの処理構成図を示している。本実施の形態は、実施の形態１で説明したコマンド列生成部２ｃへ、割込み対応機能コマンドを生成する機能を追加する拡張により容易に実現できる。
図２８は、この実施の形態のコマンド列を生成するコマンド列生成部２ｃの処理フローを示す。
コマンド列生成部２ｃは、割込み発生場所をプラグマ文として記述したプログラムソースファイル１８、割込み処理関数又はタイマ／外部割込み模擬２３と割込み発生指示を付加した拡張試験パターンファイル２１及び、別名定義ファイル２９とを用いて命令セットシミュレータ２ｄが自動実行できる実行スクリプトファイルを生成する。
【００６５】
図２８は、図７の手順にＳ２８２を追加したものである。従って、Ｓ２８２を除く処理は、図７で同じ符号をつけた動作と同様であるため、説明を省略する。
Ｓ２８２は、割込み対応機能コマンド列を生成する。
図２９は、割込み対応機能コマンド列を生成する（Ｓ２８２）の動作の一例を示した図である。
コマンド列生成部２ｃは、実際に、図２５、図２６又は図２７の入力ファイルを基に、図２８、図２９の処理フローに従い、生成された実行コマンドスクリプトファイル３１を図３０、図３１に示す。
尚、命令セットシミュレータ２ｄと出力整形部２ｅに関しては、実施の形態１に示した方法と何ら変わらない。これにより、割込みを要求する試験対象モジュールも本実施例により自動単体試験が可能となる。
【００６６】
以上のように、実施の形態１の自動単体試験システムに加え、以下の機構を備える自動単体試験システムを説明した。
対象関数がタイマ割込みや外部割込みによって変数値の書き換えがある場合、プログラム中の任意の場所で割込み発生を指定し、自動単体試験システムが有するコマンドスクリプトを用いてその割込みを模擬し変数値を書き換え、単体試験を可能であることを特徴とする。
また、コマンドスクリプトによる割込み模擬の代わりに、実際のプログラムで記述された割込みハンドラ関数やタイマ関数を使って変数値を書き換える単体試験を行うことを特徴とする。
【００６７】
実施の形態３．
上記実施の形態１及び実施の形態２では、手続型言語としてＣ言語を一例として説明したが、この実施の形態では、アセンブリ言語を用いて説明する。
図３２は、実施の形態１において、アセンブリ言語を用いた場合、コマンド列生成部２ｃが実行スクリプトファイルを生成する動作の一例を示している。図１９は、図７のＳ７４の処理が複数の処理に分割されたものである。
図３２に示すＳ１６４の動作も同様に分割すると、実施の形態２において、Ｃ言語に変わってアセンブリ言語を用いた場合の動作となる。
このように、この発明の自動単体試験システムは、手続型言語としてアセンブリ言語にも対応できる一例を示した。
【００６８】
実施の形態４．
上記実施の形態１では、拡張試験パターンファイル２１は、ビット対応記述２５と、初期値設定記述２７とプロセッサ非依存の型定義２８との３つを備える場合を説明した。しかしながら、上記３つの機能を別々に備える場合であっても構わない。また、上記３つの機能のうち、２つの機能を組み合わせた機能を備える場合であっても構わない。
【００６９】
更に、実施の形態２では、拡張試験パターンファイル２１は、ビット対応記述２５と、初期値設定記述２７とプロセッサ非依存の型定義２８と割込み対応記述２２とを備える場合を説明した。しかしながら、上記割込み対応記述２２のみを備える場合であってもよい。更に、上記４つの機能のうち、２つ、あるいは、３つの機能を組み合わせた機能を備える場合であっても構わない。
【００７０】
【発明の効果】
以上のようにこの発明によって、試験対象モジュールが割込み処理を期待して作成されている場合における自動単体試験が可能となった。
【００７１】
また、試験対象モジュールに１ビット変数が使用されている場合、自動単体試験が可能となった。
【００７２】
従来、モジュール内の分岐パスにより未設定変数となる出力グローバル変数は、自動的に期待値を照合する自動期待値照合ができなかったが、初期値設定機能により自動期待値照合が可能となった。
【００７３】
試験対象モジュールをビット幅の異なるプロセッサ（例：１６ビットＣＰＵから３２ビットＣＰＵ）に移植する場合、変数のビット幅が変わり同一の試験パターンファイルが使えない問題も、プロセッサ非依存型の導入により解決された。
【００７４】
Ｃ言語の“＃ｄｅｆｉｎｅ”文で定義された別名変数も、本発明では試験者が試験パターンファイル作成時に使用できるようになった。
【００７５】
自動単体試験の出力結果に性能情報データが出力できることで、試験対象モジュールの性能見積もりができるようになった。
【図面の簡単な説明】
【図１】 実施の形態１の組込みソフトウェア用自動単体試験システムの構成の一例を表す図である。
【図２】 実施の形態１において使用する試験対象となるソースプログラムファイルの一例である。
【図３】 実施の形態１において使用する試験パターンファイルに格納される試験パターンの一例を示す図である。
【図４】 本発明で使用するプロセッサ非依存の型定義一覧である。
【図５】 実施の形態１において使用する別名定義ファイルの一例である。
【図６】 本発明における命令セットシミュレータを使った連続テストパターン実行システムの処理構成図である。
【図７】 実施の形態１における試験パターンファイルのコマンド展開方式を示した動作フローチャート図である。
【図８】 実施の形態１において生成された実行コマンドスクリプトファイルの一例である。
【図９】 実施の形態１において生成された実行コマンドスクリプトファイルの一例である。
【図１０】 実施の形態１において生成された実行コマンドスクリプトファイルの一例である。
【図１１】 実施の形態１において生成された実行コマンドスクリプトファイルの一例である。
【図１２】 実施の形態１において生成された実行コマンドスクリプトファイルの一例である。
【図１３】 実施の形態１において１ビットデータの読み出し／書き込みに使用する拡張コマンドマクロファイルの例である。
【図１４】 実施の形態１において１ビットデータの読み出し／書き込みに使用する拡張コマンドマクロファイルの例である。
【図１５】 実施の形態１において１ビットデータの読み出し／書き込みに使用する拡張コマンドマクロファイルの例である。
【図１６】 実施の形態１において１ビットデータの読み出し／書き込みに使用する拡張コマンドマクロファイルの例である。
【図１７】 実施の形態１において１ビットデータの読み出し／書き込みに使用する拡張コマンドマクロファイルの例である。
【図１８】 実施の形態１において命令セットシミュレータより出力される実行結果ファイルの一例である。
【図１９】 実施の形態１において命令セットシミュレータより出力される実行結果ファイルの一例である。
【図２０】 実施の形態１における単体試験の出力ファイルの一例である。
【図２１】 実施の形態１において使用する試験パターンファイルに格納される試験パターンの一例を示す図である。
【図２２】 実施の形態１における単体試験の出力ファイルの一例である。
【図２３】 実施の形態２の組込みソフトウェア用自動単体試験システムの構成の一例を表す図である。
【図２４】 実施の形態２において使用する試験対象となるソースプログラムファイルの一例である。
【図２５】 実施の形態２において割込み発生用プラグマを挿入したプログラムソースファイルの一例である。
【図２６】 実施の形態２において使用する試験パターンファイルの一例である。
【図２７】 実施の形態２において割込み処理関数に既存関数を用いた場合の試験パターンファイルのパターン記述部の一例である。
【図２８】 実施の形態２における試験パターンファイルのコマンド展開方式を示した動作フローチャート図である。
【図２９】 実施の形態２において割込み対応機能の処理方式を示したフローチャート図である。
【図３０】 実施の形態２において生成された実行コマンドスクリプトファイルの一例である。
【図３１】 実施の形態２において生成された実行コマンドスクリプトファイルの一例である。
【図３２】 実施の形態３における試験パターンファイルのコマンド展開方式を示した動作フローチャート図である。
【図３３】 第３の従来例における組込みソフトウェア用自動単体試験システムの構成図である。
【符号の説明】
１ａ 出力ファイル、２ａ 性能情報、２ｂ 命令セットシミュレータを使った拡張された連続テストパターン実行システム、２ｃ コマンド列生成部、２ｄ命令セットシミュレータ、２ｅ 出力整形部、１０ 組込みソフトウェア用自動単体試験システム、１１ プログラムメモリ、１２ 開始アドレス、１３ 終了アドレス、１４ データメモリ、１５ 汎用レジスタ、１６ プログラムカウンタ、１７ 試験パターンファイル、１８ プログラムソースファイル、１９ 命令セットシミュレータを使った連続テストパターン実行システム、２０ 本発明の組込みソフトウェア用自動単体試験システム、２１ 拡張試験パターンファイル、２２ 割込み対応記述、２３ タイマ／外部割込み模擬、２４ 割込み発生用プラグマ、２５ ビット対応記述、２６ ビット、２７ 初期値設定記述、２８ プロセッサ非依存の型定義、２９ 別名定義ファイル、３０ 拡張連続テストパターン実行システム、３１ 実行コマンドスクリプトファイル、３２ 実行結果ファイル、９９ バス（システムバス）。[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a test apparatus and a test method for a module of embedded software, and prepares an input value and an expected output value as a test pattern, automatically sets an input value of a test pattern before executing a test target module, This is to automate the output of the test result by automatically collating the output value actually obtained and the expected value prepared as the test pattern.
[0002]
[Prior art]
Embedded software written in a procedural language such as C language or assembly language has a program composed of modules such as functions and subroutines. The unit test is to verify the software function for each module. In the above verification, before executing the module, values are set in the input variables (data memory) and general-purpose registers, and the module is executed. At the end of module execution, the values of the output variables (data memory) and general-purpose registers are This can be done by checking whether the expected value is reached.
[0003]
Three typical methods are listed as techniques for carrying out unit tests.
Use of instruction set simulator.
Use of an in-circuit emulator (hereinafter referred to as “ICE”).
Use of automated unit testing tools for embedded applications.
[0004]
The instruction set simulator is used to debug each of the above assembler instructions (one instruction in machine language) on a computer different from the target computer in debugging software that checks whether the program written in the machine language of the target computer is correct. ) Are sequentially interpreted and simulated. The basic functions of the instruction set simulator are as follows: (1) Reading / writing values to memory and general-purpose registers, (2) Executing programs, (3) Stopping under specified conditions (breakpoint / condition stop), (4) For example, an execution address is set for a program counter (hereinafter referred to as “PC”).
Software written in C language generates an assembler description using a cross compiler, and an instruction set simulator can be used in the same manner.
[0005]
As a first conventional example, there is a method using an instruction set simulator. The procedure for using the instruction set simulator is shown below.
(Procedure 1) The start address of the designated target module is set in the PC.
(Procedure 2) Set a breakpoint at the end address of the specified module.
(Procedure 3) A value is set in a variable (data memory) or general-purpose register as an input, and the module is executed.
(Procedure 4) After stopping execution in Procedure 2, the tester determines the value of the output variable (data memory) or general-purpose register.
A unit test can be performed manually by executing the above steps 1 to 4.
[0006]
As a second conventional example, there is a method using ICE.
ICE is an apparatus in which a debug function is added to a target processor instead of the instruction set simulator described in the conventional example 1. The debugging function is equivalent to the instruction set simulator and can be executed at high speed. Therefore, the unit test can be performed in the same manner as the method shown in the conventional example 1.
[0007]
As a third conventional example, there is a method of using an automatic unit test system using an instruction set simulator (hereinafter, the automatic unit test system may be referred to as “system”).
FIG. 33 is a configuration diagram of an automatic unit test system AMS (Advanced Module Simulator) configured by using an instruction set simulator XASS-V manufactured by a commercially available system GAIO.
Configuration diagram 10 of the entire system, program memory 11 of the test target program, start address 12 of the test target program, end address 13 of the test target program, data memory 14 of the test target program, general-purpose register 15, program counter 16, test pattern file 17, a program source file 18 written in C language or assembly language, a continuous test pattern execution system 19 using an instruction set simulator, and an output file 1a. The test pattern file 17 is a file in which a plurality of test patterns of a test target function (one test item in which an input value and an expected value are written) are described. (Procedure 1) to (Procedure 4) shown in the first conventional example are automatically executed for each test pattern, and a unit test is performed.
[0008]
As a fourth conventional example, there is JP-A-11-306042, “Software development support apparatus and debugging method”. This relates to a method for implementing the operation specified by the tester when the condition (event) specified by the tester is satisfied as a method for realizing the instruction set simulator mentioned in the first conventional example.
[0009]
As a fifth conventional example, there is Japanese Patent Laid-Open No. 05-313941 “Computer Program Debugging Method”.
This relates to a method for performing debugging by transferring execution control to a debug support unit by an interrupt (breakpoint) specified by a tester as a method for realizing the instruction set simulator described in the first conventional example.
[0010]
[Problems to be solved by the invention]
In the first and second conventional examples, there is no mention of a method for automating the unit test. In the fourth and fifth conventional examples, only the implementation method of the execution control command for the instruction set simulator, which is the realization technique of the first conventional example, is described, and the realization method is described as an automatic unit test system. It is not a thing.
As problems of the automatic unit test system for embedded software targeted by the present invention, the following problems are listed based on the automatic unit test system described in the third conventional example.
[0011]
In the third conventional example, a unit test of a module that does not use a timer or an external interrupt is possible. However, a module that leaves a loop only after a variable value is rewritten by a timer or an external interrupt becomes an infinite loop and cannot be completed and cannot be tested.
[0012]
In the third conventional example, it is possible to perform a unit test of a module that does not use a 1-bit variable. However, when a 1-bit variable is allocated in the form of a bit variable to a bit position specified by a char type or int type variable and used directly in the program, the ANSI standard C language uses the bit type. Was not supported, and there was a problem that this could not be read or written directly.
[0013]
In the third conventional example, a unit test of a module in which a value is always set in an output variable is possible. However, in a program having a global variable in which a value is set / not set due to a branch or the like, There was a problem that an undefined value occurred at the time of expected value collation, and it was not possible to confirm the match.
[0014]
In the third conventional example, if the target processor has the same bit width (for example, 16-bit CPU or 32-bit CPU), the module unit test is possible even if the processor is changed, but it is declared as an int type in the program. If the target processor is changed from a 16-bit CPU to a 32-bit CPU, the memory area itself changes and the functions of the original program differ, so the test data file must be recreated. There was a problem.
[0015]
In the third conventional example, a unit test can be performed when there is no variable aliased with a variable written in C language #define in the function, but for a function including an aliased variable, There is a problem that the value of the alias variable cannot be read / written.
[0016]
Furthermore, in the conventional system, only the unit test is provided as a function, but there is a problem that the performance information cannot be obtained by the information on how many instructions are executed during automatic execution.
[0017]
An object of the present invention is to solve the above problems and to automate the testing of a program written in a procedural language.
[0018]
[Means for Solving the Problems]
The test system according to the present invention is a test system for testing a program described in a procedural language.
The above program contains a description that specifies the occurrence of an interrupt,
An interrupt simulation file storing interrupt processing for executing an instruction for generating the above-mentioned interrupt in a simulated manner;
A test pattern file storage unit for storing a test pattern file describing an instruction to execute the interrupt processing stored in the interrupt simulation file;
A command sequence for inputting the program, reading the test pattern file stored in the test pattern file storage unit, and setting the execution of the interrupt processing in response to a description specifying the occurrence of an interrupt included in the program; A command sequence generation unit that generates an execution script file describing a command sequence for executing the program and a command sequence for outputting an execution result;
Read the execution script file generated by the command sequence generation unit and the external interrupt simulation file, execute the input execution script file using the interrupt processing stored in the external interrupt simulation file, and execute the execution result And the execution part that outputs
It is characterized by providing.
[0019]
The test system according to the present invention is a test system for testing a program described in a procedural language.
The program includes an instruction for accessing 1-bit data,
A test pattern file storage unit for storing a test pattern file describing a bit type defining the data type of the 1-bit data and test data including the bit type data;
A command definition storage unit for storing a bit access command for accessing the bit type data;
The program is input, the test pattern file stored in the test pattern file storage unit and the bit access command stored in the command definition storage unit are read, and the test data described in the test pattern file is accessed by the bit access A command string generation unit that generates an execution script file that describes a command string that is set using a command, a command string that executes the program, and a command string that outputs an execution result;
Input the bit access command stored in the command definition storage unit and the execution script file generated by the command sequence generation unit, execute the input execution script file using the bit access command, and execute the execution result And the execution part that outputs
It is characterized by providing.
[0020]
The test system according to the present invention is a test system for testing a program described in a procedural language.
The above program contains global variables,
A test pattern file storage unit for storing a test pattern file describing a variable initial value that defines an initial value to be set to a global variable described in the program;
A command sequence for inputting the program, reading a test pattern file stored in the test pattern file storage unit, and setting a variable initial value described in the test pattern file to the global variable, and a command sequence for executing the program And a command string generation unit that generates an execution script file that describes a command string for outputting the execution result executed,
An execution unit that inputs the execution script file generated by the command sequence generation unit, executes the input execution script file, and outputs the execution result.
It is characterized by providing.
[0021]
The test system according to the present invention is a test system for testing a program described in a procedural language.
The program includes a data type that depends on a processor executing an instruction,
A test pattern file storage unit for storing a test pattern file describing test data used when executing the program and a data type definition defining a data type depending on a processor described in the program;
A command sequence for inputting the program, reading a test pattern file stored in the test pattern file storage unit, and setting test data used in the program using a data type definition described in the test pattern file; A command sequence generation unit that generates an execution script file describing a command sequence for executing the program and a command sequence for outputting the execution result;
An execution unit that inputs the execution script file generated by the command sequence generation unit, executes the input execution script file, and outputs the execution result.
It is characterized by providing.
[0022]
The test system according to the present invention is a test system for testing a program described in a procedural language.
The above procedural language allows alias definition to define the name of one variable with an alias,
The program includes the alias definition variable defined as the alias,
A test pattern file storage unit for storing a test pattern file describing a variable value to be set in the alias definition variable;
An alias definition file that stores the alias definition variable defined as the alias in association with the name of the one variable, and
Input the program, read the test pattern file stored in the test pattern file storage unit and the alias definition file, rewrite the alias definition variable described in the program source file to the name of the one variable, Generates an execution script file that describes the command sequence that sets the variable value described in the test pattern file to the one rewritten variable, the command sequence that executes the program, and the command sequence that outputs the execution result A command sequence generator to
An execution unit that inputs the execution script file generated by the command sequence generation unit, executes the input execution script file, and outputs the execution result.
It is characterized by providing.
[0023]
The test pattern file storage unit further includes an expected value for predicting the execution result,
The command sequence generation unit further compares the execution result with the expected value and outputs a comparison result to the execution script file, and a command sequence for executing a performance measurement command for measuring the performance of the program And a command sequence for executing the performance information output command for outputting the performance information measured by the performance measurement command,
The execution unit executes the performance measurement command and the performance information output command, and outputs the comparison result and performance information in addition to the execution result.
The test system further includes:
And an output shaping unit that inputs the execution result, the comparison result, and the performance information output by the execution unit, and outputs the input execution result, the comparison result, and the performance information.
[0024]
The program includes an instruction for accessing 1-bit data,
The test system further includes a command definition storage unit that stores a bit access command for accessing the bit-type data.
The test pattern storage unit further stores a test pattern file including a bit type defining a data type of the 1-bit data and test data including the bit type data,
The command sequence generation unit reads a bit access command stored in the command definition storage unit, and sets a command sequence for setting test data described in the test pattern file using the bit access command to the execution script file. Describe,
The execution unit inputs a bit access command stored in the command definition storage unit, and executes the input execution script file using the bit access command.
[0025]
The above program contains global variables,
The test pattern file stores a test pattern file including a variable initial value that defines an initial value to be set to a global variable described in the program,
The command sequence generation unit describes a command sequence for setting a variable initial value described in the test pattern file in the global variable in the execution script file.
[0026]
The program includes a data type that depends on a processor executing an instruction,
The test pattern file storage unit stores a test pattern file including test data used when executing the program and a data type definition that defines a data type depending on a processor described in the program,
The command sequence generation unit describes a command sequence for setting test data used in the program in the execution script file using the data type definition described in the test pattern file.
[0027]
The above procedural language allows alias definition to define the name of one variable with an alias,
The above program contains alias definition variables that are aliased,
The test pattern file storage unit stores a test pattern file including a variable value to be set in the alias definition variable,
The test system further includes an alias variable file that associates the alias-defined variable defined as the alias with the name of the one variable.
The command sequence generation unit inputs the alias definition file, rewrites the alias definition variable described in the program source file to the name of the one variable, and rewrites the variable value described in the test pattern file. A command sequence to be set in one variable is described in the execution script file.
[0028]
A test system according to the present invention includes an interrupt handler function for performing interrupt processing, and tests a program described in a procedural language.
The above program contains a description that specifies the occurrence of an interrupt,
A test pattern file storage unit for storing a test pattern file describing an instruction to execute the interrupt handler function;
A command sequence for inputting the program, reading the test pattern file stored in the test pattern file storage unit, and executing the interrupt handler function in response to a description specifying the occurrence of an interrupt included in the program, A command sequence generation unit that generates a command sequence for executing the program and a command sequence for outputting the execution result, and generates an execution script file describing the generated command sequence;
An execution unit that inputs the execution script file generated by the command sequence generation unit, executes the input execution script file using the interrupt handler function, and outputs the execution result.
It is characterized by providing.
[0029]
The execution unit is one of an instruction set simulator and an in-circuit simulator.
[0030]
The procedural language includes any one of C language and assembly language.
[0031]
The test method according to the present invention is a test method for testing a program written in a procedural language,
Write a description that specifies the occurrence of an interrupt to the above program,
Generate an interrupt process that executes an instruction that simulates the above interrupt, store the generated interrupt process,
Generate a test pattern file that describes the instruction to execute the above interrupt processing,
A command sequence for inputting the program and the test pattern file and setting execution of the interrupt processing in response to a description designating the occurrence of an interrupt written in the program, and a command for executing the program Generate an execution script file that describes the sequence and the command sequence that outputs the execution result.
The execution script file is input, the interrupt process is read, the read execution process is executed using the read interrupt process, and the execution result is output.
[0032]
The test program according to the present invention is a test program for realizing a test of a program described in a procedural language on a computer.
Write a description that specifies the occurrence of an interrupt to the above program,
An interrupt process generation process for generating an interrupt process for executing an instruction for pseudo-generating the interrupt and storing the generated interrupt process;
A test pattern file storing process for generating a test pattern file describing an instruction to execute the interrupt process generated in the interrupt process generating process and storing the generated test pattern file;
A command sequence that inputs the program, reads the test pattern file stored in the test pattern file storage process, and sets the interrupt process to be executed in response to the description specifying the occurrence of the interrupt written in the program And a command sequence generation process for generating an execution script file describing a command sequence for executing the program and a command sequence for outputting the execution result,
An execution process that inputs the execution script file generated by the command sequence generation process, executes the input execution script file using the interrupt process, and outputs the execution result.
It is characterized by providing.
[0033]
A computer-readable recording medium for recording a test program for realizing a test of a program described in a procedural language according to the present invention by a computer,
Write a description that specifies the occurrence of an interrupt to the above program,
An interrupt process generation process for generating an interrupt process for executing an instruction for pseudo-generating the interrupt and storing the generated interrupt process;
A test pattern file storage process for storing a test pattern file describing an instruction to execute the interrupt process generated in the interrupt process generation process;
A command sequence that inputs the program, reads the test pattern file stored in the test pattern file storage process, and sets the interrupt process to be executed in response to the description specifying the occurrence of the interrupt written in the program A command sequence generation process for generating an execution script file describing a command sequence for executing the program and a command sequence for outputting an execution result, and storing the generated execution script file;
An execution process that inputs the execution script file generated by the command sequence generation process, executes the input execution script file using the interrupt process, and outputs the execution result.
And a computer-readable recording medium for recording a test program.
[0034]
DETAILED DESCRIPTION OF THE INVENTION
Embodiment 1 FIG.
FIG. 1 shows an example of a configuration diagram of an automatic unit test system according to this embodiment (hereinafter, the automatic unit test system may be referred to as “system” or “test system”).
In addition to the conventional example shown in FIG. 33, the following functions are provided.
The extended test pattern file (test pattern file) 21 is a test pattern file whose function is expanded compared to the conventional test pattern file. Specifically, a bit correspondence description 25, an initial value setting description 27, and a processor-independent type definition 28 are included.
A bit correspondence description (read / write setting description of 1-bit data) 25 enables access to 1-bit data. 1-bit data is defined as a bit type in the automatic unit test system.
The initial value setting description (variable initial value) 27 defines an initial value to be set in the global variable. The initial value setting description 27 is used to collate an expected value with an execution result by setting an initial value in a global variable in advance.
The processor-independent type definition (data type) 28 defines a data type depending on the processor. Setting data using a defined data type prevents inconsistencies when accessing data of a processor-dependent data type.
[0035]
An alias definition file 29 is provided as an aliasing variable utilization function.
The alias definition file 29 is a file that associates alias definition variables that are alias-defined with variable names.
The following functions are provided as performance information output functions.
The performance information 2a is output to the output file.
The direct read / write function of the bit data value is realized by providing an extended command macro (described later with reference to FIG. 6 and the like) in which the bit accesses other data.
The extended continuous test pattern execution system 2b using the instruction set simulator includes a command sequence generation unit 2c for processing the extended test pattern file 21, and expands the function by performing a test using the instruction set simulator. To do. The continuous test pattern execution system 2b will be described later with reference to FIG.
[0036]
Although not clearly shown in FIG. 1, the extended test pattern file (test pattern file) is stored in a test pattern file storage unit which is a storage area.
Similarly, the alias definition file 29 is stored in the alias definition file storage unit, and the program source file is stored in the program source file storage unit. Other files are also stored in the storage area, although not specified.
[0037]
In this embodiment, the C language is described as an example of the procedural language. However, the test apparatus according to the present invention can be applied to other procedural languages. In this specification, the procedural language includes languages such as C language, C ++ language, FORTLAN, and assembly language.
In this embodiment, an instruction set simulator is described as an example as an execution unit that simulates an operation in which a processor of a target machine executes an instruction. However, the execution unit is not limited to the instruction set simulator, and may be another unit such as ICE.
[0038]
The test target function decide will be described using the program source of FIG.
The variable “PFLAG” is a 1-bit variable that indicates the lower third bit of the 8-bit memory area with the variable name “condition”, and is used as an input global variable in the function. The variable “SM” is a variable with the variable name “system_mode.all” given as an alias, and is used as an output global variable in the function. The variable “result” and the variable “r” are also output global variables set by this function. The variable “base” is an input global variable. The variable “r” is an input / output global variable whose value is read and changed. This function returns the value of the variable “r” as a return value.
[0039]
Here, problems when the program source test shown in FIG. 2 is tested using the automatic unit test system of the third conventional example will be described.
Since the variable “PFLAG” is an aliased variable, there is a problem that it cannot be used directly in the test pattern file 17 shown in FIG. Further, since the variable “condition.bit.b2” pointed to by the variable “PFLAG” is a variable indicating 1 bit, there is a problem that it cannot be handled by the automatic unit test system of the third conventional example. In order to verify “condition.bit.b2”, only a method for confirming the third bit of the variable “condition” by the tester is provided. In addition, since the aliasing variable “SM” cannot be handled as a test object, there is a problem that the test pattern file 17 must be used by replacing it with “system_mode.all”. In addition, the variable “s” may not be set in the branch path in the function, and there is a problem that the expected value cannot be set in advance. If this program is a program targeting a 16-bit CPU, the variable “s” or variable “r” declared in the int type is 16 bits, but if moved to a 32-bit CPU, a 32-bit variable There is a problem that the same test pattern file cannot be used during testing.
[0040]
In order to solve these problems, an embodiment using an extended test pattern execution system 2b using an extended test pattern file 21, an alias definition file 29, and an instruction set simulator will be described.
FIG. 3 is a diagram showing an example of test patterns stored in the extended test pattern file 21 devised to solve the above problems.
“Function” indicates the name of the function to be tested, “project” indicates the name of the project to be the target of this program, “src” indicates the name of the file in which this function is described, and “clock” indicates the clock cycle of the target CPU. Variables to be tested are roughly divided into arguments, input variables, return values, and output variables. Internal variables are not tested because they do not affect the overall function of the program.
[0041]
The variable to be tested is an argument between <arg> and </ arg> (argument part), the input variable is between <in> and </ in> (input variable part), and the return value is <ret> to During </ ret> (return value part), the output variable is declared between <out> and </ out> (output variable part). The argument part and the input variable part are described in the same format. Since there are no arguments in this example, the contents of the argument part are not described. Variables (input variables, output variables, etc.) are defined in the format of “variable name / type”. The type used here is a processor-independent type, and the type shown in FIG. 4 is used.
FIG. 4 is a diagram showing an example of a list of processor-independent type definitions 28 stored in the extended test pattern file 21.
In the list of the processor-independent type definitions 28 shown in FIG. 4, a 1-bit variable frequently used in embedded software is newly added as a bit type. The Bit type included in the processor-independent type definition shown in FIG. 4 is a data type used in the bit correspondence description 25.
The return value describes only the "type". When there is no return value, nothing is written in the return value section or “void” is described. In this example, the description returns a 16-bit int type.
[0042]
There are two types of output variables. One is written after reading, and the other is written only. Variables that are read and written can be tested if they are defined in both the input variable part and the output variable part. In this example, the variable “r” corresponds to the variable that is read and written. In addition, a write-only variable may not be written by a branch path. In order to realize automatic expected value collation in that case, an initial value setting function was provided. The format is specified by “variable / type / initial value”. In this example, the write-only variable corresponds to the variable “result”, the variable “s”, and the alias variable “SM”.
[0043]
The pattern description part declared between <Vector> to <Vector> describes values in the order of “argument part, input variable part | return value part, output variable part”. The test vector description section shown in FIG. 3 has eight lines of description, and one line of description indicates one test pattern. In the example of FIG. 3, eight test patterns are described. After “|”, an expected output value is described, and the automatic unit test system 20 automatically collates with the actual execution result. The argument part is a declaration part from the beginning of the line to “,” and is omitted because there is no argument in this example. The input variable part is a declaration part from “,” to “|”, and is described in the order of “PFLAG, r, base” in this example. The return value is a declaration part from “|” to “,”, and in this example, an expected value of 16-bit int type is described. The output variable part is a declaration part from “,” to the end of the line, and in this example, expected values are described in the order of “SM”, “result”, “r”, “s”.
[0044]
In the test pattern of the first line of this example, “PFLAG = 0, r = 0, base = 0” is input and set, and the output expected values are “return value → 0”, “SM → 0”, “result → A pattern for confirming “0”, “r → 0”, “s → 0” is described.
[0045]
FIG. 5 is a diagram showing an example of the contents of the alias definition file 29.
As described above, since the entity of the alias variable “SM” is “system_mode.all” and is not directly used in the function, the variable “SM” is all included in “system_mode.all” when creating test data. There is a burden of creating a replacement. As shown in this example, the name is associated with the "alias type actual program variable" format, and the system automatically replaces the name. In this example, the variable “PFLAG” is an aliased bit variable, and the instruction set simulator cannot directly handle “condition.bit.b2”, which is a direct entity, because it is a bit type. As a format for this, the problem is solved by introducing “an alias variable bit position where an alias type bit variable exists”, and the definition is as shown in FIG.
[0046]
The extended continuous test pattern execution system 2b using the instruction set simulator with the extended test pattern file 21, the alias definition file 29, and the program source file 18 as inputs will be described below.
FIG. 6 shows the processing configuration of the extended continuous test pattern execution system 2b using an instruction set simulator.
An extended continuous test pattern execution system 2b using an instruction set simulator includes a command string generation unit 2c, an instruction set simulator 2d, and an output shaping unit 2e.
7 shows a process in which the command sequence generation unit 2c automatically generates an execution command script that can be automatically executed by the instruction set simulator 2d using the extended test pattern file 21 shown in FIG. 3 and the alias definition file 29 shown in FIG. It is an example of the flowchart figure of.
The operation in which the command sequence generation unit 2c generates an execution command script will be described with reference to FIG.
[0047]
The command sequence generation unit 2c generates an initial value setting command sequence before the test execution and an output command sequence before the test (S71). The initial value setting command sequence is a command sequence for setting initial values set in advance in the variables before the test is executed. The output command sequence is a command sequence for outputting test results.
At this time, the command sequence generation unit 2c performs other initial processing (for example, generation of a header of an execution command script file, etc.).
[0048]
Next, the command string generation unit 2c generates a command string for setting a value to the input variable (S72). When the target variable is an alias definition variable, the command string generation unit 2c uses the alias definition file to replace the alias definition variable with the actual variable name.
The command string generation unit 2c generates a command string for setting a value to the output variable with an initial value (S73). As in S72, when the target variable is an alias definition variable, the command string generation unit 2c uses the alias definition file 29 to replace the alias definition variable with the actual variable name.
[0049]
The command string generation unit 2c generates a CALL command for executing the target function (S74). The CALL command for executing the target function is a command for starting the function to be tested.
The command string generation unit 2c generates a comparison result output command between the output variable value and the expected value after the execution is stopped (S75). The comparison result output command string is a command string that outputs a comparison result between an output variable value, which is an execution result of the function to be tested, and an expected value in which the test result is predicted in advance to the execution result file 32.
Next, the command sequence generation unit 2c determines whether or not the processing of S72 to S76 has been performed for all the test patterns described in the extended test pattern file 21. When the above processing is performed for all the test patterns (when it is the final test pattern), S77 is executed. If there is still a test pattern that has not been subjected to the above processing, the processing of S72 to S76 is repeated.
[0050]
When the above processing is performed for all test patterns (when the test pattern is the final test pattern), an output command string after the test is completed is generated. The output command sequence is a command sequence for outputting information at the end of the test to the execution result file 32. Through the above procedure, the command sequence generation unit 2c uses the test pattern file 21, the alias definition file 29, and the program source file 18 to execute the execution command script file 31 in which the variable defined by the alias is replaced with the actual variable. Generate automatically.
[0051]
Actually, the contents of the execution command script file 31 generated based on the program file 18 of FIG. 2, the extended test pattern file 21 of FIG. 3, and the alias definition file 29 of FIG. 5 are shown in FIGS.
The execution command script file 31 shown in FIG. 8 implements the use of an alias (#define) variable and an output data initial value setting function. The reading / writing / comparison of 1-bit data is realized by the extension command macro 33 of “store_flag” (reading), “print_flag” (writing), and “cmp_flag” (comparison) shown in FIGS.
13 to 17 are diagrams illustrating an example of the extended command macro 33.
The instruction set simulator 2d is executed with the generated execution command script file 31 as an input. After the execution is completed, an execution result file 32 is output.
18 and 19 show an example of the execution result file 32 that is output.
[0052]
In order to make it easier for the tester to understand the result, the output shaping unit 2e formats the execution result file 32.
An example of the formatted output file 1a is shown in FIG.
The formatted output file includes performance information 2b for each test pattern. Performance information for each test pattern is realized by using the cycle count function of the instruction set simulator 2d (the cycle is reset to 0 with “reset cycle (set cycle / reset)” and displayed with “show cycle” after execution). Yes.
This can be realized by generating a command string of “reset cycle (set cycle / reset)” and “show cycle” in the execution command script of FIGS. “Reset cycle (set cycle / reset)” is a performance measurement command for measuring performance, and “show cycle” is a performance information output command for outputting measured performance information.
The portions described as “execution result” and “performance information” of the test in FIG. 20 are the portions indicating the execution result and the performance information, respectively.
[0053]
The results of testing with another test pattern file will be described with reference to FIGS. In this case, an example in which the execution result is NG is shown. FIG. 21 shows test pattern file data, and FIG. 22 shows an example of test results including execution results and performance information. In the example shown in FIG. 21, there are four test patterns. FIG. 22 shows the case where the expected value is NG in the first line of the execution result and performance information, that is, the first test pattern.
Further, this example shows a case where the coverage does not become 100% as a result of not performing a sufficient test by reducing the test pattern.
[0054]
The present embodiment is intended for a program written in C language, but after compiling / linking, it is converted into a machine language (assembly language), and an association between the program code and the machine language is realized by an instruction set simulator. This system uses this function. Even if the target language is an assembly language, it can be easily realized by using the function of this instruction set simulator.
[0055]
As described above, as an example of a procedural language, a program written in C language for embedding and test data (input value and expected value pattern) of a function to be tested therein are input, and a pattern An automatic unit test system for embedded software that has the function of automatically executing the function to be tested every time and automatically collating the executed variable value with a predetermined expected value. Explained.
When 1-bit data is used in the target function, a bit type is newly provided in the system, and the read / write setting of the value for the bit data can be directly described in the test data.
In addition, when only writing to a global variable is performed in the target function, an initial value is described and set in the test data for the variable.
When the test target program is ported to another processor (for example, changing from a 16-bit CPU to a 32-bit CPU) and a unit test is performed, the test data is described by describing test data using a processor-independent type definition. A feature of sharing files.
When a variable used in the target function is aliased (for example, #defineSM system_mode.all), even if the alias variable is used in the test data file, the value can be read / written to the variable. It is characterized by becoming.
Furthermore, the performance estimation information can also be output by counting the assembler instructions executed during automatic execution.
[0056]
Embodiment 2. FIG.
An embodiment will be described in which the following functions are added to the embedded software automatic unit test system shown in the first embodiment so that a test target module whose external variable is rewritten by a timer or an external interrupt can be tested.
FIG. 23 shows an example of the configuration of an automatic unit test system (unit test system) of this embodiment.
In addition to the configuration of FIG. 1, an interrupt correspondence description 22, a timer / external interrupt simulation 23, and an interrupt generation pragma 24 are added.
[0057]
The interrupt correspondence description 22 is a description for instructing execution of a process for generating an interrupt, and is described in the extended test pattern file 21 in this embodiment. The timer / external interrupt simulation 23 is an instruction for executing an instruction for generating an interrupt, and is described as a command macro in this embodiment.
The timer / external interrupt simulation 23 may be created as an independent file (interrupt simulation file) as shown in FIG. 23, or may be described in the extended test pattern file 21. In the following description, a case will be described in which the interrupt definition unit is described in the extended test pattern file 21.
The interrupt generation pragma 24 designates execution of the timer / external interrupt simulation 23 in the program. The interrupt generation pragma 24 designates a place where an interrupt is generated. Since the interrupt generation pragma 24 is handled as a comment in the program, it does not affect the compiling and linking of the program.
[0058]
The test target function “scan” will be described using the program source file 18 of FIG.
The variable “time” used in this function has a value indicating a predetermined time set in advance.
The “timer_counter” function is an example of a timer interrupt processing function (handler). The “timer_counter” function is activated by a timer interrupt every 1 ms. When the “timer_counter” function is activated every 1 ms, the variable “time” is decremented by 1 every 1 ms from the set value to notify that a predetermined time has elapsed when the value becomes “0”.
The variable “SCAN_B” indicates the activation state of the interrupt processing function. The interrupt processing function includes “scan_btm_on” and “scan_btm_off”. When an external signal is input to the external interrupt port and the external signal is turned ON / OFF, the interrupt processing functions “scan_btm_on” and “scan_btm_off” are activated, and the values “1” and “0” are respectively set in the variable “SCAN_B”.
[0059]
In the conventional system, it was possible to perform the test by setting the variable “time” to a fixed value. However, when the “time = 0” setting, the while loop could not be processed. On the other hand, when “time ≠ 0” is set, the while loop rotates indefinitely and the module cannot be tested. For the variable “SCAN_B”, the module unit test assuming that the value of the variable “SCAN_B” changes during the function execution cannot be performed for the same reason.
[0060]
In order to solve these problems, an embodiment of an automatic unit test system 20 for extended embedded software in which an interrupt correspondence description 22 is added to the extended test pattern file 21 and an interrupt generation pragma 24 is added to the program source file 18 will be described. .
FIG. 25 shows a program source file 18 of a function “scan” in which an interrupt occurrence location is described using an interrupt generation pragma 24. By inserting a pragma statement (“// # pragma set_do <tag name>”) as a comment statement in the program, the tester can generate an interrupt at an arbitrary location.
[0061]
The pragma statement “// # pragma set_do pscan1” in FIG. 25 is a description indicating that an interrupt is generated immediately before the execution line “time = 0;” is executed with the tag name “pscan1”. Similarly, the programmer sentence “// # pragma set_do pscan2” interrupts with the tag name “pscan2” before the execution line “while (time) {” (checks whether time is not 0) is executed. It is shown that it is generated. The tag name is used for assigning an interrupt processing function or timer / external interrupt simulation 23 that is actually activated in the extended test pattern file 21 to be described later and causing an arbitrary interrupt processing.
[0062]
FIG. 26 shows the extended test pattern file 21 of the test target function “scan”.
In addition to the format shown in the first embodiment, the pattern description part “<vector> to </ vector>” is extended and the interrupt simulation definition part “<macro> to </ macro>” is added. . The interrupt simulation definition unit realizes the function of the timer / external interrupt simulation 23 of FIG. The paragraph indicated by “set_do: ˜end_set_do:” in the pattern description part is the interrupt correspondence description 22. “Set_do:” is a start line indicating that an interrupt is to be generated below. The interrupt to be actually generated is the tag name (“pscan1” used for the interrupt generation pragma 24 shown in the target function source of FIG. "<Tag name> / (interrupt processing function name or interrupt simulation script name)".
In this example, the interrupt simulation script “scan_btm_on” is generated at the location of “pscan1”, and the interrupt simulation script “count_down” is generated in “pscan2”. Thereafter, an interrupt is generated to execute the test pattern, and when “end_set_do:” is found, the generation of the interrupt is stopped. A test pattern that is not written between “set_do: to end_set_do:” is the same processing as in the first embodiment.
[0063]
The timer / external interrupt simulation 23 defines “scan_btm_on” and “count_down”. In this embodiment, it corresponds to an interrupt simulation definition unit. The instruction set simulator 2d executes the timer / external interrupt simulation 23 based on the command script described in the execution command file generated by the command string generation unit 2c.
FIG. 27 describes a test pattern using an interrupt handler function. FIG. 27 is described by using a C function described in an actual program as an interrupt handler function instead of the pattern description part of the extended test pattern file 21 shown in FIG. In FIG. 27, the actual timer interrupt handler function loops 10,000 times, increasing the test time. On the other hand, in the pattern description part using the interrupt simulation definition part (or timer / external interrupt simulation 23) as shown in FIG. 26, the unit test time is shortened by degenerating the function into 10 loops. This is because the interrupt simulation definition unit generates a command so that the loop of 10,000 times is reduced to ten times.
[0064]
Hereinafter, an extended continuous test pattern execution system 2b using an instruction set simulator with the extended test pattern file 21, the alias definition file 29, and the program source file 18 as inputs will be described.
FIG. 6 shows a processing configuration diagram of the extended continuous test pattern execution system 2b using the instruction set simulator. The present embodiment can be easily realized by extending the command string generation unit 2c described in the first embodiment with a function for generating an interrupt handling function command.
FIG. 28 shows a processing flow of the command sequence generation unit 2c that generates the command sequence of this embodiment.
The command sequence generation unit 2c includes a program source file 18 in which an interrupt occurrence location is described as a pragma sentence, an interrupt processing function or timer / external interrupt simulation 23, an extended test pattern file 21 to which an interrupt generation instruction is added, and an alias definition file 29. Is used to generate an execution script file that can be automatically executed by the instruction set simulator 2d.
[0065]
FIG. 28 is obtained by adding S282 to the procedure of FIG. Accordingly, the processing excluding S282 is the same as the operation given the same reference numerals in FIG.
In step S282, an interrupt handling function command sequence is generated.
FIG. 29 is a diagram showing an example of the operation of generating an interrupt handling function command sequence (S282).
The command sequence generation unit 2c actually creates the generated execution command script file 31 in FIGS. 30 and 31 according to the processing flow in FIGS. 28 and 29 based on the input file in FIG. 25, FIG. 26, or FIG. Show.
The instruction set simulator 2d and the output shaping unit 2e are not different from the method shown in the first embodiment. As a result, an automatic unit test can be performed on the test target module that requests an interrupt according to this embodiment.
[0066]
As described above, the automatic unit testing system including the following mechanism in addition to the automatic unit testing system of the first embodiment has been described.
If the target function has a variable value rewritten due to a timer interrupt or an external interrupt, specify the occurrence of the interrupt at any location in the program, rewrite the variable value by simulating the interrupt using the command script of the automatic unit test system The unit test is possible.
In addition, a unit test is performed in which a variable value is rewritten using an interrupt handler function or a timer function described in an actual program instead of an interrupt simulation by a command script.
[0067]
Embodiment 3 FIG.
In the first embodiment and the second embodiment, the C language is described as an example of the procedural language. However, in this embodiment, the description is given using the assembly language.
FIG. 32 shows an example of an operation in which the command string generation unit 2c generates an execution script file when the assembly language is used in the first embodiment. In FIG. 19, the process of S74 of FIG. 7 is divided into a plurality of processes.
If the operation of S164 shown in FIG. 32 is also divided in the same manner, in the second embodiment, the operation is performed when the assembly language is used instead of the C language.
As described above, the automatic unit test system according to the present invention has shown an example that can support an assembly language as a procedural language.
[0068]
Embodiment 4 FIG.
In the first embodiment, the case where the extended test pattern file 21 includes the bit correspondence description 25, the initial value setting description 27, and the processor-independent type definition 28 has been described. However, the above three functions may be provided separately. Moreover, you may be a case where the function which combined two functions among the said three functions is provided.
[0069]
Furthermore, in the second embodiment, the case has been described where the extended test pattern file 21 includes the bit correspondence description 25, the initial value setting description 27, the processor-independent type definition 28, and the interrupt correspondence description 22. However, there may be a case where only the interrupt correspondence description 22 is provided. Furthermore, it may be a case where a function combining two or three functions among the above four functions is provided.
[0070]
【The invention's effect】
As described above, according to the present invention, it is possible to perform an automatic unit test in a case where a test target module is created in anticipation of interrupt processing.
[0071]
In addition, when a 1-bit variable is used for the test target module, an automatic unit test can be performed.
[0072]
Previously, output global variables that became unset variables due to branch paths within modules could not be automatically expected value collated to automatically match expected values, but the initial value setting function enabled automatic expected value matching. .
[0073]
When porting test target modules to processors with different bit widths (eg 16-bit CPU to 32-bit CPU), the problem that the variable bit width changes and the same test pattern file cannot be used is also resolved by introducing a processor-independent type It was done.
[0074]
The alias variable defined by the C language “#define” statement can also be used by the tester when creating the test pattern file in the present invention.
[0075]
The performance information data can be output to the output result of the automatic unit test, and the performance estimation of the module under test can be performed.
[Brief description of the drawings]
FIG. 1 is a diagram illustrating an example of a configuration of an automatic unit test system for embedded software according to a first embodiment.
FIG. 2 is an example of a source program file to be tested used in the first embodiment.
FIG. 3 is a diagram showing an example of a test pattern stored in a test pattern file used in the first embodiment.
FIG. 4 is a list of processor-independent type definitions used in the present invention.
5 is an example of an alias definition file used in Embodiment 1. FIG.
FIG. 6 is a processing configuration diagram of a continuous test pattern execution system using an instruction set simulator according to the present invention.
FIG. 7 is an operation flowchart illustrating a test pattern file command expansion method according to the first embodiment;
8 is an example of an execution command script file generated in the first embodiment. FIG.
FIG. 9 is an example of an execution command script file generated in the first embodiment.
10 is an example of an execution command script file generated in the first embodiment. FIG.
FIG. 11 is an example of an execution command script file generated in the first embodiment.
12 is an example of an execution command script file generated in the first embodiment. FIG.
FIG. 13 is an example of an extended command macro file used for reading / writing 1-bit data in the first embodiment;
FIG. 14 is an example of an extended command macro file used for reading / writing 1-bit data in the first embodiment;
FIG. 15 is an example of an extended command macro file used for reading / writing 1-bit data in the first embodiment;
FIG. 16 is an example of an extended command macro file used for reading / writing 1-bit data in the first embodiment;
17 is an example of an extended command macro file used for reading / writing 1-bit data in Embodiment 1. FIG.
FIG. 18 is an example of an execution result file output from the instruction set simulator in the first embodiment.
FIG. 19 is an example of an execution result file output from the instruction set simulator in the first embodiment.
FIG. 20 is an example of an output file of a unit test in the first embodiment.
FIG. 21 is a diagram showing an example of test patterns stored in a test pattern file used in the first embodiment.
FIG. 22 is an example of an output file of a unit test in the first embodiment.
FIG. 23 is a diagram illustrating an example of a configuration of an automatic unit test system for embedded software according to the second embodiment.
FIG. 24 is an example of a source program file to be tested used in the second embodiment.
FIG. 25 is an example of a program source file in which an interrupt generation pragma is inserted in the second embodiment.
FIG. 26 is an example of a test pattern file used in the second embodiment.
FIG. 27 is an example of a pattern description portion of a test pattern file when an existing function is used as an interrupt processing function in the second embodiment.
FIG. 28 is an operation flowchart showing a test pattern file command expansion method according to the second embodiment;
FIG. 29 is a flowchart showing a processing method of an interrupt handling function in the second embodiment.
30 is an example of an execution command script file generated in the second embodiment. FIG.
FIG. 31 is an example of an execution command script file generated in the second embodiment.
FIG. 32 is an operation flowchart showing a test pattern file command expansion method according to the third embodiment;
FIG. 33 is a block diagram of an automatic unit test system for embedded software in a third conventional example.
[Explanation of symbols]
1a output file, 2a performance information, 2b extended continuous test pattern execution system using instruction set simulator, 2c command sequence generation unit, 2d instruction set simulator, 2e output shaping unit, 10 automatic unit test system for embedded software, 11 Program memory, 12 Start address, 13 End address, 14 Data memory, 15 General purpose register, 16 Program counter, 17 Test pattern file, 18 Program source file, 19 Continuous test pattern execution system using instruction set simulator, 20 Automatic unit test system for embedded software, 21 extended test pattern file, 22 interrupt description, 23 timer / external interrupt simulation, 24 interrupt generation pragma, 25 bit description, 26 bit, 2 7 Initial value setting description, 28 processor-independent type definition, 29 alias definition file, 30 extended continuous test pattern execution system, 31 execution command script file, 32 execution result file, 99 bus (system bus).

Claims (12)

手続型言語で記述されたプログラムを試験する試験システムにおいて、
上記プログラムは、割込みの発生を指定する記述を含み、
上記プログラムに含まれる割込みの発生を指定する記述に対応して実行する割込み処理を記述した割込み模擬ファイルと、上記プログラムに含まれる割込みの発生を指定する記述と上記割込み模擬ファイルに記述された割込み処理との対応関係を記述した試験パターンファイルとを記憶する試験パターンファイル記憶部と、
上記プログラムを入力し、上記試験パターンファイル記憶部に記憶した試験パターンファイルを読み込み、入力した上記プログラムを解析して割込みの発生を指定する記述がある位置を求め、読み込んだ上記試験パターンファイルに基づいて上記割込みの発生を指定する記述に対応する割込み処理を求め、上記割込みの発生を指定する記述がある位置と上記割込み処理とを対応づける第一のコマンド列と、上記プログラムを実行する第二のコマンド列と、実行した実行結果を出力する第三のコマンド列とを記述した実行スクリプトファイルを生成するコマンド列生成部と、
上記コマンド列生成部が生成した実行スクリプトファイルと上記割込み模擬ファイルとを読み込み、読み込んだ上記実行スクリプトファイルを実行し、上記実行スクリプトファイルに記述された第二のコマンド列に基づいて上記プログラムを実行する場合に上記割込みの発生を指定する記述がある位置において上記実行スクリプトファイルに記述された第一のコマンド列により上記割込みの発生を指定する記述がある位置に対応づけられた上記割込み模擬ファイルに記述された割込み処理を実行し、上記実行スクリプトファイルに記述された第三のコマンド列に基づいて上記プログラムを実行した実行結果を出力する実行部と
を備えることを特徴とする試験システム。In a test system for testing programs written in a procedural language,
The above program contains a description that specifies the occurrence of an interrupt,
And interrupt simulated file describing interrupt process to be executed in response to description that specifies the interrupt generation included on SL program, written in the description and the interrupt simulated file that specifies the generation of an interrupt that is included in the program A test pattern file storage unit for storing a test pattern file describing a correspondence relationship with the interrupt processing;
Enter the program reads the test pattern file stored in the test pattern file storage unit, it obtains a is descriptive of analyzes on SL program input specifying the occurrence of an interrupt position, read the test pattern file The interrupt processing corresponding to the description specifying the occurrence of the interrupt is obtained based on the first command sequence for associating the interrupt processing with the position where the description specifying the occurrence of the interrupt is executed, and the program is executed. a command sequence generator for generating a second command sequence, the third command sequence and execution script file that describes you output the execution result of executing that,
Reads and the command sequence generator is generated by execution script files and upper Symbol Interrupt simulation file, executes the execution script file read, the program based on the second command string described in the execution script file the interruption first command sequence by the upper Symbol interrupt simulation associated with the position where there is a description that specifies the generation of said interrupt at a location where there is a description that specifies the generation described in the execution script file when running A test system comprising: an execution unit that executes an interrupt process described in a file and outputs an execution result of executing the program based on a third command sequence described in the execution script file. 上記試験パターンファイル記憶部は、更に、上記プログラムに入力する入力値と、上記入力値を上記プログラムに入力して実行した実行結果の期待値とを含む試験パターンファイルを記憶し、
上記コマンド列生成部は、上記実行スクリプトファイルへ、更に、上記試験パターンファイルに含まれる入力値を設定するコマンド列と、上記実行結果と上記期待値とを比較して比較結果を出力するコマンド列と、プログラムの性能を測定する性能測定コマンドを実行するコマンド列と、上記性能測定コマンドが測定した性能情報を出力する性能情報出力コマンドを実行するコマンド列とを記述し、
上記実行部は、上記性能測定コマンドと上記性能情報出力コマンドとを実行して、上記実行結果に加え、上記比較結果と性能情報とを出力し、
上記試験システムは、更に、
上記実行部が出力する実行結果と比較結果と性能情報とを入力し、入力した実行結果と比較結果と性能情報とを併せて出力する出力整形部を備えることを特徴とする請求項１に記載の試験システム。Said test pattern file storage unit further stores an input value to be input to the program, the expected value and the including test pattern file execution result of the input value and run type in the program,
The command sequence generator, a command to the execution script file, and further outputs a command sequence to set the input values contained in the test pattern files, by comparing the upper SL execution result and the expected value comparison result A command sequence for executing a performance measurement command for measuring the performance of a program, and a command sequence for executing a performance information output command for outputting performance information measured by the performance measurement command.
The execution unit executes the performance measurement command and the performance information output command, and outputs the comparison result and performance information in addition to the execution result.
The test system further includes:
The output shaping part which inputs the execution result which the said execution part outputs, a comparison result, and performance information, and outputs the input execution result, a comparison result, and performance information together is provided, The output shaping part characterized by the above-mentioned. Testing system. 上記プログラムは、１ビットのデータをアクセスする命令を含み、
上記試験システムは、更に、上記ビット型のデータをアクセスするビットアクセスコマンドを記憶するコマンド定義記憶部を備え、
上記試験パターンファイル記憶部は、更に、上記１ビットのデータのデータ型を定義するビット型と、上記ビット型のデータとを含む試験用データとを含む試験パターンファイルを記憶し、
上記コマンド列生成部は、上記コマンド定義記憶部に記憶したビットアクセスコマンドを読み込み、上記試験パターンファイルに記述された試験用データを上記ビットアクセスコマンドを用いて設定するコマンド列を上記実行スクリプトファイルへ記述し、
上記実行部は、上記コマンド定義記憶部に記憶したビットアクセスコマンドを入力し、上記ビットアクセスコマンドを用いて、入力した実行スクリプトファイルを実行することを特徴とする請求項１記載の試験システム。The program includes an instruction for accessing 1-bit data,
The test system further includes a command definition storage unit that stores a bit access command for accessing the bit-type data.
The test pattern file storage unit further stores a test pattern file including a bit type defining a data type of the 1-bit data and test data including the bit type data,
The command sequence generation unit reads a bit access command stored in the command definition storage unit, and sets a command sequence for setting test data described in the test pattern file using the bit access command to the execution script file. Describe,
The test system according to claim 1, wherein the execution unit inputs a bit access command stored in the command definition storage unit, and executes the input execution script file using the bit access command. 上記プログラムは、グローバル変数を含み、
上記試験パターンファイル記憶部は、上記プログラムに記述されたグローバル変数へ設定する初期値を定義する変数初期値を含む試験パターンファイルを記憶し、
上記コマンド列生成部は、上記試験パターンファイルに記述された変数初期値を上記グローバル変数へ設定するコマンド列を上記実行スクリプトファイルへ記述することを特徴とする請求項１記載の試験システム。The above program contains global variables,
The test pattern file storage unit stores a test pattern file including a variable initial value that defines an initial value to be set to a global variable described in the program,
2. The test system according to claim 1, wherein the command sequence generation unit describes a command sequence for setting an initial value of a variable described in the test pattern file in the global variable in the execution script file. 上記プログラムは、命令を実行するプロセッサに依存するデータ型を含み、
上記試験パターンファイル記憶部は、上記プログラムを実行する場合に使用する試験用データと、上記プログラムに記述されたプロセッサに依存するデータ型を定義するデータ型定義とを含む試験パターンファイルを記憶し、
上記コマンド列生成部は、上記試験パターンファイルに記述されたデータ型定義を用いて、上記プログラムで使用する試験用データを設定するコマンド列を上記実行スクリプトファイルへ記述することを特徴とする請求項１または４記載の試験システム。The program includes a data type that depends on a processor executing an instruction,
The test pattern file storage unit stores a test pattern file including test data used when executing the program and a data type definition that defines a data type depending on a processor described in the program,
The command sequence generation unit describes a command sequence for setting test data used in the program in the execution script file by using a data type definition described in the test pattern file. 5. The test system according to 1 or 4. 上記手続型言語は、一の変数の名称を別名で定義する別名定義が可能であり、
上記プログラムは、別名定義された別名定義変数を含み、
上記試験パターンファイル記憶部は、上記別名定義変数へ設定する変数値を含む試験パターンファイルを記憶し、
上記試験システムは、更に、上記別名定義された別名定義変数を上記一の変数の名称とを対応付ける別名定義ファイルを備え、
上記コマンド列生成部は、上記別名定義ファイルとを入力し、上記プログラムソースファイルに記述された別名定義変数を上記一の変数の名称へ書き換え、上記試験パターンファイルに記述された変数値を上記書き換えた一の変数へ設定するコマンド列を上記実行スクリプトファイルへ記述することを特徴とする請求項１，４，５いずれかに記載の試験システム。The above procedural language allows alias definition to define the name of one variable with an alias,
The above program contains alias definition variables that are aliased,
The test pattern file storage unit stores a test pattern file including a variable value to be set in the alias definition variable,
The test system further includes an alias definition file that associates the alias-defined variable defined as the alias with the name of the one variable.
The command sequence generation unit inputs the alias definition file, rewrites the alias definition variable described in the program source file to the name of the one variable, and rewrites the variable value described in the test pattern file. 6. The test system according to claim 1, wherein a command string to be set to one variable is described in the execution script file. 割込み処理を実施する割込みハンドラ関数を備え、手続型言語で記述されたプログラムを試験する試験システムにおいて、
上記プログラムは、割込みの発生を指定する記述を含み、
上記プログラムに含まれる割込みの発生を指定する記述と割込みハンドラ関数との対応関係を記述した試験パターンファイルを記憶する試験パターンファイル記憶部と、
上記プログラムを入力し、上記試験パターンファイル記憶部に記憶した試験パターンファイルを読み込み、入力した上記プログラムを解析して割込みの発生を指定する記述がある位置を求め、読み込んだ上記試験パターンファイルに基づいて上記割込みの発生を指定する記述に対応する上記割込みハンドラ関数を求め、上記割込みの発生を指定する記述がある位置と上記割込みハンドラ関数とを対応づける第一のコマンド列と、上記プログラムを実行する第二のコマンド列と、実行した実行結果を出力する第三のコマンド列とを記述した実行スクリプトファイルを生成するコマンド列生成部と、
上記コマンド列生成部が生成した実行スクリプトファイルを入力し、入力した上記実行スクリプトファイルを実行し、上記実行スクリプトファイルに記述された第二のコマンド列に基づいて上記プログラムを実行する場合に上記割込みの発生を指定する記述がある位置において上記実行スクリプトファイルに記述された第一のコマンド列により上記割込みの発生を指定する記述がある位置に対応づけられた上記割込みハンドラ関数を実行し、上記実行スクリプトファイルに記述された第三のコマンド列に基づいて上記プログラムを実行した実行結果を出力する実行部と
を備えることを特徴とする試験システム。In a test system having an interrupt handler function for executing an interrupt process and testing a program written in a procedural language,
The above program contains a description that specifies the occurrence of an interrupt,
A correspondence storing test pattern file that describes a test pattern file storage unit of the description and interrupt handler function that specifies the generation of an interrupt that is included in the above SL program,
Enter the program reads the test pattern file stored in the test pattern file storage unit analyzes on SL program entered obtain the position in which there is describe that specifies the generation of the interrupt, read the test pattern Obtaining the interrupt handler function corresponding to the description specifying the occurrence of the interrupt based on the file, and a first command sequence for associating the position with the description specifying the occurrence of the interrupt with the interrupt handler function ; a second command sequence to run a program, the command sequence generator for generating a third command sequence and execution script file that describes you output the execution result of the execution,
Input the execution script file generated by the command sequence generation unit, execute the input execution script file, and execute the program based on the second command sequence described in the execution script file. the first command string described in the execution script file at a location where there is a description that specifies the generation running on Symbol interrupt handler function associated with the position where there is a description that specifies the generation of the interrupt, the A test system comprising: an execution unit that outputs an execution result of executing the program based on a third command sequence described in an execution script file. 上記実行部は、命令セットシュミレータとインサーキットシュミレータとのいずれか一方であることを特徴とする請求項１から７いずれかに記載の試験システム。  The test system according to claim 1, wherein the execution unit is one of an instruction set simulator and an in-circuit simulator. 上記手続型言語は、Ｃ言語とアセンブリ言語とのいずれか一方を含むことを特徴とする請求項１から８いずれかに記載の試験システム。  9. The test system according to claim 1, wherein the procedural language includes one of C language and assembly language. 手続型言語で記述されたプログラムを、コマンド列生成部と実行部とを有する試験システムが試験する試験方法において、
上記試験システムのコマンド列生成部が、割込みの発生を指定する記述を含むプログラムと、上記プログラムに含まれる割込みの発生を指定する記述と割込み処理との対応関係を記述した試験パターンファイルとを入力し、上記プログラムを解析して割込みの発生を指定する記述がある位置を求め、読み込んだ上記試験パターンファイルに基づいて上記割込みの発生を指定する記述に対応する割込み処理を求め、上記割込みの発生を指定する記述がある位置と上記割込み処理とを対応づける第一のコマンド列と、上記プログラムを実行する第二のコマンド列と、実行した実行結果を出力する第三のコマンド列とを記述した実行スクリプトファイルを生成するコマンド列生成工程と、
上記試験システムの実行部が、上記コマンド列生成工程において生成した実行スクリプトファイルと上記プログラムに含まれる割込みの発生を指定する記述に対応して実行する割込み処理を記述した割込み模擬ファイルとを読み込み、読みこんだ上記実行スクリプトファイルを実行し、上記実行スクリプトファイルに記述された第二のコマンド列に基づいて上記プログラムを実行する場合に上記割込みの発生を指定する記述がある位置において上記実行スクリプトファイルに記述された第一のコマンド列により上記割込みの発生を指定する記述がある位置に対応づけられた上記割込み模擬ファイルに記述された割込み処理を実行し、上記実行スクリプトファイルに記述された第三のコマンド列に基づいて、上記プログラムを実行した実行結果を出力する実行工程と
を備えることを特徴とする試験方法。In a test method in which a test system having a command sequence generation unit and an execution unit tests a program described in a procedural language,
Command sequence generation unit of the test system, the program including a description that specifies the generation of an interrupt, the test pattern file that describes the correspondence between the description and the interrupt process of designating the occurrence of interrupt contained in the above SL program enter the analyzes the program obtains a position where there is describe that specifies the generation of interrupt determines the interrupt processing corresponding to the description that specifies the generation of the interrupt based on the read the test pattern files, the a first command sequence associating there is a description that specifies the generation of the interrupt position and the above interrupt processing, a second command sequence to run the program, third you outputs the execution result of the execution and the command sequence generating step of generating an execution script file that describes the command string,
Execution unit of the test system, and interrupts the simulated file that describes the interrupt processing executed in response to description that specifies the generation of interrupt contained in the executed script files and upper SL program generated in the command string generating step read, execute the executable script file yelling read, the certain positions is description that specifies the generation of said interrupt when executing the program based on the second command string described in the execution script file executed by the script first command sequence file written to execute the interrupt process described in the association was the interruption simulated file to specify there is a description position the occurrence of the interrupt, described the execution script file based on the third command sequence is, the execution result of executing the program Test method characterized by comprising an execution step of outputting. 手続型言語で記述されたプログラムの試験を計算機で実現する試験プログラムにおいて、上記計算機を、
割込みの発生を指定する記述を含むプログラムと、上記割込みの発生を指定する記述と割込み処理との対応関係を記述した試験パターンファイルとを入力し、上記プログラムを解析して割込みの発生を指定する記述がある位置を求め、読み込んだ上記試験パターンファイルに基づいて上記割込みの発生を指定する記述に対応する割込み処理を求め、上記割込みの発生を指定する記述がある位置と上記割込み処理とを対応づける第一のコマンド列と、上記プログラムを実行する第二のコマンド列と、実行した実行結果を出力する第三のコマンド列とを記述した実行スクリプトファイルを生成するコマンド列生成部と、
上記コマンド列生成部が生成した実行スクリプトファイルと上記プログラムに含まれる割込みの発生を指定する記述に対応して実行する割込み処理を記述した割込み模擬ファイルとを読み込み、読み込んだ上記実行スクリプトファイルを実行し、上記実行スクリプトファイルに記述された第二のコマンド列に基づいて上記プログラムを実行する場合に上記割込みの発生を指定する記述がある位置において上記実行スクリプトファイルに記述された第一のコマンド列により上記割込みの発生を指定する記述がある位置に対応づけられた上記割込み模擬ファイルに記述された割込み処理を実行し、上記実行スクリプトファイルに記述された第三のコマンド列に基づいて、上記プログラムを実行した実行結果を出力する実行部と
を備えることを特徴とする試験システムとして機能させるための試験プログラム。In a test program for realizing a test of a program written in a procedural language on a computer, the computer is
Input a program that contains a description that specifies the occurrence of an interrupt and a test pattern file that describes the correspondence between the description that specifies the occurrence of the interrupt and the interrupt process, and analyzes the program to specify the occurrence of an interrupt sought is descriptive position, determine the interrupt processing corresponding to the description that specifies the generation of the interrupt based on the read the test pattern files, the position and the interrupt process is written to specify the occurrence of the interrupt and associating the first command sequence, the command sequence generator for generating a second command sequence to run the program, the execution script file that describes a third command sequence outputs the execution result of the execution And
Read and interrupt simulation file that describes the interrupt processing to be executed in response to the description that specifies the occurrence of interrupt to be included in the execution script file and the top Symbol program in which the command sequence generation unit has generated, the execution script to read When executing the file and executing the program based on the second command sequence described in the execution script file, the first described in the execution script file at a position where there is a description specifying the generation of the interrupt based of the command sequence to perform the interrupt process described in the association was the interruption simulated file to specify there is a description position the occurrence of the interrupt, the third command string described in the execution script file Te, characterized in that it comprises an execution unit for outputting the execution result of the execution of the program Test program for functioning as a test system for. 手続型言語で記述されたプログラムの試験を計算機で実現する試験プログラムを記録する計算機で読み取り可能な記録媒体において、上記計算機を、
割込みの発生を指定する記述を含むプログラムと、上記割込みの発生を指定する記述と割込み処理との対応関係を記述した試験パターンファイルとを入力し、上記プログラムを解析して割込みの発生を指定する記述がある位置を求め、読み込んだ上記試験パターンファイルに基づいて上記割込みの発生を指定する記述に対応する割込み処理を求め、上記割込みの発生を指定する記述がある位置と上記割込み処理とを対応づける第一のコマンド列と、上記プログラムを実行する第二のコマンド列と、実行した実行結果を出力する第三のコマンド列とを記述した実行スクリプトファイルを生成するコマンド列生成部と、
上記コマンド列生成部が生成した実行スクリプトファイルと上記プログラムに含まれる割込みの発生を指定する記述に対応して実行する割込み処理を記述した割込み模擬ファイルとを読み込み、読み込んだ上記実行スクリプトファイルを実行し、上記実行スクリプトファイルに記述された第二のコマンド列に基づいて上記プログラムを実行する場合に上記割込みの発生を指定する記述がある位置において上記実行スクリプトファイルに記述された第一のコマンド列により上記割込みの発生を指定する記述がある位置に対応づけられた上記割込み模擬ファイルに記述された割込み処理を実行し、上記実行スクリプトファイルに記述された第三のコマンド列に基づいて、上記プログラムを実行した実行結果を出力する実行部と
を備えることを特徴とする試験システムとして機能させるための試験プログラムを記録する計算機で読み取り可能な記録媒体。In a computer-readable recording medium for recording a test program for realizing a test of a program described in a procedural language with a computer, the computer is
Specifying a program to enter a test pattern file that describes the correspondence between the description that specifies the interrupt process the occurrence of the interruption, the occurrence of the interrupt by analyzing the program including a description that specifies the generation of the interrupt to describe obtain the position where there is the read obtains the interrupt processing corresponding to the description that specifies the generation of the interrupt based on the test pattern files, the position and the interrupt processing description that specifies is the occurrence of the interrupt a first command sequence to associate, the command sequence to generate a second command sequence to run the program, the execution script file that describes a third command sequence you outputs the execution result of the execution A generator,
Read and interrupt simulation file that describes the interrupt processing to be executed in response to the description that specifies the occurrence of interrupt to be included in the execution script file and the top Symbol program in which the command sequence generation unit has generated, the execution of the read When the script file is executed and the program is executed based on the second command string described in the execution script file, the first script described in the execution script file is located at a position where there is a description specifying the occurrence of the interrupt. perform been interrupt process described above interrupt simulated file associated with the position where there is a description that specifies the generation of the interruption by one command sequence, the third command string described in the execution script file They based on, characterized by comprising an execution unit for outputting the execution result of the run the program Readable recording medium by a computer that records the test program for functioning as a test system for.
JP2001062750A 2001-03-07 2001-03-07 Test system, test method, test program, and computer-readable recording medium recording the test program Expired - Fee Related JP3745968B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2001062750A JP3745968B2 (en) 2001-03-07 2001-03-07 Test system, test method, test program, and computer-readable recording medium recording the test program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2001062750A JP3745968B2 (en) 2001-03-07 2001-03-07 Test system, test method, test program, and computer-readable recording medium recording the test program

Publications (2)

Publication Number Publication Date
JP2002268918A JP2002268918A (en) 2002-09-20
JP3745968B2 true JP3745968B2 (en) 2006-02-15

Family

ID=18921843

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2001062750A Expired - Fee Related JP3745968B2 (en) 2001-03-07 2001-03-07 Test system, test method, test program, and computer-readable recording medium recording the test program

Country Status (1)

Country Link
JP (1) JP3745968B2 (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006048310A (en) * 2004-08-03 2006-02-16 Ricoh Co Ltd Software testing device
JP2010015240A (en) * 2008-07-01 2010-01-21 Denso Corp Verification system and verification device

Also Published As

Publication number Publication date
JP2002268918A (en) 2002-09-20

Similar Documents

Publication Publication Date Title
JP2795244B2 (en) Program debugging system
EP0453394B1 (en) Dynamic process for the generation of biased pseudo-random test patterns for the functional verification of hardware designs
CN109189479B (en) Parallel automatic verification method for processor instruction set
JP2004164554A (en) Device and method for executing and monitoring program
JPH11513512A (en) Method of manufacturing digital signal processor
CN113742119A (en) Call stack backtracking method and device of embedded system and computer equipment
TW201907304A (en) Code tracking for a microcontroller program
US20030177471A1 (en) System and method for graphically developing a program
US20020129336A1 (en) Automatic symbol table selection in a multi-cell environment
JP3745968B2 (en) Test system, test method, test program, and computer-readable recording medium recording the test program
KR0125605B1 (en) Method and device for verifying operation of machine language program
US20030070117A1 (en) Simulation apparatus and simulation method
JP4152659B2 (en) Data processing system and design system
JP5120103B2 (en) Debugging method and debugging program
JP2004287869A (en) Program execution monitoring device and method
JP2005174045A (en) Source program conversion device, source program conversion method, source program conversion program and program recording medium
US20100251213A1 (en) Method for executing debug commands
JP4149047B2 (en) Simulator
JP5034867B2 (en) Software verification support program, recording medium recording the program, software verification support apparatus, and software verification support method
JP2011145880A (en) Generation method for test task used in logic verification of semiconductor integrated circuit
JPH1165885A (en) Device and method for debugging software
JPH05250221A (en) Simulator execution system
JP3728368B2 (en) Resource conflict check device, assemble device, link device, instruction pipeline simulation device, resource conflict check method, and medium on which resource conflict check program is recorded
Goli et al. Design Understanding Methodology
CN114707450A (en) SystemC-based virtual model generation method, system, medium, and device

Legal Events

Date Code Title Description
RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20040518

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20041019

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20050127

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20050621

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20050728

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20050920

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20051019

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20051115

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20051118

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees