JPH11282666A - テスト仕様書作成装置およびそのプログラムを格納した記憶媒体 - Google Patents

Abstract

(57)【要約】 【課題】 テスト仕様書作成装置に関し、設計工程でエ
ントリした設計情報リポジトリを利用し、テスト工程で
の作業効率を向上させることを目的とする。 【解決手段】 データ解析手段４はテスト構成記憶手段
１のテスト構成ファイルに記述された文を１行ずつ読み
込み、その行が固定出力行かプログラム出力行かを判断
する。テスト事項判断手段５は、プログラム出力行から
設計情報記憶手段９の設計テーブルにある設計情報のみ
でテスト事項を生成できるか、標準テスト事項記憶手段
３の標準テスト事項ファイルの情報をも必要とするかを
判断する。第１テスト事項生成手段６は、設計情報読み
込み手段２により取得した各設計テーブルからテスト事
項を生成し、第２テスト事項生成手段７は、各設計テー
ブルと標準テスト事項ファイルとからテスト事項を生成
する。テスト仕様書書き出し手段８は、固定出力行、生
成したテスト事項出力してテスト仕様書１０を作成す
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はテスト仕様書作成装
置に関し、特にコンピュータソフトウェアのシステム開
発において、その設計情報を元にプログラムの検証の際
に必要なテスト仕様書を作成するテスト仕様書作成装置
に関する。

【０００２】ソフトウェアの業務システムの開発は、設
計工程と、製造工程と、テスト工程と、大きく三つの作
業に分けることができる。設計工程では、顧客の要求に
応じて対象となるシステムの内容を分析し、システム化
できる部分を検討して設計仕様書を作成する。その設計
作業では、コンピュータを利用して設計を支援するＣＡ
ＳＥ（Computer Aided Software Engineering ）機能が
利用されている。製造工程では、設計工程で設計された
設計仕様書に従ってアプリケーションプログラムを作成
し、テスト工程では、作成されたプログラムが設計仕様
書通りに動作するかをテストする。そのためのテスト作
業の指標・指示を記述したものがテスト仕様書である。

【０００３】

【従来の技術】業務システムの開発においては、設計工
程および製造工程が重要であることはもちろんである
が、システムの品質および信頼性をさらに向上させるた
めに、テスト工程の比重が増してきている。このため、
テスト行程をある程度自動化することができれば、開発
の生産性をより向上させることが可能になる。このよう
なテスト環境を提供するテスティング・ツールが知られ
ており、その代表的なものとして、たとえば「ＳＱＡ
Ｓｕｉｔｅ（米国ＳＱＡ Ｉｎｃ．の登録商標）」があ
る。

【０００４】このツールは、テストの企画設計からテス
ト結果のレポート生成までのテスト作業の流れをそれぞ
れ管理するものである。テスト作業の全体の流れを管理
するためには、まず、管理に必要なテスト情報をツール
に入力する必要がある。そのテスト情報として、テスト
計画、テスト事項などがあり、これらのテスト情報はデ
ータベースに登録されて、テスト工程での作業に必要な
情報として一元管理される。テスト仕様書は、そのテス
ト情報を元に作成される。

【０００５】

【発明が解決しようとする課題】以上のように、テスト
工程では、テスト仕様書を作成するのに必要なテスト情
報の登録作業が必ず必要である。一方、設計工程でＣＡ
ＳＥ機能を使っている場合は、設計情報が設計情報リポ
ジトリに一元管理されている。ここで、テスト工程で使
われるテスト情報のうち、テスト事項などは、設計工程
で設計情報として既に登録されたものである。したがっ
て、テスト工程でも設計工程と同じような情報の登録作
業を行っていることになるため、作業効率を悪化させる
要因になっており、開発生産性も悪くなるという問題が
あった。

【０００６】本発明はこのような点に鑑みてなされたも
のであり、設計工程でエントリした設計情報リポジトリ
からテスト工程で使用するテスト仕様書を生成すること
ができるテスト仕様書作成装置を提供することを目的と
する。

【０００７】

【課題を解決するための手段】図１は上記目的を達成す
る本発明の原理構成を示す図である。テスト仕様書作成
装置は、テスト仕様書の基本的な構成を記述したテスト
構成ファイルを記憶するテスト構成記憶手段１と、設計
工程で作成された設計情報を読み込む設計情報読み込み
手段２と、詳細なテスト事項を記述した標準テスト事項
ファイルを記憶する標準テスト事項記憶手段３と、テス
ト構成ファイルに記述された文を行単位で読み込んでそ
の文は固定出力行かプログラム出力行かを解析するする
データ解析手段４と、プログラム出力行の場合、テスト
事項の生成に設計情報のみを必要とするか設計情報およ
び標準テスト事項を必要とするかを判断するテスト事項
判断手段５と、設計情報を元にテスト事項を生成する第
１テスト事項生成手段６と、設計情報および標準テスト
事項を元にテスト事項を生成する第２テスト事項生成手
段７と、データ解析手段４で解析された固定出力行およ
び第１テスト事項生成手段６および第２テスト事項生成
手段７で生成されたテスト事項を出力するテスト仕様書
書き出し手段８とから構成されている。

【０００８】設計情報は、設計工程で作成された情報で
あって、設計情報記憶手段９に設計テーブル単位で格納
されている。テスト構成記憶手段１に記憶されたテスト
構成ファイルは、１行が階層情報部およびデータ部から
構成されている。標準テスト事項記憶手段３に記憶され
た標準テスト事項ファイルは、テスト構成ファイルでは
記述しきれなかったテスト事項の詳細を記述したもの
で、パターン名とパターン詳細を記述した情報とから構
成されている。

