JP6765554B2 - ソフトウェア試験装置、ソフトウェア試験方法、および、ソフトウェア試験プログラム - Google Patents

Description

本発明は、ソフトウェア試験装置、ソフトウェア試験方法、および、ソフトウェア試験プログラムに関する。

近年、制御機器がネットワークに接続されるケースが増えている。また、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）機器の普及が進んでいる。そのため、制御機器およびＩｏＴ機器が、サイバー攻撃の標的になるケースが増加している。

一般的に、制御機器およびＩｏＴ機器では、通信データが固定的である。そのため、制御機器およびＩｏＴ機器では、正常な通信データを定義した検知ルールを予め設定しておくことが比較的容易である。そこで、検知ルールを予め設定しておくことで、サイバー攻撃を検知するホワイトリスト型攻撃検知方式が注目されている。ホワイトリスト型攻撃検知方式においては、検知ルールを予め設定しておき、受信した通信データが当該検知ルールから逸脱したときに、当該通信データが異常であると判定することで、サイバー攻撃を検知する。

ホワイトリスト型攻撃検知方式を使用した製品の性能および品質は、適用可能な検知ルールの種別の多さに大きく依存する。高信頼な攻撃検知ソフトウェアを開発する際には、実際のシステムに攻撃検知ソフトウェアを導入する前に、システムごとに異なる検知ルールに応じた攻撃検知ソフトウェアの実装試験が必要である。そのため、実装試験の際に使用するための各検知ルールに応じた高信頼なテストデータの作成が必要となる。

従来技術においては、テストデータを手動で作成していた。しかしながら、検知ルールに応じたテストデータの生成を手動で行うため、テストデータに関する漏れの発生または誤りの混入の可能性がある。したがって、漏れおよび誤りの無い高信頼なテストデータの生成が課題となる。

特許文献１では、テストデータを手動で作成するのではなく、自動的に作成することを提案している。特許文献１では、ＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）クラス図およびアクティビティ図などの設計モデルからテストデータを自動生成する。

特許文献２では、網羅的なテストデータを自動的に作成することを提案している。特許文献２では、列車走行に関する実運用上のルールからテストデータを自動生成している。

特許文献３では、安全重視ソフトウェアのモデルベース設計において、テストデータを自動的に生成することを提案している。特許文献３では、モデル検査または他の形式解析技術を用いて、仕様モデルからテストデータを自動生成している。

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

特許文献１では、設計モデルからテストデータを自動生成することを提案している。しかしながら、特許文献１では、テストデータに向けた設計モデルを作成する必要があるという課題があった。

特許文献２では、網羅的なテストデータを自動的に作成することを提案している。しかしながら、特許文献２では、テストデータの期待値を生成していないため、テスト結果の判定は、自動的に行うことができず、人手で行う必要があるという課題があった。

特許文献３では、仕様モデルから形式解析技術を用いてテストデータを自動生成することを提案している。しかしながら、特許文献３では、テストデータに向けた仕様モデルを作成する必要があるという課題があった。

本発明は、実装試験の際に使用するための検知ルールに応じたテストデータを生成する必要なしに、簡単な入力を行うだけで、検証対象のソフトウェアの検証結果を自動的に得ることができる、ソフトウェア試験装置、ソフトウェア試験方法、および、ソフトウェア試験プログラムを得ることを目的としている。

本発明は、検証対象ソフトウェアが導入される機器が通信を行う正常な通信データを定義する検知ルールを用いて、検証対象ソフトウェアが出力すべき実行結果の期待値を生成するための検証用ソフトウェアを生成する検証用ソフトウェア生成部と、検証用ソフトウェアにテストパターンを入力して、検証用ソフトウェアを実行させて、実行結果の期待値をテストケースとして生成するテストケース生成部と、テストパターンと同一のテストパターンを検証対象ソフトウェアに入力して、検証対象ソフトウェアを実行させて、得られた実行結果とテストケースの実行結果の期待値とを比較することで、検証対象ソフトウェアの合否を判定する検証実行部とを備えた、ソフトウェア試験装置である。

