C/C++ C0 C1 MC/DC ISO26262/IEC61508 カバレッジ ... · Copyright © 2006-2016 GAIO TECHNOLOGY CO., LTD. ALL RIGHTS RESERVED. カバレッジマスターwinAMS

1Copyright © 2006-2016 GAIO TECHNOLOGY CO., LTD. ALL RIGHTS RESERVED.

カバレッジマスターwinAMS

カバレッジマスター winAMS

ガイオ・テクノロジー（株）営業本部

2016.12.06_V83

ターゲットコードベース C/C++ 単体テストツール

C0、C1、MC/DCカバレッジ計測テストデータ生成をサポート

結合テストにおける関数/コールカバレッジ計測をサポート

自動車機能安全規格ISO26262/IEC61508 ツール認証取得

カバレッジマスターwinAMS/ゼネラル、CasePlayer2は、第

三者認証機関であるドイツのテュフズードより自動車向け機能安全規格 ISO 26262のツール認証を取得しました。



Agenda

■ 組み込みソフト品質向上への課題 3

■ 潜在バグを無くし信頼性を向上するモジュール単体テスト 9

■ 単体テストの効果例/実施例 18

■ カバレッジマスターwinAMS 基本機能概要 24

■ 安全規格ISO 26262/IEC 61508 ツール認証について 34

■ 機能安全（IEC 61508 / ISO 26262）へのカバレッジマスターの優位性について 41

■ プログラム解析ツール CasePlayer2との連携機能 45

■ MC/DCカバレッジ測定機能（オプション機能） 47

■ 対象関数の入出力変数の自動抽出機能（標準機能） 54

■ 【V3.7新機能】ブラック/ホワイトボックステストデータ作成支援・自動生成機能（標準機能） 56

■ C1、MC/DC 計測用テストケース自動生成機能（標準機能） 70

■ テスト作業をより効率化する「加速オプション」（オプション機能） 80

■ 結合テストに向けた関数/コールカバレッジ計測機能（オプション機能） 84

■ 【V3.7新機能】CLI（Command Line Interface）機能（オプション機能） 108

■ C++コード単体テスト機能（オプション機能） 121

■ カバレッジマスターの優位性と導入効果ツール選定のポイント（参考資料） 125

■ 導入実績・発表事例（参考資料） 130

■ テストパートナーSQV 単体テスト代行サービスについて（参考資料） 132



組み込みソフト品質向上への課題



組み込みソフトウェア開発の現状

■ 組み込みソフトウェアは大規模化、複雑化している– 累乗的に大規模化、複雑化するソフトウェア規模

– ソフトウェア規模に比例して増大する不具合件数

市場不具合や開発リスクが激増!!



ソフト品質改善に対する意識・要求

■組込みソフトが原因となる品質問題が非常に多い

■「設計品質の向上」が企業における最優先課題となっている

製品出荷後の不具合の原因事業責任者層の課題意識

設計品質向上が最大の命題

Q2-6-I 組込み系ソフトウェア開発の課題Q5-2 原因別の不具合発生製品数比率（N=74）と不具合発生件数比率（N=73）



組込みソフトウェア開発の課題

■ ソフト開発者の人数を増員によりソフト品質にばらつきが出てしまう– 組込み開発経験の浅い技術者も多く、ソフト品質が保てなくなる

– システム全体のソフトウエアの全てを見通すことは不可能になっている

■ コーディング後のソフト品質確認のために「単体テスト」が重要となる– コードレビュー、単体テストフェーズへの対策が必須

V字プロセス

仕様設計

システム設計

詳細設計（関数設計）

コーディング

システムテスト（実機テスト）

結合テスト

単体テスト

コードレビュー

【課題】・ソフト品質が個人スキルに依存・人的ミスの発生が大きい

このフェーズでのソフト品質改善が必須事項となっている

Ｖ字ボトムフェーズの開発者の増加が

著しい



組込みソフト品質改善の方策

組込みソフト品質改善

Ｃ言語コーディング規約の適用

コーディングの自由度を制限することで不具合を出しやすい記述を抑制。MISRA-C、SEC規約などのルールが有名。新規開発には有効。

ソースコードレビュー（クロスチェック）の実施静的解析ツールの活用

開発者個人に依存したミスや単純な思い違いが無いかを相互確認。

モジュール単体テストの実施

動的テストにより、レビューでは漏れてしまう不具合を検出。テスト履歴やテストエビデンスを定量的に残しやすい。

コーディングミスの早期発見、エラー推測が可能

プログラム解析/MISRA-Cルールチェックツール「CasePlayer2」

組込み向け単体テストツール「カバレッジマスター」



（参考）静的解析と動的テストの活用

■ 静的解析エラー推測と動的単体テストによるエラー検出の棲み分け静的解析：静的コードチェック、データフロー（ランタイム）解析、エラー推測

最小限のテスト工数で、コーディングミス、エラー推測が可能

動的検証：単体テストによる期待値評価＋コードカバレッジ計測

要求仕様テスト、ターゲット依存の問題点検出が可能 → 機能安全（ISO26262）対応に必須

コーディング・ハンドコード・オートコード

静的解析データーフロー解析

エラー検出

カバレッジマスター実コードベース単体テスト

ISO要求品質要求OK

エラー有り

エラー無し

GOAL

コーディングミス検出エラー推測

要求仕様確認

コードカバレッジ確認

マイコン、コンパイラ依存エラー検出

エラー検出結果評価

エラー有り

エラー無し

可能だが、レビュー工数、スキルを要する

ツール活用により最小限の工数でエラー検出効果あり

↑

後工程の工数削減効果有り

要求仕様、カバレッジ確認ターゲット上での動作担保

↑

ISO要求、品質観点で不可欠



潜在バグを無くし信頼性を向上するモジュール単体テスト



単体テストとは？

■ ブラックボックスの観点で関数の機能性を評価– 各関数が仕様通りに作られていることを確認すること

– ブラックボックスの観点で、関数仕様通りに設計されているかをテスト

– 詳細設計から設定した引数/外部変数への入力値に対して出力変数が正しいか？

■ ホワイトボックスの観点でコーディング時に作り込んだミスを検出– カバレッジの指針を使用して実装コード構造の間違いを検出

– 不要コード、デッドコードの有無の確認

– ゼロ割、NULLアクセスへの回避コードの有無、オーバーフローの発生の有無を確認

関数詳細仕様

一致性の評価

base(int a, int b, int c)

