JP2017097862A - セーフティクリティカルソフトウェア自動要求ベーステストケース生成のためのシステムおよび方法 - Google Patents

Abstract

【課題】セーフティクリティカルソフトウェア自動要求ベーステストケースを生成するための方法を提供する。
【解決手段】モデルベース開発ツール１５０において、ソフトウェア設計モデルからソフトウェアアーキテクチャモデル１３４を構築し、要求モデルがソフトウェアアーキテクチャモデルのブロック／演算子に割り付けられる。構成要素レベル要求ベーステストケース生成ユニットは１４０は、要求モデルが割り付けられている階層データフロー図の形態のソフトウェアアーキテクチャを受信し、ソフトウェア構成要素のうちの１つまたは複数を選択し、選択されているテスト戦略に基づいて対応するソフトウェアアーキテクチャモデルブロック／演算子にテスト目標または制約を付加することにより、選択されてた構成要素に基づいて中間テストモデルを構築し、実行可能なテストおよびテスト検討アーティファクトに変換してテストケースを生成する。
【選択図】図１

Description

本発明は、セーフティクリティカルソフトウェア自動要求ベーステストケース生成のためのシステムおよび方法に関する。

航空ソフトウェアのようなセーフティクリティカルソフトウェアは、認証基準（たとえば、航空ソフトウェアのＤＯ−１７８Ｂ／Ｃ）によって、認証目標に照らして厳密に検証されることが必要とされる。試験は、検証プロセスの必須部分である。要求からの手動テストケース生成は、特に複雑で大規模なソフトウェアでは困難で、時間がかかる。

テストケースを自動生成すること、および／または、高レベルソフトウェア要求からテスト手順を導出することは、手動テストケース生成および検討活動によって導入される費用を低減する一助となり得る。仕様から生成されるそれらのテストケースおよび／またはテスト手順は、テストコンダクタを通じて、関連する低レベル設計実装に対して実行することができる。

従来のテストツールおよび／またはモデルは、設計モデル内の複数の異なるレベルにおいて要求ベーステストケースを生成することは可能でない。従来のツールによってもたらされる、生成されるテストケースは、設計内の複数のレベルにある構成要素上で直に実行することができない。

米国特許出願公開第２０１４００６８３３９号公報

本発明の一態様において、自動要求ベーステストケース生成のための方法が提供され、この方法は、
モデルベース開発ツール（１５０）においてソフトウェアアーキテクチャモデル（３００）を構築することであって、ソフトウェアアーキテクチャモデル（３００）は、ソフトウェア設計モデル（１０００）のアーキテクチャ情報から自動的に導出される、構築するステップと、
要求モデル（ＲＥＱ１〜ＲＥＱ２８）をソフトウェアアーキテクチャモデル（３００）の複数の異なる構成要素に割り付けるステップと、
テストケース生成器ユニット（１４０）が、ソフトウェアアーキテクチャモデル（３００）から構成要素レベル要求ベーステストケース（１３６）を生成するステップと
を含む。

実施形態による自動要求ベーステストケース生成のためのシステムを示す図である。 実施形態によるソフトウェア試験のためのプロセスを示す図である。 実施形態による、ソフトウェア設計から自動的に導出されるソフトウェアアーキテクチャモデルを示す図である。 実施形態による、ソフトウェア設計から自動的に導出されるソフトウェアアーキテクチャモデルを示す図である。 実施形態による、ソフトウェア設計から自動的に導出されるソフトウェアアーキテクチャモデルを示す図である。 実施形態による、ソフトウェア設計から自動的に導出されるソフトウェアアーキテクチャモデルを示す図である。 実施形態による構成要素レベルテストケース生成のためのプロセスを示す図である。 実施形態による要求モデルを示す図である。 実施形態による、テスト目標を付された要求モデルを示す図である。 実施形態による、テスト目標を付された論理条件網羅モデルを示す図である。 実施形態による、テスト目標を付された入力マスキングモデルを示す図である。 実施形態による、テスト目標を付された入力マスキングモデルを示す図である。 実施形態による、テストスクリプト生成および検討プロセスを示す図である。 実施形態による、例示的なソフトウェアアーキテクチャ設計および関連する要求トレーサビリティ情報を示す図である。 実施形態による例示的なユニットレベルテストスクリプトを示す図である。 実施形態による例示的な統合レベルテストスクリプトを示す図である。

実施形態によれば、システムおよび方法は、提案されるソフトウェアアーキテクチャモデルに基づくマルチレベルアーキテクチャ要求ベーステストケース生成を自動化するために、要求モデルとともにソフトウェア設計アーキテクチャからソフトウェアアーキテクチャモデルを自動的に作成する。

