JP2022118286A - 検出装置、テストシステム、検出方法、およびプログラム - Google Patents

Abstract

【課題】宣言的モデルに従って構築されたシステムに対するテストの実行結果に基づいて、宣言的モデルのパラメータの誤り箇所を自動的に検出できる検出装置等を提供する。【解決手段】対象システムの構築に用いられた宣言的モデル、対象システムに対して実行されるテストのテスト関連情報、および対象システムに対するテストの実行結果を取得する取得部と、テストの実行結果に応じてテスト関連情報から抽出される情報に基づいて、宣言的モデルに含まれるパラメータの誤りを検出する検出部と、を備える検出装置とする。【選択図】 図１

Description

本開示は、宣言的モデルのパラメータの誤りを検出する検出装置等に関する。

宣言的モデルは、実行環境にシステムを構築するために用いられる。例えば、宣言的モデルを用いたシステムの構築方法として、ＯＡＳＩＳ ＴＯＳＣＡリファレンス実装がある（非特許文献１）。ＯＡＳＩＳは、Organization for the Advancement of Structured Information Standardsの略称である。ＴＯＳＣＡは、Topology and Orchestration Specification for Cloud Applicationsの略称である。

宣言的モデルに従って構築されたシステムは、パラメータ誤りに起因する宣言的モデルの作成ミスや、実行環境の問題などの様々な原因により正しく動作しないことがある。一般に、宣言的モデルに従って構築されたシステムは、宣言通りに構築されて正しく動作するか、手作業やテストツールによって確認される。手作業やテストツールによる確認では、テスト項目やテストコードをその都度作成する必要がある、テスト設計やテストコード作成でミスが発生し得る、適切なテスト設計やテストコード作成には高いスキルが求められる、といった問題点があった。

特許文献１には、宣言的モデルに対応したテストコード生成装置について開示されている。特許文献１の装置は、宣言的モデルに従って構築されるシステムに対して、宣言的モデルの構成要素ごとに予め設定されたテスト情報から実施が必要な事項を抽出して、テストコードを自動的に生成する。

特許文献２には、設計ルールに基づいてソフトウェアモデルを検査するモデル検査装置において、個別のプロジェクトに対して設計ルールをテーラリングする技術について開示されている。特許文献２の技術では、設計ルールに定められたパラメータ項目および基準パラメータ内容に基づき、ソフトウェアモデルに記述されたパラメータ項目に設定されたパラメータ内容を検査する。特許文献２の技術では、検査において不適合があった場合の、設計ルールを示す設計ルール識別情報と、不適合となったパラメータ項目およびパラメータ内容と、を含む履歴情報を予め記憶しておく。特許文献２の技術では、検査において不適合が生じた場合、履歴情報の傾向に基づいて、不適合となったパラメータ項目の基準パラメータ内容を改変すべきか否か判定する。特許文献２の技術では、改変すべきと判定した場合、履歴情報の傾向に基づいて、当該パラメータ項目の当該基準パラメータ内容の変更案を作成する。

特開２０２０－１８１５０９号公報 特開２０２０－０１３２３９号公報

TOSCA Simple Profile in YAML Version 1.2, Committee Specification 01, 19 July 2018.

特許文献１には、宣言的モデルに従って構築されたシステムが正しく動作するかを確認することについて開示されている。しかし、特許文献１には、構築されたシステムを正しく動作させるための対処については開示されていない。通常、構築されたシステムを正しく動作させるためには、宣言的モデルのパラメータの誤り箇所を修正する必要がある。このような場合、テスト結果からシステムが正しく動作しない原因を理解し、さらにそれを引き起こしている原因（宣言的モデルのパラメータ誤り）との対応関係を理解したうえで、その誤り箇所を特定しなければならなかった。

特許文献２の手法では、設計ルールという予め設定された制約条件に従って、ソフトウェアモデルのバリデーションを行う。そのため、特許文献２の手法では、設計ルールに定められていないパラメータ項目および基準パラメータ内容については検査できなかった。

本開示の目的は、宣言的モデルに従って構築されたシステムに対するテストの実行結果に基づいて、宣言的モデルのパラメータの誤り箇所を自動的に検出できる検出装置等を提供することにある。

本開示の一態様の検出装置は、対象システムの構築に用いられた宣言的モデル、対象システムに対して実行されるテストのテスト関連情報、および対象システムに対するテストの実行結果を取得する取得部と、テストの実行結果に応じてテスト関連情報から抽出される情報に基づいて、宣言的モデルに含まれるパラメータの誤りを検出する検出部と、を備える。

本開示の一態様の検出方法においては、コンピュータが、対象システムの構築に用いられた宣言的モデル、対象システムに対して実行されるテストのテスト関連情報、および対象システムに対するテストの実行結果を取得し、テストの実行結果に応じてテスト関連情報から抽出される情報に基づいて、宣言的モデルに含まれるパラメータの誤りを検出する。

本開示の一態様のプログラムは、対象システムの構築に用いられた宣言的モデル、対象システムに対して実行されるテストのテスト関連情報、および対象システムに対するテストの実行結果を取得する処理と、テストの実行結果に応じてテスト関連情報から抽出される情報に基づいて、宣言的モデルに含まれるパラメータの誤りを検出する処理と、をコンピュータに実行させる。

本開示によれば、宣言的モデルに従って構築されたシステムに対するテストの実行結果に基づいて、宣言的モデルのパラメータの誤り箇所を自動的に検出できる検出装置等を提供することが可能になる。

