JP2006309290A - テストプログラム作成支援方法及び装置 - Google Patents

Abstract

【課題】 形式的仕様からテストプログラムを生成し、そのテストプログラムに手作業でプログラムコードを挿入した場合、仕様が変更されたときでも作成されたプログラムコードを再利用可能とする。
【解決手段】 テストプログラムに対して挿入したいプログラムコードの記憶部を設け、テストプログラムにマッチするパターンと挿入したいプログラムコードとの組を格納する。パターンマッチ部は、形式的仕様から生成されたテストプログラムに対して、格納されているパターンとのマッチングを行い、対応するプログラムコードをテストプログラムに挿入する。プログラムコードが挿入されたテストプログラムは、テスト実行部により実行される。
【選択図】 図１

Description

本発明は、テストプログラムの作成を支援する技術に関する。

被テストプログラムの形式的な仕様からテストプログラムを自動生成する技術およびテストを自動実行する技術がある。例えば、特開平１０−２０７７２７号公報に記載されている技術は、被テストプログラムの仕様から状態遷移情報を作成し、入力したテストケース抽出条件にしたがって状態遷移情報からテストケースを抽出する。これに入力したプログラム部品を合成することにより、テストプログラムを自動生成している(特許文献１参照)。

特開平９−２２３０４２号公報に記載されている発明は、ＧＵＩ（グラフィック・ユーザ・インタフェース）を持つ被テストプログラムの仕様情報から被テストプログラムが持つ全ての状態と状態遷移とを網羅するようテストシナリオを生成し、テストシナリオ実行手段によって被テストプログラムをテストシナリオにしたがって実行する。実行中の被テストプログラムの状態を示す属性値が、仕様情報に記載されている値と一致するかどうかを照合する実行結果照合手段により、被テストプログラムのテストを自動的に行う(特許文献２参照)。

また、テストプログラムの自動生成技術とプログラムの自動生成技術とを組み合わせた技術も存在する。ＭＤＡ(登録商標)(Model Driven Architecture)技術はＵＭＬ(登録商標)(Unified Modeling Language)によって記述されたソフトウェアの形式的な仕様からプログラムを自動生成する技術である(非特許文献１参照)。ＵＭＬ(登録商標)は、ソフトウェアの状態遷移や通信手順を形式的に記述することを可能とする。ＭＤＡ(登録商標)をサポートするツールの中には、ＵＭＬ(登録商標)によって記述された形式的な仕様からテストプログラムの自動生成および自動実行を行うものがある(非特許文献２参照)。

アスペクト指向技術は、プログラム中のさまざまな箇所にある類似した処理に対してポイントカットと呼ばれるパターンを用いてプログラムコードを挿入する技術である。ただし、アスペクト指向技術は、手動で作成したプログラムの設計の見通しを改善するための技術であり、自動生成されたテストプログラムにアスペクト指向技術を適用することは容易ではない（非特許文献３）。

特開平１０−２０７７２７号公報 特開平９−２２３０４２号公報 情報処理 Vol.45 No.1 特集 モデリングとツールを駆使したこれからのソフトウェア開発技法−モデル駆動開発手法を中心として−、情報処理学会、2004年 IBM Rational Rose Technical Developer カタログ '03-11月版、日本アイ・ビー・エム株式会社、2003年、p.2 情報処理 Vol.45 No.7 特集 組み込みソフトウェア開発技術、情報処理学会、2004年

従来のテストプログラム自動生成技術は、必ずしも被テストプログラムをテストするのに必要なテストプログラムを全て生成するものではない。多くの場合には、形式的仕様から自動生成できないテストプログラムを手作業で作成する必要が出てくる。

例えば、ＭＤＡ(登録商標)技術でプログラムの生成に使用される形式的仕様は、プログラムを生成するのに必要な情報は含んでいるが、テストプログラムの生成に必要な情報は必ずしも含んでいない。また、プログラムの生成に使用する形式的仕様には表面的に現れない仕様や、形式的仕様に記述するのが難しい非機能要件に関しては、自動的にこれらのテストプログラムを生成するのは困難である。例としては要求仕様に基づく上位レベルの機能テストやパフォーマンステストのような非機能要件のテストがあげられる。