【０００９】上記構成のテスト仕様書作成装置によれ
ば、まず、テスト構成記憶手段１のテスト構成ファイル
に記述されたテスト仕様が１行ずつデータ解析手段４に
よって読み込まれる。データ解析手段４は読み込んだテ
スト構成ファイルの１行のデータ部を解析して、当該行
がそのデータ部の内容をそのまま出力する固定出力行か
プログラムから出力するプログラム出力行かを判断す
る。固定出力行と判断された場合は、テスト仕様書書き
出し手段８は階層情報とともにデータ部の内容をテスト
仕様書１０に展開する。プログラム出力行と判断された
場合は、テスト事項判断手段５にてプログラム出力行の
パターン名により、設計情報記憶手段９の設計テーブル
にある設計情報のみでテスト事項を生成できる第１パタ
ーンか、あるいは設計情報記憶手段９の設計テーブルに
ある設計情報と標準テスト事項ファイルのパターン詳細
に記述された情報とからテスト事項を生成できる第２パ
ターンであるかを判断する。第１パターンの場合、第１
テスト事項生成手段６は、設計情報読み込み手段２を利
用して、設計情報記憶手段９の各設計テーブルから、テ
スト事項生成に必要な情報を取得し、取得した情報を加
工し、階層情報を付加して、テスト仕様書書き出し手段
８に渡す。第２パターンの場合、第２テスト事項生成手
段７は、設計情報記憶手段９の各設計テーブルから、テ
スト事項生成に必要な情報を取得する。そのとき、さら
に詳細にテスト事項を生成する必要がある場合には、標
準テスト事項記憶手段３の標準テスト事項ファイルか
ら、パターン名に対応するパターン詳細を取得し、設計
情報とパターン詳細とを加工し、階層情報を付加して、
テスト仕様書書き出し手段８に渡す。テスト仕様書書き
出し手段８は、データ解析手段４からの固定出力、第１
テスト事項生成手段６および第２テスト事項生成手段７
で生成されたテスト事項を１行ずつ出力してテスト仕様
書１０を作成する。これにより、設計段階で作成された
設計情報を継承したテスト仕様書を作成することがで
き、テスト工程でのテスト事項生成に必要な情報のエン
トリ作業を省略することができる。

【００１０】また、本発明によれば、テスト仕様書の基
本的な構成を記述したテスト構成ファイルを管理するテ
スト構成管理手段と、設計工程で作成された設計情報を
読み込む設計情報読み込み手段と、詳細なテスト事項を
記述した標準テスト事項ファイルを管理する標準テスト
事項管理手段と、テスト構成ファイルに記述された文が
固定出力行かプログラム出力行かを行単位で解析するす
るデータ解析手段と、プログラム出力行の場合にテスト
事項の生成に設計情報のみを必要とするか設計情報およ
び標準テスト事項を必要とするかを判断するテスト事項
判断手段と、設計情報を元にテスト事項を生成する第１
テスト事項生成手段と、設計情報および標準テスト事項
を元にテスト事項を生成する第２テスト事項生成手段
と、データ解析手段で解析された固定出力行および第１
テスト事項生成手段および第２テスト事項生成手段で生
成されたテスト事項を出力してテスト仕様書ファイルを
構成するテスト仕様書書き出し手段とを有する、テスト
仕様書作成プログラムを記憶したコンピュータ読み取り
可能な記憶媒体が提供される。

【００１１】この媒体に記録されたテスト仕様書作成プ
ログラムをコンピュータに実行させることにより、テス
ト構成管理手段と、設計情報読み込み手段と、標準テス
ト事項管理手段と、データ解析手段と、テスト事項判断
手段と、第１テスト事項生成手段と、第２テスト事項生
成手段と、テスト仕様書書き出し手段と、の各機能がコ
ンピュータによって実現できる。

【００１２】

【発明の実施の形態】まず、本発明の概略について図面
を参照して説明する。図１は本発明の原理構成を示す図
である。テスト仕様書作成装置は、テスト仕様書の大き
な流れを記述したテスト構成ファイルを記憶するテスト
構成記憶手段１と、設計工程で作成された設計情報を読
み込む設計情報読み込み手段２と、テスト構成ファイル
で記述しきれなかったテスト事項の詳細を記述した標準
テスト事項ファイルを記憶する標準テスト事項記憶手段
３と、テスト構成ファイルに記述された文を行単位で読
み込んでその文は固定出力行かプログラム出力行かを解
析するデータ解析手段４と、プログラム出力行の場合、
テスト事項の生成に設計工程で作成された設計情報のみ
を必要とするか、あるいは設計情報および標準テスト事
項ファイルの標準テスト事項を必要とするかを判断する
テスト事項判断手段５と、設計工程で作成された設計情
報を元にテスト事項を生成する第１テスト事項生成手段
６と、設計工程で作成された設計情報および標準テスト
事項ファイルの標準テスト事項を元にテスト事項を生成
する第２テスト事項生成手段７と、データ解析手段４で
解析された固定出力行および第１テスト事項生成手段６
および第２テスト事項生成手段７で生成されたテスト事
項を出力するテスト仕様書書き出し手段８とから構成さ
れている。

【００１３】設計工程で作成された設計情報は、設計情
報記憶手段９に設計テーブル単位で格納されている。テ
スト構成記憶手段１にひな形テスト仕様書ファイルとし
て記憶されたテスト構成ファイルは、１行が階層情報部
およびデータ部から構成されている。標準テスト事項記
憶手段３に記憶された標準テスト事項ファイルは、パタ
ーン名とパターン詳細とを記述した情報とから構成され
ていて、このファイルの使用はテスト構成ファイルに指
示されている。

【００１４】テスト仕様書作成装置によりテスト仕様書
を作成するとき、まず、データ解析手段４がテスト構成
記憶手段１に記憶されているテスト構成ファイルからそ
こに記述されたテスト仕様文を１行ずつ読み込む。デー
タ解析手段４は読み込んだ１行に記述されているデータ
部を解析して、当該行がそのデータ部の内容をそのまま
出力する固定出力行かプログラムから出力するプログラ
ム出力行かを判断する。データ解析手段４が固定出力行
と判断した場合は、テスト仕様書書き出し手段８によ
り、階層情報とともにデータ部の内容をテスト仕様書１
０にそのまま展開する。プログラム出力行と判断された
場合は、テスト事項判断手段５にてプログラム出力行に
指定されたパターン名により、設計情報記憶手段９の設
計テーブルにある設計情報のみでテスト事項を生成でき
る第１パターンか、あるいは設計情報記憶手段９の設計
テーブルにある設計情報と標準テスト事項ファイルのパ
ターン詳細に記述された情報とからテスト事項を生成で
きる第２パターンであるかを判断する。第１パターンと
判断された場合、第１テスト事項生成手段６は、設計情
報読み込み手段２を利用して、設計情報記憶手段９の各
設計テーブルから、テスト事項生成に必要な情報を取得
し、取得した情報を加工し、階層情報を付加して、テス
ト仕様書書き出し手段８に渡す。第２パターンと判断さ
れた場合には、第２テスト事項生成手段７は、第１パタ
ーンの場合と同様に、設計情報記憶手段９の各設計テー
ブルから、テスト事項生成に必要な情報を取得する。そ
のとき、さらに詳細にテスト事項を生成する必要がある
場合には、標準テスト事項記憶手段３の標準テスト事項
ファイルから、パターン名に対応するパターン詳細を取
得し、設計情報とパターン詳細とを加工して、テスト仕
様書書き出し手段８に渡す。テスト仕様書書き出し手段
８は、データ解析手段４からの固定出力行、第１テスト
事項生成手段６および第２テスト事項生成手段７で生成
されたテスト事項を１行ずつファイルに出力してテスト
仕様書１０を作成していく。

