HOME | products | T-VEC | ModelBasedTestingTraceability

モデルベースドテスト 要件トレーサビリティを支援

Model-Based Testing Traceability

モデルベースドテストツールにより、要件やデザインモデルを検査(形式手法)して、要件ベースのテストを自動生成することで、テストの自動実行・解析に至る開発フルライフサイクルを支援する要件トレーサビリティについて紹介。

Mark R. Blackburn, Robert D. Busser, Aaron M. Nauman, Travis R. Morgan T-VEC Technologies, Herndon, VA

 

この資料では、大規模で高安全・信頼性が求められるシステム開発における、モデルベースドテストツールへの要件について紹介する。そして要件管理ツール、要件とテストのトレーサビリティ、要件・デザインモデリング、モデルベースのテスト生成、テストの自動実行・解析、カバレッジ解析に至るフルライフサイクルを支援できるツールの重要性を説く。一つは要件からテストのトレーサビリティツールの利点について紹介する。迅速にテストフェイルを解析できること、要件に対するテストの十分性をより良く判断できること、プロジェクトの進捗測定と管理に活用できることなど。二つ目に要件とモデルの欠陥のトレーサビリティについて紹介する。
 

キーワード:モデルベースドテスト、テスト自動生成、要件モデル・設計モデル、モデル検査、要件トレーサビリティ、形式手法、定理証明

 

 

1 INTRODUCTION

 
タイトなスケジュールと予算制約の下、製品のアプリケーションをリリースすることを命題にする実開発者や管理者と比較して、研究部門は新しいツールや手法の導入のギャップや課題に寛容である。ここ数年、様々なアプリケーションドメインの異なった組織と共に作業する機会を得た我々は、モデルベースドテストの採用とそのプロセスへの移管に関わることができた。そこにはツールの効率的な導入プロセスに対する、組織や開発者としての様々な要求があった。
モデルベースドテスト環境の完成度は多くの組織にとって決定的な要素。モデルベースドテストツールでアプリケーションのサブセットはテスト可能であったとしても、パイロットなどの評価段階で相対的に完全なアプローチでないと採用はためらわれる。モデリング言語や技術はテスト対象アプリケーションと相関すること、また様々なプログラミング言語、環境での自動テスト実行がサポートされることが必要。ターゲットアプリケーションの振る舞いを定義するモデリング言語の完成度に加え、モデルを容易に表記して活用できることも欠かせない。学習曲線は短く、一般に3カ月以内で、かつ3日程度でその有効性をデモンストレーションできなければ検討されることは無いであろう。
 
モデルベースドテストを採用した多くの組織では成熟したプロセスと何らかの要件管理プロセス、あるいは顧客や社内外の利害関係者からの要件を管理するツールを使用している。一般に要求はインターフェイスコントロールドキュメント、機能要件など複数の仕様・ドキュメントとして供給される。
 
要件管理ツールとモデルベースドテストツールの統合は、要件とモデルのリンク(紐付け)に有効であり、テスト自動生成機能が備わることで、要件からテストのトレーサビリティが最適化され、モデリングプロセス、プロジェクト管理のメトリクスの解析、欠陥と障害の解析や、要件が十分満たされていることの評価が支援される。
 

1.1 Requirements

 
以下、ビジネス•クリティカルなソフトウェア集約的なアプリケーションを開発する組織にとっての、モデルベースドテスト環境とプロセスに求められる様々な要件
 
 1. 包括的なテストの自動生成とあらゆるプログラミング言語、ターゲット環境下での実行をサポートできること
 
 2. 使いやすく表現豊かなモデリング言語、そして大規模・複雑なアプリケーションを複数のチームメンバーで開発できること
 
 3. 開発ライフサイクル全般に統合することができて、構成管理を介して要件からテストへのトレーサビリティをサポートできること
 
 4. 納期通りの製品出荷に欠かせない、プロジェクト管理と進捗解析をサポートできること
 
 5. 短期間に投資対効果が認められること
 

1.2 Organization of Paper

 
この資料では、モデルベースドテストツール活用に密接に関わる要求事項、要件からテストに至るバイディレクショナルな(双方向の)トレーサビリティをサポートする基本的な側面、そして組織に採用されるために求められる主要な利点について述べる。
 
小さな例を用いて、ツールの統合を介して実現されるフルライフサイクルサポートを紹介する。そしてモデル検査(形式手法による定理証明)と、それによって達成される、要件とモデルのトレーサビリティの利点についても資料の最後に述べる。
 