ただし、手作業でテストプログラムを作成する場合に、全てを手動で作成するのではなく、自動生成されたプログラムをスケルトンとして利用することによって、作成の労力を減らすことが可能である。従来のテストプログラム生成技術にも、自動生成されたテストプログラムに手作業でプログラムコードを追加することにより、形式的仕様より上位レベルの機能テストやパフォーマンステストを行うことができるものがある。

本発明が解決しようとしている課題は、従来技術において上記のように形式的仕様から自動生成されたテストプログラムに手作業でプログラムコードを挿入した場合、手作業で挿入したプログラムコードを再利用することが困難であるということである。

従来技術では、元となる形式的仕様が変更されると自動生成されるテストプログラムも変わるため、変更前の形式的仕様に基づいて自動生成されたテストプログラムに手作業で挿入したプログラムコードは利用できなくなる。

実際のソフトウェアの開発においては、仕様の変更はしばしば行われるため、従来技術により自動生成されたテストプログラムをスケルトンとして利用しようとすると、自動生成されたテストプログラムへのプログラムコードの挿入を繰り返し行わなければならなくなる。このため手作業でのテストプログラム作成の労力が大きくなる。

上記の課題を解決するために、本発明では以下の手段を用いる。

まず、自動生成されたテストプログラムに挿入したいプログラムコードを直接挿入するのではなく、別に記憶手段を設け、テストプログラムに対してマッチするパターンとプログラムコードとの組を格納する。テスト作成者は、プログラムコードを挿入したいテストプログラムにマッチするパターンと、挿入したいプログラムコードとの組を作成し、この記憶手段に入力する。

次に、自動生成されたテストプログラムに、記憶手段に格納されたプログラムコードを挿入するために、自動生成されたテストプログラムとパターンとのマッチングを行うパターンマッチ部を設ける。パターンマッチ部は、自動生成されたテストプログラムに対して記憶手段に格納されているパターンとのマッチングを行い、マッチしたテストプログラムに対して、パターンと組になっているプログラムコードを挿入する。

パターンマッチ部は、プログラムコードを挿入したテストプログラムをテスト実行部に出力する。テスト実行部は入力されたテストプログラムを実行することによりテストを自動実行する。

また、どの自動生成されたテストスクリプトに対してどのプログラムコードが挿入されたかをテスト作成者が確認できるように、パターンマッチ部はパターンマッチの結果をパターンマッチ結果表示部に出力する。

本発明により、自動生成されたテストプログラムに対し、手作業でプログラムコードを挿入することができる。これにより、自動生成されたテストプログラムをスケルトンとして利用できるため、形式的仕様よりも上位レベルの機能テストや非機能要件のテストを手作業で作成する労力を減らすことができる。

さらに、本発明によれば、自動生成されたテストプログラムに対してテスト作成者が手作業でプログラムコードを追加した後に、形式的仕様の変更により自動生成されるテストプログラムが変わっても、記憶手段に入力されているプログラムコードはパターンマッチ部により再度自動的にテストプログラムに挿入されるため、自動生成されたテストプログラムに直接手作業で変更を行った場合のように手作業で再度プログラムコードを追加する必要がない。

このため、被テストプログラムの仕様が変更される場合には、従来技術によって自動生成されたテストプログラムを直接修正する場合と比較して、手作業でのテストプログラム作成の労力を減らすことができる。

本発明の実施の形態を以下に示す。なお、これにより本発明が限定されるものではない。

図１は、本実施形態の概略構成を示す図である。本実施形態は、形式的仕様としてＵＭＬ(登録商標)の状態遷移図と、状態遷移を起こすイベントと、状態遷移が起きたときに実行されるアクション記述とを用いる。本実施形態の形式的仕様記憶部101は、ＵＭＬ(登録商標)の状態遷移図と、状態遷移を起こすイベントと、状態遷移が起きたときに実行されるアクション記述とを記憶する。