【００１５】これにより、テスト構成ファイルをテスト
の大きな流れの設定とし、テスト構成ファイルで指示さ
れた標準テスト事項ファイルをその詳細設定とし、これ
らを元に、設計段階で作成された設計情報を継承したテ
スト仕様書を作成することが可能になる。したがって、
テスト工程でのテスト事項生成に必要なテスト情報のエ
ントリ作業を省略することが可能になり、開発の生産性
を向上させることができる。

【００１６】次に、本発明の実施の形態を、受注入力シ
ステムのアプリケーション開発するコンピュータに適用
した場合を例にして説明する。図２は設計情報からテス
ト仕様書を生成する装置を実施する全体構成を示す図で
ある。本発明によるテスト仕様書作成装置は、たとえば
パーソナルコンピュータ１１に実装することによって実
施される。パーソナルコンピュータ１１は中央処理装置
（ＣＰＵ）１２と、メモリ１３と、ハードディスク１４
と、ＬＡＮ（Local Area Network）ボード１５とを備え
ている。ハードディスク１４には、テスト仕様書生成プ
ログラム１４ａと、このテスト仕様書生成プログラム１
４ａと一緒にあらかじめ提供される、ひな形テスト仕様
書ＩＮＩファイル１４ｂおよびひな形テスト計画書１４
ｃと、開発プロジェクトに応じてひな形テスト仕様書Ｉ
ＮＩファイル１４ｂをカスタマイズしたテスト構成ＩＮ
Ｉファイル１４ｄ，１４ｅおよび標準テスト事項ＩＮＩ
ファイル１４ｆとが格納されている。また、パーソナル
コンピュータ１１は、ＬＡＮボード１５を介してネット
ワーク２１に接続されており、そのネットワーク２１に
は設計工程を担当するコンピュータ３１に接続されてい
る。このコンピュータ３１は外部記憶装置であるハード
ディスク３２を備えており、そのハードディスク３２に
は設計工程で設計された設計情報３２ａがテーブル単位
に格納されており、リポジトリ管理されている。

【００１７】テスト仕様書を作成するときには、テスト
仕様書生成プログラム１４ａがメモリ１３に展開され、
中央演算装置１２によって実行される。このテスト仕様
書生成プログラム１４ａの作用を説明する前に、テスト
作業の流れについて先に説明する。

【００１８】図３はテスト作業の全体の流れを示す概略
図である。まず、テスト工程では、大きく分けて、テス
ト計画段階４０と、テスト設計・作成段階５０と、テス
ト実行・結果分析段階６０とに分類される。

【００１９】テスト計画段階４０では、テストの目的、
テストの完了基準、テスト手順、役割分担、性能目標、
品質管理指標、スケジュールなどをテスト計画書として
作成する。

【００２０】テスト設計・作成段階５０では、まず、テ
ストライフサイクル５１を作成する。テストライフサイ
クル５１は、テストの目的により、ユニットテスト、ビ
ルドテスト、インテグレーションテスト、およびシステ
ムテストの４種類に分類化される。ユニットテストは、
プログラムを単体レベルでテストする。ビルドテスト
は、プログラム内画面／機能間をテストする。インテグ
レーションテストは、プログラム間、サブシステム間、
システム間の整合性をテストする。システムテストは、
性能テスト、マルチユーザ（多重処理）テスト、メモリ
やディスク資源に関する負荷テスト、大量データを使っ
ての負荷テスト、システム全体の機能確認などのテスト
を行う。次に、システム機能をテストするビジネス機能
テスト、ＧＵＩ（Graphical User Interface）をテスト
するユーザインタフェーステスト、画面の入出力項目を
テストするフィールドバリデーションテスト、データベ
ース更新をテストするトランザクションテスト、帳票を
テストするプリントテスト、イレギュラー処理をテスト
するイレギュラーテストなど、各テストライフサイクル
に対し、テストの目的に応じたテストフレームワーク５
２を作成する。次に、各テストフレームワークに対し、
プログラムおよび画面ごとに具体的にどのようなテスト
を行うかを調べて、テスト要求事項を明確化し、テスト
ライフサイクルごとのテストフレームワークにテスト要
求事項を階層的に分類することで、テスト事項５３を作
成する。これにより、テスト仕様書が作成される。次
に、テストをどのような単位（たとえば画面単位、動作
単位など）、どのような手順でテストを行うかを記述し
たテストプロシージャ５４を作成する。そして、各テス
ト要求事項に対してあるテストをした場合に、結果はど
うあるべきかを記述したテストケース５５を作成する。

【００２１】次のテスト実行・結果分析段階６０では、
テスト設計・作成段階５０で作成されたテスト仕様書、
テストプロシージャ、およびテストケースを元にテスト
を実施し（６１）、テスト結果の評価をし（６２）、テ
スト結果の分析をする（６３）。ここで、分析の結果、
不具合があれば、その不具合がプログラムなのかテスト
設計なのかを判断する（６４）。プログラムの不具合な
らば、製造工程に戻って、プログラムを修正し（６
５）、テスト設計が不具合ならば、テスト設計・作成段
階５０に戻って、テスト仕様書を修正し、再テストとい
うことになる。

【００２２】ここで、確認のために、システム開発全体
の流れについて説明する。図４はシステム開発の全体の
流れを示すフローチャートである。まず、設計工程での
設計作業があり（ステップＳ１）、設計した情報を元に
画面構成の確認をする設計レビューがある（ステップＳ
２）。設計した情報をレビューしてよければ、その設計
仕様書を元にプログラムの製造を行う（ステップＳ
３）。これと並行して、設計情報を元にテスト計画書を
作り（ステップＳ４）、テスト仕様書を作成する（ステ
ップＳ５）。このステップＳ４およびステップＳ５はテ
スト仕様書生成プログラム１４ａが担当する。次に、こ
のテスト仕様書生成プログラム１４ａで生成されたテス
ト仕様書に対し、テスト事項のカスタマイズおよび必要
なテスト事項の追加を行って、テスト仕様書を完成させ
（ステップＳ６）、それ以降、プロシージャを作成し
（ステップＳ７）、テストケースを作成する（ステップ
Ｓ８）。さらに、作成されたテスト仕様書を使って実際
にテストをするのに必要なテストデータマスタの作成も
併せて行う（ステップＳ９）。最後に、製造されたプロ
グラムとテストデータとを使い、テスト仕様書に従って
テストを行うことになる（ステップＳ１０）。