実施形態によれば、ソフトウェアアーキテクチャモデルおよびその要求割り付けは、階層データフロー図の表現を用いるモデルベース開発（ＭＢＤ）ツールを使用して構築される。低レベル設計に伝統的に使用されている、従来のＭＢＤツールとは対照的に、具現化するＭＢＤツールは、ソフトウェア設計アーキテクチャからソフトウェアアーキテクチャモデルを自動的に作成し、システムレベルまたは高レベル要求に対する対応するテストケースを生成する。

具現化する実施形態のシステムおよび方法は、ソフトウェアアーキテクチャの複数の異なるレベルにある構成要素のテストケースを自動的に生成するために、構成要素レベル要求ベーステストケース生成を実装することができる。

図１は、実施形態による自動要求ベーステストケース生成のためのシステム１００を示す。システム１００は、システムおよびその構成要素の動作を制御するためのコンピュータ命令１３１を実行する制御プロセッサ１１０を含む。実行可能命令は、データストア１３０に記憶することができ、データストアはまた、システムによってアクセスおよび生成されるデータをも記憶することができる。制御プロセッサ１１０は、コンピュータまたはサーバ内に位置し、通信リンク１２０を介して様々な構成要素に相互接続することができる。通信リンクは、内部バス、電子通信ネットワークなどであってもよい。システム１００は、セーフティクリティカルソフトウェアのシステムレベル要求および／または高レベル要求１３２からテストケースを生成することができる。

図２は、実施形態による自動ソフトウェア試験のためのプロセス２００を示す。プロセス２００は、ソフトウェア設計モデルからソフトウェアアーキテクチャモデル１３４を導出する。ソフトウェアアーキテクチャモデルは、ステップ２０５において、設計モデルのアーキテクチャ情報に基づいてモデルベース開発ツール１５０環境において構築される。このソフトウェアアーキテクチャモデルは、いくつかの実装態様に従って自動的に作成することができる。ステップ２１０において、対応して監視／制御される変数（たとえば、図１：ＶＡＲ１〜ＶＡＲ１９）を構成要素の入力／出力ポートと接続することによって、要求モデルがソフトウェアアーキテクチャモデル内の複数の異なるモジュールに割り付けられる。いくつかの実施形態によれば、ステップ２０５において、要求モデル内のすべての出力変数に対する入力ポートを追加することができる。すべての出力変数に対する入力ポートを追加することによって、テストケース生成器は、１回の作動においてテストケースの入力および予測される出力を生成することができる。

構成要素レベルテストケース生成器ユニット１４０は、ステップ２１５において、ユニット／モジュールレベル要求ベーステストケースを生成するために、要求が割り付けられているソフトウェアアーキテクチャモデルを使用することができる。テストケース生成器ユニット１４０はまた、ステップ２２０において、コード構成要素または統合が割り付けられた要求に従っているか否かを検証するために、統合レベルテストケースを生成することもできる。

図３Ａ〜図３Ｄは、実施形態による、ソフトウェア設計アーキテクチャに基づいて階層データフロー図として構築されるソフトウェアアーキテクチャモデル３００を示す。ソフトウェア設計内の各構成要素Ｃｏｍｐｏｎｅｎｔ１、Ｃｏｍｐｏｎｅｎｔ２、Ｃｏｍｐｏｎｅｎｔ３、Ｃｏｍｐｏｎｅｎｔ４は、入力ポートおよび出力ポートを有するソフトウェアアーキテクチャモデル内のブロック／演算子である。ソフトウェアアーキテクチャモデル内のブロック／演算子は、互いに接続され、サブブロック／サブ演算子の複数の層を有することができる。要求モデルＲＥＱ１２、ＲＥＱ１３、ＲＥＱ１４、ＲＥＱ１５がソフトウェアアーキテクチャモデルに割り付けられ、入力ポートおよび出力ポートに接続される。構築プロセスは自動的、系統的かつモジュール式である。階層データフローは、良好に視覚化し、要求からソフトウェア設計へと容易にトレースすることを可能にする。

図４は、実施形態による構成要素レベルテストケース生成のためのプロセス４００を示す。プロセス４００は、ステップ４０５において受信される、要求モデルが割り付けられている階層データフロー図の形態の自動生成されたソフトウェアアーキテクチャモデルに基づく。ステップ４１０において、テスト生成のレベルに基づいて、ソフトウェア設計内のソフトウェア構成要素のうちの１つまたは複数が選択され、対応するソフトウェアアーキテクチャモデルブロック／演算子がテストケース生成に使用される。ステップ４１５において、テスト制約およびテスト目標を対応するソフトウェアアーキテクチャモデルブロック／演算子に付加することによって、選択された構成要素に基づいて中間テストモデルが構築される。テスト目標は、要求網羅（たとえば、すべての要求が有効にされる）、論理条件網羅（たとえば、要求内の論理条件が一定レベルにおいて有効にされる）などのような、要求レベルにおける一定の網羅基準を満たすために付加される。テスト制約は、監視／制御される変数範囲を制約し、生成されるテストケースが要求に違反しないことを保証するためにモデルに付加される。