本発明に係るソフトウェア試験装置によれば、簡単な入力を行うだけで、検証対象のソフトウェアの検証結果を自動的に得ることができる。

本発明の実施の形態１に係るソフトウェア試験装置の全体構成例を示したブロック図である。 本発明の実施の形態１に係るソフトウェア試験装置のハードウェア構成例を示したブロック図である。 本発明の実施の形態１に係るソフトウェア試験装置の動作例を示したフローチャートである。 本発明の実施の形態１に係るソフトウェア試験装置における検証用ソフトウェア生成部の動作例を示したフローチャートである。 本発明の実施の形態１に係る検知ルールの例を示した図である。 本発明の実施の形態１に係る試験装置で生成されるルールリスト木の例を示した図である。 本発明の実施の形態１に係る試験装置で生成される決定木の例を示した図である。 本発明の実施の形態１に係る試験装置で生成される検証用ソフトウェアの例を示した図である。 本発明の実施の形態２に係る試験装置における検証用ソフトウェア生成部の動作例を示したフローチャートである。 本発明の実施の形態３に係る試験装置の全体構成例を示したブロック図である。 本発明の実施の形態３に係る試験装置の動作例を示したフローチャートである。

以下、本発明に係る試験装置の実施の形態について、図面を用いて説明する。

実施の形態１．
図１は、本実施の形態１に係るソフトウェア試験装置１００の全体構成例を示す。ソフトウェア試験装置１００は、図１に示すように、検証用ソフトウェア生成部１０２と、テストケース生成部１０４と、検証実行部１０７とを備えて構成されている。ソフトウェア試験装置１００は、検証対象ソフトウェア１０６についての検証を行って合否判定する装置である。ここでは、検証対象ソフトウェア１０６として、例えば、サイバー攻撃等による異常な通信データを検知する攻撃検知ソフトウェアを例に挙げて説明する。検証対象ソフトウェア１０６は、制御機器およびＩｏＴ機器などの機器に導入されて、当該機器が通信を行う通信データが正か否かを判定するためのソフトウェアである。

検証実行部１０７は、テストケース１０５と検証対象ソフトウェア１０６とを入力にして、検証結果１０８を出力する。

検証用ソフトウェア生成部１０２は、検知ルール１０１を入力にして、検証用ソフトウェア１０３を生成する。検証用ソフトウェア１０３は、定義した通信データのみを正とするテストオラクルとして使用されるソフトウェアである。

テストケース生成部１０４は、テストパターンを検証用ソフトウェア１０３に入力して実行させることで、テストケース１０５を生成する。

検証対象ソフトウェア１０６の試験を行う際には、検証対象ソフトウェア１０６にテストパターンを入力したときに、その実行結果が正しいか否かを判定するための判定基準として、実行結果の期待値が必要である。テストケース１０５は、実行結果の期待値となるデータである。従って、検証対象ソフトウェア１０６にテストパターンを入力したときに、その実行結果がテストケース１０５の実行結果と一致すれば、検証対象ソフトウェア１０６が正しく動作していると判定することができる。

なお、ソフトウェア試験装置１００の各部の詳細については後述する。

図２は、図１に示したソフトウェア試験装置１００のハードウェア構成例を示す。図２に示すように、本実施の形態１に係るソフトウェア試験装置１００は、コンピュータ２００から構成されている。

コンピュータ２００は、ハードウェアとして、プロセッサ２０１、補助記憶装置２０２、メモリ２０３、表示装置２０４、および、操作装置２０５を備えて構成されている。

補助記憶装置２０２には、図１に示す検証用ソフトウェア生成部１０２、テストケース生成部１０４、および、検証実行部１０７の各部の機能を実現するプログラムが記憶されている。また、補助記憶装置２０２には、ソフトウェア試験装置１００に入力される検知ルール１０１および検証対象ソフトウェア１０６が記憶されている。さらに、補助記憶装置２０２には、ソフトウェア試験装置１００の各部から出力される検証用ソフトウェア１０３、テストケース１０５、および、検証結果１０８が記憶されている。