テストプログラム生成部102は、形式的仕様記憶部101に記憶されたＵＭＬ(登録商標)の状態遷移図と、状態遷移を起こすイベントとからテストプログラムを自動生成し、テストプログラム記憶部103に格納する。

また、本実施形態は、自動生成されたテストプログラムに対してマッチするパターンとして、正規表現とマッチングの場所を示す括弧とを用いたパターンを使用する。テスト作成者は、正規表現と括弧とを組み合わせたパターンと、テストプログラムに挿入するプログラムコードとの組をパターンプログラムコード記憶部104に入力し格納する。

パターンマッチ部105は、パターンプログラムコード記憶部104に入力されたパターンとテストプログラム記憶部103に格納されたテストプログラムとのマッチングを行い、マッチしたテストプログラムに対してパターンに対応するプログラムコードを挿入する。

パターンマッチ部105は、プログラムコードを挿入したテストプログラムをテスト実行装置106に出力する。テスト実行装置106は、そのテストプログラムを用いて被テストプログラムのテストを実行する。また、パターンマッチ部105は、パターンマッチの結果をマッチ結果表示装置107に出力する。マッチ結果表示装置107は、パターンマッチの結果を表示装置上に表示する。

図１に示す構成の全体は、１台又は複数台のコンピュータによって実現される。これらのコンピュータは、ＣＰＵ、メモリ、その他の記憶装置を有する。テストプログラム生成部102およびパターンマッチ部105は、メモリに格納され、ＣＰＵによって実行されるプログラムである。形式的仕様記憶部101、テストプログラム記憶部103およびパターンプログラムコード記憶部104は、記憶装置上に設けられ、各々のデータを格納する。

以下、具体的な形式的仕様からテストプログラムを生成する例をあげ、図１の各部の動作を説明する。

図２は、形式的仕様記憶部101に入力されるＵＭＬ(登録商標)の状態遷移図と、状態遷移を起こすイベントと、アクション記述との例を示す。系の状態は、状態を表す文字列によって表現される。状態遷移図は、状態がイベント発生によって別の状態に遷移する仕組みを表現する。

図２の形式的仕様は、テレビ番組の録画の予約を行うプログラムの仕様である。この仕様によるプログラムの動作は以下の通りである。

系が初期化されると、プログラムの状態は、初期状態を示す記号214によって指し示される開始状態201になる。プログラムは、開始状態201にあるときに録画予約イベントを受け取ると遷移205により番組情報入力状態202に遷移する。プログラムは、遷移205に付与された名前である録画予約と同じ名前のイベントを受け取ることにより状態遷移を起こす。他の遷移についても同様である。番組情報入力状態202に遷移すると、状態202に記述されたアクション記述211が実行され、録画したい番組の情報の入力を受け付ける。その後決定イベントを受け取ると遷移206によりプログラムは入力情報確認状態203に遷移し、アクション記述212が実行される。ここでさらに決定イベントを受け取ると、プログラムは遷移208により終了状態204に遷移し、アクション記述213が実行される。アクション記述213の実行により、番組情報入力状態202において入力された番組の情報が録画データベース（ＤＢ）に記録され、録画予約処理が完了する。

テストプログラム生成部102は、形式的仕様記憶部101にデータが格納される図２の形式的仕様からテストプログラムを生成してテストプログラム記憶部103に格納する。本実施形態では、テストプログラム生成部102は、被テストプログラムが形式的仕様の全ての遷移を網羅するように作成する。図２の形式的仕様から生成されるテストプログラムにより被テストプログラムが遷移する全ての状態遷移のパスを図３に示す。