2 モデルベースドテストの背景

 
テスト入力と期待値の自動生成は、モデルベースドテストを実現可能にする技術であり、その最も初期の、そして最も重要なアプローチの1つがDNFメソッドである。仕様はDNF(Disjunctive Normal Form =加法標準形)に変換されて、各入力ドメインのパーティションは論理和集合の事前条件から形成される。論理和は論理的にANDされたブール値条件の集合である。テストケースはパーティションの各サブドメインから引き出される。[1]
 
図1にあるようなモデルベースドテストツールを開発した。これはデシジョンテーブルやステートマシン、制御システム、コードなどの表現をベースにした、要件、デザイン、アプリケーションプロパティ(安全性など)のモデルを、階層的DNFの形式に変換する。[2] 
 
モデリング言語は、複数の開発担当者により開発される大規模・複雑なアプリケーションに対応すべく、関数処理など共有可能なモデルリファレンス(参照)ができる。そして豊富な演算子をサポートすることで(trigonometric, intrinsic, integrators, quantization, matrixなど)、多様なアプリケーションドメインの機能、振る舞いの定義に使用する標準的な算術演算子を拡張する。そしてテストベクタ生成(入力と期待値)とテストドライバー生成機能によって、あらゆるプログラミング言語と実行環境のテスト実行と結果解析の自動化を支援できる。
 

図 1.モデルベースでテストを生成して実行する流れ


 

3 ライフサイクルサポート

 
テスト自動化フレームワーク(Test Automation Framework (TAF) )として、要件管理やモデリングツール、テスト生成ツールを統合した。要件管理ツールのDOORS® 、要件モデリングに活用されたSoftware Cost Reduction (SCR) method [3]を拡張させたT-VEC Tabular Modeler (TTM)など。デザインモデルのSimulink®も統合し、要件モデルとデザインモデル、それらをベースに生成されるテストまでの完全な要件トレーサビリティが提供される。(図2)
 

図 2.TAF テスト自動化フレームワークに統合された各種ツール環境


 

3.1 例題の要件

 
以下 vertical tracker は、Traffic and Collision Avoidance System(航空機の衝突回避システム)を簡素化した例。vertical tracker は他の航空機との高度差を探知し、その状態を維持管理することが求められる。図3はvertical trackerの要求仕様のイメージ(DOORSに記載された)で、各要件記述はDOORS ID (ID)を有する。要件トレーサビリティについて説明するために使用する、高度差探知の要件とそれらID は以下の通り。
 
 1. vt_3: 他の航空機が上下2700フィート内にいる場合、追跡高度範囲内にある(“in the altitude window”)とする
 
 2. vt_6: 当該航空機の高度が10000フィート以上で他の航空機が追跡高度範囲にない場合、高度差探知は追跡モード(TRACKING state)にある
 
 3. vt_7:  航空機の高度が10000フィート以上で他の航空機が追跡高度範囲にいる場合、高度差探知は注意状態(ADVISORY state)にある 
 
 4. vt_8: 航空機の高度が10000フィート以下の場合、高度差探知は追跡しない(NOT_TRACKING state)にある
 

3.2 要件からテストへのトレーサビリティ

 
この章ではDOORSの要件をTTMの要件モデルにリンク(紐付け)させるプロセスを、例を持いて紹介する。要件からテストへのトレーサビリティをサポートするツールは様々な形式で提供される要件を、モデルを介してリンクする。モデル変換、テストベクタ生成、テストドライバー生成によって、要件からテストベクタ、テストドライバー、そしてテストレポートへのリンクを提供する。図3は、このプロセスの基本的な3ステップ:
 
 1. DOORS の一つのモジュールをTTMにインポートする。DOORS のモジュールがアップデートされる場合に追加や削除することや、TTM側の変更をDOORS にシンクロナイズさせることができる。DOORS IDとTTM の requirement ID は一対一対応。
 
 2. インポートされる要件は、DOORS上の階層構造を維持する。一つ以上のDOORSの要件がTTMモデルの一要素(condition 列やassignment 列)にリンクする(図3)。あるいは図4のように、より上位のモデルの、condition、event、modeなどの各テーブルにリンクする。
 
 3. モデル変換後も要件IDとのリンクを維持するので、テストベクタ生成時にも要件へのリンクはテストベクタのアトリビュートとなる。そして生成されるテストドライバーの出力として要件IDはコードなどで実行されるテストケースへのトレーサビリティの詳細情報となる。
 