【００２３】次に、テスト仕様書生成プログラム１４ａ
が持つ概略的な処理の流れについて説明する。図５はテ
スト仕様書生成のための処理の流れを示すフローチャー
トである。まず、ひな形テスト仕様書の定義を行う（ス
テップＳ１１）。これは、ひな形テスト仕様書ＩＮＩフ
ァイル１４ｂを元に、開発プロジェクトの特性に合わせ
てカスタマイズすることによりテスト構成ＩＮＩファイ
ル１４ｄ，１４ｅを作成し、また、プロジェクトの特性
に合わせて標準テスト事項ＩＮＩファイル１４ｆを作成
する作業である。変更を要しない場合は、ひな形テスト
仕様書ＩＮＩファイル１４ｂをそのまま使うことができ
る。次に、テスト計画書を自動生成する（ステップＳ１
２）。テスト計画書はテストの目的を書き、テストの内
容を定義したワープロ文書であり、ひな形テスト計画書
１４ｃとして前もって提供されているので、そのひな形
テスト計画書１４ｃをファイルコピーすることによっ
て、テスト計画書を自動生成している。次に、テスト事
項＜サブシステム＞の自動生成を行い（ステップＳ１
３）、テスト事項＜プログラム＞の自動生成を行う（ス
テップＳ１４）。そして、全プログラムについてテスト
事項の生成が終わったかどうかの判断があり（ステップ
Ｓ１５）、全プログラムが終了しなければ、ステップＳ
１４に戻り、全プログラムが終了すれば、このテスト仕
様書の生成処理は終了する。プログラムは、一番上にシ
ステムがあり、それがサブシステムに分割され、各サブ
システムの中にプログラムという最小単位がある、とい
うように３階層に分類することができる。テストの実際
の作業はプログラム単位にテストしていくので、各プロ
グラムのテスト仕様書が必要であり、プログラム単位の
テスト事項の生成という機能が用意されている。このプ
ログラム単位のテスト事項の生成結果は、サブシステム
として組み上げてサブシステムのテスト仕様書に組み上
げることができるので、サブシステムという単位のテス
ト仕様書も必要である。したがって、サブシステム名だ
けをまず生成し、次にサブシステム名ごとにプログラム
単位に生成したテスト事項を追加してテスト仕様書を生
成していくことになる。このため、テスト事項＜サブシ
ステム＞の生成は一回で済むが、プログラムは複数存在
するから、プログラム本数分生成作業が行われる。

【００２４】ここで、テスト事項の生成の例を示す前
に、テスト事項生成に必要な設計情報について説明す
る。設計情報には、サブシステム一覧、プログラム一
覧、画面一覧、アクション一覧、入出力情報定義、およ
びアクション詳細定義があり、これらは、設計工程で使
用したＣＡＳＥ機能によってハードディスク３２にテー
ブル単位で設計情報３２ａとして蓄積されている。以
下、これらの設計情報の例を示す。

【００２５】図６は設計情報のサブシステム一覧の一例
を示す図である。サブシステム一覧７１はサブシステム
名に関する情報を一元管理するテーブルであり、サブシ
ステム番号（Ｎｏ．）、サブシステム識別子（ＩＤ）、
サブシステム名（名称）のフィールドから構成されてい
る。図示の例では、五つのサブシステムが設計されてい
ることを示している。

【００２６】図７はプログラム一覧の一例を示す図であ
る。プログラム一覧７２は、プログラム番号（Ｎ
ｏ．）、プログラムＩＤ、プログラム名、種別のフィー
ルドから構成されている。図示の例は、サブシステムＩ
ＤがＪＹＵ、すなわち、受注サブシステムのプログラム
一覧を示しており、受注サブシステムは９本のプログラ
ムから構成されていることを示している。

【００２７】図８は画面一覧の一例を示す図である。画
面一覧は、画面番号（Ｎｏ．）、フォームＩＤ、フォー
ム名、および種別のフィールドか構成されている。図示
の例では受注サブシステムで使用される画面は１１種類
作成されていることを示している。

【００２８】図９はアクション一覧の一例を示す図であ
る。アクション一覧７４は、各種画面に定義されている
ボタン（またはファンクションキー）の情報を一元管理
するテーブルであって、アクション名称、アクションＩ
Ｄ、ファンクションキー（ＰＦキー）、名称のフィール
ドによって構成されている。図１０は入出力情報定義の
一例を示す図である。入出力情報定義７５は画面内の項
目単位の属性情報を一元管理しているもので、項目番号
（Ｎｏ．）、項目名、グループ（Ｇ）、レベル（Ｌ）、
タイプ、属性、桁数、小数桁数、最大長、フォーマッ
ト、自動タブ（Ｔ）、ＩＭＥ（Input Method Editor ）
モード（Ｉ）、必須入力、自動コード（Ｃ）、コードＩ
Ｄ、表示項目名などのフィールドから構成されている。
図示のテーブルは、フォームＩＤ＝ＪＹＵ０１００１で
あるので、受注入力画面（部署なし）に登場する項目の
詳細な属性情報が一覧になっている。たとえば受注番号
というエリアは、数字属性で、６桁であると言った、詳
細情報が定義されている。ここで、グループには、受注
入力画面の項目をヘッドグループ、ボディグループ、テ
イルグループの論理グループにグループ分けして設計し
ており、そのどのグループに属しているかが指定されて
いる。タイプには、入力もできるし表示もできるような
属性「テキスト」、表示だけできて入力はできない属性
「ラベル」などがある。

【００２９】図１１は入出力情報のアクション詳細定義
の一例を示す図である。アクション詳細定義では、入出
力情報定義７５で詳細定義した画面において、押すこと
ができるボタンをグループごとに詳細に定義している。
図示の例では、処理区分モード切り替えと論理的に区分
された「０」グループでは、１，５，６，７，１０，１
２番目のＰＦキーを押すことができることを定義してい
る。そして、各ＰＦキーが押されたときに、どのような
アクションをとるかが、アクションＩＤ、アクション名
称、アクション種別、アクション情報などによって詳細
に定義されている。アクション情報は、ＰＦキーが押さ
れたときのアクションを定義しており、たとえば１グル
ープのＦ０３では、アクション種別がフォームの切り替
えを表す「ＦＲＭ」となっていることから、フォームＩ
Ｄ＝ＪＹＵ０１００３の画面に切り換えることを指示し
ている。