第１の実施形態に係る検出装置に関連する装置等の接続関係の一例を示すブロック図である。 第１の実施形態に係る検出装置に接続された宣言的モデルオーケストレーション装置の構成の一例について説明するためのブロック図である。 第１の実施形態に係る検出装置に接続された宣言的モデルオーケストレーション装置に記憶された宣言的モデルの一例の前半部分を示す図である。 第１の実施形態に係る検出装置に接続された宣言的モデルオーケストレーション装置に記憶された宣言的モデルの一例の後半部分を示す図である。 第１の実施形態に係る検出装置に接続されたテストコード生成装置の構成の一例について説明するためのブロック図である。 第１の実施形態に係る検出装置が接続されたテストコード生成装置に記憶されたテストコードテンプレートの一例を示す図である。 第１の実施形態に係る検出装置が接続されたテストコード生成装置に記憶されたテスト情報の一例を示す図である。 第１の実施形態に係る検出装置が接続されたテストコード生成装置によって抽出された構成要素情報の一例を示す図である。 第１の実施形態に係る検出装置に接続されたテストコード生成装置によって生成されるテストコードの一例を示す図である。 第１の実施形態に係る検出装置が取得するテストの実行結果の一例を示す図である。 第１の実施形態に係る検出装置の構成の一例について説明するためのブロック図である。 第１の実施形態に係る検出装置によって検出されたパラメータの誤り候補が表示装置の画面に表示される一例を示す概念図である。 第１の実施形態に係る検出装置の動作の一例について説明するためのフローチャートである。 第２の実施形態に係る検出装置の構成の一例を示すブロック図である。 各実施形態の検出装置等の装置を実現するハードウェア構成の一例を示すブロック図である。

以下に、本発明を実施するための形態について図面を用いて説明する。ただし、以下に述べる実施形態には、本発明を実施するために技術的に好ましい限定がされているが、発明の範囲を以下に限定するものではない。なお、以下の実施形態の説明に用いる全図においては、特に理由がない限り、同様箇所には同一符号を付す。また、以下の実施形態において、同様の構成・動作に関しては繰り返しの説明を省略する場合がある。

（第１の実施形態）
まず、第１の実施形態に係る検出装置の構成について、図面を参照しながら説明する。本実施形態の検出装置は、宣言的モデルに従って構築されたシステムに対するテストの実行結果に基づいて、その宣言的モデルに含まれるパラメータの誤り箇所を検出する。

（構成）
図１は、本実施形態の検出装置１０に関連する装置等の接続関係について説明するためのブロック図である。図１には、宣言的モデルオーケストレーション装置１１０、テストコード生成装置１２０、テストコード実行装置１３０、および実行環境１５０を併せて図示する。検出装置１０、テストコード生成装置１２０、およびテストコード実行装置１３０は、テストシステム１００を構成する。なお、テストコード実行装置１３０を含めずに、検出装置１０とテストコード生成装置１２０によってテストシステム１００が構成されてもよい。以下において、検出装置１０、宣言的モデルオーケストレーション装置１１０、テストコード生成装置１２０、テストコード実行装置１３０、および実行環境１５０の各々の通信機能については、説明を省略する場合がある。

検出装置１０は、インターネットやイントラネットなどのネットワーク（図示しない）を介して、宣言的モデルオーケストレーション装置１１０、テストコード生成装置１２０、およびテストコード実行装置１３０に接続される（図１）。検出装置１０は、テストコード実行装置１３０、テストコード生成装置１２０、および宣言的モデルオーケストレーション装置１１０から取得した情報に基づいて、宣言的モデルのパラメータの誤り箇所を検出する。検出装置１０によるパラメータの誤り箇所の検出の詳細に関しては、後述する。

〔宣言的モデルオーケストレーション装置〕
宣言的モデルオーケストレーション装置１１０は、ネットワーク（図示しない）を介して、検出装置１０、テストコード生成装置１２０、および実行環境１５０に接続される（図１）。宣言的モデルオーケストレーション装置１１０は、実行環境１５０に構築されるシステム（対象システムとも呼ぶ）の宣言的モデルを解釈して、対象システムが構築される実行環境１５０に応じた処理形式に変換する。宣言的モデルオーケストレーション装置１１０は、変換された処理形式に基づいて、プロビジョニング処理を実行する。

例えば、宣言的モデルオーケストレーション装置１１０の一例として、ＯＡＳＩＳＴＯＳＣＡリファレンス実装があげられる。ＯＡＳＩＳは、Organization for the Advancement of Structured Information Standardsの略称である。ＴＯＳＣＡは、Topology and Orchestration Specification for Cloud Applicationsの略称である。
例えば、宣言的モデルオーケストレーション装置１１０の別の一例として、ＯｐｅｎＳｔａｃｋ Ｈｅａｔ実装があげられる。

図２は、宣言的モデルオーケストレーション装置１１０の構成の一例を示すブロック図である。宣言的モデルオーケストレーション装置１１０は、宣言的モデルオーケストレータ１１１、プロビジョニング処理実行部１１２、および記憶部１１３を有する。

宣言的モデルオーケストレータ１１１は、宣言的モデルおよびその宣言的モデルに用いられるパラメータを、実行処理を行う内部インタプリタにデータ変換する。例えば、宣言的モデルオーケストレータ１１１は、宣言的モデルおよびその宣言的モデルに用いられるパラメータを、実行環境１５０に対応した命令を部品とするワークフローに変換するように動作する。

