HOME | products | T-VEC | MBT で派生開発を支援

テストは人手に頼らない!

派生開発,モジュール化を支援できるモデルベースドテスト

T-VECのモデルベースドテストは,仕様をモデル化して形式手法で検査。テストを開発と並行して進行することで、早期段階で仕様上の欠陥を排除して手戻りを削減。加えて、テスト入力・期待値・ドライバーを自動生成するので、後工程の工数を飛躍的に軽減する。
 
要求の仕様化は、機能安全規格や社内ルールに従うことが目的では形骸化しかねないが、T-VEC があればテストが楽になるので嬉しい!
 

 

T-VEC テスト自動化フレームワークのプロセス
 
1. 早期段階から要件をモデル化

2. モデル化の過程で漏れ・抜け・曖昧さを排除して要求仕様を洗練
3. モデルをT-VEC形式に変換
4. 各要件を満たす入力・期待値を自動生成/生成できない仕様からは欠陥を検出
5. 入力・期待値を基にテスト実行するドライバーを生成するスキーマを定義
6. テスト実行結果と期待値を比較してコードの一致制を検証

こんな症状でお困りでは?

 
*ソフトウエアに品質、安定性の問題がある
*要件上の問題が多くの問題の原因となっている
*テストドライバーのデバッグ工数がバカにならない
*機能間の問題に対して多くのテスト工数を要している
*要件トレーサビリティを求められるが、もう身が持たない

インターフェイス駆動のモデリングでモジュール化を支援

結合(coupling)はコンポーネントの再利用性を損ねること、システムコンポーネント間の結合はリグレッションテストの苦労と工数を増加させること、重度に結合されたシステムのテストに関わる問題はMBTに限らずどのようなタイプのテストにも悪影響を及ぼすことは既に周知されている。
 
理想的には早期段階からインターフェイス駆動で、テストプランを並行して実施できれば良いが、人手に頼ったテストは、担当者間の重複、肥大化する成果物の管理、テストドライバーにも潜むバグへの対処(テスト工数の50%を占める)に加えて、変更・追加される要件への対処がプロセスを複雑にし、大きな障壁となっている。 
 
そこで数千行ものテストスクリプトを書く代わりに、早期段階からMBTを通じて要求をモデル化すれば、要求仕様を洗練させて、インターフェイスを明確に定義した疎結合な設計を育み、テストの自動化を得ることができる。
 

派生開発

 
派生開発でも検証作業の効率化には、インターフェイスを明確にして振舞いから分離することが求められることは同じ。ただリソースに限りがあることから、変更・追加要件のみに割り切ってMBTを取り入れる。既存システムが結合状態にある場合は(殆どはこちら)、ラッパーを介したコンポーネント化などによりカップリングを排除するなど、上手な工夫も考える。
 


 

 “既存システムの機能は、メモリスペースの制限など、過去から引き継いできた多くの制約と密接に関わっていました。また、Filter、Match、Select間のインターフェイスは、明確に定義されていませんでした。そのため、テストプロセスは複雑でした。多くのテストは、Checkのようなサブシステムに対して、上位層レベルから実行される必要が有りました。なぜなら、入力のいくつかは、Checkコンポーネントから上流へセットされるからです。さらに、Matchなど機能からの出力は、可視的では有りませんでした。そのため、これら下位層レベルにあるコンポーネントの体系的、かつ包括的なテストは、困難でした。それゆえ、実装を介して、これら下位層レベルのコンポーネントの、各スレッドに対するテストのカバレッジを満たすためには、上位層レベルのコンポーネントからのテスト実行が増大することになります。時にはテストの数量が大規模になってしまいます。
 
 要求仕様のモデリングを行うことで、早期段階から入出力間のインターフェイスは明らかになり、内部ステート情報を得ることも相まって、テストの容易性が飛躍的に向上しました。デザインチームにより改善されたインターフェイスへの対応により、おおよそ80%の機能がテストされるようになりました。これにより、モデルとテストの複雑さを飛躍的に軽減し、より少ないテストで工数とコストを削減しながら、最大限のカバレッジが得られるようになりました。 ちなみに、残りの20%は、性能や、コストへのインパクト、リソース、再テストのスケジュールなど、改善できない要素に関わるコンポーネントです” 
T-VEC Wiki “テストを容易にするモジュール構造” より
 
医療機器開発の事例では、システムレベルの機能仕様から得られたテストシナリオをモデル化(例えば、体内式除細動器のパラメータを変更する機能)。そしてソフトウエア開発者がレビューに関わって、コード設計上の詳細情報をモデル上にテストの制約条件を加味することで、より良いテストとカバレッジを行えたことが報告されている。
 

例えば派生開発の実践的手法として知られるXDDP の変更三点セットを作成しながら仕様変更についての理解を深めることで、モデルベースドテストを使ってテストを楽にできる!

T-VEC TTMによるテスト自動化フレームワーク

モデルベースで要件上の欠陥検出と、テストの自動化により、飛躍的に開発コストを削減できる。事例として検証作業の50%が削減されることが報告されている。

特徴:

 -形式手法による定理証明(人では解析できない階層間に存在する矛盾、非線形)
 -テストベクタ(入力・期待値)を自動生成(上下限、境界値、線形・非線形)
 -フロート、ダブルなどあらゆるデータ型をサポート(定理証明、テストベクタ生成)
 -モデル化による共通部品化で再利用性向上
 -モデルをベースにすることで様々なテストの成果物の構成管理を単純化
 -要件等の変更にもモデルの変更のみで直ちにテストできる
 -状態爆発しない(サブシステムごとに上流のコンストレインツを加味した入力で検証)
 

効能・効果

・開発工数とコストを飛躍的に削減(50%)
・品質と安定性の向上
・欠陥検出やカバレッジ結果からプロジェクトの進捗を評価
・修正に多額のコストを要する後工程で欠陥が検出されることを削減
・テスト、検証の工数を50%削減
・要件上の欠陥を早期検出して想定外のやり直し作業を軽減
・システムの機能はモデル内にドキュメント化される
(テストスクリプトやテスト担当者の頭の中ではなく)
・システム変更時には、モデルの変更のみで直ちにテストを再生成できる
・テスト実行環境が変更されても、モデルに依存することなくテストスクリプトの更新が容易
・モデリング作業を通じて仕様を洗練して欠陥を早期に発見
・要件から包括的なテストを自動生成
・要件からテストに至る完全なトレーサビリティ
・早期段階からインターフェイスを明確にすることを促進してアーキテクチャを安定化
 

参考文献

・困ってませんか? 派生開発 ~XDDP はじめの一歩~  AFFORDD T3 研究会(XDDP 入門)