【００３０】以上の設計情報を元に図５に示した流れに
従ってテスト仕様書を生成することになる。まず、ひな
型テスト仕様書ＩＮＩファイル１４ｂを元に、開発プロ
ジェクトの特性に合わせてカスタマイズすることにより
テスト構成ＩＮＩファイル１４ｄ，１４ｅを作成する
が、この作成例を以下に示す。

【００３１】図１２はテスト構成ＩＮＩファイルのテス
ト事項＜サブシステム＞版の定義例を示す図である。テ
スト構成ＩＮＩファイルのファイルフォーマットについ
て説明する。１行目はテスト構成ＩＮＩファイルの制御
行につき、修正は不可である。２行目以降はプロジェク
トによりカスタマイズ可能な行である。２行目は、プロ
グラム出力行であって、デリミタ" ，" によって二つの
部分に分けられており、第１区切り目は階層番号、第２
区切り目は＃を含む制御文字とタイトルからなる生成パ
ターン名を記述している。３行目以降の固定出力行につ
いては、デリミタによって三つの部分に分けられ、第１
区切り目に階層番号、第２区切り目にテスト仕様のタイ
トル、第３区切り目にテスト仕様の詳細がそれぞれ記述
される。

【００３２】図１３はテスト構成ＩＮＩファイルのテス
ト事項＜プログラム＞版の定義例を示す図である。図示
のファイルの記述例において、１行目の制御行には、パ
ラメータとしてファイル名が記述されているが、これは
テスト仕様書の生成にそのファイル名の標準テスト事項
ＩＮＩファイルを使用することを指示している。２行目
はプログラム名の生成指示である。３行目は２行目より
も１階層を下げて第２区切り目の記述をそのまま出力指
示する固定出力行である。以降の行は、第１区切り目の
階層指示とともに固定出力またはプログラム出力が指示
される。ここで、第２区切り目が＃で始まるプログラム
出力行の生成パターン名についてまとめておく。

【００３３】図１４は生成パターン名一覧を示す図であ
る。この一覧において、「＃００１０＿ＰＧ」はプログ
ラム名の生成指示、「＃００２０＿ＦＯＲＭ」はフォー
ム名の生成指示、「＃００３０＿ＡＣＴＩＯＮ」はアク
ションのテスト事項の生成指示、「＃００４０＿ＩＮ＿
ＩＴＥＭ」は入力フィールドの展開指示、「＃００５０
＿ＯＵＴ＿ＩＴＥＭ」は表示フィールドの展開指示、
「＃００７０＿ＤＥＴＡＩＬＳ＿ＣＯＮＴＲＯＬ」は明
細型テスト事項の生成指示、「＃００８０＿ＩＭＥ」は
ＩＭＥモードのテスト事項生成指示、「＃００９０＿Ｉ
Ｎ＿ＥＲＲ」はエラー入力テスト事項の生成指示、「＃
１０１０＿ＳＵＢＳＹＳＴＥＭ」はテスト構成ＩＮＩフ
ァイルのテスト事項＜サブシステム＞版にてサブシステ
ム名でテスト事項の生成指示を示している。

【００３４】図１５は標準テスト事項ＩＮＩファイルの
定義例を示す図である。この標準テスト事項ＩＮＩファ
イルは、生成パターンの内、さらに詳細設定できるパタ
ーンについて、詳細設定を記述するファイルであって、
プロジェクトの特性に合わせてカスタマイズされる。こ
のファイルのファイルフォーマットは、「［パターン
名］」とその詳細設定の分岐条件である「パターン詳細
＝」とから構成されている。「［パターン名］」は、図
示の例では、図１３に示した、テスト構成ＩＮＩファイ
ルの中で指示された生成パターン名であるＡＣＴＩＯＮ
について詳細設定することを示し、「パターン詳細＝」
は、図示の例では、グループ遷移（ＧＲＰ）、データベ
ース更新（ＤＢＵ）、前頁（ＢＦＲ）、次頁（ＮＸＴ）
のアクションについて詳細設定している。

【００３５】次に、設計情報の各テーブル、テスト事項
ＩＮＩファイル、および標準テスト事項ＩＮＩファイル
を元に、テスト仕様書が生成されていく例を順次説明す
る。まず、テスト仕様書のヘッダ行の生成について説明
する。

【００３６】図１６はテスト仕様書のヘッダ行の生成を
説明する図である。テスト仕様書作成を前述のテストツ
ール「ＳＱＡ Ｓｕｉｔｅ」の書式で行ったときに、パ
ーソナルコンピュータ側からシステム日付とシステム時
間とを取得し、テスト仕様書にシステム日付およびシス
テム時間を含む１行だけを生成する。

【００３７】図１７はテスト事項＜サブシステム＞の生
成例を示す図である。テスト事項＜サブシステム＞の生
成は、設計情報のテーブルの中から図６に示したサブシ
ステム一覧７１に記述された全項目のサブシステムＩＤ
および名称を単純にテスト仕様書に展開するようにして
いる。このサブシステム一覧の全項目を展開した後は、
テスト構成ＩＮＩファイルに記述されている固定出力行
がテスト仕様書にテスト項目として生成される。

【００３８】これにより、サブシステムのテストの大枠
の仕様書ができたことになる。続いて、テスト構成ＩＮ
Ｉファイルのテスト事項＜プログラム＞版により、各サ
ブシステムのプログラムに関するテスト仕様書を生成
し、テスト仕様書の各サブシステムの記述の後に入れ子
のように追加していく。たとえば、「受注サブシステ
ム」と展開された次の行にプログラム名「受注入力（部
署なし）」のプログラムについて生成したテスト事項が
挿入されていくことになる。そして、プログラム名「受
注入力（モックアップ）」のプログラムについて生成し
たテスト事項が追加された後は、次の「発注サブシステ
ム」のプログラムについてテスト事項の生成を行い、
「発注サブシステム」の次の行へ追加していくことにな
る。

【００３９】図１８はテスト事項＜プログラム＞の生成
手順を示すフローチャートである。プログラムのテスト
事項の生成手順としては、まず、プログラム名を指示し
（ステップＳ２１）、これを元に設計情報のテーブルを
検索し、テスト仕様書生成に必要な情報を取得してテス
ト仕様書に展開することによって、テスト事項を生成し
ていく（ステップＳ２２）。ここで、ステップＳ２２に
おける各プログラム出力行のテスト事項生成の詳細につ
いてパターンごとに順次説明する。