自動テストケース生成戦略（すなわち、テスト目標および制約を付加するための）は、一般的な形態の要求に基づくことができる。自然な構造の英語では、要求の形態は以下のように表現することができる。

＜先行式＞は＜帰結式＞を意味する（＜ａｎｔｅｃｅｄｅｎｔ ｅｘｐｒｅｓｓｉｏｎ ＞ ｉｍｐｌｉｅｓ ＜ｃｏｎｓｅｑｕｅｎｔ ｅｘｐｒｅｓｓｉｏｎ＞）
ここで、＜先行式＞は、監視される変数に対する論理表現である。

また、＜帰結式＞は、制御される変数に対する論理表現である。

図５は、実施形態による（Ｓｉｍｕｌｉｎｋにおいて表現されるときの）要求モデル５００を示す。要求モデルは、先行式５１０および帰結式５２０を含む。これらの式は、式の状態（すなわち、Ａ＝＝＞Ｂ）に基づいて出力信号５４０を意味する論理ブロック５３０に提供される。要求が成立するようにするために、出力信号は１すなわち「真」でなければならない。自動テストケース生成器ユニット１４０はそれを受信し、そこから、１つまたは複数の戦略（たとえば、要求網羅戦略、論理条件網羅戦略、入力マスキング戦略など）に従ってテストケースを生成する。実施形態はそのようには限定されず、テストケース生成のための他の戦略が、本開示の意図の範疇にある。

要求網羅戦略は、各要求について、先行式が真であることによって要求が満たされなければならない１つのテストケースを生成することを含む。これは、テスト目標および制約を挿入し、テスト目標を達成するための入力シーケンスを駆動することができるテスト生成エンジンを作動させることによって行われる。

例として、テスト目標の挿入は、選択されるモデルベース開発ツール内の商用設計検証器ブロックライブラリからのテスト目標およびテスト条件ブロック（たとえば、Ｓｉｍｕｌｉｎｋから入手可能なＳｉｍｕｌｉｎｋ設計検証器ブロックなど）を使用して行うことができる。テスト生成エンジンは、入力を駆動してテスト目標を達成するために使用することができる。図６は、実施形態による、テスト目標を付された要求モデル６００を示す図である。ブール型であるその先行式が真であるようにする変数値割り当てＶＡＲ２１、ＶＡＲ２２の組み合わせを見つけるために、テスト目標ブロック６１０（円の中の「Ｏ」によって表記される）が、設計検証器によって分析される。テスト条件ブロック６２０（円の中の「Ｃ」によって表記される）が、設計検証器に、「意味する」ブロックの出力が真のままであるようにさせる。「意味する」ブロックの真出力信号は、要求ＲＥＱ２７が満たされていることの指標である。監視および制御される変数に対する値割り当ては、設計検証器によって自動的に生成される。

論理条件網羅（ＬＣＣ）戦略は、論理式条件の機能的網羅を達成するために実装することができる。論理式内の各条件は、その条件のみを変更し、結果に影響を与え得るすべての他の条件については固定したままにすることによって、論理式の結果に影響を及ぼすことが実証されている。２つの変数に関する論条件網羅を示す表１の例を考慮する。２つのブール値（ａおよびｂ）が、リストされているブール型演算子に対する条件である。表１はテストケースがＬＣＣ網羅（レ）またはｎｏｔ（ｘ）を達成するために必要であるか否かを示す。先行式がこれらの演算子の１つを有するとき、（レ）によってマークされている対応する組み合わせの各々についてテストケースが生成され、これは、任意の数のオペランドについて生成可能である。

図７は、実施形態による、テスト目標を付された論理条件網羅モデル７００を示す。このＬＣＣモデルは、追加のテスト目標および条件ブロック７１０、７２０、７３０のパターンを有する要求モデル６００に基づく。テストケースを生成するために、表１内の使用されているブール演算子およびそれぞれケースに従ってテスト目標ブロックが付加される。テスト生成エンジンが作動した後、論理条件網羅を満たすためにテストケースのセットが生成される。各生成されるテストケースはまた、そのテストケースがいずれの要求を「起動」するかを見出すために試験される。起動とは、充足可能性ポート７４０の出力信号が１すなわち「真」でなければならないことを意味する。