このように、図１に示す検証用ソフトウェア生成部１０２、テストケース生成部１０４、および、検証実行部１０７の各部の機能は、プログラムにより実現される。検証用ソフトウェア生成部１０２、テストケース生成部１０４、および、検証実行部１０７の各部の機能を実現するプログラムは、メモリ２０３にロードされ、プロセッサ２０１により実行される。

図２では、プロセッサ２０１が、検証用ソフトウェア生成部１０２、テストケース生成部１０４、および、検証実行部１０７の各部の機能を実現するプログラムを実行している状態を模式的に表している。

表示装置２０４は、操作装置２０５の補助を行うとともに、検証結果１０８のデータを表示する。

操作装置２０５は、検知ルール１０１、検証対象ソフトウェア１０６などの各データのデータ入力操作を実施するのに用いられる。

次に、図１に示す検証用ソフトウェア生成部１０２、テストケース生成部１０４、および、検証実行部１０７の詳細について説明する。

検証用ソフトウェア生成部１０２は、正常な通信データを定義した検知ルール１０１に基づいて、定義した通信データのみを正として判定する検証用ソフトウェア１０３を生成する。

テストケース生成部１０４は、検証用ソフトウェア１０３に、境界値または確率的な入力による任意のテストパターンを入力し、検証用ソフトウェア１０３を実行させて、実行結果を得る。テストケース生成部１０４は、検証用ソフトウェア１０３に入力したテストパターンと実行結果とのペアを、テストケース１０５として生成する。テストケース１０５に含まれる実行結果は、検証対象ソフトウェア１０６に同じテストパターンを入力したときに得られる実行結果の期待値となる。そのため、以下では、テストケース１０５内の実行結果を、「実行結果の期待値」または「期待値」と呼ぶこととする。

検証実行部１０７は、検証用ソフトウェア１０３に入力したテストパターンと同一のテストパターンを検証対象ソフトウェア１０６に入力し、その実行結果をテストケース１０５内の期待値と比較し、比較結果を検証結果１０８として出力する。

次に、図３を用いて、ソフトウェア試験装置１００の動作例を説明する。但し、図３は、ソフトウェア試験装置１００の動作フローの一例Ｓ１０００を示しており、ソフトウェア試験装置１００の動作フローは必ずしも図３の通りでなくてもよい。

図３において、まず、ステップＳ１００１で、ソフトウェア試験装置１００に検知ルール１０１を入力する。

次に、ステップＳ１００２において、検証用ソフトウェア生成部１０２が、ステップＳ１００１で入力した検知ルールから、検証用ソフトウェア１０３を生成する。検証用ソフトウェア生成動作の詳細な処理フローは後述する。

次に、ステップＳ１００３において、テストケース生成部１０４が、ステップＳ１００２で生成した検証用ソフトウェア１０３に、テストパターンを入力する。

次に、ステップＳ１００４において、テストケース生成部１０４が、検証用ソフトウェア１０３を実行させ、実行結果とステップＳ１００３で入力したテストパターンとの組を、テストケース１０５として生成する。テストケース１０５に含まれる実行結果は、上述したように、「実行結果の期待値」として用いられる。

次に、ステップＳ１００５において、テストケース生成部１０４が、ステップＳ１００４で全てのテストケース１０５を生成したか否かを判定する。ステップＳ１００４で全てのテストケース１０５を生成したと判定した場合、ステップＳ１００６へ進む。一方、全てのテストケース１０５の生成が途中の場合には、ステップＳ１００３に戻る。全てのテストケース１０５の生成が完了するまで、ステップＳ１００３からステップＳ１００５までの処理を繰り返す。

ステップＳ１００６において、検証実行部１０７が、ステップＳ１００３からステップＳ１００５までの処理で生成したテストケース１０５内のテストパターンを、検証対象ソフトウェア１０６に入力する。

ステップＳ１００７において、検証実行部１０７が、検証対象ソフトウェア１０６を実行させて得られた実行結果と、テストケース１０５内の実行結果の期待値とを比較する。検証対象ソフトウェア１０６の実行結果とテストケース１０５内の実行結果の期待値とが一致していれば、比較結果は「一致」となり、一致していなければ、比較結果は「不一致」として出力される。