【００４０】図１９はプログラム名のテスト事項生成を
説明する図である。生成パターン名「＃００１０＿Ｐ
Ｇ」において、どのプログラムのテスト仕様書を作るの
かを入力するエントリ画面で、たとえば「受注入力（部
署なし）」のプログラムを指定する場合、それに対応す
るプログラムＩＤ「JYU010VE」で指定される。すると、
そのプログラムＩＤをキーにして設計情報のプログラム
一覧のテーブル（図７参照）を検索する。検索の結果、
１行目のレコードが該当するので、そのレコードからプ
ログラム名が取得される。取得されたプログラム名「受
注入力（部署なし）」および最初に指定したプログラム
ＩＤは加工されてテスト仕様書に展開される。すなわ
ち、テスト仕様書中のアンダーラインで示した箇所にプ
ログラム名およびプログラムＩＤが配置された形に加工
されて、テスト仕様書のファイルにその加工された１行
が書き出される。

【００４１】図２０は画面のフォーム名のテスト事項生
成を説明する図である。生成パターン名「＃００２０＿
ＦＯＲＭ」のとき、まず、指定されたプログラム名に対
応するプログラムＩＤをキーにして、設計情報のテーブ
ル「フォームインデックス」を検索する。このフォーム
インデックスの中からに、指定されたプログラムに該当
するフォームＩＤの全レコードを取得する。図示の例で
は、プログラムＩＤ「JYU010VE」に対して二つのフォー
ムＩＤ「JYU01001」，「JYU01003」が該当している。次
に、そのフォームＩＤをキーにして、設計情報の画面一
覧のテーブル（図８参照）を検索することにより、フォ
ーム名が「受注入力画面（部署なし）」および「受注詳
細入力」というフォームが該当レコードになる。これら
のフォーム名およびフォームＩＤがテスト仕様書に展開
される。

【００４２】このように一つのプログラムの中に複数の
フォームがある場合は、複数の行が生成される。また、
このフォーム名のテスト事項生成以降において、フォー
ムに関するテスト事項生成は、フォームの数だけ繰り返
し行われる。すなわち、図１３に示したテスト構成ＩＮ
Ｉファイルでは、「＃００３０＿ＡＣＴＩＯＮ」から
「＃００８０＿ＩＭＥ」までが、フォームごとにテスト
事項が生成される。

【００４３】図２１はアクションのテスト事項生成を説
明する図である。生成パターン名「＃００３０＿ＡＣＴ
ＩＯＮ」では、たとえば指定されたプログラム名に対応
するプログラムＩＤが「JYU010VE」であった場合、フォ
ーム名のテスト事項生成のところでそれに該当するフォ
ームＩＤがフォームインデックスのテーブルより「JYU0
1001」，「JYU01003」であることがわかっており、それ
に対応するフォームインデックスが「１」，「２４」で
あったとする。このフォームインデックスで設計情報の
グループアクション一覧のテーブルに対して絞り込みを
行う。グループアクション一覧のテーブルのたとえばフ
ォームインデックスが「１」のレコードで、一番上の行
を見ると、アクションＩＤが「ＳＵＢ」というのが入っ
ている。「ＳＵＢ」は、アクション定義のテーブルを参
照することによって、アクション名称が「照会サブ」で
あることが分かり、これがテスト仕様書に書き出されて
いることが分かる。また、グループアクション一覧のテ
ーブルから「ＳＵＢ」は、グループＩＤが「０」であ
り、これをキーにグループＩＤマスタのテーブルを参照
することにより、グループコンスタントが「Ｆ＿ＭＯＤ
Ｅ」であることが分かる。グループコンスタント「Ｆ＿
ＭＯＤＥ」は、ＭＯＤＥグループと呼んでおり、テスト
仕様書には、「ＭＯＤＥ」という言葉を使って、「ＭＯ
ＤＥグループのテスト」と書き出している。ＭＯＤＥグ
ループの中に他のアクションがあると、「照会サブ」と
同じようにしてテスト仕様書に書き出される。さらに詳
細なテスト事項については、標準テスト事項の定義に従
ってテスト仕様書に展開される。この展開は、図では、
階層番号「８」の「項目チェック」、「グループ遷移」
の行に記述されている。

【００４４】図２２は入力項目のテスト事項生成を説明
する図である。生成パターン名「＃００４０＿ＩＮ＿Ｉ
ＴＥＭ」では、指定されたプログラム名に対応するプロ
グラムＩＤが「JYU010VE」であった場合、該当するフォ
ームＩＤがフォームインデックスのテーブルより「JYU0
1001」，「JYU01003」であることがわかっており、この
フォームＩＤで設計情報の入出力情報定義のテーブル
（図１０参照）に対して絞り込みを行う。入出力情報定
義のテーブルにはタイプという項目があって、そこか
ら、画面上入力できる項目を全部取得してくる。図示の
例では、ＴＸＴ（テキスト）、ＣＭＢ（コンボボック
ス）が画面上入力できる項目であり、それらに対応する
項目名「受注番号」および「取引区分」がテスト仕様書
に展開されることになる。

【００４５】図２３は出力項目のテスト事項生成を説明
する図である。生成パターン名「＃００５０＿ＯＵＴ＿
ＩＴＥＭ」では、表示項目について、テストするための
項目を書き出している。入力項目の場合と同じように、
該当フォームＩＤを求め、このフォームＩＤで設計情報
の入出力情報定義のテーブルに対して絞り込みを行う。
入出力情報定義のテーブルのタイプという項目から、画
面表示の項目であるＬＢＬ（ラベル）を全部取得し、ラ
ベルの該当する項目名をテスト仕様書に展開する。図示
の例では、項目名「処理モード」がテスト仕様書に展開
されている。

【００４６】図２４は明細型項目のテスト事項生成を説
明する図である。生成パターン名「＃００７０＿ＤＥＴ
ＡＩＬＳ＿ＣＯＮＴＲＯＬ」では、同様にフォームＩＤ
による入出力情報定義のテーブルに対して絞り込みを行
った後、レベルの項目に、伝票形式で入力できるような
明細タイプを表す「Ｍ」があったときには、テスト仕様
書に、たとえば「5.画面明細フィールド制御テスト,"制
御部の明細部のスクロールや…」というテスト項目を１
行生成する。

【００４７】図２５はＩＭＥモードのテスト事項生成を
説明する図である。生成パターン名「＃００８０＿ＩＭ
Ｅ」では、入出力情報定義において、タイプが画面上入
力できる全項目について、日本語入力ソフト（ＩＭＥ）
が指定モードになっているかをチェックするテスト事項
を生成する。画面上入力できる項目として、図示の例で
は、ＴＸＴ（テキスト）、ＣＨＫ（チェックボックス）
があり、他にもＣＭＢ（コンボボックス）が入力できる
項目である。ＩＭＥモード値としては、図示のように、
たとえば９種類あり、入力できる項目がどのモードにあ
るかは、設計情報の入出力情報定義のテーブルにある
「ＩＭＥ」という項目に設定されている。したがって、
タイプがＴＸＴ、ＣＨＫ、ＣＭＢなど、画面上入力でき
る項目から、これに対応する「項目名」および「ＩＭ
Ｅ」を取得し、「ＩＭＥ」については、ＩＭＥモード値
の説明からモード名を抽出し、これを「項目名」と結合
させる加工をした後、テスト仕様書に展開する。なお、
ＩＭＥが設定されていない場合は、「項目名」に括弧だ
けを付加してテスト仕様書に展開している。

