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

Description

本発明の実施形態はテスト仕様の作成を支援する装置、方法及びプログラムに関する。

コンピュータソフトウェアの開発が大規模かつ複雑になった結果、開発された個々のプログラムが要求・設計に照らし合わせて正しいかどうかを確認するテストもまた大規模で複雑なものとなっている。テストの期間も長期化の傾向にあり、テストの実施に関わる人のスキルもさまざまである。

特開２００９−２６６０４５号公報 特開２００７−２９９１５５号公報 特開２００６−３５０８５１号公報 特開２００３−３３７９３３号公報

テストの抜けに気づかず不具合が見逃されることを防ぎ、同じテストが何度も実施される無駄を省く等のために、テスト仕様を最適化することが必要である。従って、個々のテスト仕様間の関係性を可視化し、テストの全体像を把握しながらテスト仕様の作成編集を行えるよう支援を行うテスト仕様作成支援装置、方法及びプログラムの提供が望まれている。

実施形態によれば、ソフトウェアに対する複数のテスト仕様であって、少なくともテストの目的及び前記ソフトウェア内でテストを実行すべきテスト対象を記述したテスト仕様を記憶する第１の記憶部と、前記第１の記憶部から、任意の２つのテスト仕様を抽出してモニタに表示させ、当該テスト仕様間の関係を指示する指示データを受け取る手段と、前記指示データを記憶する第２の記憶部と、前記テスト仕様を代表する図形と前記指示データに応じたテスト仕様間の関係を示す図形とを含む、前記テスト仕様全体を表す構成図を作成する作成部と、を備える、テスト仕様作成支援装置が提供される。

ソフトウェアの設計開発、テストの設計及び実施の各工程を示す図 ＬＴＭａｐ（レイヤ・ティア図）を示す図 ＴＲＭａｐ（テスト仕様関連図）を示す図 テスト仕様とテスト項目の関係を示す図 テストの構造の可視化について説明するための図 テスト仕様を作成する大まかな手順を示す図 実施形態に係るテスト仕様作成支援装置を示すブロック図 構成管理システムを示す図 テスト環境を示す図 ＬＴＭａｐに基づくテスト仕様作成編集の概念を示す図 ＬＴＭａｐに基づくテスト仕様編集の具体的手順を示すフローチャート ＬＴＭａｐの作成及び編集の具体的な実施例に係るエレベータの制御プログラムを説明するための図 ＬＴＭａｐに係る表形式の内部データを示す図 ＬＴＭａｐの表示例（要求仕様のサイズを横軸とする場合）を示す図 表形式の内部データを示す図 ＬＴＭａｐの表示例（リスクの大きさを横軸とする場合）を示す図 テスト仕様の重複排除について説明するための図 テスト仕様の重複排除について説明するための図 テスト仕様の追加について説明するための図 テスト仕様の追加について説明するための図 軸の組合せを変化させる場合を示す図 軸の値の分割方法を修正する例について説明するための図 軸の値の分割方法を修正する例について説明するための図 軸の値の分割方法を修正する例について説明するための図 軸の修正に伴うテスト仕様の配置変更を説明するための図 軸の修正に伴うテスト仕様の配置変更を説明するための図 テスト仕様の属性値の付け直しを説明するための図 ＴＲＭａｐに基づくテスト仕様作成編集の概念を示す図 ＬＴＭａｐに基づくテスト仕様編集の具体的手順を示すフローチャート テスト仕様間の関係の検証部及び変換部を備えるＴＲＭａｐ作成部を示すブロック図 変換部による変換処理を含んだ処理の手順を示すフローチャート テスト仕様間の関係の図形表現を示す図 ＴＲＭａｐに係る表形式の内部データを示す図 ＴＲＭａｐの表示例を示す図 ＴＲＭａｐに基づくテスト仕様の追加を示す図 包含関係への変換を説明するための図 包含関係への変換を説明するための図 包含関係への変換を説明するための図 エレベータのテスト設計を行う際のＴＲＭａｐの変遷を示す図 エレベータのテスト設計を行う際のＴＲＭａｐの変遷を示す図 エレベータのテスト設計を行う際のＴＲＭａｐの変遷を示す図 エレベータのテスト設計を行う際のＴＲＭａｐの変遷を示す図

本発明の実施形態は、図１に示すソフトウェアの設計開発、テスト設計及び実施の各工程において、特に、テストに関係する上流工程１（テスト戦略、テストアーキテクチャ等）を強化するテスト設計手法に関する。実施形態に係るテスト仕様作成支援装置は、レイヤ・ティア図（以下「ＬＴＭａｐ」）及びテスト仕様関連図（以下「ＴＲＭａｐ」）を作成して表示する。テスト設計に関与するユーザーが主に本装置を利用し、ＬＴＭａｐ及びＴＲＭａｐに基づいてテスト仕様の作成等を行う。図２において、参照符号２によって示すＬＴＭａｐは、テスト仕様の位置づけをソフトウェアの論理構造の縦軸とテストの観点の横軸の２軸で表現した図である。また、図３において、参照符号３によって示すＴＲＭａｐは、テスト仕様間の関係を包含関係のネットワークで表現した図である。図２のようなＬＴＭａｐは、テスト仕様のばらつきやギャップ（漏れ）を見るトップダウンアプローチに有用であり、図３のようなＴＲＭａｐは、重複や粒度を見てテスト仕様を整理するボトムアップアプローチに有用である。

実施形態の詳細な説明の前に、本明細書で用いる用語について説明する。
・「テスト」とは、開発したソフトウェアプログラムが、分析した要求に対応する仕様や考案した設計の通りに作られたかどうかを、当該プログラム（すなわちソフトウェア内においてテストを実行すべきテスト対象のプログラム）を動作させて確認することをいう。

・「テスト設計」とは、テスト対象のプログラムのどのような動作確認が必要かを予め決定し用意しておくことをいう。複数のテストケースをそれぞれ設計し、すべてが合格することを期待する。なお、「テストケース」なる用語は、テスト仕様やテスト項目のいずれかを指すものとする。