プロビジョニング処理実行部１１２は、宣言的モデルオーケストレータ１１１が生成した内部インタプリタを処理し、実行環境１５０に対して対象システムのプロビジョニング処理を行う。例えば、プロビジョニング処理実行部１１２は、宣言的モデルオーケストレータ１１１によって変換されたワークフローを実行する。

記憶部１１３は、宣言的モデル、宣言的モデルの構成要素、および実行時パラメータ（以下、パラメータとも呼ぶ）を格納する。例えば、ＯＡＳＩＳ ＴＯＳＣＡでは、宣言的モデルは、Ｓｅｒｖｉｃｅ Ｔｅｍｐｌａｔｅと呼ばれるシステム構成全体を表す定義である。構成要素は、Ｎｏｄｅ ＴｙｐｅやＲｅｌａｔｉｏｎｓｈｉｐ Ｔｙｐｅなどのタイプ（Ｔｙｐｅ）と呼ばれる型定義である。宣言的モデルは、構成要素の型定義に基づいて記述される。構成要素には、プロビジョニング先のサーバ情報と、そのサーバ情報が示すサーバで動作するミドルウェアやアプリケーションなどの機能の情報とを含む。例えば、サーバ情報は、仮想サーバ、コンテナ、および物理サーバのいずれかである。パラメータは、ユーザによって指定される値や、実行環境１５０から取得される値である。例えば、パラメータは、Ｓｅｒｖｉｃｅ Ｔｅｍｐｌａｔｅの一部であるＴｏｐｏｌｏｇｙ Ｔｅｍｐｌａｔｅのｉｎｐｕｔｓで指定される。

図３および図４は、宣言的モデルの一例である。図３は宣言的モデルの一例の前半部分である、図４は宣言的モデルの一例の後半部分である。なお、図３および図４の宣言的モデルには、非特許文献１（TOSCA Simple Profile in YAML Version 1.2, Committee Specification 01, 19 July 2018.）より引用された内容が含まれる。なお、図３および図４の宣言的モデルの例では、wordpress（ノード）の Standard（インターフェース）のdb_user（入力パラメータ）の指定に誤りがある（図３の下から２行目）。図３および図４の宣言的モデルに含まれるパラメータの誤りの検出については、後述する。

〔実行環境〕
実行環境１５０は、ネットワーク（図示しない）を介して、宣言的モデルオーケストレーション装置１１０およびテストコード実行装置１３０に接続される（図１）。実行環境１５０は、実際のシステムを稼働させる実行環境である。例えば、実行環境１５０の一例として、ＯｐｅｎＳｔａｃｋやＡＷＳ（Amazon Web Services）、ＶＭｗａｒｅなどがあげられる。宣言的モデルに従って実行環境１５０に構築されたシステムは、テストコード実行装置１３０によって、テストコード生成装置１２０によって生成されたテストコードを用いたテストを受ける。

〔テストコード生成装置〕
テストコード生成装置１２０は、ネットワーク（図示しない）を介して、検出装置１０、宣言的モデルオーケストレーション装置１１０、およびテストコード実行装置１３０に接続される（図１）。テストコード生成装置１２０は、宣言的モデルに従って構築される対象システムに対して実施が必要なコードを、宣言的モデルの構成要素ごとに予め設定されたテスト情報から抽出する。テストコード生成装置１２０は、抽出されたコードを用いて、対象システムに対するテストコードを自動的に生成する。

図５は、テストコード生成装置１２０の構成の一例を示すブロック図である。テストコード生成装置１２０は、情報取得部１２１、テスト情報記憶部１２２、およびテストコード生成部１２３を有する。

情報取得部１２１は、宣言的モデルオーケストレーション装置１１０の記憶部１１３に格納された情報を取得する。例えば、情報取得部１２１は、宣言的モデル、宣言的モデルの構成要素、およびパラメータに関する情報を取得する。

テスト情報記憶部１２２は、宣言的モデルの構成要素に対するテストコードのひな型（テストコードテンプレートとも呼ぶ）と、宣言的モデルの構成要素とテストコードのパラメータの置換ルールとが対応付けられた情報（テスト情報とも呼ぶ）を格納する。言い換えると、テスト情報記憶部１２２は、テストコードテンプレート（以下、テンプレートとも呼ぶ）ごとのパラメータ値の置換ルールを記憶する。

図６は、テスト情報記憶部１２２に記憶されるテンプレートの一例を示す図である。図６には、複数のテストコードテンプレートの一覧（テンプレートリストとも呼ぶ）を示す。テンプレートリストには、テンプレートの識別子（テンプレートＩＤ）に対応付けられたテンプレートの名称（テンプレート名）およびテンプレートのソースコード（プログラム）が含まれる。図６のテンプレートリストのテンプレートの列に含まれる各テストコードは、「：（パラメータ名）：」の形式でパラメータの名称（パラメータ名とも呼ぶ）が記述された部分を含む。テンプレートの列のパラメータ名が記述された括弧の内部（括弧の部分を含む）は、テストコード生成部１２３によるテストコードの生成の際に具体的なパラメータ値に置換される。

図７は、テスト情報記憶部１２２に記憶されるテスト情報の一例を示す図である。テスト情報は、宣言的モデルの構成要素と、その構成要素に使用されるテストコードテンプレートとの対応関係に関する情報である。図７では、複数のテスト情報がテーブル形式（テスト情報リストとも呼ぶ）で記述される。図７のテスト情報は、テストの識別子（テストＩＤ）に対応付けられた、宣言的モデルの構成要素を示すタイプの名称（タイプ名）、テストの名称（テスト名）、テンプレートＩＤ、およびパラメータ（パラメータ値の置換ルール）を含む。

