Requirements-based Test パッケージ

BTC EmbeddedPlatformのRequirements-based Testパッケージは、Simulinkモデルのテストを効率的かつ確実に実施するために必要な機能セットを提供します。

Requirements-based Test パッケージ

 BTC EmbeddedPlatformのRequirements-based Testパッケージは、要求に基づいたソフトウェア及びシステムのテストをサポートするための製品です。テストケース(時系列の入力値と出力に対する期待値のセット)を記述するための洗練されたエディタ、MILシミュレーションによるテスト実行と自動判定、及びモデルカバレッジの測定機能を備えています。ユーザ様には、モデルベース開発以前から広く使われてきたRequirements-basedテストを、モデルベース開発においてより効率的で確実に行うことができるツールであるとご評価いただいております。

Requirements-based Testパッケージ

サポートするユースケース

*1 Requirements-based Testパッケージで取り扱うことのできるテスト対象はSimulinkモデルのみです。各種コードに対するRequirements-basedテストをご希望の場合は、Formal Test BASEパッケージ、Formal Testパッケージ、もしくはBack-to-back Testパッケージをご利用ください。

*2 Requirements-based TestパッケージではAPIはサポートされません。APIによる各種自動化をご希望の場合は、Formal Test BASEパッケージ、Formal Testパッケージ、もしくはBack-to-back Testパッケージをご利用ください。

追加可能なアドオン

無し

 

Requirements-basedテスト

モデルベース開発では、開発プロセスの様々な統合レベル(ソフトウェアユニットレベル、ソフトウェアインテグレーションレベル、システムレベル)で要求に基づいた検証が行われます。この要求に基づいた検証を目的として、テストケースに基づいたシミュレーションと判定の実施を行う技法がRequirements-basedテストです。

Requirements-basedテストでは、まず各要求に基づいてテストケースを記述します。テストケースは時系列の入力値と出力に対する期待値のセットで構成されます。このテストケースの入力値を用いてモデルのシミュレーションを実行し、得られた出力値が期待値と一致していればPassed(テスト合格)、一致していなければFailed(テスト不合格)がレポートされます。

 

Requirements-basedテストのテスト対象

機能モデル (Simulinkモデル/TargetLinkモデル)

ソフトウェア機能モデルのモデリング及びシミュレーションにはMathworks社のSimulinkが広く活用されています。機能モデルは、Simulinkの標準のブロックセットまたはこれに追加されたdSPACE TargetLinkのブロックセットで構成されます。

実装モデル (Simulinkモデル/TargetLinkモデル)

機能モデルに対し、実装用のデータタイプやスケーリング、クラスやストレージといった情報が追加され、必要に応じて一部のブロックを実装用に差し替えたものが実装モデルです。実装モデルは一般的に自動コード生成機能を持つツールを用いて作成されます。自動コード生成用のツールとして代表的な製品はdSPACE社のTargetLink、Mathworks社のEmbedded Coderです。

実装モデルのテスト・検証には、機能モデルのときと同じくModel-in-the-loop(MIL)シミュレーションと呼ばれるSimulinkのモデルシミュレーション機能が用いられます。

なお、Requirements-based Testパッケージでは、TargetLinkのブロックセット、もしくはEmbedded Coderのブロック設定が用いられていたとしても、そこから生成されるコードはテストの対象には加えられません。BTC EmbeddedPlatformを用いたモデルベース開発においては、コードの検証にはBack-to-backテストを用いることを推奨しております。各種コードに対するRequirements-basedテストをご希望の場合は、Formal Test BASEパッケージ、Formal Testパッケージ、もしくはBack-to-back Testパッケージをご利用ください。

 

洗練されたテストケースエディタ

BTC EmbeddedPlatformには、Test Composer(テスト コンポーザー)と名付けられたテストケースエディタが搭載されています。このエディタはモデルのテスト用に最適化されており、多種多様な特徴のテストケースの編集が容易に行えます。記述されたテストケースは、BTC EmbeddedPlatform独自のファイルフォーマットの他に、Excel(.xlsx)形式またはCSV形式でのエクスポート/インポートにも対応しているため、データベースや他のツールとの連携も容易に行えます。

 