【００４８】図２６は入力エラーテスト時のテスト事項
生成を説明する図である。生成パターン名「＃００９０
＿ＩＮ＿ＥＲＲ」では、入出力情報定義の入力項目に設
定された以外の入力が不可能かどうかのテスト事項を生
成するものである。たとえば、入出力情報定義のテーブ
ルの１行目のレコードはタイプがテキストであり、属性
が数字を表す「９＋」になっている。この場合、数字以
外の入力があると、エラーにならなければならない。こ
のような入力エラーをテスト事項として生成するため
に、タイプがＴＸＴ、ＣＭＢなど、画面上入力できる項
目から、これに対応する「項目名」を取得し、これをテ
スト仕様書に展開すればよい。

【００４９】以上のようにして生成されたテスト仕様書
を前述のテストツール「ＳＱＡ Ｓｕｉｔｅ」を利用し
てリスト出力した結果を図２７に示す。図２７はテスト
仕様書のリスト出力の一例を示す図である。図示の例で
は、記述８１に、プログラム名が記載されており、記述
８２には、固定出力がそれぞれ階層番号に従って字下げ
されて記載されている。記述８３はフォームごとの記
載、記述８４はグループごとの記載、記述８５はアクシ
ョンごとの記載である。また、記述８６，８７は標準テ
スト事項ＩＮＩファイルの情報より生成された記載であ
る。

【００５０】最後に、テスト仕様書生成プログラム１４
ａの処理の流れを示す。なお、このプログラムが持って
いる、テスト計画書自動生成機能については、示してい
ない。

【００５１】図２８はテスト仕様書生成プログラムの処
理の流れを示すフローチャートである。まず、テスト構
成ＩＮＩファイルから１行を読み出す（ステップＳ３
１）。次に、読み出した行がファイルの終了を表すファ
イル終端ラベル（ＥＯＦ）であるかどうかを判断し（ス
テップＳ３２）、ファイルの終端であれば、この処理は
終了する。ファイル終端でなければ、その入力行は固定
出力かどうかを判断する（ステップＳ３３）。ここで、
固定出力行と判断された場合は、その行をテスト仕様書
ファイルに書き出す（ステップＳ３４）。もし、入力行
がプログラム出力行であれば、設計情報が取得可能かど
うかが判断される（ステップＳ３５）。ここで、設計情
報が存在しない場合あるいは正常に読み込めなかった場
合は、ここでこの処理は終了する。設計情報が取得可能
な場合、読み込んだプログラム出力行のパターン名によ
り、標準テスト事項ＩＮＩファイルを必要とするかどう
かが判断される（ステップＳ３６）。ここで、標準テス
ト事項ＩＮＩファイルを必要とせず、設計情報の各テー
ブルのみでテスト事項を生成できる場合には、プログラ
ム出力行のパターン名に応じて、テスト生成に必要な情
報を設計情報の各テーブルから取得し（ステップＳ３
７）、プログラム一覧、画面一覧、または明細テストな
どをプログラム内で加工し（ステップＳ３８）、テスト
仕様書に書き出す。このとき、パターン名により、複数
行書き出すパターンと、１行だけ書き出すパターンがあ
る。もし、標準テスト事項を必要とする場合は、プログ
ラム出力行のパターン名に応じて、テスト生成に必要な
情報を設計情報の各テーブルから取得し（ステップＳ３
９）、さらに詳細なパターンのテスト事項を生成するた
めに、標準テスト事項ＩＮＩファイルを読み込む（ステ
ップＳ４０）。そして、取得し設計情報とパターン詳細
をプログラム内で加工して、アクションテスト事項、入
出力項目、または出力項目などのテスト事項を生成し
（ステップＳ４１）、テスト仕様書に書き出す。このと
き、パターン名や標準テスト事項ＩＮＩファイルのパタ
ーン詳細により、複数行書き出すパターンと、１行だけ
書き出すパターンがある。

【００５２】上記説明では、データ解析手段は、テスト
構成ファイルに記述された文を行単位で読み込むと説明
したが、テスト構成ファイルをファイルごとに読み込む
ものであってもよい。

【００５３】

【発明の効果】以上説明したように本発明では、テスト
仕様書の概略を記述したテスト構成ファイルとテスト事
項の詳細を記述した標準テスト事項ファイルとの記述に
従って設計工程で蓄積した設計情報からテスト仕様書を
自動生成するように構成した。このため、設計工程で既
にエントリされた設計情報を利用するため、テスト工程
でのエントリ作業が軽減され、テスト設計作業を標準
化、効率化することができる。

【００５４】また、設計情報を継承したテスト仕様書を
元にテスト作業を行うことが可能になり、そのテスト仕
様書で製造工程で作成されたプログラムが設計通りに作
成されているかのテストをすれば、プログラムの製造品
質をさらに向上させることができる。

【図面の簡単な説明】

【図１】本発明の原理構成を示す図である。

【図２】設計情報からテスト仕様書を生成する装置を実
施する全体構成を示す図である。

【図３】テスト作業の全体の流れを示す概略図である。

【図４】システム開発の全体の流れを示すフローチャー
トである。

【図５】テスト仕様書生成のための処理の流れを示すフ
ローチャートである。

【図６】設計情報のサブシステム一覧の一例を示す図で
ある。

【図７】プログラム一覧の一例を示す図である。

【図８】画面一覧の一例を示す図である。

【図９】アクション一覧の一例を示す図である。

【図１０】入出力情報定義の一例を示す図である。

【図１１】入出力情報のアクション詳細定義の一例を示
す図である。

【図１２】テスト構成ＩＮＩファイルのテスト事項＜サ
ブシステム＞版の定義例を示す図である。

【図１３】テスト構成ＩＮＩファイルのテスト事項＜プ
ログラム＞版の定義例を示す図である。

【図１４】生成パターン名一覧を示す図である。

【図１５】標準テスト事項ＩＮＩファイルの定義例を示
す図である。

【図１６】テスト仕様書のヘッダ行の生成を説明する図
である。