入力マスキング戦略は、マスキング改良条件／判定網羅（ＭＣ／ＤＣ）を達成することができる。マスキングＭＣ／ＤＣは、マスキングＭＣ／ＤＣは、固有の原因と同じ各論理演算子における最小のテストケースを保証することによって独立した効果の定義を満たし、セーフティクリティカルソフトウェア開発規格（たとえば、ＤＯ−１７８Ｂ／Ｃ）のＭＣ／ＤＣ目標を満たすために許容可能である。マスキングとは、論理構築に対する特定の入力が、その構築に対する他の入力の効果を隠すことができるという概念を指す。たとえば、ＡＮＤ演算子に対する偽入力はすべての他の入力をマスクし、ＯＲ演算子に対する真入力は、すべての他の入力をマスクする。ＭＣ／ＤＣに対するマスキング手法は、対象の条件が判定結果の値に影響を与える唯一の条件であることが示される限り、２つ以上の入力が独立した対において変化することを可能にする。しかしながら、対象の条件が、判定の結果の値を変化させる唯一の条件であることを示すために、判定の内部論理の分析が必要とされる。

図８Ａ〜図８Ｂは、実施形態による、テスト目標を付された入力マスキングモデル戦略８００を示す。入力マスキングモデル８００内に図示されている各副次式は、監視される変数ＶＡＲ２３、ＶＡＲ２４、ＶＡＲ２５を含む先行式の入力条件において開始し、監視される式の結果を表す信号において終端する信号／ブロック経路に対応する。このモデルから、自動テストケース生成器ユニット１４０によってテストケースを自動的に生成して要求ＲＥＱ２８に関連付け、出力テストスクリプトに変換することができる。

入力マスキングテスト生成戦略は、以下のステップに従って、テスト目標を付加する。

先行式の各基礎命題（入力条件）について、この命題自体を除き、この命題を含むすべての副次式から成る集合Ｓを得る。その後、集合Ｓ内の各式について、（１）副次式の最上位演算がＯＲゲートである場合、この式を、Ｓ内のその否定に置き換え、（２）Ｓ内のすべての式および上記の基礎命題の共役である式ｅを作成し、（３）式ｅを真にしなければならないテスト目標を作成する。

図４を再び参照すると、テスト制約およびテスト目標が付加された後、プロセス４００は、テストケース生成器ユニット１４０が、テストケース１３６を生成するステップ４２０によって継続する。テストケース生成器ユニットは、テスト目標を満たし、および／または、到達不可能なテスト目標を検出するように、中間テストモデルに対して、テストケースを生成しモデルチェック、制約解決、および到達可能性解決方法を実施することができる。生成されたテストケースは、ステップ４２５において、テスト実行のためのテストスクリプト、および、認証のためのテスト検討アーティファクトに変換される。構成要素レベルテスト生成方法の利点は、方法が、適切な要求レベル網羅基準を達成するために、ソフトウェアアーキテクチャ内の複数の異なるレベルにある構成要素について要求ベーステストケースを自動的に生成するように、柔軟であることである。実施形態によれば、ユニット／モジュールレベル試験ならびに統合レベル試験に適用可能なテストケースを生成することができる。

図９は、実施形態によるテストスクリプト生成およびテストアーティファクト検討のためのプロセス９００を示す。プロセス９００によって生成される中間フォーマット９０５は、人間および／または機械によって読解可能であり得る。プロセス９００は、上述した構成要素レベルテストケースに対して機能する。ステップ９０５において、テストケースから中間フォーマットが生成される。この中間フォーマットは、入力および予測される出力情報を示すことができる。中間フォーマットはまた、テストケースが追従する要求、テストケースが満たしているテスト目標、および、テスト目標が導出される基準をも示すことができる。中間情報は、手動で、または、自動的にテスト検討を行うために使用することができる。ステップ９１０において、中間情報から認証アーティファクトが生成される。中間情報は、ステップ９１５において、複数の異なるテスト環境において実行するのに適した実行可能なテストスクリプトを生成するために使用することができる。ステップ９２０において、要求およびテスト管理ツール（たとえば、ＩＢＭ（登録商標）Ｒａｔｉｏｎａｌ（登録商標）ＤＯＯＲＳ（登録商標））に、テストスクリプトを自動的にライトバックすることもできる。