図４に、テスト仕様とテスト項目の関係を示す。
・「テスト仕様」（参照符号４によって示す）とは、テスト対象のプログラムをどのように動作させ確認するかを抽象的に記述したものをいう。一つのテスト仕様は、テストの目的、テストの対象範囲、テストの手順を要素として持つ。テスト仕様に基づいて、複数のテスト項目が抽出される。

・「テストの目的」とは、そのテストで何を確認するのかを定義したものをいう。テストの目的は、テスト対象の位置づけの属性（値）と、テストの観点の位置づけの属性（値）を持つことが必須である。

・「テスト項目」（参照符号５によって示す）とは、テスト仕様の数値、手順を具体化して記述したものをいう。テストを実施するための設定条件、作業手順、確認事項及び期待値などを要素として持つ。例えば図４のように、あるテスト仕様について複数のテスト項目Ａ〜Ｃがあり、テストＡは「Ｘを１００にするとＺが２０になる」という具体化されたテスト項目の要素を持ち、テストＢは「Ｘを５００にするとＺが４０になる」という具体化されたテスト項目の要素を持つ。

図５を参照してテストの構造の可視化について説明する。まず前提として、図５に示すように、テストの構成要素である「テスト項目」５２は、抽象化された「テスト仕様」５１から導き出され、具体化されるものである。テスト仕様５１は、必ず「テストの目的」を含まなければならない。「テストの目的」は、「テスト対象の位置づけ」の属性と「テストの観点の位置づけ」の属性を持つ。テスト対象は、テスト対象のプログラム５０のことである。ここで、「テストの構造を可視化する」とは「テストの目的」の位置づけの２属性に基づいて、テストの位置関係を表現する、あるいは接続関係を表現することをいう。本実施形態では、このようなテスト構造の可視化をＬＴＭａｐ又はＴＲＭａｐによって行う。

図６に示すように、テスト仕様６２は、テストの目的を決める段階と、テストの対象範囲（入出力）及び手順を決める段階とを経て作成される。前者の段階すなわちテストの目的を決める段階では、ＬＴＭａｐ６０又はＴＲＭａｐ６１が利用される。後者の段階では、テスト仕様６２に基づいて複数のテスト項目６３が作成され、これらに基づいてテストが実施されることになる。本実施形態に係るテスト仕様作成支援装置は、テスト仕様を作成する前者の段階を支援する。

図７は、実施形態に係るテスト仕様作成支援装置を示すブロック図である。同図に示すように、テスト仕様作成支援装置７１は、ＬＴＭａｐ作成部７４、ＴＲＭａｐ作成部７５、ユーザインタフェース７６、第１の記憶部７７及び第２の記憶部７８を有する。また本装置７１には、マウス／キーボード７２及びモニタ７３が接続されている。

第１の記憶部７７は、ＬＴＭａｐ又はＴＲＭａｐに配置されるテスト仕様を記憶する。テスト仕様はソフトウェアに対するものであって、少なくともテストの目的及びソフトウェア内でテストを実行すべきテスト対象を記述したものである。

ＬＴＭａｐ作成部７４は、少なくともテスト対象の論理構造の大きさを分類するための第１軸とテストの観点に沿って各テスト仕様を分類するための少なくとも１つの第２軸とで表現される２次元空間に対して、各軸上での前記テスト仕様の位置を示す指示データを受け取り、該指示データに基づいてＬＴＭａｐ（構成図）を作成する。指示データは、第２の記憶部７８によって記憶される。

ＴＲＭａｐ作成部７５は、テスト仕様を代表する図形と指示データに応じたテスト仕様間の関係を示す図形とを含む、テスト仕様全体を表わす構成図を作成する。ＴＲＭａｐ作成部７５による処理については後述する。

ユーザインタフェース７６は、ＬＴＭａｐ作成部７４及びＴＲＭａｐ作成部７５と、マウス／キーボード７２及びモニタ７３を介したユーザーとの間をインターフェースする例えばＧＵＩである。マウス／キーボード７２及びモニタ７３の代わりにタッチパネル式の入出力装置を用いてもよい。

テスト仕様作成を行うユーザーは、マウス／キーボード７２を操作することにより、本装置７１に対して指示データを与えることができる。モニタ７３は、本装置７１により作成されたＬＴＭａｐ又はＴＲＭａｐを表示する。

なお本実施形態に係る装置は、コンピュータプログラムによって実現することができる。この場合、コンピュータを、テスト仕様作成支援装置として機能させるためのプログラムが、コンピュータ読み取り可能な記録媒体からメモリ等の記憶手段に読み出され、ＣＰＵにより実行される。

またテスト仕様作成支援装置７１は構成管理システム７０に接続されており、ＬＴＭａｐ及びＴＲＭａｐの作成ならびにテスト仕様の作成を、構成管理システム７０から提供されるソフトウェアプログラム及び設計情報等に基づいて行うことができる。

図８は、構成管理システムを示す図である。本実施形態において扱うテスト仕様は、テスト対象に依存する。テスト対象は、例えばソフトウェアプログラム８０である。ソフトウェアプログラム８０は構造化され、モジュールという形でそれぞれ独立したファイルに分割されている。ファイルには処理関数がいくつか含まれている。構成管理システム８３は、開発された最新のソフトウェアプログラム８０を一箇所に集約して管理する。構成管理システム８３には、ソフトウェアプログラム８０の他にも、要求仕様書８１や設計書８２などの設計文書の成果物も格納することができる。ユーザーは、指定バージョンについて、構成管理システム８３から成果物を検索することができる。

図９はテスト環境を示す図である。テストを実施する場合、テスト対象としてのソフトウェアプログラムの全体又はその一部９１が構成管理システム９０から取り出される。テストの目的に応じて、テスト対象から取り出される部分９１は異なる。部分９１は、例えば関数やモジュールファイルなどであり、テスト環境（例えばデバッガ）９２に組み込んで動作させ、テストが行われる。テストの実行はテストプログラム９３によって制御される。

テスト対象は、テスト仕様毎に必要な部分が違うので、テスト対象の大きさはテスト仕様毎に異なる。例えば行数をテスト対象の大きさとする場合、関数Ａと関数Ｘと関数Ｃの組合せに関するテストにおいて、テスト対象の大きさは、「関数Ａの行数＋関数Ｘの行数＋関数Ｃの行数」である。関数Ｂ単独のテストでは、「関数Ｂの行数」がテスト対象の大きさとなる。構成管理システムから取り出したテスト対象を評価して決定する本実施形態において、後述するＬＴＭａｐの対象軸の値は、テスト対象の大きさに依存して、区分されたいずれかの値に決定される。

