JP2008293382A - Automatic test specification generation system - Google Patents
Automatic test specification generation system Download PDFInfo
- Publication number
- JP2008293382A JP2008293382A JP2007139753A JP2007139753A JP2008293382A JP 2008293382 A JP2008293382 A JP 2008293382A JP 2007139753 A JP2007139753 A JP 2007139753A JP 2007139753 A JP2007139753 A JP 2007139753A JP 2008293382 A JP2008293382 A JP 2008293382A
- Authority
- JP
- Japan
- Prior art keywords
- test
- event
- data
- scenario path
- test scenario
- 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.)
- Withdrawn
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
- Stored Programmes (AREA)
Abstract
Description
本発明は、組み込みソフトウェアを含むソフトウェアのテスト仕様の項目を設計するにあたって、自動的にテスト仕様を生成するテスト仕様自動生成方式に関するものである。 The present invention relates to an automatic test specification generation method for automatically generating a test specification when designing test specification items of software including embedded software.
従来、イベント駆動型ソフトウェアの要求仕様からテストケースを自動生成する場合、ＵＭＬ(Unified Modeling Language)(統一モデリング言語)のユースケース記述を用いたユースケース駆動テストがソフトウェア開発に従事する者に広く知られている。 Conventionally, when generating test cases automatically from the requirements of event-driven software, use case-driven testing using UML (Unified Modeling Language) use case description is widely known to those engaged in software development. It has been.
また特許文献１では、要求仕様に含まれる各ユースケースの実行過程を履歴として残し、ユースケースを実行してシステムの動きを表すシナリオを生成し、生成されたシナリオを参照することにより、記述された要求仕様中でユースケースの抜けや記述漏れがないかを確認する技術を開示している。
Further, in
また非特許文献１では、上記したユースケース駆動テストについて、ユースケース仕様書からシナリオとテストケースを抽出し、テストケースの条件を加えてテストケースマトリックスを完成させる方法について開示している。
Non-Patent
さらに非特許文献２では、ユースケースのイベントフローと特殊要件によりシステムのテストケースのほとんどが検出可能であることを示唆している。
従来技術であるユースケース駆動テストは、テストシナリオやテストケースの生成を手動で行っているか、人の判断に依存したテストケースおよびテストシナリオの抽出を行っている。 The use case-driven test, which is a conventional technology, manually generates test scenarios and test cases, or extracts test cases and test scenarios that depend on human judgment.
また特許文献１は、要求仕様に含まれる各ユースケースの実行過程を履歴として残し、ユースケースを実行してシステムの動きを表すシナリオを生成し、生成されたシナリオを参照することにより、記述された要求仕様中でユースケースの抜けや記述漏れがないかを確認しているが、要求仕様記述および自動生成したテストシナリオパスからテスト仕様を自動的に生成すること、またテスト仕様の生成状況により要求仕様の不備を検出することについての記載はなされていない。
また非特許文献１は、ユースケース駆動テストについて、ユースケース仕様書からシナリオとテストケースを抽出し、テストケースの条件を加えてテストケースマトリックスを完成させる方法について開示しているが、テストケースマトリックスの生成は全てユースケース仕様書を目視して人手により生成するものであり、生成工数がかかり、また記述漏れや抜けが発生する可能性が高い。
Non-Patent
さらに非特許文献２は、ユースケースのイベントフローと特殊要件によりシステムのテ
ストケースのほとんどが検出可能であるとし、ユースケース及び特殊要件（非機能要件）からテスト仕様を抽出することが妥当であると述べている。しかし具体的方式については触れていない。
Furthermore, in Non-Patent
上述したこれらの問題点を解決するために本発明は、要求仕様記述および自動生成したテストシナリオパスからテスト仕様を自動的に生成するテスト仕様自動生成方式を提供することを目的とする。 In order to solve these problems described above, an object of the present invention is to provide an automatic test specification generation method that automatically generates a test specification from a requirement specification description and an automatically generated test scenario path.
上記目的を達成するために本発明は、テスト仕様生成に関するデータ項目およびテストシナリオパス生成に関するデータ項目について要求仕様記述がなされた要求仕様を格納する要求仕様ファイルと、テストシナリオパス生成処理手段の処理によって生成されるテストシナリオパスの処理過程中のデータを一時保存するテストシナリオパステーブルと、前記テストシナリオパス生成処理手段の処理によって自動生成されたテストシナリオパスを格納するテストシナリオパスファイルと、テスト仕様生成処理手段の処理によって自動生成されたテスト仕様データとテスト担当者入力の判定データとを格納するテスト仕様ファイルと、を有し、テスト担当者指示により起動され、前記要求仕様ファイルに格納された要求仕様の中からテストシナリオパス生成に関するデータ項目を抽出しかつテスト担当者によって指定されたテスト戦略に対応するテストシナリオパスを、前記テストシナリオパステーブルに一時保存された処理過程中のデータを用いてテストシナリオパスを自動的に生成するテストシナリオパス生成処理手段と、テスト担当者指示により起動され、前記要求仕様ファイルに格納された要求仕様の中からテスト仕様生成に関するデータ項目を抽出するとともに、前記テストシナリオパスファイルに格納されたテストシナリオパスの中からテスト仕様生成に関するデータ項目を抽出して、判定項目を除くテスト仕様を自動的に生成するテスト仕様生成処理手段と、を備えていることを特徴とする。 To achieve the above object, the present invention provides a requirement specification file for storing requirement specifications in which requirement specifications are described for data items relating to test specification generation and data items relating to test scenario path generation, and processing of test scenario path generation processing means A test scenario path table that temporarily stores data during the process of the test scenario path generated by the test scenario path file, a test scenario path file that stores the test scenario path automatically generated by the processing of the test scenario path generation processing means, and a test A test specification file for storing test specification data automatically generated by the processing of the specification generation processing means and determination data input by a tester, and is activated by a tester instruction and stored in the required specification file Test scenario from the required specifications Data items related to path generation are extracted, and test scenario paths corresponding to the test strategy specified by the tester are automatically used, and test scenario paths are automatically used by using the in-process data temporarily stored in the test scenario path table. The test scenario path generation processing means to be generated at the same time and the test person instructed by the test person, extract data items related to test specification generation from the requirement specifications stored in the requirement specification file and store them in the test scenario path file Test specification generation processing means for extracting data items relating to test specification generation from the test scenario path thus generated and automatically generating test specifications excluding determination items.
本発明によれば、要求仕様記述および自動生成したテストシナリオパスからテスト仕様を自動的に生成することが可能となり、テスト仕様の生成状況から要求仕様の不備を容易に検出することができ、ソフトウェア開発の早期の段階で要求仕様の記述漏れや抜け、曖昧さをなくし、更にテスト仕様の漏れや抜け、曖昧さをなくすことで手戻り作業を削減し、品質の高いソフトウェアを開発することが可能となる。 According to the present invention, it is possible to automatically generate a test specification from a requirement specification description and an automatically generated test scenario path, and it is possible to easily detect a deficiency of the requirement specification from the test specification generation status. Eliminate omissions, omissions, and ambiguities in required specifications at an early stage of development, and further reduce the reworking by eliminating omissions, omissions, and ambiguities in test specifications, and develop high-quality software It becomes.
以下、本発明の実施の形態を、図面を参照しながら説明する。
図１は、本発明テスト仕様自動生成に係るシステム構成概要を示す図である。図１に示すシステム構成は、本発明テスト仕様自動生成を実現する上でのハードウェア環境を概略的に示したもので、本発明テスト仕様自動生成は、クライアントとサーバとがネットワークで結合されるクライアントサーバシステムを用いて実現される例について説明するが、他のシステム構成であってもよい。
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
FIG. 1 is a diagram showing an outline of a system configuration related to automatic test specification generation according to the present invention. The system configuration shown in FIG. 1 schematically shows a hardware environment for realizing automatic test specification generation of the present invention. In the automatic test specification generation of the present invention, a client and a server are connected by a network. Although an example realized using a client server system will be described, other system configurations may be used.
クライアント11はネットワーク10経由でサーバ１に繋がれ、周知のクライアントが有するコンピュータハードウェア資源を用いてサーバ１に対する処理の起動やデータの表示(ダウンロードを含む)、データの設定(アップロードを含む)を行う。ネットワーク10はクライアント11とサーバ１とを連携するもので、ＬＡＮ、公衆網（インターネットを含む）など、周知のネットワーク技術を用いることができる。サーバ１のコンピュータハードウェア資源は当業者に周知のコンピュータ技術によって実現されているもので、例えばコンピュータハードウェア資源としてＣＰＵ、記憶装置(ＲＯＭ，ＲＡＭ，ＨＤＤを含む)、入出力装置(通信Ｉ/Ｆ，ディスプレイ，プリンタ，マウス，キーボードなどを含む)などを備えている。なお本発明テスト仕様自動生成に係るハードウェア構成については後述する
それぞれの生成処理部動作において詳しく説明する。
The
図１では、本発明テスト仕様自動生成に係る各種ファイルのデータ構造を概略的に説明している。各種ファイルのデータ構造は、本発明テスト仕様自動生成に係る各種ファイルの全体構成を理解しやくするために記載しているものである。そして各種ファイルは、上述したサーバ１の記憶装置(ＲＯＭ，ＲＡＭ，ＨＤＤを含む)に保存され、サーバ１のＣＰＵによってアクセス可能にされる。
FIG. 1 schematically illustrates the data structure of various files related to automatic test specification generation according to the present invention. The data structure of each file is described in order to make it easy to understand the overall configuration of each file related to the automatic generation of test specifications of the present invention. Various files are stored in the storage device (including ROM, RAM, and HDD) of the
図１に示す要求仕様ファイル２は、要求仕様記述がなされたデータを格納するものである。要求仕様の記述をなすために、図１０のデータの流れ(１)に示すようにクライアント11の要求仕様記述を行うテスト担当者がサーバ１にログインし、サーバ１から要求仕様記述に係るデータなどをダウンロードする。クライアント11の要求仕様記述を行うテスト担当者は、表示画面上において必要なデータを入力する。本発明では要求仕様記述について以下に示すような所定の規約を設けている。すなわち、本発明の要求仕様記述では、要求仕様の機能要件および非機能要件をソフトウェア開発従事者に周知のＵＭＬ(Ｕnified Ｍodeling Ｌanguage)のユースケース図を用いたユースケース記述を基本とし、さらに要求仕様の項目の漏れ抜けや曖昧さをなくすため形式的仕様記述言語であるソフトウェア開発従事者に周知のＶＤＭ−ＳＬ（Vienna Development Method Specification Language)の構文に基づいた項と境界値テストを想定した境界値の項を追加する。なお、ＶＤＭ−ＳＬは、ISO_IEC_13817-1として標準化されているものである。
The
またユースケース記述によるイベントフローの各イベントには形式的仕様記述言語であるＶＤＭ−ＳＬの「操作定義」構文に対応した項を設ける。すなわち
operation definition=identifier, parameter types
externals,
'pre', expression,
'post', expression
のＶＤＭ−ＳＬの「操作定義」構文について
identifierを「イベント」
parameter typesを「入力データ」
externalsを「外部データ」
'pre', expressionを「事前条件」
'post', expressionを「事後条件」
に対応付ける。
Each event in the event flow by use case description is provided with a term corresponding to the “operation definition” syntax of VDM-SL, which is a formal specification description language. Ie
operation definition = identifier, parameter types
externals,
'pre', expression,
'post', expression
The "operation definition" syntax of VDM-SL
identifier is "event"
parameter types is "input data"
externals for external data
'pre', expression is "precondition"
'post', expression as `` post condition ''
Associate with.
さらに、入力データに対する境界値および外部データによる境界値を明確にし、設計およびテストの条件を明確にするため、「入力データ・境界値」「外部データ・境界値」の項目を設ける。 Furthermore, in order to clarify the boundary value for the input data and the boundary value by the external data, and to clarify the design and test conditions, items of “input data / boundary value” and “external data / boundary value” are provided.
これはＶＤＭ−ＳＬの「型定義」に相当する。すなわち
type definition=identifier,'=','map to',type ＜写像型の場合＞
について
identifier は「入力データ」または「外部データ」
type は「境界値」
に対応付ける。
This corresponds to the “type definition” of VDM-SL. Ie
type definition = identifier, '=', 'map to', type <Mapping type>
about
identifier is "input data" or "external data"
type is "boundary value"
Associate with.
各イベントの「入力データ・境界値」「外部データ・境界値」により論理的にデータの真が成立する条件が明確になり、偽の条件となる例外系列のイベントを自動生成することができる。そしてテスト実行に際して真が成立する境界値または偽が成立する境界値でテストを行う。つまり「入力データ・境界値」及び「外部データ・境界値」のデータにより
ブラックボックステスト手法である境界値分析が適用可能となる。すなわち整数のdataが1,000≦data≦10,000の範囲が真であるとすると、真のテストはdata=1,000および data=10,000で行い、偽のテストはdata=999およびdata=10,001で行う。なお、「入力データ」「外部データ」の数が多くなるとテスト数が増加するため、実験計画法、All Pair 法、同値分割などのテスト数を削減する手法を導入しても良い。
Conditions for logically true data are clarified by "input data / boundary value" and "external data / boundary value" of each event, and an exception series event that is a false condition can be automatically generated. Then, the test is performed at the boundary value where true is true or false when the test is executed. That is, boundary value analysis, which is a black box test method, can be applied based on data of “input data / boundary value” and “external data / boundary value”. That is, if the integer data is in the range of 1,000 ≦ data ≦ 10,000, the true test is performed with data = 1,000 and data = 10,000, and the false test is performed with data = 999 and data = 10,001. Since the number of tests increases as the number of “input data” and “external data” increases, a method for reducing the number of tests such as an experimental design method, an All Pair method, and equivalence division may be introduced.
またユースケース記述による項目のイベントとイベントフローの各イベント間の前後関係を明確に記述するように「次のイベント」の項目を設ける。この「次のイベント」項目への設定により各イベント間の前後関係や分岐が明確になり、イベント網羅度をテスト戦略として設定することが可能になる。 In addition, an item “next event” is provided so as to clearly describe the context between the event of the item by the use case description and each event of the event flow. By setting this “next event” item, the context and branching between each event become clear, and the event coverage can be set as a test strategy.
このようにしてクライアント11の要求仕様記述を行うテスト担当者によって要求仕様記述がなされたデータをサーバ１にアップロードして要求仕様ファイル２に要求仕様記述がなされたデータを要求仕様として格納する。図１に示す要求仕様ファイル２において、要求仕様ファイル２のファイルの項目として下記がある。
In this way, the data in which the requirement specification description is made by the tester who performs the requirement specification description of the
仕様名・版数 201：仕様名は仕様記述の対象としている仕様名を格納する。仕様記述に対して一意に設定する。また版数は仕様名の版を識別する数値を格納する。
項目名202：ユースケースのイベントに対応した機能要求または非機能要求の項目名を格納する。
Specification name / version number 201: The specification name stores the specification name that is the target of the specification description. Set uniquely for the specification description. The version number stores a numerical value for identifying the version of the specification name.
Item name 202: Stores the item name of the function request or non-function request corresponding to the use case event.
概要203：機能要求または非機能要求の概要を格納する。
イベント204：当該項目が起動されるイベント名を格納する。
次のイベント205：当該項目の次に起動されるイベント番号を格納する。次のイベントがない場合は「終了」と記載する。またイベント番号の後ろに（ ）で「備考」を格納してもよい。
Summary 203: Stores a summary of function requests or non-function requests.
Event 204: Stores the event name that the item is activated.
Next event 205: Stores the event number activated next to the item. If there is no next event, “end” is described. “Remarks” may be stored in parentheses after the event number.
不変条件206：当該項目の各イベント内で変化しない条件。
初期条件207：当該項目が成立するために初期に必要とする条件。
イベントフロー208：当該項目内での一連のイベントの系列。基本系列、代替系列、例外系列からなる。
Invariant 206: A condition that does not change within each event of the item.
Initial condition 207: A condition that is initially required for the item to be satisfied.
Event flow 208: A series of events in the item. Consists of basic series, alternative series, and exceptional series.
基本系列209：当該項目内での基本的なイベントの系列。
イベント番号・イベント210：イベントを識別するための当該項目内での一意の番号と当該イベントの説明を格納する。
Basic series 209: A basic series of events in the item.
Event number / event 210: A unique number in the item for identifying the event and a description of the event are stored.
事前条件211：当該イベントが成立するために事前に必要とする条件。
入力データ・境界値212：当該イベントの入力データと当該入力データのデータ値がとる値の範囲を格納する。
Precondition 211: A condition required in advance for the event to be established.
Input data / boundary value 212: Stores the input data of the event and the range of values taken by the data value of the input data.
事後条件213：当該イベントの処理が終了した時にとる条件。
外部データ・境界値214：当該イベントの入力データ以外のデータと当該データのデータ値がとる値の範囲を格納する。
Post-condition 213: A condition to be taken when processing of the event is completed.
External data / boundary value 214: Stores data other than input data of the event and a range of values taken by the data value of the data.
次のイベント215：当該イベントの次に起動されるイベント番号を格納する。次のイベントがない場合は「終了」と記載する。またイベント番号の後ろに（ ）で「備考」を格納してもよい。 Next event 215: Stores the event number activated next to the event. If there is no next event, “end” is described. “Remarks” may be stored in parentheses after the event number.
代替系列216：当該項目内での基本系列に代替するイベントの系列。代替系列も基本系列と同様にイベント番号・イベント、事前条件、入力データ・境界値、事後条件、外部
データ・境界値、次のイベントのデータを持つ。
Substitution series 216: A series of events substituting for the basic series in the item. Similar to the basic series, the alternative series also has event numbers / events, preconditions, input data / boundary values, postconditions, external data / boundary values, and next event data.
例外系列217：当該項目内での異常が発生した場合など例外イベントの系列。例外系列も基本系列と同様にイベント番号・イベント、事前条件、入力データ・境界値、事後条件、外部データ・境界値、次のイベントのデータを持つ。 Exception series 217: A series of exception events such as when an abnormality occurs in the item. Similar to the basic series, the exception series has event numbers / events, preconditions, input data / boundary values, postconditions, external data / boundary values, and next event data.
図２は、本発明の実施形態に係る要求仕様ファイル２に格納された要求仕様記述がなされたデータ構造例を示す図である。事例は要求仕様項目名が“入金”の例であり、図示していないが要求仕様ファイル２にはこれ以外の要求仕様項目名、例えば“出金”などについても要求仕様記述がなされて格納されている。図２の右欄下部には後述する例外項目生成処理部７の処理フローにしたがって自動生成された例外項目イベントに対しクライアント11の要求仕様記述を行うテスト担当者が記述を追加した例についても示しているが、これについては後述する。
FIG. 2 is a diagram showing an example of a data structure in which the requirement specification description stored in the
例外項目イベントファイル４は、後述する例外項目生成処理部７の処理フローにしたがって自動生成された例外項目を格納するものである。例外項目イベントを自動生成して当該データを例外項目イベントファイル４に格納するために、クライアント11の例外項目イベント生成を行うテスト担当者は、サーバ１にログインし、サーバ１内において後述する例外項目生成処理部７の起動を指示する。図１０に示す例外項目生成処理部７は、要求仕様記述がなされた要求仕様ファイル２からデータの流れ(２)に示すように例外項目イベント生成に関するデータを抽出して、例外項目イベントを自動生成(これについては後述する)し、データの流れ(３)に示すように例外項目イベントファイル４に生成したデータを格納する。この際、自動生成した例外項目イベントを要求仕様ファイル２に追記する。そして自動生成され要求仕様ファイル２に追記した例外項目イベントに対しては、改めてクライアント11の要求仕様記述を行うテスト担当者が要求仕様ファイル２の要求仕様をダウンロードして「イベント」「事前条件」「入力データ・境界値」「事後条件」「外部データ・境界値」「次のイベント」を吟味のうえ、要求仕様に追記を行う。
The exception
図１に示す例外項目イベントファイル４において、例外項目イベントファイル４のファイルの項目として下記がある。すなわち、
仕様名・版数401：仕様名には対象としている仕様名を格納する。また版数には対象としている仕様名の版数を格納する。
In the exception
Specification name / version 401: The specification name stores the target specification name. The version number stores the version number of the target specification name.
項目名402：対象としているユースケースのイベントに対応した機能要求または非機能要求の項目名を格納する。
イベント番号・イベント403：例外項目生成処理部７の処理フローにしたがって生成される例外系列における例外項目のイベント番号とコメントを格納する。
Item name 402: Stores the item name of the function request or non-function request corresponding to the event of the target use case.
Event number / event 403: Stores the event number and comment of the exception item in the exception series generated according to the processing flow of the exception item
図４は、本発明の実施形態に係る例外項目イベントファイル４に格納された例外項目イベント記述がなされたデータ構造例を示す図である。同図においてはイベント番号３〜８に係る例外項目イベントが自動生成されたことを示す。ただし、同図においてファイルの項目「仕様名・版数」「項目名」は表記が省かれている。
FIG. 4 is a diagram showing an example of the data structure in which the exception item event description stored in the exception
テストシナリオパスファイル５は、後述するテストシナリオパス生成処理部８の処理フローにしたがって自動生成されたテストシナリオパスを格納するものである。テストシナリオパスを自動生成して当該データをテストシナリオパスファイル５に格納するために、クライアント11のテストシナリオパス生成を行うテスト担当者は、サーバ１にログインし、サーバ１内において後述するテストシナリオパス生成処理部８の起動を指示する。図１０に示すテストシナリオパス生成処理部８は、所定プログラムを動作させ図８Ａ〜Ｃに示すテストシナリオパス生成処理部８の処理フローにしたがってデータの流れ(４)に示すよ
うに要求仕様記述がなされた要求仕様ファイル２のイベントフローのイベント(系列)を図１１に示すテストシナリオパスの形をイメージして処理し、一方、テストシナリオパス生成を行うテスト担当者がテスト戦略として「全シナリオ」「全分岐」「イベント網羅」のいずれかをデータの流れ(１)、(４)で指定することにより、それに対応して自動的にテストシナリオパスをデータの流れ(５)に示すように生成する。このテストシナリオパスの生成に際しては、データの流れ(６)に示すようにテストシナリオパステーブル６にデータを一時保存しながらテストシナリオパスを自動生成する。
The test scenario path file 5 stores a test scenario path automatically generated according to a processing flow of a test scenario path
図１に示すテストシナリオパスファイル５において、テストシナリオパスファイル５のファイルの項目として下記がある。すなわち、
仕様名・版数501：仕様名には対象としている仕様名を格納する。また版数には対象としている仕様名の版数を格納する。
The test scenario path file 5 shown in FIG. 1 includes the following items as file items of the test scenario path file 5. That is,
Specification name / version number 501: The specification name stores the target specification name. The version number stores the version number of the target specification name.
項目名502：対象としているユースケースのイベントに対応した機能要求または非機能要求の項目名を格納する。
テスト戦略503：テスト戦略として指定された「全シナリオ」「全分岐」「イベント網羅」を格納する。
Item name 502: Stores the item name of the function request or non-function request corresponding to the event of the target use case.
Test strategy 503: Stores “all scenarios”, “all branches”, and “event coverage” specified as test strategies.
テストシナリオパス番号504：テストシナリオパス生成処理部８にて自動生成される当該項目内のテストシナリオパスを識別するための通番を格納する。
「全シナリオ」の場合はテストシナリオパステーブル６のNo．が格納される。
Test scenario path number 504: Stores a serial number for identifying a test scenario path in the item automatically generated by the test scenario path
In the case of “all scenarios”, the test scenario path table 6 No. Is stored.
「全分岐」の場合はテストシナリオパステーブル６の登録ステータス（全分岐）が１；登録済のものについての通番が格納される。
「イベント網羅」の場合はテストシナリオパステーブル６の登録ステータス（イベント網羅）が１；登録済のものについての通番が格納される。
In the case of “all branches”, the registration status (all branches) in the test scenario path table 6 is 1; the serial numbers of registered ones are stored.
In the case of “event coverage”, the registration status (event coverage) in the test scenario path table 6 is 1; the serial number of the registered one is stored.
イベント番号505：テストシナリオパス生成処理部８にて自動生成される当該項目内のテストシナリオパス内のイベント番号を格納する。すなわちテストシナリオパステーブル６の当該テストシナリオパス番号に対応するレコードに記載されているイベントのイベント番号が格納される。
Event number 505: Stores the event number in the test scenario path in the item automatically generated by the test scenario path
図５は、本発明の実施形態に係るテストシナリオパスファイル５に格納されたテストシナリオパスの記述がなされたデータ構造例を示す図である。同図においてはいずれのテスト戦略が指定されたかを特定せずに３つのテスト戦略、すなわち、「全シナリオ」「全分岐」「イベント網羅」についてのテストシナリオパスの「テストシナリオパス番号」(通番)、「イベント番号」(系列１・・等)を格納したときのデータ構造を示している。ただし、同図においてファイルの項目「仕様名・版数」「項目名」「テスト戦略」は表記が省かれている。
FIG. 5 is a diagram showing an example of a data structure in which a test scenario path stored in the test scenario path file 5 according to the embodiment of the present invention is described. In the figure, without specifying which test strategy is specified, the test scenario path “test scenario path number” (serial number) for three test strategies, namely “all scenarios”, “all branches”, and “event coverage” ), “Event number” (
テストシナリオパステーブル６は、後述するテストシナリオパス生成処理部８によって自動生成されるテストシナリオパスデータを一時保存するテーブルである。そしてテストシナリオパステーブル６には、
No. 601：テストシナリオパステーブル６のレコード（テストシナリオパス）に対応する通番を格納する。
The test scenario path table 6 is a table for temporarily storing test scenario path data automatically generated by a test scenario path
No. 601: The serial number corresponding to the record (test scenario path) in the test scenario path table 6 is stored.
登録ステータス（全分岐）602：全分岐のテストシナリオパスが１；登録済または0；未登録かのステータスを格納する。
登録ステータス（イベント網羅）603：イベント網羅のテストシナリオパスが１；登録済または0；未登録かのステータスを格納する。
Registration status (all branches) 602: Stores the status of whether the test scenario path of all branches is 1; registered or 0; not registered.
Registration status (event coverage) 603: Stores the status of whether the test scenario path for event coverage is 1; registered or 0; unregistered.
開始604：分岐とイベントの組が存在することを示す。
分岐605：イベントと組となって当該テストシナリオパスの要素となる分岐番号を格納する。
Start 604: Indicates that a branch and event pair exists.
Branch 605: Stores a branch number which is paired with an event and becomes an element of the test scenario path.
イベント606：分岐と組となって当該テストシナリオパスの要素となるイベント番号(系列１・・等)を格納する。
図１２は、本発明の実施形態に係るテストシナリオパステーブルのテーブル構造例を示す図である。同図に示されるテーブルには、テストシナリオパス生成処理部８によって自動生成されるテストシナリオパスが生成されるにしたがって左から、No.、登録ステータス（全分岐）のステータス、登録ステータス（イベント網羅）のステータス、開始、分岐、イベントの順で、テストシナリオパス(図１１参照)に合致するよう記述される。
Event 606: Stores an event number (
FIG. 12 is a diagram showing a table structure example of the test scenario path table according to the embodiment of the present invention. In the table shown in the figure, as the test scenario path automatically generated by the test scenario path
テスト仕様ファイル３は、後述するテスト仕様生成処理部９の処理フローにしたがって要求仕様ファイル２に格納されたテスト仕様生成に関するデータ項目およびテストシナリオパスファイル５に格納されたテストシナリオパスの中からテスト仕様生成に関するデータ項目に基づいて自動生成されるテスト仕様データと、クライアント11のテスト担当者入力の判定データとを格納するものである。テスト仕様を自動生成してデータをテスト仕様ファイル３に格納するために、クライアント11のテスト仕様生成を行うテスト担当者は、サーバ１にログインし、サーバ１内において後述するテスト仕様生成処理部９の起動を指示する。図１０に示すテスト仕様生成処理部９は、要求仕様記述がなされた要求仕様ファイル２からデータの流れ(７)に示すようにテスト仕様生成に関するデータ項目を抽出するとともに、テストシナリオパスファイル５からデータの流れ(８)に示すようにテストシナリオパスの中からテスト仕様生成に関するデータ項目を抽出して、テスト仕様を自動生成(これについては後述する)し、データの流れ(９)に示すようにテスト仕様ファイル３に生成したデータを格納する。この場合、本テスト仕様の項目は、IEEE standard 829-1983 for Software Test Documentationの標準を参考にし、テスト項目、テストシナリオ、テストケースの階層で構成する。
The
IEEE standard 829-1983 の
Test caseは「テスト項目」に相当し
Test procedureは「テストシナリオ」に相当する。
IEEE standard 829-1983
Test case is equivalent to "test item"
Test procedure corresponds to “test scenario”.
「テストケース」はIEEE standard 610の定義「入力値、実行事前条件、予想結果、そして実行事後条件の組み合わせで、特定のプログラムパスを用いることや指定された要件の遵守を検証することのような、特定の目的またはテスト条件のために開発されたもの」を指し、本発明では一連のTest procedureの個々の項目を「テストケース」と呼び、この単位で合否判定をすることでTest procedureのどの部分が不具合であるかを検出できるようにし、テストの精密さを増すようにしている。 “Test cases” are defined by IEEE standard 610, such as using specific program paths and verifying compliance with specified requirements, using a combination of input values, pre-execution conditions, expected results, and post-execution conditions. `` Developed for a specific purpose or test condition '', and in the present invention, individual items of a series of test procedures are called `` test cases '' and pass / fail judgments are made in this unit. It is possible to detect whether a part is defective and to increase the precision of the test.
図１に示すテスト仕様ファイル３において、テスト仕様ファイル３のファイルの項目として下記がある。すなわち、
仕様名・版数 301：仕様名にはテスト仕様名を格納する。また版数にはテスト仕様名の版を識別する番号を格納する。
In the
Specification name / version number 301: The test specification name is stored in the specification name. The version number stores a number identifying the version of the test specification name.
テスト項目302：要求仕様ファイル２の項目に対応したテスト項目名を格納する。
テスト概要303：要求仕様ファイル２の概要に対応したテストの概要を格納する。
共通テスト条件304：要求仕様ファイル２の「イベント」「不変条件」「初期条件」を共通テスト条件とし、テスト項目に対応した共通テスト条件として格納する。（ ）で「備考」を格納してもよい。
Test item 302: Stores a test item name corresponding to an item in the
Test summary 303: Stores a test summary corresponding to the summary of the
Common test condition 304: “Event”, “Invariant condition” and “Initial condition” in the
テストシナリオ305：テスト項目に対応したテストシナリオパス番号を格納する。テスト項目に対し、１つ以上のテストシナリオがある。
テストケース306：当該テスト項目でのイベントフローの各イベントに相当するイベント番号を格納する。（ ）で「備考」を格納してもよい。
Test scenario 305: Stores the test scenario pass number corresponding to the test item. There are one or more test scenarios for a test item.
Test case 306: Stores an event number corresponding to each event of the event flow in the test item. “Remarks” may be stored in ().
個別テスト条件307：要求仕様ファイル２の「事前条件」「入力データ・境界値」を個別テスト条件とし、当該テストケースのテストを実施するに当たっての個別テスト条件として格納する。（ ）で「備考」を格納してもよい。
Individual test condition 307: The “precondition” and “input data / boundary value” in the
テスト内容308：要求仕様ファイル２の「イベント番号・イベント」の「イベント」をテスト内容とし、当該テストケースの説明として格納する。（ ）で「備考」を格納してもよい。
Test content 308: “Event” of “event number / event” in the
テスト結果309：要求仕様ファイル２の「事後条件」「外部データ・境界値」をテスト結果とし、当該テストケースを実施した場合の判定条件として格納する。（ ）で「備考」を格納してもよい。
Test result 309: “Post-conditions” and “external data / boundary values” in the
判定310：項目のみとし、テスト担当者がテストを実施した結果とテスト結果を照合し、テスト担当者が「判定結果」「担当者名」「テスト年月日」を入力する。テストに使用したデータ値を（ ）で「備考」として格納してもよい。 Judgment 310: Only the item is selected, the test person collates the test result with the test result, and the test person inputs “judgment result”, “person in charge name”, and “test date”. The data value used for the test may be stored as “Remarks” in ().
図６は、本発明の実施形態に係るテスト仕様ファイル３に格納されたテスト仕様記述がなされたデータ構造例を示す図である。同図において「判定」項目への記述以外は自動生成により仕様が設定される。
FIG. 6 is a diagram showing an example of the data structure in which the test specification description stored in the
例外項目生成処理部７は、上述した図１のサーバ１内において実現される機能実現手段であって、サーバ１内においてＣＰＵへの起動に伴い記憶装置（ＲＯＭ，ＨＤＤ）に格納されているプログラムを読み込み、ＣＰＵがプログラム制御によって動作し、クライアント11とのデータのやりとりの外、サーバ１内の記憶装置（ＲＡＭ，ＨＤＤ）に展開されるファイルへのリード/ライト機能、当該ファイルに対するファイル編集機能などを用いて実現される。このようなコンピュータのハードウェア資源を用いて実現される諸機能は図解せずとも当業者に広く知られているものでここではその説明を省略する。クライアント11の例外項目イベント生成を行うテスト担当者はサーバ１に対して例外項目生成処理部７の起動を指示し、これを受けて図１０に示す例外項目生成処理部７は、所定プログラムを動作させ図７に示す例外項目生成処理部７の処理フローにしたがって要求仕様記述がなされた要求仕様ファイル２からデータの流れ(２)に示すように例外項目イベント生成に関するデータ項目、すなわち要求仕様ファイル２に記述されているイベントフローのイベント項目に設けられている入力データ・境界値または外部データ・境界値を抽出して、評価が偽となる例外項目を自動生成し、例外項目イベントとしてデータの流れ(３)に示すように例外項目イベントファイル４に生成したデータを格納する（図４参照）。この際、自動生成した例外項目イベントを要求仕様ファイル２に追記する（図３右欄下部参照）。そして自動生成され要求仕様ファイル２に追記した例外項目イベントに対しては、改めてクライアント11の要求仕様記述を行うテスト担当者が要求仕様ファイル２の要求仕様をダウンロードして例外項目イベント項目に対して記述を行う（図２右欄下部参照）。具体的な例外項目生成処理部７の処理フローを図７に示す。図７の処理フローについては後述する。
The exception item
テストシナリオパス生成処理部８は、上述した図１のサーバ１内において実現される機能実現手段であって、サーバ１内においてＣＰＵへの起動に伴い記憶装置（ＲＯＭ，ＨＤＤ）に格納されているプログラムを読み込み、ＣＰＵがプログラム制御によって動作し、
クライアント11とのデータのやりとりの外、サーバ１内の記憶装置（ＲＡＭ，ＨＤＤ）に展開されるファイルへのリード/ライト機能、当該ファイルに対するファイル編集機能などを用いて実現される。このようなコンピュータのハードウェア資源を用いて実現される諸機能は図解せずとも当業者に広く知られているものでここではその説明を省略する。クライアント11のテストシナリオパス生成を行うテスト担当者は、サーバ１に対してテストシナリオパス生成処理部８の起動を指示し、これを受けて図１０に示すテストシナリオパス生成処理部８は、所定プログラムを動作させ図８Ａ〜Ｃに示すテストシナリオパス生成処理部８の処理フローにしたがってデータの流れ(４)に示すように要求仕様記述がなされた要求仕様ファイル２のイベントフローのイベント(系列)を図１１に示すテストシナリオパスの形をイメージして処理し、一方、テストシナリオパス生成を行うテスト担当者がテスト戦略として「全シナリオ」「全分岐」「イベント網羅」のいずれかをデータの流れ(１)、(４)で指定することにより、それに対応してデータの流れ(５)に示すように自動的にテストシナリオパスを生成する。このテストシナリオパスの生成に際しては、データの流れ(６)に示すようにテストシナリオパステーブル６にデータを一時保存しながらテストシナリオパスを自動生成する。
The test scenario path
In addition to the exchange of data with the
なお、テストシナリオパス生成を行うテスト担当者が指定するテスト戦略が、
・全シナリオの場合は、分岐が３分岐以上となるときは分岐を分離して全てのパスを通るテストシナリオパスを生成する。
Note that the test strategy specified by the tester who generates the test scenario path is
In the case of all scenarios, when the number of branches is three or more, separate the branches and generate a test scenario path that passes through all paths.
・全分岐の場合は、分岐が３分岐以上となるときも１つの分岐として全てのパスを通るテストシナリオパスを生成する。
・イベント網羅は、全てのイベントを通る最少のパスをテストシナリオパスとして生成する。
In the case of all branches, a test scenario path that passes through all paths is generated as one branch even when there are three or more branches.
-Event coverage generates the minimum path through all events as a test scenario path.
このようにテスト戦略を指定することによりテストケース数の増減が可能となる。
図８Ａ〜Ｃは、上記テストシナリオパス生成処理部８の処理フローを示す図である。図８Ａ〜Ｃの処理フローについては後述する。
By specifying the test strategy in this way, the number of test cases can be increased or decreased.
8A to 8C are diagrams illustrating a processing flow of the test scenario path
テスト仕様生成処理部９は、上述した図１のサーバ１内において実現される機能実現手段であって、サーバ１内においてＣＰＵへの起動に伴い記憶装置（ＲＯＭ，ＨＤＤ）に格納されているプログラムを読み込み、ＣＰＵがプログラム制御によって動作し、クライアント11とのデータのやりとりの外、サーバ１内の記憶装置（ＲＡＭ，ＨＤＤ）に展開されるファイルへのリード/ライト機能、当該ファイルに対するファイル編集機能などを用いて実現される。このようなコンピュータのハードウェア資源を用いて実現される諸機能は図解せずとも当業者に広く知られているものでここではその説明を省略する。クライアント11のテスト仕様生成を行うテスト担当者は、サーバ１に対してテスト仕様生成処理部９の起動を指示し、これを受けて図１０に示すテスト仕様生成処理部９は、所定プログラムを動作させ図９に示すテスト仕様生成処理部９の処理フローにしたがって要求仕様記述がなされた要求仕様ファイル２からデータの流れ(７)に示すようにテスト仕様生成に関するデータ項目を抽出するとともに、テストシナリオパスファイル５からデータの流れ(８)に示すようにテストシナリオパスの中からテスト仕様生成に関するデータ項目を抽出して、「判定」項目以外のデータ項目についてテスト仕様を自動生成し、データの流れ(９)に示すようにテスト仕様ファイル３に生成したデータを格納する。具体的なテスト仕様生成処理部９の処理フローを図９に示す。図９の処理フローについては後述する。
The test specification
図１０は、図１に示したサーバ１内の各種ファイル、各種生成処理部およびクライアント11を活用して本発明テスト仕様自動生成を実現するための相互の結合関係およびデータの流れを示す相関図である。図１０に示したそれぞれのブロックは、図１に示したサーバ１内において機能を実現するための機能ブロックであり、相互の結合関係およびデータの
流れを図示番号とともに矢視線で示す。なお処理内容の詳細については後述する。
FIG. 10 is a correlation diagram showing the mutual connection relationship and the data flow for realizing the automatic generation of test specifications of the present invention by utilizing the various files, various generation processing units and the
相互の結合関係およびデータの流れについて図１０を用いて簡単に説明する。クライアントサーバシステムにおいてクライアント11がサーバ１にログインする。次いでサーバ１に対してどのような生成処理を成そうとするのかの指示をクライアント11から出す。なお図１０ではクライアント11を代表して一つだけ表示しているもので、図１に示すようにクライアント11はサーバ１に対して複数存在する。いま、要求仕様を記述するための指示が出されたとすると、これに応じて要求仕様の記述に係るデータのダウンロードが行われてクライアント11の画面に表示される。また要求仕様ファイル２の要求仕様であって例外項目イベントが追記された要求仕様がダウンロードされる。そしてデータの流れ(１)に示すように要求仕様の記述画面で必要な項目への記述を行って記述がなされた要求仕様をサーバ１にアップロードする。
The mutual coupling relationship and data flow will be briefly described with reference to FIG. The
例外項目生成処理部７は、クライアント11からの指示により起動し、図７に示す処理フローにしたがって要求仕様記述がなされた要求仕様ファイル２からデータの流れ(２)に示すように例外項目イベント生成に関するデータを抽出して、例外項目イベントを自動生成し、データの流れ(３)に示すように例外項目イベントファイル４に生成したデータを格納する。この際、自動生成した例外項目イベントを要求仕様ファイル２に追記する。
The exception item
テストシナリオパス生成処理部８は、クライアント11からの指示により起動し、図８Ａ〜Ｃに示す処理フローにしたがってデータの流れ(４)に示すように要求仕様記述がなされた要求仕様ファイル２のイベントフローのイベント(系列)を図１１に示すテストシナリオパスの形をイメージして処理し、一方、テスト戦略として「全シナリオ」「全分岐」「イベント網羅」のいずれか一つをクライアント11からデータの流れ(１)、(４)で指定することにより、それに対応して自動的にテストシナリオパスを生成し、データの流れ(５)に示すようにテストシナリオパスファイル５に生成したデータを格納する。このテストシナリオパスの生成に際しては、データの流れ(６)に示すようにテストシナリオパステーブル６にデータを一時保存しながらテストシナリオパスを自動生成する。
The test scenario path
テスト仕様生成処理部９は、クライアント11からの指示により起動し、図９に示す処理フローにしたがって要求仕様記述がなされた要求仕様ファイル２からデータの流れ(７)に示すようにテスト仕様生成に関するデータ項目を抽出するとともに、テストシナリオパスファイル５からデータの流れ(８)に示すようにテストシナリオパスの中からテスト仕様生成に関するデータ項目を抽出して、「判定」項目以外のデータ項目についてテスト仕様を自動生成し、データの流れ(９)に示すようにテスト仕様ファイル３に生成したデータを格納する。
The test specification
テスト仕様ファイル３に格納されたテスト仕様に対して、クライアント11はデータの流れ(10)に示すようにテスト仕様をダウンロードしてテスト仕様の抜け、漏れ、曖昧さの有無を検出し、さらにこのテスト仕様の生成状況から要求仕様の抜け、漏れ、曖昧さをなくし、手戻り作業を削減し、品質の高いソフトウェアを開発する。
For the test specifications stored in the
図７は、本発明の実施形態に係る例外項目生成処理部７の例外項目生成処理フローを示す図である。同図において、ステップはSと略記する。
S11 要求仕様ファイル２の当該項目名のイベントフローから各イベントのイベント番号・イベント、入力データ・境界値、外部データ・境界値を読み込む。
FIG. 7 is a diagram showing an exception item generation processing flow of the exception item
S11 Read the event number / event, input data / boundary value, external data / boundary value of each event from the event flow of the corresponding item name in the
S12 入力データ・境界値に境界値データなしかを確認する。
S13 境界値データがある場合は、ステップS14で例外項目イベントファイル４に「（イベント番号）で入力データ・境界値を満たさない場合」とのイベント書き込みを行う。ま
た境界値データがない場合は、ステップS15の処理へバイパスする。
S12 Check input data / boundary values for boundary value data.
S13 If there is boundary value data, an event is written in the exception
S15 外部データ・境界値に境界値データなしかを確認する。
S16 境界値データがある場合は、ステップS17で例外項目イベントファイル４に「（イベント番号）で外部データ・境界値を満たさない場合」とのイベント書き込みを行う。また境界値データがない場合は、ステップS18の処理へバイパスする。
S15 Check if there is no boundary value data in the external data / boundary value.
If there is S16 boundary value data, an event is written in the exception
S18 全イベントを処理したか確認し、未処理イベントがある場合はステップS12の処理へ戻り、全イベントを処理した場合は、ステップS19の処理を行う。
S19 例外項目イベントファイル４にイベント番号書き込みを行う。例えば、
例 「例外系列 Ｎ」
この場合、Ｎは既にある例外系列の番号をＫとするとＮ＝Ｋ+１からインクリメントする。
S18 Check whether all events have been processed. If there are unprocessed events, the process returns to step S12. If all events have been processed, the process of step S19 is performed.
S19 Write the event number to the exception
Example “Exception series N”
In this case, N is incremented from N = K + 1, where K is the number of an existing exception series.
また要求仕様ファイル２に例外項目イベントファイル４の内容を追記する。
当該処理の後、要求仕様記述を行うテスト担当者により「イベント」「事前条件」「入力データ・境界値」「事後条件」「外部データ・境界値」「次のイベント」が吟味され、要求仕様ファイル２が編集され、生成された例外項目イベントへの仕様記述が行われる。
Further, the contents of the exception
After the processing, the tester who describes the required specifications will review the "event", "precondition", "input data / boundary value", "postcondition", "external data / boundary value", and "next event" The
図８Ａ〜図８Ｃは、本発明の実施形態に係るテストシナリオパス生成処理部８のテストシナリオパス生成処理フローを示す図である。そして図１１は、本発明の実施形態に係るテストシナリオパスの生成の様子を示す図であり、テストシナリオパス生成処理部８が要求仕様ファイル２のイベントフローのイベント(系列)をこのテストシナリオパスの形をイメージして処理する。
8A to 8C are diagrams showing a test scenario path generation processing flow of the test scenario path
図８Ａは、本発明の実施形態に係るテストシナリオパス生成処理部８の全シナリオテストシナリオパス生成処理フローを示す図である。当該処理は図８Ｂ、図８Ｃの処理前にも実行する。図８Ａ、図８Ｂ、図８Ｃの処理でテストシナリオパステーブル６に一時保存されやがてテストシナリオパスファイル５に格納されるテストシナリオパスを生成する。図８Ａにおいて、
S21 要求仕様ファイル２のイベントフローを参照し、「次のイベント」のイベント番号をテストシナリオパステーブル６のイベントへ記入する。当該イベントの「次のイベント」のイベント番号をテストシナリオパステーブル６での当該レコードの次のイベントの項目へ記入する。「終了」を検出した場合は終了を当該レコードの次ぎのイベントに記入し、次は前回の最終イベントから「次のイベント」でテストシナリオパステーブル６に記入しなかったイベントをテストシナリオパステーブル６の次ぎのレコードから記入を始める。それ以前のレコードの項目は前のレコードと同じイベント番号を記載する。「次のイベント」が全てテストシナリオパステーブル６に記載されるまで続ける。
FIG. 8A is a diagram showing an all-scenario test scenario path generation processing flow of the test scenario path
S21 Referring to the event flow in the
S22 テストシナリオパステーブル６のレコードをイベントのイベント番号の昇順に左端⇒右端の順にソートする。ソートしたらテストシナリオパステーブル６の次ぎのレコードについて同様の処理を行い、全レコードが終了するまで行う。 S22 The records of the test scenario path table 6 are sorted in the order of the left end ⇒ right end in ascending order of event numbers of events. After sorting, the same processing is performed for the next record in the test scenario path table 6 until all records are completed.
S23 テストシナリオパステーブル６の分岐に分岐番号を設定する。当該イベントのイベント番号と前のイベントのイベント番号の組み合わせが初めての場合は分岐番号を変更して一意にする
図８Ｂは、本発明の実施形態に係るテストシナリオパス生成処理部８の全分岐テストシナリオパス生成処理フローを示す図である。図８Ｂにおいて、
S31 テストシナリオパステーブル６の全レコードの中で、登録ステータス（全分岐）が0；未登録のレコ−ドを検索する。
S23 Set a branch number for the branch in the test scenario path table 6. When the combination of the event number of the event and the event number of the previous event is the first time, the branch number is changed to make it unique. FIG. 8B shows all branch tests of the test scenario path
S31 The registration status (all branches) is 0 among all the records in the test scenario path table 6; a record that is not registered is searched.
S32 存在する場合は、ステップS33の処理を行い、存在しない場合は当該処理を終了する。
S33 イベントに「終了」が格納されている列について列番号が最小のレコードを検索する。当該レコードのイベントのイベント番号または分岐番号の中で、登録ステータス（全分岐）が1；登録済のレコードに含まれていないか確認する。
S32 If present, the process of step S33 is performed, and if not present, the process ends.
S33 Searches for the record with the smallest column number for the column where “End” is stored in the event. Among the event number or branch number of the event of the record concerned, the registration status (all branches) is 1; check whether it is not included in the registered record.
S34 ステップS33の処理で、存在する場合は当該レコードの登録ステータス（全分岐）に1；登録済を記入する。
S35 テストシナリオパステーブル６に次のレコードがある場合は、ステップS33の処理を行い、次のレコードがない場合は当該処理を終了する。
S34 In step S33, if it exists, enter 1; registered in the registration status (all branches) of the record.
S35 If there is a next record in the test scenario path table 6, the process of step S33 is performed. If there is no next record, the process is terminated.
図８Ｃは、本発明の実施形態に係るテストシナリオパス生成処理部８のイベント網羅テストシナリオパス生成処理フローを示す図である。図８Ｃにおいて、
S41 テストシナリオパステーブル６の全レコードの中で、登録ステータス（イベント網羅）が0；未登録のレコ−ドを検索する。
FIG. 8C is a diagram showing an event coverage test scenario path generation processing flow of the test scenario path
S41 Among all the records in the test scenario path table 6, the registration status (event coverage) is 0; unregistered records are searched.
S42 存在する場合はステップS43の処理を行い、存在しない場合は当該処理を終了する。
S43 イベントに「終了」が格納されている列について列番号が最大のレコードを検索する。当該レコードのイベントのイベント番号または分岐番号の中で、登録ステータス（イベント網羅）が1；登録済のレコードに含まれていないか確認する。
S42 If it exists, the process of step S43 is performed. If it does not exist, the process ends.
S43 The record having the largest column number is searched for the column in which “End” is stored in the event. Check whether the registration status (event coverage) is 1 in the event number or branch number of the event of the record; it is not included in the registered record.
S44 ステップS43の処理、存在する場合は、当該レコードの登録ステータス（イベント網羅）に1；登録済を記入する。
S45 テストシナリオパステーブル６に次のレコードがある場合は、ステップS43の処理を行い、次のレコードがない場合は当該処理を終了する。
S44 Processing in step S43, if present, enter 1; registered in the registration status (event coverage) of the record.
S45 If there is a next record in the test scenario path table 6, the process of step S43 is performed. If there is no next record, the process is terminated.
図９は、本発明の実施形態に係るテスト仕様生成処理部９のテスト仕様生成処理フローを示す図である。図９において、
S51 要求仕様ファイル２の当該項目名のデータを読み込むとともに当該項目名のテストシナリオパスファイル５を読み込む。
FIG. 9 is a diagram showing a test specification generation processing flow of the test specification
S51 Read the data of the item name in the
S52 テスト仕様ファイル３に要求仕様ファイル２のデータを下記の変換をして書き込む。すなわち、
仕様名 版数⇒仕様名 版数
項目名⇒テスト項目
概要⇒テスト概要
イベント＆不変条件＆初期条件⇒共通テスト条件
S53 テスト仕様ファイル３に当該項目名のテストシナリオパスファイル５のテストシナリオパス番号を書き込む。
S52 Write the data of the
Specification name Version number ⇒ Specification name Version number Item name ⇒ Test item Overview ⇒ Test overview Event & invariant condition & initial condition ⇒ Common test condition
S53 Write the test scenario path number of the test scenario path file 5 of the item name in the
イベント番号はテストケース番号としてテストシナリオパスのイベント内の通番を書き込む。
S54 テスト仕様ファイル３に要求仕様ファイル２のイベントフローの系列(イベント)データを下記の変換をして書き込む。すなわち、
事前条件＆入力データ・境界値⇒個別テスト条件
(イベント番号・イベントの)イベント⇒テスト内容
事後条件＆外部データ・境界値⇒テスト結果
判定の項目名を書き込む。
As the event number, the serial number in the event of the test scenario path is written as the test case number.
S54 Write the event flow series (event) data of the
Preconditions & input data / boundary values ⇒ Individual test conditions
Event (event number / event) ⇒ test contents Post-condition & external data / boundary value ⇒ test result Write the judgment item name.
S55 当該テストシナリオパス番号の全イベント処理が完了でステップS56へ、未完了の場合はステップS54の処理へ戻る。
S56 当該項目名の全テストシナリオパス処理が完了で終了し、未完了の場合はステップS54の処理へ戻る。
S55 If all event processing of the test scenario pass number is completed, the process returns to step S56. If not completed, the process returns to step S54.
S56: When all the test scenario path processes for the item name are completed, the process returns to step S54.
１ サーバ
２ 要求仕様ファイル
３ テスト仕様ファイル
４ 例外項目イベントファイル
５ テストシナリオパスファイル
６ テストシナリオパステーブル
７ 例外項目生成処理部
８ テストシナリオパス生成処理部
９ テスト仕様生成処理部
１０ ネットワーク
１１ クライアント
1
Claims (6)
テストシナリオパス生成処理手段の処理によって生成されるテストシナリオパスの処理過程中のデータを一時保存するテストシナリオパステーブルと、
前記テストシナリオパス生成処理手段の処理によって自動生成されたテストシナリオパスを格納するテストシナリオパスファイルと、
テスト仕様生成処理手段の処理によって自動生成されたテスト仕様データとテスト担当者入力の判定データとを格納するテスト仕様ファイルと、を有し、
テスト担当者指示により起動され、前記要求仕様ファイルに格納された要求仕様の中からテストシナリオパス生成に関するデータ項目を抽出しかつテスト担当者によって指定されたテスト戦略に対応するテストシナリオパスを、前記テストシナリオパステーブルに一時保存された処理過程中のデータを用いてテストシナリオパスを自動的に生成するテストシナリオパス生成処理手段と、
テスト担当者指示により起動され、前記要求仕様ファイルに格納された要求仕様の中からテスト仕様生成に関するデータ項目を抽出するとともに、前記テストシナリオパスファイルに格納されたテストシナリオパスの中からテスト仕様生成に関するデータ項目を抽出して、判定項目を除くテスト仕様を自動的に生成するテスト仕様生成処理手段と、
を備えていることを特徴とするテスト仕様自動生成方式。 A requirement specification file storing requirement specifications in which requirement specifications are described for data items relating to test specification generation and data items relating to test scenario path generation;
A test scenario path table that temporarily stores data during the process of the test scenario path generated by the process of the test scenario path generation processing means;
A test scenario path file for storing a test scenario path automatically generated by the processing of the test scenario path generation processing means;
A test specification file for storing test specification data automatically generated by the processing of the test specification generation processing means and determination data input by a tester;
A test scenario path that is activated by a tester instruction, extracts data items related to test scenario path generation from the requirement specifications stored in the requirement specification file, and corresponds to the test strategy specified by the tester, A test scenario path generation processing means for automatically generating a test scenario path using data during the process temporarily stored in the test scenario path table;
Data items related to test specification generation are extracted from the requirement specifications stored in the requirement specification file and started by the tester's instructions, and the test specification generation from the test scenario path stored in the test scenario path file Test specification generation processing means for automatically extracting test specifications excluding judgment items by extracting data items related to
A test specification automatic generation method characterized by comprising:
テスト担当者指示により起動され、前記要求仕様ファイルに格納された要求仕様の中から例外項目イベント生成に関するデータ項目として前記入力データに対する境界値および外部データによる境界値を抽出して、例外項目イベントを自動的に生成し前記例外項目イベントファイルに格納するとともに自動生成された前記例外項目イベントを前記要求仕様ファイルに追記する例外項目生成処理手段と、を有し、
前記例外項目イベントが前記要求仕様ファイルに追記された場合には、追記された前記要求仕様ファイルにアクセスして前記例外項目イベントに対して前記テストシナリオパス生成に関するデータ項目および前記テスト仕様生成に関するデータ項目について要求仕様記述の追加を行うことを特徴とする請求項２記載のテスト仕様自動生成方式。 An exception item event file that stores exception item events automatically generated by the processing of the exception item generation processing means;
Triggered by the person in charge of the test, the boundary value for the input data and the boundary value by external data are extracted from the requirement specifications stored in the requirement specification file as data items for exception item event generation. An exception item generation processing means for automatically generating and storing the exception item event file in the exception specification event file and adding the exception item event automatically generated to the requirement specification file,
When the exception item event is added to the requirement specification file, the data item relating to the test scenario path generation and the data relating to the test specification generation for the exception item event are accessed by accessing the requirement specification file added. 3. The test specification automatic generation method according to claim 2, wherein a requirement specification description is added to an item.
前記要求仕様ファイルに格納された前記要求仕様の中から前記テスト仕様生成に関するデータ項目を抽出し該データ項目を前記テスト仕様のデータ項目に変換し該データ項目に仕様を設定する第１のデータ項目変換設定手段と、
前記テストシナリオパスファイルに格納されたテストシナリオパスの中からテスト仕様
生成に関するデータ項目を抽出し該データ項目を前記テスト仕様のデータ項目に変換し該データ項目に仕様を設定する第２のデータ項目変換設定手段と、
を有することを特徴とする請求項１記載のテスト仕様自動生成方式。 The test specification generation processing means includes:
A first data item that extracts a data item related to test specification generation from the requirement specification stored in the requirement specification file, converts the data item into a data item of the test specification, and sets the specification in the data item Conversion setting means;
A second data item for extracting a data item relating to test specification generation from the test scenario path stored in the test scenario path file, converting the data item into a data item of the test specification, and setting the specification in the data item Conversion setting means;
The test specification automatic generation system according to claim 1, further comprising:
前記要求仕様ファイルに格納された前記要求仕様の中から前記テストシナリオパス生成に関するデータ項目を抽出しかつ前記テスト戦略として全シナリオが指定されたことに伴い全シナリオに対応するテストシナリオパスを生成する全シナリオテストシナリオパス生成手段と、
前記要求仕様ファイルに格納された前記要求仕様の中から前記テストシナリオパス生成に関するデータ項目を抽出しかつ前記テスト戦略として全分岐が指定されたことに伴い全分岐に対応するテストシナリオパスを生成する全分岐テストシナリオパス生成手段と、
前記要求仕様ファイルに格納された前記要求仕様の中から前記テストシナリオパス生成に関するデータ項目を抽出しかつ前記テスト戦略としてイベント網羅が指定されたことに伴いイベント網羅に対応するテストシナリオパスを生成するイベント網羅テストシナリオパス生成手段と、
を有することを特徴とする請求項５記載のテスト仕様自動生成方式。 The test scenario path generation processing means includes:
Data items relating to the test scenario path generation are extracted from the requirement specifications stored in the requirement specification file, and test scenarios paths corresponding to all scenarios are generated when all scenarios are specified as the test strategy. All scenario test scenario path generation means,
Data items relating to the test scenario path generation are extracted from the requirement specifications stored in the requirement specification file, and a test scenario path corresponding to all branches is generated when all branches are designated as the test strategy. All branch test scenario path generation means,
A data item related to the test scenario path generation is extracted from the requirement specifications stored in the requirement specification file, and a test scenario path corresponding to event coverage is generated when event coverage is specified as the test strategy. Event coverage test scenario path generation means,
The test specification automatic generation system according to claim 5, further comprising:
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007139753A JP2008293382A (en) | 2007-05-25 | 2007-05-25 | Automatic test specification generation system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007139753A JP2008293382A (en) | 2007-05-25 | 2007-05-25 | Automatic test specification generation system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2008293382A true JP2008293382A (en) | 2008-12-04 |
Family
ID=40168021
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007139753A Withdrawn JP2008293382A (en) | 2007-05-25 | 2007-05-25 | Automatic test specification generation system |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2008293382A (en) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011159202A (en) * | 2010-02-03 | 2011-08-18 | Nippon Telegr & Teleph Corp <Ntt> | Test item generating method, device, and program |
| JP2012118873A (en) * | 2010-12-02 | 2012-06-21 | Fujitsu Ltd | Data production method, program and apparatus |
| WO2012128120A1 (en) * | 2011-03-18 | 2012-09-27 | 独立行政法人産業技術総合研究所 | Test specification generator, test specification generation method, and program |
| CN103473148A (en) * | 2012-06-08 | 2013-12-25 | 中兴通讯股份有限公司 | Method and device for restoring testing environment |
| JP2015204065A (en) * | 2014-04-16 | 2015-11-16 | 株式会社日立製作所 | Test case generation device and test case generation method |
-
2007
- 2007-05-25 JP JP2007139753A patent/JP2008293382A/en not_active Withdrawn
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011159202A (en) * | 2010-02-03 | 2011-08-18 | Nippon Telegr & Teleph Corp <Ntt> | Test item generating method, device, and program |
| JP2012118873A (en) * | 2010-12-02 | 2012-06-21 | Fujitsu Ltd | Data production method, program and apparatus |
| WO2012128120A1 (en) * | 2011-03-18 | 2012-09-27 | 独立行政法人産業技術総合研究所 | Test specification generator, test specification generation method, and program |
| CN103473148A (en) * | 2012-06-08 | 2013-12-25 | 中兴通讯股份有限公司 | Method and device for restoring testing environment |
| CN103473148B (en) * | 2012-06-08 | 2017-10-10 | 中兴通讯股份有限公司 | One kind recovers test environment method and device |
| JP2015204065A (en) * | 2014-04-16 | 2015-11-16 | 株式会社日立製作所 | Test case generation device and test case generation method |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Gallaba et al. | Use and misuse of continuous integration features: An empirical study of projects that (mis) use Travis CI | |
| US6941546B2 (en) | Method and apparatus for testing a software component using an abstraction matrix | |
| US6986125B2 (en) | Method and apparatus for testing and evaluating a software component using an abstraction matrix | |
| JP5295269B2 (en) | Method for generating component model-based virtual software platform, method for verifying software platform architecture using the same, and apparatus therefor | |
| US9342273B1 (en) | Automatic communications graphing for a source application | |
| US8074204B2 (en) | Test automation for business applications | |
| Mesbah et al. | Invariant-based automatic testing of modern web applications | |
| US8001532B1 (en) | System and method for generating source code-based test cases | |
| US8839201B2 (en) | Capturing test data associated with error conditions in software item testing | |
| US10067858B2 (en) | Cloud-based software testing | |
| US9292416B2 (en) | Software development kit testing | |
| US9588871B1 (en) | Method and system for dynamic business rule extraction | |
| US20140181793A1 (en) | Method of automatically testing different software applications for defects | |
| US9684587B2 (en) | Test creation with execution | |
| US20020091968A1 (en) | Object-oriented data driven software GUI automated test harness | |
| US20130305212A1 (en) | Dry-run design time environment | |
| US8949794B2 (en) | Binding a software item to a plain english control name | |
| CN110928772A (en) | Test method and device | |
| WO2012014284A1 (en) | Method of generating test scenario, test scenario generating system and test scenario generating program | |
| US20120266131A1 (en) | Automatic program generation device, method, and computer program | |
| US20050137844A1 (en) | Method for generating a language-independent regression test script | |
| US20140047276A1 (en) | Model-based testing of a graphical user interface | |
| JP2008293382A (en) | Automatic test specification generation system | |
| US10387294B2 (en) | Altering a test | |
| US20020133753A1 (en) | Component/Web services Tracking |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A300 | Withdrawal of application because of no request for examination |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20100803 |