図１０〜図１３はまとめて、実施形態によるエンドツーエンドの実装態様の例示を示す。図１０は、実施形態による、例示的なソフトウェアアーキテクチャ設計モデル１０００および関連する要求トレーサビリティ情報を示す。ソフトウェアアーキテクチャモデルは、Ｓｉｍｕｌｉｎｋモデル（図３Ａ〜図３Ｄ）として構築することができる（図２、ステップ２０５）。ソフトウェア設計モデルソフトウェアアーキテクチャ設計内の各ブロックは、同じインターフェースおよびアーキテクチャ情報を有する、Ｓｉｍｕｌｉｎｋにおけるソフトウェアアーキテクチャモデル内のブロックに変換される。ソフトウェアアーキテクチャモデル内の各ブロックはまた、図１０の要求トレーサビリティ情報に基づいて、要求モデルのセットを割り付けられる。たとえば、図３Ｄにおいては、図１０内の情報に基づいて、４つの要求モデル（１０１０）がｃｏｍｐｏｎｅｎｔ２に割り付けられている。同様に、ブロック１０２０は、ｃｏｍｐｏｎｅｎｔ１の要求トレーサビリティ情報を示し、ブロック１０３０は、ｃｏｍｐｏｎｅｎｔ３の要求トレーサビリティ情報を示し、ブロック１０４０は、ｃｏｍｐｏｎｅｎｔ４の要求トレーサビリティ情報を示す。図３Ａ〜図３Ｄに示すソフトウェアアーキテクチャモデルはその後、ソフトウェアアーキテクチャ内の複数の異なるレベルにおける要求ベーステストケースを生成するために使用される。

ユーザは、このユニットレベルにおけるテストケースを生成し、入力マスキングテスト戦略を選択するために、「ｃｏｍｐｏｎｅｎｔ２」ブロック（図４、ステップ４１０）を選択することができる。実施形態によれば、テスト目標および制約ブロックは、ステップ４１５において「ｃｏｍｐｏｎｅｎｔ２」ブロック内部のすべての要求モデルに自動的に付加される。ステップ４２０においてＳｉｍｕｌｉｎｋ設計検証器を呼び出し、ステップ４２５においてテストケースを変換した後、入力マスキングテスト戦略のすべてのテスト目標および制約を満たすテストケースが生成されることになる。

図１１は、実施形態による例示的なユニットレベルテストスクリプト１１００を示す。このユニットレベルテストスクリプトは、「ｃｏｍｐｏｎｅｎｔ２」についての、ユニットレベルにある生成されるテストケースの一例である。テストケースは、設計内の「ｃｏｍｐｏｎｅｎｔ２」ブロック上のＳＣＡＤＥテスト環境内で実行することが可能であるように生成される。ユーザは代替的に、統合レベルテストケースを生成するために、図４、ステップ４１０において、構成要素１〜４を含む統合レベルブロックを選択してもよい。実施形態によれば、テスト目標および制約ブロックは、ステップ４１５において統合レベルブロック内部のすべての要求モデルに自動的に付加される。ステップ４２０においてＳｉｍｕｌｉｎｋ設計検証器を呼び出し、ステップ４２５においてテストケースを変換した後、入力マスキングテスト戦略のすべてのテスト目標および制約を満たすテストケースが生成されることになる。

図１２は、実施形態による例示的な統合レベルテストスクリプト１２００を示す。このテストスクリプトは、生成される統合レベルテストケースの一例である。テストケースは、設計内の統合レベルブロック上のＳＣＡＤＥテスト環境内で実行することが可能であるように生成される。

実施形態によれば、階層データフロー図（すなわち、要求モデルを伴うソフトウェアアーキテクチャモデル）が、要求および設計情報を捕捉するために自動的に作成される。この階層データフロー図は、ソフトウェアアーキテクチャ内の複数の異なるレベルにおける要求ベーステストケースを生成するために使用される。実施形態によれば、システム設計情報が、階層データフロー図を構築するために使用され、要求モデルが、階層データフロー図のモジュール内部に割り付けられる。要求割り付けは、設計情報からの要求モジュールトレーサビリティ情報に基づく。ユーザ選択のテスト戦略に従って、テスト目標および制約を、ソフトウェアアーキテクチャモデルに付加することができる。自動テストケース生成は、テスト目標および制約を満たす設計アーキテクチャ内で、複数の異なるレベルにある要求ベーステストケースを生成するために、階層データフロー図に基づく。生成されるテストケースは、設計内の複数のレベルにある構成要素上で直に実行することができる。

いくつかの実施形態によれば、不揮発性メモリまたはコンピュータ可読媒体（たとえば、レジスタメモリ、プロセッサキャッシュ、ＲＡＭ、ＲＯＭ、ハードドライブ、フラッシュメモリ、ＣＤ ＲＯＭ、磁気媒体など）に記憶されているコンピュータプログラムアプリケーションは、実行されると、上述したような、自動要求ベーステストケース生成のための方法のような、本明細書において論じられている方法を実施するように制御装置もしくはプロセッサに命令し、および／または、そのようにさせるコードまたは実行可能命令を含むことができる。