状態遷移パス301に従って遷移することにより、遷移205と、遷移206と、遷移208と、遷移209とが行われる。状態遷移パス302に従って遷移することにより、遷移205と、遷移206と、遷移207とが行われる。状態遷移パス303に従って遷移することにより、遷移205と、遷移210とが行われる。これにより、状態遷移パス301と、状態遷移パス302と、状態遷移パス303とに従ってプログラムを遷移させることにより、図２の形式的仕様に示される全ての状態遷移が行われることがわかる。

本実施形態では、テストプログラム生成部102は、図３の状態遷移パスごとに対応するテストプログラムを生成する。状態遷移パス301に対応するテストプログラムを図４に示す。

図４のテストプログラムの１行目は、被テストプログラムの初期化を行う処理である。これにより、被テストプログラムが初期化され、開始状態201になる。また、被テストプログラムはobjという変数に代入される。

２行目では、テストプログラムは、assert_stateという関数の呼び出しにより、第一引数の変数objにより参照される被テストプログラムが、第二引数の開始状態という名前により示される開始状態201にあることを確認する。assert_stateは、本実施形態において被テストプログラムの状態を確認するために用意される関数である。２行目を実行すると、被テストプログラムの状態が期待通りに開始状態であるときにはテストプログラムの実行結果のログに"ＯＫ"と出力され、状態が異なっている場合、例えば状態が終了状態である場合には、"ＮＧ： 開始状態になることが期待されていますが状態は終了状態です"と出力される。

３行目では、テストプログラムは、generate_eventという関数の呼び出しにより、被テストプログラムに対して録画予約イベントを送信する。generate_eventは、本実施形態において被テストプログラムにイベントを送信するために用意される関数である。４行目から１０行目は、２行目および３行目と同様の処理の繰り返しである。

１１行目では、テストプログラムは、被テストプログラムの終了処理を行う。

１行目から１１行目までを実行することにより、被テストプログラムは、状態遷移パス301に従って遷移する。

本実施形態のテストプログラム生成部102によって生成されるプログラムは、図４に示されるテストプログラムのように、被テストプログラムにイベントを送信し、被テストプログラムが形式的仕様に従って状態遷移するかどうかを確認するものである。しかし、実際のソフトウェアの開発においては、被テストプログラムの状態遷移を確認するだけでは十分なテストとはいえない。

例えば、実際に録画予約処理が行われているかどうかをテストするためには、被テストプログラムを状態遷移パス301に従って状態遷移させたときに、録画予約の件数が1件増えているということを確認する必要がある。形式的仕様にはこのような要求仕様が記述されていないため、このような要求仕様をテストするテストプログラムを自動生成することは困難である。このため、この例のように実際に録画予約処理が行われているかどうかをテストするテストプログラムは、手作業で作成される必要がある。

これは本実施形態のテストプログラム生成方式に限った問題ではない。形式的仕様からテストプログラムを自動生成する他の従来技術においても同様の問題が起こる。

以下、テスト作成者がパターンプログラムコード記憶手段104に入力するパターンとプログラムコードについて説明する。本実施形態では、正規表現と括弧とを組み合わせたパターンを用いる。パターンプログラムコード記憶部104には図５の表の形式でパターンとプログラムコードが入力される。図５の表には２つのパターンが入力されている。

１つのパターンには１つ以上のプログラムコードが対応する。対応するプログラムコードの数は、パターン内に出現する括弧に囲まれた部分の数と同じである。パターン501には、括弧に囲まれた部分が"(開始)"と"(終了)"の２箇所であるため、対応するプログラムコードも502と503の２つになる。

本実施形態では、パターンは被テストプログラムのいずれかの状態遷移パスにマッチするように設定される。パターン501に出現する文字列".*"は、「開始」の状態と「終了」の状態との間に任意の状態が任意の数だけ挿入されていてよいことを示す。したがって第１のパターンは、開始状態201から０個以上の状態を経過して終了状態204に遷移するパスを含むパスとマッチする。図３に示された状態遷移パスの中では、遷移301のみがこのパターンにマッチする。