【図１７】テスト事項＜サブシステム＞の生成例を示す
図である。

【図１８】テスト事項＜プログラム＞の生成手順を示す
フローチャートである。

【図１９】プログラム名のテスト事項生成を説明する図
である。

【図２０】画面のフォーム名のテスト事項生成を説明す
る図である。

【図２１】アクションのテスト事項生成を説明する図で
ある。

【図２２】入力項目のテスト事項生成を説明する図であ
る。

【図２３】出力項目のテスト事項生成を説明する図であ
る。

【図２４】明細型項目のテスト事項生成を説明する図で
ある。

【図２５】ＩＭＥモードのテスト事項生成を説明する図
である。

【図２６】入力エラーテスト時のテスト事項生成を説明
する図である。

【図２７】テスト仕様書のリスト出力の一例を示す図で
ある。

【図２８】テスト仕様書生成プログラムの処理の流れを
示すフローチャートである。

【符号の説明】

１ テスト構成記憶手段 ２ 設計情報読み込み手段 ３ 標準テスト事項記憶手段 ４ データ解析手段 ５ テスト事項判断手段 ６ 第１テスト事項生成手段 ７ 第２テスト事項生成手段 ８ テスト仕様書書き出し手段 ９ 設計情報記憶手段 １０ テスト仕様書 １１ パーソナルコンピュータ １２ 中央処理装置（ＣＰＵ） １３ メモリ １４ ハードディスク １４ａ テスト仕様書生成プログラム １４ｂ ひな形テスト仕様書ＩＮＩファイル １４ｃ ひな形テスト計画書 １４ｄ，１４ｅ テスト構成ＩＮＩファイル １４ｆ 標準テスト事項ＩＮＩファイル １５ ＬＡＮボード ２１ ネットワーク ３１ コンピュータ ３２ ハードディスク ３２ａ 設計情報３２ａ

Claims (7)

【特許請求の範囲】
1. 【請求項１】 設計情報を元にテスト仕様書を作成する
   テスト仕様書作成装置において、 テスト仕様書の基本的な構成を記述したテスト構成ファ
   イルを記憶するテスト構成記憶手段と、 設計工程で作成された設計情報を読み込む設計情報読み
   込み手段と、 前記テスト構成ファイルに記述された文を行単位で読み
   込んでその文は固定出力行かプログラム出力行かを解析
   するデータ解析手段と、 入力行がデータ解析手段によりプログラム出力行と判断
   された場合に前記設計情報読み込み手段にて読み込んだ
   設計情報を元にテスト事項を生成する第１テスト事項生
   成手段と、 データ解析手段で解析された固定出力行および第１テス
   ト事項生成手段で生成されたテスト事項を出力するテス
   ト仕様書書き出し手段と、 から構成されていることを特徴とするテスト仕様書作成
   装置。
2. 【請求項２】 詳細なテスト事項を記述した標準テスト
   事項ファイルを記憶する標準テスト事項記憶手段と、入
   力行が前記データ解析手段によりプログラム出力行と判
   断された場合にテスト事項の生成に設計情報のみを必要
   とするか設計情報および標準テスト事項を必要とするか
   を判断するテスト事項判断手段と、前記テスト事項判断
   手段がテスト事項の生成に設計情報および標準テスト事
   項を必要とするかを判断した場合に前記設計情報読み込
   み手段にて読み込んだ設計情報および前記標準テスト事
   項ファイルに記述された標準テスト事項を元にテスト事
   項を生成して前記テスト仕様書書き出し手段に出力する
   第２テスト事項生成手段と、をさらに備えたことを特徴
   とする請求項１記載のテスト仕様書作成装置。
3. 【請求項３】 前記テスト事項判断手段は、テスト事項
   の生成に設計情報のみを必要とするか設計情報および標
   準テスト事項を必要とするかの判断を前記テスト構成フ
   ァイルに標準テスト事項ファイルが指定されているか否
   かで判断することを特徴とする請求項２記載のテスト仕
   様書作成装置。
4. 【請求項４】 前記テスト構成記憶手段に記憶された前
   記テスト構成ファイルは、各行を階層情報部とデータ部
   とで構成し、前記階層情報部の階層情報については前記
   テスト仕様書書き出し手段によりそのまま出力すること
   を特徴とする請求項１記載のテスト仕様書作成装置。
5. 【請求項５】 前記標準テスト事項記憶手段に記憶され
   た前記標準テスト事項ファイルは、前記設計情報のパタ
   ーン名とそのパターン詳細とから構成されていることを
   特徴とする請求項２記載のテスト仕様書作成装置。
6. 【請求項６】 テスト仕様書の基本的な構成を記述した
   テスト構成ファイルを管理するテスト構成管理手段と、
   設計工程で作成された設計情報を読み込む設計情報読み
   込み手段と、詳細なテスト事項を記述した標準テスト事
   項ファイルを管理する標準テスト事項管理手段と、テス
   ト構成ファイルに記述された文が固定出力行かプログラ
   ム出力行かを行単位で解析するデータ解析手段と、プロ
   グラム出力行の場合にテスト事項の生成に設計情報のみ
   を必要とするか設計情報および標準テスト事項を必要と
   するかを判断するテスト事項判断手段と、設計情報を元
   にテスト事項を生成する第１テスト事項生成手段と、設
   計情報および標準テスト事項を元にテスト事項を生成す
   る第２テスト事項生成手段と、データ解析手段で解析さ
   れた固定出力行および第１テスト事項生成手段および第
   ２テスト事項生成手段で生成されたテスト事項を出力し
   てテスト仕様書ファイルを構成するテスト仕様書書き出
   し手段とを有する、テスト仕様書作成プログラムを記憶
   したコンピュータ読み取り可能な記憶媒体。
7. 【請求項７】 設計情報を元にテスト仕様書を作成する
   テスト仕様書作成装置において、 テスト仕様書の基本的な構成を記述したテスト構成ファ
   イルを記憶するテスト構成記憶手段と、 設定工程で作成された設計情報を読み込む設計情報読み
   込み手段と、 前記テスト構成ファイルに記述された文を読み込んでそ
   の文は固定出力行かプログラム出力行かを解析するデー
   タ解析手段と、 入力行がデータ解析手段によりプログラム出力行と判断
   された場合に前記設計情報読み込み手段にて読み込んだ
   設計情報を元にテスト事項を生成する第１テスト事項生
   成手段と、 データ解析手段で解析された固定出力行および第１テス
   ト事項生成手段で生成されたテスト事項を出力するテス
   ト仕様書書き出し手段と、 から構成されていることを特徴とするテスト仕様書作成
   装置。