例えば、図７の対応関係によると、タイプ名が「tosca.nodes.DBMS.MySQL」の構成要素に対しては、図６のテンプレートのうちテンプレートＩＤが１～４のテンプレートが使用される。パラメータの列には、置換対象となるパラメータの名称と値の情報が格納される。パラメータ値には、固定値ではなく、実行時のパラメータ値も指定可能である。例えば、図７の例では、紐づけられる構成要素に対するプロパティ（properties）が「prop」と記述され、紐づけられる構成要素に対する要件（requirements）が「req」と記述される。「prop」や「req」などの記述は、宣言的モデルオーケストレーション装置１１０から情報取得部１２１が値を取得することを示す。例えば「prop.port」との記述は、実行時に当該構成要素の「port」プロパティに指定された値を取得することを示す。なお、実行時にパラメータ値を取得する記述は、「prop」おや「req」に限定されない。実行時にパラメータ値を取得する記述は、宣言的モデルオーケストレーション装置１１０の種類に応じた記述とすることができる。

テストコード生成部１２３は、情報取得部１２１によって宣言的モデルオーケストレーション装置１１０から記憶部１１３から取得された情報と、テスト情報記憶部１２２に格納された情報とを取得する。例えば、テストコード生成部１２３は、下記の手順で情報を取得する。

テストコード生成部１２３は、宣言的モデルの構成要素に対するテストコードのテンプレートを取得する。具体的には、テストコード生成部１２３は、宣言的モデルの構成要素の情報に基づいて、その構成要素をテストするためのテストコードのテンプレートをテスト情報記憶部１２２から読み出す。テストコード生成部１２３は、宣言的モデルの構成要素に対するテストコードのテンプレートに含まれるパラメータのパラメータ値を取得する。具体的には、テストコード生成部１２３は、テスト情報記憶部１２２に記憶されたテストコードのテンプレートごとのパラメータ値の取得ルールに基づいてパラメータ値を取得する。パラメータ値の取得ルールは、パラメータ値が固定値（定数）で指定されている場合や、宣言的モデルオーケストレーション装置１１０からパラメータ値を取得するよう指示する場合を含む。また、テストコード生成部１２３が、実行環境１５０からパラメータ値を取得するようにしてもよい。テストコード生成部１２３は、取得したパラメータ値をテンプレートに適用することによって、宣言的モデルの構成要素に対するテストコードを取得する。

テストコード生成部１２３は、宣言的モデルオーケストレーション装置１１０に記憶された宣言的モデル（例えば、図３および図４）から、その宣言的モデルの構成要素を抽出する。構成要素には、プロビジョニング先のサーバ情報や、そのサーバ情報が示すサーバで動作するミドルウェアやアプリケーションの機能に関する情報が含まれる。

図８は、テストコード生成部１２３によって抽出される構成要素に関する情報（構成要素情報とも呼ぶ）の一例を示す図である。図８の例は、複数の構成要素に関する構成要素情報がテーブル形式（構成要素テーブルとも呼ぶ）でまとめられる。図８の構成要素テーブルの各行の構成要素情報には、構成要素（ノード）の識別子（ＩＤ：Identifier）、宣言的モデルから抽出された構成要素（ノード）の名称、その構成要素（ノード）のタイプの名称（タイプ名）、およびその構成要素（ノード）がプロビジョニングされるサーバ情報が含まれる。

例えば、図３および図４の宣言的モデルの例において、テストコード生成部１２３は、「node_templates」のラベル（図３の下から１７行目）の下に含まれる各ラベルをノードの名称として抽出する。図３および図４の宣言的モデルの例においては、「wrodpress」（図３の下から１６行目）、「apache」（図４の上から１行目）、「web_serber」（図４の上から７行目）、「wordpress_db」（図４の上から１１行目）、「mysql」（図４の下から１１行目）、「db_server」（図４の下から４行目）が抽出される。テストコード生成部１２３は、抽出されたノードの名称を、図８の構成要素テーブルのノードの列に書き込む。また、テストコード生成部１２３は、宣言的モデル（図３および図４）から、ノードごとに「type:・・・」で示されるタイプの名称（構成要素）を抽出する。テストコード生成部１２３は、抽出されたタイプの名称を、図８の構成要素テーブルのタイプの列に書き込む。また、テストコード生成部１２３は、宣言的モデル（図３および図４）から、ノードごとに「host:・・・」の記載を検出し、検出された記載に含まれるノードを辿ってサーバの名称（サーバ情報）を抽出する。例えば、テストコード生成部１２３は、「wordpress」の「host:apache」（図３の下から１０行目）との記載を検出して「appache」（図４の上から１行目）を辿り、「host:web_server」（図４の上から６行目）との記載を検出する。さらに「web_server」（図４の上から７行目）を辿ると「host:・・・」の記載がないことから、テストコード生成部１２３は、「web_server」という名称のサーバを、「wordpress」に対応するサーバとして検出する。テストコード生成部１２３は、検出されたサーバの名称（サーバ情報）を、図８の構成要素テーブルのサーバの列に書き込む。テストコード生成部１２３は、「wordpress」以外のノード（apache、wordpress_db、myspl）についても同様に、各々のノードに対応するサーバの名称（web_server、db_server、db_server）を検出する。テストコード生成部１２３は、検出されたサーバの名称（サーバ情報）を、図８の構成要素テーブルのサーバの列に書き込む。一方、「web_server」および「db_server」の各ノードについては、「host:・・・」の記載がないため、サーバの名称が検出されない。テストコード生成部１２３は、サーバの名称が検出されなかったノード（web_server、db_server）については、図８の構成要素テーブルのサーバの列に「－」という記号を書き込む。