ステップＳ１００８において、検証実行部１０７が、ステップＳ１００７で全てのテストケース１０５についての検証を実行したか否かを判定する。全てのテストケース１０５についての検証を実行したと判定した場合、ステップＳ１００９へ進む。一方、検証の実行が途中の場合には、ステップＳ１００６に戻る。全てのテストケース１０５の検証の実行が完了するまで、ステップＳ１００６からステップＳ１００８の処理を繰り返す。

ステップＳ１００９において、検証実行部１０７は、全ての比較結果を、検証結果１０８として出力し、図３の動作フローの処理を終了する。

次に、図４を用いて、図３に示すステップＳ１００２の「検証用ソフトウェア生成」の動作の詳細な処理フローを説明する。

図４において、ステップＳ２００１において、検証用ソフトウェア生成部１０２に検知ルール１０１を入力する。検知ルール１０１の例を図５に示す。図５に示す検知ルール１０１は、正常な通信データの定義項目として、送信元情報、送信先情報、データ長、ペイロードなどの情報を含んでいる。図５の例では、検知ルール１０１が、ルール１からルールＮまでのＮ個の検知ルールを含んでいる。検証用ソフトウェア１０３および検証対象ソフトウェア１０６においては、検知ルール１０１に含まれるＮ個の通信データが正となり、それ以外は異常データと判定される。

ステップＳ２００２において、検証用ソフトウェア生成部１０２は、ステップＳ２００１で入力された検知ルール１０１を、検知ルール解析することにより、ルールリスト木４００を作成する。ルールリスト木の例を図６に示す。図６に示すルールリスト木４００は、定義項目が葉、各ルールを木として、ルールリストを表している。

ステップＳ２００３において、検証用ソフトウェア生成部１０２は、ステップＳ２００２で生成されたルールリスト木４００から、全ての木の定義項目を共通な項目ごとに結合する。

ステップＳ２００４において、検証用ソフトウェア生成部１０２は、決定木５００を構築する。決定木５００の例を図７に示す。図７に示す決定木５００は、ステップＳ２００３で定義項目を結合されたルールリスト木４００を決定木構造に変換し、また、各枝に不一致の葉を追加したものである。

ステップＳ２００５において、検証用ソフトウェア生成部１０２は、ステップＳ２００４で生成した決定木５００から、検証用ソフトウェア１０３となるプログラムを生成する。検証用ソフトウェア１０３となるプログラム６００の例を図８に示す。

ステップＳ２００６において、検証用ソフトウェア生成部１０２は、ステップＳ２００５で生成されたプログラム６００を検証用ソフトウェア１０３として出力し、終了する。

図８のプログラム６００から構成された検証用ソフトウェア１０３について説明する。検証用ソフトウェア１０３においては、テストデータが、図５に示すルール１からルールＮまでのＮ個の検知ルールのいずれか１つに一致すれば、当該テストデータを正と判定する。一方、テストデータが、これらのＮ個の検知ルールのいずれにも一致しなければ、当該テストデータは異常となり、サイバー攻撃を受けている可能性があると判定する。具体的には、テストデータの送信元情報が送信元情報１で、送信先情報が送信先情報１で、データ長がデータ長１で、ペイロードがペイロード１の場合、ルール１と一致するので、当該テストデータは正と判定できる。

