知財求人 - 知財ポータルサイト「IP Force」
▶ 株式会社東芝の特許一覧 ▶ 東芝ソリューション株式会社の特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2025007644
(43)【公開日】2025-01-17
(54)【発明の名称】情報処理装置、情報処理方法およびプログラム
(51)【国際特許分類】
G06F 8/10 20180101AFI20250109BHJP
G06F 8/30 20180101ALI20250109BHJP
G06F 11/36 20060101ALI20250109BHJP
【ＦＩ】
G06F8/10
G06F8/30
G06F11/36 136
G06F11/36 164
G06F11/36 184
【審査請求】未請求
【請求項の数】8
【出願形態】ＯＬ
(21)【出願番号】P 2023109182
(22)【出願日】2023-07-03
(71)【出願人】
【識別番号】000003078
【氏名又は名称】株式会社東芝
(71)【出願人】
【識別番号】301063496
【氏名又は名称】東芝デジタルソリューションズ株式会社
(74)【代理人】
【識別番号】110001634
【氏名又は名称】弁理士法人志賀国際特許事務所
(72)【発明者】
【氏名】稲葉 昴裕
(72)【発明者】
【氏名】前田 尚人
【テーマコード（参考）】
5B042
5B376
【Ｆターム（参考）】
5B042HH17
5B042HH19
5B042HH30
5B376BB03
5B376BB13
5B376BC65
(57)【要約】
【課題】テスト仕様書の作成工数を削減できる情報処理装置、情報処理方法およびプログラムを提供すること。
【解決手段】実施形態の情報処理装置は、設計情報読込部と、テスト観点データ読込部と、設計情報トレース管理部と、テスト仕様書生成部とを持つ。設計情報読込部は、テスト対象の設計書を複数読み込み、複数の設計書の各々に含まれる設計情報をモデルに分解する。テスト観点データ読込部は、テスト観点データを読み込む。設計情報トレース管理部は、複数の設計書の各々に含まれる設計情報をモデルに分解した結果に基づきモデル間の対応関係を定義する。テスト仕様書生成部は、テスト観点データと、複数の設計書の各々に含まれる設計情報をモデルに分解した結果と、モデル間の対応関係を定義した結果とに基づいて、複数の設計書のテスト項目を生成し、生成したテスト項目に基づいてテスト仕様書を生成する。
【選択図】図２
【解決手段】実施形態の情報処理装置は、設計情報読込部と、テスト観点データ読込部と、設計情報トレース管理部と、テスト仕様書生成部とを持つ。設計情報読込部は、テスト対象の設計書を複数読み込み、複数の設計書の各々に含まれる設計情報をモデルに分解する。テスト観点データ読込部は、テスト観点データを読み込む。設計情報トレース管理部は、複数の設計書の各々に含まれる設計情報をモデルに分解した結果に基づきモデル間の対応関係を定義する。テスト仕様書生成部は、テスト観点データと、複数の設計書の各々に含まれる設計情報をモデルに分解した結果と、モデル間の対応関係を定義した結果とに基づいて、複数の設計書のテスト項目を生成し、生成したテスト項目に基づいてテスト仕様書を生成する。
【選択図】図２
【特許請求の範囲】
【請求項1】
設計書のテスト仕様書を作成する情報処理装置において、
テスト対象の設計書を複数読み込み、読み込んだ複数の前記設計書の各々に含まれる設計情報をモデルに分解する設計情報読込部と、
テスト観点データを読み込むテスト観点データ読込部と、
複数の前記設計書の各々に含まれる設計情報をモデルに分解した結果に基づいて、モデル間の対応関係を定義する設計情報トレース管理部と、
前記テスト観点データ読込部が読み込んだ前記テスト観点データと、前記設計情報読込部によって複数の前記設計書の各々に含まれる設計情報をモデルに分解した結果と、前記設計情報トレース管理部によってモデル間の対応関係を定義した結果とに基づいて、複数の前記設計書のテスト項目を生成し、生成した前記テスト項目に基づいてテスト仕様書を生成するテスト仕様書生成部と
を備える、情報処理装置。
テスト対象の設計書を複数読み込み、読み込んだ複数の前記設計書の各々に含まれる設計情報をモデルに分解する設計情報読込部と、
テスト観点データを読み込むテスト観点データ読込部と、
複数の前記設計書の各々に含まれる設計情報をモデルに分解した結果に基づいて、モデル間の対応関係を定義する設計情報トレース管理部と、
前記テスト観点データ読込部が読み込んだ前記テスト観点データと、前記設計情報読込部によって複数の前記設計書の各々に含まれる設計情報をモデルに分解した結果と、前記設計情報トレース管理部によってモデル間の対応関係を定義した結果とに基づいて、複数の前記設計書のテスト項目を生成し、生成した前記テスト項目に基づいてテスト仕様書を生成するテスト仕様書生成部と
を備える、情報処理装置。
【請求項2】
メタ情報に対して定義された検証ルールに基づいて、複数の前記設計書の各々に含まれる設計情報をモデルに分解した結果に設計漏れがあるか否かを検証する設計情報検証管理部
をさらに備え、
前記テスト仕様書生成部は、前記設計情報検証管理部によって設計漏れがないとされた設計情報をモデルに分解した結果に基づいて、複数の前記設計書のテスト項目を生成し、生成した前記テスト項目に基づいてテスト仕様書を生成する、請求項１に記載の情報処理装置。
をさらに備え、
前記テスト仕様書生成部は、前記設計情報検証管理部によって設計漏れがないとされた設計情報をモデルに分解した結果に基づいて、複数の前記設計書のテスト項目を生成し、生成した前記テスト項目に基づいてテスト仕様書を生成する、請求項１に記載の情報処理装置。
【請求項3】
メタ情報に対して定義された検証ルールに基づいて、複数の前記設計書の各々に含まれる設計情報をモデルに分解した結果に誤りが無いか否かを検証する設計情報検証管理部
をさらに備え
前記テスト仕様書生成部は、前記設計情報検証管理部によって誤りが無いとされた設計情報をモデルに分解した結果に基づいて、複数の前記設計書のテスト項目を生成し、生成した前記テスト項目に基づいてテスト仕様書を生成する、請求項１に記載の情報処理装置。
をさらに備え
前記テスト仕様書生成部は、前記設計情報検証管理部によって誤りが無いとされた設計情報をモデルに分解した結果に基づいて、複数の前記設計書のテスト項目を生成し、生成した前記テスト項目に基づいてテスト仕様書を生成する、請求項１に記載の情報処理装置。
【請求項4】
前記設計情報トレース管理部は、複数の前記設計書の各々に含まれる設計情報をモデルに分解して得られるクラス図に含まれる項目間の対応関係を定義する、請求項１に記載の情報処理装置。
【請求項5】
前記テスト仕様書生成部は、生成した前記テスト項目の値を、前記設計情報をモデルに分解した結果から取得する、請求項１に記載の情報処理装置。
【請求項6】
前記テスト仕様書生成部は、生成した前記テスト項目の値を、前記設計情報をモデルに分解した結果から、前記モデル間の対応関係を定義した結果を使用して取得する、請求項１に記載の情報処理装置。
【請求項7】
設計書のテスト仕様書を作成する情報処理装置が実行する情報処理方法において、
テスト対象の設計書を複数読み込み、読み込んだ複数の前記設計書の各々に含まれる設計情報をモデルに分解し、
テスト観点データを読み込み、
複数の前記設計書の各々に含まれる設計情報をモデルに分解した結果に基づいて、モデル間の関連を定義し、
前記テスト観点データと、複数の前記設計書の各々に含まれる設計情報をモデルに分解した結果と、モデル間の関連を定義した結果とに基づいて、複数の前記設計書のテスト項目を生成し、生成した前記テスト項目に基づいてテスト仕様書を生成する、情報処理方法。
テスト対象の設計書を複数読み込み、読み込んだ複数の前記設計書の各々に含まれる設計情報をモデルに分解し、
テスト観点データを読み込み、
複数の前記設計書の各々に含まれる設計情報をモデルに分解した結果に基づいて、モデル間の関連を定義し、
前記テスト観点データと、複数の前記設計書の各々に含まれる設計情報をモデルに分解した結果と、モデル間の関連を定義した結果とに基づいて、複数の前記設計書のテスト項目を生成し、生成した前記テスト項目に基づいてテスト仕様書を生成する、情報処理方法。
【請求項8】
コンピュータに
テスト対象の設計書を複数読み込ませ、読み込ませた複数の前記設計書の各々に含まれる設計情報をモデルに分解させ、
テスト観点データを読み込ませ、
複数の前記設計書の各々に含まれる設計情報をモデルに分解した結果に基づいて、モデル間の関連を定義させ、
前記テスト観点データと、複数の前記設計書の各々に含まれる設計情報をモデルに分解した結果と、モデル間の関連を定義した結果とに基づいて、複数の前記設計書のテスト項目を生成させ、生成させた前記テスト項目に基づいてテスト仕様書を生成させる、プログラム。
テスト対象の設計書を複数読み込ませ、読み込ませた複数の前記設計書の各々に含まれる設計情報をモデルに分解させ、
テスト観点データを読み込ませ、
複数の前記設計書の各々に含まれる設計情報をモデルに分解した結果に基づいて、モデル間の関連を定義させ、
前記テスト観点データと、複数の前記設計書の各々に含まれる設計情報をモデルに分解した結果と、モデル間の関連を定義した結果とに基づいて、複数の前記設計書のテスト項目を生成させ、生成させた前記テスト項目に基づいてテスト仕様書を生成させる、プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明の実施形態は、情報処理装置、情報処理方法およびプログラムに関する。
【背景技術】
【0002】
システムおよびソフトウェアの開発を行う際には、これらの作業のアウトプットとしてドキュメントを別途作成する必要がある。このドキュメントとしては、例えば、設計の図面やプログラムの仕様等があり、作成はＣＡＳＥ（Computer Aided Software Engineering）ツール等を用いて行われる。
【0003】
なお、システムおよびソフトウェアの開発では、分析、設計、開発、テストのライフサイクルを考慮する必要がある。これらのライフサイクルの入力情報は、顧客からの要件を基に決定される。この顧客要件は、ライフサイクルを通じて、要求仕様、機能仕様、設計仕様、テストシナリオ、コンポーネント、テスト結果、製品等に具体化される。同様に、ライフサイクルを通じて、要求仕様書、機能仕様書、ソフトウェア・システム設計書、テスト仕様書、テスト成績書、詳細設計書、テスト完了報告書、出荷報告書等のドキュメントに文書化される。
【0004】
テスト仕様書の作成は人手で賄われており、多くのコストを費やしている。例えば、テスト項目の洗い出しは、テスト設計者の経験に依存している。このため、テスト項目の洗い出しは、熟練した技術者であっても、抜け漏れなく設計するのは困難である。
【0005】
システムおよびソフトウェアの仕様の定義決定、登録、更新等を行い、この仕様を基に正式なドキュメントを正確に作成する技術が知られている（例えば、特許文献１参照）。この技術ではシステムおよびソフトウェアの仕様を定義した成果物をメタモデルに分類して定義・管理する。また、この技術では、クラス名、親クラス名、クラス制約条件が定義される。また、この技術では、設計情報が制約条件を満たすか否かが検証される。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】特開２０１３－２５４５０３号公報
【発明の概要】
【発明が解決しようとする課題】
【0007】
本発明が解決しようとする課題は、テスト仕様書の作成工数を削減できる情報処理装置、情報処理方法およびプログラムを提供することである。
【課題を解決するための手段】
【0008】
実施形態の情報処理装置は、設計情報読込部と、テスト観点データ読込部と、設計情報トレース管理部と、テスト仕様書生成部とを持つ。前記設計情報読込部は、テスト対象の設計書を複数読み込み、読み込んだ複数の前記設計書の各々に含まれる設計情報をモデルに分解する。前記テスト観点データ読込部は、テスト観点データを読み込む。前記設計情報トレース管理部は、複数の前記設計書の各々に含まれる設計情報をモデルに分解した結果に基づいて、モデル間の対応関係を定義する。前記テスト仕様書生成部は、前記テスト観点データ読込部が読み込んだ前記テスト観点データと、前記設計情報読込部によって複数の前記設計書の各々に含まれる設計情報をモデルに分解した結果と、前記設計情報トレース管理部によってモデル間の対応関係を定義した結果とに基づいて、複数の前記設計書のテスト項目を生成し、生成した前記テスト項目に基づいてテスト仕様書を生成する。
【図面の簡単な説明】
【0009】
【図1】モデルのデータ形式の一例を示す図
【図2】本実施形態の情報処理装置の一例を示す図
【図3A】本実施形態の情報処理装置によって実行される処理の一例を示す図
【図3B】本実施形態の情報処理装置によって実行される処理の一例を示す図
【図3C】本実施形態の情報処理装置によって実行される処理の一例を示す図
【図4】テスト観点一覧表の一例を示す図
【図5A】本実施形態の情報処理装置によって実行される処理の一例を示す図
【図5B】本実施形態の情報処理装置によって実行される処理の一例を示す図
【図6】本実施形態の情報処理装置によって実行される処理の一例を示す図
【図7】本実施形態の情報処理装置の動作の一例を示すフローチャート
【図8】本実施形態の情報処理装置の動作の一例を示すフローチャート
【図9】本実施形態の情報処理装置の動作の一例を示すフローチャート
【図10】実施形態の変形例の情報処理装置の一例を示す図
【発明を実施するための形態】
【0010】
以下、実施形態の情報処理装置、情報処理方法およびプログラムを、図面を参照して説明する。なお以下の説明では、同一または類似の機能を有する構成に同一の符号を付す。そして、それら構成の重複する説明は省略する場合がある。
【0011】
（実施形態）
＜モデルのデータ形式＞
図１は、モデルのデータ形式の一例を示す図である。モデルのデータ形式とは、管理者が設計メタ情報を定義する際にベースとする、設計モデル、ドキュメント、これらの間の関連情報の基礎情報となる。
＜モデルのデータ形式＞
図１は、モデルのデータ形式の一例を示す図である。モデルのデータ形式とは、管理者が設計メタ情報を定義する際にベースとする、設計モデル、ドキュメント、これらの間の関連情報の基礎情報となる。
【0012】
（設計メタ情報）
モデルのデータ形式は、設計メタ情報として、モデルのデータ形式である「モデルクラス」「モデル間関連クラス」、「ドキュメントクラス」、「モデルドキュメント間関連クラス」を基底クラスとして備える。なお、クラスとは、オブジェクト指向の技術分野にて定義されたデータの型を指す。
モデルのデータ形式は、設計メタ情報として、モデルのデータ形式である「モデルクラス」「モデル間関連クラス」、「ドキュメントクラス」、「モデルドキュメント間関連クラス」を基底クラスとして備える。なお、クラスとは、オブジェクト指向の技術分野にて定義されたデータの型を指す。
【0013】
図１は、オブジェクト指向技術記法であるＵＭＬ（Unified Modeling Language）に則って記載されたクラス図であり、長方形はクラスを表し、長方形間の直線はクラス間の関連を表す。クラス内は、３つに分けて表現され、上段はクラス名、中段は属性、下段には操作が記述される。全ての操作１ｃ，操作２ｃ，操作３ｃおよび操作４ｃは、斜体文字で示されている。
【0014】
操作１ｃ～操作４ｃは、抽象操作を示し、本クラスを継承するクラスを管理者が定義する際に、本クラスの特性に応じて、操作の実体を再定義する。
【0015】
モデルクラス１は、開発のライフサイクルを通じて作成する仕様の最小単位の型である。モデルクラスのデータは、この型のデータである。また、モデルクラス１は、全てのモデルクラスの親クラスであり、管理者は、当該クラスの子クラスとして、具体的なモデル毎にモデルクラスを定義する。
【0016】
モデルクラス１は、クラス名１ａとして「モデル」、属性１ｂとして「モデル名」、「モデルＩＤ」、「バーション」、「修正可能性フラグ」、「変更履歴」、この他「識別子」等の属性を備える。操作１ｃとしては「クラス制約条件検証（ ）」操作、「インスタンス制約条件検証（ ）」操作、「特定インスタンス制約条件検証（ ）」操作を備える。なお、これら操作の制約条件については後述する。
【0017】
属性１ｂの「Ｆｒｏｍ」には関連元のクラス名、「Ｔｏ」には関連先のクラス名、「バーション」にはバーション情報を、「修正可能性フラグ」には修正が必要となる可能性のあるフラグ“ＯＮ”又は修正不要フラグ“ＯＦＦ”を、「変更履歴」には変更済みの履歴情報を記載する。
【0018】
モデルクラス１を継承してあらたにクラスを定義する場合、操作１ｃの「クラス制約条件検証（ ）」操作および「インスタンス制約条件検証（ ）」操作は、管理者が定義する。「特定インスタンス制約条件検証（ ）」操作は、新たに定義したクラスのインスタンスを定義する際、ユーザが定義する。
【0019】
複数のモデルクラス１の間には、親と子の関係を備える場合がある。この場合の親子関係とは、親の要素として、子となるクラスが対応する、全体と部分の関係を持つことを指す。
【0020】
モデル間関連クラス２は、モデルとして定義した任意の２つのモデル間の関連の型である。モデル間関連クラスのデータは、この型のデータである。開発のライフサイクルを通じて作成する仕様には様々な種類があり、入力関係、参照関係、設計と対応する検証仕様の関係等の関連にも様々な種類がある為、これらの関連をモデル間関連クラス２にて定義する。
【0021】
モデル間関連クラス２は、全てのモデル間関連クラスの親クラスであり、管理者は当該クラスの子クラスとしてドキュメントに含まれる具体的なモデル間関連毎にモデル間関連クラスを定義する。
【0022】
モデル間関連クラス２は、クラス名２ａとして「モデル間関連」、属性２ｂとしてモデルクラス１の属性１ｂと同様の「Ｆｒｏｍ」、「Ｔｏ」、「バーション」、「修正可能性フラグ」、「変更履歴」、この他「説明」、「関連元モデルリスト」、「関連先モデルリスト」等の属性を備える。操作２ｃとしてはモデルクラス１の操作３ｃと同様の操作と、必要に応じて「制約条件による関連の検証」の操作も備える。
【0023】
ドキュメントクラス３は、開発のライフルサイクルを通じて作成するドキュメント（文書）の最小単位の型である。ドキュメントクラスのデータは、この型のデータである。また、ドキュメントクラス３は、全てのドキュメントクラスの親クラスであり、管理者は当該クラスの子クラスとして具体的なドキュメント毎にドキュメントクラスを定義する。
ドキュメントクラス３は、クラス名３ａとして「ドキュメント」、属性３ｂとしてモデルクラス１の属性１ｂと同様の「ドキュメント名称」、「ドキュメントＩＤ」、「バーション」、「修正可能性フラグ」、「変更履歴」、この他「識別子」、「説明」、「サブドキュメントリスト」等の属性を備える。操作３ｃとしては、モデルクラス１と同様の操作を備える。
ドキュメントクラス３は、クラス名３ａとして「ドキュメント」、属性３ｂとしてモデルクラス１の属性１ｂと同様の「ドキュメント名称」、「ドキュメントＩＤ」、「バーション」、「修正可能性フラグ」、「変更履歴」、この他「識別子」、「説明」、「サブドキュメントリスト」等の属性を備える。操作３ｃとしては、モデルクラス１と同様の操作を備える。
【0024】
複数のドキュメントクラス３の間には、親と子の関係を備える場合がある。この場合の親子関係とは、親の要素として、子となるクラスが対応する、全体と部分の関係を持つことを指す。
【0025】
モデルドキュメント間関連クラス４は、「モデル」、「ドキュメント」として定義した、任意のモデルとドキュメントの間の関連の型である。モデルドキュメント間関連クラスのデータは、この型のデータである。開発のライフサイクルを通じて作成するドキュメントは、同じく開発のライフサイクルを通じて作成する仕様情報であり「モデル」の情報に基づいて文章として作成する。このとき「モデル」と「ドキュメント」の関係には、要求と要求仕様書、設計仕様と設計仕様書、テストシナリオとテスト仕様書等の様々な関連が存在するため、そのような関連の型をモデルドキュメント間関連クラス４にて定義する。
【0026】
また、モデルドキュメント間関連クラス４は、全てのモデルドキュメント間関連クラスの親クラスであり、管理者は当該クラスの子クラスとしてドキュメントに含まれる具体的なモデルドキュメント間関連毎にモデルドキュメント間関連クラスを定義する。
【0027】
モデルドキュメント間関連クラス４は、クラス名４ａとして「モデルドキュメント間関連」、属性４ｂとしてモデルクラス１の属性１ｂと同様の「Ｆｒｏｍ」「Ｔｏ」「バーション」「修正可能性フラグ」「変更履歴」、この他「説明関連元モデルリスト」「関連先ドキュメントリスト」等の属性を備える。操作４ｃとしてモデルクラス１の操作１ｃと同様であり、必要に応じて「制約条件による関連の検証」の操作を備える。
【0028】
（設計情報）
設計情報は、上記した４つの各クラスによって作成されるデータの実態であり、「モデルインスタンス」、「モデル間関連インスタンス」、「ドキュメントインスタンス」、「モデルドキュメント関連インスタンス」を備える。なお、図示しないが、これらのインスタンスも図１のクラスと同様に、インスタンス内は、３つに分けて表現され、上段にはインスタンスの名称、中段には属性、下段には操作が記述される。操作は、抽象操作を示す。操作の実体は、上記した親クラスを継承するインスタンスをユーザが定義する際に、親クラスの特性に応じて、定義する。
設計情報は、上記した４つの各クラスによって作成されるデータの実態であり、「モデルインスタンス」、「モデル間関連インスタンス」、「ドキュメントインスタンス」、「モデルドキュメント関連インスタンス」を備える。なお、図示しないが、これらのインスタンスも図１のクラスと同様に、インスタンス内は、３つに分けて表現され、上段にはインスタンスの名称、中段には属性、下段には操作が記述される。操作は、抽象操作を示す。操作の実体は、上記した親クラスを継承するインスタンスをユーザが定義する際に、親クラスの特性に応じて、定義する。
【0029】
モデルインスタンスは、開発のライフサイクルを通じて作成する仕様の最小単位の実体である。モデルインスタンスのデータは、この実体のデータである。モデルインスタンスの属性としては、親となるモデルクラスの識別子、インスタンスの識別子および名称（説明）、子となるモデルインスタンスの識別子を備える。モデルインスタンスの操作としては、必要に応じて、制約条件による仕様検証の操作を備える。
【0030】
モデル間関連インスタンスは、モデルインスタンスとして定義した任意の２つのモデルインスタンス間の関連情報であり、モデル間関連クラスとして、定義した関連の型の実体である。モデル間関連インスタンスのデータは、この実体のデータである。モデル間関連インスタンスの属性としては、親となるモデル間関連識別子、関連元のモデルインスタンス識別子、関連先のモデルインスタンス識別子を備える。モデル間関連インスタンスの操作としては、必要に応じ、制約条件による関連の検証の操作を備える。
【0031】
ドキュメントインスタンスは、開発のライフサイクルを通じて作成するドキュメント（文書）の最小単位の実体である。ドキュメントインスタンスのデータは、この実体のデータである。ドキュメントインスタンスの属性としては、親となるドキュメントクラスの識別子、ドキュメントインスタンスの識別子および名称（説明）、子となるドキュメントインスタンスの識別子を備える。ドキュメントインスタンスの操作としては、必要に応じ、制約条件によるドキュメント検証の操作を備える。
【0032】
モデルドキュメント間関連インスタンスは、モデルインスタンスとドキュメントインスタンスとして定義した、任意のモデルインスタンスとドキュメントインスタンス間の関連情報であり、モデルドキュメント間関連クラスとして定義した関連の型の実体である。モデルドキュメント間関連インスタンスのデータは、この実体のデータである。モデルドキュメント間関連インスタンスの属性としては、親となるモデルドキュメント間関連識別子、関連元のモデルインスタンス識別子、関連先のドキュメントインスタンス識別子を備える。モデルドキュメント間関連インスタンスの操作としては、必要に応じ、制約条件による関連の検証の操作を備える。
【0033】
（制約条件）
設計メタ情報において、図１の操作１ｃ，操作２ｃ，操作３ｃおよび操作４ｃの「クラス制約条件検証（ ）」操作、「インスタンス制約条件検証（ ）」操作、「特定インスタンス制約条件検証（ ）」操作を備え、設計情報である４つのインスタンスも各操作を備えると上述したが、以下でこれらクラスおよびインスタンスを定義するための制約条件について説明する。
設計メタ情報において、図１の操作１ｃ，操作２ｃ，操作３ｃおよび操作４ｃの「クラス制約条件検証（ ）」操作、「インスタンス制約条件検証（ ）」操作、「特定インスタンス制約条件検証（ ）」操作を備え、設計情報である４つのインスタンスも各操作を備えると上述したが、以下でこれらクラスおよびインスタンスを定義するための制約条件について説明する。
【0034】
制約条件は、「モデル」、「モデル間関連」、「ドキュメント」、および「モデルドキュメント間関連」のそれぞれに、必要に応じて、設定するルールである。具体的に制約条件としては、例えば「テスト」というモデルであれば、テストモデルの一つ一つには「入力と出力が定義されていなければならない」、テストモデルの集合には、「機能モデルから関連されていないテストモデルは存在してはならない」等のルールを設定する。
【0035】
制約条件には、クラスに関する制約条件、クラスに属するインスタンスに広く適用される制約条件、ある特定のインスタンスにだけ適用される制約条件がある。クラスの制約条件とインスタンスの制約条件は、モデルクラス１、モデル間関連クラス２、ドキュメントクラス３およびモデルドキュメント間関連クラス４において、管理者が必要に応じて、「クラス制約条件検証（ ）」操作、「インスタンス制約条件検証（ ）」操作として定義する。また、特定のインスタンスの制約条件は、各クラスのインスタンスにおいて、ユーザが必要に応じて、「特定インスタンス制約条件検証( )」操作として定義する。
【0036】
＜情報処理装置＞
図２は、本実施形態の情報処理装置の一例を示す図である。本実施形態の情報処理装置１０は、パーソナルコンピュータ、サーバ、スマートフォン、タブレットコンピュータ又は産業用コンピュータ等の装置によって実現される。
情報処理装置１０は、設計書のテスト仕様書を作成する。情報処理装置１０は、設計情報読込部１１と、テスト観点データ読込部１２と、設計情報記憶部１３と、設計情報トレース管理部１４と、トレース記憶部１５と、テスト仕様書生成部１６とを備える。
図２は、本実施形態の情報処理装置の一例を示す図である。本実施形態の情報処理装置１０は、パーソナルコンピュータ、サーバ、スマートフォン、タブレットコンピュータ又は産業用コンピュータ等の装置によって実現される。
情報処理装置１０は、設計書のテスト仕様書を作成する。情報処理装置１０は、設計情報読込部１１と、テスト観点データ読込部１２と、設計情報記憶部１３と、設計情報トレース管理部１４と、トレース記憶部１５と、テスト仕様書生成部１６とを備える。
【0037】
設計情報読込部１１は、設計書テンプレートに基づいて作成された設計書を読み込む。設計書の一例は、テスト対象の設計書である。設計情報読込部１１は、読み込んだ設計書に含まれる設計情報をモデルに分解する。設計情報読込部１１は、設計情報とともに、設計書に含まれる情報をモデルに分解した結果を、設計情報記憶部１３に記憶させる。
【0038】
図３Ａは、本実施形態の情報処理装置によって実行される処理の一例を示す図である。図３Ａは、一例として、設計情報読込部１１が、画面の設計書テンプレートに基づいて作成された画面一覧表を読み込み、読み込んだ画面一覧表をモデルに分解して得られるクラス図を示す。クラス内は、複数に分けて表現され、図３Ａによれば、クラス内は、項目として、仕様クラス、画面ＩＤ、画面名、説明が定義されて、それぞれ、仕様クラス、画面ＩＤ、画面名、説明が記述される。
【0039】
仕様クラスは、画面一覧表における仕様のデータの型であり、例えば「画面」などが記述される。画面ＩＤは、画面の識別情報であり、例えば「ＩＭＧ０１」、「ＩＭＧ０２」、「ＩＭＧ０３」などが記述される。画面名は、画面の名称であり、例えば「画面０１」、「画面０２」、「画面０３」などが記述される。説明は、画面一覧表における仕様についての記述であり、例えば仕様の内容が記述される。
【0040】
設計情報読込部１１は、画面一覧表をモデルに分解することによって、仕様クラスとして「画面」、画面ＩＤとして「ＩＭＧ０１」、画面名として「画面０１」、説明として「・・・」をクラス図に含める。また、設計情報読込部１１は、画面一覧表をモデルに分解することによって、仕様クラスとして「画面」、画面ＩＤとして「ＩＭＧ０２」、画面名として「画面０２」、説明として「・・・」をクラス図に含める。
【0041】
また、設計情報読込部１１は、画面一覧表をモデルに分解することによって、仕様クラスとして「画面」、画面ＩＤとして「ＩＭＧ０３」、画面名として「画面０３」、説明として「・・・」をクラス図に含める。設計情報読込部１１は、画面一覧表をモデルに分解することによって得られたクラス図を、設計情報記憶部１３に記憶させる。
【0042】
図３Ｂは、本実施形態の情報処理装置によって実行される処理の一例を示す図である。図３Ｂは、一例として、設計情報読込部１１が、画面項目の設計書テンプレートに基づいて作成された画面項目仕様書を読み込み、読み込んだ画面項目仕様書をモデルに分解して得られるクラス図を示す。クラス内は、複数に分けて表現され、図３Ｂによれば、クラス内は、項目として、仕様クラス、画面項目ＩＤ、画面項目名、要素タイプ、ラベルが定義されて、それぞれ、仕様クラス、画面項目ＩＤ、画面項目名、要素タイプ、ラベルが記述される。
【0043】
仕様クラスは、画面項目仕様書における仕様のデータの型であり、例えば「画面項目」などが記述される。画面項目ＩＤは、画面項目の識別情報であり、例えば「ＩＭＧ０１．０１」、「ＩＭＧ０１．０２」、「ＩＭＧ０１．０３」などが記述される。画面項目名は、画面項目の名称であり、例えば「タイトル」、「○○ラベル」、「××ボタン」などが記述される。要素タイプは、画面項目の型（種類）であり、例えば「タイトル」、「ラベル」、「ボタン」などが記述される。ラベルは、画面項目仕様書における仕様についての記述であり、例えば仕様の内容が記述される。
【0044】
設計情報読込部１１は、画面項目仕様書をモデルに分解することによって、仕様クラスとして「画面項目」、画面項目ＩＤとして「ＩＭＧ０１．０１」、画面項目名として「タイトル」、要素タイプとして「タイトル」、ラベルとして「・・・」をクラス図に含める。また、設計情報読込部１１は、画面一覧表をモデルに分解することによって、仕様クラスとして「画面項目」、画面項目ＩＤとして「ＩＭＧ０１．０２」、画面項目名として「○○ラベル」、要素タイプとして「ラベル」、ラベルとして「・・・」をクラス図に含める。
【0045】
また、設計情報読込部１１は、画面一覧表をモデルに分解することによって、仕様クラスとして「画面項目」、画面項目ＩＤとして「ＩＭＧ０１．０３」、画面項目名として「××ボタン」、要素タイプとして「ボタン」、ラベルとして「・・・」をクラス図に含める。設計情報読込部１１は、画面項目仕様書をモデルに分解することによって得られたクラス図を、設計情報記憶部１３に記憶させる。
【0046】
図３Ｃは、本実施形態の情報処理装置によって実行される処理の一例を示す図である。図３Ｃは、一例として、設計情報読込部１１が、画面項目処理の設計書テンプレートに基づいて作成された画面項目処理仕様書を読み込み、読み込んだ画面項目処理仕様書をモデルに分解して得られるクラス図を示す。
クラス内は、複数に分けて表現され、図３Ｃによれば、クラス内は、項目として、仕様クラス、アクションＩＤ、アクション名、イベント、対応項目名、アクション詳細、処理説明が定義されて、それぞれ、仕様クラス、アクションＩＤ、アクション名、イベント、対応項目名、アクション詳細、処理説明が記述される。
クラス内は、複数に分けて表現され、図３Ｃによれば、クラス内は、項目として、仕様クラス、アクションＩＤ、アクション名、イベント、対応項目名、アクション詳細、処理説明が定義されて、それぞれ、仕様クラス、アクションＩＤ、アクション名、イベント、対応項目名、アクション詳細、処理説明が記述される。
【0047】
仕様クラスは、画面項目処理仕様書における仕様のデータの型であり、例えば「アクション」などが記述される。アクションＩＤは、アクションの識別情報であり、例えば「ＡＣＴ０１．０１」、「ＡＣＴ０１．０２」、「ＡＣＴ０１．０３」などが記述される。アクション名は、アクションの名称であり、例えば「初期表示」、「××ボタンクリック時の正常終了」、「××ボタンクリック時の異常終了」などが記述される。イベントは、画面のアクションが発生する条件であり、例えば「××ボタンをクリック」などが記述される。対応項目名は、画面のアクションと対応する画面項目であり、例えば「××ボタン」などが記述される。アクション詳細は、アクションについての記述であり、例えばアクションの内容が記述される。処理説明は、処理についての記述であり、例えば処理の内容が記述される。
【0048】
設計情報読込部１１は、画面項目処理仕様書をモデルに分解することによって、仕様クラスとして「アクション」、アクションＩＤとして「ＡＣＴ０１．０１」、アクション名として「初期表示」、イベントとして「・・・」、対応項目名として「・・・」、アクション詳細として「・・・」、処理説明として「・・・」をクラス図に含める。
設計情報読込部１１は、画面項目処理仕様書をモデルに分解することによって、仕様クラスとして「アクション」、アクションＩＤとして「ＡＣＴ０１．０２」、アクション名として「××ボタンクリック時の正常終了」、イベントとして「・・・」、対応項目名として「・・・」、アクション詳細として「・・・」、処理説明として「・・・」をクラス図に含める。
設計情報読込部１１は、画面項目処理仕様書をモデルに分解することによって、仕様クラスとして「アクション」、アクションＩＤとして「ＡＣＴ０１．０２」、アクション名として「××ボタンクリック時の正常終了」、イベントとして「・・・」、対応項目名として「・・・」、アクション詳細として「・・・」、処理説明として「・・・」をクラス図に含める。
【0049】
設計情報読込部１１は、画面項目処理仕様書をモデルに分解することによって、仕様クラスとして「アクション」、アクションＩＤとして「ＡＣＴ０１．０３」、アクション名として「××ボタンクリック時の異常終了」、イベントとして「・・・」、対応項目名として「・・・」、アクション詳細として「・・・」、処理説明として「・・・」をクラス図に含める。設計情報読込部１１は、画面項目処理仕様書をモデルに分解することによって得られたクラス図を、設計情報記憶部１３に記憶させる。図２に戻り、説明を続ける。
【0050】
テスト観点データ読込部１２は、テスト観点定義テンプレートに基づいて作成されたテスト観点一覧表を読み込む。テスト観点一覧表の一例は、テストの観点を一覧にしたものである。テスト観点データ読込部１２は、読み込んだテスト観点一覧表を、設計情報記憶部１３に記憶させる。
【0051】
図４は、テスト観点一覧表の一例を示す図である。図４は、一例として、テスト観点データ読込部１２が読み込むテスト観点一覧表を示す。テスト観点一覧表は、複数の項目を含み、図４によれば、項目として、テスト観点ＩＤ、テスト観点＿大、テスト観点＿中、テスト観点＿小、テスト分類、テスト工程、仕様クラス、属性名、属性値、説明、操作、確認が定義され、それぞれ、テスト観点ＩＤ、テスト観点＿大、テスト観点＿中、テスト観点＿小、テスト分類、テスト工程、仕様クラス、属性名、属性値、説明、操作、確認が記述される。
【0052】
テスト観点ＩＤはテスト観点の識別情報であり、例えば、「ＫＡＮＴＥＮ０１」、「ＫＡＮＴＥＮ０２」、「ＫＡＮＴＥＮ０３」などが記述される。テスト観点＿大は、テストの大項目であり、例えば、「画面系」などが記述される。テスト観点＿中は、テストの中項目であり、例えば、「画面仕様」、「画面項目仕様」、「画面項目処理仕様」などが記述される。テスト観点＿小は、テストの小項目であり、例えば、「画面名」、「ラベル」、「アクション」などが記述される。テスト分類は、テストの分類であり、例えば、「画面」などが記述される。テスト工程は、テストの種類であり、例えば、「単体テスト」などが記述される。
【0053】
仕様クラス、属性名および属性値は、生成するテストの内容を判定するための定義である。仕様クラス、属性名および属性値は、テスト対象となる仕様クラスとＩＤで紐付くことを前提とする。仕様クラスのみが定義されている場合には前提を満たす仕様クラスの仕様データが存在することをテストする。仕様クラスおよび属性名が定義されている場合には前提を満たす仕様クラスの仕様データの属性名に任意のデータが定義されていることをテストする。仕様クラス、属性名および属性値が定義されている場合には前提を満たす仕様クラスの仕様データの属性名に属性値のデータが定義されていることをテストする。
【0054】
仕様クラスは、テスト観点一覧表における仕様のデータの型であり、であり、例えば、画面、画面項目、アクションなどが記述される。属性名は、テスト観点の属性の名称であり、例えば、画面名、ラベル、イベントなどが記述される。属性値は、テスト対象となる設計情報の値を固定値として定義したものであり、例えば、画面項目の場合、仕様クラスには「画面項目」、属性名には「タイプ」、属性値には「プルダウンメニュー」などが記述される。
【0055】
説明は、テスト観点の説明であり、例えば、「画面名の確認」、「画面項目ラベルの確認」、「画面項目アクションの確認」などが記述される。操作は、テストの方法であり、例えば、「「[ｓｐｅｃ：画面名]」を初期状態で表示させる。」、「「[ｓｐｅｃ：画面名]」を初期状態で表示させて、画面上の画面項目「[ｓｐｅｃ：画面項目名]」を表示させる。」、「「[ｓｐｅｃ：画面名]」を初期状態で表示させて、画面項目「[ｓｐｅｃ：画面項目名]」で「[ｓｐｅｃ：イベント]」をして、以下の処理をする。［ｓｐｅｃ：処理説明］」などが記述される。ここで、［ｓｐｅｃ：ＸＸＸ］タグは設計情報の値を動的に埋め込むためのタグ情報である。
【0056】
確認は、テストの結果の確認方法であり、例えば、「画面名として「[ｓｐｅｃ：画面名]」が表示されていることを確認する。」、「ラベルが「[ｓｐｅｃ：ラベル]」であることを確認する。」、「以下のアクションが行われることを確認する。[ｓｐｅｃ：アクション詳細]」などが記述される。
【0057】
テスト観点データ読込部１２は、読み込んだテスト観点一覧表に基づいて、テスト観点ＩＤとして「ＫＡＮＴＥＮ０１」、テスト観点＿大として「画面系」、テスト観点＿中として「画面仕様」、テスト観点＿小として「画面名」、テスト分類として「画面」、テスト工程として「単体テスト」、仕様クラスとして「画面」、属性名として「画面名」、属性値として「－」、説明として「画面名の確認」、操作として「「[ｓｐｅｃ：画面名]」を初期状態で表示させる。」、確認として「画面名として「「[ｓｐｅｃ：画面名]」が表示されていることを確認する。」を関連付けて、設計情報記憶部１３に記憶させる。
【0058】
また、テスト観点データ読込部１２は、読み込んだテスト観点一覧表に基づいて、テスト観点ＩＤとして「ＫＡＮＴＥＮ０２」、テスト観点＿大として「画面系」、テスト観点＿中として「画面項目仕様」、テスト観点＿小として「ラベル」、テスト分類として「画面」、テスト工程として「単体テスト」、仕様クラスとして「画面項目」、属性名として「ラベル」、属性値として「－」、説明として「画面項目ラベルの確認」、操作として「「[ｓｐｅｃ：画面名]」を初期状態で表示させて、画面上の画面項目「[ｓｐｅｃ：画面項目名]」を表示させる。」、確認として「ラベルが「「[ｓｐｅｃ：ラベル]」であることを確認する。」を関連付けて、設計情報記憶部１３に記憶させる。
【0059】
また、テスト観点データ読込部１２は、読み込んだテスト観点一覧表に基づいて、テスト観点ＩＤとして「ＫＡＮＴＥＮ０３」、テスト観点＿大として「画面系」、テスト観点＿中として「画面項目処理仕様」、テスト観点＿小として「アクション」、テスト分類として「画面」、テスト工程として「単体テスト」、仕様クラスとして「アクション」、属性名として「イベント」、属性値として「－」、説明として「画面項目アクションの確認」、操作として「「[ｓｐｅｃ：画面名]」を初期状態で表示させて、画面項目「[ｓｐｅｃ：画面項目名]」で「[ｓｐｅｃ：イベント]」をして、以下の処理をする。[ｓｐｅｃ：処理説明]、確認として「以下のアクションが行われることを確認する。[ｓｐｅｃ：アクション詳細]」を関連付けて、設計情報記憶部１３に記憶させる。図２に戻り、説明を続ける。
【0060】
設計情報記憶部１３は、ＨＤＤ（Hard Disk Drive）やフラッシュメモリ、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）などにより実現される。設計情報記憶部１３には、設計情報と、テスト観点データとが記憶される。設計情報は設計書のデータの実態であり、設計書の情報をモデルに分解した結果を含む。テスト観点データはテスト観点データの実態である。
【0061】
設計情報トレース管理部１４は、モデルの対応関係に基づいて、モデル間の関連を定義する。具体的には、設計情報トレース管理部１４は、設計情報記憶部１３から、複数の設計書の情報の各々をモデルに分解した結果を複数取得し、取得した複数の設計書の情報の各々をモデルに分解した複数の結果間の対応関係に基づいて関連を定義する。設計情報トレース管理部１４は、モデル間の関連を定義した結果をトレース情報として、トレース記憶部１５に記憶させる。
【0062】
具体的には、設計情報トレース管理部１４は、設計情報記憶部１３に記憶された画面一覧表をモデルに分解して得られるクラス図と、画面項目仕様書をモデルに分解して得られるクラス図と、画面項目処理仕様書をモデルに分解して得られるクラス図とを取得する。設計情報トレース管理部１４は、取得した画面一覧表をモデルに分解して得られるクラス図および画面項目仕様書をモデルに分解して得られるクラス図の各々の項目間の対応関係に基づいて関連を定義する。
【0063】
図５Ａは、本実施形態の情報処理装置によって実行される処理の一例を示す図である。設計情報トレース管理部１４は、画面一覧表をモデルに分解して得られるクラス図および画面項目仕様書をモデルに分解して得られるクラス図に基づいて、項目間の対応関係を検出する。例えば、設計情報トレース管理部１４は、画面項目仕様書をモデルに分解して得られるクラス図に含まれる項目に、画面一覧表をモデルに分解して得られるクラス図に含まれる項目があるか否かを判定する。
また、例えば、設計情報トレース管理部１４は、画面一覧表をモデルに分解して得られるクラス図に含まれる項目に、画面項目仕様書をモデルに分解して得られるクラス図に含まれる項目があるか否かを判定する。
また、例えば、設計情報トレース管理部１４は、画面一覧表をモデルに分解して得られるクラス図に含まれる項目に、画面項目仕様書をモデルに分解して得られるクラス図に含まれる項目があるか否かを判定する。
【0064】
例えば、設計情報トレース管理部１４は、画面項目仕様書をモデルに分解して得られるクラス図に含まれる画面項目ＩＤ「ＩＭＧ０１．０１」、「ＩＭＧ０１．０２」および「ＩＭＧ０１．０３」が、画面一覧表をモデルに分解して得られるクラス図に含まれる画面ＩＤ「ＩＭＧ０１」に含まれると判定する。
この場合、設計情報トレース管理部１４は、画面項目仕様書をモデルに分解して得られるクラス図において、項目として、仕様クラス、画面項目ＩＤ、画面項目名、要素タイプおよびラベルに関連して、さらに画面ＩＤを定義し、定義した画面ＩＤとして「ＩＭＧ０１」を記述する。
この場合、設計情報トレース管理部１４は、画面項目仕様書をモデルに分解して得られるクラス図において、項目として、仕様クラス、画面項目ＩＤ、画面項目名、要素タイプおよびラベルに関連して、さらに画面ＩＤを定義し、定義した画面ＩＤとして「ＩＭＧ０１」を記述する。
【0065】
例えば、設計情報トレース管理部１４は、仕様クラスとして「画面項目」、画面項目ＩＤとして「ＩＭＧ０１．０１」、画面項目名として「タイトル」、要素タイプとして「タイトル」、ラベルとして「・・・」に関連して、画面ＩＤとして「ＩＭＧ０１」を記述する。例えば、設計情報トレース管理部１４は、仕様クラスとして「画面項目」、画面項目ＩＤとして「ＩＭＧ０１．０２」、画面項目名として「○○ラベル」、要素タイプとして「ラベル」、ラベルとして「・・・」に関連して、画面ＩＤとして「ＩＭＧ０１」を記述する。
【0066】
例えば、設計情報トレース管理部１４は、仕様クラスとして「画面項目」、画面項目ＩＤとして「ＩＭＧ０１．０３」、画面項目名として「××ボタン」、要素タイプとして「ボタン」、ラベルとして「・・・」に関連して、画面ＩＤとして「ＩＭＧ０１」を記述する。設計情報トレース管理部１４は、画面ＩＤとして「ＩＭＧ０１」を記述したものをトレース情報として、トレース記憶部１５に記憶させる。
【0067】
図５Ｂは、本実施形態の情報処理装置によって実行される処理の一例を示す図である。設計情報トレース管理部１４は、画面項目仕様書をモデルに分解して得られるクラス図および画面項目処理仕様書をモデルに分解して得られるクラス図に基づいて、項目間の対応関係を検出する。
例えば、設計情報トレース管理部１４は、画面項目処理仕様書をモデルに分解して得られるクラス図に含まれる項目に、画面項目仕様書をモデルに分解して得られるクラス図に含まれる項目があるか否かを判定する。
また、例えば、設計情報トレース管理部１４は、画面項目仕様書をモデルに分解して得られるクラス図に含まれる項目に、画面項目処理仕様書をモデルに分解して得られるクラス図に含まれる項目があるか否かを判定する。
例えば、設計情報トレース管理部１４は、画面項目処理仕様書をモデルに分解して得られるクラス図に含まれる項目に、画面項目仕様書をモデルに分解して得られるクラス図に含まれる項目があるか否かを判定する。
また、例えば、設計情報トレース管理部１４は、画面項目仕様書をモデルに分解して得られるクラス図に含まれる項目に、画面項目処理仕様書をモデルに分解して得られるクラス図に含まれる項目があるか否かを判定する。
【0068】
例えば、設計情報トレース管理部１４は、画面項目処理仕様書をモデルに分解して得られるクラス図に含まれるアクションＩＤ「ＡＣＴ０１．０１」、「ＡＣＴ０１．０２」および「ＡＣＴ０１．０３」が、画面項目仕様書をモデルに分解して得られるクラス図に含まれる画面ＩＤ「ＩＭＧ０１」に含まれると判定する。
この場合、設計情報トレース管理部１４は、画面項目処理仕様書をモデルに分解した結果において、項目として、仕様クラス、アクションＩＤ、アクション名、イベント、対応項目名、アクション詳細および処理説明に加え、画面ＩＤを定義し、定義した画面ＩＤとして「ＩＭＧ０１」を記述する。
この場合、設計情報トレース管理部１４は、画面項目処理仕様書をモデルに分解した結果において、項目として、仕様クラス、アクションＩＤ、アクション名、イベント、対応項目名、アクション詳細および処理説明に加え、画面ＩＤを定義し、定義した画面ＩＤとして「ＩＭＧ０１」を記述する。
【0069】
例えば、設計情報トレース管理部１４は、仕様クラスとして「アクション」、アクションＩＤとして「ＡＣＴ０１．０１」、アクション名として「初期表示」、イベントとして「・・・」、対応項目名として「・・・」、アクション詳細として「・・・」、処理説明として「・・・」に関連して、画面ＩＤとして「ＩＭＧ０１」を記述する。
【0070】
例えば、設計情報トレース管理部１４は、仕様クラスとして「アクション」、アクションＩＤとして「ＡＣＴ０１．０２」、アクション名として「××ボタンクリック時の正常終了」、イベントとして「・・・」、対応項目名として「・・・」、アクション詳細として「・・・」、処理説明として「・・・」に関連して、画面ＩＤとして「ＩＭＧ０１」を記述する。
【0071】
例えば、設計情報トレース管理部１４は、仕様クラスとして「アクション」、アクションＩＤとして「ＡＴ０１．０３」、アクション名として「××ボタンクリック時の異常終了」、イベントとして「・・・」、対応項目名として「・・・」、アクション詳細として「・・・」、処理説明として「・・・」に関連して、画面ＩＤとして「ＩＭＧ０１」を記述する。設計情報トレース管理部１４は、画面ＩＤとして「ＩＭＧ０１」を記述したものをトレース情報として、トレース記憶部１５に記憶させる。図２に戻り、説明を続ける。
【0072】
トレース記憶部１５は、ＨＤＤやフラッシュメモリ、ＲＡＭ、ＲＯＭなどにより実現される。トレース記憶部１５には、トレース情報が記憶される。
【0073】
テスト仕様書生成部１６は、設計情報記憶部１３から設計情報およびテスト観点データを取得し、トレース記憶部１５からトレース情報を取得する。テスト仕様書生成部１６は、取得した設計情報、テスト観点データおよびトレース情報に基づいてテスト仕様書を生成する。例えば、テスト仕様書生成部１６は、テスト仕様書テンプレートに基づいてテスト仕様書を作成する。
【0074】
図６は、本実施形態の情報処理装置によって実行される処理の一例を示す図である。図６は、一例として、テスト仕様書生成部１６が、設計情報、テスト観点データおよびトレース情報に基づいてテスト仕様書を生成する処理を示す。テスト仕様書は、複数のテスト項目を含み、図６によれば、テスト項目として、テスト項目ＩＤ、テスト項目名、テスト工程、テスト対象ＩＤ、テスト対象名、種別、区分、操作、確認が定義され、それぞれ、テスト項目ＩＤ、テスト項目名、テスト工程、テスト対象ＩＤ、テスト対象名、種別、区分、操作、確認が記述される。
【0075】
テスト項目ＩＤは、テスト項目の識別情報であり、例えば、「ＫＡＮＴＥＮ０１」、「ＫＡＮＴＥＮ０２」、「ＫＡＮＴＥＮ０３」などが記述される。テスト項目名は、テスト項目の名称であり、例えば、「画面名の確認」、「画面項目ラベルの確認」、「画面項目アクションの確認」などが記述される。
テスト工程は、テストの種類であり、例えば、「単体テスト」などが記述される。テスト対象ＩＤは、テスト対象の識別情報であり、例えば、「ＩＭＧ０１」などが記述される。テスト対象名は、テスト対象の名称であり、例えば、「画面０１」などが記述される。種別は、テストの種別であり、例えば、「機能」などが記述される。区分は、テスト観点のテスト区分として定義されるものであり、例えば、「正常系」、「準正常系」、「異常系」などが記述される。
テスト工程は、テストの種類であり、例えば、「単体テスト」などが記述される。テスト対象ＩＤは、テスト対象の識別情報であり、例えば、「ＩＭＧ０１」などが記述される。テスト対象名は、テスト対象の名称であり、例えば、「画面０１」などが記述される。種別は、テストの種別であり、例えば、「機能」などが記述される。区分は、テスト観点のテスト区分として定義されるものであり、例えば、「正常系」、「準正常系」、「異常系」などが記述される。
【0076】
操作は、テストの方法であり、例えば、「「画面０１」を初期状態で表示させる。」、「「画面０１」を初期状態で表示させて、画面上の画面項目「○○ラベル」を表示させる。」、「「画面０１」を初期状態で表示させて、画面項目「ＸＸボタン」で「ボタンクリック」をして、以下の処理をする。」などが記述される。
ここで、「画面０１」、「○○ラベル」、「××ボタン」および「ボタンクリック」は、テスト仕様書生成部１６によって、［ｓｐｅｃ：ＸＸＸ］タグに該当する値が、設計情報から取得され、取得された値が出力されたものである。
ここで、「画面０１」、「○○ラベル」、「××ボタン」および「ボタンクリック」は、テスト仕様書生成部１６によって、［ｓｐｅｃ：ＸＸＸ］タグに該当する値が、設計情報から取得され、取得された値が出力されたものである。
【0077】
確認は、テストの結果の確認方法であり、例えば、「画面名として「画面０１」が表示されていることを確認する。」、「ラベルが「○○ラベル」であることを確認する。」、「以下のアクションが行われることを確認する。「画面０２」へ画面遷移する」などである。
ここで、「画面０１」、「○○ラベル」および「画面０２」は、テスト仕様書生成部１６によって、［ｓｐｅｃ：ＸＸＸ］タグに該当する値が、設計情報からトレース情報を使用して取得され、取得された値が出力されたものである。
ここで、「画面０１」、「○○ラベル」および「画面０２」は、テスト仕様書生成部１６によって、［ｓｐｅｃ：ＸＸＸ］タグに該当する値が、設計情報からトレース情報を使用して取得され、取得された値が出力されたものである。
【0078】
テスト仕様書生成部１６は、設計情報、テスト観点データおよびトレース情報に基づいて、テスト観点データに含まれる操作を取得し、取得した操作をテスト項目の操作として出力し、テスト観点データに含まれる確認を取得し、取得した確認をテスト項目の確認として出力する。さらに、テスト仕様書生成部１６は、［ｓｐｅｃ：ＸＸ］タグに該当する値を設計情報から取得し、取得した値を［ｓｐｅｃ：ＸＸ］タグの代わりに出力する。
ここで、テスト仕様書生成部１６は、［ｓｐｅｃ：ＸＸ］タグに該当する値を設計情報からトレース情報を使用して取得し、取得した値を［ｓｐｅｃ：ＸＸ］タグの代わりに出力してもよい。
ここで、テスト仕様書生成部１６は、［ｓｐｅｃ：ＸＸ］タグに該当する値を設計情報からトレース情報を使用して取得し、取得した値を［ｓｐｅｃ：ＸＸ］タグの代わりに出力してもよい。
【0079】
具体的には、テスト仕様書生成部１６は、設計情報、テスト観点データおよびトレース情報に基づいて、テスト項目ＩＤとして「ＫＡＮＴＥＮ０１」、テスト項目名として「画面名の確認」、テスト工程として「単体テスト」、テスト対象ＩＤとして「ＩＭＧ０１」、テスト対象名として「画面０１」、種別として「機能」、区分として「正常系」、操作として「「画面０１」を初期状態で表示させる。」、確認として「画面名として「画面０１」が表示されていることを確認する」を生成する。
【0080】
また、具体的には、テスト仕様書生成部１６は、設計情報、テスト観点データおよびトレース情報に基づいて、テスト項目ＩＤとして「ＫＡＮＴＥＮ０２」、テスト項目名として「画面項目ラベルの確認」、テスト工程として「単体テスト」、テスト対象ＩＤとして「ＩＭＧ０１」、テスト対象名として「画面０１」、種別として「機能」、区分として「正常系」、操作として「「画面０１」を初期状態で表示させて、画面上の画面項目「○○ラベル」を表示させる。」、確認として「ラベルが「○○ラベル」であることを確認する」を生成する。
【0081】
また、具体的には、テスト仕様書生成部１６は、設計情報、テスト観点データおよびトレース情報に基づいて、テスト項目ＩＤとして「ＫＡＮＴＥＮ０３」、テスト項目名として「画面項目アクションの確認」、テスト工程として「単体テスト」、テスト対象ＩＤとして「ＩＭＧ０１」、テスト対象名として「画面０１」、種別として「機能」、区分として「正常系」、操作として「「画面０１」を初期状態で表示させて、画面項目「××ボタン」で「ボタンクリック」をして、以下の処理をする」、確認として「以下のアクションが行われることを確認する。画面０２へ画面遷移する」を生成する。テスト仕様書生成部１６は、生成したテスト仕様書を出力する。
【0082】
（情報処理装置の動作）
図７から図９は、本実施形態の情報処理装置１０の動作の一例を示すフローチャートである。図７から図９を参照して、主に、情報処理装置１０がテスト仕様書を生成する処理について説明する。
図７から図９は、本実施形態の情報処理装置１０の動作の一例を示すフローチャートである。図７から図９を参照して、主に、情報処理装置１０がテスト仕様書を生成する処理について説明する。
【0083】
テスト仕様書生成部１６は、テスト対象の仕様クラス（親クラス）からテスト観点情報の仕様クラス属性に定義された値（子クラス）を取得する（ステップＳ１－１）。ステップＳ２－１からＳ３１－１は、子クラスごとに行われる。
テスト仕様書生成部１６は、テスト分類の仕様クラス（親クラス）の設計情報と、テスト観点の仕様クラスの属性の仕様クラス（子クラス）の設計情報との関連性を、トレース情報に基づいてチェックする（ステップＳ２－１）。このとき、テスト仕様書生成部１６は、関連性のチェックを、親クラスの設計情報から子クラスの設計情報と、子クラスの設計情報から親クラスの設計情報との両方をチェックする。
テスト仕様書生成部１６は、テスト分類の仕様クラス（親クラス）の設計情報と、テスト観点の仕様クラスの属性の仕様クラス（子クラス）の設計情報との関連性を、トレース情報に基づいてチェックする（ステップＳ２－１）。このとき、テスト仕様書生成部１６は、関連性のチェックを、親クラスの設計情報から子クラスの設計情報と、子クラスの設計情報から親クラスの設計情報との両方をチェックする。
【0084】
テスト仕様書生成部１６は、ステップＳ２－１でテスト分類の仕様クラス（親クラス）の設計情報と、テスト観点の仕様クラスの属性の仕様クラス（子クラス）の設計情報との関連性があるか否かを判定する（ステップＳ３－１）。
テスト仕様書生成部１６は関連が無いと判定した場合にはステップＳ２－１へ戻る。テスト仕様書生成部１６は、関連があると判定した場合には、子クラスの設計情報を仕様クラスがキー、設計情報配列がバリューのＭａｐに格納する（ステップＳ４－１）。
テスト仕様書生成部１６は関連が無いと判定した場合にはステップＳ２－１へ戻る。テスト仕様書生成部１６は、関連があると判定した場合には、子クラスの設計情報を仕様クラスがキー、設計情報配列がバリューのＭａｐに格納する（ステップＳ４－１）。
【0085】
テスト仕様書生成部１６は、テスト観点データを取得する（ステップＳ５－１）。例えば、テスト仕様書生成部１６は、仕様クラス属性が子クラスの設計情報に該当するテスト観点データを取得する。ステップＳ６－１からＳ３１－１は、テスト観点データごとに行われる。
テスト仕様書生成部１６は、仕様クラスが定義されているかを判定する（ステップＳ６－１）。テスト仕様書生成部１６は、仕様クラスが定義されていない場合には（ステップＳ６－１：ＮＯ）、テスト項目を生成しない（ステップＳ７－１）。
テスト仕様書生成部１６は、仕様クラスが定義されているかを判定する（ステップＳ６－１）。テスト仕様書生成部１６は、仕様クラスが定義されていない場合には（ステップＳ６－１：ＮＯ）、テスト項目を生成しない（ステップＳ７－１）。
【0086】
テスト仕様書生成部１６は、仕様クラスが定義されている場合には（ステップＳ６－１：ＹＥＳ）、属性名が定義されているかを判定する（ステップＳ８－１）。テスト仕様書生成部１６は、属性名が定義されていない場合には（ステップＳ８－１：ＮＯ）、テスト項目オブジェクトを生成する（ステップＳ９－１）。
テスト仕様書生成部１６は、属性名が定義されている場合には（ステップＳ８－１：ＹＥＳ）、属性値が定義されているかを判定する（ステップＳ１０－１）。
テスト仕様書生成部１６は、属性値が定義されている場合には（ステップＳ１０－１：ＹＥＳ）、子クラスの設計情報の属性名の値と属性名とが一致するかを判定する（ステップＳ１１－１）。
テスト仕様書生成部１６は、属性名が定義されている場合には（ステップＳ８－１：ＹＥＳ）、属性値が定義されているかを判定する（ステップＳ１０－１）。
テスト仕様書生成部１６は、属性値が定義されている場合には（ステップＳ１０－１：ＹＥＳ）、子クラスの設計情報の属性名の値と属性名とが一致するかを判定する（ステップＳ１１－１）。
【0087】
テスト仕様書生成部１６は、子クラスの設計情報の属性名の値と属性名とが一致する場合には（ステップＳ１１－１：ＹＥＳ）、テスト項目オブジェクトを生成する（ステップＳ１２－１）。テスト仕様書生成部１６は、属性値が定義されていない場合には（ステップＳ１０－１：ＮＯ）、子クラスの設計情報の属性名に値が定義されているかを判定する（ステップＳ１３－１）。
【0088】
テスト仕様書生成部１６は、子クラスの設計情報の属性名に値が定義されていない場合には（ステップＳ１３－１：ＮＯ）、テスト項目を生成しない（ステップＳ１４－１）。テスト仕様書生成部１６は、子クラスの設計情報の属性名に値が定義されている場合には（ステップＳ１３－１：ＹＥＳ）、テスト項目オブジェクトを生成する（ステップＳ１５－１）。
【0089】
テスト仕様書生成部１６は、子クラスの設計情報の属性名の値と属性名とが一致しない場合には（ステップＳ１１－１：ＮＯ）、テスト項目を生成しない（ステップＳ１６－１）。ステップＳ９－１、Ｓ１２－１およびＳ１５－１で、テスト項目オブジェクトを生成した後、テスト仕様書生成部１６は、操作が定義されているかを判定する（ステップＳ１３－１）。
【0090】
テスト仕様書生成部１６は、操作が定義されている場合には（ステップＳ１３－１：ＹＥＳ）、［ｓｐｅｃ：ＸＸ］タグがあるかを判定する（ステップＳ１４－１）。テスト仕様書生成部１６は、［ｓｐｅｃ：ＸＸ］タグが無い場合には（ステップＳ１４－１：ＮＯ）、操作の値をテスト項目オブジェクトに追加する（ステップＳ１５－１）。ステップＳ１６－１からＳ３０－１は、テスト項目化対象となる子クラスの設計情報の数だけ行われる。ステップＳ１６－１からＳ２２－１は、［ｓｐｅｃ：ＸＸ］タグの個数分だけ行われる。
【0091】
テスト仕様書生成部１６は、テスト観点データに属性値が定義されているかを判定する（ステップＳ１６－１）。テスト仕様書生成部１６は、テスト観点データに属性値が定義されている場合には（ステップＳ１６－１：ＹＥＳ）、テスト観点データを取得する（ステップＳ１７－１）。
テスト仕様書生成部１６は、子クラスの設計情報のテスト観点の属性名の値がテスト観点の属性値の値と一致するかを判定する（ステップＳ１８－１）。テスト仕様書生成部１６は、子クラスの設計情報のテスト観点の属性名の値がテスト観点の属性値の値と一致しない場合には（ステップＳ１８－１：ＮＯ）、テスト項目を生成しない（ステップＳ１９－１）。
テスト仕様書生成部１６は、子クラスの設計情報のテスト観点の属性名の値がテスト観点の属性値の値と一致するかを判定する（ステップＳ１８－１）。テスト仕様書生成部１６は、子クラスの設計情報のテスト観点の属性名の値がテスト観点の属性値の値と一致しない場合には（ステップＳ１８－１：ＮＯ）、テスト項目を生成しない（ステップＳ１９－１）。
【0092】
テスト仕様書生成部１６は、テスト観点に属性値が定義されていない場合には（ステップＳ１６－１：ＮＯ）、子クラスの設計情報に［ＳＰＥＣ：ＸＸ］タグの属性名が定義されているかを判定する（ステップＳ２０－１）。
テスト仕様書生成部１６は、子クラスの設計情報に［ＳＰＥＣ：ＸＸ］タグの属性名が定義されている場合には（ステップＳ２０－１：ＹＥＳ）、子クラスの設計情報にテスト観点の属性名が定義されているかを判定する（ステップＳ２１－１）。
テスト仕様書生成部１６は、子クラスの設計情報に［ＳＰＥＣ：ＸＸ］タグの属性名が定義されている場合には（ステップＳ２０－１：ＹＥＳ）、子クラスの設計情報にテスト観点の属性名が定義されているかを判定する（ステップＳ２１－１）。
【0093】
テスト仕様書生成部１６は、子クラスの設計情報にテスト観点の属性名が定義されている場合には、［ＳＰＥＣ：ＸＸ］タグのループを終了する。
テスト仕様書生成部１６は、子クラスの設計情報に［ＳＰＥＣ：ＸＸ］タグの属性名が定義されていない場合（ステップＳ２０－１：ＮＯ）又は子クラスの設計情報にテスト観点の属性名が定義されていない場合（ステップＳ２１－１：ＮＯ）、テスト項目を生成しない（ステップＳ２２－１）。
テスト仕様書生成部１６は、子クラスの設計情報に［ＳＰＥＣ：ＸＸ］タグの属性名が定義されていない場合（ステップＳ２０－１：ＮＯ）又は子クラスの設計情報にテスト観点の属性名が定義されていない場合（ステップＳ２１－１：ＮＯ）、テスト項目を生成しない（ステップＳ２２－１）。
【0094】
テスト仕様書生成部１６は、操作が定義されていない場合（ステップＳ１３－１：ＮＯ）又は操作の値をテスト項目のオブジェクトに追加した後（ステップＳ１５－１）、確認が定義されているかを判定する（ステップＳ２３－１）。テスト仕様書生成部１６は、確認が定義されている場合には（ステップＳ２３－１：ＹＥＳ）、［ｓｐｅｃ：ＸＸ］タグがあるかを判定する（ステップＳ２４－１）。
【0095】
テスト仕様書生成部１６は、［ｓｐｅｃ：ＸＸ］タグがない場合には（ステップＳ２４－１：ＮＯ）、確認後の値をテスト項目オブジェクトに追加する（ステップＳ２５－１）。テスト仕様書生成部１６は、確認が定義されていない場合（ステップＳ２３－１：ＮＯ）又は確認後の値をテスト項目オブジェクトに追加した（ステップＳ２５－１）後に、テスト項目化リストに追加する（ステップＳ２６－１）。ステップＳ２７－１からＳ３０－１は、テスト項目化対象となる子クラスの設計情報の数だけ行われる。ステップＳ２７－１は、［ｓｐｅｃ：ＸＸ］タグの個数分だけ行われる。
【0096】
テスト仕様書生成部１６は、子クラスの設計情報に［ＳＰＥＣ：ＸＸ］タグの属性名が定義されているかを判定する（ステップＳ２７－１）。テスト仕様書生成部１６は、子クラスの設計情報に［ＳＰＥＣ：ＸＸ］タグの属性名が定義されていない場合には（ステップＳ２７－１：ＮＯ）、テスト項目を生成しない（ステップＳ２８－１）。
テスト仕様書生成部１６は、操作の値をテスト項目オブジェクトに追加する（ステップＳ２９－１）。テスト仕様書生成部１６は、テスト項目化リストに追加する（ステップＳ３０－１）。テスト仕様書生成部１６は、テスト項目データを書き出す（ステップＳ３１－１）。
テスト仕様書生成部１６は、操作の値をテスト項目オブジェクトに追加する（ステップＳ２９－１）。テスト仕様書生成部１６は、テスト項目化リストに追加する（ステップＳ３０－１）。テスト仕様書生成部１６は、テスト項目データを書き出す（ステップＳ３１－１）。
【0097】
前述した実施形態では、設計書テンプレートに基づいて作成された設計書の一例として、画面一覧表、画面項目仕様書、画面項目処理仕様書について説明したが、この例に限られない。例えば、画面一覧表、画面項目仕様書、画面項目処理仕様書に限られず、他の設計書についても適用できる。
【0098】
前述した実施形態では、設計情報トレース管理部１４が、画面一覧表をモデルに分解して得られるクラス図の項目と画面項目仕様書をモデルに分解して得られるクラス図の項目との関連と、画面項目仕様書をモデルに分解して得られるクラス図の項目と画面項目処理仕様書をモデルに分解して得られるクラス図との項目との関連を定義する場合について説明したがこの例に限られない。
例えば、設計情報トレース管理部１４は、２の設計書の各々をモデルに分解して得られるクラス図の項目同士の関連を定義するようにしてもよいし、４以上の設計書の各々をモデルに分解して得られるクラス図の項目について関連を定義するようにしてもよい。
例えば、設計情報トレース管理部１４は、２の設計書の各々をモデルに分解して得られるクラス図の項目同士の関連を定義するようにしてもよいし、４以上の設計書の各々をモデルに分解して得られるクラス図の項目について関連を定義するようにしてもよい。
【0099】
本実施形態の情報処理装置１０によれば、情報処理装置１０は、設計書のテスト仕様書を作成する。情報処理装置１０は、設計情報読込部１１と、テスト観点データ読込部１２と、設計情報トレース管理部１４と、テスト仕様書生成部１６とを備える。
設計情報読込部１１は、テスト対象の設計書を複数読み込み、読み込んだ複数の設計書の各々に含まれる設計情報をモデルに分解する。テスト観点データ読込部１２は、テスト観点データを読み込む。
設計情報トレース管理部１４は、複数の設計書の各々に含まれる設計情報をモデルに分解した結果に基づいて、モデル間の対応関係を定義する。
テスト仕様書生成部１６は、テスト観点データ読込部１２が読み込んだテスト観点データと、設計情報読込部１１によって複数の設計書の各々に含まれる設計情報をモデルに分解した結果と、設計情報トレース管理部１４によってモデル間の対応関係を定義した結果とに基づいて、複数の設計書のテスト項目を生成し、生成したテスト項目に基づいてテスト仕様書を生成する。
設計情報読込部１１は、テスト対象の設計書を複数読み込み、読み込んだ複数の設計書の各々に含まれる設計情報をモデルに分解する。テスト観点データ読込部１２は、テスト観点データを読み込む。
設計情報トレース管理部１４は、複数の設計書の各々に含まれる設計情報をモデルに分解した結果に基づいて、モデル間の対応関係を定義する。
テスト仕様書生成部１６は、テスト観点データ読込部１２が読み込んだテスト観点データと、設計情報読込部１１によって複数の設計書の各々に含まれる設計情報をモデルに分解した結果と、設計情報トレース管理部１４によってモデル間の対応関係を定義した結果とに基づいて、複数の設計書のテスト項目を生成し、生成したテスト項目に基づいてテスト仕様書を生成する。
【0100】
このように構成することによって、情報処理装置１０は、複数の設計書の各々に含まれる設計情報をモデルに分解した結果に基づいて、設計情報間の対応関係を定義できるため、任意の設計情報において、関連する他の設計情報を使用してテスト仕様書を作成できる。具体的には、情報処理装置１０は、画面の設計情報において、関連する機能の設計情報を使用してテスト仕様書を作成できる。このため、複数の設計書の各々に含まれる設計情報をモデルに分解した結果に基づいて、設計情報間の対応関係を定義しない場合と比較して、生成可能なテストの種類を増加できる。
【0101】
情報処理装置１０において、設計情報トレース管理部１４は、複数の設計書の各々に含まれる設計情報をモデルに分解して得られるクラス図に含まれる項目間の対応関係を定義する。
【0102】
このように構成することによって、情報処理装置１０は、複数の設計書の各々に含まれる設計情報をモデルに分解して得られるクラス図に含まれる項目間の対応関係を定義できるため、任意の設計情報において、関連する他の設計情報を使用してテスト仕様書を作成できる。具体的には、情報処理装置１０は、画面の設計情報において、関連する機能の設計情報を使用してテスト仕様書を作成できる。
このため、複数の設計書の各々に含まれる設計情報をモデルに分解して得られるクラス図に含まれる項目間の対応関係を定義しない場合と比較して、生成可能なテストの種類を増加できる。
このため、複数の設計書の各々に含まれる設計情報をモデルに分解して得られるクラス図に含まれる項目間の対応関係を定義しない場合と比較して、生成可能なテストの種類を増加できる。
【0103】
情報処理装置１０において、テスト仕様書生成部１６は、生成したテスト項目の値を、設計情報をモデルに分解した結果から取得する。
【0104】
このように構成することによって、情報処理装置１０は、複数の設計書の各々に含まれる設計情報をモデルに分解した結果から、生成したテスト項目の値を取得できるため、取得したテスト項目の値に基づいて、テスト仕様書を作成できる。
【0105】
情報処理装置１０において、テスト仕様書生成部１６は、生成したテスト項目の値を、設計情報をモデルに分解した結果から、モデル間の対応関係を定義した結果を使用して取得する。
【0106】
このように構成することによって、情報処理装置１０は、複数の設計書の各々に含まれる設計情報をモデルに分解した結果から、生成したテスト項目の値を、モデル間の対応関係を定義した結果を使用して取得できるため、任意の設計情報において、関連する他の設計情報を使用してテスト項目の値を取得できる。
【0107】
（実施形態の変形例）
＜情報処理装置＞
図１０は、実施形態の変形例の情報処理装置の一例を示す図である。実施形態の変形例の情報処理装置１０ａは、パーソナルコンピュータ、サーバ、スマートフォン、タブレットコンピュータ又は産業用コンピュータ等の装置によって実現される。
情報処理装置１０ａは、設計情報読込部１１と、テスト観点データ読込部１２と、設計情報記憶部１３と、設計情報トレース管理部１４と、トレース記憶部１５と、テスト仕様書生成部１６ａと、設計情報検証管理部１７ａと、設計メタ情報記憶部１８ａと、検証エラー記憶部１９ａとを備える。
＜情報処理装置＞
図１０は、実施形態の変形例の情報処理装置の一例を示す図である。実施形態の変形例の情報処理装置１０ａは、パーソナルコンピュータ、サーバ、スマートフォン、タブレットコンピュータ又は産業用コンピュータ等の装置によって実現される。
情報処理装置１０ａは、設計情報読込部１１と、テスト観点データ読込部１２と、設計情報記憶部１３と、設計情報トレース管理部１４と、トレース記憶部１５と、テスト仕様書生成部１６ａと、設計情報検証管理部１７ａと、設計メタ情報記憶部１８ａと、検証エラー記憶部１９ａとを備える。
【0108】
設計情報検証管理部１７ａは、設計メタ情報記憶部１８ａに記憶された設計情報のメタ情報に対して定義された検証ルールに基づいて、設計情報記憶部１３に記憶された設計情報に設計漏れがあるか否かを判定する。設計情報検証管理部１７ａは、設計漏れがないと判定した設計情報を、設計情報記憶部１３に記憶させ、設計漏れがあると判定した設計情報を検証エラー記憶部１９ａに記憶させる。
【0109】
具体的には、設計情報検証管理部１７ａは、画面一覧表をモデルに分解した場合に定義される仕様クラス、画面ＩＤ、画面名、説明などの項目について、必須の項目に値が記述されているか否かを判定する。例えば、必須の項目は、管理者によって予め設定される。設計情報検証管理部１７ａは、必須の項目の全てに値が記述されている場合には設計漏れがないと判定し、必須の項目に値が記述されていないものがある場合には設計漏れがあると判定する。
【0110】
設計情報検証管理部１７ａは、設計漏れがないと判定した場合に、設計漏れがないと判定した画面一覧表を設計情報記憶部１３に記憶させる。設計情報検証管理部１７ａは、設計漏れがあると判定した場合に、設計漏れがあると判定した画面一覧表を検証エラー記憶部１９ａに記憶させる。
【0111】
また、具体的には、設計情報検証管理部１７ａは、画面項目仕様書をモデルに分解した場合に定義される仕様クラス、画面項目ＩＤ、画面項目名、要素タイプ、ラベルなどの項目について、必須の項目に値が記述されているか否かを判定する。
例えば、必須の項目は、管理者によって予め設定される。設計情報検証管理部１７ａは、必須の項目の全てに値が記述されている場合には設計漏れがないと判定し、必須の項目に値が記述されていないものがある場合には設計漏れがあると判定する。
例えば、必須の項目は、管理者によって予め設定される。設計情報検証管理部１７ａは、必須の項目の全てに値が記述されている場合には設計漏れがないと判定し、必須の項目に値が記述されていないものがある場合には設計漏れがあると判定する。
【0112】
設計情報検証管理部１７ａは、設計漏れがないと判定した場合に、設計漏れがないと判定した画面項目仕様書を設計情報記憶部１３に記憶させる。設計情報検証管理部１７ａは、設計漏れがあると判定した場合に、設計漏れがあると判定した画面項目仕様書を検証エラー記憶部１９ａに記憶させる。
【0113】
また、具体的には、設計情報検証管理部１７ａは、画面項目処理仕様書をモデルに分解した場合に定義される仕様クラス、アクションＩＤ、アクション名、イベント、対応項目名、アクション詳細、処理説明などの項目について、必須の項目に値が記述されているか否かを判定する。
例えば、必須の項目は、管理者によって予め設定される。設計情報検証管理部１７ａは、必須の項目の全てに値が記述されている場合には設計漏れがないと判定し、必須の項目に値が記述されていないものがある場合には設計漏れがあると判定する。
例えば、必須の項目は、管理者によって予め設定される。設計情報検証管理部１７ａは、必須の項目の全てに値が記述されている場合には設計漏れがないと判定し、必須の項目に値が記述されていないものがある場合には設計漏れがあると判定する。
【0114】
設計情報検証管理部１７ａは、設計漏れがないと判定した場合に、設計漏れがないと判定した画面項目処理仕様書を設計情報記憶部１３に記憶させる。設計情報検証管理部１７ａは、設計漏れがあると判定した場合に、設計漏れがあると判定した画面項目処理仕様書を検証エラー記憶部１９ａに記憶させる。
【0115】
設計メタ情報記憶部１８ａは、ＨＤＤやフラッシュメモリ、ＲＡＭ、ＲＯＭなどにより実現される。設計メタ情報記憶部１８ａには、設計情報のメタ情報に対して定義された検証ルールが記憶される。設計メタ情報記憶部１８ａには、設計情報をモデルに分解した場合に定義される項目について、必須の項目が記憶される。
【0116】
具体的には、設計メタ情報記憶部１８ａには、画面一覧表をモデルに分解した場合に定義される仕様クラス、画面ＩＤ、画面名、説明などの項目について、値が記述されなければならない必須の項目が記憶される。
また、具体的には、設計メタ情報記憶部１８ａには、画面項目仕様書をモデルに分解した場合に定義される仕様クラス、画面項目ＩＤ、画面項目名、要素タイプ、ラベルなどの項目について、値が記述されなければならない必須の項目が記憶される。
また、具体的には、設計メタ情報記憶部１８ａには、画面項目仕様書をモデルに分解した場合に定義される仕様クラス、画面項目ＩＤ、画面項目名、要素タイプ、ラベルなどの項目について、値が記述されなければならない必須の項目が記憶される。
【0117】
また、具体的には、設計メタ情報記憶部１８ａには、画面項目処理仕様書をモデルに分解した場合に定義される仕様クラス、アクションＩＤ、アクション名、イベント、対応項目名、アクション詳細、処理説明などの項目について、値が記述されなければならない必須の項目が記憶される。
【0118】
検証エラー記憶部１９ａは、ＨＤＤやフラッシュメモリ、ＲＡＭ、ＲＯＭなどにより実現される。検証エラー記憶部１９ａは、設計情報検証管理部１７ａによって設計漏れがあると判定された設計情報を記憶する。
【0119】
具体的には、検証エラー記憶部１９ａは、設計情報検証管理部１７ａによって設計漏れがあると判定された画面一覧表を記憶する。また、具体的には、検証エラー記憶部１９ａは、設計情報検証管理部１７ａによって設計漏れがあると判定された画面項目仕様書を記憶する。また、具体的には、検証エラー記憶部１９ａは、設計情報検証管理部１７ａによって設計漏れがあると判定された画面項目処理仕様書を記憶する。
【0120】
テスト仕様書生成部１６ａは、設計情報記憶部１３から設計情報およびテスト観点データを取得し、トレース記憶部１５からトレース情報を取得する。例えば、テスト仕様書生成部１６ａが設計情報記憶部１３から設計漏れがないと判定された設計情報を取得する。
テスト仕様書生成部１６ａは、取得した設計情報、テスト観点データおよびトレース情報に基づいてテスト仕様書を生成する。例えば、テスト仕様書生成部１６ａは、テスト仕様書テンプレートに基づいてテスト仕様書を作成する。テスト仕様書生成部１６ａがテスト仕様書を作成する処理は、設計漏れがないと判定された設計情報を使用すること以外は、テスト仕様書生成部１６と同様である。
テスト仕様書生成部１６ａは、取得した設計情報、テスト観点データおよびトレース情報に基づいてテスト仕様書を生成する。例えば、テスト仕様書生成部１６ａは、テスト仕様書テンプレートに基づいてテスト仕様書を作成する。テスト仕様書生成部１６ａがテスト仕様書を作成する処理は、設計漏れがないと判定された設計情報を使用すること以外は、テスト仕様書生成部１６と同様である。
【0121】
【0122】
前述した実施形態に変形例では、設計情報検証管理部１７ａによって設計情報に設計漏れがあるか否かを判定する場合について説明したが、この例に限られない。例えば、設計情報検証管理部１７ａは、複数の設計書の各々に含まれる設計情報をモデルに分解した場合に定義される項目について、記述されている値に誤りが無いか否かを判定するようにしてもよい。設計情報検証管理部１７ａは、誤りが無いと判定した設計情報を設計情報記憶部１３に記憶させ、誤りがあると判定した設計情報を検証エラー記憶部１９ａに記憶させる。
【0123】
この場合、設計メタ情報記憶部１８ａには、設計情報のメタ情報に対して定義された検証ルールとして、設計情報をモデルに分解した場合に定義される項目について、記述される値の条件が記憶される。設計情報検証管理部１７ａは、複数の設計書の各々に含まれる設計情報をモデルに分解した場合に定義される項目について記述されている値が、設計メタ情報記憶部１８ａに記憶されている条件を満たす場合には誤りが無いと判定し、記述されている値が条件を満たさない場合には誤りがあると判定する。
【0124】
前述した実施形態に変形例において、設計情報検証管理部１７ａが設計情報のメタ情報に対して定義された検証ルールを有するように構成してもよい。
【0125】
実施形態の変形例の情報処理装置１０ａによれば、情報処理装置１０において、メタ情報に対して定義された検証ルールに基づいて、複数の設計書の各々に含まれる設計情報をモデルに分解した結果に設計漏れがあるか否かを検証する設計情報検証管理部１７ａをさらに備える。テスト仕様書生成部１６ａは、設計情報検証管理部１７ａによって設計漏れがないとされた設計情報をモデルに分解した結果に基づいて、複数の設計書のテスト項目を生成し、生成したテスト項目に基づいてテスト仕様書を生成する。
【0126】
このように構成することによって、テスト仕様書生成部１６ａは、設計漏れがないとされた設計情報をモデルに分解した結果に基づいてテスト仕様書を生成できるため、テスト仕様書を生成するために入力されるデータの品質を確保できる。このため、テスト仕様書生成部１６ａによって生成されるテスト仕様書は、システムおよびソフトウェアに必要なテスト項目の漏れがないものとなる。
【0127】
実施形態の変形例の情報処理装置１０ａによれば、情報処理装置１０において、メタ情報に対して定義された検証ルールに基づいて、複数の設計書の各々に含まれる設計情報をモデルに分解した結果に誤りが無いか否かを検証する設計情報検証管理部１７ａをさらに備える。テスト仕様書生成部１６ａは、設計情報検証管理部１７ａによって誤りが無いとされた設計情報をモデルに分解した結果に基づいて、複数の前記設計書のテスト項目を生成し、生成した前記テスト項目に基づいてテスト仕様書を生成する。
【0128】
このように構成することによって、テスト仕様書生成部１６ａは、誤りが無いとされた設計情報をモデルに分解した結果に基づいてテスト仕様書を生成できるため、テスト仕様書を生成するために入力されるデータの品質を確保できる。このため、テスト仕様書生成部１６ａによって生成されるテスト仕様書は、システムおよびソフトウェアに必要なテスト項目の誤りが無いものとなる。
【0129】
以上、本発明の実施形態およびその変形例を説明したが、これらの実施形態およびその変形例は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態およびその変形例は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更、組合せを行うことができる。これら実施形態およびその変形例は、発明の範囲や要旨に含まれると同時に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。
【符号の説明】
【0130】
１０、１０ａ…情報処理装置、１１…設計情報読込部、１２…テスト観点データ読込部、１３…設計情報記憶部、１４…設計情報トレース管理部、１５…トレース記憶部、１６、１６ａ…テスト仕様書生成部、１７ａ…設計情報検証管理部、１８ａ…設計メタ情報記憶部、１９ａ…検証エラー記憶部
【図1】
【図2】
【図3A】
【図3B】
【図3C】
【図4】
【図5A】
【図5B】
【図6】
【図7】
【図8】
【図9】
【図10】