{

if (a == 1)

{

if (b == 1)

{

idx = 0; // data[0]

if (c == 1)

pos = 0; // data[0].str[0]

：：

}

// 結果の設定data[idx].c = data[idx].str[pos];

value = data[idx].str[pos]; //- 1;

}

ブラックボックスの観点で関数の機能を評価


{

if (a == 1)

{

if (b == 1)

{

idx = 0; // data[0]

if (c == 1)

pos = 0; // data[0].str[0]

：：

}

// 結果の設定data[idx].c = data[idx].str[pos];

value = data[idx].str[pos]; //- 1;

}

ホワイトボックスの観点でコード実装ミスを評価

ロバスト性（堅牢性）の評価

ゼロ除算オーバーフロー

その他の実装上の不具合

カバレッジ評価

デッドコード・パス検出永久ループ検出

「機能性テスト」の補完

定義された関数機能



（参考）ISTQBに定義された単体テスト技法

■ ISTQBの定義から引用：単体テストの設計技法仕様ベーステスト

関数仕様書を基にテスト項目を作成

ブラックボックステスト / 関数への入力に対する出力を評価

構造ベーステスト

ソースコードの全ての構造を網羅して、これがすべて「動くこと」を確認するテスト

カバレッジの指標（C0,C1,MC/DC）により、これを満たすテストを行う

欠陥ベーステスト

予測される潜在的な問題を中心にテストを設計する

経験ベーステスト

過去の問題経験からテストを設計する



（参考）仕様ベーステスト/仕様網羅のテスト項目設計

■ 関数仕様を基にテスト項目を導出する関数仕様を読んで理解し、テスト項目を導出する

例： AddFunc() 関数仕様【関数機能】

入力された２つの引数InA、InBの加算値を求め、戻り値として出力する【入出力仕様】

入力引数： InA： unsigned char型、有効レンジ 150以下引数： InB： unsigned char型、有効レンジ 150以下

出力戻り値： unsigned char型

【例外条件】InA、InBのいずれかが有効レンジ外の場合は、255（0xFF）を出力して終了加算値が200を超える場合は、200を出力して終了

【API】unsigned char AddFunc(unsigned char InA, unsigned char InB)

149 149150 150151 151255 最大値 255 最大値

0 最小値 0 最小値75 代表値 75 代表値

入力テストケース例

境界条件境界条件

inA inB

・境界値分析・デシジョンテーブルテスト

・同値分割法・状態遷移テスト・ユースケーステスト

単体テスト設計の手法

（参考）自動車機能安全規格 ISO 26262-6: 9 Software unit testing

導出



（参考）構造ベーステスト/カバレッジ確認

■ 仕様を基に設計したテストケースでコード構造が網羅されるかを評価• カバレッジ（C0、C1、MC/DC）が100%になるかを確認

100%の場合：不要コード、デッドコードが無いことが確認できる

未達の場合：テストケースの不足か、または不要コード、デッドコードかを評価

（参考）自動車機能安全規格 ISO 26262-6: 9 Software unit testing

コード構造を網羅するかを評価仕様を網羅するテストケース



単体テストの工程

■ 単体テスト設計指針の作成単体テストがテスト担当者のスキルに依存しないように指針を設定

※次頁に参考例

■ 単体テスト設計仕様ベースによるテストケース設計

• 境界値分析、同値分割、状態遷移など単体テストの導出手法を使用

構造ベースによるカバレッジ網羅のテスト設計

• C0、C1、MC/DCなどカバレッジ指針を満たすテストを行う

欠陥ベース、経験ベースによるテストケースの追加

■ 単体テスト実行– 作成したテストデータを関数に与えて実行

■ 実行結果の評価– 期待値との一致を確認、カバレッジ評価

入力テストデータ

出力テストデータ

カバレッジ

モジュール単体テストの概要

出力（評価対象）の確認

実装コードの網羅性確認

関数の機能性とロバスト性を評価

単体テスト設計要素分析

モジュール（関数）

ツールで自動化が可能



（参考）単体テストには作業フローのマニュアル化が重要

■ 単体テストを定着運用するためには・・・• 単体テストの作業フローをマニュアル化する

• 担当者のスキルに依存しないテストが可能な様にテストを標準化する

必ず行わなければならないテスト項目（必須項目）を明確に定義する

テスト設計に可能な限り担当者の判断が入らないようにテスト指針を設定する

単体テスト実施の前に指針を決めておこう！

※単体テスト代行サービスにおける指針（ガイドライン）の一例



（参考）コントロールカバレッジ

■ コントロール（実行制御に対する）カバレッジ

C0：ステートメント（命令）カバレッジ【指針】全ての実行文を１度実行すればOK【保証できる内容】

・コーディングしたが実行されない実行文はない・存在してはいけない実行文はない

C1：分岐（ブランチ）カバレッジ【指針】全ての条件文の真/偽を実行すればOK【保証できる内容】

・存在してはいけない実行パスは存在しない

条件

Ａ=1

真偽

A=0

X=Y/A

条件Ｃ

X or (Y and Z)

処理Ａ処理Ｂ

真偽

赤のパスには実行文がないので、C0ではテストされない

条件真偽

処理

処理処理

C1では十分でない例

C0カバレッジ：ソース行をマークして、全て塗りつぶす

C0では十分でない例 C1カバレッジ：フローチャートの全てのルートを塗りつぶす

複合条件では１つのTRUE/FALSEがテストされるのみ全ての組合せがテストされる訳ではない



（参考）コントロールカバレッジ（続）

■ コントロール（実行制御に対する）カバレッジ（続き）C2：コンディション（条件）カバレッジ【指針】全ての条件文の条件式の組み合わせを１度実行すればOK【保証できる内容】

・存在してはいけない条件判定式の要素がないこと

MC/DC： Modified Condition/Decision カバレッジ【指針】全ての条件文の条件式の組み合わせのうち、意味のある組み合わせを全て１度実行すればOK【保証できる内容】

・C2と同等の網羅内容（テストデータはC2より少ない）

条件Ｃ（X and Y） or Z

処理Ａ処理Ｂ

真偽

条件式 X F F F F T T T T

条件式 Y F F T T F F T T

条件式 Z F T F T F T F T

条件Ｃ（X and Y） or Z

処理Ａ処理Ｂ

真偽

条件式 X F F F F T T T T

条件式 Y F F T T F F T T

条件式 Z F T F T F T F T

論理 F T F T F T T T

条件要素に対する網羅性は100%だが、効果のないテストが含まれてしまう

全ての条件文の条件式の組み合わせを実行

他の条件式の真偽を固定して、１つの条件式の真偽を変化させたとき、全体の条件に変化があるものだけを実行する（↓色のついたデータ）

Ｃ２の網羅性を維持して、テストパターン数を抑えることができる

Z X Y２つのデータ組み合わせで、

各条件式を評価→

MC/DC：全ての条件式のTRUE/FALSEの効果を確認する

C2カバレッジ：複合条件の全数組合せをテストする



単体テストの効果例/実施例



・テスト項目がすっきりと整理された！

・不具合が出ても、原因が関数にあるかシステムにある

かが、直ぐに分かる！

・例外系の条件に対するロバスト性も確保できた！

・テスト項目が多く複雑で、全てをテストしきれない

・不具合を確認したが、要因の特定が難しい

・正常動作には問題がないと思うが、例外系はどうか分

からない・・・

モジュール単体テストの効果例1

■ ソフト設計の上流工程での単体テストは潜在バグを未然に防ぐ– 上流工程での「ホワイトボックステスト」で「想定外」条件を検証

– 下流工程のテスト項目を減らし、問題要因の発見を容易にする

システムテスト（実機テスト）

結合テスト

単体テスト

コードレビュー

コーディング上流

下流

単体テストを行わないと・・・

単体テストを行ったら・・・

不具合潜在化のリスクあり！



新規開発ソースコード

■ 関数モジュールの再利用において製品品質を確保可能にする– 単体テスト未実行の関数の再利用は他の製品へ不具合を及ぼす

– モジュールの再利用においては単体テストは必須となる


OK!

旧機種のソースコード

ソースの大半は再利用OK! OK!

OK!

OK!

OK! OK!

OK!

OK! OK!

新機種のソースコード

再利用するソースに不具合が潜在していると・・次の設計にもそのまま影響してしまう！

一般的な組み込み開発では、新規開発するソースは、少ない

ほとんどは、ソースを再利用して開発される



1100xfff

e22

0060xaaaa

11

15

-5

11

0

10

9

5

A

0xffff5

0xfffe

4

0xaaaa

0xffff3

B F

9

7

8

6

EDC

入力値

入力要素

第1引数y

第2引数count

disp_set2

の

復帰値

disp_set2

の引数

count

グローバ

ル変数

flag

第2引数countが示すメモリデータ

short型の領域を示す

アドレス


■ テストの結果を定量的に図りやすく品質の指標が明確になる要素分析表：変数に対してどの様な値を与えてテストしたかを示す

テストベクターの個数：

カバレッジ率： C1/MCDCなど、ソースコードのテスト網羅率を示す

※ガイオ単体テスト代行サービスでの納品物の例

カバレッジ率

要素分析表

テストベクタ数




■ 関数設計者自身による単体テストはコーディングに良い影響がある– 関数設計者自身による単体テスト実施でソースコードを反復レビューすることになる

– 「網羅性」を意識したテストケース作りの過程でソースの潜在バグを検出できる

■ 自動テストシステムで工数をかけない反復テストの実施が可能– 一定時間毎に単体テストが自動実行され、変更による全体への影響が直ぐに確認できる

実機総合テスト

関数設計コーディング

テストデータ作成

関数設計者

データ登録

１台の自動テストシステムで一定時間毎に自動実行

関数設計＆テストデータ作成ソースコードレビュー

２段階工程のモジュール単体・カバレッジテスト

テストレポート

網羅性を意識したテストケース作成で、

ソースコードを繰り返しレビュー

※フェリカネットワークス様のユーザー事例より

自動テストシステムへデータを登録すれば

日々のテスト作業から解放される

テスト指針書

自動テストシステム



単体テストの定着運用による効果

■ 単体テストは「開発プロセス」の中での反復した運用で効果が高まる１つのプロジェクトへの適用での即時効果よりも、

数回のプロジェクトへの運用で、再利用されることにより効果が高まる

■ 単体テストの実施はソフト設計にも良い影響を与える単体テスト実施で得た不具合情報を設計にフィードバック

テストしやすいコーディング ← 品質の高いソフトの基本条件

テストを意識したコーディング ← 網羅性を意識したソフト設計に

単体テスト

開発

テストしやすいコーディング

ソースコード

ソースコード

ソースコード

結果のフィードバック

ソースコード

ソースコード

ソースコード

反復した運用で品質が高まる

テストを意識したコーディング



カバレッジマスターwinAMS基本機能概要



ガイオカバレッジマスター winAMS 特長

■ 組込みソフトをターゲットとした単体テストツール

■ マイコンシミュレータ（ISS）を使用して「実機コード」をテスト– マイコン仕様、コンパイラなどの、ターゲットへの実装時の問題を含めた評価が可能

– 単体テストのソースコード、ビルド環境は、製品開発のものをそのまま適用可能

■ テストドライバ作成、ソースコードの変更は不要

■ テストデータ（関数、変数名）は全てCSVファイルで入出力

■ 実行後のパスカバレッジ結果を自動レポート

マイコンシミュレータ（ＩＳＳ）

winAMSユニット（仮想テスト装置）

内部連携

●評価対象の組み込みオブジェクトコード（実装ROMコード）を実行

●テストデータ（ＣＳＶ）入出力●カバレッジ結果の作成

C0/C1カバレッジ

テストデータ・結果

入出力データ

実機マイコン動作と等価なテスト環境



関数への入出力テスト方法（仕組み）

■ 関数を単体実行する仕組みをシミュレータ本体に実装– クロスコンパイルした組み込みオブジェクトをそのまま使用

– 関数名、変数名、テストデータをCSVで入出力

– 期待値との照合結果を自動レポート


{

if (a == 1)

{

if (b == 1)

{

idx = 0; // data[0]

if (c == 1)

pos = 0; // data[0].str[0]

：：

}

// 結果の設定value = data[idx].str[pos]; //- 1;

}

テスト入力データ CSV

テスト結果出力 CSV

試験対象のソースコード

カバレッジマスターwinAMS パッケージ

・対象の関数名・入力変数名＆入力データ・出力変数名＆期待値

・出力変数名＆変数結果出力・期待値との比較結果（OK or NG）

・組み込みソースをそのまま使用・コンパイラも現在お使いのものを

利用可能・バッチ処理で自動テスト

マイコンシミュレータ

単体テストシミュレータ



C0/C1カバレッジ自動レポート（標準機能）

■ 「カバレッジマスター winAMS」 C0/C1カバレッジ結果を自動レポート– 条件分岐によるコードパスの網羅テストで品質を保証

– 「winAMS」によりテスト実行後に実行したソース行を色表示

– 組み込みソフトのC0/C1カバレッジの自動テストを実現

C0/C1カバレッジ結果表示

実行後

winAMS シミュレータ

入出力CSVデータ

クリックしたテストデータによる実行ソース行を色表示



呼び出し関数ＳＴＵＢ作成機能（標準機能）

■ 単体テストのフェーズでは関数を独立させて単体で評価する• テスト対象関数とサブ関数の依存関係を無くすためにスタブ関数を作成

■ スタブ関数作成・管理機能をサポート• 元のソースコード修正なしでサブ関数の入れ替えが可能

• 関数リスト上の「置換」スイッチでスタブのON/OFFを簡単に切り替え可能

• テスト対象の関数呼出し部分のコーディングは、一切修正不要

テスト対象関数void func( void ){

ret = SubFunc( 10 );

}

呼び出し関数int SubFunc( int value ){

return ○×..;

}

STUB関数int AMSTB_SubFunc( int value )

{

return ○×..;

}

×

「置換」実行



ポインタ変数対応・その他機能（標準機能）

■ ポインタ変数・引数にも対応– 変数の実体を伴わないポインタ変数・引数の場合でもそのままテスト可能

– 入力データCSVの変数名に「$」を付けるだけで実体を自動割り当て

– 割り付けエリアは MPUのメモリモデルから自由に指定可能

■ CSVファイルに「～」で期待値の範囲指定も可能– レンジ内に入ることを期待値とする場合

– 浮動小数点変数に対する有効数字範囲指定

int func1( char *data )

$ポインタ変数の実体を作るための割り当てエリアを指定



アセンブラ混在表示（標準機能）

クロスコンパイラの最適化等により、Ｃソースと生成されたマイコンコードの不一致が起こる場合がある為、混在表示で影響を判断出来ます。

■コンパイラが生成したデバッグ情報を基にソースと生成コードの対応を混在表示

関数内で使用されていないことにより、マイコンコードが生成されていない為、背景色が白色となる例です。



C0/C1カバレッジ、入出力結果表示

■ C0/C1カバレッジビュー– カバレッジ結果とテストデータを表示

– 期待値と異なるデータセルを表示

• 100?(200) →期待値が200だが結果は100

– C0を満たさない未実行行を表示

– C1を満たさない条件を明示

– ★各行を通過するデータを解析しで表示

• 未実行行のデータを追加する際の解析に非常に役立つ機能



選択テストデータを一斉自動実行（標準機能）

■ 管理ツールSSTManagerで選択したデータを自動実行– 指定したCSVデータ（関数）を自動バッチ実行

– 結果表示まで全て自動実行

テストデータを選択

テスト開始ボタン

自動テスト実行

入出力テスト結果表示

C0/C1カバレッジ結果表示

ダブルクリックで各結果詳細表示へ



カバレッジマスターゼネラルとは

■ マイコンシミュレータに汎用マイコン「ゼネラル」を使用• マイコン構造に依存しない C/C++関数を単体テスト

• 未サポートのマイコンの代替えとして使用

• マイコンを特定しないミドルウエア/アプリ層のコードを評価

■ 実行コードを生成する汎用コンパイラを内蔵• プログラム解析ツールCasePlayer2にてコンパイル＆実行コード生成

■ 単体テストの機能は「カバレッジマスター」winAMSと同じ• 実行環境（マイコンシミュレータ）が汎用化されているのみで、他の機能は全く同じ

評価対象ソースコード

.c

.h

テストプロジェクト雛形生成テスト実行ファイル作成

ANSI準拠汎用コンパイラ

単体テスト実行シミュレータ

ソースコード静的解析ツール「CasePlayer2」

実行結果・期待値判定カバレッジ結果表示・解析機能

「カバレッジマスターゼネラル」ツールパッケージ

単体テストに必要な全ての機能を標準搭載

テストプロジェクトに評価対象関数（ファイル）

を登録するだけ



安全規格ISO 26262/IEC 61508ツール認証について



機能安全ツール認証をTÜV SÜDより取得

■ 第三者認証機関であるドイツのテュフズード（TÜV SÜD）より機能安全ツール認証を取得 ISO 26262（自動車）、IEC 61508 （機能安全メタ企画）にて取得

ツール認証取得製品（2015/9/18に取得）

• カバレッジマスターwinAMS/ゼネラル V6.0.x：単体テストツール

• CasePlayer2 V6.0.x：プログラム解析ツール

結合テスト向け「関数/コールカバレッジ計測機能」もツール認証対象に– 単体テスト機能に加え、結合テストで求められる「関数/コールカバレッジ」計測機能も、

ツール認証の対象に含まれます。

TCLの設定によらず適用可能– 最も煩雑なツール認定作業が必要となる

TCL3に設定した場合にも適用されます

• ユーザ様は、TCLによらずツール認定に関わる作業を省略することが可能です



リファレンスワークフロー（RWF）とは？

■ ISO 26262に適合した静的解析、単体テストを行うのに必要なガイオツールの使用方法（ワークフロー）を定義した文書

■ TCLによらずツール認定に関わる作業を省略可能– ISO 26262は開発に用いるソフトウェアツール毎に設定するTCL (Tool Confidence

Level)に応じた開発ツール認定レポートの作成をユーザーに要求します

– 「カバレッジマスターwinAMS/ゼネラル」「CasePlayer2」はTÜV認証取得済み

– 最も煩雑なツール認定作業が必要となるTCL3に設定した場合にも適用可能

OEMECU

サプライヤツール

ベンダー認証機関

TÜV

リファレンスワークフロー

テクニカルレポート発行認証マーク発行

OKリファレンスワークフロー

納品物ツールクオリフィケーションレポート

この使い方に沿えば、機能安全のツールとして使えますよ。TÜVの認証がありますよ。

TÜVの認証を基に

して、ツールの認定をしましたよ。

RWFに沿わない部

分は、機能安全に沿ったプロセスが既にあるなら、それで

良いですよ。

RWFに沿わない部分

は、自分でツールの認定をして、レポート

に入れましたよ。

TÜVの認証※参考イメージ図



ユーザーにツール認定に必要な資料を提供

■ GAIOユニットテストツールセットリファレンスワークフロー（RWF）– 保守契約を頂いているユーザー様からの要求に基づいてガイオが提供

• 提供先を管理されたペーパードキュメントで提供致します（複写、転送はできません）

– 機能安全に対応する静的解析、単体テストを行うためにユーザー様は、RWFに沿ったプロセス（テスト手順）を構築する必要があります



認証バージョンの提供とバージョンアップについて

■ ISO 26262/IEC 61508認証バージョン専用WEBページを設置機能安全（ISO 26262/IEC 61508）ツール認証取得バージョン

• カバレッジマスターwinAMS/ゼネラル：v6.0.x

• CasePlayer2：v6.0.x

ガイオがアップデートバージョンで再認証を取得するまで、上記認証取得バージョンをいつでもダウンロード可能

■ 認証バージョンに対するバグフィックス等は認証の範囲内で個別対応機能安全に影響を与えないアップデートは、リビジョンアップにて対応

■ 再認証は機能安全へ与える影響とお客様のご意見を考慮し対応を決定※お客様自身でツール認証版以外のプライベート認定を行う場合は、資料提供などを協力致します

機能追加を含む最新版

(v3.X / v5.X)

認証バージョンのリビジョンアップ(v3.6.x / v5.6.x)

認証の範囲内で個別対応専用WEBページにて提供

通常のアップデートで提供再認証はお客様のご意見を考慮して

対応時期を決定

未認証



（参考）機能安全規格 IEC 61508 と ISO 26262

■ IEC 61508（メタ規格）のもと各分野ごとに機能安全規格が派生自動車機能安全（ISO 26262）はもとより、

IEC 61508のツール認証により広範囲な機能安全のテストに使用可能

機能安全規格

IEC 61508

鉄道IEC 62278

(RAMS)

船舶

防衛

自動車ISO 26262

医療器械IEC 62304

土工機械ISO 15998

ロボットISO 10218

エレベータEN 81-1

ISO 22201

プロセス産業IEC 61511

原子力IEC 61513

産業機械IEC 62061



機能安全（IEC 61508 / ISO 26262）へのカバレッジマスターの優位性について



自動車機能安全規格ISO 26262の推奨事項

■ ソフトウエアの構造網羅テスト、カバレッジテストに関する項目が規定自動車安全度水準ASILに応じて、ステートメントカバレッジ、ブランチカバレッジ、

MC/DCカバレッジの計測が推奨されている

■ 「単体テストの環境はターゲット環境に可能な限り合わせること」を推奨カバレッジマスターwinAMSは「実装コードがそのまま動く単体テスト」が可能な

業界唯一のツール

IEC 61508 META-STANDARDEN 5012x(鉄道)

IEC 60601 1-4 (Medical)

IEC 62304(医療機器ソフトウェア)

IEC 61513 (原子力)

IEC 61511 (プロセス産業)

ISO EN 12100 (Machinery)

ISO 26262 (自動車)

Part1:Glossary of Terms

Part2:Management of Functional Safety

Part3:Concept Phase

Part4:System Development

Part5:Hardware Development

Part6:Software Development

Part7:Production and Operation

Part8:Supporting Processes

Part9: ASIL- and safety-oriented analyses

6-9 ソフトウェア単体テスト構造網羅テスト

ステートメントカバレッジ分岐カバレッジ,MCDCカバレッジ

機能レベルでの欠陥投入モデルベーストテストMIL,SIL,PIL、HIL

モデルとコードの一致性テスト(BTBテスト)

6-10 ソフトウェア統合とテストモデルとコードの一致性テスト(BTBテスト)モデルベーストテスト

SIL,PIL,HIL欠陥投入テスト



実装コードがそのまま動く単体テストとは？

■ 単体テスト、カバレッジ計測のためのフックコード追加は必要なし– 計測用コード挿入のない、製品実装コードそのものを実行して単体テストを実行

– 計測の仕組みはコードではなく、シミュレータ本体に機能実装

– マイコン依存問題、クロスコンパイラコード展開、最適化処理を含めた高信頼性テスト

• ターゲットと異なる要素を全て排除した最も信頼性が高いテストとなる

C

CPP

ASM

評価対象の製品実装組込みコード

BIN

LIB

クロスコンパイラ※他社利用可能

カバレッジマスターwinAMS計測用フックコード

計測用テストドライバ

不要！

OBJ

CODE

実装マイコンコード

製品実装と同一のコード

テストCSV

データ作成

スタブ作成スタブ自動作成

テスト実行期待値評価

レビュー

C0/C1/MCDC

カバレッジ計測レビュー

マイコンシミュレータ

実装コードがそのまま動く単体テスト



他社単体テストツールフックコード挿入の影響

■ ターゲット環境での実行を行う他社ツールはコード構造を変化させるターゲット環境で実行したとしても、実装コードそのものをテストしていることにはならない！

フックコード挿入により、レジスタの使用方法、最適化などが変わり、コード構造が変化してしまう

カバレッジマスターwinAMSはこのままのコードを単体テストに使用

他社のターゲット環境実行可能なツールは全て

構造の変化したコードを単体テストに使用する

C言語ステートメント (1)


C言語ステートメント(1)のマイコンコード展開※コード構造が変化

C言語ステートメント(2)のマイコンコード展開※コード構造が変化

テスト対象関数にフックコード挿入

計測用フックコード１

計測用フックコード１のマイコンコード展開

計測用フックコード２

計測用フックコード２のマイコンコード展開

C

C

C

C

ASM

ASM

ASM

ASM

展開

展開

展開

展開



C言語ステートメント(1)のマイコンコード展開※最適化コード構造

C言語ステートメント(2)のマイコンコード展開※最適化コード構造

テスト対象関数

C

C

ASM

ASM

展開

展開

ターゲット環境で実行したとしても実装コードをテストしていることにはならない！完全にターゲットに

一致したテスト！

◎

×

●カバレッジマスターwinAMS ●クロス対応を謳う他社単体テストツール



機能安全認証IEC 61508 への適用事例

■ （株）不二越ロボット事業部様の IEC 61508機能安全認証への取り組みと単体テストツール「カバレッジマスターwinAMS」の適用事例– GAIO CLUB / 組込み開発技術者のための技術情報Vol.05 (2011/1/24)に掲載



プログラム解析ツールCasePlayer2との連携機能



CasePlayer2との連携による拡張機能

■ カバレッジ計測機能の拡張– C1カバレッジ計測（実コード実行による計測） ※C1計測にはCasePlayer2が必要

– MC/DCカバレッジ計測（埋め込みコードによる計測）

■ テストデータ設計機能の効率化– テスト対象関数の入出力変数を自動抽出

– C1/MCDC構造カバレッジ計測用テストケース自動生成

■ C++コード単体テストへの対応

フローチャート作成ソース解析ツールCasePlayer2

変数解析結果ファイル

カバレッジマスターwinAMSテスト実行ツール「SSTManager」

データ読み込み

関数の構造を解析データ自動作成など評価関数

ソースコード

解析

各種チャート連携変数ブラウジング



MC/DCカバレッジ測定機能（オプション機能）

※ CasePlayer2との連携機能



MC/DC計測のためにはコード挿入が必須

■ 実コードそのままの状態では複合条件式の評価は不可能– MC/DCが評価対象とするのは複合条件式内の各条件式の実行論理

– 原理的に、どのようなツールでも、各条件式を個別に評価することはできない

■ MC/DC計測では複合条件式の構造を変更する必要がある– 各条件式を独立して評価できるようにコードの構造を変更する

■ MC/DC計測用のフックコードを挿入した「埋め込みコード」で計測– CasePlayer2により、評価対象の関数から自動生成される

if( ( x>10 && y>20 ) || z>30 )

if(Hook(Hook(x>10) && Hook(y>20) ) || Hook(z>30) )

←元の複合条件式

↑各条件式の論理をHook()関数に送り、Hook()の中で実行状態を記録する構造に変更する

フックコードを挿入



実コード計測と埋め込みコード計測を併用

■ 複合条件計測のためにフックコードを埋め込み MC/DC計測実行

■ MC/DCカバレッジのみ「埋め込みコード」から計測実行結果（期待値比較）は「実コード」から取得し評価– 実行結果は実コードから取得することでテスト品質を保つ

製品に実装するマイコン

実ターゲットコード

単体テスト入出力実行結果を取得

テスト品質が保たれる

MC/DC計測用「埋め込みコード」

実行

MC/DCカバレッジのみ計測

テスト品質を保つ「実コード」単体テスト「メイン」実行ライン

カバレッジ計測のための「サブ」実行ライン

MAIN実行

SUB実行



解析コードを自動埋め込み

←重要！



MC/DCカバレッジ測定方法のポイント

■ 実コードによるテスト品質を維持したまま MC/DCを計測

↓ ↓ ↓

■ テスト実行結果（出力）は「実コード」実行結果から取得– 出力結果はソースに手を加えない「実コード」から取得（従来の標準機能と同じ）

■ MC/DCカバレッジは解析コードを挿入した「埋め込みコード」から取得– MC/DCカバレッジは、複合条件に分離するために、解析コードを挿入して実行

– MC/DC計測用「埋め込みコード」の実行のためにビルドプロジェクトを自動複製

– ※C0、C1カバレッジも、埋め込みコードから取得可能

• 最適化によるコード構造の変化により、実コードではカバレッジ計測ができない場合に適用

■ 「実コード」実行結果と「埋め込みコード」実行結果を比較– MC/DC条件解析コードを追加しても、関数出力値に相違が無いことを確認

– 相違が無いことを持って MC/DCカバレッジ結果の確からしさを検証



実コードビルド MCDC計測専用ビルド

MC/DCカバレッジ測定機能：詳細処理フロー

■ 「実コード」と「埋め込みコード」を並列実行– MCDC計測には、複合条件式を分解する解析コードを自動挿入し実行

– 入出力テスト、期待値評価には」、製品実装と同じ「実コード」から取得

評価対象のソースコード

MC/DC計測用コードを追加したソースコード

MC/DC計測コード自動挿入

機能

クロスコンパイラ

製品搭載実機コード

カバレッジ取得のための実行コード

入力テストデータ

if( ( x>10 && y>20 ) || z>30 )

011000101010

011000101010

WinAMS_SPMC_C0();if((WinAMS_SPMC_C1("func_mcdc_01",3),WinAMS_SPMC_Clr(),….


単体テスト実行

クロスコンパイラ


単体テスト実行

実行結果取得MC/DC取得コードからの期待値

一致することを確認

C0カバレッジ取得

MCDC（C1)カバレッジ取得

※C1計測とMCDC計測を同時使用する場合は、C1カバレッジ計測は、計測用に変更したコードから計測されます。

MAIN実行

SUB実行

製品実装時と同じ最適化オプションを使用可能

MC/DC計測用コードを正しく実行するために、最適化をOFFにすることを推奨

CasePlayer2が実行

※C0計測も埋め込みコードで計測可能



MC/DCカバレッジ測定機能：解析コード挿入

■ 各条件式を「フック関数」に送るコードに変更（コード挿入イメージ）

//

int func_01( int x, int y, int z )

{

/* 複合条件設定 */

if( ( x>10 && y>20 ) || z>30 )

{

gb_result.data = x+y-z;

gb_result.ret_code = TRUE;

return TRUE; // 条件TRUEの時、TRUEを返す}

else

{

gb_result.data = z+y-x;

gb_result.ret_code = FALSE;

return FALSE; // 条件FALSEの時、FALSEを返す}

}

// int HOOKED_func_01( int x, int y, int z )

{

/* カバレッジ条件式 Hook Routine 挿入 */

if( Hk_Cr(), Hk_R(Hk_E(x>10) && Hk_E(y>20) ) || Hk_E(z>30) )

{

Hk_C1cvr(1); // 実行マーキングフックコードgb_result.data = x+y-z;

gb_result.ret_code = TRUE;

return TRUE; // 条件TRUEの時、TRUEを返す}

else

{

Hk_C1cvr(0); // 実行マーキングフックコードgb_result.data = z+y-x;

gb_result.ret_code = FALSE;

return FALSE; // 条件FALSEの時、FALSEを返す}

}

int Hk_Cr( void )

{

// フックの情報クリア}

int Hk_C1cvr( int path_no )

{

// 実行マーキング}

int Hk_E( int condition )

{ // MCDC用論理式の評価return condition;

}

int Hk_R( int condition )

{ // 論理式の判定return condition;

}

コード挿入

ツールのカバレッジ計測のためのフック関数

MC/DCカバレッジ評価を行う対象関数カバレッジ計測のために自動生成されたフック関数挿入後の関数

各条件式を別々に実行



C0、C1、MC/DCカバレッジ表示

C0カバレッジ（各行の実行回数）

C1カバレッジ（実行分岐数）

実行回数が0

→C0カバレッジがNG

switch文のcase3が実行されていない→C1カバレッジNG

C0、C1カバレッジ（実機コードから取得）

MCDCカバレッジ結果（フックコード付きから取得）

表示切替

MCDCカバレッジ（t=TRUE f=FALSE）

※最後の'gb_c>30' の条件文のFALSE

ケースが実行されていないことを示す



対象関数の入出力変数の自動抽出機能（標準機能）



対象関数の入出力変数の自動抽出機能

■ 評価対象の関数が使用（参照/代入）している外部変数を自動抽出

■ 入力/出力条件を自動検索しコード解析工数を省力化

入出力変数リスト評価対象の関数を指定すると

自動表示される

リストアップされた変数から評価に必要な変数を

ユーザーが選択・指定

関数が参照している外部変数

（単体テストの入力変数）

関数が書き換えている外部変数

（単体テストの評価変数）

関数の引数リスト（単体テストの入力変数）



ブラック/ホワイトボックステストデータ作成支援・自動生成機能

（標準機能）

～テストデータ分析エディタ～



単体テスト設計の課題

■ 要求仕様を確認するテスト（ブラックボックス）設計の工数が大きい• 要求仕様書を読み解き、関数に対するテストケースを抽出する必要がある

• テスト設計の自動化が難しく、基本的に手作業ベースの確認が多い

要求仕様の確認、境界値分析、同値クラス分析

エクセルベースの煩雑な作業が多くなる

■ 機能安全認証への対応• 機能安全認証に対応したテストエビデンス、レポート作成が要求される

ISO 26262-6: 9 Software unit testing

Table.10、11、12

■テストデータ設計を標準化するプロセス作り• V字開発プロセスに対応した単体テスト設計のワークフローを構築する必要

• 開発者個人に依存しない標準的なテスト設計プロセスを確立する必要



単体テスト設計プロセスをツール機能に実装

■ ガイオ単体テスト受託サービスの手法、ノウハウをツールに実装• 単体テストの品質向上と、テスト設計の平準化、標準化、効率化を図る機能

• 独自の分析表により、テスト設計のレビュー、クロスチェックを容易にする

入力データ分析表出力データ分析表テストケース表

ユニットテストデータ分析機能

カバレッジマスター用

CSVファイル出力

テスト設計のレビュー、

クロスチェックが容易

要求仕様の確認に必要な

単体テスト入力条件を分析/設定/レビュー

要求仕様の確認に必要な

単体テスト出力値を分析/設定/レビュー

入力データ分析表から生成したテストケース

（期待値を設定）

設計したテストが十分かどうかを評価生成した組合せが十分かを評価

組合せ生成



ユニットテストデータ分析機能

■ 入力データ分析表を短時間で効率的に作成• 最も工数のかかるテストデータ設計用の分析表をツール機能で自動作成

• 静的解析機能により、コード構造に基づいた「テスト項目」を自動作成

• コード構造と要求仕様を照らし合わせながら効率的に仕様確認/テスト設計

■ テスト設計の粒度を標準化するための設計ルールを指定可能• 境界値、最大/最小値、同値分割による代表値などを漏れなく設定

テストデータ分析エディタ

要求仕様書

func(){

}

コード構造を自動解析しテスト項目の枠組み

を自動設定

要求仕様とコード構造の対応を確認し

テストデータを設定

コード構造情報

ユーザー

テスト対象関数

組合せ生成

要求仕様とコード構造が確認されたテストケース



入力データ分析表

単体テスト設計、レビューを容易にするためのデータ設計一覧表• 入出力変数、型、最大/最小値など、各変数に与えるデータを一覧

• 選択したテスト入力変数を表の横列に自動配置

ソースの静的解析により、テストデータの候補を自動生成境界条件に基づいた「境界値、境界値±１」、「変数型の最大/最小値」、特異値（0、-1）など

入力テスト分析表

テスト設計ルールに基づき、デフォルトで作成するデータの種類を設定

単体テスト入力条件/変数

ソースの静的解析により

自動取得

ソースコード上で検出した付与値



コード構造に基づいた「テスト分析項目」

■ ソースコードを構造解析し、「テスト分析項目」を自動設定• 境界条件が抽出できる場合は境界値、変数の型に応じた最大値/最小値を自動設定

• フローチャートの構造上のテスト項目と入力テストデータ分析表が連携

入力データ分析表フローチャート

入力変数

テスト項目

コード構造



（参考）テスト分析項目抽出のモード切替

■ 分岐条件＋分岐中の処理ブロックに対して抽出• 各処理ブロック中の演算などを含めたテスト設計向き

■ 分岐条件のみに着目して抽出• コードカバレッジを網羅する視点のみのテスト設計向き

分岐条件のみ分岐条件＋分岐中の処理ブロック

テスト項目

テスト項目



要求仕様をコード構造に当てはめながら確認

要求仕様項目とコード構造を照らし合わせながら確認• 要求仕様に対応するコード構造が実装されているか？ →無ければコード実装不足？

• 要求仕様に存在しないコード構造がないか？ →有れば不要コード/デッドコード？

テストデータ分析表の「テスト分析項目」に要求仕様情報を追記• 要求仕様内容の記載が可能

• トレーサビリティのための要求仕様項番を記載可能

トレーサビリティのための要求仕様項番

要求仕様内容の記載

デフォルトではソースの抜粋が自動入力される



入力データ分析表からテストケースを組合せ生成

「入力テスト分析」と「組み合わせルール」からテストケースを自動生成• 入力テスト分析表のテスト付与値を用いて組み合わせを生成

• テスト付与値属性を色分けし、レビューを効率化

組み合わせの方法（ルール）を細かく指定可能


テストケース表

組み合わせ生成



組み合わせのルールをプリセット

■ テストデータ属性を指定して組み合わせ方法を細かく設定• 全数組み合わせ生成

（例）最大値/最小値は全数組み合わせ ← 2変数の演算のオーバーフローテスト

（例）境界値/境界値±１は全数組み合わせ ← 分岐条件の網羅テスト

• 少なくとも1つはテストケースに出現するように生成．．．等

テスト付与値の組み合わせを設定する画面



分岐のネスト条件を自動管理

■ 意図した処理ブロックへ到達するための条件を管理、自動で組み合わせ• 煩わしい条件の確認、組み合わせ設計を省力化し、ミスを削減

自動生成

分岐条件のテストデータを自動組み合わせ


テストケース表

ブロックをテストするための変数値



出力データ分析表による期待値設計確認

■ テストする必要のある出力値が期待値に含まれるかを確認• テスト要因として確認する必要のある期待値を「出力データ分析表」に指定

• 関数要求仕様に基づき入力された期待値が「出力データ分析表」を網羅しているかを確認

網羅していない場合は、テスト項目が足りないことを示す

※この期待値設計確認は、テスト設計精度を高めたい場合に適用（必須項目ではない）

期待値（出力値）に入力されていない出力がある場合には、太字で表示

テスト要因として確認する必要のある期待値を

「出力データ分析表」に設定



テスト設計内容をHTML/XLSに出力

■ 入力テスト分析表、出力テスト分析表、テストケース表を出力

■ HTML、XLS（エクセル）のファイルで出力• 帳票（オフライン）でテスト設計レビューが可能

• エディタと同じイメージ、色の表を生成 ※XLSは、次回バージョンアップでサポート予定



テスト設計の漏れをHTML出力で確認

■ 入力変数と出力変数をまとめた入出力分析表をHTML出力• 入力変数の付与値、出力変数に設定した期待値の漏れを一覧で確認可能



C1、MC/DC 計測用テストケース自動生成機能（標準機能）



C1カバレッジデータを自動生成

■ 解析結果から C1カバレッジを満たす入力データを自動生成– 関数内の条件文をリストアップして、各条件文のTRUE/FALSEケースを自動生成

// C1説明用サンプルint gb_a, gb_b, gb_c, gb_d, gb_out;char gb_unused1, gb_unused12;

int func_c1_01( int code ){

int return_value=FALSE;

if( gb_a > 10 ){

if( gb_b > 20 && gb_c > 30 ){

gb_out = 0;}else{

gb_out = -1;}return_value = FALSE;

}else{

switch( code ){

case 1:gb_out = 1;break;



default:gb_out = -1;break;

}return_value = FALSE;

}return return_value;

}

各々の条件文の TRUE/FALSE の各ケースを満たすために必要な変数を自動設定する

C1カバレッジモードでの条件文解析結果



最少数のC1組み合わせデータを生成

■ 条件文を解析して C1を満たす最少数のデータを生成– 各条件文（if,switchなど）に対して生成したデータの組み合わせを自動生成

– C0/C1の観点から、同じ分岐経路を通るデータ、同じ分岐条件は、重複生成しない

– 必要最小限のデータ組み合わせを生成

■ 最小限の期待値評価工数で C1を指針とした単体テストが可能– 実行結果は、関数仕様を基に設定した期待値と比較評価する必要がある

C1のカバレッジを満たす入力データを自動生成

ここは期待値

実行結果の評価は、関数の詳細仕様を基に

必ず行わなければならない

↓

必ず発生する工数



C1生成データが評価する条件式を表示

■ CSVファイルに生成したデータと評価する条件式を表示– 生成されたテストベクターが何を評価しているのかを明示



MCDCカバレッジデータも自動生成

■ MCDCデータ作成のために複合条件文に含まれる条件式を解析– 条件文をリストアップして、各条件文のTRUE/FALSEケースを自動生成

// MCDC説明用サンプル

int func_mcdc_01( int x, int y, int z )

{

//

if( ( x>10 && y>20 ) || z>30 )

{

return TRUE;

}

else

{

return FALSE;

}

return FALSE;

}

(1) (2) (3)

MCDCカバレッジモードでの複合条件文解析結果

各々の条件文の TRUE/FALSE の各ケースを満たすために必要な変数を自動設定する



MCDC指針のデータを自動抽出

■ 複合条件を解析して MCDCカバレッジを満たす入力データを自動生成– MCDCの指針に従い、全条件組み合わせ（All-Pair）からMCDCデータを自動抽出

条件式 (1) F F F F T T T T

条件式 (2) F F T T F F T T

条件式 (3) F T F T F T F T

If 全体論理 F T F T F T T T

条件式のTRUE/FALSEの全組み合わせから MCDCデータを抽出

if( ( x>10 && y>20 ) || z>30 )

(1) (2) (3)

(3)

(1)

(2)(1)

(2)

(3)

複合条件例MCDCのカバレッジを満たす入力データを自動生成

(3)

(1)

(2)

＜MCDCのデータ抽出指針＞他の条件式の真偽を固定して、１つの条件式の真偽を変化させたとき、全体の条件に変化があるものだけを実行する



MCDC生成データが評価する論理条件を表示

■ CSVファイルに生成したデータと評価する論理条件を表示– 生成されたテストベクターが何を評価しているのかを明示



生成データの編集も自由に可能

■ 解析情報より自動生成されるデータの追加削除も自由に可能– テスト指針に従って、境界値近傍のデータ、特異点データなどを追加

– 自動生成するデータの属性（種類）も設定可能

生成されるデータを編集可能

自動生成するデータのデフォルトでの種類（属性）

も選択可能



ソース解析に役立つチャートリンク機能

■ CasePlayer2が生成した各種チャート、変数参照リストへリンク– 面倒な設定やソースコードの修正追加なしで簡単にチャートを生成

– 入出力データ作成時のロジック解析、パス解析を効率化

カバレッジマスターの変数設定画面

CasePlayer2のソースコード表示

CasePlayer2のフローチャート表示

リンク



フローチャート連動

■ フローチャートC0・C1カバレッジ表示– テスト実行パスをフローチャート上に表示して、ビジュアルに判断可能



テスト作業をより効率化する「加速オプション」（オプション機能）




加速オプションとは

■ 構造カバレッジ（C1、MC/DC）計測を完全自動化するオプション− 関数を選択するだけで、テスト設計からカバレッジ結果出力までを自動化

− 単体テストの工数となる作業を自動化

• CSV形式のテストファイルフォーマットを自動作成

• 関数の入出力変数を自動抽出、自動設定

• 構造カバレッジを満たす C1、MC/DCテストデータ自動生成

• 単体テストの自動実行（入出力テスト、カバレッジ計測）

テスト対象関数を選択

関数入出力変数の自動設定

テストファイル自動作成

構造カバレッジテストC1、MC/DCテストデータ

自動生成

単体テストの自動実行と結果出力

＜自動化される工程＞

関数を選ぶだけで直ぐに構造カバレッジ結果が見られます！



加速オプションの利用手順

■ テスト自動化の設定• 自動抽出された入力変数に対する初期値

• 生成するカバレッジデータの選択（C1 or MC/DC）

• スタブ関数の使用切り替え（使用/不使用）

■ テスト対象関数の選択• リストから対象関数を選択（Ctrlキーで複数選択可能）

■ テスト自動化オプションの選択• どの工程までを自動で行うかを選択可能



（参考）加速オプション利用時の注意点

■ 仕様ベーステストは別途行う必要がある- 本機能は、ソースコードを起点とするホワイトボックス観点の「構造ベーステスト」のみ

■ 必要な準備：スタブ関数の事前作成− 関数のテストに必要なスタブ関数は、事前に作成しておく必要があります。

• スタブ関数の雛形作成

• スタブ関数へのコード追加、編集

• スタブ関数の追加ビルド＆リンク

■ カバレッジ未達の場合のテストデータ追加編集− 自動実行結果でカバレッジ未達の場合は、出力されたテストデータを調整し、

再テスト（従来の手動操作）を行う必要があります

スタブ付きオブジェク

ト

スタブ関数選択・作成

スタブ関数編集

スタブ関数追加ビルド

SSTManagerスタブ設定ビュー

ご利用の開発環境ご利用の開発環境またはSSTManager内蔵簡易エディタ

テストデータ追加編集



結合テストに向けた関数/コールカバレッジ計測機能

（オプション機能）



結合テストの領域をカバー

■ 結合テストでの構造カバレッジ計測機能をサポート（V3.6以降）関数カバレッジ計測

• ユーザーが指定した機能コンポーネント内の関数が全てコールされたかを計測

コールカバレッジ計測

• ユーザーが指定した関数からの関数コールが全て行われたかを計測

※ご利用にはオプションライセンスが必要です

ソフトウエア要求分析

ソフトウエア構造設計

ソフトウエアユニット設計

ソフトウエア単体テスト

ソフトウエア結合テスト

システムテスト

実装

設計検証

カバレッジマスター単体テスト機能

C0、C1、MC/DCカバレッジ計測

CasePlayer2（MISRA-Cチェック）

カバレッジマスター結合テスト機能関数、コールカバレッジ計測

V3.6にて追加



（参考）ISO 26262 結合レベルでのテストの目的

■ 結合レベルでのテストの目的ソフトウエアエレメントを統合すること。

組込みソフトウエアによって、ソフトウエアの構造が実現されているかを実証すること。

ISO 26262 Part.6-10 Software integration and testing

10.1 Objectives

The first objective of this sub-phase is to integrate the software elements. The second objective of this sub-phase is to demonstrate that the software architectural design is realized by the embedded software.

ソフトウエアエレメント間の個々の結合レベルとインタフェースを、ソフトウエアの構造上の設計に対してテストする。ソフトウエアエレメントの統合とテストは、ソフトウエアの階層構造に直接対応する。

10.2 General

In this sub-phase, the particular integration levels and the interfaces between the software elements are tested against the software architectural design. The steps of the integration and testing of the software elements correspond directly to the hierarchical architecture of the software.



（参考） ISO 26262 要求/推奨事項

■ 結合レベルでのテストに対する要求/推奨事項ソフトウエア結合の計画は、個々のソフトウエアユニットを階層化してソフトウエアコンポーネン

トに結合し、組み込みソフトが十分に結合されるようにする

a)この時、ソフトウエア結合に関連する機能的な依存性を考慮する必要がある

b)また、ソフトウエア結合と、ハード/ソフトの結合の間の依存性を考慮する必要がある10.4.1 The planning of the software integration shall describe the steps for integrating the

individual software units hierarchically into software components until the embedded software is fully integrated, and shall consider:

a) the functional dependencies that are relevant for software integration; and

b) the dependencies between the software integration and the hardware-software integration.



（参考） ISO 26262 結合テスト構造カバレッジ

■ 結合レベルにおける構造カバレッジの計測が要求されているISO 26262 Part6. 10 に定義

10.4.6 This subclause applies to ASIL (A), (B), C and D, in accordance with 4.3: To evaluate thecompleteness of test cases and to obtain confidence that there is no unintended functionality, the structural coverage shall be measured in accordance with the metrics listed in Table 15. If the achieved structural coverage is considered insufficient, either additional test cases shall be specified or a rationale shall be provided.

テストケースが十分であるかを評価し、意図しない機能が実装されていないことを確認するために、表15のメトリクスに従って構造カバレッジを計測する必要がある。

もしも、カバレッジが100%にならない場合は、テストケースを追加するか、未達に対する論理的な根拠を示す必要がある。

■ 関数カバレッジ / コールカバレッジの計測が要求されている結合レベルでの関数呼び出しの構造カバレッジを取得する必要がある



関数/コールカバレッジ計測機能概要

■ 単体テストの延長線上で結合状態のテストが可能操作方法やテストデータ（CSV）のフォーマット作成方法は単体テストと同様

スタブをOFFにした結合状態で、機能モジュールの上位関数をテスト駆動

コールカバレッジの計測には、埋め込みコード（MC/DC計測と同じ方法）が必要

■ ISO 26262の関数/コールカバレッジのエビデンスを効率的に作成 Function/Callカバレッジの測定結果の一覧を自動作成

関数一覧、コール位置の一覧を自動出力

結果出力にはHTML/CSVのフォーマットをサポート

■ 関数/コールカバレッジ計測機能は、カバレッジマスターwinAMS/ゼネラル V3.6 の追加オプション機能機能安全ツール認証（TÜV SÜD）は2013/06取得済み

本機能を含めたリファレンスワークフロー（安全マニュアル）を提供



カバレッジマスター：関数カバレッジ計測

■ 関数カバレッジ（Function coverage）ユーザーが指定した機能コンポーネント内の全ての関数が「実行されたか」を計測

＜計測範囲の関数選択＞

機能コンポーネント単位に機能を構成する関数を含む「ソースファイル」を選択

［機能コンポーネント］→［ソースファイル］→［関数ユニット］で階層化が必要

＜計測方法＞

機能コンポーネントの最上位関数にテストケースを与えて関数実行

選択したソースファイル内の関数が網羅されて呼び出されたかを計測

＜計測結果＞

計測対象の関数がコールされたかを表示

選択したソースファイルごとに、関数数を元に網羅率を計測

赤：実行関数黒：未実行関数

source_3.c

source_2.csource_1.c

上位関数

func1

func6

func2 func3

func7

func4 func5 func8 func9

選択した機能コンポーネント

source_1.c : 関数カバレッジ＝4/6 → 66%source_2.c : 関数カバレッジ＝0/2 → 0%source_3.c : 関数カバレッジ＝1/2 → 50%

機能コンポーネントの関数カバレッジ＝ 5/10 → 50%



■ コールカバレッジ（Call coverage）ユーザーが指定した関数からの全ての「関数コールが行われたか」を計測

＜計測範囲の関数選択＞

機能コンポーネント単位に機能を構成する関数を含む「ソースファイル」を選択

［機能コンポーネント］→［ソースファイル］→［関数ユニット］で階層化が必要

＜計測方法＞

機能コンポーネントの最上位関数にテストケースを与えて関数実行

各関数の関数コールが行われたかを計測

＜計測結果＞

各関数からのコール位置を表示

実行されたコール位置を○で表示

各関数の「コール数」を基に網羅率を計測

カバレッジマスター：コールカバレッジ計測

source1.c

TestFunc1 : コールカバレッジ＝2/3 → 66%

TestFunc1(){

if( val == 0)

{

SubFunc1(); OK

}

else

{

SubFunc2(); OK

：：

if(ctl) SubFunc2(); NG

}

}

TestFunc1()

SubFunc1

SubFunc2

OK

OKNG



関数/関数コールカバレッジ測定結果：標準形式

■ 関数/関数コールカバレッジ結果をソースファイル単位で表出力（HTML）標準形式では、関数コール位置を省いた結果をコンパクトに出力

選択したソースファイル単位で出力

■ CSVファイルへの出力も可能標準形式

ソースファイルにある関数のうち、何個の関数が実行されたか

ソースファイルにある関数からの関数コールのうち、何個の関数コールが行われたか

ソースファイルにある関数名と、実行状態

各関数からの関数コールのうち、何個の関数コールが行われ

たか



関数/関数コールカバレッジ測定結果：詳細形式

■ 関数/関数コールカバレッジ結果を詳細形式で出力（HTML）詳細形式では、関数毎の関数コール位置と実行状態を追加表示

選択したソースファイル単位で出力

■ CSVファイルへの出力も可能詳細形式

各関数からの関数コール位置（行番号）と、そのコールが行

われたかを示す



関数/コールカバレッジの計測範囲の選択

■ 機能コンポーネントを構成する関数を含む「ソースファイル」を選択個々の関数単位で選択することはできない

ソースファイル単位に同じコンポーネントの関数が管理されていることが必要



関数/関数コールカバレッジビュー

■ 関数コール文の下に実行状態を表示[call (回数)] (関数名)

→ コールされた関数

[ nocall ] (関数名)

→コールされていない関数（未実行）



サブ関数を含めたテストデータ生成機能

■ コンポーネント最上位関数から呼ばれるサブ関数の構造を解析

■ サブ関数の網羅を含めたテストケースを生成• 解析対象関数は、サブ関数（1階層下）まで

＜データ作成オプション＞

• サブ関数も対象にする：

• 条件リストにサブ関数コールの項目を表示

• サブ関数の全ての条件文に関して自動抽出したテストベクタを設定



（参考）結合テストの手法

■ 結合テストの一般的な手法• ビッグバン結合テスト（Big-bang Integration Testing）

機能の最上位関数にテストケースを与えて駆動し、全ての関数が動作することを一度に確認

• インクリメンタル結合テスト（Incremental Integration Testing ）

結合を数階層に抑えて、部分的に結合確認したものをつなぎ合わせて、全体の結合を確認

※単体テストの延長上で、インクリメンタルに結合状態を確認する方法が現実的と思われる

駆動関数

BIGCSV

駆動関数A

sub1 sub2

sub3 sub4

sub5

sub6

駆動関数B

駆動関数C

ACSV

BCSV

CCSV

ビッグバン結合テストインクリメンタル結合テスト

関数Aを駆動（A.csv）：sub1()、sub2()

関数B、関数C の実行を確認

関数Bを駆動（B.csv）：sub3() の実行を確認

関数Cを駆動（C.csv）：sub4() 、sub5()、sub6() の実行を確認

最上位関数Aからの結合状態が確認できる

一斉に全ての関数実行を確認



（参考）単体テストと結合テストの違い

■ コールカバレッジは単体テストのC0カバレッジと何が違うのか単体テスト: 関数単体の機能、構造についてのテスト

• サブ関数SubFunc()はスタブ化される

• 戻り値retの分岐条件はCSVから直接与える

• C0カバレッジのテストは容易に可能

C0を満たせば、全てのコール位置は実行されるのでコールカバレッジはOKと考えて良いのか？

結合テスト：サブ関数を含めた結合状態でのテスト

• 戻り値retは実際のSubFunc()から値が適用される

• SubFunc()に与える引数によって戻り値が決まる

• 例えばSubFunc()がFALSEの論理値を返さない関数だった場合、 SubFunc_B（）はコールされない

• ↑ SubFunc_B()は関数の結合では、つながっていない（結合されていない）ことになる

TestFunc2(){

ret = SubFunc();

if(ret)

{

SubFunc_A()；}

else

{

SubFunc_B();

}

}

C0カバレッジは結合された状態でのテストではないC0カバレッジとコールカバレッジは同じではない

テスト対象関数の例

FAQ



（参考）関数カバレッジ計測でのスタブ関数について

■ 関数カバレッジ計測対象外のドライバ関数、標準関数などをスタブ化

■ 結合レベルで動作の障害となる関数をスタブ化

source_3.c

source_2.csource_1.c

上位関数

func1

func6

func2 func3

func7

func4 func5 func8 func9

機能コンポーネント内の構造

ドライバ関数ドライバ関数標準関数1

機能コンポーネント外のスタブ化対象



「関数/コールカバレッジ」機能デモ



デモサンプルソースコード

// コンポーネント最上位void fc_cover_test( void )

{

if( ctl_fct == 0 )

{

sub_func1();

}

else

{

sub_func6();

}

}

void sub_func1( void )

{

if( ctl_sf1 == 0 )

{

sub_func2();

sub_func3();

}

else

{

sub_func3();

}

}


{

if( ctl_sf2 == 0 )

{

sub_func4();

}

else if( ctl_sf2 == 1 )

{

sub_func5();

}

else

{

sub_func8();

}

}


{

temp_val = 3;

}


{

temp_val = 4;

}


{

temp_val = 5;

}


{

if( ctl_sf6 == 0 )

{

sub_func7();

}

else

{

temp_val = 6;

}

}


{

if( ctl_sf7 == 0 )

{

sub_func8();

}

else

{

sub_func8();

sub_func9();

}

}


{

temp_val = 8;

}


{

temp_val = 9;

}

source_1.c source_2.c source_3.c



デモサンプル構造

■ デモサンプルのモジュール（関数）構造２つの部分に分けて、別々のCSVファイルでテストデータを設定

機能コンポーネント上位関数

0

1

0

0,1

0

1

2

0 0

0,1

ctl_sf1ctl_sf2

ctl_fct

ctl_sf6

ctl_sf7

CSV1

CSV2



デモサンプルテストケース

■ source_1.c の範囲の関数を網羅するテストケース

■ source_2.c、source_3.c の関数を網羅するテストケース

source_1.c内の機能

に関連する変数のみを設定

ctl_fct

ctl_sf1

ctl_sf2

source_2.c、source_3.c

内の機能に関連する変数のみを設定

ctl_fct

ctl_sf6

ctl_sf7

CSV1

CSV2



デモサンプル実行結果例１

■ source_1.c の範囲の関数を実行



デモサンプル実行結果例２

■ source_2.c、source_3.c の関数を実行



デモサンプル実行結果例３

■ ２つのCSVファイルですべての関数を網羅テスト（インクリメンタル結合）



デモサンプル実行結果カバレッジビュー

■ ソース上のどの関数がコールされているかを表示



CLI（Command Line Interface）機能（オプション機能）



単体テスト実行の課題

■ UI操作を必要とするツールでは自動化が困難• テスト作業に人が介在してしまうとテスト効率を上げることが困難

• レグレッションテスト等の決まった作業の繰り返しを効率化、自動化したい

• 他のツール（クロスコンパイラ）を使用する工程も含めて自動化したい

機能安全対応のトレーサビリティのためのテストリソース管理が必要• 要求仕様に対応したテストリソースをツールで管理する必要がある

• 管理するテストリソース（テストプロジェクトファイル）を最小限にしたい

• ALM系ツール、構成管理ツール、テスト駆動ツールとの親和性

スクリプトベースのツール実行機能が要求される



CLI機能とは

■ CLI（=Command Line Interface）Windows コマンドプロンプト上でのコマンド実行機能

■ Windows標準のバッチファイル記述によりツールを駆動、設定変更UI（ウインドウ操作）を必要としないツール操作が可能

テスト/解析プロジェクトの作成、機能設定、実行の一連の作業をバッチ化可能

Windows標準のバッチファイル



カバレッジマスターバッチ実行機能

■ 従来（カバレッジマスターV3.6.2）の「バッチ実行」標準機能• カバレッジマスター既存プロジェクトの「実行」機能はサポート済み

CSVファイルを指定してテスト実行

• CasePlayer2 既存プロジェクトの「解析（仕様書生成）機能」はサポート済み

プロジェクトファイルを指定して解析実行、仕様書生成

WORD、HTML帳票変換出力

■ 本アップデート（V3.7）で追加された「CLI機能」• プロジェクトの設定をコマンドによりサポート

プロジェクト作成及び基本設定のインポート

CPU及びコンパイラの設定変更

設定変更

OMFコンバータ、ターゲットオブジェクトファイル、スタートアップコマンドファイル

MC/DC測定用オブジェクトファイル ... 等ほぼ全ての設定項目

共通スタブの設定

CLI機能追加によりテスト工程の自動化を実現



UI/CLIの使い分けと運用方法

■ 従来のカバレッジマスターＵＩによるテスト設計、テストケース確認テストCSV雛形（フォーマット）作成

テストケースの設計、テスト実行確認（カバレッジ確認）

テストケース、スタブ関数などテストリソースをサーバーにチェックイン

■ バッチファイルよるテスト自動実行（レグレッションテスト、再実行）テスト実行時にソースコード、テストリソースをサーバーからチェックアウト

ターゲットコードのビルド

MC/DC測定用埋め込みコード生成、ビルド

テストCSVファイルを指定してテスト実行

テストケース、スタブ関数などテストリソース

> sstmanager

テスト結果、カバレッジ結果

ＣＬＩによるバッチテスト自動実行

各テスト設計者テスト設計者テスト管理者

CLI機能カバレッジマスターＵＩ

テスト設計テストケース確認

ソース修正/マイコン変更に伴う自動テスト新規関数のテスト設計



既存プロジェクトの設定情報を使用して新規作成

■ カバレッジマスター、CasePlayer2 の既存プロジェクト設定を有効利用既存プロジェクトからエクスポートした設定情報をベースにプロジェクト生成

全ての設定をCLIで行う必要はなく、既存の設定を引き継ぎ可能

変更/追加したい設定箇所のみを、CLIコマンドを使用して書き換え

※ゼロから（既存プロジェクトなし）テストプロジェクトを生成する事は不可能

AmsProjSave.amso

カバレッジマスター

CasePlayer2

CP2Project.vopt

設定情報ファイル

設定情報ファイル

エクスポート

エクスポート

新規CasePlyer2

プロジェクト作成

> sstmanager

CLIコマンドでプロジェクトを作成/変更

テスト/解析実行

新規カバレッジマスタープロジェクト作成

CLIコマンド

CLIコマンド

CLIコマンド



カバレッジマスターコマンド

■ プロジェクト作成及び基本設定のインポート設定情報ファイルから新規プロジェクトフォルダを作成

■ MPU及びコンパイラの設定変更

■ 各種設定変更OMFコンバータ、オブジェクトファイル、初期設定終了アドレス、等

設定ファイル（別途作成テキスト形式）をロード

■ オブジェクトの部分的ロード（シンボル情報読み込みソースファイル選択）

■ 関数・関数コールカバレッジ・関数テスト履歴一覧の集計対象の設定

■ 共通スタブの設定

■ バッチ自動実行



CasePlayer2コマンド

■ プロジェクト作成及び基本設定のインポート設定情報ファイルから新規プロジェクトフォルダを作成

■ MPU及びコンパイラの設定変更Cオプションパラメータファイルをインポート（コンパイラ方言の解析設定）

■ 各種設定変更設定ファイル（別途作成テキスト形式）をロード

■ プリプロセッサ設定変更

■ ソース登録変更

■ 定義のない関数、変数の定義を生成

■ カバレッジ測定用コードの設定/埋め込み生成

■ 仕様書生成及びMISRA-C解析

■ Word及びHTML生成



コンパイル作業を含めた自動化例

■ カバレッジマスターでのテスト実行に必要な一連の作業を記述• ソースコード変更時の「実コード」コンパイル

• CasePlayer2による「カバレッジ計測用（MC/DC）埋め込みコード生成」＋コンパイル

• OMF変換

「実コード」コンパイル＋

OMF変換「埋め込みコード」コンパイル

＋OMF変換

CasePlayer2によるカバレッジ計測用

埋め込みコード生成

ソースコード修正が発生

カバレッジマスター設定変更（必要な場合）

カバレッジマスター単体テスト実行

rem *** 「実コード」コンパイル ***

call C:¥DEMO_CM_CLI_EXEC¥02.BuildTarget.bat

rem *** 「実コード」OMF変換 ***

sstmanager -obj sample.xlo sample.amsy

rem *** 解析＆CasePlayer2 埋め込みコード生成 ***

call C:¥DEMO_CM_CLI_EXEC¥01.Cp2Test.bat

rem *** 「埋め込みコード」コンパイル ***

call C:¥DEMO_CM_CLI_EXEC¥03.BuildMcdcCode.bat

rem *** 「埋め込みコード」OMF変換 ***

sstmanager -obj sample_mcdc.xlo sample.amsy

rem *** カバレッジマスター設定変更＆テスト実行 ***

call C:¥DEMO_CM_CLI_EXEC¥04.RunUnitTest.bat

テストに必要な一連の作業を記述したバッチファイル例：



（参考）カバレッジマスターCLIコマンド仕様

■ （準備）既存プロジェクトからエクスポートした設定情報ファイルを用意UIで作成した既存のプロジェクト設定情報をファイルに出力

テストを再現するためには、このファイルだけを管理すれば良い

■ エクスポートした設定情報ファイルから新規にプロジェクトを作成テスト作業に使用するカバレッジマスタープロジェクト（フォルダ一式）を生成

■ プロジェクト設定（*.amsy）をコマンド（CLI）で書き換え変更エクスポートしたプロジェクト設定で変更が必要な箇所を書き換え

例：ターゲットオブジェクトファイルを指定

■ CSVファイルを指定して単体テストを実行

sstmanager.exe -crtprojimport [設定情報ファイルパス] [新規作成プロジェクトフォルダパス]

例：AmsProjSave.amso

sstmanager.exe -obj [オブジェクトファイルパス] [プロジェクトファイル *.amsy]

sstmanager.exe -b -testCsv [CSVファイルパス] [プロジェクトファイル *.amsy]



（参考）CasePlayer2 CLIコマンド仕様

■ （準備）既存プロジェクトからエクスポートした設定情報ファイルを用意UIで作成した既存のプロジェクト設定情報をファイルに出力

テストを再現するためには、このファイルだけを管理すれば良い

■ エクスポートした設定情報ファイルから新規にプロジェクトを作成テスト作業に使用するカバレッジマスタープロジェクト（フォルダ一式）を生成

■ プロジェクト設定（*.amsy）をコマンド（CLI）で書き換え変更エクスポートしたプロジェクト設定で変更が必要な箇所を書き換え

例：プロジェクトにソースファイルを登録

■ プロジェクトを解析 / 「全仕様書生成」実行

例：CP2Project.vopt

CaseViewer.exe -crtprojimport [設定情報ファイルパス] [CasePlayer2の新規プロジェクトフォルダパス]

CaseViewer.exe -a [ソースパス指定ファイル] [プロジェクトファイル *.vproj]

CaseViewer.exe -R [プロジェクトファイル *.vproj]



（参考）カバレッジマスターCLIコマンド例(続)

■ バッチファイル作成例設定情報ファイルを基に新規プロジェクト作成

オブジェクトファイルを指定

CSVファイル（４ファイル）を指定してテスト実行

rem ------ ディレクトリ -----

set SETTINGS= "C:¥DEMO_CM_CLI_EXEC¥Settings"

set CM_WORK= "C:¥DEMO_CM_CLI_EXEC¥winAMS_CLI"

set TARGET= "C:¥DEMO_CM_CLI_EXEC¥winAMS_PRJ¥target"

set MCDC_TARGET= "C:¥DEMO_CM_CLI_EXEC¥winAMS_PRJ¥target_mcdc"

set CSVFILE= "C:¥DEMO_CM_CLI_EXEC¥CSV_TestData"

rem ----------------------- プロジェクト作成 -----------------------

del /Q %CM_WORK%¥*.*

sstmanager -crtprojimport %SETTINGS%¥AmsProjSave.amso %CM_WORK%

rem ----------------------- オブジェクトコード指定 -----------------------

sstmanager -objspmc %TARGET%¥obj¥SAMP1.xlo %CM_WORK%¥winAMS_CLI.amsy

rem ----------------------- CSV テスト実行 --------------------------

sstmanager -b -e -testCsv %CSVFILE%¥func1_data.csv %CM_WORK%¥winAMS_CLI.amsy






（参考）別の設定定義ファイルで定義可能

■ 詳細変更内容は iniファイルの様な別ファイルで定義可能 -set コマンドで、設定定義ファイルの内容を一括設定

sstmanager –set [設定定義ファイル *.txt]

// 設定定義ファイルサンプル

// 基本設定[Base]

UseOMF=0 // OMFコンバータを使用する

// OMFコンバート設定[OMF]

ChangeOption=オプション文字列 // 変換オプション

// 起動設定[System_G]

Cp2Proj=.¥CaseProj¥CaseProj.vproj // CasePlayer2プロジェクトファイルパスStart=.¥SS_STARTUP.com // スタートアップコマンドファイルRunEachCsv=0 // テストCSV毎にシミュレータを再起動:

// カバレッジ測定コード設定-起動設定[SAMPL_System_G]

Start=.¥SS_STARTUP.com // スタートアップコマンドファイル（AllMemAlloc=0 // 全てのメモリ領域をアサインCodeMemAlloc=0 // コードエリアを書き込み禁止とする:

// スタブ設定[STUB]

STB_SRCPATH=ソースファイルパス // スタブ生成ソースファイルパス:

// テスト設定[TEST]

InDir=.¥TestCsv // テストCSV保存先フォルダパス（プロジェクトフォルダからの相対パス）C1Cover=0 // C1カバレッジを測定するMCDCCover=0 // MC/DCを測定するFuncCover=0 // 関数カバレッジを測定するFuncCallCover=0 // 関数コールカバレッジを測定するAutoCovLog=0 // カバレッジログを生成する:

AllMemAlloc=0 // 全てのメモリ領域をアサイン(参照)

CodeMemAlloc=0 // コードエリアを書き込み禁止とする (参照)

TestCaseTable_TF_OK=0 // テストケース表の条件/判定の実測値がT/Fの場合を全てOKにする (参照)

:

// テスト自動化設定[AUTO_TEST]

Out_Set=0 // 出力変数を初期化するOut_Int=0 // 初期値設定(整数)

:

In_Set=1 // 入力値のデフォルト設定を行うIn_Int=0 // 入力値設定（整数）:

// 関数テスト履歴の設定（詳細設定）[Output]

OutputTestHistory=0 // 関数テスト履歴情報を出力するOutputUnexeFuncList=0 //関数テスト履歴一覧に未実行関数リストを出力する。TestHistoryFolder=TestHistory //関数テスト履歴情報の出力フォルダパス（プロジェクトフォルダからの相対パス）:

/



C++コード単体テスト機能（オプション機能）




C++に対応：概要

■ 実コードを使用したC++単体テストに対応– ※ C++コード対応は、オプション機能

■ C++クラス内に定義されたメソッド（関数）の単体テストが可能– テスト対象クラスの構造をツリーに表示

class CClass{public:

CClass(){} // コンストラクタ~CClass(){} // デストラクタ

structST_PARAM m_result;

void func1( int enable, int mode, int input ){/* 処理分岐 */

if( enable ){

switch( mode ) /* 4case */{case 0:

// input代入m_result.data = input;break;

case 1:m_result.data = input * 10; // input * 10 代入break;

：：

}// return codem_result.ret_code = TRUE;

}}void func2( int mode, int *data_in );

};

テスト対象メソッドや初期化に必要なコンストラクタ

をツリーから選択



C++に対応：クラスオブジェクト生成

■ テスト時にクラスの定義からクラスオブジェクトを自動生成可能– テスト時にクラスオブジェクトを自動生成可能

– 静的オブジェクト内の関数（メソッド）を指定してテスト可能

■ 初期化に必要なコンストラクタの実行を選択可能– テスト時にクラスオブジェクトを生成する場合は、コンストラクタの実行選択が可能

• ※静的オブジェクトの場合は、コンストラクタの実行はコンパイラのコード展開に依存

クラスオブジェクトを自動生成

コンストラクタの実行を選択



C++に対応： C0/C1カバレッジ計測

■ メソッドに対する入出力テスト、カバレッジ計測はCコードと同様に可能– ※MC/DCカバレッジ計測（オプション機能）はC++に未対応

C0/C1カバレッジ計測

入出力テスト結果



カバレッジマスターの優位性と導入効果ツール選定のポイント

（参考資料）



単体テストツールの選定ポイント

■ 単体テストツールの比較を行う際には、多くのお客様が以下の様な評価項目を設定しています

項目必要条件

準備工数製品開発ビルド環境をそのまま使えるか？ソース変更は発生しないか？テストドライバ作成の必要があるか？スタブは自動生成可能か

カバレッジ機能 C0、C1、MC/DC、関数、コールカバレッジは計測可能か？カバレッジ計測結果を容易にレポート出力できるか？

精度/信頼性実コードに忠実なテストが可能か？エンディアン/ビットフィールド/アラインメント/ポインタサイズ/シフト演算等

データ資産化 CSVファイルのみでテストデータ管理が可能か？回帰テストが自動化できるか？

データ入力支援構造カバレッジ計測のテストデータは自動生成可能か？生成されるテストデータの冗長性は低いか？

サポート体制開発メーカー直接のサポートが受けられるか？レスポンスは良いか？導入時のレクチャ／セミナーは充実しているか？



他社ツールとの比較とアドバンテージ

■ ツール構成/特長の比較※各社ツールのWEBページ情報を基に作成（作成日：2013年6月）

比較項目カバレッジマスターwinAMS 他社ツール

計測方法マイコンシミュレータ（ISS)で実コードをそのまま実行して単体テスト、カバレッジ測定

PCに接続したターゲットボード上で、関数を駆動するテストドライバを実行し、測定結果をPCへ転送

ツール構成単体テストアプリ、マイコンシミュレータ※全てのモジュールがソフトウエアのみ※常に安定動作する

単体テストアプリ、ターゲットボードPCとの接続ケーブル、電源装置※ソフトツール、専用ハードウエアが必要※ノイズなど物理的な影響を考慮する必要あり

全てソフトウエアであるため保守性が高い専用ハードウエアの保守が必要

環境セットアップ（テスト準備作業）

製品開発のビルドをそのまま使用可能作業は発生しない※デバッグ情報を付加してビルドするだけ

ターゲットボードに計測装置I/Fファームウエアの組み込みが必要、ターゲット毎にカスタマイズ（コンフィグレーション）を行う必要有り※計測装置I/F ファームウエア← 計測した情報をボードからPCへ転送する仕組み

テスト開始のリードタイムなし専用HWコンフィギュレーションが必要

テスト対象コード製品に搭載するコードと同じオブジェクトテスト対象関数にフックコード（プローブ）を挿入したテスト専用ビルドを別途準備する必要あり

製品へ実装するコードと同一最もターゲットに忠実な状態でテスト

製品へ実装するコードとは異なるコードに挿入したフックコード（プローブ）による影響が避けられない

ISO 26262認証認証取得済み認証取得済み

カバレッジ機能 C0, C1, MC/DC, 関数、コール C0, C1, MC/DC, 関数、コール（関数、コールをサポートしないツールもある）



ICEによる手作業がどのように改善されるか

■ ICEを使用して、１関数６０分で単体テストを行っている場合を例にとると・・・作業時間の内訳は・・

– ソース解析＆テストデータ作成：３０分

– ICEによる手作業でのテスト実行：３０分

■ カバレッジマスターの導入により、初回のテストにおいては・・– ソース解析＆テストデータ作成：３０分 ←同じ時間がかかる

– カバレッジマスターで自動実行：数秒 ←テストは自動化され作業工数はゼロ

■ ２回目以降の反復テストでは– ソース解析＆テストデータ作成、テスト実行の作業工数もゼロになる

テストデータ作成３０分

ICEによるテスト実行３０分

６０分

ICEによる手作業

テストデータ作成３０分

テスト実行は数秒（ほぼゼロ）

３０分

カバレッジマスター導入の初回

テスト実行は数秒（ほぼゼロ）

導入後の反復テストでは・・

既存のテストデータを使用するため

データ作成工数はない

５０％削減

作業工数はゼロ



他社ISS/ICEを使用した場合との比較

■ 他社（半導体メーカー純正）ISS/ICEを使用した単体テストとは– ISS/ICE（デバッガ）がサポートするスクリプト言語を駆使して単体テストを行う方法

• 関数の呼び出し指定、変数に対するデータ設定を行うスクリプトを作成

• テスト実行後に実行ログファイルを解析して、評価対象の変数の値を確認

• テスト結果を表に記入（手作業）

• 期待値との比較判定（手作業）

■ C1、MC/DCカバレッジをとることは困難、または膨大な手作業が必要– ステップ実行毎に、プリントしたソースコードをマーカーで塗りつぶす手作業となる

純正ISSを駆使した方法カバレッジマスターによる自動テスト

テストデータ表作成

テストスクリプト作成

テスト実行

ログ解析

テスト結果を表に記入

期待値との比較判定

手作業の大半を自動化

テストデータ表作成

テストスクリプト作成

テスト実行

ログ解析

テスト結果を表に記入

期待値との比較判定

５０％削減



導入実績・発表事例（参考資料）



カバレッジマスターwinAMSの導入実績/事例

■ 導入実績自動車業界、鉄道、デバイス関連、通信機器、空調関連、メカトロ機器、プリンター複写機、

FA機器、計器関連、エネルギー関連、交通機器関連、等々

■ 多数のユーザ事例を発表・不二越（株）：2011/01 GAIO CLUB ONLINEに事例紹介

・パナソニック（株）：2009/06 「ガイオ品質向上セミナー」にて発表

・パイオニア（株）：2008/02 組込み情報誌「ガイオ倶楽部」記事にて発表

・ソニーLSIデザイン（株）：2007/11 「単体試験の賢い選択・活用セミナー」にて発表

・日産自動車（株）：2006/08 「組込みソフト単体テスト成功事例セミナー」にて発表

・アイシン精機（株）：2006/08 「組込みソフト単体テスト成功事例セミナー」にて発表

・フェリカネットワーク（株）：2005/12 組込み情報誌「ガイオ倶楽部」記事にて発表



テストパートナーSQV単体テスト代行サービスについて

（参考資料）



単体テスト代行サービスの概要

■ ガイオの優位性を活かして単体テストを実施– 単体テストツールメーカとしてのツール知識の活用

– コンパイラメーカとしてのプログラム知見の活用

■ お客様に代わってテスト業務を完全代行– テスト作業のアウトソーシング

– 第三者評価機関としての立場で品質評価

■ カバレッジマスター導入の評価に利用可能– 御社のソース（数関数）で単体テストを代行

– ツール導入後の実工数、成果物の検討などに利用

コンパイラメーカ（プログラム知見）

テストツールメーカ（ツール知見）

テスト代行におけるガイオの優位性

G

ガイオテスト作業からレポート作成まで

お客様のソース・仕様書テスト指針

お客様ガイオ

G

お打ち合わせ



単体テスト代行作業の全体イメージ

■ モジュール単体テスト工程の全てをガイオへ業務委託– テスト作業の短期化と品質向上を実現

– カバレッジマスターwinAMSのテスト実施環境・データ一式、テストレポートを納品

お客様

コーディング詳細（関数）仕様書モジュール単体テスト

ガイオが代行

詳細（関数）仕様書

ソースコードカバレッジマスター

winAMS

ツール知見プログラム知見

納品

単体テスト仕様書テスト実施環境単体テスト報告書

障害レポート

納品物

作業の短期化ソフト品質の向上

ガイオへ業務委託



単体テスト代行の流れ

■ 最終納品までの流れと各フェーズでの受け渡し書類– お見積もりはご提供頂くソースコード、ドキュメントにより決定

作業終了/納品

モジュールテスト仕様書テスト実施環境モジュールテスト報告書

機密保持締結

ソース開示のための機密保持契約

ファーストミーティング

テスト指針概要

仕様書

テストの概要を打ち合わせ

・テスト指針・関数数・納期

ソースコード受領

見積り作成用の対象ソースを受領

見積書提出

テスト指針詳細

仕様書

契約ご発注

見積書

作業開始

作業進捗表

ソース、ドキュメント機密保持契約書

テスト再実行環境（資産化できるデータ）

¥



納品物：テスト指針書

■ ご依頼元（お客様）との打ち合わせによりテストのゴールを決定– 仕様書から読み取れる仕様の動作確認の方法

– ホワイトボックス的観点からカバレッジの指針、テストデータの与え方など

• コーディングの人的ミスを発見するためのデータ作成指針



納品物：テストデータ

■ ガイオが作成するテストデータの意図を明確化する書類を作成します– 作成したテストデータの意味（不具合検出のための観点）を明確化

– 作成データがソースコードのどのパスを通過するかをフローチャートに図示

フローチャート入力データ

カバレッジ指針に従ったテストデータの意味を色で識別

どの実行パスを通過するデータか表示

テストデータ毎の実行パスを表示



納品物：テスト結果報告書

■ 単体テストの実行結果についてのドキュメントを作成– 入出力テストの期待値照合結果、 C0/C1カバレッジレポートを作成します

単体テスト入出力結果カバレッジデータ

実行結果の出力＆期待値との合否判定C0 / C1 カバレッジ結果のテキストレポート



納品物：障害報告書

■ 単体テストで障害が発生した関数のドキュメントを作成– 障害が発見された場合の、障害箇所の指摘と、考えられる原因のレポート

障害発生関数サマリ障害発生テスト結果報告書

各関数毎の単体テスト結果を一覧表でレポート

各関数毎の入出力結果（OK or NG）期待値との照合結果レポート

障害レポート例：



END

■ 最新情報はWEBサイトから www.gaio.co.jp

※会社名・商品名は各社の商標または登録商標です。※本テキストの内容は、予告無く変更される場合があります。※本書記載の誤りにより生ずる問題や損失に対して弊社は責任を負いません。

※本資料の無断転載、複写はお断りします。

ガイオ・テクノロジー株式会社営業本部営業部〒140-0002 東京都品川区東品川2-2-4 天王洲ファーストタワー25階

TEL: 03-4455-4767 Email: info＠gaio.co.jp ・・ご質問はこちらまで

Documents

C/C++ C0 C1 MC/DC ISO26262/IEC61508 カバレッジ ... · Copyright © 2006-2016 GAIO TECHNOLOGY CO., LTD. ALL RIGHTS RESERVED. カバレッジマスターwinAMS