図１０は、ＬＴＭａｐに基づくテスト仕様作成編集の概念を示す図である。ユーザーは、テスト仕様について、その対象が何であるか、確認したいことは何であるかを決定する。これは、テストの目的を決めることに相当する。この作業をＬＴＭａｐ１０２を利用して行うことができる。ＬＴＭａｐ１０２は、図７に示したＬＴＭａｐ作成部７４によって作成され、モニタ７３により表示される。ＬＴＭａｐ１０２は、レイヤ軸及びティア軸の少なくとも２つの軸から構成される。ＬＴＭａｐ１０２は、レイヤ軸の種類及びレイヤ軸の目盛（分割の仕方）１００と、ティア軸の種類及びティア軸の目盛（分割の仕方）１０１とによって規定される。レイヤ軸の目盛については、テスト対象を評価することによりその属性値を決める。一方、ティア軸の目盛については、離散的な値についてすべての組合せを洗い出す。連続値ならば、同値分割して離散化してもよい。ユーザーは、表示されたＬＴＭａｐ１０２に基づいて、テスト仕様の作成編集を行う。これにより、追加されるテスト仕様１０３、変更されるテスト仕様１０４、削除されるテスト仕様１０５が発生する。最終的なテスト仕様は、責務が明確なものとなり、Ｗｈｙ（なぜそのテストが必要か）、Ｗｈａｔ（何を確認するテストか）を特定することができる。また、設計情報を加味することで、Ｈｏｗ（どのようにテストを実施するか）も特定することが可能である。

図１１は、ＬＴＭａｐに基づくテスト仕様編集の具体的手順を示すフローチャートである。ユーザーは、テスト仕様作成支援装置を通じて、テスト仕様洗い出し（ステップＳ１）と、軸の決定及び値の分割（ステップＳ２）とを行う。このために利用可能な情報が予め構成管理システム等からテスト仕様作成支援装置に与えられ、仕様書や設計書を参照して意思決定できることが好ましい。また、ステップＳ１において複数のテスト仕様が作成されると、これらは図７の第１の記憶部７７に格納される。次に、テスト仕様作成支援装置は、第１の記憶部７７からテスト仕様のデータを一つ取りだす（ステップＳ３）。次に、このテスト仕様について、テスト対象の位置づけを決定する（ステップＳ５）。これは、ＬＴＭａｐにおける第１軸の値を決定することに相当する。第１軸は、テスト対象の論理構造の大きさを分類するものである。第１軸の値は、ユーザーが図７のマウス／キーボード７２等を操作し、ユーザインタフェース７６を通じてＬＴＭａｐ作成部７４に与える指示データとしても良いし、構成管理システム等からＬＴＭａｐ作成部７４が取得してもよい。

テスト対象の位置づけの値（第１軸の値）が決まったら、テストの観点の軸の値を決める（ステップＳ６）。これは、ＬＴＭａｐにおける第２軸の値を決定することに相当し、ユーザーが図７のマウス／キーボード７２等を操作し、ユーザインタフェース７６を通じてＬＴＭａｐ作成部７４に指示データとして与える。ステップＳ５及びＳ６によって、当該テスト仕様について、テストの目的が持つ、テスト対象の位置づけの属性値とテストの観点の属性値とが決まる。

次にＬＴＭａｐ作成部７４は、上記第１軸及び第２軸により規定されるＬＴＭａｐを作図し、上記第１軸及び第２軸の値に従って当該テスト仕様を代表する図形（アイコン、サムネイル等）をＬＴＭａｐ上に配置することによりＬＴＭａｐの表示データを生成する。ＬＴＭａｐの表示データに従ってモニタ７３にはＬＴＭａｐが表示される（ＬＴＭａｐの可視化：ステップＳ７）。

ステップＳ３以下の処理が繰り返されることにより、複数のテスト仕様がＬＴＭａｐ上に配置され、表示される。これにより、テスト仕様の重複や欠損（漏れ）がＬＴＭａｐの表示上で明らかとなる（ステップＳ８）。ユーザーは、このようなテスト仕様の重複や欠損を修正すべきであると判断し、その旨をＬＴＭａｐ作成部７４に指示する（ステップＳ９）。これに応じて、ＬＴＭａｐ作成部７４は、テスト仕様の追加、削除、変更等の編集を可とする（ステップＳ１０）。ユーザーによる編集作業のための機能は、ユーザインタフェース７６により実現される。

なお、テスト仕様の重複や欠損に対する修正が完了し、最後のテスト仕様のデータまで処理されたら、ＬＴＭａｐ（構成図）の最終結果を出力して処理を終了する。

以上説明したＬＴＭａｐの作成及び編集に関して、本実施形態に係るテスト仕様作成支援装置７１は、２つ以上の評価軸（第１軸及び第２軸）を組み合わせたＬＴＭａｐ上にテスト仕様を配置することで、「テストの目的」の位置づけを示すことができる。また、ＬＴＭａｐ上に複数のテスト仕様を配置されることで、テスト仕様間の違い（目的の属性の違い）を明示することができる。なお、ＬＴＭａｐは、２軸のみならず、３軸や４軸で表現しても良い。評価軸には、テスト対象の構造を表す軸（レイヤ軸）とテストの観点を表す軸（ティア軸）を必ず含むものとする。テスト対象の構造を表す軸の値はテスト対象のプログラムを評価することによって取得してもよい。

複数の評価軸によって「テストの目的」の位置づけを示す複数のＬＴＭａｐを生成し、これらを任意に組み合わせたり、ある評価軸を固定し、他の軸と組み合わせたりするなど、ＬＴＭａｐの表示態様は種々変形してもよい。

また、評価軸の目盛の値を離散化し、分割した座標を用いることで位置づけを表現してもよい。

また、テスト仕様の抜けを補完するように、テスト目的の適切な属性値を持つテスト仕様を自動的に生成してもよい。

