JP6568017B2 - テスト支援装置、および、テスト支援方法 - Google Patents

テスト支援装置、および、テスト支援方法 Download PDF

Info

Publication number
JP6568017B2
JP6568017B2 JP2016113577A JP2016113577A JP6568017B2 JP 6568017 B2 JP6568017 B2 JP 6568017B2 JP 2016113577 A JP2016113577 A JP 2016113577A JP 2016113577 A JP2016113577 A JP 2016113577A JP 6568017 B2 JP6568017 B2 JP 6568017B2
Authority
JP
Japan
Prior art keywords
parameter
information
test
test case
analyzed
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.)
Active
Application number
JP2016113577A
Other languages
English (en)
Other versions
JP2017220008A (ja
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.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
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 Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2016113577A priority Critical patent/JP6568017B2/ja
Publication of JP2017220008A publication Critical patent/JP2017220008A/ja
Application granted granted Critical
Publication of JP6568017B2 publication Critical patent/JP6568017B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Debugging And Monitoring (AREA)

Description

本発明は、テスト支援装置、および、テスト支援方法に係り、特に、外部仕様からテストケースを生成して、ソフトウェアのテストにおける労力を軽減するのに好適なテスト支援装置、および、テスト支援方法に関する。
ソフトウェア開発において、開発したソフトウェアが期待通り動作するかを確認するためのテストは、ソフトウェアの品質を確保するために重要な意義を有する。テストを実施する際には、ソフトウェアの設計段階に作成された仕様書を分析し、テストを実施するための具体的な入力データや対応する期待結果を作成するテスト設計をおこなうのが一般的である。このようなテスト設計においては、テスト設計における設計仕様を分析し、関連する入力情報を漏れなく抽出して、テストをする際のテストケースを生成することが必要である。
そこで、例えば、特許文献1には、テストケースを生成する際に、設計仕様書とテスト仕様書に記載する項目と、設計仕様書とテスト仕様書の項目間の対応関係を予め定めておくことにより、テスト設計段階における設計仕様書からの抽出漏れを防ぐ方法が開示されている。
また、特許文献2にはソフトウェアの仕様から、仕様上出力する値を網羅する値を出力するため、仕様上出力する値が、入力の結果、出力が期待される期待出力値に含まれるか否かを確認して、仕様上出力する値とそれに対応するテスト入力値をテストケースとして生成する技術が開示されている。
特開2013−77173号公報 特開2014−186407号公報
テスト実施時には、ソフトウェア開発者は、一般に、テスト対象となるソフトウェアそのもの、あるいは、構成モジュール、関数にかかわる入力情報(パラメータ)を分析し、テストデータを作成するが、テスト対象が取り得る全てのテストデータの組合せをテストすることは困難である。そのため、各パラメータが取り得るパターンの分析や、パラメータ間の関係性を考慮した上で、適切なクラス分けをおこなう必要がある。また、設計仕様書には、必ずしもテスト実施時に必要な全ての情報が、記述されるとは限らない。しかしながら、特許文献1や特許文献2では、テスト設計段階での追加入力の必要性にどのような対処するか、あるいは、どのようにパラメータの分析をおこなうかについては、開示されていない。
本発明は、上記問題点を解決するためになされたもので、設計仕様書を分析し、テスト設計段階で必要となる情報を抽出するとともに設計仕様書から得られるテスト対象の入力情報から、入力パターンを分析して、テスト実行に必要なテストケースを生成して、テスト実施者の労力を軽減することを可能とするテスト支援装置、および、テスト支援方法を提供することにある。
上記問題点を解決するために、本発明に係るテスト支援装置は、CPUと、記憶部と、表示部を有し、記憶部に格納されたプログラムを実行することにより機能を実現するテスト支援装置であって、記憶部は、外部仕様と、分析済みパラメータ情報と、テストケース生成情報と、テストケースを記憶し、外部仕様と分析済みパラメータ情報とは、テスト対象のソフトウェアプログラムで記述されるパラメータのパラメータ情報と、そのパラメータのパラメータ間の関係を表す制約条件とを保持し、外部仕様と分析済みパラメータ情報のパラメータ情報は、そのパラメータの型情報と、パラメータ名が取り得るパターン情報とを含み、テストケース生成情報は、テスト対象のソフトウェアプログラムで記述されるパラメータのパラメータ情報と、そのパラメータのパラメータ間の関係を表す制約条件とを保持し、テストケース生成情報のパラメータ情報は、そのパラメータの型情報と、パラメータ名が取り得る候補値とを含み、テストケースは、テスト対象のソフトウェアプログラムで記述されるパラメータのパラメータ値を定めた組合せを、一つ以上保持する。そして、外部仕様のパラメータ情報のパラメータの型情報、パターン情報、制約条件から、パラメータのクラス分割をおこない、分析済みパラメータ情報を生成し、分析済みパラメータ情報のパラメータ情報のパラメータの型情報、パターン情報、制約条件から、パラメータのクラス分割をおこない、テストケース生成情報を生成し、テストケース生成情報のパラメータ情報のパラメータの型情報と、制約条件と、パラメータ情報の候補値とから、パラメータ値を定めた組合せを生成し、テストケースを生成する。
本発明によれば、設計仕様書を分析し、テスト設計段階で必要となる情報を抽出するとともに設計仕様書から得られるテスト対象の入力情報から、入力パターンを分析して、テスト実行に必要なテストケースを生成して、テスト実施者の労力を軽減することを可能とするテスト支援装置、および、テスト支援方法を提供することができる。
テスト支援装置の機能構成とデータフローを示す図である。 テスト支援装置のハードウェア構成図である。 被テストプログラムのモデルを示す模式図である。 テスト支援装置100による外部仕様の入力からテストケース生成までの処理を示すフローチャートである。 外部仕様の一例を示す図である。 分析済みパラメータ情報の一例を示す図である。 分析済みパラメータ情報の補完入力画面を示す図である。 テストケース生成情報の一例を示す図である。 テストケースの一例を示す図である。 外部仕様分析処理S302の詳細な処理を示すフローチャートである。 テストケース生成情報生成処理S304の詳細な処理を示すフローチャートである。 分析済みパラメータ情報からテストケース生成情報を生成する例を示す図である。 テストケース生成情報生成処理S305の詳細な処理を示すフローチャートである。 外部仕様400、分析済みパラメータ情報500、テストケース生成情報600のデータ構造の概略をUML(Unified Modeling Language)のクラス図ライクに記述した図である。 テストケース生成処理に必要となる定義情報として、基本型情報定義と個別型情報定義を示した図である。 生成したテストケースから、テスト実行までの処理を説明するフローチャートである。
以下、本発明の一実施形態に係るテスト支援装置について、図1ないし図16を用いて説明する。
先ず、図1および図2を用いてテスト支援装置の構成について説明する。
図1は、テスト支援装置の機能構成とデータフローを示す図である。
図2は、テスト支援装置のハードウェア構成図である。
テスト支援装置100は、図1に示されるように、各々のデータを格納する外部仕様格納部101、分析済みパラメータ情報格納部102、テストケース生成情報格納部103、テストケース格納部104、型情報定義格納部105、テストデータ格納部106、実行結果格納部107の格納部と、解析部111、変換部112、テストケース生成部113、テストデータ生成部114、テスト実行部115、および、ユーザからの情報を入力したり、各格納部の格納情報を表示する入出力部110から構成される。
なお、各格納部で格納される情報の詳細は、後に説明する。
解析部111は、型情報定義格納部105に格納されている型情報の定義と外部仕様格納部101に格納されている外部仕様を解析して、分析済みパラメータ情報を生成する機能部である。変換部112は、型情報定義を参照し、分析済みパラメータ情報を変換して、テストケース生成情報を生成する機能部である。テストケース生成部113は、型情報定義を参照し、テストケースを生成する機能部である。テストデータ生成部114は、テストケースとテストケース生成情報より、テストデータを生成する機能部である。テスト実行部115は、テストデータを入力し、被テスト対象のプログラムを実行することにより、実行結果のデータを生成し、実行結果格納部107に格納する機能部である。
テスト支援装置100は、図2に示されるように、一般的なコンピュータ(電子計算機)の構造で実現することができる。テスト支援装置100は、CPU(Central Processing Unit)201、主メモリ202、表示I/F(Interface)203、入出力I/F204、補助記憶I/F205がバスにより接続された構成である。
CPU201は、コンピュータの各部の制御や演算処理をするプロセッサであり、外部記憶装置であるHDD210から各種プログラムを主メモリ202にロードし、所定のプログラムを実行することにより上述の各処理部を実現する。主メモリ202は、半導体記憶装置からなる記憶装置であり、実行されるプログラムやワークデータを記憶する。表示I/F203は、LCD(Liquid Crystal Display)などの表示装置240を接続する部分である。入出力I/F204は、キーボード241やマウス242、プリンタなどを接続し、インタフェース処理をおこなう部分である。補助記憶I/F205は、HDD(Hard Disk Drive)210やSDD(Solid State Drive)などの外部記憶装置を接続し、インタフェース処理をおこなう部分である。
HDD210には、テスト支援プログラム220とテスト支援DB(Data Base)230が格納されている。
テスト支援プログラム220は、入出力プログラム221、解析プログラム222、変換プログラム223、テストケース生成プログラム224、テストデータ生成プログラム225、テスト実行プログラム226からなり、各々、図1で説明した入出力部110、解析部111、変換部112、テストケース生成部113、テストデータ生成部114、テスト実行部115に対応している。
また、テスト支援DBには、外部仕様400、型情報定義(基本型情報定義1300、個別型情報定義1310:後述)、分析済みパラメータ情報500、データケース生成情報600、テストケース800、テストデータ900、実行結果1000が格納されている。
CPU201は、主メモリ202にロードされたプログラムを実行することにより、入出力部110、解析部111、変換部112、テストケース生成部113、テストデータ生成部114、テスト実行部115の各処理部をプロセスとして具現化する。
上記所定のプログラムは、予めHDD210などの外部記憶装置に格納されていてもよいし、コンピュータが利用可能な可搬性を有する外部記憶媒体から読取装置を介して必要に応じて読み出されてもよい。あるいは、コンピュータが利用可能なネットワークまたはネットワーク上の通信装置を介して、接続された他のコンピュータから必要に応じてダウンロードされて外部記憶装置に格納されるものであってもよい。
次に、具体的なテスト支援装置の処理について説明する前に、図3を用いて被テストプログラムのモデルについて簡単に説明する。
図3は、被テストプログラムのモデルを示す模式図である。
被テストプログラムは、鉄道進路制御の設備制御をイメージしたモデルであり、鉄道の運行制御で列車の出発可否を、現在の在線位置や信号機の状態などの状況に応じて判断するプログラムである。1Rは制御対象の信号機であり、2R、3Rは、それぞれ1Rに競合する信号機を表している。また、ST、1T、…、4Tは、在線上の位置を表す軌道回路である。図3で「閉そく」とされている2T、3T、4Tは、信号機1Rが侵入を許可した場合に列車が進入可能な範囲を示している。
実際の設備制御では、より細かな条件のもとで、関数の処理設計、実装がおこなわれる。以下の説明では、本実施形態では、簡易的な例を用いて説明するが、具体的に実装された関数や処理設計に対して適用してもよい。
また、上記の設備制御に限らず、例えば金融や銀行の業務システムの構成モジュールであってもよいし、あるいは、システムの動作環境の組合せ(例えば、OS(Operation System)やブラウザ)などの設定情報であってもよい。
次に、図4を用いてテスト支援装置100による外部仕様の入力からテストケース生成までの処理について説明する。
図4は、テスト支援装置100による外部仕様の入力からテストケース生成までの処理を示すフローチャートである。
テスト支援装置100は、先ず、ユーザ入力311を受け取り、外部仕様として外部仕様を外部仕様格納部101に格納する(S301)。なお、外部仕様の入力は、例えば、専用の設計ツールを用いてS301でおこなってもよいし、外部で作成された設計書を、例えば、ファイル入力等で取り込んでもよい。
次に、テスト支援装置100の解析部111は、外部仕様分析処理をおこない(S302)、分析済みパラメータ情報補完画面(後述)に、解析された分析済みパラメータ情報を提示して、ユーザ入力312を受取る。それにより、補完された分析済みパラメータ情報を分析済みパラメータ情報格納部102に格納する(S303)。
それに基づいて、テスト支援装置100の変換部112は、テストケース生成情報を生成する(S304)。テストケース生成情報は、テストケース生成情報格納部103に格納される。
次に、テスト支援装置100のテストケース生成部113は、テストケース生成情報よりテストケースを生成する(S305)。生成されたテストケースは、テストケース格納部104に格納される。
次に、図5ないし図9を用いてテスト支援装置で扱うデータ構造について説明する。
図5は、外部仕様の一例を示す図である。
図6は、分析済みパラメータ情報の一例を示す図である。
図7は、分析済みパラメータ情報の補完入力画面を示す図である。
図8は、テストケース生成情報の一例を示す図である。
図9は、テストケースの一例を示す図である。
外部仕様400は、ソフトウェアの外部仕様をパラメータとそれに関する制約条件で表したデータであり、図5に示されるように、外部仕様(パラメータ情報)401と、外部仕様(制約条件)410から構成される。
外部仕様(パラメータ情報)401は、設計対象となるソフトウェアの構成モジュールや関数にかかわるパラメータの情報を記述するためのテーブルであり、ID欄402、パラメータ名欄403、型欄404、IO欄405、配列欄406、パターン欄407から構成される。
ID欄401は、パラメータの識別子を示す欄である。パラメータ名欄403は、パラメータの名称を記載する欄である。型欄404は、パラメータの型(タイプ)情報を記載する欄である。IO欄405は、パラメータが入力、出力の何れか、あるいは、その双方で利用されるかを表す欄である。配列欄406は、そのパラメータが配列構造か、否かを示す欄である。パターン欄407は、パラメータが取り得るバリエーションを記載する欄である。
さらに、外部仕様(制約条件)410は、複数パラメータにまたがる制約条件を記載するためのテーブルであり、図5に示されるように、ID欄411、制約条件制約条件欄412から構成される。
ID欄411は、制約条件を識別するための識別子を示す欄である。制約条件欄412は、制約条件本体を記載するための欄である。
制約条件本体の記述には、簡易的な文法が定められている。条件による実行を定める文は、if(条件)then(実行)とする。ここで、if,thenは、予約語である。パラメータの値は、${パラメータ名}で表す。また、条件の部分には、=,or,andなどの予約語により論理演算が可能になっている。
また、図5のパラメータ名欄401では、パラメータ欄にインデントされた項目があるが、これは、パラメータ間の親子関係を表している。例えば、“閉そく”、“競合信号機”は、“監視対象”より、一段下げた列に記載されている。これは、“閉そく”、“競合信号機”が、“監視対象”の子パラメータであることを示している。このような、パラメータ間の親子関係は、例えば、プログラム実装上では、構造体やクラスのメンバ変数として実装すればよい。
型欄404は、各パラメータが持つ型の種別を示している。型情報には、上記パラメータがどのような値を取り得るかを示し、整数や実数、時刻や、ソフトウェアごとに定められた固有の型情報を入力する。型情報の定義については、図14、図15を用いて、後述する。なお、本実施形態では、型情報に“監視対象”、“在線状態”などの名称を用いているが、C言語やJAVA(登録商標)言語等のプログラミング言語で用いられる型“int”,“char”などを用いてもよい。
IO欄405には、パラメータが設計対象に対し、入力情報として作用するか、出力情報として作用するか、あるいは、その双方かを記載する。図5では、“I”(Input:入力)、“O”(Output:出力)を表しており、入出力双方で利用する場合には、例えば、“I/O”と記載すればよい。
また、パラメータの格納先や参照先など、IO以外の情報を付与する場合には、単に“I”、“O”などと記載するだけでなく、付与したい情報に応じた識別子を設定してもよい。たとえば、実装された関数を対象とする場合、関数のパラメータとして渡す情報、関数内で参照する外部(グローバル変数)を区別したい場合には、例えば“(P)I”、“(G)I”などと記載し、IO情報欄に参照先の種別情報がわかるように記載してもよい。
配列欄405は、パラメータが配列型か否かを示すために用いる情報であり、“○”が記載された項目は、そのパラメータが配列であることを示している。なお、固定長配列など、予め配列の長さが決められている場合には、配列欄405にその値を記載してもよい。
パターン欄407は、各パラメータがとりうる値のバリエーションを“、”区切りで記載する。例えば、“閉そく”という名称のパラメータには、パターン欄407に、“未在線、{進入中、収容中}”が記載されている。これは、“閉そく”の取りうる候補値のパターンとして、“未在線”と“{進入中、収容中}”のいずれかの場合があり得ることを示している。なお、“{進入中、収容中}”は、“{}”内に記載された候補値(この場合は“進入中”と“収容中”)のうち、一つの値をとることを示している。すなわち、“閉そく”は、入力パターンとして、“未在線”、“進入中”、“収容中”のいずれかの値をとり、外部仕様400では、“未在線”、“{進入中、収容中}”の二つのクラスに分割されることを示しているここで、「クラス」というのは、ソフトウェア開発の概念で使われる「同値クラス」であり、ソフトウェア動作として出力が同じようになるとみなせるパラメータのまとまりである。すなわち、“進入中”、“収容中”は、いずれの値をとってもテスト時の出力には影響しないことを意味する。
“競合信号機”や“列番”に記載された“@Another”、“@Valid”や“@Invalid”は、それぞれ、“その他の値”、“有効な値”、“無効な値”を表す予約語であり、外部仕様の設計段階では決定できない場合に、テストにおけるパターンを記述するために用いる。
その他、パターン欄407には、プログラム実装上のNULL値を表す“@Null”や配列の長さのバリエーションを表するための“@Length”、あるいは、任意の値をとることを示す“@Any”など、事前に予約語を定めることで、所定の情報を記載できるようにしてもよい。
先ず、ID欄3のパラメータ名403が“競合信号機”のパターン欄407の表記の“all $x are R”は、配列である競合信号機403の全ての要素の値が、R(赤信号)であることを意味している。
また、ID欄8のパラメータ名403が“在線時間”のパターン欄407のように、等号、不等号によりとり得る範囲を表すことも可能である。
さらに、ID欄8のパラメータ名403が“出力”のパターン欄407のTrue,Falseは、真偽を表す予約語である。
外部仕様(制約条件)410内の制約条件欄412欄には、パラメータ間の制約関係を記載する。図5の例(ID欄411が“1”の場合)では、対象列車の在線位置の長さが“1”でないとき、対象列車の在線時間は“0”であることを示している。
なお、”.”は、パラメータ名欄403の説明のときに言及したパラメータ間の親子関係を示しており、例えば、“対象列車.在線位置.@Length”は、“対象列車”の子パラメータである“在線位置”の“長さ”であることを示している。
次に、図6に示される分析済みパラメータ情報500は、外部仕様400を解析した結果得られる情報であり、分析済みパラメータ情報(パラメータ情報)501と、分析済みパラメータ情報(制約条件)510から構成される。
分析済みパラメータ情報(パラメータ情報)501は、外部仕様(パラメータ情報)401と同様に、ID欄502、パラメータ名欄503、型欄504、IO欄505、配列欄506、パターン欄507から構成される。
分析済みパラメータ情報500は、外部仕様400と同様のデータ構造を有するが、テスト支援装置は、図4の外部仕様分析処理S303の処理結果として、外部仕様400からテストケース生成時に必要な情報の抽出し、クラス分割が不十分なパラメータのクラス分割がおこなわれた結果を、図7に示されたパラメータ情報補完画面を表示して、ユーザにパラメータ情報の補完入力を求める。パラメータ情報補完画面では、表形式でパラメータ情報を表示し、ユーザに補完を求める欄に太枠を表示したり、あるいは、セルの背景色を変える、セルを点滅表示させるなどにより、ユーザに入力を促す。
なお、図6に示された分析済みパラメータ情報500では、パラメータ情報の補完入力を求める部分は、太枠で表示している。
例えば、図6の分析済みパラメータ情報500では、図5の外部仕様400に対し、ID欄502の“3a”、“6a”のパラメータ名“@Length”のレコードが追加されている。これは、対応する親要素の“競合信号機”、“在線位置”が配列情報であるため、テスト実行時には、配列の長さを特定し、具体的なデータを割り当てる必要があるため、ユーザに入力が促されるものである。
また、ID欄502が“11”の“現在時刻”がパラメータ名に追加されているが、これらは、外部仕様(制約条件)410より、パラメータ名欄407に存在しないパラメータの記述が${現在時刻}として制約条件に記載されているためである(ID欄411が“2”の制約条件412を参照)。
また、例えば“@Another”(“競合信号機”のパラメータ欄)等の抽象的なパターンが記述された場合や空欄(“在線位置”等)の場合に、パターン入力、あるいは、具体的な候補値の割当てが必要であることを示しており、入力された値は、{}の部分に反映される。
そして、テスト支援装置100は、ユーザが具体値、あるいは、データパターンの入力を行った結果に対し、テストケース生成情報生成処理(S304)を実行する。
また、図6の分析済みパラメータ情報(パラメータ情報)501のパラメータが“在線時間”のレコードのパターン欄507は、図4の外部仕様400の“在線時間”のレコードのパターン欄407の記述が異なっている。これは、外部仕様400のパラメータのクラス分割が不十分である場合に、外部仕様分析処理S302によって、クラス分けが補充された結果である。
以上の説明では、分析済みパラメータ情報500が生成された段階(S302の後)で具体値の入力を促しているが、具体値の入力は必須ではない。この場合、S304のテストケース生成処理までは抽象的なパターン名(@Valid)が用いられる。そのため、テスト実行前(テストケース生成後)に、実行可能な具体値の割り当てをおこなえばよい。
次に、図8に示されるテストケース生成情報600は、ユーザにより情報を補完された分析済みパラメータ情報500を変換して得られる情報であり、テストケース生成情報(パラメータ情報)601と、テストケース生成情報(制約条件)610から構成される。テストケース生成情報600は、次の工程であるテストケース800を生成するための元データとなる情報である。
テストケース生成情報601(パラメータ情報)は、ID欄602、パラメータ名欄603、型欄604、IO欄605、候補値欄606から構成される。
ID欄602、パラメータ名欄603、型欄604、IO欄605は、それぞれ分析済みパラメータ情報(パラメータ情報)501のID欄502、パラメータ名欄503、型欄504、IO欄505、配列欄506、パターン欄507に対応する。候補値欄606は、分析済みパラメータ情報500に基づいて、パラメータが取り得る候補値を格納する欄である。
また、テストケース生成情報(制約条件)610は、ID欄611、制約条件欄612から構成される。
ID欄611は、制約条件の識別情報を一意に特定する識別子を示す欄である。制約条件欄612は、テストケース生成時に用いるパラメータ間の制約条件を記載する欄である。
上記のごとく、図8に示したテストケース生成情報600は、外部仕様400、および、分析済みパラメータ情報500と同様の書式を有している。しかしながら、テストケース生成情報600では、パラメータ名欄603は、外部仕様400、分析済みパラメータ情報500とは異なり、階層化されておらず、代わりに、“.”を用いて、パラメータ間の親子関係(クラスのメンバ変数など)を表している。
また、例えば、ID欄602が“6−1”“6−2”のパラメータ名が“在線位置”というパラメータが配列であるために、配列の要素ごとに値を割り振って、配列の長さ分のパラメータを生成している。この例では、“在線位置”に対し、二つ分のパラメータを生成しているが、これは、ユーザ入力311による分析済みパラメータ情報の入力(S304)により、“@Lenghth”として最大で“2”を持つパターンが入力された場合を示している。
以上のテストケース生成情報への変換は、テストケース生成処理S305において、各パラメータを階層化していない情報として扱うことに対応するため、また、配列データに対し、配列の要素ごとに具体的なデータ割当てをおこなうための処理である。なお、“競合信号機”というパラメータ名のパラメータも配列であるが、型情報の違い(集合型であるため)により、本例では長さ分のデータを生成しない。
また、テストケース生成情報(制約条件)610には、ID(ID欄611)が“3”の制約条件等が追加されている。これらは、パラメータの親子関係や、配列の長さを考慮した適切なテストケース生成をおこなうための制約条件である。例えば、親子関係を有するパラメータに対し、親パラメータがNULL値の場合に、子パラメータが値を持たないようにする、あるいは同様に、配列の長さ情報にバリエーションがある場合に、長さ以上の配列の要素に値を持たせないようにする(例えば、配列の長さが“1”,“2”の二つの値をとる場合に、長さ“1”の場合に2番目の配列データに値を割りあてないようにする)、などの無効なテストケースが生成されないようにするためである。
次に、図9に示されるテストケース800は、テストケース生成処理S305の結果得られるデータであり、実際のソフトウェアテストの元データとなるものである。テストケース生成処理S305では、テストケース生成情報600から入力パラメータの候補値の組合せを生成することにより、テストケースの生成をおこなう。
テストケース800は、図9に示されるように、ID欄801、パラメータ名欄802、型欄803、IO欄804、テストケース欄805から構成される。
ID欄801は、パラメータの識別子を示す欄である。パラメータ名欄802は、パラメータの名称を記載する欄である。型欄803は、パラメータの型情報を記載する欄である。IO欄804は、パラメータが入力か出力かをあらわす欄である。テストケース欄805は、各々のテストケース(パラメタ毎にとる値を定めたもの)を記載する欄である。
例えば、テストケース欄805のサブ1欄には、パラメータ名“競合信号機”のパラメータの値が、@Notnullであり、パラメータ名“監視対象.閉そく”のパラメータの値が、未在線であり、…ということを意味する。
次に、図10を用いて外部仕様分析処理S302の詳細について説明する。
図10は、外部仕様分析処理S302の詳細な処理を示すフローチャートである。
外部仕様分析処理S302は、前述の通り、解析部111において実行される処理であった。
先ず、まず、外部仕様(パラメータ情報)401を対象に、全てのパラメータを順次分析し、パラメータ単位の分析処理(S902)、パラメータ単位のクラス分割処理(S903)、パターン情報の分析処理(S904)をおこなう(S901〜S905)。
ここで、パラメータ単位の分析処理(S902)では、配列欄506に“○”が記載されている場合(可変長配列である場合)に、配列の長さ情報を表す“@Length”をパラメータ情報に追加する。また、IO欄405にI/O(入力と出力双方で用いるパラメータ)の場合に、当該パラメータを“I”(入力)と“O”(出力)の二つのパラメータに分割する。
また、パラメータ単位のクラス分割処理(S903)では、パターン欄407に記載されたパターンのクラス分割が不十分である場合に、型欄404に記載された型情報に基づき、クラス分割処理をおこなう。
さらに、パターン情報の分析処理(S904)は、パターン欄407内に、例えば“@Valid”、“@Invalid”などの抽象的なパターンが記述されているか否かの分析をおこなう。
次に、外部仕様(制約条件)410を分析し、制約条件欄412を順次読込み、外部仕様(パラメータ情報)401に記載されていないパラメータが記述されている場合には、その項目の抽出をおこなう(S907)(S906〜S908)。
最後に、S908までの処理結果から、分析済みパラメータ情報500として整形し、生成する(S909)。その際には、S904で抽出されたパラメータのパターン欄507、S907で追加されたパラメータ、および、パターン欄507に記述がない欄を、補完を要するデータとして認識し、テスト支援装置100は、図7に示したパラメータ情報補完画面を表示するときには、強調表示をおこなう。
次に、図11および図12を用いてテストケース生成情報生成処理S304の詳細について説明する。
図11は、テストケース生成情報生成処理S304の詳細な処理を示すフローチャートである。
図12は、分析済みパラメータ情報からテストケース生成情報を生成する例を示す図である。
テストケース生成情報生成処理S304は、テスト支援装置100の変換部112で実行される処理であり、分析済みパラメータ情報500から、テストケース生成情報600を生成する処理であった。
先ず、テストケース生成情報生成処理S304では、全てのパラメータを順次読込み、パラメータ情報の変換(S1002)、配列データの生成(S1003)、パラメータ単位のクラス分割処理(S1004)、および、制約条件の追加(S1005)をおこなう(S1001〜S1006)。
パラメータ情報の変換(S1002)では、パラメータの親子間の関係から、パラメータ名の変換をおこなう。すなわち、親パラメータから当該パラメータまでを“.”でつなぐことよりテストケース生成情報600のパラメータ名に変換する。
次に、親子間の関係からパターンに候補値の追加をおこなう。具体的には、子パラメータが何らかの値を持つことが明らかな場合に、NULL値でないことをあらわす“@NotNull”を追加する。また、親パラメータが“@Null”などの値を持たないパターンが含まれている場合、当該パラメータが値を持たないことを示す“@Vain”を追加する。次に、配列データの生成(S1003)では、パラメータが配列データである場合に、パターン欄507に与えられた長さの最大値分、パラメータを生成する。
パラメータ単位のクラス分割処理(S1004)は、外部仕様分析処理S302における、パラメータ単位のクラス分割処理(S903)と同じである。このテストケース生成情報生成処理においてもクラス分割処理がおこなわれるのは、ユーザ入力311による分析済みパラメータ情報への入力(S304)のときに、パターン欄507に追加入力されたパターンに対し、クラス分割処理をおこなうためである。
制約条件の追加(S1005)では、親パラメータが“@Null”などの値を持たない場合に、子パラメータが値を持たないことを表す“@Vain”を取ること、配列の長さ以上の配列要素に対し、当該パラメータが“@Vain”となることを、制約条件に追加する。
図8に示されるテストケース生成情報(制約条件)610の例では、ID欄611が3のレコードに対して、“在線位置”の長さが“1”のときに、在線位置の2番目の配列要素“対象列車.在線位置[1]”が“@Vain”となる制約条件を追加した例を示している。
次のS1007からS1009の処理では、前記S1001からS1006までの処理結果に合わせ、制約条件の変換をおこなう。本処理では、配列データに対して制約条件が記述されている場合に、配列データ分の制約条件の複製などをおこなう。
次に、パラメータ間のクラス分割処理をおこなう(S1010)(詳細は、後述)。
最後に、分析済みパラメータ情報500から変換の結果、得られた情報をテストケース生成情報600として出力する(S1011)。
S1010のパラメータ間のクラス分割処理では、分析済みパラメータ情報500のパターン507に基づいて、テストケース生成情報(パラメータ情報)601の候補値欄606の候補値が生成できるようにパラメータの置き換えをおこなう。以下、その具体例を、図12のケースを例にとり説明する。
図12に示される例におけるパラメータ間のクラス分割処理(S1010)では、分析済みパラメータ情報700のパラメータP0の子パラメータであるP01、P02、P03、P04に対し、分析済みパラメータ情報(制約条件)702に記載された情報に基づいて、テストケース生成情報710を生成する例を示している。
図12に示されるように、分析済みパラメータ情報(制約条件)702のパターン欄に値が定義されていない。この場合、分析済みパラメータ情報(制約条件)702を分析し、関連する制約条件を抽出し、制約条件からテストケース生成用に擬似パラメータ(図12のA,B,C)を生成し、分析済みパラメータ情報(制約条件)702から得られるパターン、および、パラメータ間の制約関係を、それぞれテストケース生成情報(パラメータ情報)711の擬似パラメータの候補値欄と、テストケース生成情報(制約条件)712の制約条件欄に追加する。
図12に示される例では、分析済みパラメータ情報(制約条件)702の最初に、${P1}+${P3}<10という条件式が存在するが、パラメータ名P0のレコードのパターン欄、パラメータ名P3のレコードのパターン欄には値が定義されていない。そこで、テストケース生成情報(制約条件)712のID欄が2のレコードに示されるように、新しいパラメータとして、A=P0.P1+P0.P3を生成する。これにより、問題としている条件式に等価な条件式は、A<10となり、Aに対するテストケース生成情報における候補値としては、<10の場合、≧10の場合が生成される(テストケース生成情報(パラメータ情報)711のID欄が1のレコード)。同様に、B=P0.P1+P0.P2、C=P0.P2+P0.P3が導入され、条件式にあったように、テストケース生成情報における候補値が生成される。
なお、上記のように、テストケース生成情報の生成時にパラメータに具体値が設定されていない場合には、テストケース生成前に、警告メッセージを出力する等、事前にユーザにテストケース生成の実施要否をたずねるなどしてもよい。また、上記の処理でも、候補値が未定となるパラメータが存在する場合には、エラーメッセージを表示し、処理を中止する、あるいは、警告メッセージを表示したうえで、生成可能な範囲でテストケースの生成を行ってもよい。
次に、図13を用いてテストケース生成処理S305の詳細について説明する。
図13は、テストケース生成情報生成処理S305の詳細な処理を示すフローチャートである。
テストケース生成処理S305は、テスト支援装置100のテストケース生成部113において実行される処理であった。
テストケース生成処理305では、テストケース生成情報(パラメータ情報)601より、IO欄605が入力(“I”)であるパラメータごとに候補値を選び、パラメータの候補値の組合せを生成する(S1101)。次に、選んだパラメータの候補値の組合せが、テストケース生成情報(制約条件)610の制約条件を満たすか否かをチェックする(S1102)。制約条件を満たす場合(S1103:満たす)、S1101で生成したパラメータの候補値の組合せをテストケースとして登録し、テストケースの生成基準に準拠するか否かのチェックをおこなう(S1104)。
生成されたテストケース群がテストケース基準を満たす場合(S1105:満たす)には、テストケース800を生成する(S1106)。
制約条件を満たさない場合(S1103:満たさない)、生成されたテストケース群がテストケース基準を満たさない場合(S1105:満たさない)には、S1101に戻り、再度、パラメータの候補値の組合せを生成する。
ここで、制約条件のチェックは、例えば、SAT(SATisfiability problem) SolverやSMT(Satisfiability Modulo Theories) Solverなどを用いて制約条件を満たすかのチェックが可能である。
テストケースの生成基準は、生成されたテストケースの数や、パラメータの候補値の組合せの網羅率など、テストの設計基準に応じて予め設定しておけばよい。なお、パラメータの候補値の組合せを考慮したテストケース基準として、n−wiseカバレッジが知られている。n−wiseカバレッジを満たすテストケース生成方法をn−wise法と呼び、様々なテストケース生成方法が知られている。図13に示したテストケース生成処理S305は、これらn−wise法のテストケース生成方法を用いてもよい。また、n−wise法には、パラメータに優先度を考慮してテストケースを生成する方法や、パラメータをグループ化し、グループごとに網羅率を設定するなどの応用方式が知られている。分析済みパラメータ情報(パラメータ情報)501にパラメータの優先度やグループ分けの情報を追加する欄を設けることにより、これらの応用方式を用いてもよい。さらに、上記のテストケース生成処理S305の説明や、一般的なn−wise法では、出力パラメータを考慮していないが、例えば、出力パラメータを考慮した方式(特許文献2など)を用いてもよい。
次に、図14、図15を用いて、本実施形態の説明に採用した外部仕様400、分析済みパラメータ情報500、テストケース生成情報600のデータ構造の詳細を説明する。
図14は、外部仕様400、分析済みパラメータ情報500、テストケース生成情報600のデータ構造の概略をUML(Unified Modeling Language)のクラス図ライクに記述した図である。
図15は、テストケース生成処理に必要となる定義情報として、基本型情報定義と個別型情報定義を示した図である。
図14に示される本実施形態のデータは、パラメータ構造1200、型情報1210、制約条件1221から構成されている。
パラメータ構造1200は、パラメータ間の関係を表している。型情報1210は、パラメータのとりうる型の関係を示す情報である。制約条件1221は、パラメータの制約条件を記述する情報である。
パラメータ構造1200は、パラメータ1201、親パラメータを格納するため複合パラメータ1202、および、具体的なデータ割当が必要となる単純パラメータ1203から構成される。ここで、パラメータ構造1200のボックスに記述した上半分が、UMLのクラス図のクラスにあたるものであり、下半分が属性にあたるものである。例えば、パラメータ1201の構成要素である"長さ"は、当該パラメータが配列データである場合に、その配列の長さを格納するための属性である。
また、複合パラメータ1202は、構造体やクラスなど、親パラメータの情報を格納するためのデータであり、型名称は構造体やクラスの型名称を表す。また、パターンは、複合パラメータ1202自体が、NULL値、あるいは、値を持たないこと等を示すために用いる(図5、図6、図8の“@Null”や“@Vain”等に対応)。
さらに、単純パラメータ1203は、候補値となるパラメータのパターンを格納するための“パターン”から構成され、型情報1210との関係によって、そのパラメータがどの型情報に属するかの情報を格納する。
型情報1210は、パラメータの型情報(外部仕様400、分析済みパラメータ情報500、テストケース生成情報600の型欄に相当)を格納するためのデータである。
図14に示したように、型情報1210は、基本となる基底型1211をベースとして、グループ型1212、列挙型1213、集合型1214、比較可能グループ型1215から構成されている。
ここで、グループ型1212、比較可能グループ型1215は、数学でいう所の演算が定義された群など、算術演算が可能なパラメータに対する型の総称であり、比較可能グループ1215は、整数、実数など、パラメータ間の大小の比較が可能なパラメータに対する型の総称である。列挙型1213は、曜日や性別など、パラメータの取り得る値が決められたパラメータに対する型の総称であり、集合型1214はパラメータを集合として扱う必要がある場合に用い、例えば、図5の外部仕様400の“競合信号機”のように、複数の項目からなるが、“全ての○○が□□である”(図5のID欄が3のレコードのパターン欄407に記載された予約語all)、“少なくとも○○の一つが”(図示しなかったが予約語some)など、パラメータ内の項目をまとめて一つの集合として扱う必要があるものを示している。
次に、制約条件1221は、外部仕様(制約条件)410、分析済みパラメータ情報(制約条件)510、テストケース生成情報(制約条件)610で記述されたデータを表している。
なお、図14は、外部仕様400、分析済みパラメータ情報500、テストケース生成情報600の構造の概略図であり、上記以外の構成要素を含んでもよい。また、型情報1210も、図14に示した型情報以外の型を含んでもよい。
次に、図15を用いてテストケース生成処理に必要となる定義情報について説明する。
図15に示したように定義情報は、基本型情報定義1300と個別型情報定義1310から構成される。基本型情報定義1300は、ID欄1301、型種別欄1302、制約条件記述欄1303、制約条件分析チェック1304から構成される。
ID欄1301は、型情報の識別子を示す欄である。型種別欄1302は、型の社別を示す欄である。制約条件記述欄1303は、その型種別に対して、制約条件の記述方法を記載する欄である。制約条件分析チェック1304は、図13に示した制約条件チェック処理S1102で用いる制約条件記述欄1303に対応した記法を記載する欄である。特に、制約条件記述欄1303は、SAT SolverやSMT Solverなどのようなテストツールで使用されることを意図している。
また、個別型情報定義1310には、実際の外部仕様400、分析済みパラメータ情報500、テストケース生成情報600内で用いる型情報と、記法や関連情報を格納する。個別型情報定義1310は、図15に示されるように、ID欄1311、型名称欄1312、型種別欄1313、書式欄1314、補足情報欄1315から構成される。
ID欄1311は、定義情報の識別子を示す欄である。型名称欄1312は、型の名称を示す欄である。型種別欄1313は、基底となる型情報を示す欄である。書式欄1314は、パターン欄への記述方法を定める欄である。補足情報欄1315は、最小値や最大値、ビット幅などの型情報ごとの補足情報を格納する欄である。
上記で定義した型情報に基づき、パラメータごと、および、パラメータ単位のクラス分割をおこなう(図10のS903、図11のS1004)。
以下、各型に対するクラス分割処理の概要を説明する。
グループ型、および、列挙型の場合には、パラメータが取り得る値のバリエーションからクラス分割をおこなう。例えば、“e1,e2,e3,e4,e5,e6”の6個の値を取り得る列挙型のパラメータがあり、パターン欄として“{e1,e2,e3}”、“e4”、“@Another”、“e1”の4つのバリエーションがあると記載されている場合には、与えられたバリエーションを順次読込み、以下のように処理をおこなう。なお“@Another”は、“その他”を表し、与えられたバリエーションの中から残った値のいずれかの値を取ることを示す。
先ず、“{e1,e2,e3}”というパターンより、“e1,e2,e3,e4,e5,e6”を、“{e1,e2,e3}”と“{e4,e5,e6}”の二つのクラスに分割する。次に、“e4”というパターンより、“{e4,e5,e6}”を“e4”と“{e5,e6}”に分割する。“@Another”に対しては、上記分割の内、パターンに割当されていない “{e5,e6}”を割当てる。最後に、“e1”に対し、“{e1,e2,e3}”を“e1”と“{e2,e3}”に分割し、最終的に以下の分割結果として、“e1,{e2,e3},e4,{e5,e6}”を得る。
一方、比較可能グループ型の場合には、与えられたパターン内の数値でデータの大小関係、比較演算子からクラス分割をおこなう。例えば、整数型のパラメータのパターンが“>=0”,“>10”,“3<x<5"の場合には、以下のように処理をおこなう。
先ず、与えられたバリエーション内の数値データを昇順(または、降順)に並べる。昇順に並べら得た結果(“>=0”、“3<”、“<5”、“>10”)に対し、比較演算子の特性を意識して、以下のようにクラス分割をおこなう。
先ず、“>=0”、“3<”より、0から3を超える数値の間にあるクラスを補間するため、“3<”の記述から、“<=3”を補間し、“0<=x<=3”の分割を得る。次に“3<”、“<5”の記述から、“3<x<5”を生成する。“<5”、“>10”の記述から、最初の分割処理と同様、5以上、10未満の値を表すクラスを補間するため、“<5”より、“5<=”を補間し、“5<=x<10”を生成する。最後に、“0<”の記述から、“>10”より、“>=10”のクラスを補間する。以上の分析結果より、“0<=x<=3”、3<x<5”、5<=x<10”、“>=10”を得る。以上の分割は、数値直線上に各分割領域をマッピングすることで、容易に実装可能である。
なお、上記では、与えられたバリエーションのみから、クラス分割をおこなったが、指定以外の領域をクラス分割結果に含めてもよい。上記の例では、“>=0”に対し、“<0”をクラス分割に加えてもよい。
最後に、集合型はパターン欄に記述された各パターンをバリエーションとしてそのまま用いればよい。上記の型情報ごとのクラス分割は、クラス分割方法の一例であり、上記とは異なる形で実施してもよい。
以上の処理により、外部仕様400から、分析済みパラメータ情報500、テストケース生成情報600の生成、および、テストケース800の生成が実現される。
なお、本実施形態では、外部仕様400から、分析済みパラメータ情報500、テストケース生成情報600を表形式の形式で表現し、さらに制約条件には、事前条件など入力パラメータのみの制約条件と、入出力パラメータ間を表す制約条件を混在して記述したが、事前条件と事後条件など、制約条件の内容に応じて分割して書いてもよい。
また、上記の制約条件の記述やテストケース生成情報生成処理S304の制約条件の生成処理において、関連する仕様書から制約条件を補完してもよい。例えば、UMLにおけるクラス図や、DB設計に用いられるER(Entity Relationship)図等から、パラメータ間の多重度やパラメータ間の関係を抽出することで制約条件を追加してもよい。
次に、図16を用いて生成したテストケースから、テスト実行までの処理を説明する。
図16は、生成したテストケースから、テスト実行までの処理を説明するフローチャートである。
以上のように、外部仕様からテストケースが生成され、実際にテストをおこなう際には、テスト対象となるソフトウェアの構成モジュール、あるいは、関数に対し、生成されたテストケースを用いてテスト実行を行い、その結果の確認をおこなう。
なお、テスト実行は具体的なテストデータを用いて、テスト対象のソフトウェア構成モジュールや関数等を動作させ、その結果を取得する処理をおこなうが、テスト対象を動作させる処理は、必ずしもテスト支援装置100で実行する必要は無い。例えば、テスト対象のソフトウェア構成モジュールがネットワークで接続されている場合には、ネットワーク経由で実行してもよい。
図16に示したように、外部仕様格納(S1501)から、テストケース生成(S505)までの処理の流れは、図4の処理の流れと同様である。
図16の処理では、図4のテストケース生成(S1505)に、生成されたテストケースの修正(S1506)、テストデータ生成処理(S1507)、テストデータの修正(S1508)、テスト実行(S1509)、テスト実行結果の確認(S1510)の手順が追加されている。
先ず、生成された生成されたテストケースに対して、テストケースの修正をおこなう(S1506)。例えば、パラメータの候補値として、“@Valid”などの抽象的な候補値が設定されていた場合に、テスト実行可能な具体値の割当てをおこなう、あるいは、個別実行したいテストケースの追加をおこなう。
次に、テストデータ生成をおこなう(S1507)。例えばテストケース内に抽象的なパターン(例えば、“@Valid”や、“0<x<100”など)である場合に、実際にテスト実行可能な具体値を生成する、あるいは、テストデータ入力を促すための強調表示をおこない、ユーザ入力1523でのテストデータ900の入力を促す。なお、具体値の生成では、与えられた条件を満たすランダムな具体値を設定してもよいし、あるいは、“0<x<100”のような特定の範囲が割当てられている場合には、テスト基準に従い、境界値や中間値を割当てるようにしてもよい。
次に、上記生成されたテストデータ900に対し、具体的なデータの割当て、テスト実行者が、修正が必要と判断した場合には、さらに、テストデータ900の修正をおこない(S1508)、その後に、テスト実行をおこなう(S1509)。
テスト実行の結果、全てのテストケースに対応するテスト結果が得られた、あるいは、全て(あるいは規定件数以上)のテストの実行結果1000が期待結果どおりだった、等、テストの合格基準に達した場合には(S15011:満たす)、テストを終了し、そうでない場合には(S15011:満たさない)、その結果に応じて、S1501、S1503、S1506、S1508の各入力手順に戻る(S1511)。
例えば、テスト結果から制約条件に記述漏れがあり、無効な入力値を入れてしまったなど、外部仕様400の記述が足りなかった場合には、外部仕様400の作成(S1501)に戻り、外部仕様400の記述の見直しをすればよい。
また、テスト実行結果として、テスト件数や、実行時のカバレッジ(実行ステップカバレッジや分岐ステップカバレッジなどのブラックボックステストのカバレッジ基準など)が不足している場合には、テストケースの修正(S1506)に戻り、テストケースの追加をおこなえばよい。このとき、例えば、テスト実行中の実行パスを記録し、各入力データがどの実行パスに対応するかをテスト実行結果に含めてもよい。これによって、テストケースの修正(S1506)を実施する際、選ばれていない(異なるパスを通りそうな)パターンの組合せをテストケースの生成に加えるなど、テストケースの修正(S1506)の参考にすることが可能となる。
また、前記テストの実行結果に、実行パスとの対応を含める場合において、全ての組合せパターンに対して、テスト実行をしたにもかかわらず、実行ステップカバレッジや分岐ステップカバレッジのカバレッジ率が合格基準を満たさない、あるいは、意図したパスと異なる経路を通る場合には、外部仕様400、あるいは、テスト対象のソースコードを見直すなど、生成されたテストケースと実行パスの対応を参考にしてもよい。
これらは、テスト実行結果を元にユーザが目視で確認してもよいし、テスト実行時にテスト実行パスを取得し、テストケースとの対応関係をテストケース上で管理することで、テストの合格基準の判断(S1511)を自動的に判定できるようにしてもよい。
さらに、テストケース生成(S1505)において、実行結果1000の特定ができない(入力パラメータの組合せのみを生成する)場合には、各テストケースの初回実行時の実行結果1000から、その実行結果が期待通りか否かを確認した後、テストケースの修正(S1506)、あるいは、テストデータの修正(S1508)に反映することによって、期待結果として用いるようにしてもよい。これによって、ソフトウェア改修時のリグレッションテスト時の結果確認を含めたテスト自動実行が容易となる。
100…テスト支援装置、101…外部仕様格納部、102…分析済みパラメータ情報格納部、103…テストケース生成情報格納部、104…テストケース格納部、105…型情報定義格納部、106…テストデータ格納部、107…実行結果格納部、110…入出力部、111…解析部、112…変換部、113…テストケース生成部、114…テストデータ生成部、115…テスト実行部

Claims (14)

  1. CPUと、記憶部と、表示部を有し、前記記憶部に格納されたプログラムを実行することにより機能を実現するテスト支援装置であって、
    前記記憶部は、外部仕様と、分析済みパラメータ情報と、テストケース生成情報と、テストケースを記憶し、
    前記外部仕様と前記分析済みパラメータ情報とは、テスト対象のソフトウェアプログラムで記述されるパラメータのパラメータ情報と、そのパラメータのパラメータ間の関係を表す制約条件とを保持し、
    前記外部仕様と前記分析済みパラメータ情報のパラメータ情報は、そのパラメータの型情報と、パラメータ名が取り得るパターン情報とを含み、
    前記テストケース生成情報は、テスト対象のソフトウェアプログラムで記述されるパラメータのパラメータ情報と、そのパラメータのパラメータ間の関係を表す制約条件とを保持し、
    前記テストケース生成情報のパラメータ情報は、そのパラメータの型情報と、パラメータ名が取り得る候補値とを含み、
    前記テストケースは、テスト対象のソフトウェアプログラムで記述されるパラメータのパラメータ値を定めた組合せを、一つ以上保持し、
    前記外部仕様のパラメータ情報の前記パラメータの型情報、前記パターン情報、前記制約条件から、前記パラメータのクラス分割をおこない、前記分析済みパラメータ情報を生成し、
    前記分析済みパラメータ情報のパラメータ情報の前記パラメータの型情報、前記パターン情報、前記制約条件から、前記パラメータのクラス分割をおこない、前記テストケース生成情報を生成し、
    前記テストケース生成情報のパラメータ情報の前記パラメータの型情報と、前記制約条件と、前記パラメータ情報の候補値とから、前記パラメータ値を定めた組合せを生成し、前記テストケースを生成することを特徴とするテスト支援装置。
  2. 前記外部仕様から、前記分析済みパラメータ情報を生成する際に、
    前記外部仕様に記述されたパラメータの不足情報を抽出し、前記表示部に、パラメータごとにパラメータの不足情報を強調表示する画面を表示し、前記分析済みパラメータ情報の補完入力を受け付けることを特徴とする請求項1記載のテスト支援装置。
  3. 前記分析済みパラメータ情報から、前記テストケース生成情報を生成する際に、
    前記分析済みパラメータ情報のパラメータ制約条件に基づいて、前記分析済みパラメータ情報に記載されたパラメータを変換して、前記テストケース生成情報に記載されるパラメータを生成することを特徴とする請求項1記載のテスト支援装置。
  4. 前記外部仕様のパラメータ情報と前記分析済みパラメータ情報におけるパラメータのクラス分割とは、前記パターン情報に記載されたパラメータに対して、パラメータの型情報ごとに定められたクラス分割処理をおこなうことを特徴とする請求項1記載のテスト支援装置。
  5. 前記分析済みパラメータ情報に記載されたパラメータを変換して、前記テストケース生成情報に記載されるパラメータを生成する処理は、
    前記分析済みパラメータ情報に記載されたパラメータに親子間の関係がある場合に、親パラメータが値を持たないときに、子パラメータに値を持たないことを示すパターン情報、または、子パラメータに値を持つときに、親パラメータが値を持つことを示すパターン情報を追加する処理と、
    前記分析済みパラメータ情報に記載されたパラメータが複数の項目からなる配列であった場合に、与えられた配列の項目数に応じたパラメータを生成する処理と、
    前記パラメータの親子関係、および、配列の長さに応じて生じるパラメータ間の制約条件を、前記テストケース生成情報に記載される制約条件に追加する処理を含むことを特徴とする請求項3記載のテスト支援装置。
  6. 前記外部仕様に記述されたパラメータの不足情報を抽出し、前記表示部に、パラメータごとにパラメータの不足情報を強調表示する画面を表示し、前記分析済みパラメータ情報の補完入力を受け付ける処理は、
    前記外部仕様に記述されたパラメータが複数の項目からなる配列であり、配列のデータが可変である場合に、配列の長さを入力するためのパラメータを追加する処理と、
    前記外部仕様に記述されたパラメータのパターン情報に、テスト実行に必要な情報が不足しているパターン情報を抽出する処理を含むことを特徴とする請求項2記載のテスト支援装置。
  7. 前記記憶部は、さらに、前記テストケースに記載された前記パラメータ値を定めた組合せに基づいて、生成されるテスト実行可能な具体値を格納したテスト実行のためのテストデータと、前記テストデータによるテスト実行結果を記憶し、
    前記テストケースからテストデータを生成し、
    前記テストデータを用いてテスト実行を行い、その実行結果を収集することを特徴とする請求項1記載のテスト支援装置。
  8. CPUと、記憶部と、表示部を有し、前記記憶部に格納されたプログラムを実行することにより機能を実現するテスト支援装置のテスト支援方法であって、
    前記記憶部は、外部仕様と、分析済みパラメータ情報と、テストケース生成情報と、テストケースを記憶し、
    前記外部仕様と前記分析済みパラメータ情報とは、テスト対象のソフトウェアプログラムで記述されるパラメータのパラメータ情報と、そのパラメータのパラメータ間の関係を表す制約条件とを保持し、
    前記外部仕様と前記分析済みパラメータ情報のパラメータ情報は、そのパラメータの型情報と、パラメータ名が取り得るパターン情報とを含み、
    前記テストケース生成情報は、テスト対象のソフトウェアプログラムで記述されるパラメータのパラメータ情報と、そのパラメータのパラメータ間の関係を表す制約条件とを保持し、
    前記テストケース生成情報のパラメータ情報は、そのパラメータの型情報と、パラメータ名が取り得る候補値とを含み、
    前記テストケースは、テスト対象のソフトウェアプログラムで記述されるパラメータのパラメータ値を定めた組合せを、一つ以上保持し、
    前記外部仕様のパラメータ情報の前記パラメータの型情報、前記パターン情報、前記制約条件から、前記パラメータのクラス分割をおこない、前記分析済みパラメータ情報を生成するステップと、
    前記分析済みパラメータ情報のパラメータ情報の前記パラメータの型情報、前記パターン情報、前記制約条件から、前記パラメータのクラス分割をおこない、前記テストケース生成情報を生成するステップと、
    前記テストケース生成情報のパラメータ情報の前記パラメータの型情報と、前記制約条件と、前記パラメータ情報の候補値とから、前記パラメータ値を定めた組合せを生成し、前記テストケースを生成するステップとを有することを特徴とするテスト支援方法。
  9. 前記外部仕様から、前記分析済みパラメータ情報を生成するステップにおいて、
    前記外部仕様に記述されたパラメータの不足情報を抽出し、前記表示部に、パラメータごとにパラメータの不足情報を強調表示する画面を表示し、前記分析済みパラメータ情報の補完入力を受け付けることを特徴とする請求項8記載のテスト支援方法。
  10. 前記分析済みパラメータ情報から、前記テストケース生成情報を生成するステップにおいて、
    前記分析済みパラメータ情報のパラメータ制約条件に基づいて、前記分析済みパラメータ情報に記載されたパラメータを変換して、前記テストケース生成情報に記載されるパラメータを生成することを特徴とする請求項8記載のテスト支援方法。
  11. 前記外部仕様のパラメータ情報と前記分析済みパラメータ情報におけるパラメータのクラス分割とは、前記パターン情報に記載されたパラメータに対して、パラメータの型情報ごとに定められたクラス分割処理をおこなうことを特徴とする請求項8記載のテスト支援方法。
  12. 前記分析済みパラメータ情報に記載されたパラメータを変換して、前記テストケース生成情報に記載されるパラメータを生成するステップは、
    前記分析済みパラメータ情報に記載されたパラメータに親子間の関係がある場合に、親パラメータが値を持たないときに、子パラメータに値を持たないことを示すパターン情報、または、子パラメータに値を持つときに、親パラメータが値を持つことを示すパターン情報を追加する処理と、
    前記分析済みパラメータ情報に記載されたパラメータが複数の項目からなる配列であった場合に、与えられた配列の項目数に応じたパラメータを生成する処理と、
    前記パラメータの親子関係、および、配列の長さに応じて生じるパラメータ間の制約条件を、前記テストケース生成情報に記載される制約条件に追加する処理を含むことを特徴とする請求項10記載のテスト支援方法。
  13. 前記外部仕様に記述されたパラメータの不足情報を抽出し、前記表示部に、パラメータごとにパラメータの不足情報を強調表示する画面を表示し、前記分析済みパラメータ情報の補完入力を受け付ける処理は、
    前記外部仕様に記述されたパラメータが複数の項目からなる配列であり、配列のデータが可変である場合に、配列の長さを入力するためのパラメータを追加する処理と、
    前記外部仕様に記述されたパラメータのパターン情報に、テスト実行に必要な情報が不足しているパターン情報を抽出する処理を含むことを特徴とする請求項9記載のテスト支援方法。
  14. 前記記憶部は、さらに、前記テストケースに記載された前記パラメータ値を定めた組合せに基づいて、生成されるテスト実行可能な具体値を格納したテスト実行のためのテストデータと、前記テストデータによるテスト実行結果を記憶し、
    前記テストケースからテストデータを生成するステップと、
    前記テストデータを用いてテスト実行を行い、その実行結果を収集するステップとを有することを特徴とする請求項8記載のテスト支援方法。
JP2016113577A 2016-06-07 2016-06-07 テスト支援装置、および、テスト支援方法 Active JP6568017B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2016113577A JP6568017B2 (ja) 2016-06-07 2016-06-07 テスト支援装置、および、テスト支援方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2016113577A JP6568017B2 (ja) 2016-06-07 2016-06-07 テスト支援装置、および、テスト支援方法

Publications (2)

Publication Number Publication Date
JP2017220008A JP2017220008A (ja) 2017-12-14
JP6568017B2 true JP6568017B2 (ja) 2019-08-28

Family

ID=60656481

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016113577A Active JP6568017B2 (ja) 2016-06-07 2016-06-07 テスト支援装置、および、テスト支援方法

Country Status (1)

Country Link
JP (1) JP6568017B2 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110083537B (zh) * 2019-04-26 2023-08-18 广东天舜信息科技有限公司 手机app端口测试的方法及系统
CN111506305B (zh) * 2020-03-26 2023-07-18 拉扎斯网络科技(上海)有限公司 工具包生成方法、装置、计算机设备及可读存储介质
CN114416458B (zh) * 2022-03-30 2022-08-05 航天中认软件测评科技(北京)有限责任公司 测试方法、装置、设备及存储介质
CN116932403A (zh) * 2023-07-25 2023-10-24 太初(无锡)电子科技有限公司 测试用例的生成方法

Also Published As

Publication number Publication date
JP2017220008A (ja) 2017-12-14

Similar Documents

Publication Publication Date Title
US6421822B1 (en) Graphical user interface for developing test cases using a test object library
US6332211B1 (en) System and method for developing test cases using a test object library
US7721252B2 (en) Apparatus and method for product-line architecture description and verification
US7979841B2 (en) Programmatically determining calling information of a graphical program
US8589884B2 (en) Method and system for identifying regression test cases for a software
JP6568017B2 (ja) テスト支援装置、および、テスト支援方法
US20050144529A1 (en) Method for defined derivation of software tests from use cases
EP3023876A1 (en) Quality assurance tools for use with source code and a semantic model
CN104090776A (zh) 一种软件开发方法及系统
US20140208431A1 (en) Automated tools for building secure software programs
JPWO2012057170A1 (ja) ソースコード変換方法およびソースコード変換プログラム
JP2009265810A (ja) 状態遷移テスト支援装置、状態遷移テスト支援プログラム、および状態遷移テスト支援方法
Campos et al. A more intelligent test case generation approach through task models manipulation
CN104657274A (zh) 软件界面测试方法及装置
Felderer et al. Using defect taxonomies for requirements validation in industrial projects
CN111813409A (zh) 一种交互界面的代码生成方法、装置、设备及存储介质
Tierno et al. Open issues for the automotive software testing
Kumar et al. Conceptualizing “COBieEvaluator” A rule based system for tracking asset changes using COBie datasheets
Dumas et al. Robotic Process Mining.
KR20220073151A (ko) 고장형태 영향분석 기반 고장 분석의 고장 모드 추천 시스템
Wojszczyk et al. The process of verifying the implementation of design patterns—used data models
JP2002014845A (ja) テスト・スクリプト部品の自動生成方法および装置
Srivastava et al. Cause effect graph to decision table generation
US20080195453A1 (en) Organisational Representational System
JP5657183B2 (ja) 第1のコンピュータ・プログラムが第2のコンピュータ・プログラムのアプリケーション・ロジックを実行することを可能にするための方法および装置、第1のコンピュータ・プログラムと第2のコンピュータ・プログラムとのインターフェースをとるためのコンピュータ・プログラム・コードを生成するための方法および装置、コンピュータ・プログラム、ならびに第1のコンピュータ・プログラムが第2のコンピュータ・プログラムのアプリケーション・ロジックを実行することを可能にするためのソフトウェア・インターフェースを提供するための方法(コンピュータ・プログラム・インターフェース)

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20181002

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20190626

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: 20190709

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190801

R150 Certificate of patent or registration of utility model

Ref document number: 6568017

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150