(57)【特許請求の範囲】
【請求項１】
システム（１００）であって、
ユーザと通信して、テストケース生成モジュール（１０６）のためのモデルと関連づけられた１つまたは複数の要件（１０２）を取得するよう動作する通信デバイス（１２２０）と、
前記モデルを受信し、前記モデルを格納し、中間モデル（４００）を生成するための変換コンピュータモジュール（３０２）と、
前記中間モデル（４００）を受信し、前記中間モデル（４００）を格納し、少なくとも１つのテストケースを生成するための生成器コンピュータモジュール（３１４）と、
プログラム命令を格納するためのメモリと、
前記メモリに結合されて、前記変換コンピュータモジュール（３０２）および前記生成器コンピュータモジュール（３１４）と通信して、
さらに前記変換コンピュータモジュール（３０２）を実行することによる前記モデルの中間モデル（４００）への変換、
前記生成器コンピュータモジュール（３１４）を実行することによる前記中間モデル（４００）の解析に基づく前記中間モデル（４００）と関連づけられたモデル型の識別、
前記生成器コンピュータモジュール（３１４）を実行することによる前記識別されたモデル型の解析に基づくテスト生成方法の選択、および
ソフトウェア検証および検査で使用するための
少なくとも１つのテストケースの生成のためのプログラム命令を実行するよう動作する少なくとも１つのテストケース生成プラットフォームプロセッサ（１２１０）と
を備える、システム。
【請求項２】
前記モデルは、仕様モデル（１０４）および設計モデル（１０８）の一方である、請求項１に記載のシステム。
【請求項３】
各要件（１０２）は、１つまたは複数の入力変数（１１０４）、および１つまたは複数の出力変数を含む、請求項１に記載のシステム。
【請求項４】
前記少なくとも１つの生成されたテストケースは、前記要件（１０２）の記述、入力変数（１１０４）のセット、および期待出力（１１０６）のセットを含み、期待出力（１１０６）の前記セットは、前記１つまたは複数の出力変数に基づく、請求項３に記載のシステム。
【請求項５】
前記モデル型は、記号変数モデル型、実数モデル型、非線形演算モデル型、およびフィードバック・ループ・モデル型の少なくとも１つである、請求項１に記載のシステム。
【請求項６】
前記中間モデル（４００）は、前記少なくとも１つのモデルから、関連したサンプリング時間ごとに、１つまたは複数の挙動を保存する、請求項１に記載のシステム。
【請求項７】
前記変換コンピュータモジュール（３０２）は、前記少なくとも１つのモデルの１つまたは複数の計算シーケンスを、前記中間モデル（４００）における１つまたは複数の計算パス（４０２）にマッピングする、請求項６に記載のシステム。
【請求項８】
１つまたは複数のテスト基準（３０６）を、１つまたは複数のテスト目標（３１０）に変換するよう動作するコンバータモジュール（３１２）をさらに備え、各テスト目標（３１０）が、テスト目標パスと関連づけられる、請求項７に記載のシステム。
【請求項９】
前記１つまたは複数のテスト目標（３１０）が、前記中間モデル（４００）に添付される、請求項８に記載のシステム。
【請求項１０】
前記計算パス（４０２）が、モデル挙動を記述し、前記テスト目標パスが、テスト目標（３１０）を記述する、請求項９に記載のシステム。
【請求項１１】
前記生成器コンピュータモジュール（３１４）が、前記計算パス（４０２）および前記テスト目標パスに基づいて、１つまたは複数のパス制約および１つまたは複数のデータを含む表を生成するよう動作する、請求項８に記載のシステム。
【請求項１２】
前記生成器コンピュータモジュール（３１４）が、前記中間モデル（４００）における計算の前記型を識別するよう動作する、請求項１１に記載のシステム。
【請求項１３】
前記生成器コンピュータモジュール（３１４）が、モデルチェックモジュール（３１６）、制約解決モジュール（３１８）、および可到達性解決モジュール（３２０）の１つを選択し、前記中間モデル（４００）に適用し、前記計算型に基づいてテストケースを生成するよう動作する、請求項１２に記載のシステム。
【請求項１４】
前記中間モデル（４００）が、所与の目標と関連づけられた前記中間モデル（４００）の一部のみを含むよう削減される、請求項１に記載のシステム。
【請求項１５】
方法であって、
テストケースを生成するためのモデルと関連づけられた１つまたは複数の要件（１０２）を受信するステップと、
変換コンピュータモジュール（３０２）の実行により前記モデルを中間モデル（４００）に変換するステップと、
生成器コンピュータモジュール（３１４）の実行による前記中間モデル（４００）の解析に基づいて前記中間モデル（４００）と関連づけられたモデル型を識別するステップと、
前記生成器コンピュータモジュール（３１４）の実行による前記識別されたモデル型に基づいてテスト生成方法を選択するステップと、
ソフトウェア検証および検査で使用するための少なくとも１つのテストケースを生成するステップと
を備える、方法。
【請求項１６】
前記モデル型は、記号変数モデル型、実数モデル型、非線形演算モデル型、およびフィードバック・ループ・モデル型の少なくとも１つである、請求項１５に記載の方法。
【請求項１７】
前記モデルは、仕様モデル（１０４）および設計モデル（１０８）の一方である、請求項１５に記載の方法。
【請求項１８】
１つまたは複数のテスト基準（３０６）を、１つまたは複数のテスト目標（３１０）に変換するステップをさらに備える、請求項１５に記載の方法。
【請求項１９】
前記中間モデル（４００）における計算の型を判断するステップをさらに備える、請求項１５に記載の方法。
【請求項２０】
モデルチェックモジュール（３１６）、制約解決モジュール（３１８）、および可到達性解決モジュール（３２０）の１つを選択し、前記中間モデル（４００）に適用し、前記計算型に基づいてテストケースを生成するステップをさらに備える、請求項１９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、セーフティクリティカルソフトウェアのための統合された自動テストケース生成に関する。
【背景技術】
【０００２】
ソフトウェアコンポーネントを伴うシステムを開発することは、多くの場合、顧客により提供されたシステム要件を含むことがある。これらの要件は、ソフトウェアに組み込まれる可能性がある。ソフトウェアを設計した後、その要件を適切に満たしているかを確認するために検査および検証することができる。検査および検証処理は、ソフトウェアのコストの大部分を占める可能性がある。検査および検証処理のタイミングは、例えば、コア業績、顧客満足度、および事業者の評判に影響を与える可能性がある。
【０００３】
したがって、そのソフトウェアが要件に適合し、機能が要件ごとの目的を正確および適切にカバーしていることを検査および検証するためのより迅速な方法を提供する装置および方法を設計することが望ましいであろう。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】米国特許出願公開第２０１４／０１３０００６号明細書
【発明の概要】
【０００５】
いくつかの実施形態によれば、テストケースが、変換コンピュータモジュールおよび生成器コンピュータモジュールの適用によって生成され、ソフトウェア要件を検証および検査するために使用することができる。変換コンピュータモジュールは、１つまたは複数の仕様モデルおよび設計モデルに適用され、中間モデルを生成し、次いで、テストケースが、変換コンピュータモジュールの出力（例えば、中間モデル）への生成器コンピュータモジュールの実行を介して生成される。
【０００６】
本発明のいくつかの実施形態の技術的効果は、テストケースを生成するための技術およびシステムを改善することである。以下で明らかになるこの、ならびに他の利点および特徴と共に、本発明の本質は、以下の詳細な説明および添付図面を参照することにより、より完全に理解することができる。
【０００７】
他の実施形態は、本明細書で説明する方法のいずれかを実行するための命令を格納するシステムおよび／またはコンピュータ読込み可能媒体と関連づけられる。
【図面の簡単な説明】
【０００８】
【図１】いくつかの実施形態によるシステムの図である。
【図２】いくつかの実施形態によるフロー図である。
【図３】いくつかの実施形態によるシステムのブロック図である。
【図４】いくつかの実施形態によるモデルの図である。
【図５】いくつかの実施形態によるモデルの図である。
【図６Ａ】いくつかの実施形態によるモデルの図である。
【図６Ｂ】いくつかの実施形態によるモデルの図である。
【図７】いくつかの実施形態によるフロー図である。
【図８】いくつかの実施形態のよるパス解析結果の表である。
【図９】いくつかの実施形態によるユーザインターフェースの図である。
【図１０】いくつかの実施形態によるユーザインターフェースの図である。
【図１１】いくつかの実施形態によるテストケースの図である。
【図１２】いくつかの実施形態による自動テストケース生成処理ツールまたはプラットフォームのブロック図である。
【発明を実施するための形態】
【０００９】
ソフトウェアコンポーネントを伴うシステムを開発することは、多くの場合、顧客により提供されたシステム要件を含むことがある。これらの要件は、コンピュータ読込み可能形式で仕様モデルに組み込むか、または取り込むことができる。要件は、人間が読取り可能な形式で仕様モデルに取り込んでもよい。次いで、設計モデルを、仕様モデルに格納された要件から開発することができ、設計モデルは、ソフトウェア設計データ（例えば、所定のソフトウェアコンポーネントの内部データ構造、データフロー、および／または制御フロー）を表すことができる。その場合、ソースコードを、適切なコード生成器を使用して設計モデルから自動的に生成することができる。ソフトウェアを設計した後（例えば、設計モデル）、ソフトウェアがその要件を適切に満たしているかを確認するために検査および検証することができる。検査および検証処理は、ソフトウェアのコストの大部分を占める可能性がある。検査および検証処理のタイミングは、例えば、コア業績、顧客満足度、および事業者の評判に影響を与える可能性がある。
【００１０】
従来、例えば、セーフティクリティカルソフトウェア（例えば、航空ソフトウェア）の多くが、各条件が独立して判定に影響を与えることを必要とする、変更条件判定カバレッジ（Ｍｏｄｉｆｉｅｄ  Ｃｏｎｄｉｔｉｏｎ／Ｄｅｃｉｓｉｏｎ  Ｃｏｖｅｒａｇｅ、ＭＣ／ＤＣ）などの、厳密なテスト網羅度でテストされることを求められている。内部変数を特定の値にする入力シーケンスを識別するためのモデル／コードの手動検証は、特に、ソフトウェア（例えば、航空ソフトウェア）が巨大で、複雑度が高い場合、難しく、時間がかかる。従来のテストは、低い構造／モデルカバレッジ、サポートされていないブロック／機能、および長いテスト生成時間の少なくとも１つの影響を受ける。例えば、従来のテスト手法は、ソフトウェアの全ての仕様／設計モデルで１つのテスト生成方法を盲従的に適用する可能性がある。しかしながら、１つのテスト生成方法は、全ての仕様／設計モデルに適合しない可能性があり、長いテスト生成時間を要する可能性があり、または何らのテストケースも全く生成しない可能性がある。
【００１１】
従来の手法の１つにおいて、例えば、テストケース生成手法が、あるモデル要素について非到達可能性を示す可能性がある、および標準カバレッジ目標ならびに要件およびユーザ定義テスト目的ならびに要件を満たすテスト入力を生成する可能性がある一方で、本手法は、非サポートブロック（例えば、「積分器」ブロック）を有する可能性があり、設計特性（例えば、真の活性特性）の全てを表すことができない可能性があり、およびテストケース長の所定の上限を求める可能性がある。別の従来手法において、例えば、本手法は、乱数テストの組み合わせを使用することができ、したがって、非常に迅速にテストケースを生成することができる一方で、しかしながら、検索のランダム性のため、高カバレッジを達成することは難しい（例えば、モデルサイズおよび複雑度が、低い構造カバレッジに繋がる可能性がある）。この手法はまた、説明することなく発見的であるとしてもよく、生成する入力信号を長さに関して制限される可能性がある。
【００１２】
いくつかの実施形態は、仕様／設計モデルの型（例えば、記号変数、実数、非線形演算、およびフィードバックループなど）を識別し、次いで、そのモデルに最も適合する適切なテスト方法／モジュールを選択することによって、テスト生成処理を誘導し、その結果、テストが、より効果的および効率的に生成される。モデルの識別情報に基づいて最も適合するテストモジュール／方法を選択することの利点の１つは、時間のかかる試行およびエラー処理を含む必要が無くなる可能性があることであり、モデルの解析が一度だけの実行で済む可能性があり、それにより、時間の節約に繋がる可能性があることである。別の利点は、最も適合するテストモジュール／方法自体が、他のテストモジュール／方法と比べて、時間のかかるテスト生成作業（例えば、フィードバックループの検索）および抽象化（例えば、実数の近似）を避けることができ、それにより、時間の節約となり、より高いテストカバレッジを実現する。
【００１３】
本発明の実施形態の別の利点は、最も適合するモジュール／方法を完全に自動化することができることである。いくつかの実施形態において、数式は、中間モデルにおける計算パスを見つけることによって導出することができ、中間モデルは、以下でさらに説明するように、設計または仕様モデルから自動的に変換される。数式は、内部信号をそれらの出力割当と置換することによって組み合わせてもよい。次いで、数式の最終セットは、テスト目的信号の値を決定する出力割当関数と、モデルを発展する方法を決定するデータ更新関数（例えば、差分方程式）とを含んでもよい。これらの数式は、機械読取り可能とすることができ、モデル型は、数式パターンデータベースをルックアップすることにより数式パターンを認識することによって識別することができる。従来の手動モデル型識別は、専門知識を必要とし、モデルサイズが大きくなり、フィードバックループが引き起こされると、時間がかかっていた。本発明の実施形態における自動モデル型識別要素は、例えば、１つのボタンをクリックすることによって、モデル型を識別することができる。
【００１４】
いくつかの実施形態は、仕様モデルおよび設計モデルを入力としてとり、適切なモデルカバレッジ基準を満たすテスト記述、テストケース、およびテスト手順を自動的に出力することができる。いくつかの実施形態は、設計モデルおよびソースコード／実行可能オブジェクトコードに対して実行されるよう意図され得る入力および期待される出力値を含むテストケースおよび手順を含み、仕様モデルとの適合性をチェックすることができる。言い換えると、いくつかの実施形態において、テストケースは、仕様モデルから生成することができ、設計モデルで実行されて、設計モデルが、要件の正しい実装態様であるかどうかを検証する。いくつかの実施形態において、テストケースは、設計モデルから生成され、ソースコード／実行可能オブジェクトコードで実行され、ソースコードがデザインモデルに準拠していることを検証することができる。
【００１５】
いくつかの実施形態では、モデルの中間表現に基づいて、仕様／設計モデル型を自動的に識別することができる。１つまたは複数の実施形態では、中間モデルを自動的に削減ことができ、ここで、削減されたモデルを、モデル識別のための中間モデルにマッピングしてもよい。１つまたは複数の実施形態では、適切なテスト生成モジュールを自動的に選択し、モデル識別結果に基づいて、テストケースを生成することができる。１つまたは複数の実施形態において、適切なテスト生成モジュールを選択することにより、効率性および有効性を実現することができる。
【００１６】
図１は、いくつかの実施形態による、ソフトウェア開発システム１００の一例である。システム１００は、システム要件１０２、仕様モデル１０４、要件ベース自動テストケース生成モジュール１０６、設計モデル１０８、ソースコードモジュール１１２、実行可能オブジェクトコードモジュール１１４、および構造カバレッジ解析モジュール１２４を含むことができる。本明細書で使用される場合、「システム要件」、「ソフトウェア要件」、および「要件」は、交換可能に使用される。
【００１７】
いくつかの実施形態において、ソフトウェアに割り当てられるべきシステム要件１０２のテキスト版を取得する。これらの要件１０２から、仕様モデル１０４が開発される。１つまたは複数の実施形態において、仕様モデル１０４は、セマンティックモデリング技術とグラフィカルモデリング技術との組み合わせを使用して開発してもよい。他の適切な仕様モデル開発技術を使用してもよい。１つまたは複数の実施形態において、仕様モデル１０４は、顧客検証モジュール１１６を介して、顧客が検証することができる。いくつかの実施形態において、仕様モデル１０４は、正確性および一貫性について、自動定理証明を使用して、形式的要件解析モジュール１１８により正式に解析および検証することができる。解析および検証について他の適切な手段を使用してもよい。
【００１８】
仕様モデル１０４が顧客検証モジュール１１６および形式的要件解析モジュール１１８によって検証された後、仕様モデル１０４を、設計モデル１０８を生成するため、モデルベース設計チームへの入力として通すことができる。１つまたは複数の実施形態において、設計モデルは、仕様モデルから生成された要件ベーステストケースでシミュレートすることができ、その結果、設計モデルレベルでエラーを捕らえることができる。１つまたは複数の実施形態において、ソースコードモジュール１１２は、設計モデル１０８から自動生成することができる。
【００１９】
いくつかの実施形態において、仕様モデル１０４は、要件ベース自動テストケース生成モジュール１０６（テストケースモジュール）への入力として使用することができる。テストケースおよび手順は、テストケースモジュール１０６によって自動的に生成することができ、以下でさらに説明するように、次いで、設計モデル１０８に適用することができる。１つまたは複数の実施形態において、テストケースモジュール１１０を使用して、技術者を補助し、到達不能コードを識別し、モデルの特定のセクションを実行することができるテストベクタを識別することができる。１つまたは複数の実施形態において、テストケースモジュール１０７で生成されたテストケースは、設計モデル１０８に適用されて、構造カバレッジ解析モジュール１２４で構造カバレッジについて解析することができる。構造カバレッジ解析モジュール１２４は、意図しない機能、デッドコード、および派生要件などの、設計モデルで実行される要件ベーステストケースのテストカバレッジにおけるギャップを識別することができる。派生要件の場合において、例えば、テストケースは、構造カバレッジを満たすよう、モデルカバレッジテストケースモジュール１１０により自動的に生成することができる。
【００２０】
１つまたは複数の実施形態において、テストケースはまた、ソースコードモジュール１１２を介してソースコードで、および実行可能オブジェクトコードモジュール１１４を介して実行可能オブジェクトコードで実行してもよい。
【００２１】
図２から図６を参照すると、いくつかの実施形態による１つの例示的動作において、図２は、処理２００のフロー図である。処理２００および本明細書で説明する他の処理は、ハードウェア（例えば、回路）、ソフトウェア、または手動手段の任意の適切な組み合わせを使用して実行することができる。１つまたは複数の実施形態において、システム１００は、処理２００を実行するために調整され、システム１００は、汎用コンピュータまたはデバイスによって実行できない動作を実行するよう構成される専用要素である。これらの処理を実施するソフトウェアは、固定ディスク、フロッピー(登録商標）ディスク、ＣＤ、ＤＶＤ、フラッシュドライブ、または磁気テープを含む、任意の非一時的有形媒体によって格納することができる。これらの処理の例は、システム１００の要素に関して以下で説明するが、実施形態はそれらに限定されない。
【００２２】
最初に、Ｓ２１０で、モデルが、テストケースモジュール１０６で受信される。モデルは、仕様モデル１０４または設計モデル１０８の一方とすることができる。１つまたは複数の実施形態において、仕様モデル１０４および設計モデル１０８を準備することで、ユーザは、設計モデル１０８の評価のため、仕様モデル１０４から要件ベーステストケースを生成することができ、増補テストケースを生成し、モデルカバレッジを満たすことができる。１つまたは複数の実施形態において、仕様／設計モデル１０４／１０８は、Ｓｉｍｕｌｉｎｋ（商標）／Ｓｔａｔｅｆｌｏｗ（商標）、またはＳＣＡＤＥ（商標）で記述することができる。他の任意の適切なモデルベース開発言語を、仕様／設計モデル１０４／１０８の記述に使用してもよい。仕様／設計モデル１０４／１０８は、他の任意の適切な言語で記述してもよい。１つまたは複数の実施形態において、変数マップ（図示せず）が、仕様モデル１０４に加えて受信される。いくつかの実施形態において、変数マップは、仕様モデル１０４における変数名と、設計モデル１０８におけるそれらと等価な変数名とをリスト化することができる。変数マップは、例えば、要件技術者および設計者の少なくとも一方によって提供することができる。
【００２３】
次いで、Ｓ２１２において、中間モデル４００（図４）が生成される。１つまたは複数の実施形態において、自動変換手法が、変換コンピュータモジュール３０２「トランスレータ」（図３）を介して仕様／設計モデル１０４／１０８に適用され、仕様／設計モデル１０４／１０８を解析して、中間モデル４００に変換することができる。いくつかの実施形態において、中間モデル４００は、入力／出力拡張有限オートマトン（Ｉ／Ｏ−ＥＦＡ）と称されることもある。１つまたは複数の実施形態において、中間モデル４００は、サンプリング時間で観測される要件の入力と出力との間の挙動を保存することができる。１つまたは複数の実施形態において、変換は、仕様／設計モデル１０４／１０８の計算シーケンスから、変換された中間（Ｉ／Ｏ−ＥＦＡ）モデル４００における計算パスへのマッピングを形式化および自動化することができる。本明細書で使用される場合、計算パスは、連結された遷移のシーケンスである。図４に示すように、所与の位置に２つ以上の計算パスまたはサブパスがあってもよい。図４は、いくつかの計算パスを提供し、以下の例は、２つの異なるパス４０５ａおよび４０５ｂの一部（遷移）に焦点を当てる。どちらのパスも、第１の遷移４０１で開始される。パス４０５ａでは、遷移４０１から、パスは、太矢印で示される遷移４０２を通り、遷移４０３に続くことができる。別の例として、パス４０５ａが、４０１から、４０２、４０３へと続く代わりに、パス４０５ｂが、遷移４０１から、点線で示した遷移４０４を通り、遷移４０３に続くことができる。１つまたは複数の実施形態において、計算パスは、モデル挙動を説明することができる。本明細書で使用される場合、計算シーケンスは、１つの時間サイクル内で仕様／設計モデルによって実行される計算のシーケンスである。いくつかの実施形態において、中間モデルは、仕様／設計モデルにおける計算シーケンスを抽出および解析する。１つまたは複数の実施形態において、変換コンピュータモジュール３０２は、Ｍａｔｌａｂ（登録商標）における自動化変換ツールＳＳ２ＥＦＡとすることができる。本明細書で説明する例は、Ｓｉｍｕｌｉｎｋ（商標）からＩ／Ｏ−ＥＦＡへの変換手法を提示するが、自動化への他の変換（例えば、統一モデリング言語への変換）を使用してもよい。
【００２４】
１つまたは複数の実施形態において、仕様モデル１０４に対するテスト基準３０６および設計モデル１０８に対するモデルカバレッジ３０８におけるギャップは、論理表現５０２（図５）に変換され、次いで、コンバータモジュール３１２「コンバータ」（図３）によってテスト目標３１０に変換することができ、次いで、テスト目標３１０は、図５に示すように、Ｓ２１４において、中間モデル４００に添付される。例えば、コンバータモジュール３１２は、入力としてモデルカバレッジにおけるテスト基準／ギャップを受信し、この情報を論理表現に変換し、次いで、その論理表現を、中間モデルにマッピングされる機械的テスト目標または表現に変換する。１つまたは複数の実施形態において、テスト目標３１０は、生成器コンピュータモジュール３１４「生成器」がモデルを駆動する目的を設定することができる。１つまたは複数の実施形態において、各テスト目標３１０は、中間モデル４００におけるテスト目標パスと関連づけることができ、テスト目標５００を伴う中間モデルを図５に示す。以下でさらに説明するように、生成器コンピュータモジュール３１４は、テスト目標５００を伴う中間モデルを解析し、テスト目標５００を伴う変換された中間モデルに基づいて自動テスト生成手法を適用し、テスト目標（例えば、仕様モデルにおける全ての要件および設計モデルに対するミッシングカバレッジ）を実現または実行する、テストケース３０４とも呼ばれる入出力シーケンスのセットを見つける。１つまたは複数の実施形態において、テストケースモジュール１０６は、入力された仕様モデル１０４から要件ベーステストケース３０４を出力することができ、入力された設計モデル１０８からモデルカバレッジに対する増補テストケース３０４を出力することができる。１つまたは複数の実施形態において、テスト目標３１０は、中間モデル４００における最終状態として添付してもよい。１つまたは複数の実施形態において、最終状態としてのテスト目標３１０は、図５においてｌfとして示されるように、外に向かうエッジ／矢印を伴わない位置（ｌ）として表すことができる。
【００２５】
サブグラフ６００（図６Ａ）が、Ｓ２１６において決定される。１つまたは複数の実施形態において、サブグラフ６００は、目標に影響する可能性がある。図６Ａに示すように、サブグラフは、点線の長方形で示される。１つまたは複数の実施形態において、中間モデル４００は、目標に影響しない可能性のある要素を含むことができる。例えば、中間モデル４００は、いくつかの要件を扱う要素を含むことができ、１つの要件に影響する可能性のある要素は、別の要件に影響しない可能性がある。サブグラフ６００は、関連しない要素から関連する要素を分離し、１つまたは複数の実施形態において、テスト目標に影響する要素のみを識別することができる。
【００２６】
次いで、Ｓ２１８において、中間モデル４００が削減される（図６Ｂ）。いくつかの実施形態において、中間モデル４００のサイズを削減することができ、削減中間モデル（例えば、サブモデル）は、サブグラフ６００と関連づけられた中間モデルの部分のみを含む。１つまたは複数の実施形態において、中間モデルのサイズを削減することは、テストケースを生成するために生成器コンピュータモジュール３１４によって実行されるべき計算のシーケンスの複雑さを低減することができ、それにより、効率が高まる。１つまたは複数の実施形態において、モデルは自動的に削減され、削減モデルは、中間モデル４００にマッピングすることができる。
【００２７】
モデル型は、Ｓ２２０において識別される。１つまたは複数の実施形態において、生成器コンピュータモジュール３１４は、テスト目標５００を伴う削減中間モデルを受信し、削減中間モデルを解析し、図７に関して以下でさらに説明するように、削減中間モデルの解析に基づいて、モデル型を識別する。１つまたは複数の実施形態において、識別されたモデル型は、削減中間モデルにおける計算の型に基づくことができ、例えば、モデル型は、記号／ブール変数モデル型、実数制約モデル型、非線形演算モデル型、動的またはフィードバック・ループ・モデル型の１つとすることができる。他の適切なモデル型を使用してもよい。
【００２８】
モデル型が識別された後、テスト生成方法がＳ２２２において選択され、テストケースが、Ｓ２２４において、生成器コンピュータモジュール３１４の実行を介して、識別されたモデル型に基づいて、自動的に生成される。１つまたは複数の実施形態において、生成器コンピュータモジュール３１４は、例えば、識別されたモデル型ごとに中間モデルにおける計算の型に基づいて生成器コンピュータモジュール３１４によって選択された場合、モデルチェックモジュール３１６、制約解決モジュール３１８、または可到達性解決モジュール３２０の１つの適用を介して、識別されたモデル型を解析し、テストケースを生成することができる。テストケースは、他の適切なモデルの実行を介して、生成器コンピュータモジュール３１４によって生成してもよい。
【００２９】
１つまたは複数の実施形態において、モデルチェックモジュール３１６は、記号／ブール変数モデル型として識別された削減中間モデルに適用することができる。モデルチェックモジュール３１６は、削減中間モデル（Ｉ／Ｏ−ＥＦＡ）をモデルチェッカ言語（例えば、ＮｕＳＭＶ）にマッピングすることができる。モデルチェックモジュール３１６は、仕様モデル１０４における各要件の可到達性をチェックし、１つまたは複数の実施形態における反例からテストケースを生成することができる。
【００３０】
１つまたは複数の実施形態において、制約解決モジュール３１８は、実数制約または非線形演算モデル型として識別された削減中間モデルに適用することができる。制約解決モジュール３１８は、（例えば、各テスト目標へのパスに沿って）モデルにおける各要件の制約を集め、数学的最適化を適用し、いくつかの実施形態における要件（例えば、テスト目標）を満たす入出力シーケンスを取得する。
【００３１】
１つまたは複数の実施形態において、可到達性解決モジュール３２０は、動的またはフィードバック・ループ・モデル型として識別された削減中間モデルに適用することができる。可到達性解決モジュール３２０は、コンパクトモデルを使用して、動力学方程式を解析的に解き、ダイナミクスを伴うモデルに対するテスト生成の検索空間を削減することができる。１つまたは複数の実施形態において、コンパクトモデルの各位置は、中間モデルにおける計算パスとすることができる。可到達性解決モジュール３２０は、コンパクトモデルにおける遷移を使用して、ある計算パスから別の計算パスへのモデルのモード切り替えを示すことができる。
【００３２】
テストケース３０４がＳ２２４において生成された後、テストケース３０４は、Ｓ２２６において表示される。１つまたは複数の実施形態において、テストケースは、．ｓｓｓファイルフォーマットとすることができる。テストケースは、他の適切なファイルフォーマットとしてもよい。上記のように、テストケース３０４を使用して、設計モデルがソフトウェア要件を満たすこと、または実装態様（例えば、ソースコード／オブジェクトコード）が設計モデルと一致することを検証および検査することができる。
【００３３】
図７を参照すると、いくつかの実施形態による例示的動作の１つとして、図７は、図２に示した処理２００のＳ２２０ごとのモデル型を識別するための処理７００のフロー図である。
【００３４】
最初に、Ｓ７１０で、中間モデルは、Ｓ２１８ごとに削減される。次いで、Ｓ７１２で、計算パス４０２およびテスト目標パスが、削減中間モデルから抽出され、解析される。１つまたは複数の実施形態において、解析により、パスが有効（例えば、モデル挙動を表す）かどうかを判断することができる。１つまたは複数の実施形態において、有効な計算パスは、モデル挙動を表すことができ、テスト目標パスは、テスト目標を表すことができる。パスの抽出および解析は、各パスに対するパス制約およびデータについての決定をもたらすことができる。本明細書で使用される場合、パス制約は、計算パスに対する入口条件とすることができ、パスデータは、パスが入力された後、パスに沿って実行されるデータとすることができる。１つまたは複数の実施形態において、モデル型の識別はパス制約およびデータの識別に基づく。抽出された制約およびデータは、Ｓ７１４において識別することができる。例えば、図８は、１０６によって生成された表８００を示し、図４で示した中間モデル４００に対するパス抽出／解析／識別を示す。１つまたは複数の実施形態において、表８００は、各パス８０２に対して、パス述語（パス入口条件）８０４、パスデータ（パスデータ更新）８０６、およびパス出力（期待出力値）８０８をリスト化することができる。Ｓ７１６では、モデルチェックモジュール３１６、制約解決モジュール３１８、または可到達性解決モジュール３２０のいずれもサポートできないパス制約およびデータにおける非サポート演算が存在するかどうかを判断する。Ｓ７１６において非サポート演算が存在する場合、処理７００は、Ｓ７１８に進み、処理は終了して、エラーメッセージが生成される。Ｓ７１６において非サポート演算が存在しない場合、処理７００はＳ７２０に進み、パス制約およびデータにおいて非線形演算または実数が存在するかどうかを判断する。Ｓ７２０において非線形演算または実数が存在しない場合、処理７００はＳ７２２に進み、モデルチェックモジュール３１６が、削減中間モデルに適用される。次いで、Ｓ７３０において、Ｓ２２２に対して上記したように、テストケース３０４が生成される。Ｓ７２０において非線形演算または実数が存在する場合、処理７００はＳ７２４に進み、パスデータ内に差分方程式が存在するかどうかを判断する。Ｓ７２４において、パスデータ内で全ての、または一部の差分方程式がサポートされないと判断された場合、処理７００はＳ７２６に進み、制約解決モジュール３１８が、削減中間モデルに適用される。次いで、Ｓ７３０において、Ｓ２２２に対して上記したように、テストケース３０４が生成される。Ｓ７２４において、非サポート差分方程式がパスデータに存在しないと判断された場合、処理７００はＳ７２８に進み、可到達性解決モジュール３２０が、中間モデルに適用される。次いで、Ｓ７３０において、Ｓ２２２に対して上記したように、テストケース３０４が生成される。１つまたは複数の実施形態において、いくつかの非線形方程式は、制約解決モジュール３１８で使用される最適化モジュール（図示せず）の機能に応じてサポートされない可能性がある。これらの非線形方程式を伴うモデルは、エラーメッセージと共に終了する可能性がある（Ｓ７１８）。
【００３５】
図９から図１１を参照すると、テストケースを生成するための例示的なユーザインターフェース９００が提供される。１つまたは複数の実施形態において、例えば、ユーザが、「モデル選択」ボタン９０２を選択することを介してテストケースを生成するためのモデル（Ｓ２１０）を、および仕様モデルのための「変数マップ選択」ボタン（図示せず）を適用することを介して変数マップを選択した後、ユーザは、生成するためのテストの型を選択することができる。１つまたは複数の実施形態において、テスト型ウィンドウ９０４は、仕様モデルが使用されるのに適切なテストを読み込むことができる。例えば、仕様モデルに対して、テストは、要求カバレッジテスト、論理条件テスト、または他の任意の適切なテストとすることができ、一方、設計モデルに対して、テストは、ＭＣ／ＤＣテスト、決定カバレッジテスト、または他の任意の適切なテストとすることができる。１つまたは複数の実施形態において、要件カバレッジテストは、全ての要件をカバーするためのテストケースを生成することができ、一方、論理条件テストは、全ての要件と、各要件内の論理条件をカバーするためのテストケースを生成することができる。その場合、ユーザは、「テスト生成」ボタン９０６を選択して、上記した処理２００を開始し、選択されたテスト型に基づいて、要件ベーステストケースを生成することができる。図１０は、結果ウィンドウ１０００において４つのテストが生成されたことを示す。特に、仕様モデルにおける４つの要件に対して生成された、４つの要件ベーステストケースが存在する。各テスト・ケース・ファイル１００２は、要件ＩＤ番号を選択すること、および「選択ファイルを開く」ボタン１００４を選択することによって、検証するために開くことができる。１つまたは複数の実施形態において、実行状態ウィンドウ１００６は、要件ベース自動テストケース生成モジュール１０６の状態を提供する。例えば、実行状態ウィンドウ１００６は、テストが特定の位置で生成されていることを示すメッセージを表示することができ、次いで、そのテスト生成を完了する。図１１は、要件Ｒ１に対して生成されたテストケース１１００を示す。生成されたテストケース１１００は、１つまたは複数の実施形態において、関連要件１１０２の記述、（名前、値、およびデータ型を含むことができる）モニタされた（入力）変数１１０４のセット、（名前、値、およびデータ型を含むことができる）制御された（出力）変数に対する期待出力１１０６のセットを含むことができる。要件ベーステストケースが生成されると、それらは、設計モデルでテストすることができる。１つまたは複数の実施形態において、テストケースおよび手順は、入力および期待出力値からなり、設計モデル１０８およびソースコード／実行可能オブジェクトコードに対して実行され、仕様モデル１０４とのそれらの適合性をチェックすることができる。１つまたは複数の実施形態において、テストケースは、設計モデルに適用することができ、その適用から生成された出力は、設計モデルの正確な機能および構造カバレッジを判断するために解析することができる。
【００３６】
本明細書で説明する実施形態は、任意の数の異なるハードウェア構成を使用して実現することができることに留意されたい。例えば、図１２は、例えば、図１のシステム１００と関連づけることができる自動テストケース生成処理プラットフォーム１２００を示す。自動テストケース処理プラットフォーム１２００は、通信ネットワーク（図１２では図示せず）を介して通信するよう構成される通信デバイス１２２０に結合される、１チップマイクロプロセッサの形式の１つまたは複数の市販の中央処理装置（ＣＰＵ）などの、テストケース生成プラットフォームプロセッサ１２１０（プロセッサ）を備える。通信デバイス１２２０を使用して、例えば、１人または複数人のユーザと通信することができる。自動テストケース生成プラットフォーム１２００は、入力デバイス１２４０（例えば、変数、クラスタリング、および最適化についての情報を入力するためのマウスおよび／またはキーボード）と、（例えば、選択されたサンプルを出力および表示する）出力デバイス１２５０とをさらに含む。
【００３７】
プロセッサ１２１０はまた、メモリ／ストレージデバイス１２３０と通信する。ストレージデバイス１２３０は、磁気ストレージデバイス（例えば、ハードディスクドライブ）、光学ストレージデバイス、携帯電話、および／または半導体メモリデバイスの組み合わせを含む、任意の適切な情報ストレージデバイスを備えることができる。ストレージデバイス１２３０は、プロセッサ１２１０を制御するための、プログラム１２１２および／または自動テストケース生成処理ロジック１２１４を格納することができる。プロセッサ１２１０は、プログラム１２１２、１２１４の命令を実行し、それにより、本明細書で説明する実施形態のいずれかに従って動作する。例えば、プロセッサ１２１０は、仕様モデルおよび／または設計モデルを受信することができ、次いで、変換コンピュータモジュール３０２を、次いで、テストケース３０４を生成するために、プログラム１２１２、１２１４の命令を介して、生成器コンピュータモジュール３１４を、適用することができる。
【００３８】
プログラム１２１２、１２１４は、圧縮フォーマット、未コンパイルフォーマット、および／または暗号化フォーマットで格納することができる。プログラム１２１２、１２１４は、さらに、オペレーティングシステム、データベース管理システム、および／または周辺機器とインターフェースするためにプロセッサ１２１０によって使用されるデバイスドライバなどの、他のプログラム要素を含むことができる。
【００３９】
本明細書で使用される場合、情報は、例えば、（ｉ）別のデバイスからプラットフォーム１２００によって「受信される」か、もしくは別のデバイスからプラットフォーム１２００に「送信する」ことができ、または（ｉｉ）別のソフトウェアアプリケーション、モジュール、もしくはソースからプラットフォーム１２００内のソフトウェアアプリケーションもしくはモジュールによって「受信される」か、もしくは別のソフトウェアアプリケーション、モジュール、もしくはソースからプラットフォーム１２００内のソフトウェアアプリケーションもしくはモジュールに「送信する」ことができる。
【００４０】
当業者によって理解されるように、本発明の態様は、システム、方法、またはコンピュータプログラム製品として実現することができる。したがって、本発明の態様は、完全なハードウェアの実施形態、（ファームウェア、常駐ソフトウェア、またはマイクロコードなどの）完全なソフトウェアの実施形態、または本明細書で「回路」「モジュール」もしくは「システム」として一般に呼ばれる可能性のあるソフトウェア態様とハードウェア態様を組み合わせた実施形態の形式をとってもよい。さらに、本発明の態様は、そこで実施されるコンピュータ読込み可能プログラムコードを有する１つまたは複数のコンピュータ読込み可能媒体で実施されるコンピュータプログラム製品の形式をとってもよい。
【００４１】
図内のフローチャートおよびブロック図は、本発明のさまざまな実施形態による、システム、方法、およびコンピュータプログラム製品の可能な実装態様のアーキテクチャ、機能、および動作を示す。この点に関して、フローチャートまたはブロック図における各ブロックは、特定の論理機能を実施する１つまたは複数の実行可能命令を備える、モジュール、セグメント、またはコードの一部を表すことができる。いくつかの代替実装態様において、ブロック内に記載された機能は、図に記載された順序で行われない可能性があることにも留意すべきである。例えば、連続する２つのブロックは、実際は、実質的に同時に実行してもよく、または複数のブロックを、含まれる機能によって、逆順に実行してもよい。ブロック図ならびに／もしくはフローチャートの各ブロック、およびブロック図ならびに／もしくはフローチャートのブロックの組み合わせは、特定の機能または動作を実行する特定用途ハードウェアベースシステム、または特定用途ハードウェアならびにコンピュータ命令の組み合わせにより実施することができることもまた留意されよう。
【００４２】
本明細書で説明した方法のいずれも、コンピュータ読込み可能ストレージ媒体で実施される別個のソフトウェアモジュールを備えるシステムを提供する追加ステップを含むことができ、モジュールは、例えば、ブロック図で示した、ならびに／もしくは本明細書で説明した要素の一部もしくは全てを含むことができ、そのようなモジュールには、限定するものではないが、変換コンピュータモジュールおよび生成器コンピュータモジュールなどがあることに留意されたい。その場合、方法ステップは、上記したように、１つまたは複数のハードウェアプロセッサ１２１０（図１２）で実行するシステムの別個のソフトウェアモジュールおよび／またはサブモジュールを使用して実行することができる。さらに、コンピュータプログラム製品は、別個のソフトウェアモジュールを伴うシステムの準備を含む、本明細書で説明した１つまたは複数の方法ステップを実行するために実現されるよう適合されるコードを伴うコンピュータ読込み可能ストレージ媒体を含むことができる。
【００４３】
本明細書は好適な実施形態を含む、本発明を開示するため、および、あらゆるデバイスまたはシステムを製作し、ならびに使用し、およびあらゆる組込方法を実行することを含む任意の当業者が本発明を実施することを可能にするための例を用いる。本発明の特許可能な範囲は、特許請求の範囲によって定義され、当業者が想到するその他の実施例を含むことができる。このような他の実施例は、特許請求の範囲の文言との差がない構造要素を有する場合、または特許請求の範囲の文言との実質的な差がない等価の構造要素を含む場合、特許請求の範囲内にある。説明したさまざまな実施形態からの態様、および各そのような態様に対する他の既知の等価物は、当業者によって混合され、適合されて、本出願の原理による追加の実施形態および技術を構築することができる。
【００４４】
当業者は、上記した実施形態のさまざまな適合および変形例は、特許請求の範囲の範囲および精神から逸脱することなく構成することができることを理解するであろう。したがって、特許請求の範囲は、本明細書で特に説明した場合以外も実施されることができることを理解されよう。
【符号の説明】
【００４５】
１００  ソフトウェア開発システム
１０２  システム要件
１０４  仕様モデル
１０６  要件ベース自動テストケース生成モジュール、テストケースモジュール
１０７  テストケースモジュール
１０８  設計モデル
１１０  テストケースモジュール
１１２  ソースコードモジュール
１１４  実行可能オブジェクトコードモジュール
１１６  顧客検証モジュール
１１８  形式的要件解析モジュール
１２４  構造カバレッジ解析モジュール
２００  処理
３０２  変換コンピュータモジュール
３０４  テストケース
３０６  テスト基準
３０８  モデルカバレッジ
３１０  テスト目標
３１２  コンバータモジュール
３１４  生成器コンピュータモジュール
３１６  モデルチェックモジュール
３１８  制約解決モジュール
３２０  可到達性解決モジュール
４００  中間モデル
４０１  第１の遷移
４０２  計算パス、遷移
４０３  遷移
４０４  遷移
４０５ａ  パス
４０５ｂ  パス
５００  テスト目標
５０２  論理表現
６００  サブグラフ
７００  処理
８０２  パス
９００  ユーザインターフェース
９０２  「モデル選択」ボタン
９０４  テスト型ウィンドウ
９０６  「テスト生成」ボタン
１０００  結果ウィンドウ
１００２  テスト・ケース・ファイル
１００４  「選択ファイルを開く」ボタン
１００６  実行状態ウィンドウ
１１００  テストケース
１１０２  関連要件
１１０４  （入力）変数
１１０６  期待出力
１２００  自動テストケース生成処理プラットフォーム
１２１０  テストケース生成プラットフォームプロセッサ、ハードウェアプロセッサ
１２１２  プログラム
１２１４  自動テストケース生成処理ロジック
１２２０  通信デバイス
１２３０  メモリ／ストレージデバイス
１２４０  入力デバイス
１２５０  出力デバイス
【図１】
0006607565.tif 000002
【図２】
0006607565.tif 000003
【図３】
0006607565.tif 000004
【図４】
0006607565.tif 000005
【図５】
0006607565.tif 000006
【図６Ａ】
0006607565.tif 000007
【図６Ｂ】
0006607565.tif 000008
【図７】
0006607565.tif 000009
【図８】
0006607565.tif 000010
【図９】
0006607565.tif 000011
【図１０】
0006607565.tif 000012
【図１１】
0006607565.tif 000013
【図１２】
0006607565.tif 000014