さらに、評価軸の分割の態様を変更する（例えば軸の分割を追加し、変更し、あるいは削除する）ことにより、テスト仕様の位置づけを変更できるようにすることが好ましい。

以下、ＬＴＭａｐの作成及び編集に関して、より具体的な実施例を説明する。ここでは、エレベータの制御プログラムを対象にする場合を例に挙げる。図１２は、ＬＴＭａｐの作成及び編集の具体的な実施例に係るエレベータの制御プログラムを説明するための図である。

例えば次のようにテスト仕様を洗い出した。
テスト仕様（Ａ）：各階にある上下ボタン１２０の押下に応じてボタンが点灯し、リフトが到着する。

テスト仕様（Ｂ）：リフトの中にあるフロアボタン１２２の押下に応じてボタンが点灯し、指定された階にリフトが移動する。

テスト仕様（Ｃ）：リフトが到着すると、各階のドア上部にある上下ランプ１２１が点滅し、ドアが開くと消灯する。

テスト仕様（Ｄ）：ボタンの要求に応じてリフトの移動方向と停止階を決定する。

テスト仕様（Ｅ）：非常停止ボタンが押されると最寄り階に停止し、ドアが開く。

評価軸は、例えば次のように定めた。
レイヤ軸１：テスト対象の粒度、
ティア軸１：要求仕様のサイズ、
ティア軸２：リスクの大きさ
各軸の値域を次のように分類した。
レイヤ軸１：関数／クラス／モジュール／システム、
ティア軸１：ロジック・アルゴリズム／機能仕様／ソフトウェア要求仕様、
ティア軸２：小／大／致命的
システム（テスト仕様作成支援装置）は、構成管理システムからの情報に基づき、テスト仕様の対象の位置づけを以下のように評価した。即ち、各テスト仕様のＬＴＭａｐにおける第１軸の値を決定した。

テスト仕様（Ａ）：テスト対象は上下ボタン１２０である。当該テスト対象のプログラムを分析することにより、関数レベルのテスト仕様であるという位置づけとする。

テスト仕様（Ｂ）（Ｃ）：フロアボタン１２２及び上下ランプ１２１も同様に、関数レベルに位置づけられる。

テスト仕様（Ｄ）：テスト対象はリフトのスケジューラであり、操作前の状態と入力された要求を加味して判断するシステム全体に関わるテスト仕様である。

テスト仕様（Ｅ）：操作の対象は「非常停止ボタン」であるが、テストの目的は非常停止処理であることから、非常停止処理について、システム全体に関わるテスト仕様である。

次に、テストの観点（要求仕様のサイズ）の位置づけをユーザーが以下のように判断してシステムに与えた。即ち、各テスト仕様のＬＴＭａｐにおける第２軸の値を決定した。

テスト仕様（Ａ）：上下ボタン１２０を押された場合、スケジューラに要求を出し、ボタンを点灯する、というテストは機能仕様レベルという位置づけである。

テスト仕様（Ｂ）（Ｃ）：フロアボタン１２２及び上下ランプ１２１も同様に、機能仕様レベルである。

テスト仕様（Ｄ）：スケジューラは全体の動きを決めるソフトウェア要求仕様に関わるものである。

テスト仕様（Ｅ）：非常停止処理も同様に、ソフトウェア要求仕様に関わるものという位置づけである。

以上のようなテスト対象の位置づけとテストの観点の位置づけに従って、システムが図１３に示すような表形式の内部データを作成した。これは、第２の記憶部７８に記憶されるものである。

システムは、上記内部データに従って図１４に示すような２次元空間のＬＴＭａｐを表示することができる。同図に示されるＬＴＭａｐにおいて、縦軸（第１軸）は、テスト対象の粒度を表す。これは、システム、モジュール、クラス、関数という属性（値）を持つ。一方、横軸（第２軸）は、要求仕様のサイズを表す。これは、ロジック又はアルゴリズム、機能仕様、ソフトウェア要求仕様という属性（値）を持つ。

第３軸として、さらに別のテストの観点（リスクの大きさ）をシステムに与える場合について説明する。

更なるテストの観点として、リスクの大きさの位置づけをユーザーが以下のように判断してシステムに与えた。即ち、各テスト仕様のＬＴＭａｐにおける第３軸の値を決定した。

テスト仕様（Ａ）：上下ボタン１２０が押された場合に、システムが誤動作するとリフトが到着しないなど、移動したい要求を実現できないので、リスクは「大」と位置づける。テスト仕様（Ｂ）のフロアボタン１２２についても同様とする。

テスト仕様（Ｃ）：上下ランプ１２１は点灯しなくても要求を実現することは可能なので、リスクは「小」と位置づける。

テスト仕様（Ｄ）：スケジューラが誤動作すると、移動したい要求を実現できないので、リスクは「大」と位置づける。

テスト仕様（Ｅ）：非常停止処理が誤動作すると、使用者の生命に危険が及ぼされるので、リスクは「致命的」と位置づける。

テスト対象の位置づけとテストの観点の位置づけに従って、システムは表形式の内部データを持つ
以上のようなテスト対象の位置づけとテストの観点の位置づけに従って、システムは図１５に示すような表形式の内部データを作成した。これは、第２の記憶部７８に記憶される。

システムは、上記内部データに従って図１６に示すような２次元空間のＬＴＭａｐを表示することができる。同図に示されるＬＴＭａｐにおいて、縦軸（第１軸）は、図１４の場合と同じくテスト対象の粒度を表す。一方、横軸は、リスクの大きさを表す第３軸とする。リスクの大きさは、「小」、「大」、「致命的」という３つの値に分類される。

ここで、テスト仕様の重複排除について説明する。図１７及び図１８に示すように、テスト仕様（Ａ）及び（Ｂ）１７０、即ち上下ボタン及びフロアボタンは、２つの図でどちらも同じポジションにあって重複していることが分かる。これら重複している２つテスト仕様１７０を一つにまとめて要求ボタンのテスト仕様１７１とし、同じポジションに配置することができる。なお、図１７は、テスト対象の粒度（第１軸）と要求仕様のサイズ（第２軸）を組み合わせた場合のＬＴＭａｐであり、図１８は、テスト対象の粒度（第１軸）とリスクの大きさ（第３軸）を組み合わせた場合のＬＴＭａｐである。