また、パターン中の括弧に囲まれた部分の状態を表す文字列は、プログラムコードがテストプログラムに挿入される場所を示している。パターン501の場合は、1つめの括弧である"(開始)"に対応する箇所に１つめのプログラムコード502が挿入され、２つめの括弧である"(終了)"に対応する箇所に２つめのプログラムコード503が挿入される。

第２のパターンは、「開始」の状態と「終了」の状態との間に「番組情報入力」の状態が挿入されるパスがマッチする。図３に示された状態遷移パスの中では、遷移303のみがこのパターンにマッチする。プログラムコードの挿入箇所については、第１のパターンと同様である。

パターンマッチ部105のマッチング処理の流れを図６に示す。まず、パターンマッチ部105は、ステップ601においてテストプログラム記憶部103に記憶されているテストプログラムの１つを取得する。次にステップ602において、取得したテストプログラム内に出現するassert_state文を解析することにより、このテストプログラムにより行われる状態遷移のパスを抽出する。

例えば図４に示すテストプログラムがステップ601において取得された場合、図４のテストプログラムでは、assert_state文が２行目、４行目、６行目、８行目および１０行目に出現している。これらのassert_stateの引数より、テストプログラムによって引き起こされる状態遷移のパスは開始→番組情報入力→入力情報確認→終了→開始であることがわかる。

次にステップ603において、パターンマッチ部105は、パターン取得の初期化を行う。これによって図５に示されるようなパターン群の先頭に位置づけされる。これは、それぞれのテストプログラムについて全てのパターンとマッチングを行うための初期化処理である。

次にステップ604において、パターンマッチ部105は、パターンプログラムコード記憶部104に記憶されたパターンを取得する。ステップ605において、パターンマッチ部105は、ステップ602で抽出した状態遷移パスと取得したパターンとのマッチングを行い、当該状態遷移パスがパターンとマッチするか否か判定する。状態遷移パス中に出現する状態を表す文字列のシーケンスがパターン中に出現する状態を表す文字列のシーケンスに一致すれば、両者はマッチすると判定される。

パターンと状態遷移パスとがマッチすれば、ステップ606において、パターンマッチ部105は、マッチしたパターンに対応するプログラムコードをステップ601で取得したテストプログラムの該当する状態を示す文の次に挿入する。本実施形態では、パターンの括弧に囲まれた状態を示す文字列に対応するassert_state文がある次の行にプログラムコードを挿入する。

例えば図４に示すテストプログラムがステップ601において取得され、パターン501がステップ604で取得された場合、テストプログラムに対してパターン501はマッチするため、ステップ606に進む。パターン501の１つめの括弧に囲まれた部分"(開始)"に対応するassert_state文は、図４の２行目であるため、パターンマッチ部105は、２行目の次にパターン501の１つめのプログラムコードであるプログラムコード502を挿入する。同様にして８行目の次にプログラムコード503を挿入する。

このようにプログラムコードを挿入し、行番号を付け直したものを図７に示す。

次のステップ607において、パターンマッチ部105は、ステップ606でプログラムコードを挿入したテストプログラムをテスト実行装置106に対して出力する。さらにステップ608において、パターンマッチ部105は、マッチ結果表示装置107においてパターンマッチの結果を出力する。

ステップ609では、パターンマッチ部105は、パターンプログラムコード記憶部104に記憶されておりまだ取得されていないパターンがあるかどうか判定する。まだパターンがある場合にはステップ604に戻りパターンを取得する。本実施例の場合には、図５に示す第２のパターンを取得する。次にステップ605が実行されるとき、状態遷移パス301が第２のパターンと比較されることになるが、この場合には両者はマッチしない。

ステップ610では、パターンマッチ部105は、テストプログラム記憶部103に記憶されておりまだ取得されていないテストプログラムがあるかどうか判定する。まだテストプログラムがある場合にはステップ601に戻り、次のテストプログラムを取得する。本実施例の場合には、図３に示す状態遷移パス302に対応するテストプログラムが取得される。