Test Composerにおける入力値及び期待値は数値で直接与えることも可能ですし、もしくは波形エディタ、数式エディタにも対応しています。波形や数式は、エディタ上で任意のセルに対して設定可能で、テストケースに埋め込むことができます。

波形エディタによる編集ではRampなどの数式を選択して、いくつかのパラメータを埋めるだけで、ツールが各ステップの値を計算します。

 

数式による編集では、他のインタフェースの値を参照しながら計算式で入力値及び期待値を設定することができます。

 

任意のサブシステムに対する分割テスト

テストを行う際に、いつでもモデル全体のテストを行いたいとは限りません。一部の子サブシステムだけが切り取ってテストされることもあります。しかしこのサブシステムの切り取り作業、及びテストフレームの作成作業を適切に行わなければ、テストの妥当性は確保されません。またこれらの作業は手作業で行うには非常に煩雑です。BTC EmbeddedPlatformでは、これらの作業はツールが自動で行います。ユーザはGUI上で任意の子サブシステムを選択するだけでそのサブシステムに対するテストが行えます。

 

Requirements-basedテストとカバレッジ

Requirements-basedテストによってモデルに対する十分なテストが行われたか(検証の完全性は十分か、テスト目的を適切に達成したか)は、モデルカバレッジを通して評価されます。

BTC EmbeddedPlatformでは、最も代表的な構造カバレッジとして知られるModified Condition/Decision カバレッジ(MC/DC)の他に、Executionカバレッジ、Branch(Decision)カバレッジ、Conditionカバレッジ、Stateflow Chartに対するStateカバレッジ、Transitionカバレッジに対応しています。これらのカバレッジはMILシミュレーション中に自動測定されます。*1

 

モデルカバレッジの測定の際には、子サブシステムに対するテストのカバレッジと、親サブシステムに対するテストのカバレッジが自動的に積算されます。モデルに対するテスト全体でのカバレッジを容易に知ることができます。

*1 モデルカバレッジの測定には、Mathworks - Simulink Coverageが必要です。

 

充実したデバッグ機能

Requirements-basedテストで期待する振る舞いが得られなかった場合は、BTC EmbeddedPlatformが不具合解析環境を生成します。 Simulinkで実行可能な不具合再現モデルの生成、さらには不具合を子サブシステムで再現する分割デバッグ環境の生成により、不具合箇所の特定作業を効率的に行えます。

 

テスト結果の蓄積とレポート

 テスト結果は全て蓄積されhtmlレポートとして出力されます。モデルをサブシステム毎に分割して行ったテスト結果のみならず、それらを集計したモデル毎の統計もレポートに含まれます。レポートには、各要求に対していくつテストケースが実行されたか、実行したうちの何%が合格したか、などのテスト結果の報告に必要な各種情報が記録されています。

 

テストケースの再利用

Requirements-basedテスト用に作成したテストケースはそのまフォーマルテストとBack-to-backテストに再利用されます。ユースケースに応じたパッケージのライセンスに切り替えるだけで再利用は自動的に行われるため、特別な操作は必要としません。様々な意図を反映して手動で作成されたテストケースを異なる用途で再利用することにより、より効率的で一貫性のあるテストプロセス構築を容易にしています。

 

各種機能安全規格準拠

BTC EmbeddedPlatformのRequirements-basedテストは、各種機能安全規格の最新版に準拠し、 ドイツTÜV Süd社による認証を受けています。

 

 

フォーマルテスト、モデルチェックによる形式検証よりもRequirements-basedテストの方が良い?

Requirements-basedテスト、モデルチェックによる形式検証、フォーマルテストは要求に基づいたテスト・検証を行うという観点では同じですが、いずれにも長所短所があるため、一概にどれが良いとは言えません。どれかを選択するよりも、用途に合わせて使い分けることの方が重要です。一つの開発プロセス上でも適切に組み合わせて利用することによって効率的かつ効果的なテストプロセスを構築することが可能になります。比較と使い分けの詳細はこちらをご覧ください。