テストコード生成部１２３は、取得された情報に基づいて、宣言的モデルに従って構築されたシステム（対象システム）に対するテストコードを生成する。例えば、テストコード生成部１２３は、特許文献１（特開２０２０－１８１５０９号公報）に記載された手法を用いてテストコードを生成する。テストコード生成部１２３によるテストコードの生成方法の詳細については、説明を省略する。

図９は、テストコード生成装置１２０によって生成されるテストコードの一例を示す図である。図９は、web_server（サーバ）にプロビジョニングされたwordpress（ノード）に対するテストコードの一例である。

〔テストコード実行装置〕
テストコード実行装置１３０は、ネットワーク（図示しない）を介して、検出装置１０、テストコード生成装置１２０、および実行環境１５０に接続される（図１）。テストコード実行装置１３０は、テストコード生成装置１２０によって生成されたテストコードを解釈し、宣言的モデルに従って構築された対象システムに対してテストを実行する。例えば、テストコード実行装置１３０の一例として、ＳｅｒｖｅｒｓｐｅｃやＩｎｆｒａｔａｓｔｅｒなどがあげられる。

図１０は、テストコード実行装置１３０によるテストの実行結果の一例を示す図である。図１０のテストの実行結果には、実行結果がＮＧだったテストコードの識別子（テストコードＩＤ）、テストの実行結果（ＮＧ：No Good）、テストＩＤ、テストが実行されたノードの名称（ノード名）、およびテストが実行されたノードが含まれるサーバ情報（サーバ）が含まれる。テストコード実行装置１３０によるテストの実行結果は、検出装置１０によって取得される。

〔検出装置〕
図１１は、検出装置１０の構成の一例について説明するためのブロック図である。検出装置１０は、取得部１１と検出部１２を有する。図１１には、検出装置１０の取得部１１に接続される宣言的モデルオーケストレーション装置１１０、テストコード生成装置１２０、およびテストコード実行装置１３０を併せて図示する。

取得部１１は、テストコード実行装置１３０からテストの実行結果を取得する。例えば、取得部１１は、テストコード実行装置１３０からＮＧ（No Good）となったテストの実行結果を取得する。また、取得部１１は、テストコード生成装置１２０からテスト関連情報を取得する。テスト関連情報は、構成要素情報（図８）、テスト情報（図７）、およびテンプレート（図６）を含む。また、取得部１１は、宣言的モデルオーケストレーション装置１１０から宣言的モデルを取得する。

検出部１２は、テストの実行結果に応じて、テスト関連情報から、テストコードのパラメータの置換ルールを抽出する。検出部１２は、抽出されたパラメータの置換ルールに基づいて、宣言的モデルに含まれるパラメータの誤りを検出する。

例えば、検出部１２は、図１０のテストの実行結果（図１０）に含まれるノードの名称（wordpress）とサーバ情報（web_server）に基づいて、図８の構成要素情報テーブルからＩＤ１の行の構成要素情報を抽出する。次に、検出部１２は、図７のテスト情報リストから、実行結果（図１０）に含まれるテストＩＤ（９）に基づいて、テストＩＤが９の行のテスト情報を抽出する。次に、検出部１２は、図７のテスト情報リストから抽出されたテストＩＤが９の行のテスト情報に含まれるテンプレートＩＤ（６）に基づいて、図６のテストコードテンプレートの一覧からテンプレートＩＤが６の行のテストコードテンプレートを抽出する。

例えば、検出部１２は、上記の手順で抽出されたテスト関連情報とテストコードのパラメータ置換ルール（図７のパラメータ列）に基づいて、宣言的モデルから、wordpress（ノード）のreq.database_endpointに指定されているノードを誤り候補として検出する。例えば、検出部１２は、woredpress_db（ノード）のプロパティ（name、user、password）を誤り候補として検出する（図４の上から１４～１６行目）。また、検出部１２は、検出されたプロパティに対応する入力パラメータ（wp_db_name、wp_db_user、wp_db_password）を誤り候補として検出する（図３の上から５、７、９行目）。さらに、検出部１２は、検出された入力パラメータが使用されている箇所を誤り候補として検出する。すなわち、検出部１２は、wordpress（ノード）のインターフェースの入力パラメータ（db_name、db_user、db_password）を誤り候補として検出する（図３の下から１～３行目）。

例えば、検出部１２によって検出された宣言的モデルのパラメータの誤り候補に関する情報は、表示装置（図示しない）の画面に表示される。例えば、表示装置１７０の画面には、パラメータの誤りの候補が強調表示される。例えば、表示装置１７０の画面には、パラメータの誤りの候補が、他の部分とは異なる色で表示されたり、枠で囲われたり、点滅したりすれば、宣言的モデルに関する情報の中からパラメータの誤りの候補を検出しやすくなる。表示装置の画面に表示された情報を視認したユーザは、その情報に基づいて、宣言的モデルのパラメータの誤りを検出できる。

図１２は、検出部１２によって検出された宣言的モデルのパラメータの誤り候補を表示装置１７０の画面に表示させる一例を示す概念図である。図１２の例では、宣言的モデル（図３、図４）から検出されたパラメータの誤り候補（下から１～３行目のdb_name、db_user、db_password）を他の部分とは異なる表示形式（太字）で示す。また、図１２には、誤って指定された入力パラメータ（下から２行目のname）を斜字で示す。表示装置１７０の画面を視認したユーザは、表示形式が異なる部分（db_name、db_user、db_password）に、パラメータの誤り候補が含まれることを認識できる。例えば、ユーザは、認識したパラメータの誤り候補に基づいて、誤って指定された入力パラメータ（name）を検出できる。