コンピュータ可読媒体は、一時的伝搬信号を除く、すべての形態およびタイプのメモリならびにすべてのコンピュータ可読媒体を含む非一時的コンピュータ可読媒体であってもよい。一実装態様において、不揮発性メモリまたはコンピュータ可読媒体は、外部メモリであってもよい。

特定のハードウェアおよび方法が本明細書において記載されているが、本発明の実施形態によれば、任意の数の他の構成が提供されてもよいことに留意されたい。したがって、本発明の基本的な新規の特徴が図示、記載、および指摘されているが、本発明の趣旨および範囲から逸脱することなく、当業者によって、例示されている実施形態の形態および詳細ならびにそれらの動作の様々な省略、置換、および変更が行われてもよいことが理解されよう。一実施形態から別の実施形態への要素の置換も、完全に意図および企図されている。本発明は、本明細書に添付されている特許請求の範囲、および、その中の記載の均等物のみに関連して定義される。

最後に、代表的な実施態様を以下に示す。
［実施態様１］
自動要求ベーステストケース生成のための方法であって、
モデルベース開発ツール（１５０）においてソフトウェアアーキテクチャモデル（３００）を構築することであって、ソフトウェアアーキテクチャモデル（３００）は、ソフトウェア設計モデル（１０００）のアーキテクチャ情報から自動的に導出される、構築することと、
要求モデル（ＲＥＱ１〜ＲＥＱ２８）をソフトウェアアーキテクチャモデル（３００）の複数の異なる構成要素に割り付けることと、
テストケース生成器ユニット（１４０）が、ソフトウェアアーキテクチャモデル（３００）から構成要素レベル要求ベーステストケース（１３６）を生成することと
を含む、方法。
［実施態様２］
対応する監視または制御される変数（ＶＡＲ１〜ＶＡＲ２５）を、複数の異なるモジュールのそれぞれの入力ポートおよび出力ポートの少なくとも１つと接続することによって、要求モデルを割り付けることを含む、実施態様１に記載の方法。
［実施態様３］
テストケース生成器ユニット（１４０）が、統合レベルテストケースを生成することと、コードモジュールが割り付けられている要求に従っているか否かを検証するために、統合レベルテストケースを適用することとを含む、実施態様１に記載の方法。
［実施態様４］
割り付けられている要求モデルとともに、ソフトウェア設計から導出される階層データフロー図の形態のソフトウェアアーキテクチャモデルを受信することであって、階層データフロー図は、ソフトウェア設計内の対応する構成要素（Ｃｏｍｐｏｎｅｎｔ１〜Ｃｏｍｐｏｎｅｎｔ４）にマッピングする１つまたは複数ブロック／演算子を含む、受信することと、
テストケース生成のために、ソフトウェア設計からソフトウェア構成要素（Ｃｏｍｐｏｎｅｎｔ１〜Ｃｏｍｐｏｎｅｎｔ４）のうちの１つを選択することと、
少なくとも１つのテスト目標およびテスト制約を対応するソフトウェアアーキテクチャモデルブロック／演算子に自動的に付加することによって、選択されている構成要素に基づいて中間テストモデルを構築することと
を含む、実施態様１に記載の方法。
［実施態様５］
テスト生成のレベルに基づいてソフトウェア構成要素（Ｃｏｍｐｏｎｅｎｔ１〜Ｃｏｍｐｏｎｅｎｔ４）を選択することを含む、実施態様４に記載の方法。
［実施態様６］
要求網羅戦略、論理条件網羅戦略、および入力マスキング戦略のリストから選択される少なくとも１つの戦略に従ってテストケースを生成することを含む、実施態様１に記載の方法。
［実施態様７］
中間テストモデルに対して、モデルチェック、制約解決、および到達可能性解決方法の少なくとも１つを実施することによって、要件ベーステストケースを生成することと、
生成されているテストケースをテスト実行のためのテストスクリプト、および、検討のためのテストアーティファクトに変換することと
を含む、実施態様４に記載の方法。
［実施態様８］
プロセッサによって実行されると、プロセッサに、自動要求ベーステストケース生成のための方法を実施させる命令を記憶されている非一時的コンピュータ可読媒体であって、方法は、
ソフトウェアアーキテクチャモデル（３００）を構築することであって、ソフトウェアアーキテクチャモデル（３００）は、ソフトウェア設計モデル（１０００）のアーキテクチャ情報から自動的に導出される、構築することと、
要求モデル（ＲＥＱ１〜ＲＥＱ２８）をソフトウェアアーキテクチャモデル（３００）の複数の異なるブロック／演算子に割り付けることと、
ソフトウェアアーキテクチャモデル（３００）から構成要素レベル要求ベーステストケース（１３６）を生成することと
を含む、非一時的コンピュータ可読媒体。
［実施態様９］
プロセッサに、対応する監視または制御される変数（ＶＡＲ８〜ＶＡＲ２５）を、複数の異なるモジュールのそれぞれの入力ポートまたは出力ポートと接続することによって、要求モデルを割り付けることを行わせるための命令を含む、実施態様８に記載の非一時的コンピュータ可読媒体。
［実施態様１０］
プロセッサに、統合レベルテストケースを生成することと、コードモジュールが割り付けられている要求に従っているか否かを検証するために、統合レベルテストケースを適用することとを行わせるための命令を含む、実施態様８に記載の非一時的コンピュータ可読媒体。
［実施態様１１］
プロセッサに、
割り付けられている要求モデルとともに、ソフトウェア設計から導出される階層データフロー図の形態のソフトウェアアーキテクチャモデルを受信することであって、階層データフロー図は、ソフトウェア設計内の対応する構成要素（Ｃｏｍｐｏｎｅｎｔ１〜Ｃｏｍｐｏｎｅｎｔ４）にマッピングする１つまたは複数ブロック／演算子を含む、受信することと、
テストケース生成のために、ソフトウェア設計からソフトウェア構成要素（Ｃｏｍｐｏｎｅｎｔ１〜Ｃｏｍｐｏｎｅｎｔ４）のうちの１つを選択することと、
少なくとも１つのテスト目標およびテスト制約を対応するソフトウェアアーキテクチャモデルブロック／演算子に付加することによって、選択されている構成要素に基づいて中間テストモデルを構築することと
を行わせるための命令を含む、実施態様８に記載の非一時的コンピュータ可読媒体。
［実施態様１２］
プロセッサに、要求網羅戦略、論理条件網羅戦略、および入力マスキング戦略のリストから選択される少なくとも１つの戦略に従ってテストケースを生成することを行わせるための命令を含む、実施態様１０に記載の非一時的コンピュータ可読媒体。
［実施態様１３］
プロセッサに、
中間テストモデルに対して、モデルチェック、制約解決、および到達可能性解決方法の１つを実施することによって、要件ベーステストケースを生成することと、
生成されているテストケースをテスト実行のためのテストスクリプト、および、検討のためのテストアーティファクトに変換することと
を行わせるための命令を含む、実施態様１１に記載の非一時的コンピュータ可読媒体。
［実施態様１４］
自動要求ベーステストケース生成のためのシステム（１００）であって、
命令を実行するように構成されている制御プロセッサ（１１０）を含むモデルベース開発ツール（１５０）であって、制御プロセッサ（１１０）は通信リンク（１２０）に接続されている、モデルベース開発ツール（１５０）と、
テストケース（１３６）を自動的に生成するための構成要素レベルテストケース生成器ユニット（１４０）と
を備える、システム（１００）。
［実施態様１５］
制御プロセッサ（１１０）に、
ソフトウェア設計からソフトウェアアーキテクチャモデル（３００）を導出するステップと、
要求モデル（ＲＥＱ１〜ＲＥＱ２８）をソフトウェアアーキテクチャモデル（３００）の複数の異なるブロック／演算子に割り付けるステップと、
構成要素レベルテストケースを生成するステップと
を実施させる命令を実行するように構成されている制御プロセッサ（１１０）を含む、実施態様１４に記載のシステム（１００）。
［実施態様１６］
制御プロセッサ（１１０）に、統合レベルテストケースを生成することと、コードモジュールがソフトウェアアーキテクチャモデル（３００）および割り付けられている要求モデルに従っているか否かを検証するために、統合レベルテストケースを適用することとを行わせるための命令を実行するように構成されている制御プロセッサ（１１０）を含む、実施態様１５に記載のシステム（１００）。
［実施態様１７］
制御プロセッサ（１１０）に、
割り付けられている要求モデルとともに、ソフトウェア設計から導出される階層データフロー図の形態のソフトウェアアーキテクチャモデルを受信することであって、階層データフロー図は、ソフトウェア設計内の対応する構成要素（Ｃｏｍｐｏｎｅｎｔ１〜Ｃｏｍｐｏｎｅｎｔ４）にマッピングする１つまたは複数ブロック／演算子を含む、受信することと、
テストケース生成のために、ソフトウェア設計からソフトウェア構成要素（Ｃｏｍｐｏｎｅｎｔ１〜Ｃｏｍｐｏｎｅｎｔ４）のうちの１つを選択することと、
少なくとも１つのテスト目標およびテスト制約を対応するソフトウェアアーキテクチャモデルブロック／演算子に自動的に付加することによって、選択されている構成要素に基づいて中間テストモデルを構築することと
を行わせるための命令を実行する用に構成されている制御プロセッサ（１１０）を含む、実施態様１５に記載のシステム（１００）。