次に、テスト仕様の抜けを補完することについて説明する。図１９から分かるように、テスト対象の粒度が「クラス」であるテスト仕様が存在しない（「モジュール」についても同様）。この場合、例えばリフト制御を対象とする、クラスレベルのテスト仕様１９０を追加することができる。テスト対象となるリフト制御というクラスは、例えば、リフトを上方向又は下方向に移動させるものであり、指定階に近づいたら減速し、指定階に到着したら停止し、ドアを開くというものである。なお、図１９において、テスト仕様（Ｄ）について、「リフトの移動」とは、リフトの停止階と移動方向を決めるのみとし、実際のリフトの移動の確認は要しないこととしている。

システムは、新たに追加したリフト制御というテスト仕様１９０について、テスト対象として複数の関数を対象とする「クラス」レベルの位置づけであることを判定する（ユーザーは、この判定結果が正しいことを確認する）。またユーザーは、新たに追加したリフト制御というテスト仕様１９０が、要求仕様のサイズではロジック又はアルゴリズムのレベルであることを判断し、そのように位置づける。また、図２０から分かるように、ユーザーは、同テスト仕様１９０が、リスクの大きさという観点において「致命的」に位置づけられると判断する。リフトの制御が誤動作すると人命が危機にさらされる可能性が高くなるからである。

次に、テスト対象の構造を表す軸とテストの観点を表す軸について、その種類及び分類（軸の分割）の例を幾つか説明する。

テスト対象の構造を表す軸として、ソフトウェアの構造上の粒度、処理モジュールのリスト、コードの規模、ハードウェアとの距離、並行度合いなどを用いてもよい。ソフトウェアの構造上の粒度は、例えば「関数／モジュール／コンポーネント／システム」に分類することができる。処理モジュールのリストは、例えば「上下ボタン／フロアボタン／上下ランプ／非常停止ボタン／リフト／スケジューラ」に分類することができる。コードの規模は、例えば「１０行程度／１００行程度／１０００行程度」に分類することができる。ハードウェアとの距離は、例えば「直接操作／依存関係がある／独立と見なせる」に分類することができる。並行度合いは、例えば「並行に動作する／シーケンシャルに動作する」に分類することができる。

テストの観点を表す軸として、テスト工程、テストの実行環境、リスクの大きさ、ライフサイクルの長さ、開発者の経験、新規開発量などを用いてもよい。テスト工程は、例えば「単体テスト／結合テスト／総合テスト」に分類することができる。テストの実行環境は、例えば「デバッガ（ＩＤＥ）／シミュレータ（ＩＳＳ）／実基板（フルＩＣＥ）／実機」に分類することができる。リスクの大きさは、例えば「低／高／致命的」に分類することができる。ライフサイクルの長さは、例えば「今回のみ／変更しながら使う／使い回す」に分類することができる。開発者の経験は、例えば「浅い／中堅／ベテラン」に分類することができる。新規開発量は、例えば「流用／変更／新規」に分類することができる。

次に、軸の組合せを変化させて提示し、新たなテスト仕様の追加を促すことについて説明する。図２１に示すＬＴＭａｐは、横軸をリスクの大きさ（既存の軸）とし、縦軸を要求仕様のサイズ（既存の軸）としたものである。各テスト仕様の属性の値は既に決定されているため、表示をするのみである。このように軸の組合せを変化させることによって、テスト仕様が存在しないポジションが明らかになる場合がある。このような表示に基づいて、適切なポジションにテスト仕様を追加することができる。図２１の例では、「乗客が（エレベータの扉に）挟まったらドアを開く」という、機能仕様×致命的リスクレベルのテスト仕様２１０を追加した場合を示している。この場合、システムは、ドアの制御なのでテスト対象の粒度は関数レベルであると判定するものの、図２１のＬＴＭａｐの表示において、この情報は利用されない。ユーザーは、追加に係るテスト仕様２１０について、要求仕様のサイズを「機能仕様」レベルに位置づけるとともに、リスクを「致命的」レベルに位置づけている。

次に、ＬＴＭａｐにおける軸の値の分割方法を修正する例について説明する。
修正前の２種類のＬＴＭａｐを図２２及び図２３に示す。ここで、図２３に対応するテストの観点の一つである「リスクの大きさ」の軸の値の取り方を、ユーザーからの指示に応じて「小／大／致命的」から「小／中／大／致命的」に修正してもよい。軸の値の取り方を修正した結果を図２４に示す。システムは横軸の「中」の値の領域２４０を作成するが、テスト仕様は新たに追加された属性を持っているものがないので、該当なしの状態である。

ＬＴＭａｐにおける軸の値の分割方法の修正に伴い、ユーザーは、既存のテスト仕様について、リスクの大きさを（軸の修正により追加された）「中」とするのが適切なテスト仕様を見極める。例えば、図２５に示すように、上下ボタンというテスト仕様（Ａ）は、リフトに乗る以前の操作に関するものであり、リフトに乗った後のフロアボタンの機能不全によるダメージよりはリスクが軽いと判断し、「中」に変更する（参照符号２５０によって示す）。この場合の、ＬＴＭａｐ上でのテスト仕様の配置変更を図２６に示す。同図から分かるように、テスト仕様（Ａ）は、当初はリスクの大きさが「大」に位置づけていたが、これをリスクの大きさ「中」のレベルに配置変更する（参照符号２６０によって示す）。

なお、ＬＴＭａｐにおける軸の値の分割数は変わらず、値そのものを修正する場合には、図２７に示すように、内部テーブルにおけるテスト仕様の属性値を付け直せばよい。これは、リスクの大きさを当初は「小／中／大／致命的」としていたものを「低／中／高／致命的」に修正した場合に相当する（参照符号２７０によって示す）。

以上の説明は、ＬＴＭａｐ作成部７４による処理に関するものであった。以下では、ＴＲＭａｐ作成部７５による処理について説明する。

図２８は、ＴＲＭａｐに基づくテスト仕様作成編集の概念を示す図である。図１０を参照して説明したように、ユーザーは、テスト仕様について、その対象が何であるか、確認したいことは何であるかを決定する。これは、テストの目的を決めることに相当する。この作業は、主にＬＴＭａｐを利用して行われる。これに対しＴＲＭａｐは、重複や粒度を見てテスト仕様を整理するボトムアップアプローチに有用である。