（動作）
次に、本実施形態の検出装置１０の動作の一例について図面を参照しながら説明する。図４は、検出装置１０の動作の一例について説明するためのフローチャートである。

図４において、まず、検出装置１０は、宣言的モデルに従って構築された対象システムに対するテストの実行結果をテストコード実行装置１３０から取得する（ステップＳ１１）。

ＮＧとなった実行結果がある場合（ステップＳ１２でＹｅｓ）、検出装置１０は、テストコード生成装置１２０から、宣言的モデルの構成要素に関するテスト関連情報を取得する（ステップＳ１３）。ＮＧとなった実行結果がない場合（ステップＳ１２でＮｏ）、図１３のフローチャートに沿った処理は終了である。

ステップＳ１３の次に、検出装置１０は、取得されたテスト関連情報から、実行結果がＮＧとなったテストに関連するテスト関連情報を抽出する（ステップＳ１４）。

次に、検出装置１０は、宣言的モデルオーケストレーション装置１１０から宣言的モデルを取得する（ステップＳ１５）。

次に、検出装置１０は、抽出されたテスト関連情報に基づいて、宣言的モデルからパラメータの誤り候補を検出する（ステップＳ１６）。

以上のように、本実施形態の検出装置は、取得部および検出部を備える。取得部は、対象システムの構築に用いられた宣言的モデル、対象システムに対して実行されるテストのテスト関連情報、および対象システムに対するテストの実行結果を取得する。検出部は、テストの実行結果に応じてテスト関連情報から抽出される情報に基づいて、宣言的モデルに含まれるパラメータの誤りを検出する。

本実施形態の検出装置は、テストの実行結果に応じてテスト関連情報から抽出される情報に基づいて、宣言的モデルに含まれるパラメータの誤りを検出する。そのため、本実施形態の検出装置によれば、宣言的モデルに従って構築されたシステムに対するテストの実行結果に基づいて、宣言的モデルのパラメータの誤り箇所を自動的に検出できる。

本実施形態の一態様において、テスト関連情報は、構成要素情報、テスト情報、およびテンプレート情報を含む。構成要素情報は、宣言的モデルの構成要素の識別子、宣言的モデルから抽出された構成要素の名称、構成要素のタイプ、および構成要素がプロビジョニングされたサーバ情報を含む。テスト情報は、テストの識別子、構成要素のタイプの名称、実行されるテストの名称、テストで使用されるテストコードテンプレートの識別子、およびテストコードテンプレートに含まれるテストコードのパラメータの置換ルールを含む。テンプレート情報は、テストコードテンプレートの識別子、テストコードテンプレートの名称、およびテストコードテンプレートを含む。本態様によれば、構成要素情報、テスト情報、およびテンプレート情報を含むテスト関連情報に基づいて、宣言的モデルのパラメータの誤り箇所を自動的に検出できる。

本実施形態の一態様において、取得部は、テストの実行結果、テストの識別子、テストが実行された構成要素の名称、構成要素がプロビジョニングされたサーバ情報を含むテスト実行結果情報を取得する。検出部は、テストの実行結果がＮＧのテスト実行結果情報に含まれるテストの識別子に基づいてテスト情報を抽出する。検出部は、抽出されたテスト情報に含まれるテストコードテンプレートの識別子に基づいてパラメータの置換ルールを抽出する。検出部は、抽出されたパラメータの置換ルールに基づいて、宣言的モデルに含まれるパラメータの誤り候補を検出する。例えば、検出部は、パラメータの置換ルールに基づいて、宣言的モデルから、構成要素のプロパティをパラメータの誤り候補として検出する。例えば、検出部は、検出された構成要素のプロパティに対応する入力パラメータをパラメータの誤り候補として検出する。例えば、検出部は、検出された構成要素のインターフェースの入力パラメータをパラメータの誤り候補として検出する。本態様によれば、テストの実行結果に応じてテスト関連情報を辿ることによって、宣言的モデルのパラメータの誤り箇所を自動的に検出できる。

本実施形態の一態様のテストシステムは、テストコード生成装置、テストコード実行装置、および検出装置を備える。テストコード生成装置は、宣言的モデルの構成要素に関する情報を宣言的モデルから抽出し、構成要素に関する情報に紐づけられたテストコードテンプレートを取得する。テストコード生成装置は、構成要素に関する情報に紐づけられたパラメータの置換ルールに従ってテストコードテンプレートに適用されるパラメータの値を取得する。テストコード生成装置は、取得されたパラメータの値をテストコードテンプレートに適用してテストコードを生成する。テストコード実行装置は、実行環境に構築された対象システムに対して、テストコード生成装置によって生成されたテストコードを実行する。検出装置は、対象システムの構築に用いられた宣言的モデル、対象システムに対して実行されるテストのテスト関連情報、および対象システムに対するテストの実行結果を取得する。検出装置は、テストの実行結果に応じてテスト関連情報から抽出される情報に基づいて、宣言的モデルに含まれるパラメータの誤りを検出する。本態様のテストシステムによれば、テストコード生成装置によって生成されたテストコードを用いたテストの実行結果に応じて、宣言的モデルに含まれるパラメータの誤りを検出できる。

