ソフトウェアに対する複数のテスト仕様であって、少なくともテストの目的及び前記ソフトウェア内でテストを実行すべきテスト対象を記述したテスト仕様を記憶する第1の記憶部と、前記第1の記憶部から、任意の2つのテスト仕様を抽出してモニタに表示させ、当該テスト仕様間の関係を指示する指示データを受け取る手段と、前記指示データを記憶する第2の記憶部と、前記テスト仕様を代表する図形と前記指示データに応じたテスト仕様間の関係を示す図形とを含む、前記テスト仕様全体を表す構成図を作成する作成部と、を備える、テスト仕様作成支援装置。前記テスト仕様間の関係は、第1のテスト仕様と第2のテスト仕様との間の部分的な包含関係である包含仮関係、又は第1のテスト仕様と第2のテスト仕様との間の類似関係を含み、少なくとも前記テスト対象の論理構造の大きさを分類するための第1軸とテストの観点に沿って前記テスト仕様を分類するための少なくとも1つの第2軸とで表現される2次元空間における前記2つのテスト仕様のそれぞれの位置の関係に基づいて、前記包含仮関係又は前記類似関係を包含関係に変換する変換部をさらに備える、請求項1記載の装置。ソフトウェアに対する複数のテスト仕様であって、少なくともテストの目的及び前記ソフトウェア内でテストを実行すべきテスト対象を記述したテスト仕様を記憶する第1の記憶部と、少なくとも前記テスト対象の論理構造の大きさを分類するための第1軸とテストの観点に沿って前記テスト仕様を分類するための少なくとも1つの第2軸とで表現される2次元空間における前記テスト仕様の位置を示す指示データを受け取る手段と、前記指示データをそれぞれの前記テスト仕様に関連付けて記憶する第2の記憶部と、前記2次元空間における前記指示データに応じた位置に各テスト仕様を代表する図形を配置することにより構成図を作成する作成部と、を備える、テスト仕様作成支援装置。ソフトウェアに対する複数のテスト仕様であって、少なくともテストの目的及び前記ソフトウェア内でテストを実行すべきテスト対象を記述したテスト仕様を第1の記憶部に記憶するステップと、前記第1の記憶部から、任意の2つのテスト仕様を抽出してモニタに表示させ、当該テスト仕様間の関係を指示する指示データを受け取るステップと、前記指示データを第2の記憶部に記憶するステップと、前記テスト仕様を代表する図形と前記指示データに応じたテスト仕様間の関係を示す図形とを含む、前記テスト仕様全体を表す構成図を作成するステップと、を備える、テスト仕様作成支援方法。ソフトウェアに対する複数のテスト仕様であって、少なくともテストの目的及び前記ソフトウェア内でテストを実行すべきテスト対象を記述したテスト仕様を第1の記憶部に記憶するステップと、少なくとも前記テスト対象の論理構造の大きさを分類するための第1軸とテストの観点に沿って前記テスト仕様を分類するための少なくとも1つの第2軸とで表現される2次元空間における前記テスト仕様の位置を示す指示データを受け取るステップと、前記指示データをそれぞれの前記テスト仕様に関連付けて第2の記憶部に記憶するステップと、前記2次元空間における前記指示データに応じた位置に各テスト仕様を代表する図形を配置することにより構成図を作成するステップと、を備える、テスト仕様作成支援方法。コンピュータを、ソフトウェアに対する複数のテスト仕様であって、少なくともテストの目的及び前記ソフトウェア内でテストを実行すべきテスト対象を記述したテスト仕様を記憶する第1の記憶部、前記第1の記憶部から、任意の2つのテスト仕様を抽出してモニタに表示させ、当該テスト仕様間の関係を指示する指示データを受け取る手段、前記指示データを記憶する第2の記憶部、前記テスト仕様を代表する図形と前記指示データに応じたテスト仕様間の関係を示す図形とを含む、前記テスト仕様全体を表す構成図を作成する作成部、として機能させるためのテスト仕様作成支援プログラム。コンピュータを、ソフトウェアに対する複数のテスト仕様であって、少なくともテストの目的及び前記ソフトウェア内でテストを実行すべきテスト対象を記述したテスト仕様を記憶する第1の記憶部、少なくとも前記テスト対象の論理構造の大きさを分類するための第1軸とテストの観点に沿って前記テスト仕様を分類するための少なくとも1つの第2軸とで表現される2次元空間における前記テスト仕様の位置を示す指示データを受け取る手段、前記指示データをそれぞれの前記テスト仕様に関連付けて記憶する第2の記憶部、前記2次元空間における前記指示データに応じた位置に各テスト仕様を代表する図形を配置することにより構成図を作成する作成部、として機能させるためのテスト仕様作成支援プログラム。テストの抜けに気づかず不具合が見逃されることを防ぎ、同じテストが何度も実施される無駄を省く等のために、テスト仕様を最適化することが必要である。従って、個々のテスト仕様間の関係性を可視化し、テストの全体像を把握しながらテスト仕様の作成編集を行えるよう支援を行うテスト仕様作成支援装置、方法及びプログラムの提供が望まれている。実施形態によれば、ソフトウェアに対する複数のテスト仕様であって、少なくともテストの目的及び前記ソフトウェア内でテストを実行すべきテスト対象を記述したテスト仕様を記憶する第1の記憶部と、前記第1の記憶部から、任意の2つのテスト仕様を抽出してモニタに表示させ、当該テスト仕様間の関係を指示する指示データを受け取る手段と、前記指示データを記憶する第2の記憶部と、前記テスト仕様を代表する図形と前記指示データに応じたテスト仕様間の関係を示す図形とを含む、前記テスト仕様全体を表す構成図を作成する作成部と、を備える、テスト仕様作成支援装置が提供される。本発明の実施形態は、図1に示すソフトウェアの設計開発、テスト設計及び実施の各工程において、特に、テストに関係する上流工程1テスト戦略、テストアーキテクチャ等を強化するテスト設計手法に関する。実施形態に係るテスト仕様作成支援装置は、レイヤティア図以下LTMap及びテスト仕様関連図以下TRMapを作成して表示する。テスト設計に関与するユーザーが主に本装置を利用し、LTMap及びTRMapに基づいてテスト仕様の作成等を行う。図2において、参照符号2によって示すLTMapは、テスト仕様の位置づけをソフトウェアの論理構造の縦軸とテストの観点の横軸の2軸で表現した図である。また、図3において、参照符号3によって示すTRMapは、テスト仕様間の関係を包含関係のネットワークで表現した図である。図2のようなLTMapは、テスト仕様のばらつきやギャップ漏れを見るトップダウンアプローチに有用であり、図3のようなTRMapは、重複や粒度を見てテスト仕様を整理するボトムアップアプローチに有用である。実施形態の詳細な説明の前に、本明細書で用いる用語について説明する。テストとは、開発したソフトウェアプログラムが、分析した要求に対応する仕様や考案した設計の通りに作られたかどうかを、当該プログラムすなわちソフトウェア内においてテストを実行すべきテスト対象のプログラムを動作させて確認することをいう。テスト設計とは、テスト対象のプログラムのどのような動作確認が必要かを予め決定し用意しておくことをいう。複数のテストケースをそれぞれ設計し、すべてが合格することを期待する。なお、テストケースなる用語は、テスト仕様やテスト項目のいずれかを指すものとする。図4に、テスト仕様とテスト項目の関係を示す。テスト仕様参照符号4によって示すとは、テスト対象のプログラムをどのように動作させ確認するかを抽象的に記述したものをいう。一つのテスト仕様は、テストの目的、テストの対象範囲、テストの手順を要素として持つ。テスト仕様に基づいて、複数のテスト項目が抽出される。テストの目的とは、そのテストで何を確認するのかを定義したものをいう。テストの目的は、テスト対象の位置づけの属性値と、テストの観点の位置づけの属性値を持つことが必須である。テスト項目参照符号5によって示すとは、テスト仕様の数値、手順を具体化して記述したものをいう。テストを実施するための設定条件、作業手順、確認事項及び期待値などを要素として持つ。例えば図4のように、あるテスト仕様について複数のテスト項目A~Cがあり、テストAはXを100にするとZが20になるという具体化されたテスト項目の要素を持ち、テストBはXを500にするとZが40になるという具体化されたテスト項目の要素を持つ。図5を参照してテストの構造の可視化について説明する。まず前提として、図5に示すように、テストの構成要素であるテスト項目52は、抽象化されたテスト仕様51から導き出され、具体化されるものである。テスト仕様51は、必ずテストの目的を含まなければならない。テストの目的は、テスト対象の位置づけの属性とテストの観点の位置づけの属性を持つ。テスト対象は、テスト対象のプログラム50のことである。ここで、テストの構造を可視化するとはテストの目的の位置づけの2属性に基づいて、テストの位置関係を表現する、あるいは接続関係を表現することをいう。本実施形態では、このようなテスト構造の可視化をLTMap又はTRMapによって行う。図6に示すように、テスト仕様62は、テストの目的を決める段階と、テストの対象範囲入出力及び手順を決める段階とを経て作成される。前者の段階すなわちテストの目的を決める段階では、LTMap60又はTRMap61が利用される。後者の段階では、テスト仕様62に基づいて複数のテスト項目63が作成され、これらに基づいてテストが実施されることになる。本実施形態に係るテスト仕様作成支援装置は、テスト仕様を作成する前者の段階を支援する。図7は、実施形態に係るテスト仕様作成支援装置を示すブロック図である。同図に示すように、テスト仕様作成支援装置71は、LTMap作成部74、TRMap作成部75、ユーザインタフェース76、第1の記憶部77及び第2の記憶部78を有する。また本装置71には、マウス/キーボード72及びモニタ73が接続されている。第1の記憶部77は、LTMap又はTRMapに配置されるテスト仕様を記憶する。テスト仕様はソフトウェアに対するものであって、少なくともテストの目的及びソフトウェア内でテストを実行すべきテスト対象を記述したものである。LTMap作成部74は、少なくともテスト対象の論理構造の大きさを分類するための第1軸とテストの観点に沿って各テスト仕様を分類するための少なくとも1つの第2軸とで表現される2次元空間に対して、各軸上での前記テスト仕様の位置を示す指示データを受け取り、該指示データに基づいてLTMap構成図を作成する。指示データは、第2の記憶部78によって記憶される。TRMap作成部75は、テスト仕様を代表する図形と指示データに応じたテスト仕様間の関係を示す図形とを含む、テスト仕様全体を表わす構成図を作成する。TRMap作成部75による処理については後述する。ユーザインタフェース76は、LTMap作成部74及びRMap作成部75と、マウス/キーボード72及びモニタ73を介したユーザーとの間をインターフェースする例えばGUIである。マウス/キーボード72及びモニタ73の代わりにタッチパネル式の入出力装置を用いてもよい。テスト仕様作成を行うユーザーは、マウス/キーボード72を操作することにより、本装置71に対して指示データを与えることができる。モニタ73は、本装置71により作成されたLTMap又はTRMapを表示する。なお本実施形態に係る装置は、コンピュータプログラムによって実現することができる。この場合、コンピュータを、テスト仕様作成支援装置として機能させるためのプログラムが、コンピュータ読み取り可能な記録媒体からメモリ等の記憶手段に読み出され、CPUにより実行される。またテスト仕様作成支援装置71は構成管理システム70に接続されており、LTMap及びTRMapの作成ならびにテスト仕様の作成を、構成管理システム70から提供されるソフトウェアプログラム及び設計情報等に基づいて行うことができる。図8は、構成管理システムを示す図である。本実施形態において扱うテスト仕様は、テスト対象に依存する。テスト対象は、例えばソフトウェアプログラム80である。ソフトウェアプログラム80は構造化され、モジュールという形でそれぞれ独立したファイルに分割されている。ファイルには処理関数がいくつか含まれている。構成管理システム83は、開発された最新のソフトウェアプログラム80を一箇所に集約して管理する。構成管理システム83には、ソフトウェアプログラム80の他にも、要求仕様書81や設計書82などの設計文書の成果物も格納することができる。ユーザーは、指定バージョンについて、構成管理システム83から成果物を検索することができる。図9はテスト環境を示す図である。テストを実施する場合、テスト対象としてのソフトウェアプログラムの全体又はその一部91が構成管理システム90から取り出される。テストの目的に応じて、テスト対象から取り出される部分91は異なる。部分91は、例えば関数やモジュールファイルなどであり、テスト環境例えばデバッガ92に組み込んで動作させ、テストが行われる。テストの実行はテストプログラム93によって制御される。テスト対象は、テスト仕様毎に必要な部分が違うので、テスト対象の大きさはテスト仕様毎に異なる。例えば行数をテスト対象の大きさとする場合、関数Aと関数Xと関数Cの組合せに関するテストにおいて、テスト対象の大きさは、関数Aの行数関数Xの行数関数Cの行数である。関数B単独のテストでは、関数Bの行数がテスト対象の大きさとなる。構成管理システムから取り出したテスト対象を評価して決定する本実施形態において、後述するLTMapの対象軸の値は、テスト対象の大きさに依存して、区分されたいずれかの値に決定される。図10は、LTMapに基づくテスト仕様作成編集の概念を示す図である。ユーザーは、テスト仕様について、その対象が何であるか、確認したいことは何であるかを決定する。これは、テストの目的を決めることに相当する。この作業をLTMap102を利用して行うことができる。LTMap102は、図7に示したLTMap作成部74によって作成され、モニタ73により表示される。LTMap102は、レイヤ軸及びティア軸の少なくとも2つの軸から構成される。LTMap102は、レイヤ軸の種類及びレイヤ軸の目盛分割の仕方100と、ティア軸の種類及びティア軸の目盛分割の仕方101とによって規定される。レイヤ軸の目盛については、テスト対象を評価することによりその属性値を決める。一方、ティア軸の目盛については、離散的な値についてすべての組合せを洗い出す。連続値ならば、同値分割して離散化してもよい。ユーザーは、表示されたLTMap102に基づいて、テスト仕様の作成編集を行う。これにより、追加されるテスト仕様103、変更されるテスト仕様104、削除されるテスト仕様105が発生する。最終的なテスト仕様は、責務が明確なものとなり、Whyなぜそのテストが必要か、What何を確認するテストかを特定することができる。また、設計情報を加味することで、Howどのようにテストを実施するかも特定することが可能である。図11は、LTMapに基づくテスト仕様編集の具体的手順を示すフローチャートである。ユーザーは、テスト仕様作成支援装置を通じて、テスト仕様洗い出しステップS1と、軸の決定及び値の分割ステップS2とを行う。このために利用可能な情報が予め構成管理システム等からテスト仕様作成支援装置に与えられ、仕様書や設計書を参照して意思決定できることが好ましい。また、ステップS1において複数のテスト仕様が作成されると、これらは図7の第1の記憶部77に格納される。次に、テスト仕様作成支援装置は、第1の記憶部77からテスト仕様のデータを一つ取りだすステップS3。次に、このテスト仕様について、テスト対象の位置づけを決定するステップS5。これは、LTMapにおける第1軸の値を決定することに相当する。第1軸は、テスト対象の論理構造の大きさを分類するものである。第1軸の値は、ユーザーが図7のマウス/キーボード72等を操作し、ユーザインタフェース76を通じてLTMap作成部74に与える指示データとしても良いし、構成管理システム等からLTMap作成部74が取得してもよい。テスト対象の位置づけの値第1軸の値が決まったら、テストの観点の軸の値を決めるステップS6。これは、LTMapにおける第2軸の値を決定することに相当し、ユーザーが図7のマウス/キーボード72等を操作し、ユーザインタフェース76を通じてLTMap作成部74に指示データとして与える。ステップS5及びS6によって、当該テスト仕様について、テストの目的が持つ、テスト対象の位置づけの属性値とテストの観点の属性値とが決まる。次にLTMap作成部74は、上記第1軸及び第2軸により規定されるLTMapを作図し、上記第1軸及び第2軸の値に従って当該テスト仕様を代表する図形アイコン、サムネイル等をLTMap上に配置することによりLTMapの表示データを生成する。LTMapの表示データに従ってモニタ73にはLTMapが表示されるLTMapの可視化:ステップS7。ステップS3以下の処理が繰り返されることにより、複数のテスト仕様がLTMap上に配置され、表示される。これにより、テスト仕様の重複や欠損漏れがLTMapの表示上で明らかとなるステップS8。ユーザーは、このようなテスト仕様の重複や欠損を修正すべきであると判断し、その旨をLTMap作成部74に指示するステップS9。これに応じて、LTMap作成部74は、テスト仕様の追加、削除、変更等の編集を可とするステップS10。ユーザーによる編集作業のための機能は、ユーザインタフェース76により実現される。なお、テスト仕様の重複や欠損に対する修正が完了し、最後のテスト仕様のデータまで処理されたら、LTMap構成図の最終結果を出力して処理を終了する。以上説明したLTMapの作成及び編集に関して、本実施形態に係るテスト仕様作成支援装置71は、2つ以上の評価軸第1軸及び第2軸を組み合わせたLTMap上にテスト仕様を配置することで、テストの目的の位置づけを示すことができる。また、LTMap上に複数のテスト仕様を配置されることで、テスト仕様間の違い目的の属性の違いを明示することができる。なお、LTMapは、2軸のみならず、3軸や4軸で表現しても良い。評価軸には、テスト対象の構造を表す軸レイヤ軸とテストの観点を表す軸ティア軸を必ず含むものとする。テスト対象の構造を表す軸の値はテスト対象のプログラムを評価することによって取得してもよい。複数の評価軸によってテストの目的の位置づけを示す複数のLTMapを生成し、これらを任意に組み合わせたり、ある評価軸を固定し、他の軸と組み合わせたりするなど、LTMapの表示態様は種々変形してもよい。また、評価軸の目盛の値を離散化し、分割した座標を用いることで位置づけを表現してもよい。また、テスト仕様の抜けを補完するように、テスト目的の適切な属性値を持つテスト仕様を自動的に生成してもよい。さらに、評価軸の分割の態様を変更する例えば軸の分割を追加し、変更し、あるいは削除することにより、テスト仕様の位置づけを変更できるようにすることが好ましい。以下、LTMapの作成及び編集に関して、より具体的な実施例を説明する。ここでは、エレベータの制御プログラムを対象にする場合を例に挙げる。図12は、LTMapの作成及び編集の具体的な実施例に係るエレベータの制御プログラムを説明するための図である。例えば次のようにテスト仕様を洗い出した。テスト仕様A:各階にある上下ボタン120の押下に応じてボタンが点灯し、リフトが到着する。テスト仕様B:リフトの中にあるフロアボタン122の押下に応じてボタンが点灯し、指定された階にリフトが移動する。テスト仕様C:リフトが到着すると、各階のドア上部にある上下ランプ121が点滅し、ドアが開くと消灯する。テスト仕様D:ボタンの要求に応じてリフトの移動方向と停止階を決定する。テスト仕様E:非常停止ボタンが押されると最寄り階に停止し、ドアが開く。評価軸は、例えば次のように定めた。レイヤ軸1:テスト対象の粒度、ティア軸1:要求仕様のサイズ、ティア軸2:リスクの大きさ各軸の値域を次のように分類した。レイヤ軸1:関数/クラス/モジュール/システム、ティア軸1:ロジックアルゴリズム/機能仕様/ソフトウェア要求仕様、ティア軸2:小/大/致命的システムテスト仕様作成支援装置は、構成管理システムからの情報に基づき、テスト仕様の対象の位置づけを以下のように評価した。即ち、各テスト仕様のLTMapにおける第1軸の値を決定した。テスト仕様A:テスト対象は上下ボタン120である。当該テスト対象のプログラムを分析することにより、関数レベルのテスト仕様であるという位置づけとする。テスト仕様BC:フロアボタン122及び上下ランプ121も同様に、関数レベルに位置づけられる。テスト仕様D:テスト対象はリフトのスケジューラであり、操作前の状態と入力された要求を加味して判断するシステム全体に関わるテスト仕様である。テスト仕様E:操作の対象は非常停止ボタンであるが、テストの目的は非常停止処理であることから、非常停止処理について、システム全体に関わるテスト仕様である。次に、テストの観点要求仕様のサイズの位置づけをユーザーが以下のように判断してシステムに与えた。即ち、各テスト仕様のLTMapにおける第2軸の値を決定した。テスト仕様A:上下ボタン120を押された場合、スケジューラに要求を出し、ボタンを点灯する、というテストは機能仕様レベルという位置づけである。テスト仕様BC:フロアボタン122及び上下ランプ121も同様に、機能仕様レベルである。テスト仕様D:スケジューラは全体の動きを決めるソフトウェア要求仕様に関わるものである。テスト仕様E:非常停止処理も同様に、ソフトウェア要求仕様に関わるものという位置づけである。以上のようなテスト対象の位置づけとテストの観点の位置づけに従って、システムが図13に示すような表形式の内部データを作成した。これは、第2の記憶部78に記憶されるものである。システムは、上記内部データに従って図14に示すような2次元空間のLTMapを表示することができる。同図に示されるLTMapにおいて、縦軸第1軸は、テスト対象の粒度を表す。これは、システム、モジュール、クラス、関数という属性値を持つ。一方、横軸第2軸は、要求仕様のサイズを表す。これは、ロジック又はアルゴリズム、機能仕様、ソフトウェア要求仕様という属性値を持つ。第3軸として、さらに別のテストの観点リスクの大きさをシステムに与える場合について説明する。更なるテストの観点として、リスクの大きさの位置づけをユーザーが以下のように判断してシステムに与えた。即ち、各テスト仕様のLTMapにおける第3軸の値を決定した。テスト仕様A:上下ボタン120が押された場合に、システムが誤動作するとリフトが到着しないなど、移動したい要求を実現できないので、リスクは大と位置づける。テスト仕様Bのフロアボタン122についても同様とする。テスト仕様C:上下ランプ121は点灯しなくても要求を実現することは可能なので、リスクは小と位置づける。テスト仕様D:スケジューラが誤動作すると、移動したい要求を実現できないので、リスクは大と位置づける。テスト仕様E:非常停止処理が誤動作すると、使用者の生命に危険が及ぼされるので、リスクは致命的と位置づける。テスト対象の位置づけとテストの観点の位置づけに従って、システムは表形式の内部データを持つ以上のようなテスト対象の位置づけとテストの観点の位置づけに従って、システムは図15に示すような表形式の内部データを作成した。これは、第2の記憶部78に記憶される。システムは、上記内部データに従って図16に示すような2次元空間のLTMapを表示することができる。同図に示されるLTMapにおいて、縦軸第1軸は、図14の場合と同じくテスト対象の粒度を表す。一方、横軸は、リスクの大きさを表す第3軸とする。リスクの大きさは、小、大、致命的という3つの値に分類される。ここで、テスト仕様の重複排除について説明する。図17及び図18に示すように、テスト仕様A及びB170、即ち上下ボタン及びフロアボタンは、2つの図でどちらも同じポジションにあって重複していることが分かる。これら重複している2つテスト仕様170を一つにまとめて要求ボタンのテスト仕様171とし、同じポジションに配置することができる。なお、図17は、テスト対象の粒度第1軸と要求仕様のサイズ第2軸を組み合わせた場合のLTMapであり、図18は、テスト対象の粒度第1軸とリスクの大きさ第3軸を組み合わせた場合のLTMapである。次に、テスト仕様の抜けを補完することについて説明する。図19から分かるように、テスト対象の粒度がクラスであるテスト仕様が存在しないモジュールについても同様。この場合、例えばリフト制御を対象とする、クラスレベルのテスト仕様190を追加することができる。テスト対象となるリフト制御というクラスは、例えば、リフトを上方向又は下方向に移動させるものであり、指定階に近づいたら減速し、指定階に到着したら停止し、ドアを開くというものである。なお、図19において、テスト仕様Dについて、リフトの移動とは、リフトの停止階と移動方向を決めるのみとし、実際のリフトの移動の確認は要しないこととしている。システムは、新たに追加したリフト制御というテスト仕様190について、テスト対象として複数の関数を対象とするクラスレベルの位置づけであることを判定するユーザーは、この判定結果が正しいことを確認する。またユーザーは、新たに追加したリフト制御というテスト仕様190が、要求仕様のサイズではロジック又はアルゴリズムのレベルであることを判断し、そのように位置づける。また、図20から分かるように、ユーザーは、同テスト仕様190が、リスクの大きさという観点において致命的に位置づけられると判断する。リフトの制御が誤動作すると人命が危機にさらされる可能性が高くなるからである。次に、テスト対象の構造を表す軸とテストの観点を表す軸について、その種類及び分類軸の分割の例を幾つか説明する。テスト対象の構造を表す軸として、ソフトウェアの構造上の粒度、処理モジュールのリスト、コードの規模、ハードウェアとの距離、並行度合いなどを用いてもよい。ソフトウェアの構造上の粒度は、例えば関数/モジュール/コンポーネント/システムに分類することができる。処理モジュールのリストは、例えば上下ボタン/フロアボタン/上下ランプ/非常停止ボタン/リフト/スケジューラに分類することができる。コードの規模は、例えば10行程度/100行程度/1000行程度に分類することができる。ハードウェアとの距離は、例えば直接操作/依存関係がある/独立と見なせるに分類することができる。並行度合いは、例えば並行に動作する/シーケンシャルに動作するに分類することができる。テストの観点を表す軸として、テスト工程、テストの実行環境、リスクの大きさ、ライフサイクルの長さ、開発者の経験、新規開発量などを用いてもよい。テスト工程は、例えば単体テスト/結合テスト/総合テストに分類することができる。テストの実行環境は、例えばデバッガIDE/シミュレータISS/実基板フルICE/実機に分類することができる。リスクの大きさは、例えば低/高/致命的に分類することができる。ライフサイクルの長さは、例えば今回のみ/変更しながら使う/使い回すに分類することができる。開発者の経験は、例えば浅い/中堅/ベテランに分類することができる。新規開発量は、例えば流用/変更/新規に分類することができる。次に、軸の組合せを変化させて提示し、新たなテスト仕様の追加を促すことについて説明する。図21に示すLTMapは、横軸をリスクの大きさ既存の軸とし、縦軸を要求仕様のサイズ既存の軸としたものである。各テスト仕様の属性の値は既に決定されているため、表示をするのみである。このように軸の組合せを変化させることによって、テスト仕様が存在しないポジションが明らかになる場合がある。このような表示に基づいて、適切なポジションにテスト仕様を追加することができる。図21の例では、乗客がエレベータの扉に挟まったらドアを開くという、機能仕様×致命的リスクレベルのテスト仕様210を追加した場合を示している。この場合、システムは、ドアの制御なのでテスト対象の粒度は関数レベルであると判定するものの、図21のLTMapの表示において、この情報は利用されない。ユーザーは、追加に係るテスト仕様210について、要求仕様のサイズを機能仕様レベルに位置づけるとともに、リスクを致命的レベルに位置づけている。次に、LTMapにおける軸の値の分割方法を修正する例について説明する。修正前の2種類のLTMapを図22及び図23に示す。ここで、図23に対応するテストの観点の一つであるリスクの大きさの軸の値の取り方を、ユーザーからの指示に応じて小/大/致命的から小/中/大/致命的に修正してもよい。軸の値の取り方を修正した結果を図24に示す。システムは横軸の中の値の領域240を作成するが、テスト仕様は新たに追加された属性を持っているものがないので、該当なしの状態である。LTMapにおける軸の値の分割方法の修正に伴い、ユーザーは、既存のテスト仕様について、リスクの大きさを軸の修正により追加された中とするのが適切なテスト仕様を見極める。例えば、図25に示すように、上下ボタンというテスト仕様Aは、リフトに乗る以前の操作に関するものであり、リフトに乗った後のフロアボタンの機能不全によるダメージよりはリスクが軽いと判断し、中に変更する参照符号250によって示す。この場合の、LTMap上でのテスト仕様の配置変更を図26に示す。同図から分かるように、テスト仕様Aは、当初はリスクの大きさが大に位置づけていたが、これをリスクの大きさ中のレベルに配置変更する参照符号260によって示す。なお、LTMapにおける軸の値の分割数は変わらず、値そのものを修正する場合には、図27に示すように、内部テーブルにおけるテスト仕様の属性値を付け直せばよい。これは、リスクの大きさを当初は小/中/大/致命的としていたものを低/中/高/致命的に修正した場合に相当する参照符号270によって示す。以上の説明は、LTMap作成部74による処理に関するものであった。以下では、TRMap作成部75による処理について説明する。図28は、TRMapに基づくテスト仕様作成編集の概念を示す図である。図10を参照して説明したように、ユーザーは、テスト仕様について、その対象が何であるか、確認したいことは何であるかを決定する。これは、テストの目的を決めることに相当する。この作業は、主にLTMapを利用して行われる。これに対しTRMapは、重複や粒度を見てテスト仕様を整理するボトムアップアプローチに有用である。TRMapは、図7に示したTRMap作成部75によって作成され、モニタ73により表示される。TRMapは、テスト仕様間の関係を表す。これには、図28に示すように包含関係、包含仮関係、類似関係がある。ユーザーは、表示されたTRMapをもとにテスト仕様の整理を行う。これにより、追加されるテスト仕様352、変更されるテスト仕様353、削除されるテスト仕様354が発生し得る。図29は、TRMapに基づくテスト仕様編集の具体的手順を示すフローチャートである。ユーザーは、テスト仕様作成支援装置を通じて、テスト仕様洗い出しを行うステップS1。このために利用可能な情報要求仕様書や設計書、過去に作成したテスト仕様等が予め構成管理システム等からテスト仕様作成支援装置に与えられ、ユーザーに示されることが好ましい。また、ステップS1において複数のテスト仕様が作成されると、これらは図7の第1の記憶部77に格納される。次に、テスト仕様作成支援装置は、第1の記憶部77からテスト仕様のデータを2つ取りだすステップS2。次に、これらテスト仕様間の関係を決定するステップS5。この処理は、ユーザーが図7のマウス/キーボード72等を操作し、ユーザインタフェース76を通じてTRMap作成部75に与える指示データとしても良いし、構成管理システム等からTRMap作成部75が取得してもよい。2つのテスト仕様間の関係が決まると、TRMap作成部75は、当該2つのテスト仕様のそれぞれを代表する図形アイコン、サムネイル等をTRMap上に配置し、決定された関係を示す図形によって両者を結びつけてTRMapの表示データを生成する。このTRMapの表示データに従ってモニタ73にはTRMap構成図が表示されるステップS5。テスト仕様間の関係が十分に決定されるまで、ステップS1~S6の処理が繰り返される。図30は、テスト仕様間の関係の検証部及び変換部を備えるTRMap作成部を示すブロック図である。TRMap作成部75は、2つのテスト仕様間における包含関係の有無を定めることによってテスト仕様の構造を可視化する。検証部750は、TRMapが表すテスト仕様間の関係が適切なものであるかどうかをLTMapのデータに基づいて検証する。検証部750は、包含関係の正しさを、テスト仕様を特徴づけるすべての、あるいは予め定められた割合以上の属性の軸の大小によって判断してもよい。変換部751は、TRMapにおいてユーザーにより類似関係又は包含仮関係として設定されたテスト仕様間の関係を包含関係に変換する。図31は、変換部751による変換処理を含んだ処理の手順を示すフローチャートである。テスト仕様間の関係を決定し、両者の関係をTRMapとして表示するまでのステップS1乃至S6の処理は、図29に示したものと同様である。図31に示す処理では、変換部751による変換処理を行うためにステップS7においてLTMapが作成されることが必要である。ステップS8及びS9において、変換部751は、TRMapにおけるテスト仕様間の類似関係を包含関係に変換する。次に、ステップS10及びS11において、変換部751は、TRMapにおけるテスト仕様間の包含仮関係を包含関係に変換する。変換を終えた最終的なTRMapは、モニタ73により表示される。包含関係は、テストの親子関係を表し、親テストとすべての子テストの集合が等価であり、親テストは子テストに分割可能であることを表す。これに対し包含仮関係は、2つのテスト仕様間における部分的な包含を示す。包含仮関係の正しさについて、検証部750はテスト仕様を特徴づける一部の軸の値の大小に基づいて検証を行ってもよい。類似関係は、2つのテスト仕様に相関がある場合に、両者の間に定める。類似関係をLTMapに反映する場合には、類似関係を、テスト仕様を特徴づけるある特定の1つの軸の同じ値として表現すればよい。変換部751は、テストの属性を表す軸の目盛りの振り方、あるいは値を変更をすることによって、包含仮関係を包含関係に変換してもよい。また変換部751は、共通の値をもった軸を新たに作成すること、あるいは軸の目盛りの振り方を変更することによって、類似関係を包含関係に変換してもよい。さらに、変換部751は、共通の包含関係をもつ第三のテスト仕様を追加することによって、類似関係を解消してもよい。次に、TRMapにおいてテスト仕様間の関係を図形によってどのように表現するかを説明する。例えば、図32aに示すようにテスト仕様の包含関係を矢印で表現し、同図bに示すように包含仮関係を先端が三角形の矢印で表現し、同図cに示すようにテスト仕様の類似関係を角丸四角で囲んで表現してもよい。以下、TRMapの作成及び編集に関して、より具体的な実施例を説明する。ここでは、LTMap作成の実施例と同様、エレベータの制御プログラムを対象にする。また、テスト仕様の洗い出しの結果は、LTMap作成の実施例の場合と同様であるとする。2つのテスト仕様の組合せは、AとB、AとC、AとD、AとE、BとC、BとD、BとE、CとD、CとE、DとEの10通りがある。これら組合せを図33に示すような表形式の内部データ構造として持ち、関係性の有無及びその種類を決める。これは、ユーザーから指示データとしてシステムに与えられ、図7の第2の記憶部78に格納される。上記関連性のデータに従い、TRMap作成部75は図34に示すTRMapを作成してモニタ73に表示する。図35に示すように、ユーザーは、TRMapの表示をもとに、テストを分割又は統合する際の過不足を考慮して、テスト仕様の追加、変更、削除を行うことができる。図35の例では、初期化処理、リフト制御、押下認知、ランプ点灯、点灯までの反応時間といった新たなテスト仕様390が追加されている。LTMapのポジションに基づいて包含関係の検証を行うことについて説明する。図33には3つの包含関係があることを示した。即ち、AとD、BとD、CとDである。検証部750は、これらが適切であるかどうかを図22及び図23に示したLTMapに基づいて検証する。まずAとDについて、図22のLTMapによれば、DがAに対して右上に位置し、図23のLTMapによれば、DがAの真上に位置することから、両者の包含関係は正しいと判定する。同様に、BとDについて、図22のLTMapによれば、DがBに対して右上に位置し、図23のLTMapによれば、DがBの真上に位置することから、両者の包含関係は正しいと判定する。CとDについて、図22のLTMapによれば、DがCに対して右上に位置し、図23のLTMapにおいても、DがCの右上に位置することから、両者の包含関係は正しいと判定する。このように、LTMapにおけるテスト仕様の位置関係から、包含関係の有無について判定することができる。なお、軸の値の大小関係によって、どちらのテスト仕様が親であって他方のテスト仕様を包含するかを判定することができる。図36に示すように、テスト仕様DとEは包含仮関係43にある。この包含仮関係は、変換部751により包含関係に変換される。即ち、図36の包含仮関係43は、図23のLTMapリスクの大きさをテストの観点とするにおけるテスト仕様DとEの位置関係EはDよりも軸の値が大きいに基づいて、図37に示す包含関係44に変換される。図36によれば、テスト仕様AとCは類似関係にあり、BとCも類似関係にある。これら類似関係は、両者を包含するテスト仕様を変換部751が追加することにより、包含関係に変換することができる。即ち、図37に示すように、AとCを包含する新たなテスト仕様441要求ボタンを共通の親として作成したり、図38に示すように、BとCを包含する新たなテスト仕様45を結果表示を共通の親として作成することができる。変換部751によれば、テスト仕様間の包含仮関係や類似関係を包含関係に変換することができる。このようなテスト仕様の統廃合を行うことの意義について説明する。テストケースを作成設計する際には、対象のソフトウェアの要求仕様書や設計書を分析して、どのようなテストケースが必要かを洗い出す。テスト対象のソフトウェアが大規模複雑になってきているので、テストケースの洗い出しを見通しよく実施していくことが困難になってきている。そのため、アドホックにとりあえずのテストケースを設計し、後から整理しなおして最適化する、という手順を踏まざるを得ない。アドホックに設計されたテストケースは、他との関連を考慮して作成されてはいない。このため、様々なテストを集めてくると、目的がバラバラであったり、他のテストケースと重複してしまったりする。従来、テストケース間の関係を可視化することができなかったので、人間の頭の中で最適化を図っていかねばならず、困難な状況にあった。そこで、上記実施形態のようにテスト間の関連をTRMapを使って表現することで、アドホックに作成されたテストケース間の目的の不整合や重複を発見し、調整していくことでテストケースを統廃合して最適なテストケースに修正していくことができる。エレベータのテスト設計を行う際のTRMapの変遷を図39乃至図42に例示する。図39は、テスト仕様を洗い出した初期の状態を示す。テスト仕様間の関係が複雑に入りくんだ箇所300矢印が錯綜しているをユーザーが見つけ、図40に示すように新たな包含関係の親テスト311を作成して整理する。このようなテスト仕様の整理中に、矢印が集中しているテスト310をユーザーが発見し、図41に示すように、いくつかに親テスト33を作成して整理する。さらに、左上に統合できるテスト320があるので、図42に示すように、テスト330及びテスト331にまとめ、完成とする。次に、最終的に作成されたテスト仕様の出力について説明する。テスト仕様を出力する際に、定義した属性や関係を利用せずにすべてを独立に出力してもよい。また、指定した軸において指定した値の範囲についてテスト仕様を出力してもよい。これらのテスト仕様は、LTMap上では近接して示される。また、類似関係に基づいてテスト仕様をグループ化して出力してもよい。また、包含関係にある一連のテスト仕様を抽出して出力してもよい。この場合、指定した数の接続先までのテスト仕様をさらに抽出して出力してもよい。以上説明した実施形態によれば、テスト仕様の抜けを補完することによりテスト仕様の網羅性を向上することができる。これによりテストの実施において不具合発見率を向上することができる。テスト仕様の目的が明確になるため、不具合を狙い撃つテスト項目を生成することが可能となり、不具合発見率を向上することができる。テスト仕様間の重複が発見できるため、無駄なテストを削減でき、テスト工程のコストダウンを実現することができる。テスト仕様間の関係性が可視化されるため、テスト仕様の強弱テストを綿密に実施するか、粗く実施するかを決めることができる。テストの全体が把握できるため、何を先にやるか、どんな順序でやるか、といったテストの進め方をコントロールすることができる。本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。