１００ システム
１１０ 制御プロセッサ
１２０ 通信リンク
１３０ データストア
１３１ コンピュータ命令
１３２ 高レベル要求
１３４ ソフトウェアアーキテクチャモデル
１３６ テストケース
１４０ テストケース生成器ユニット
１５０ モデルベース開発ツール
３００ ソフトウェアアーキテクチャモデル
ＶＡＲ１〜ＶＡＲ１９ 変数
ＲＥＱ１２〜ＲＥＱ１５ 要求モデル
Ｃｏｍｐｏｎｅｎｔ１〜Ｃｏｍｐｏｎｅｎｔ４ 構成要素
５００ 要求モデル
５１０ 先行式
５２０ 帰結式
５３０ 論理ブロック
５４０ 出力信号
６００ 要求モデル
６１０ テスト目標ブロック
６２０ テスト条件ブロック
ＶＡＲ２０〜ＶＡＲ２２ 変数
ＲＥＱ２７ 要求
７００ 論理条件網羅モデル
７１０ 条件ブロック
７２０ 条件ブロック
７３０ 条件ブロック
７４０ 充足可能性ポート
８００ 入力マスキングモデル戦略
ＶＡＲ２３〜ＶＡＲ２５ 変数
ＲＥＱ２８ 要求
１０００ ソフトウェアアーキテクチャ設計モデル
１０１０ ブロック
１０２０ ブロック
１０３０ ブロック
１０４０ ブロック
ＲＥＱ１〜ＲＥＱ１１ 要求モデル
ＲＥＱ１６〜ＲＥＱ２６ 要求モデル
１１００ ユニットレベルテストスクリプト
１２００ 統合レベルテストスクリプト