以上のように、本実施形態の検出装置は、宣言的モデルのパラメータの誤り箇所を自動的に検出できる。そのため、本実施形態によれば、テストの実行結果がＮＧとなった原因と、宣言的モデルの誤りとの対応関係を把握するスキルが無い作業者であっても、宣言的モデルのパラメータの誤り箇所を容易に特定できる。

例えば、本実施形態の検出装置は、クラウド運用管理分野に属し、宣言的モデルに従って構築される対象システムに対して、システムが正しく構築されない場合に宣言的モデルのパラメータの誤り箇所を検出できる。例えば、本実施形態の手法は、クラウドの運用を管理する分野に適用できる。例えば、本実施形態の手法は、テンプレートプロビジョニング機能や、ＩａＣ（Infrastructure as Code）機能を利用する装置などに適用できる。

（第２の実施形態）
次に、第２の実施形態に係る検出装置について図面を参照しながら説明する。本実施形態の検出装置は、第１の検出装置を簡略化した構成である。図１４は、本実施形態の検出装置２０の構成の一例を示すブロック図である。検出装置２０は、取得部２１および検出部２２を備える。

取得部２１は、対象システムの構築に用いられた宣言的モデル、対象システムに対して実行されるテストのテスト関連情報、および対象システムに対するテストの実行結果を取得する。検出部２２は、テストの実行結果に応じてテスト関連情報から抽出される情報に基づいて、宣言的モデルに含まれるパラメータの誤りを検出する。

本実施形態の検出装置は、テストの実行結果に応じてテスト関連情報から抽出される情報に基づいて、宣言的モデルに含まれるパラメータの誤りを検出する。そのため、本実施形態の検出装置によれば、宣言的モデルに従って構築されたシステムに対するテストの実行結果に基づいて、宣言的モデルのパラメータの誤り箇所を自動的に検出できる。

（ハードウェア）
ここで、本開示の各実施形態に係る検出装置等（宣言的モデルオーケストレーション装置やテストコード生成装置、テストコード実行装置を含む）の処理を実行するハードウェア構成について、図１５の情報処理装置９０を一例として挙げて説明する。なお、図１５の情報処理装置９０は、各実施形態の検出装置等の処理を実行するための構成例であって、本開示の範囲を限定するものではない。

図１５のように、情報処理装置９０は、プロセッサ９１、主記憶装置９２、補助記憶装置９３、入出力インターフェース９５、および通信インターフェース９６を備える。図１５においては、インターフェースをＩ／Ｆ（Interface）と略記する。プロセッサ９１、主記憶装置９２、補助記憶装置９３、入出力インターフェース９５、および通信インターフェース９６は、バス９８を介して、互いにデータ通信可能に接続される。また、プロセッサ９１、主記憶装置９２、補助記憶装置９３、および入出力インターフェース９５は、通信インターフェース９６を介して、インターネットやイントラネットなどのネットワークに接続される。

プロセッサ９１は、補助記憶装置９３等に格納されたプログラムを、主記憶装置９２に展開する。プロセッサ９１は、主記憶装置９２に展開されたプログラムを実行する。本実施形態においては、情報処理装置９０にインストールされたソフトウェアプログラムを用いる構成とすればよい。プロセッサ９１は、本実施形態に係る検出装置等による処理を実行する。

主記憶装置９２は、プログラムが展開される領域を有する。主記憶装置９２には、プロセッサ９１によって、補助記憶装置９３等に格納されたプログラムが展開される。主記憶装置９２は、例えばＤＲＡＭ（Dynamic Random Access Memory）などの揮発性メモリによって実現される。また、主記憶装置９２として、ＭＲＡＭ（Magnetoresistive Random Access Memory）などの不揮発性メモリが構成／追加されてもよい。

補助記憶装置９３は、プログラムなどの種々のデータを記憶する。補助記憶装置９３は、ハードディスクやフラッシュメモリなどのローカルディスクによって実現される。なお、種々のデータを主記憶装置９２に記憶させる構成とし、補助記憶装置９３を省略することも可能である。

入出力インターフェース９５は、規格や仕様に基づいて、情報処理装置９０と周辺機器とを接続するためのインターフェースである。通信インターフェース９６は、規格や仕様に基づいて、インターネットやイントラネットなどのネットワークを通じて、外部のシステムや装置に接続するためのインターフェースである。入出力インターフェース９５および通信インターフェース９６は、外部機器と接続するインターフェースとして共通化してもよい。

情報処理装置９０には、必要に応じて、キーボードやマウス、タッチパネルなどの入力機器が接続されてもよい。それらの入力機器は、情報や設定の入力に使用される。なお、タッチパネルを入力機器として用いる場合は、表示機器の表示画面が入力機器のインターフェースを兼ねる構成としてもよい。プロセッサ９１と入力機器との間のデータ通信は、入出力インターフェース９５に仲介させればよい。

また、情報処理装置９０には、情報を表示するための表示機器を備え付けてもよい。表示機器を備え付ける場合、情報処理装置９０には、表示機器の表示を制御するための表示制御装置（図示しない）が備えられていることが好ましい。表示機器は、入出力インターフェース９５を介して情報処理装置９０に接続すればよい。

また、情報処理装置９０には、ドライブ装置が備え付けられてもよい。ドライブ装置は、プロセッサ９１と記録媒体（プログラム記録媒体）との間で、記録媒体からのデータやプログラムの読み込み、情報処理装置９０の処理結果の記録媒体への書き込みなどを仲介する。ドライブ装置は、入出力インターフェース９５を介して情報処理装置９０に接続すればよい。