このように、本実施の形態１においては、検証用ソフトウェア生成部１０２が、検知ルール１０１から、図８に示す検証用ソフトウェア１０３を生成する。テストケース生成部１０４は、検証用ソフトウェア１０３に、Ｍ個のテストパターンＡ，Ｂ，Ｃ，・・・，Ｍを入力し、それぞれの実行結果を、実行結果の期待値Ａｏｕｔ、Ｂｏｕｔ，Ｃｏｕｔ，・・・，Ｍｏｕｔとして得る。検証実行部１０７は、試験対象の検証対象ソフトウェア１０６に、テストパターンＡ，Ｂ，Ｃ，・・・，Ｍを入力し、それぞれの実行結果を、実行結果Ａｏｕｔ’、Ｂｏｕｔ’，Ｃｏｕｔ’，・・・，Ｍｏｕｔ’として得る。検証実行部１０７は、実行結果の期待値Ａｏｕｔ、Ｂｏｕｔ，Ｃｏｕｔ，・・・，Ｍｏｕｔと実行結果Ａｏｕｔ’、Ｂｏｕｔ’，Ｃｏｕｔ’，・・・，Ｍｏｕｔ’とをそれぞれ比較して、Ｍ個のうち、一致した個数が予め設定された閾値以上であれば、検証対象ソフトウェア１０６を合格とし、一致した個数が閾値未満であれば、検証対象ソフトウェア１０６を不合格と判定する。なお、閾値は、Ｍに設定してもよく、あるいは、Ｍより小さい値に設定してもよい。

以上のように、本実施の形態１係るソフトウェア試験装置１００によれば、検知ルール１０１と検証対象ソフトウェア１０６とを入力するだけで、検証対象ソフトウェア１０６の試験が全自動で実行することができる。したがって、従来のように手動によりテストケースを生成することが不要であり、テスト時間の削減ができる。

本実施の形態１に係るソフトウェア試験装置１００は、全自動でテストケースが生成されるため、人間の介入によるテストケースに関する漏れの発生および誤りの混入の可能性が低減できる。

本実施の形態に係るソフトウェア試験装置１００は、検知ルール１０１からテストケース１０５を生成し、検証対象ソフトウェア１０６の検証テストを実行するため、検証対象ソフトウェア１０６の内容がブラックボックスで不明であっても、検証テストを行うことが可能である。

本実施の形態に係るソフトウェア試験装置１００は、検証用ソフトウェア１０３を用いて実行結果の期待値としてのテストケース１０５を得ることができるので、検証対象ソフトウェア１０６の合否の判定結果を自動的に得ることができるので、合否の判定を人手によって行う必要がない。

実施の形態２．
図９を用いて、本発明の実施の形態２に係るソフトウェア試験装置について説明する。図９は、上述した図３に示すステップＳ１００２の「検証用ソフトウェア生成」の動作の詳細な処理フローを示す。

なお、実施の形態２に係るソフトウェア試験装置の全体構成は、図１に示した実施の形態１に係るソフトウェア試験装置１００の構成と同じである。また、実施の形態２のハードウェア構成例は、図２に示した実施の形態１のハードウェア構成と同じである。実施の形態２のソフトウェア試験装置の動作は、図３の実施の形態１と基本的に同じである。本実施の形態２において、実施の形態１と異なる点は、実施の形態１の図４の代わりに、図９の動作フローを行う点だけである。ここで生成される形式検証プロパティは、検査対象の通信データと図５の検知ルール１０１との一致を検証するために用いられる。形式検証プロパティには、図５の検知ルール１０１に定義されたＮ個の検知ルールが形式的に変換されたものが記述されている。例えば、図５の検知ルール１０１のルール１からは、「ルール１ == sender == 送信元情報１ && receiver == 送信先情報１ && length ==データ長１ && command == ペイロード１」といった形式検証プロパティが作成される。ここで、sender、 receiver、length、commandは、検査対象の通信データの内容である。

図９において、ステップＳ３００１、ステップＳ３００２、ステップＳ３００３、ステップＳ３００５、ステップＳ３００６、ステップＳ３００８は、それぞれ、実施の形態１の図４のステップＳ２００１、ステップＳ２００２、ステップＳ２００３、ステップＳ２００４、ステップＳ２００５、ステップＳ２００６と同じであるため、ここでは、その説明を省略する。すなわち、図９においては、図４に対して、ステップＳ３００４の「形式検証プロパティ生成」のステップが追加されている。形式検証プロパティは、検証用ソフトウェア１０３の動作を形式的に検証するためのプロパティである。

図９において、ステップＳ３００４において、検証用ソフトウェア生成部１０２は、ステップＳ３００２で生成した図６のルールリスト木４００から、検知ルール１０１に応じた形式検証プロパティを生成する。