TTM 自身、DOORS モジュール同様に要件管理機能を有す。インポートされるDOORS モジュールはTTM にリードオンリーなモジュールとしてリンクされる。要件への変更はDOORS 内で実施されるべきで、その後TTMに同期される。また追加の要件をTTM内に直接作成することもできる。DOORS 内に存在しない場合、あるいはDOORS のような要件管理システム内に要件のソースが無い場合。要件とモデルのリンクのプロセスも同様。
 

図 3.要件、モデル、テストベクタのリンク


図 4.要件とテーブルとのリンク


 

3.3 デザインモデルのトレーサビリティ

 
この章では要件をSimulinkデザインモデルにリンクして、要件からテストベクタへトレースする仕組みを紹介する。図5は3.1 で紹介した vertical tracker の要件から実装されたSimulink モデル図の例。Simulink へのリンクはブロックごと(relational operator, absolute value, switch など)で行われるが、特定が困難な場合もある。要件がブロック内の分岐に応じて変わる場合など。
 
例えば“Advisory or Track”のラベルを持つ switch ブロックは、DOORS ID vt_6 と vt_7 の2つの要件に関わっている。入力2が真なら入力1を通過させ、偽の場合は入力3を通過させる、このswitchブロックのプロパティ設定にあるタグ設定領域には、両方の要件(DOORS)が参照される。 switchブロックの出力は、Advisory あるいは Track のいずれかであるので。
 
図2にある Simulink Tester によってSimulinkモデルが変換される過程で、これらタグ情報は変換後のモデルのアトリビュートとして組込まれる。このモデルからのテストベクタ生成時に要件IDは相当するテストベクタに連携される。結果のテストベクタ(図5)には、要件IDや該当Simulinkブロックの情報が含まれている。
 

図 5.Simulink モデル内への要件のリンク


 
テストドライバーは MATLAB の Simulink モデルシミュレータ用や、MATLAB Real-time workshopを介して自動生成されるコード用に生成できる。そしてこれらの実行結果として図6のような結果を得ることができる。モデルから自動生成されたテストベクタ内の期待値に一致しない実行結果が得られれば、該当するモデルブロック、要件へとタグ情報を基にして辿ることで解析を進めることができる。
 

図 6.テスト結果レポート


 

4 モデルのトレーサビリティ

 
要件は様々な形式で提供され、要件の変更通知はシステムへ追加される新機能などのドキュメントがインクリメンタルにリリースされる。モデリング時には要件を満たすべく様々な機能が異なるサブシステムに依存関係を持って実装され、そして別のサブシステムに実装される機能が矛盾となってモデルの欠陥になる。モデルのトレーサビリティが確保されていればモデル内の欠陥の検出に役立てられる。一連のモデルで構成される大規模なモデルでこの課題は顕著になる。
 
T-VEC はテストベクタ自動生成の過程で各DNFにモデル検査を実施して、モデル内の欠陥をレポートする(形式手法による定理証明)。
 
モデルの欠陥の単純な例は論理矛盾(logical contradiction)。DNF に分解された仕様内の (x > 0) & (x < 0) といった制約条件上の矛盾。
 
モデル検査はサブシステム間で構成される階層に対して、制約条件や関数参照(function references )が上流レベル(親)と下流レベル(子)サブシステム間で充足されるかどうかをチェックできる。
 
例えはコンセプト図(図1)のように、最上位(祖父)サブシステムから子サブシステムへの DNFスレッド 内に制約条件 x > 0 があると、親サブシステムを介して子に至るDNFの少なくとも1つは、x > 0を満たされる必要がある。しかし、このような最上位側の制約条件が満たされないなら、その最上位サブシステムのDNFの入力スペースはヌル(null)であり、テスト入力値が得られない。これがモデル上のエラー(入力範囲内で制約事項を満たせないというエラー)。テストベクタ生成時にモデルへのトレーサビリティ情報を活用し、モデルエラー結果から該当するモデルの位置に探索できる。
 

4.1 モデルのトレーサビリティリンクの例題

 
図7は4つのSCRコンディションテーブルがTTMにモデル化されている簡単な例。この単純なモデルのテーブル間には依存関係があり、モデル検査結果のトレーサビリティを説明するための欠陥が埋め込まれている。各テーブルのそれぞれの行は、各々DNFスレッドに変換される。最上位のサブシステム(hierarchical_root)は一つのDNFを持ち、それぞれ2つのDNFを持つchild_yz と parent_xy を参照する。そしてParent_xy は、同じく2つのDNFを持つchild_xy を参照する。
 