以上が、本発明の各実施形態に係る検出装置等を可能とするためのハードウェア構成の一例である。なお、図１５のハードウェア構成は、各実施形態に係る検出装置等の演算処理を実行するためのハードウェア構成の一例であって、本発明の範囲を限定するものではない。また、各実施形態に係る検出装置等に関する処理をコンピュータに実行させるプログラムも本発明の範囲に含まれる。さらに、各実施形態に係るプログラムを記録したプログラム記録媒体も本発明の範囲に含まれる。記録媒体は、例えば、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）などの光学記録媒体で実現できる。記録媒体は、ＵＳＢ（Universal Serial Bus）メモリやＳＤ（Secure Digital）カードなどの半導体記録媒体によって実現されてもよい。また、記録媒体は、フレキシブルディスクなどの磁気記録媒体、その他の記録媒体によって実現されてもよい。プロセッサが実行するプログラムが記録媒体に記録されている場合、その記録媒体はプログラム記録媒体に相当する。

各実施形態の検出装置等の構成要素は、任意に組み合わせてもよい。また、各実施形態の検出装置等の構成要素は、ソフトウェアによって実現されてもよいし、回路によって実現されてもよい。

以上、実施形態を参照して本発明を説明してきたが、本発明は上記実施形態に限定されるものではない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

１０ 検出装置
１１ 取得部
１２ 検出部
１１０ 宣言的モデルオーケストレーション装置
１１１ 宣言的モデルオーケストレータ
１１２ プロビジョニング処理実行部
１１３ 記憶部
１２０ テストコード生成装置
１２１ 情報取得部
１２２ テスト情報記憶部
１２３ テストコード生成部
１３０ テストコード実行装置
１５０ 実行環境

Claims (10)

1. 対象システムの構築に用いられた宣言的モデル、前記対象システムに対して実行されるテストのテスト関連情報、および前記対象システムに対する前記テストの実行結果を取得する取得手段と、
   前記テストの実行結果に応じて前記テスト関連情報から抽出される情報に基づいて、前記宣言的モデルに含まれるパラメータの誤りを検出する検出手段と、を備える検出装置。
2. 前記テスト関連情報は、
   前記宣言的モデルの構成要素の識別子、前記宣言的モデルから抽出された前記構成要素の名称、前記構成要素のタイプ、および前記構成要素がプロビジョニングされたサーバ情報を含む構成要素情報と、
   前記テストの識別子、前記構成要素のタイプの名称、実行される前記テストの名称、前記テストで使用されるテストコードテンプレートの識別子、および前記テストコードテンプレートに含まれるテストコードの前記パラメータの置換ルールを含むテスト情報と、
   前記テストコードテンプレートの識別子、前記テストコードテンプレートの名称、および前記テストコードテンプレートを含むテンプレート情報と、を含む請求項１に記載の検出装置。
3. 前記取得手段は、
   前記テストの実行結果、前記テストの識別子、前記テストが実行された前記構成要素の名称、前記構成要素がプロビジョニングされた前記サーバ情報を含むテスト実行結果情報を取得し、
   前記検出手段は、
   前記テストの実行結果がＮＧの前記テスト実行結果情報に含まれる前記テストの識別子に基づいて前記テスト情報を抽出し、
   抽出された前記テスト情報に含まれる前記テストコードテンプレートの識別子に基づいて前記パラメータの置換ルールを抽出し、
   抽出された前記パラメータの置換ルールに基づいて、前記宣言的モデルに含まれる前記パラメータの誤り候補を検出する請求項２に記載の検出装置。
4. 前記検出手段は、
   前記パラメータの置換ルールに基づいて、前記宣言的モデルから、前記構成要素のプロパティを前記パラメータの誤り候補として検出する請求項２または３に記載の検出装置。
5. 前記検出手段は、
   検出された前記構成要素のプロパティに対応する入力パラメータを前記パラメータの誤り候補として検出する請求項４に記載の検出装置。
6. 前記検出手段は、
   検出された前記構成要素のインターフェースの入力パラメータを前記パラメータの誤り候補として検出する請求項４または５に記載の検出装置。
7. 請求項１乃至６のいずれか一項に記載の検出装置と、
   宣言的モデルの構成要素に関する情報を前記宣言的モデルから抽出し、前記構成要素に関する情報に紐づけられたテストコードテンプレートを取得し、前記構成要素に関する情報に紐づけられたパラメータの置換ルールに従って前記テストコードテンプレートに適用される前記パラメータの値を取得し、取得された前記パラメータの値を前記テストコードテンプレートに適用してテストコードを生成するテストコード生成装置と、を備えるテストシステム。
8. 実行環境に構築された対象システムに対して、前記テストコード生成装置によって生成された前記テストコードを実行するテストコード実行装置をさらに備える請求項７に記載のテストシステム。
9. コンピュータが、
   対象システムの構築に用いられた宣言的モデル、前記対象システムに対して実行されるテストのテスト関連情報、および前記対象システムに対する前記テストの実行結果を取得し、
   前記テストの実行結果に応じて前記テスト関連情報から抽出される情報に基づいて、前記宣言的モデルに含まれるパラメータの誤りを検出する検出方法。
10. 対象システムの構築に用いられた宣言的モデル、前記対象システムに対して実行されるテストのテスト関連情報、および前記対象システムに対する前記テストの実行結果を取得する処理と、
    前記テストの実行結果に応じて前記テスト関連情報から抽出される情報に基づいて、前記宣言的モデルに含まれるパラメータの誤りを検出する処理と、をコンピュータに実行させるプログラム。

Images