ステップＳ３００７において、検証用ソフトウェア生成部１０２は、ステップＳ３００６で生成したプログラム６００について、ステップＳ３００４で生成した形式検証プロパティを用いて、図５の検知ルール１０１が、正しく、プログラム６００に反映されているか否かを検証する。

以上のように、実施の形態２においても、実施の形態１と同様に、検知ルール１０１と検証対象ソフトウェア１０６とを入力するだけで、自動的に、検証対象ソフトウェア１０６の合否判定を行うことができるので、上記の実施の形態１と同様の効果が得られる。

さらに、本実施の形態２においては、検証用ソフトウェア生成部１０２が、検知ルール１０１に応じた形式検証プロパティを生成する。形式検証プロパティを用いた形式検証を行うことにより、検証用ソフトウェア１０３にバグが無いことが証明される。したがって、高信頼なテストケース１０５を生成することができる。

実施の形態３．
図１０は、本発明の実施の形態３に係るソフトウェア試験装置１００Ａの全体構成例を示す。

ソフトウェア試験装置１００Ａは、図１０に示すように、図１の実施の形態１の構成に対して、モデル検査部７０２と検知ルール生成部７０３とが追加されている。

モデル検査部７０２は、通信モデル７０１を入力とし、モデル検査を行う。

検知ルール生成部７０３は、モデル検査部７０２から出力されるモデル検査後の通信モデルから、検知ルール１０１を出力する。

なお、モデル検査部７０１と検知ルール生成部７０３との詳細については後述する。

本実施の形態３に係るソフトウェア試験装置１００Ａのハードウェア構成例は、図２の実施の形態１に係るソフトウェア試験装置１００のハードウェア構成に対して、モデル検査部７０２と検知ルール生成部７０３との機能を加えた構成であり、モデル検査部７０２と検知ルール生成部７０３とは、検証用ソフトウェア生成部１０２と同様に、プログラムにより実現される。このように、本実施の形態３に係るソフトウェア試験装置１００Ａのハードウェア構成例は、図２の実施の形態１に係るソフトウェア試験装置１００のハードウェア構成と基本的に同じであるため、ここでは、その説明を省略する。なお、通信モデル７０１は、補助記憶装置２０２に格納されるか、あるいは、メモリ２０３に格納される。

次に、図１０に示す本実施の形態３に係るソフトウェア試験装置１００Ａにおける、通信モデル７０１、モデル検査部７０２、および、検知ルール生成部７０３の詳細を説明する。他の構成については、実施の形態１と同じであるため、ここでは、その説明を省略する。

通信モデル７０１は、検証対象ソフトウェア１０６が導入される制御機器あるいはＩｏＴ機器などの機器によって通信される通信データの設計モデルである。通信モデル７０１は、例えばブロック図または状態遷移図で記述され、通信機能の実装に必要な情報が含まれている。

モデル検査部７０２は、予め設定されたモデル検査ルールに従って、通信モデル７０１に誤りがないかのモデル検査を行う。例えば、モデル検査部７０２は、通信シーケンスにおいて、デッドロックが発生しないか等を、モデル検査により、形式検証する。

検知ルール生成部７０３は、モデル検査後の通信モデル７０１を入力とし、正常な通信データを定義した検知ルール１０１を生成する。検知ルール生成部７０３は、通信モデル７０１に含まれる通信機能の仕様を抽出し、抽出した通信機能を、検知ルール１０１の定義項目として定義する。

次に、図１１を用いて、ソフトウェア試験装置１００Ａの動作について説明する。但し、図１１は、ソフトウェア試験装置１００Ａの動作の一例Ｓ４０００を示しており、ソフトウェア試験装置１００Ａの動作フローは必ずしも図１１の通りでなくてもよい。

図１１において、まず、ステップＳ４００１において、ソフトウェア試験装置１００Ａに通信モデル７０１を入力する。

次に、ステップＳ４００２において、モデル検査部７０２が、ステップＳ４００１で入力された通信モデル７０１をモデル検査により形式検証する。