Claims (7)

1. 自動要求ベーステストケース生成のための方法であって、
   モデルベース開発ツール（１５０）においてソフトウェアアーキテクチャモデル（３００）を構築することであって、前記ソフトウェアアーキテクチャモデル（３００）は、ソフトウェア設計モデル（１０００）のアーキテクチャ情報から自動的に導出される、構築することと、
   要求モデル（ＲＥＱ１〜ＲＥＱ２８）をソフトウェアアーキテクチャモデル（３００）の複数の異なる構成要素に割り付けることと、
   テストケース生成器ユニット（１４０）が、前記ソフトウェアアーキテクチャモデル（３００）から構成要素レベル要求ベーステストケース（１３６）を生成することと
   を含む、方法。
2. 対応する監視または制御される変数（ＶＡＲ１〜ＶＡＲ２５）を、複数の異なるモジュールのそれぞれの入力ポートおよび出力ポートの少なくとも１つと接続することによって、前記要求モデルを割り付けることを含む、請求項１記載の方法。
3. 前記テストケース生成器ユニット（１４０）が、統合レベルテストケースを生成することと、コードモジュールが前記割り付けられている要求に従っているか否かを検証するために、前記統合レベルテストケースを適用することとを含む、請求項１記載の方法。
4. 前記割り付けられている要求モデルとともに、前記ソフトウェア設計から導出される階層データフロー図の形態の前記ソフトウェアアーキテクチャモデルを受信することであって、前記階層データフロー図は、前記ソフトウェア設計内の対応する構成要素（Ｃｏｍｐｏｎｅｎｔ１〜Ｃｏｍｐｏｎｅｎｔ４）にマッピングする１つまたは複数ブロック／演算子を含む、受信することと、
   テストケース生成のために、前記ソフトウェア設計から前記ソフトウェア構成要素（Ｃｏｍｐｏｎｅｎｔ１〜Ｃｏｍｐｏｎｅｎｔ４）のうちの１つを選択することと、
   少なくとも１つのテスト目標およびテスト制約を前記対応するソフトウェアアーキテクチャモデルブロック／演算子に自動的に付加することによって、前記選択されている構成要素に基づいて中間テストモデルを構築することと
   を含む、請求項１記載の方法。
5. テスト生成のレベルに基づいて前記ソフトウェア構成要素（Ｃｏｍｐｏｎｅｎｔ１〜Ｃｏｍｐｏｎｅｎｔ４）を選択することを含む、請求項４記載の方法。
6. 要求網羅戦略、論理条件網羅戦略、および入力マスキング戦略のリストから選択される少なくとも１つの戦略に従って前記テストケースを生成することを含む、請求項１記載の方法。
7. 前記中間テストモデルに対して、モデルチェック、制約解決、および到達可能性解決方法の１つを実施することによって、要件ベーステストケースを生成することと、
   前記生成されるテストケースをテスト実行のためのテストスクリプト、および、検討のためのテストアーティファクトに変換することと
   を含む、請求項４記載の方法。