ＴＲＭａｐは、図７に示したＴＲＭａｐ作成部７５によって作成され、モニタ７３により表示される。ＴＲＭａｐは、テスト仕様間の関係を表す。これには、図２８に示すように包含関係、包含仮関係、類似関係がある。ユーザーは、表示されたＴＲＭａｐをもとにテスト仕様の整理を行う。これにより、追加されるテスト仕様３５２、変更されるテスト仕様３５３、削除されるテスト仕様３５４が発生し得る。

図２９は、ＴＲＭａｐに基づくテスト仕様編集の具体的手順を示すフローチャートである。ユーザーは、テスト仕様作成支援装置を通じて、テスト仕様洗い出しを行う（ステップＳ１）。このために利用可能な情報（要求仕様書や設計書、過去に作成したテスト仕様等）が予め構成管理システム等からテスト仕様作成支援装置に与えられ、ユーザーに示されることが好ましい。また、ステップＳ１において複数のテスト仕様が作成されると、これらは図７の第１の記憶部７７に格納される。次に、テスト仕様作成支援装置は、第１の記憶部７７からテスト仕様のデータを２つ取りだす（ステップＳ２）。次に、これらテスト仕様間の関係を決定する（ステップＳ５）。この処理は、ユーザーが図７のマウス／キーボード７２等を操作し、ユーザインタフェース７６を通じてＴＲＭａｐ作成部７５に与える指示データとしても良いし、構成管理システム等からＴＲＭａｐ作成部７５が取得してもよい。

２つのテスト仕様間の関係が決まると、ＴＲＭａｐ作成部７５は、当該２つのテスト仕様のそれぞれを代表する図形（アイコン、サムネイル等）をＴＲＭａｐ上に配置し、決定された関係を示す図形によって両者を結びつけてＴＲＭａｐの表示データを生成する。このＴＲＭａｐの表示データに従ってモニタ７３にはＴＲＭａｐ（構成図）が表示される（ステップＳ５）。テスト仕様間の関係が十分に決定されるまで、ステップＳ１〜Ｓ６の処理が繰り返される。

図３０は、テスト仕様間の関係の検証部及び変換部を備えるＴＲＭａｐ作成部を示すブロック図である。ＴＲＭａｐ作成部７５は、２つのテスト仕様間における包含関係の有無を定めることによってテスト仕様の構造を可視化する。検証部７５０は、ＴＲＭａｐが表すテスト仕様間の関係が適切なものであるかどうかをＬＴＭａｐのデータに基づいて検証する。検証部７５０は、包含関係の正しさを、テスト仕様を特徴づけるすべての、あるいは予め定められた割合以上の属性の軸の大小によって判断してもよい。

変換部７５１は、ＴＲＭａｐにおいてユーザーにより類似関係又は包含仮関係として設定されたテスト仕様間の関係を包含関係に変換する。

図３１は、変換部７５１による変換処理を含んだ処理の手順を示すフローチャートである。テスト仕様間の関係を決定し、両者の関係をＴＲＭａｐとして表示するまでのステップＳ１乃至Ｓ６の処理は、図２９に示したものと同様である。図３１に示す処理では、変換部７５１による変換処理を行うためにステップＳ７においてＬＴＭａｐが作成されることが必要である。ステップＳ８及びＳ９において、変換部７５１は、ＴＲＭａｐにおけるテスト仕様間の類似関係を包含関係に変換する。次に、ステップＳ１０及びＳ１１において、変換部７５１は、ＴＲＭａｐにおけるテスト仕様間の包含仮関係を包含関係に変換する。変換を終えた最終的なＴＲＭａｐは、モニタ７３により表示される。

包含関係は、テストの親子関係を表し、親テストとすべての子テストの集合が等価であり、親テストは子テストに分割可能であることを表す。これに対し包含仮関係は、２つのテスト仕様間における部分的な包含を示す。包含仮関係の正しさについて、検証部７５０はテスト仕様を特徴づける「一部の」軸の値の大小に基づいて検証を行ってもよい。

類似関係は、２つのテスト仕様に相関がある場合に、両者の間に定める。類似関係をＬＴＭａｐに反映する場合には、類似関係を、テスト仕様を特徴づける「ある特定の１つの」軸の同じ値として表現すればよい。

変換部７５１は、テストの属性を表す軸の目盛りの振り方、あるいは値を変更をすることによって、包含仮関係を包含関係に変換してもよい。また変換部７５１は、共通の値をもった軸を新たに作成すること、あるいは軸の目盛りの振り方を変更することによって、類似関係を包含関係に変換してもよい。さらに、変換部７５１は、共通の包含関係をもつ第三のテスト仕様を追加することによって、類似関係を解消してもよい。

次に、ＴＲＭａｐにおいてテスト仕様間の関係を図形によってどのように表現するかを説明する。

例えば、図３２（ａ）に示すようにテスト仕様の包含関係を矢印で表現し、同図（ｂ）に示すように包含仮関係を先端が三角形の矢印で表現し、同図（ｃ）に示すようにテスト仕様の類似関係を角丸四角で囲んで表現してもよい。

以下、ＴＲＭａｐの作成及び編集に関して、より具体的な実施例を説明する。ここでは、ＬＴＭａｐ作成の実施例と同様、エレベータの制御プログラムを対象にする。

また、テスト仕様の洗い出しの結果は、ＬＴＭａｐ作成の実施例の場合と同様であるとする。２つのテスト仕様の組合せは、（Ａ）と（Ｂ）、（Ａ）と（Ｃ）、（Ａ）と（Ｄ）、（Ａ）と（Ｅ）、（Ｂ）と（Ｃ）、（Ｂ）と（Ｄ）、（Ｂ）と（Ｅ）、（Ｃ）と（Ｄ）、（Ｃ）と（Ｅ）、（Ｄ）と（Ｅ）の１０通りがある。これら組合せを図３３に示すような表形式の内部データ構造として持ち、関係性の有無及びその種類を決める。これは、ユーザーから指示データとしてシステムに与えられ、図７の第２の記憶部７８に格納される。