図 7.階層化されているTTMモデル


 
図8は、モデル検査結果のエラーレポートからモデルの該当箇所へのリンクの様子。ステータスレポートは各サブシステムの概要、モデルのコンパイルで得られるDNF (Domain Convergence Paths or DCPs [1])の数 などを表示。サマリーレポートはテストベクタ数、モデルカバレッジエラー数などを表示する。プロジェクトごとのステータスレポートは、欠陥のあるDCPごとに生成されるモデルエラーにハイパーリンク。そしてモデルエラーレポートから、モデル上の欠陥の該当箇所へハイパーリンクされる。
 
この例の欠陥は、最上位のサブシステム(hierarchical_root)の出力(assignment)がTRUEであるための、x と z が > 0 を満たすDNFのスレッドが下流サブシステムで得られないこと。child_xy は y <= 0 when x > 0、しかしながら child_yz は y > 0 when z > 0 なので、最上位のサブシステム(hierarchical_root)と、2つの依存するサブシステムとの間のロジックで矛盾が生じている。
 
図9はSimulink ツールで図7と同じ仕様をモデル化したもの。TTM モデルと同様、Simulink モデルは変換されテストベクタ生成が試みられるが、やはり最上位のサブシステム(hierarchical_root)の出力(assignment)がTRUEのケースでモデル上の矛盾があるので、テストベクタは生成されない。そしてエラーレポートから、Simulink モデル上の該当箇所へのハイパーリンクが張られる(図10)。
 

図 8.欠陥レポートからTTMモデル上の該当箇所へのトレーサビリティ


図 9.欠陥レポートからSimulinkモデル上の該当箇所へのトレーサビリティ


 

4.2 その他、モデル検査の有用な活用法

 
モデル検査はセーフティプロパティなどの証明にも活用できる(あってはならない事象が無いことの証明)。セーフティプロパティをモデル・アサーションとして追加でモデル化し、テストベクタ自動生成プロセスにて、モデル・アサーションがモデル内で成立できるか否かを検査する。この場合、テストベクタが生成されなければ、そのセーフティプロパティは侵害されていないということになる。(逆にテストベクタが生成されれば、その入出力関係であってはならない事象が存在するということ)
 
日本の次期支援戦闘機として採用が決定された Lockheed Martin 社の Joint Strike Fighter(F35)は、T-VEC がモデル検査とテストベクタ生成に活用されたSimulink モデルで最も大規模で複雑なもののひとつ。このような航空システムで一般に共通した安全要件の一つに、航空機が地上にあるとき(車輪に荷重しているとき=weight on wheels (WOW))にはレーダーを有効にしてはいけないというものがある。地上作業員に危害を加えないために。これを例にするとセーフティプロパティのモデル検査は、WOW(車輪荷重) & Radar = ENABLED(レーダー有効)が成り立つかどうか。このアサーションをSimulink モデル内に追加記述して、もしテストベクタが生成されるなら、その安全要件が成り立たないケースがあることが検出される。また他にもゼロ割やレンジオーバーフロー、アンダーフローなどモデルシステム内の各インターフェイスに定義される範囲(レンジ)内で起こり得る算術的な矛盾やエラーの可能性を正確に検出できる。そしてこれらのエラーもモデルの該当箇所にハイパーリンクされる。
 

5 SUMMARY

 

図 10.Simulink モデルのトレーサビリティ


 
モデルベースのテストは要求仕様の改善、より良いテストの実施、早期段階からのテスト設計など多くの効果があるものの、開発組織は様々なタイプの需要に対して活用できることを確認できるまで、採用に抵抗を示すことが多い。これらには、開発ライフサイクル全般にわたるサポート、モデリングの豊かな表現、プログラミング言語などテスト実行環境、短期間の投資対効果、などが求められることを1996年から経験している。そして近年では殆どの組織が、要件管理ツールに、我々の提供する要件・設計モデリングツールとテスト生成機能を統合することも求めるようになっている。
 
この資料では、要件管理ツールであるDOORS とTTMモデリングツールの統合や、Simulinkモデルとの統合を介して、モデルベースドテストによるテストベクタとテストドライバーの自動生成についての成果を紹介した。DOORS との統合によって、テストまで含めた要件トレーサビリティが完全にサポートされる。そしてトレーサビリティのプロセスによる以下の効果によって、開発組織に於ける採用が助長される。
 
1. 要件モデリングプロセスによって、要件とモデルの詳細との間のリンク(紐付)が後押しされて、要求仕様が明白になるような完全なモデル化を支援する。そしてモデルへのリンクが無い要件があれば、それは未だモデル化されていないだけなのか、モデル化やテストができない要件なのかであり、いずれにしても更なる改善が求められるということが明らかになる。
 