テスト実行装置106は、パターンマッチ部105がプログラムコードを挿入したテストプログラムを実行することにより、自動的に被テストプログラムのテストを行う。

例として図７のテストプログラムの実行について説明する。１行目で被テストプログラムの初期化が行われ、２行目のassert_state文により被テストプログラムの状態が開始状態201であることが確認された後、３行目のcount_yoyakuという関数の呼び出しが行われる。本実施例では、count_yoyakuはその時点での録画予約件数を数える関数である。これにより、変数countに録画予約件数が代入される。

続いて４行目、６行目および８行目のgenerate_eventの呼び出しにより、被テストプログラムの状態遷移が引き起こされ、録画予約操作が行われる。

その後１０行目のassertという関数が呼び出される。本実施形態では、assert文は引数の式が成り立つことを確認する関数である。１０行目では、assertの引数として、３行目でcount_yoyakuの戻り値を代入した変数countに１を加えた値と、count_yoyakuの値とを比較した式を与えている。これにより、１０行目の時点での録画予約件数が、３行目の時点での録画予約件数よりも１件多いことを確認することができる。

マッチ結果表示装置107は、パターンマッチ部105が行ったパターンマッチの結果を表示する。本実施形態での表示画面例を図８に示す。本画面例では、パターンにマッチしたテストプログラムに対応する状態遷移のパス801、テストプログラムにマッチしたパターン802、およびテストプログラムに挿入されたコード803が全てのパターンマッチ結果について表示される。これを見ることにより、テスト作成者は、どの状態遷移パスに対応するテストスクリプトにどのプログラムコードが挿入されたかを確認することができる。

以上で図１の装置による形式的仕様からのテストプログラム生成の例の説明を終わる。

次に、図２の形式的仕様が変更され、機能が追加された場合の本実施形態のパターンマッチ処理およびプログラムコード挿入処理について説明する。

図９は、図２の形式的仕様に対して機能を追加した形式的仕様である。これは、録画予約を行うプログラムであるが、録画を行う媒体を録画予約時に指定できるように状態901が追加されている。状態が番組情報入力状態202にあるとき、この仕様によるプログラムの動作は以下の通りである。

番組情報入力状態202にあるときに決定イベントを受け取ると、遷移903によりプログラムは媒体情報入力状態901に遷移し、アクション記述902が実行される。ここでさらに決定イベントを受け取ると、プログラムは遷移904により入力状態確認状態203に遷移する。入力情報確認状態203にあるときの動作は、図２の仕様の場合と同じである。

図７のテストプログラムを図９の形式的仕様に従ったプログラムに適用した場合、テストプログラムの６行目で決定イベントを送信した後に、図９の形式的仕様に従ったプログラムは媒体情報入力状態901に遷移するため、図７のテストプログラムの７行目のassert_state文で行っている確認に失敗する。このため、図７のテストプログラムは図９のプログラムには適用できない。本実施形態では、図９の形式的仕様より再度テストプログラムを自動生成し、パターンマッチによりプログラムコードを挿入する。

図９の形式的仕様で可能な状態遷移である。開始状態201、番組情報入力状態202、媒体情報入力状態901、入力情報確認状態203、終了状態204、開始状態201の順に遷移する状態遷移パスに対応するテストプログラムを図１０に示す。図１０のテストプログラムは、図９の形式的仕様に従ったプログラムに適用することはできるが、図７の３行目および１０行目に示すようなプログラムコードが挿入されていないため、録画予約件数のチェックは行えない。

ここで再度パターンマッチ部105によって図６に示す手順でパターンマッチを行うことにより、図１１に示すプログラムコードが生成される。このテストプログラムは、図９の形式的仕様に従ったプログラムをテストすることができ、録画予約件数もチェックすることができる。

２回目にパターンマッチ部105によってパターンマッチを行う際には、テスト作成者が再度パターンプログラムコード記憶部104にパターンとプログラムコードの対を入力する必要はなく、あらかじめ入力してあるものがそのまま使用される。これにより、図９の形式的仕様に対応するためのテストプログラムの作成が省力化されることがわかる。