上記関連性のデータに従い、ＴＲＭａｐ作成部７５は図３４に示すＴＲＭａｐを作成してモニタ７３に表示する。

図３５に示すように、ユーザーは、ＴＲＭａｐの表示をもとに、テストを分割又は統合する際の過不足を考慮して、テスト仕様の追加、変更、削除を行うことができる。図３５の例では、初期化処理、リフト制御、押下認知、ランプ点灯、点灯までの反応時間といった新たなテスト仕様３９０が追加されている。

ＬＴＭａｐのポジションに基づいて包含関係の検証を行うことについて説明する。

図３３には３つの包含関係があることを示した。即ち、（Ａ）と（Ｄ）、（Ｂ）と（Ｄ）、（Ｃ）と（Ｄ）である。検証部７５０は、これらが適切であるかどうかを図２２及び図２３に示したＬＴＭａｐに基づいて検証する。

まず（Ａ）と（Ｄ）について、図２２のＬＴＭａｐによれば、（Ｄ）が（Ａ）に対して右上に位置し、図２３のＬＴＭａｐによれば、（Ｄ）が（Ａ）の真上に位置することから、両者の包含関係は正しいと判定する。同様に、（Ｂ）と（Ｄ）について、図２２のＬＴＭａｐによれば、（Ｄ）が（Ｂ）に対して右上に位置し、図２３のＬＴＭａｐによれば、（Ｄ）が（Ｂ）の真上に位置することから、両者の包含関係は正しいと判定する。（Ｃ）と（Ｄ）について、図２２のＬＴＭａｐによれば、（Ｄ）が（Ｃ）に対して右上に位置し、図２３のＬＴＭａｐにおいても、（Ｄ）が（Ｃ）の右上に位置することから、両者の包含関係は正しいと判定する。このように、ＬＴＭａｐにおけるテスト仕様の位置関係から、包含関係の有無について判定することができる。なお、軸の値の大小関係によって、どちらのテスト仕様が親であって他方のテスト仕様を包含するかを判定することができる。

図３６に示すように、テスト仕様（Ｄ）と（Ｅ）は包含仮関係４３にある。この包含仮関係は、変換部７５１により包含関係に変換される。即ち、図３６の包含仮関係４３は、図２３のＬＴＭａｐ（リスクの大きさをテストの観点とする）におけるテスト仕様（Ｄ）と（Ｅ）の位置関係（（Ｅ）は（Ｄ）よりも軸の値が大きい）に基づいて、図３７に示す包含関係４４に変換される。

図３６によれば、テスト仕様（Ａ）と（Ｃ）は類似関係にあり、（Ｂ）と（Ｃ）も類似関係にある。これら類似関係は、両者を包含するテスト仕様を変換部７５１が追加することにより、包含関係に変換することができる。即ち、図３７に示すように、（Ａ）と（Ｃ）を包含する新たなテスト仕様４４１（要求ボタン）を共通の親として作成したり、図３８に示すように、（Ｂ）と（Ｃ）を包含する新たなテスト仕様４５を（結果表示）を共通の親として作成することができる。

変換部７５１によれば、テスト仕様間の包含仮関係や類似関係を「包含関係」に変換することができる。このようなテスト仕様の統廃合を行うことの意義について説明する。
テストケースを作成（設計）する際には、対象のソフトウェアの要求仕様書や設計書を分析して、どのようなテストケースが必要かを洗い出す。テスト対象のソフトウェアが大規模・複雑になってきているので、テストケースの洗い出しを見通しよく実施していくことが困難になってきている。そのため、アドホックに（とりあえずの）テストケースを設計し、後から整理しなおして最適化する、という手順を踏まざるを得ない。

アドホックに設計されたテストケースは、他との関連を考慮して作成されてはいない。このため、様々なテストを集めてくると、目的がバラバラであったり、他のテストケースと重複してしまったりする。従来、テストケース間の関係を可視化することができなかったので、人間の頭の中で最適化を図っていかねばならず、困難な状況にあった。

そこで、上記実施形態のようにテスト間の関連をＴＲＭａｐを使って表現することで、アドホックに作成されたテストケース間の目的の不整合や重複を発見し、調整していくことでテストケースを統廃合して最適なテストケースに修正していくことができる。

エレベータのテスト設計を行う際のＴＲＭａｐの変遷を図３９乃至図４２に例示する。

図３９は、テスト仕様を洗い出した初期の状態を示す。テスト仕様間の関係が複雑に入りくんだ箇所３００（矢印が錯綜している）をユーザーが見つけ、図４０に示すように新たな包含関係の親テスト３１１を作成して整理する。

このようなテスト仕様の整理中に、矢印が集中しているテスト３１０をユーザーが発見し、図４１に示すように、いくつかに親テスト３３を作成して整理する。さらに、左上に統合できるテスト３２０があるので、図４２に示すように、テスト３３０及びテスト３３１にまとめ、完成とする。

次に、最終的に作成されたテスト仕様の出力について説明する。テスト仕様を出力する際に、（定義した属性や関係を利用せずに）すべてを独立に出力してもよい。また、指定した軸において指定した値の範囲についてテスト仕様を出力してもよい。これらのテスト仕様は、ＬＴＭａｐ上では近接して示される。また、類似関係に基づいてテスト仕様をグループ化して出力してもよい。また、包含関係にある一連のテスト仕様を抽出して出力してもよい。この場合、指定した数の接続先までのテスト仕様をさらに抽出して出力してもよい。

以上説明した実施形態によれば、テスト仕様の抜けを補完することによりテスト仕様の網羅性を向上することができる。これによりテストの実施において不具合発見率を向上することができる。テスト仕様の目的が明確になるため、不具合を狙い撃つテスト項目を生成することが可能となり、不具合発見率を向上することができる。テスト仕様間の重複が発見できるため、無駄なテストを削減でき、テスト工程のコストダウンを実現することができる。テスト仕様間の関係性が可視化されるため、テスト仕様の強弱（テストを綿密に実施するか、粗く実施するか）を決めることができる。テストの全体が把握できるため、何を先にやるか、どんな順序でやるか、といったテストの進め方をコントロールすることができる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