次に、ステップＳ４００３において、検知ルール生成部７０３が、ステップＳ４００２でモデル検査された通信モデル７０１から、検知ルール１０１を生成する。生成される検知ルール１０１の一例は、例えば、図５に示されるものである。

ステップＳ４００３で生成された検知ルール１０１は、検証用ソフトウェア生成部１０２への入力となる。

図１１のステップＳ４００４からステップＳ４０１１の処理は、それぞれ、図３の実施の形態１のステップＳ１００２からステップＳ１００９と同様であるため、ここでは、その説明を省略する。

以上のように、本実施の形態３においても、通信モデル７０１と検証対象ソフトウェア１０６とを入力するだけで、自動的に、検証対象ソフトウェア１０６の合否判定を行うことができるので、上記の実施の形態１と同様の効果が得られる。

さらに、本実施の形態３においては、モデル検査を実施した後の通信モデル７０１から検知ルール１０１を生成するようにしたので、通信モデル７０１から検知ルール１０１の生成及び検証対象ソフトウェア１０６の検証テストまでが、全自動かつ高信頼なテストスキームで実現できる。

最後に、図２のソフトウェア試験装置１００および１００Ａのハードウェア構成の補足説明を行う。

プロセッサ２０１は、プロセッシングを行うＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）である。プロセッサ２０１は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）である。

補助記憶装置２０２は、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、フラッシュメモリ、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）である。

メモリ２０３は、例えば、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）である。

表示装置２０４は、例えば、ディスプレイ、ランプ、音声によるオペレータである。

操作装置２０５は、例えば、マウス、キーボード、タッチパネルである。

補助記憶装置２０２には、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）も記憶されている。そして、ＯＳの少なくとも一部がメモリ２０３にロードされる。プロセッサ２０１はＯＳを実行しながら、検証用ソフトウェア生成部１０２、テストケース生成部１０４、検証実行部１０７、モデル検査部７０２、および、検知ルール生成部７０３の各部の機能を実現するプログラムを実行する。

プロセッサ２０１がＯＳを実行することで、タスク管理、メモリ管理、ファイル管理、通信制御等が行われる。

また、ソフトウェア試験装置１００および１００Ａは、プロセッサ２０１を代替する複数のプロセッサを備えていてもよい。これら複数のプロセッサは、検証用ソフトウェア生成部１０２、テストケース生成部１０４、検証実行部１０７、モデル検査部７０２、および、検知ルール生成部７０３の各部の機能を実現するプログラムの実行を分担する。それぞれのプロセッサは、プロセッサ２０１と同じように、プロセッシングを行うＩＣである。

また、検証用ソフトウェア生成部１０２、テストケース生成部１０４、検証実行部１０７、モデル検査部７０２、および、検知ルール生成部７０３の各部の処理の結果を示す情報およびデータが、メモリ２０３、補助記憶装置２０２、又は、プロセッサ２０１内のレジスタ又はキャッシュメモリにファイルとして記憶される。

また、検証用ソフトウェア生成部１０２、テストケース生成部１０４、検証実行部１０７、モデル検査部７０２、および、検知ルール生成部７０３の各部の機能を実現するプログラムは、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ブルーレイ（登録商標）ディスク、ＤＶＤ等の可搬記憶媒体に記憶されてもよい。

また、検証用ソフトウェア生成部１０２、テストケース生成部１０４、検証実行部１０７、モデル検査部７０２、および、検知ルール生成部７０３の各部の「部」を、「回路」又は「工程」又は「手順」又は「処理」に読み替えてもよい。

また、ソフトウェア試験装置１００および１００Ａは、ロジックＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、ＧＡ（Ｇａｔｅ Ａｒｒａｙ）、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、ＦＰＧＡ（Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）といった電子回路により実現されてもよい。その場合は、検証用ソフトウェア生成部１０２、テストケース生成部１０４、検証実行部１０７、モデル検査部７０２、および、検知ルール生成部７０３の各部は、それぞれ電子回路の一部として実現される。

なお、プロセッサ及び上記の電子回路を総称してプロセッシングサーキットリーともいう。