なお状態遷移の仕様は、図２に示す状態遷移図とは別の形式を用いて表すこともできる。図１２は、図２で示される状態遷移の仕様を表形式で示したものである。図１２の表の１行目はプログラムが取り得る状態を示し、１列目はプログラムへ入力されるイベントを示す。プログラムが開始状態にあり、録画予約イベントが入力された場合、状態は表の２行目２列目にある番組情報入力状態に遷移する。プログラムが開始状態にあり、決定イベントが入力された場合には何も状態遷移は起こらない。これを表の３行目２列目にある「−」記号により表す。他の場合も同様である。

次に、形式的仕様がテストプログラムと被テストプログラムとの通信手順を表す場合の実施例を示す。

図１３は、録画の予約を行うプログラムの内部で行われる通信の手順を示す形式的仕様である。このプログラムは、リモコン、表示部、制御部、データベースの４つの部分から成る。この仕様によるプログラムの動作は以下の通りである。

まず、リモコンは制御部に録画予約イベントを送る。このとき受信部となる制御部はこのイベントを受信する。次に送信部となる制御部は、表示部に番組情報入力画面表示イベントを送る。次にリモコンは、制御部に番組情報イベントを送信した後、決定イベントを送信すると、制御部は、表示部に入力情報確認画面表示イベントを送る。その他のイベントについても、図示するようにイベントが送られ、同様に動作する。

次に、テストプログラム生成部１０２は、図１３の形式的仕様からテストプログラムを生成する。本実施例では、プログラムの部分のうち、制御部をテスト対象とするテストプログラムを生成する。テストプログラムは、テスト対象のプログラムとイベントの送受信を行う部分を模擬することによってテストを行う。この例では、リモコンおよび表示部のイベント送受信操作を模擬することによってテストを行う。

テストプログラムは、まず制御部に録画予約イベントを送信し、制御部から番組情報入力画面表示イベントが送信されてくるのを待つ。次にテストプログラムは、制御部に番組情報イベント、決定イベントの順に送信し、入力情報確認画面表示イベントが送信されるのを待つ。その他のイベントについても同様に動作する。

このテストプログラムを図１４に示す。２行目でgenerate_eventによりイベントを送信している。３行目のwait_for_eventはイベントが送信されるのを待つ関数である。

次にパターンマッチ部105が行うマッチング処理について述べる。図１４のテストプログラムによって送受信されるイベントの列は図１５の形式で表すことができる。ここでイベント名の前に「出：」がついているものはテストプログラムから送信されるイベント、「入：」がついているものはテストプログラムに送信されるイベントを表す。

本実施形態では、図１６に示されるパターンが図１５の形式で示される送受信されるイベントのシーケンスにマッチする。パターンの意味は、状態遷移の場合の実施例と同様である。

状態遷移の場合の図６と同様の手順によってパターンマッチを行うことにより、図１４のテストプログラムにプログラムコードを挿入することができる。この結果を図１７に示す。３行目にコード１６０１が挿入され、１０行目にコード１６０２が挿入される。

実施形態の概略構成を示す図である。 テストプログラムの生成に用いられる形式的仕様の例を示す図である。 テストプログラムによる状態遷移のパスの例を示す図である。 生成されるテストプログラムの例を示す図である。 パターンとプログラムコードとの格納形式を例示する図である。 実施例のテストプログラムとパターンとのマッチング処理の流れを示す図である。 プログラムコード挿入後のテストプログラムの例を示す図である。 パターンマッチ結果の表示画面例を示す図である。 図２の形式的仕様に機能を追加した仕様を示す図である。 図９の形式的仕様により生成されるテストプログラムの例を示す図である。 図１０のテストプログラムにプログラムコードを挿入した後のテストプログラムを示す図である。 他の形式の状態遷移仕様の例を示す図である。 通信手順の形式的仕様の例を示す図である。 通信手順の形式的仕様から生成されるテストプログラムの例を示す図である。 通信手順のテストプログラムによる状態遷移のパスの例を示す図である。 通信手順についてパターンとプログラムコードとの格納形式例を示す図である。 プログラムコード挿入後のテストプログラムの他の例を示す図である。