７０…構成管理システム；
７１…テスト仕様作成支援装置；
７２…マウス／キーボード；
７３…モニタ；
７４…ＬＴＭａｐ（ＬＴマップ）作成部；
７５…ＴＲＭａｐ（ＴＲマップ）作成部；
７６…ユーザインタフェース；
７７…第１の記憶部；
７８…第２の記憶部

Claims (7)

1. ソフトウェアに対する複数のテスト仕様であって、少なくともテストの目的及び前記ソフトウェア内でテストを実行すべきテスト対象を記述したテスト仕様を記憶する第１の記憶部と、
   前記第１の記憶部から、任意の２つのテスト仕様を抽出してモニタに表示させ、当該テスト仕様間の関係を指示する指示データを受け取る手段と、
   前記指示データを記憶する第２の記憶部と、
   前記テスト仕様を代表する図形と前記指示データに応じたテスト仕様間の関係を示す図形とを含む、前記テスト仕様全体を表す構成図を作成する作成部と、を備え、
   前記テスト仕様間の関係は、第１のテスト仕様と第２のテスト仕様との間の親子関係が未確定な状態である部分的な包含関係を示す包含仮関係、又は第１のテスト仕様と第２のテスト仕様との間の相関を示す類似関係を含み、
   前記包含仮関係又は前記類似関係を包含関係に変換する変換部をさらに備える、テスト仕様作成支援装置。
2. 前記変換部は、少なくとも前記テスト対象の論理構造の大きさを分類するための第１軸とテストの観点に沿って前記テスト仕様を分類するための少なくとも１つの第２軸とで表現される２次元空間における前記２つのテスト仕様のそれぞれの位置の関係に基づいて、前記包含仮関係又は前記類似関係を包含関係に変換する請求項１記載の装置。
3. ソフトウェアに対する複数のテスト仕様であって、少なくともテストの目的及び前記ソフトウェア内でテストを実行すべきテスト対象を記述したテスト仕様を記憶する第１の記憶部と、
   少なくとも前記テスト対象の論理構造の大きさを分類するための第１軸とテストの観点に沿って前記テスト仕様を分類するための少なくとも１つの第２軸とで表現される２次元空間に前記テスト仕様を代表する図形を配置した構成図を作成する作成部と、
   前記構成図に含まれる前記図形の配置に対する指示データを受け取る手段と、
   前記指示データをそれぞれの前記テスト仕様に関連付けて記憶する第２の記憶部と、を備え、
   前記作成部は、前記指示データに応じて、前記構成図に含まれる前記図形を変更する、テスト仕様作成支援装置。
4. ソフトウェアに対する複数のテスト仕様であって、少なくともテストの目的及び前記ソフトウェア内でテストを実行すべきテスト対象を記述したテスト仕様を第１の記憶部に記憶するステップと、
   前記第１の記憶部から、任意の２つのテスト仕様を抽出してモニタに表示させ、当該テスト仕様間の関係を指示する指示データを受け取るステップと、
   前記指示データを第２の記憶部に記憶するステップと、
   前記テスト仕様を代表する図形と前記指示データに応じたテスト仕様間の関係を示す図形とを含む、前記テスト仕様全体を表す構成図を作成するステップと、を備え、
   前記テスト仕様間の関係は、第１のテスト仕様と第２のテスト仕様との間の親子関係が未確定な状態である部分的な包含関係を示す包含仮関係、又は第１のテスト仕様と第２のテスト仕様との間の相関を示す類似関係を含み、
   前記包含仮関係又は前記類似関係を包含関係に変換するステップをさらに備える、テスト仕様作成支援方法。
5. ソフトウェアに対する複数のテスト仕様であって、少なくともテストの目的及び前記ソフトウェア内でテストを実行すべきテスト対象を記述したテスト仕様を第１の記憶部に記憶するステップと、
   少なくとも前記テスト対象の論理構造の大きさを分類するための第１軸とテストの観点に沿って前記テスト仕様を分類するための少なくとも１つの第２軸とで表現される２次元空間に前記テスト仕様を代表する図形を配置した構成図を作成するステップと、
   前記構成図に含まれる前記図形の配置に対する指示データを受け取るステップと、
   前記指示データをそれぞれの前記テスト仕様に関連付けて第２の記憶部に記憶するステップと、
   前記指示データに応じて、前記構成図に含まれる前記図形を変更するステップと、を備える、テスト仕様作成支援方法。
6. コンピュータを、
   ソフトウェアに対する複数のテスト仕様であって、少なくともテストの目的及び前記ソフトウェア内でテストを実行すべきテスト対象を記述したテスト仕様を記憶する第１の記憶手段、
   前記第１の記憶手段から、任意の２つのテスト仕様を抽出してモニタに表示させ、当該テスト仕様間の関係を指示する指示データを受け取る手段、
   前記指示データを記憶する第２の記憶手段、
   前記テスト仕様を代表する図形と前記指示データに応じたテスト仕様間の関係を示す図形とを含む、前記テスト仕様全体を表す構成図を作成する作成手段、として機能させ、
   前記テスト仕様間の関係は、第１のテスト仕様と第２のテスト仕様との間の親子関係が未確定な状態である部分的な包含関係を示す包含仮関係、又は第１のテスト仕様と第２のテスト仕様との間の相関を示す類似関係を含み、
   前記包含仮関係又は前記類似関係を包含関係に変換する変換手段、としてさらに機能させるためのテスト仕様作成支援プログラム。
7. コンピュータを、
   ソフトウェアに対する複数のテスト仕様であって、少なくともテストの目的及び前記ソフトウェア内でテストを実行すべきテスト対象を記述したテスト仕様を記憶する第１の記憶手段、
   少なくとも前記テスト対象の論理構造の大きさを分類するための第１軸とテストの観点に沿って前記テスト仕様を分類するための少なくとも１つの第２軸とで表現される２次元空間における前記テスト仕様を代表する図形を配置した構成図を作成する作成手段、
   前記構成図に含まれる前記図形の配置に対する指示データを受け取る手段、
   前記指示データをそれぞれの前記テスト仕様に関連付けて記憶する第２の記憶手段、
   前記指示データに応じて、前記構成図に含まれる前記図形を変更する手段、として機能させるためのテスト仕様作成支援プログラム。

Images