１００，１００Ａ ソフトウェア試験装置、１０１ 検知ルール、１０２ 検証用ソフトウェア生成部、１０３ 検証用ソフトウェア、１０４ テストケース生成部、１０５ テストケース、１０６ 検証対象ソフトウェア、１０７ 検証実行部、１０８ 検証結果、２０１ プロセッサ、２０２ 補助記憶装置、２０３ メモリ、２０４ 表示装置、２０５ 操作装置、７０１ 通信モデル、７０２ モデル検査部、７０３ 検知ルール生成部。

Claims (6)

1. 検証対象ソフトウェアが導入される機器における正常な通信データを定義する検知ルールを用いて、前記検証対象ソフトウェアが実行結果として出力すべき期待値を生成するための検証用ソフトウェアを生成する検証用ソフトウェア生成部と、
   前記検証用ソフトウェアにテストパターンを入力して、前記検証用ソフトウェアを実行させることで、前記期待値をテストケースとして生成するテストケース生成部と、
   前記テストパターンと同一のテストパターンを前記検証対象ソフトウェアに入力して、前記検証対象ソフトウェアを実行させることで得られた実際の実行結果と、前記テストケースによる前記期待値とを比較することで、前記検証対象ソフトウェアの合否を判定する検証実行部と
   を備えた、ソフトウェア試験装置。
2. 予め設定されたモデル検査ルールに従って、前記正常な通信データの設計モデルである通信モデルに誤りが無いか否かのモデル検査を行うモデル検査部と、
   前記モデル検査後の前記通信モデルに基づいて、前記検知ルールを生成する検知ルール生成部と
   をさらに備えた、請求項１に記載のソフトウェア試験装置。
3. 前記検証用ソフトウェア生成部は、
   前記正常な通信データを定義する定義項目として、送信元情報、送信先情報、データ長さ、ペイロードのうちの少なくとも１つの情報を含む、前記検知ルールが入力され、
   前記検知ルールを検知ルール解析して、前記定義項目を葉とし、各ルールを木とする、ルールリスト木を生成し、
   前記ルールリスト木から、全ての木の前記定義項目を共通な項目ごとに結合して、決定木を生成し、
   前記決定木から、前記検証用ソフトウェアを生成する、
   請求項１または２に記載のソフトウェア試験装置。
4. 前記検証用ソフトウェア生成部は、
   前記ルールリスト木から、前記検知ルールに応じた形式検証プロパティを生成し、
   前記形式検証プロパティを用いて、前記決定木から生成した前記検証用ソフトウェアを形式的に検証する、
   請求項３に記載のソフトウェア試験装置。
5. 検証対象ソフトウェアが導入される機器における正常な通信データを定義する検知ルールを用いて、前記検証対象ソフトウェアが実行結果として出力すべき期待値を生成するための検証用ソフトウェアを生成する検証用ソフトウェア生成ステップと、
   前記検証用ソフトウェアにテストパターンを入力して、前記検証用ソフトウェアを実行させることで、前記期待値をテストケースとして生成するテストケース生成ステップと、
   前記テストパターンと同一のテストパターンを前記検証対象ソフトウェアに入力して、前記検証対象ソフトウェアを実行させることで得られた実際の実行結果と、前記テストケースによる前記期待値とを比較することで、前記検証対象ソフトウェアの合否を判定する検証実行ステップと
   を備えた、ソフトウェア試験方法。
6. コンピュータに、
   検証対象ソフトウェアが導入される機器における正常な通信データを定義する検知ルールを用いて、前記検証対象ソフトウェアが実行結果として出力すべき期待値を生成するための検証用ソフトウェアを生成する検証用ソフトウェア生成ステップと、
   前記検証用ソフトウェアにテストパターンを入力して、前記検証用ソフトウェアを実行させることで、前記期待値をテストケースとして生成するテストケース生成ステップと、
   前記テストパターンと同一のテストパターンを前記検証対象ソフトウェアに入力して、前記検証対象ソフトウェアを実行させることで得られた実際の実行結果と前記テストケースによる前記期待値とを比較することで、前記検証対象ソフトウェアの合否を判定する検証実行ステップと
   を実行させるためのソフトウェア試験プログラム。

Images