2. 曖昧すぎる要件は、モデリングプロセスの早期段階で明らかになるので、その細分化や改善が、コスト効率良く実施できるようになる。例えば一つの要件が大きすぎて、モデル内の一つの表の全て(SCR 形式のコンディションテーブル)や、複数の表に跨ってしまうような場合、そのような要件は表のエレメントにリンクできるように改善することが賢明。
 
3. 要件にリンクされないモデルも明確になる。それらは実装時に派生される要件、あるいはローレベルの要件であり、恐らく要求仕様書へ反映させるかどうかが考察されるべき。
 
4. 要件からテストへのリンクによって、テスト実行の結果(例えばテストフェイル)は実装コードからモデル、要件へとさかのぼってリンクできる。これによってテスト実行フェイル時の解析工数・費用は飛躍的に改善できる。
 
5. プロジェクトマネージャは、モデルベースの解析とテスト自動生成によって得られる成果のプロジェクトや製品、プロセス管理・解析などへの活用状況をより良く知ることで、組織内の意思決定の糧とすることができる。資料[4]では、モデルベースの成果物から得られる基本単位について紹介している。テストに至る要件トレーサビリティはプロジェクトの進捗状況判断材料となる情報を提供できる。経験則に基づくデータを用いてプロジェクトの進捗を予測するツールも別に開発している。
 
他にもモデル検査結果のエラーレポートからモデル上の該当箇所へのハイパーリンクによって、モデルや要件上の欠陥が直ちに確認できて改定作業の工数を削減する。
この資料で紹介したモデルベースドテストと要件トレーサビリティは、多くのユーザによって支持された。TAF によるモデルベースドテストによって、テストが自動化されコストが削減できること[5, 6]、要件上の欠陥を早期発見して改定工数を削減すること[7]、セーフティクリティカルなシステムの欠陥を体系的に検出できること[8]、拡張機能・能力[9]、セキュリティシステムなど他のドメインへの活用[10, 11]、など多岐にわたる。しかしながらモデルベースドテストをライフサイクル全体にわたって活用することが、組織への採用には非常に重要であると考えられる。
 

6 ACKNOWLEGEMENT

 
DOORS とTTM の統合への Chris Snyder 氏の尽力に感謝の意を表する。
 

7 REFERENCES

 
[1] Rob.Hierons. http://www.brunel.ac.uk/~csstrmh/research/test_z.html.
 
[2] Blackburn, M.R., R.D. Busser, Automatic Generation of Test Vectors for SCR-Style Specifications. Proceeding of the 12th Annual Conference on Computer Assurance, June, 1997. http://www.t-vec.com/download/papers/tvec_scr2tvec.pdf
 
[3] Heitmeyer, C., R. Jeffords, B. Labaw, Automated Consistency Checking of Requirements Specifications. ACM TOSEM, 5(3):231-261, 1996. See http://chacs.nrl.navy.mil/personnel/heitmeyer.html.
 
[4] Blackburn, M.R., Objective Measures from Model-Based Testing, STAREAST, Orlando, May 2004.
 
[5] Statezni, David, Industrial Application of Model-Based Testing, 16th International Conference and Exposition on Testing Computer Software, June 1999.
 
[6] Statezni, David. Test Automation Framework, State-based and Signal Flow Examples, Twelfth Annual Software Technology Conference, May 2000.
 
[7] Safford, Ed, L. Test Automation Framework, State-based and Signal Flow Examples, Twelfth Annual Software Technology Conference, May 2000.
 
[8] Blackburn, M. R., R.D. Busser, R. Knickerbocker, R. Kasuda, Mars Polar Lander Fault Identification Using Model-based Testing, NASA Software Engineering Workshop, November 2001. See http://www.software.org/pub/taf/downloads/mars_polar_lander_2001.pdf.
 
[9] Busser, R.D., L. Boden, Adding Natural Relationships to Simulink Models to Improve Automated Model-based Testing, Digital Avionics Systems Conference, October 2004. See http://www.software.org/pub/externalpapers/papers/busser-2004-2.doc.
 
[10] Chandramouli, R., M. R. Blackburn, Model-based Automated Security Functional Testing , 7th Annual Workshop on Distributed Objects and Components Security (DOCSEC), Baltimore, MD, April 2003.
 
[11] Blackburn, M. R., R. Chandramouli, Using Model-Based Testing to Assess Smart Card Interoperability Conformance, International Conference on Computing, Communications and Control Technologies, Austin, August 2004.