符号の説明

101…形式的仕様記憶部、102…テストプログラム生成部、103…テストプログラム記憶部、104…パターンプログラムコード記憶部、105…パターンマッチ部、106…テスト実行装置、107…マッチ結果表示装置、301…状態遷移パス、302…状態遷移パス、303…状態遷移パス、501…パターン、502…プログラムコード、503…プログラムコード。

Claims (6)

1. 系の状態がイベント発生によって別の状態に遷移する仕組みを表現する形式的仕様情報を格納する記憶手段と、
   前記形式的仕様情報から各状態遷移の経路ごとにテストプログラムを生成するテストプログラム生成部と、
   前記状態を表す文字列のシーケンスを示すパターンと対応するプログラムコードとを格納する記憶手段と、
   前記状態遷移の経路に出現する状態を表す文字列のシーケンスと前記パターンとのマッチングを行い、パターンにマッチした当該経路に対応するテストプログラムに指定されたプログラムコードを挿入するパターンマッチ部と、
   前記プログラムコードが挿入されたテストプログラムを実行し、被テストプログラムをテストするテスト実行部とを備えることを特徴とするテストプログラム作成支援装置。
2. 前記テストプログラム作成支援装置は、さらに前記パターンマッチ部により行われたパターンマッチの結果を表示するマッチ結果表示部を備えることを特徴とする請求項１記載のテストプログラム作成支援装置。
3. 送信部が受信部へイベントを送信する手順を表現する通信手順を形式的仕様情報として格納する記憶手段と、
   前記形式的仕様情報から各通信手順ごとにテストプログラムを生成するテストプログラム生成部と、
   前記通信手順を表す文字列のシーケンスを示すパターンと対応するプログラムコードとを格納する記憶手段と、
   前記通信手順に出現するイベントを表す文字列のシーケンスと前記パターンとのマッチングを行い、パターンにマッチした当該通信手順に対応するテストプログラムに指定されたプログラムコードを挿入するパターンマッチ部と、
   前記プログラムコードが挿入されたテストプログラムを実行し、被テストプログラムをテストするテスト実行部とを備えることを特徴とするテストプログラム作成支援装置。
4. 前記テストプログラム作成支援装置は、さらに前記パターンマッチ部により行われたパターンマッチの結果を表示するマッチ結果表示部を備えることを特徴とする請求項３記載のテストプログラム作成支援装置。
5. 記憶手段に格納され、系の状態がイベント発生によって別の状態に遷移する仕組みを表現する形式的仕様情報から各状態遷移の経路ごとにテストプログラムを生成するステップと、
   前記状態を表す文字列のシーケンスを示すパターンと対応するプログラムコードとを格納する記憶手段を参照し、前記状態遷移の経路に出現する状態を表す文字列のシーケンスと前記パターンとのマッチングを行い、パターンにマッチした当該経路に対応するテストプログラムに指定されたプログラムコードを挿入するステップと、
   前記プログラムコードが挿入されたテストプログラムを実行し、被テストプログラムをテストするステップとを有することを特徴とするテストプログラム作成支援方法。
6. 記憶手段に格納され、送信部が受信部へイベントを送信する手順を表現する通信手順から各通信手順ごとにテストプログラムを生成するステップと、
   前記通信手順を表す文字列のシーケンスを示すパターンと対応するプログラムコードとを格納する記憶手段を参照し、前記通信手順に出現するイベントを表す文字列のシーケンスと前記パターンとのマッチングを行い、パターンにマッチした当該通信手順に対応するテストプログラムに指定されたプログラムコードを挿入するステップと、
   前記プログラムコードが挿入されたテストプログラムを実行し、被テストプログラムをテストするステップとを有することを特徴とするテストプログラム作成支援方法。

Images