ISTQB Automotive Tester の Chapter 4 では、

自動車特有のテスト技法（Static / Dynamic Test Techniques） が扱われています。

静的テスト（レビュー、コーディング規約）、

動的テスト（条件テスト、Back-to-Back、フォルトインジェクション等）

どちらも試験ではよく問われる重要領域です。

このページでは、試験直前対策として役立つ Chapter 4 のサンプル問題（3問） を解説します。

◆ 試験での出題数（Chapter 4）

ISTQB公式情報によると、Chapter 4 からは次のとおり出題されます。

• 合計：7問

• 4.1（静的テスト）

  • K2：複数

  • K3：1問

• 4.2（動的テスト）

  • K3レベルが 4.2.1、4.2.5 から出題される

特に 動的テスト技法（4.2）から多く出題（約4問） されるため、確実に理解しておきましょう。

================================

■ サンプル問題 1：MISRA-C:2012 の正しい記述はどれか？

================================

問題文

以下の MISRA-C:2012 に関する記述のうち、正しいものはどれですか？

選択肢

A. 「required」に分類されているルールは、開発者が理由を示したとしても無視してはならない。

B. ガイドラインの拘束力は、すべての組織においてあらかじめ定義されている。

C. 「mandatory」に分類されているルールは、典型的なコーディング異常を回避しなければならない。

D. MISRA ガイドラインはすべて静的解析ツールで完全に検出できる。

■ 解説

A：誤り

Required ルールは「理由があれば例外を認める」ことが MISRA の原則。無条件ではない。

B：誤り

MISRA の拘束力（どのルールを遵守するか）は 組織ごとに決める。

既定ではない。

C：正しい（正解）

Mandatory ルールは

• 典型的なコーディング異常

• バグを生む書き方

• 可読性低下

  を避けるための規約であり、遵守必須。

D：誤り

静的解析ツールでは MISRA のすべてを完全にチェックすることはできない。

🎯 正解：C

================================

■ サンプル問題 2：要求品質特性（ISO/IEC/IEEE 29148）

================================

問題文（要約）

カーラジオの要求仕様が以下のように与えられています：

1. 電源ON後、3秒間 “Welcome” と表示する。

2. 電源ON時、ラジオは Active / Passive / Maintenance のいずれかの状態となり、電源OFF時の最後の状態を保存する。

3. ラジオ機能は「Radio」ボタンを押したときにのみ有効になる。

4. CD機能が選択されていて、ドライブに CD が入っていない場合 “No Disk” と表示する。

質問：

ISO/IEC/IEEE 29148 における要求品質特性の観点で、正しい指摘はどれか？

選択肢

A. 要求1は検証可能ではない

B. 要求2は単一要素（singular）ではない

C. 要求3は一貫していない

D. 要求4は非曖昧（unambiguous）ではない

■ 解説

A：誤り

3秒の表示、メッセージ内容も明確なので 検証可能（verifiable）。

B：正しい（正解）

要求2には次の2種類の内容が含まれている：

• ON 時の状態

• OFF 時の状態保存

  → 複数の要求が1つに混在しており “非単一”

  本来は 2 つに分割すべき。

C：誤り

要求3は明確で一貫している。

D：誤り

要求4は明確で非曖昧。

🎯 正解：B

================================

■ サンプル問題 3：フォルトインジェクションテストの説明

================================

問題文

以下のうち、フォルトインジェクションテストの説明として 誤っている ものはどれか？

選択肢

A. 外部コンポーネントの振る舞いに故障を注入し、システムが誤動作に対処できるか確認する。

B. 内部インタフェースに故障を注入する（例：メッセージロスト）。

C. 仕様に故障を注入する（例：性能要件に対してパラメータを低くする）。

D. 動作ユニットに故障を注入して内部欠陥を顕在化させる。

■ 解説

フォルトインジェクション（Fault Injection）は

意図的に故障（Fault）を作り、エラーハンドリングやリカバリ機能を確認するための技法。

仕様（要求）に故障を入れることはしない。

あくまで 実装（コード・ハード・通信） に注入する。

🎯 正解：C

================================

■ ISTQB Automotive Tester 試験まとめ

================================

• 試験時間

  • 60分

  • 非英語母語者は＋15分

• 問題数：40問

• 章別出題数

  1章：3問

  2章：18問（最多）

  3章：12問

  4章：7問 ←（この記事の対象）

Chapter 4 は難易度高め＆出題率高い技法が多いので、確実に押さえておくと合格率が上がります。

ソフトウェアテスト技法練習帳　～知識を経験に変える40問～ [ 梅津正洋、竹内亜未、伊藤由貴、浦山さつき、佐々木千絵美、高橋理、武田春恵、根本紀之、藤沢耕助、真鍋俊之、山岡悠、吉田直史［著］ ]

posted with カエレバ

楽天市場

Amazon

ソフトウェアテスト技法ドリル【第2版】 テスト設計の考え方と実際 [ 秋山 浩一 ]

posted with カエレバ

楽天市場

Amazon

ISTQB Automotive Tester Chapter 4 では、自動車特有のテスト技法について学びます。その中でも 4.2 動的テスト技法の最後のテーマが「4.2.5 文脈依存のテスト技法選択」です。

Part-2では「どのようにテスト技法を選ぶのか？」を、具体的な表を使った例で解説しています。

このテーマはK3（適用）レベルの出題となるため、単に知識を覚えるだけでは不十分です。

状況を読んで、適切なテスト技法を選べるかどうかが問われます。

1. 文脈依存のテスト技法選択とは？

テスト技法は複数ありますが、すべてを同時に使うことは現実的ではありません。

そのため、以下のような複数の要素を踏まえて最適な技法を選択する必要があります。

• ASIL（安全度水準）

• 利用できるテストベース（要件・仕様・コードなど）

• 欠陥を見逃した場合のリスク

• 対象となるテストレベル（今回は「システムテスト」）

• 適用可能性と効果

ISTQBでは、これらを整理して技法を比較・判断するために表形式で評価する方法を紹介しています。

2. 技法選択のサンプル表

技法一覧：

• 要件ベーステスト

• 同値分割法（Equivalence Partitioning）

• 境界値分析（Boundary Value Analysis）

• ステートメントテスト

• デシジョンテスト

• MCDC

• エラー推測（Error Guessing）

• フォルトインジェクション

• バックトゥバックテスト

以下、技法選択の判断基準。

評価基準

3. 表から読み取る「技法の選び方」

▼結論：最終的に選ばれた技法

1. 要件ベーステスト

2. 同値分割法（Equivalence Partitioning）

以下で、他の技法が選ばれなかった理由を解説します。

4. 技法が選ばれなかった理由の分析

1）テストレベルが「システムテスト」で不適

以下の技法は、主にホワイトボックス（コードレベル）のためシステムレベルのテストに適さないと判断されます。

• ステートメントテスト

• デシジョンテスト

• MCDC（修正条件/決定条件網羅）

• フォルトインジェクション（用途が限定的）

よって「選択しない」。

2）テストベースが存在しない

テストベースがないと設計自体が不可能な場合があります。

• 境界値分析：数値の入力範囲が仕様に記載されていないため不可

• エラー推測：経験・チェックリストがないので不可

• バックトゥバックテスト：比較対象のモデル・参照システムがない

→ 必要情報が欠けているため「選択しない」。

3）ASILレベルだけで選択してはいけない

「ASILが高いので推奨レベルが高い＝必ず使うべき」ではありません。

ASILはあくまで優先度の目安の一つであり、

テストレベル（システム/統合/ユニット等）やテストベースの有無との組み合わせで

実際に使えるかどうかが決まります。

――この点はISTQB的な重要ポイントです。

5. 実践例：あるシステムのテスト技法選択

以下は動画の例を、日本語で具体的なストーリーとして再構成したものです。

■ 想定するケース

レベル：システムテスト

ASIL：A（安全上重要）

仕様書：利用可能

数値条件の仕様なし（境界値分析は不可）

■ 技法評価の流れ

▼ Step1：テストレベルから除外する

ホワイトボックス系を除く

• ステートメント

• デシジョン

• MCDC

• フォルトインジェクション

▼ Step2：テストベースの有無で除外

• 境界値分析 → 入力範囲の仕様がない

• エラー推測 → 経験ベース情報なし

• バックトゥバック → 比較元なし

▼ Step3：ASILと適用性で最終決定

残ったのは以下の2つ

✓ 要件ベーステスト

✓ 同値分割法

よって、この2つが最適な技法と判断されます。

6. まとめ：技法選択は“状況の総合評価”が鍵

文脈依存の技法選択では、以下の総合評価が必要です。

• ASIL

• 利用できるテストベース

• 欠陥見逃しリスク

• テストレベルとの適合性

• 技法の目的と特性

• 現実的な適用可否判断

特にISTQB試験（K3）では、

「表を読み、最適な技法を選べるか」が直接問われます。

表の要素を一つだけ見るのではなく、

複数の要素を組み合わせて分析することが重要です。

ソフトウェアテスト技法練習帳　～知識を経験に変える40問～ [ 梅津正洋、竹内亜未、伊藤由貴、浦山さつき、佐々木千絵美、高橋理、武田春恵、根本紀之、藤沢耕助、真鍋俊之、山岡悠、吉田直史［著］ ]

posted with カエレバ

楽天市場

Amazon

ソフトウェアテスト技法ドリル【第2版】 テスト設計の考え方と実際 [ 秋山 浩一 ]

posted with カエレバ

楽天市場

Amazon

Automotive Tester の Chapter 4 では、自動車領域で特に重要となる「動的テスト技法」が扱われます。

今回のトピック 4.2.5「Context-dependent Selection of Test Techniques」 は、その名の通り、

状況（文脈）に合わせてどのテスト技法を選ぶべきか

を理解するための章です。

CTFL（Foundation Level）で学んだブラックボックス/ホワイトボックス技法をベースにしつつ、自動車領域では ISO 26262 の ASIL や テストレベル などが選択に強く影響します。

1. テスト技法の種類と自動車領域との関係

まず、CTFL で学んだテスト技法をおさらいします。

■ ブラックボックス技法

• 同値分割（EP）

• 境界値分析（BVA）

• 状態遷移テスト

• 判定表テスト（Decision Table）

• ユースケース／シナリオベーステスト など

■ ホワイトボックス技法

• ステートメントカバレッジ

• ディシジョンカバレッジ

• 条件網羅

• MCDC（Modified Condition & Decision Coverage）

■ 経験ベース技法

• エラーハンドリング中心の Error Guessing（エラー推測）

• 探索的テスト など

自動車ソフトウェアでもこれらの技法をそのまま使いますが、

ISO 26262（特に Part 6）では ASILごとに推奨される技法が異なるため、

“どれを使うべきか” が明確に決まりやすい特徴があります。

2. ISO 26262（ASIL）による技法の推奨

ISO 26262 は ASIL（A/B/C/D）ごとに推奨技法を提示しています。

たとえば…

ASIL が上がるほど ホワイトボックス寄りの網羅性が高い技法が要求されます。

3. Automotive Tester で扱う技法一覧

以下の技法が例として挙げられます。

• Requirement-based Testing（要求ベーステスト）

• Equivalence Partition（同値分割）

• Boundary Value Analysis（境界値分析）

• Statement Testing（ステートメント網羅）

• Decision Testing（分岐網羅）

• Modified Condition/Decision Coverage（MCDC）

• Error Guessing（エラー推測）

• Fault Injection Test（フォルトインジェクション）

• Back-to-Back Testing（バックトゥバック）

これらはすでに Chapter 4 で解説済みの内容なので、ここでは選択基準を中心に説明します。

4. テスト技法を選ぶための「3つの基準」

テスト技法は ASIL だけでなく、以下 3 つの視点から判断する必要があります。

① State of the Art（技術の妥当性・最新性）

技法がその対象に適しているかどうか。

▼例

• 数値入力の範囲チェック → 同値分割 / 境界値分析が妥当

• 状態遷移を伴うドアロックシステム → 状態遷移テストが適切

• Safety領域の高リスクECU → ASIL D → MCDC が最適

参照規格：

• ISO 26262

• ISO/IEC/IEEE 29119-11/19（テスト技法標準）

② Test Basis（テストベースの情報量）

技法を適用するために必要な情報が仕様に含まれている必要があります。

▼例

• 仕様に「数値の許容範囲」が書かれていなければ境界値分析はできない

• 仕様に「状態遷移」が定義されていなければ状態遷移テストは使えない

• ソースコードがないとホワイトボックス技法は使えない

③ Test Level（テストレベルに適しているか）

すべての技法がすべてのレベルに適しているわけではありません。

▼例：どのレベルで使うと効果的？

例

ECU の単体テスト → MCDC で内部ロジックを網羅

車両統合システムテスト → 状態遷移やシナリオテストが効果的

5. 実務でよくある判断例

◆ケース1：ADASのセンサ入力をテストする場合

• 値の範囲が仕様にある

  → EP/BVA が最適

• 統合環境で挙動確認したい

  → システムレベルの状態遷移テスト

◆ケース2：重要ECUの安全機能（ASIL D）

→ MCDC + フォルトインジェクションが必須級

◆ケース3：モデルベース開発のコード生成部分

→ Back-to-Back Testing（MIL/SIL/HIL の比較）で整合性チェック

6. まとめ（Part-1）

4.2.5 Part-1 の結論は以下です：

テスト技法は決まりきったものではなく、文脈（Context）に応じて選ぶ必要がある。

その判断基準は：

1. State of the Art（システムに最適か）

2. Test Basis（仕様に必要情報があるか）

3. Test Level（レベルに適しているか）

4. ISO 26262（ASIL）による推奨

ソフトウェアテスト技法練習帳　～知識を経験に変える40問～ [ 梅津正洋、竹内亜未、伊藤由貴、浦山さつき、佐々木千絵美、高橋理、武田春恵、根本紀之、藤沢耕助、真鍋俊之、山岡悠、吉田直史［著］ ]

posted with カエレバ

楽天市場

Amazon

ソフトウェアテスト技法ドリル【第2版】 テスト設計の考え方と実際 [ 秋山 浩一 ]

posted with カエレバ

楽天市場

Amazon

この記事では、自動車領域のテストで重要となる「要件ベースドテスト」の考え方を、具体例を交えながらわかりやすく紹介します。

■ 要件ベースドテストとは？

要件ベースドテストとは、仕様書（要求仕様）からテスト条件を抽出し、それに基づいてテストケースを作成・実行するアプローチ です。

テスト設計技法（同値分割・境界値分析など）とは異なり、

これは 「テストの進め方（アプローチ）」 に分類されます。

■ 要件ベースドテストの基本ステップ

Foundationレベルで学んだ「テストプロセス」と同じ流れで進んでいきます。

1. 要件を分析する

2. テスト条件を特定する

3. テストケースを設計する

4. テストケースを実行する

5. 結果を分析し、必要なら追加テストを作る

このように、要件に基づいてテスト設計 → 実行 → 改善 を繰り返し、要件を十分にカバーすることが目的です。

■ 自動車開発での具体例：要件ベースドテスト

● 要件例

要件R1：車速が20km/h以下のとき、後方カメラが自動で起動すること。

要件R2：車速が20km/hを超えた場合、後方カメラは自動的にオフになること。

● テスト条件の抽出

• 車速 ≤ 20km/h のときカメラON

• 車速 > 20km/h のときカメラOFF

● テストケース例

このように、要件の内容をそのまま反映したテストケースが作られます。

■ 要件が不十分な場合のリスク

要件が曖昧・不完全な場合、

その要件に基づくテストケースも不完全になる

という点が最大のデメリットです。

例：

要件に「20km/h以下」とあっても、

• “20km/hちょうど” の扱いが明確でない

• 小数点はどう扱うのか？

• 停止中（0km/h）をどう扱うのか？

などが曖昧な場合、テスト時にも混乱が生じます。

■ すべての要件を100%網羅できない問題

要件が膨大だったり、非常に詳細だったりすると、

すべての要件をテストするのは不可能 です。

これはテスト原則の1つ、

「原則②：完全（網羅的）テストは不可能」

に対応する内容です。

そのため現実的には、

• 重要度

• リスク

• 優先度

  に基づいてテストケースを優先付けします。

特に自動車領域では、安全に直結する要件（ASILが高いもの）を優先してテストを行います。

■ 要件ベースドテスト＋探索的テストの組み合わせ

動画でも解説されているように、要件ベースドテストだけでは

「要件に記述されていない欠陥」に気づけないことがあります。

そこで、自動車開発では次のような組み合わせが一般的です。

• 要件ベースドテスト（形式的）

• 経験ベーステスト（探索的テスト、エラーベース）

• 回帰テスト

特に探索的テストでは、実車特有の動き、環境条件、ドライバー操作などから新しい不具合を見つけることがよくあります。

■ まとめ

要件ベースドテストは最も基本的なアプローチですが、

自動車開発では非常に重要な役割を果たします。

• 要件からテストを作ることで、仕様を漏れなく確認できる

• ただし要件が不完全だとテストも不完全になる

• 全部の要件はテストできないので優先度付けが必要

• 経験ベースや回帰テストと組み合わせると効果が高い

K1レベルの範囲ですが、実務でも頻繁に登場する重要な考え方です。

ソフトウェアテスト技法練習帳　～知識を経験に変える40問～ [ 梅津正洋、竹内亜未、伊藤由貴、浦山さつき、佐々木千絵美、高橋理、武田春恵、根本紀之、藤沢耕助、真鍋俊之、山岡悠、吉田直史［著］ ]

posted with カエレバ

楽天市場

Amazon

ソフトウェアテスト技法ドリル【第2版】 テスト設計の考え方と実際 [ 秋山 浩一 ]

posted with カエレバ

楽天市場

Amazon

自動車ソフトウェアでは、通常のテストケースでは通らない**エラーパス（error handling code path）を正しく検証することが極めて重要です。

本記事では、ISTQB Automotive Tester シラバス 4.2.3 のFault Injection Testing（フォルトインジェクションテスト）**について、図解イメージや具体例を交えてわかりやすく解説します。

1. フォルトインジェクションテストとは？

**フォルトインジェクションテスト（Fault Injection Testing）**とは、

テスト中に意図的に故障（フォルト）や異常値を注入し、エラーハンドリングや回復処理が正しく動作するかを確認するテスト技法

です。

通常のテストケースでは通らないコードパス（エラー処理）を強制的に実行させることで、以下を検証できます。

• 不正値を検出できるか

• 安全なフェール（safe state）に移行できるか

• システムが異常状態から回復できるか

典型的な例

• try-catch ブロックが正しく例外を捕捉するか

• センサーからあり得ない値（implausible values）が来たときに安全に動作するか

• CAN通信が途絶・遅延したときに機能が暴走しないか

2. なぜフォルトインジェクションが自動車で重要なのか？

自動車は人命に関わる領域のため、**異常時の安全性（機能安全）**が最優先です。

例えば：

• 加速度センサーが壊れて異常値を送ってきた

• ECU間通信が途絶した

• メモリが破損して値が正しくない

これらの状況は“稀”ですが、1回でも起これば事故につながる可能性があります。

そのため、

通常のテストでは通らない“エラーハンドリング”部分を必ず検証する必要がある

ここがフォルトインジェクションテストの核心です。

3. フォルトインジェクションを行う 3 つのポイント

フォルトインジェクションは主に以下の3つの箇所で実施します。

(1) 外部コンポーネントへの欠陥注入

例：センサーからの不合理（implausible）な値の送信

• あり得ない速度（例：500 km/h）

• 温度センサーが -100℃ を送ってくる

• ステアリング角度センサーが急激に変化する

目的： 不合理値を検出し、安全動作へ切り替えられるかを確認。

(2) インターフェースの欠陥

例：通信のショート、断線、遅延、メッセージロスト

• CANメッセージが届かない

• LIN通信が遅延する

• 信号線がショートして電圧レベルがおかしくなる

目的：

通信障害や信号欠損時に、システムが安全に動作するかを検証。

(3) ソフトウェア内部の欠陥

例：メモリ破損、内部モジュールの例外

• 変数が突然不正な値に書き換わる

• 内部モジュールが例外を投げる

目的：

内部異常を検出し、回復処理や安全状態へ移行するかを確認。

こうした内部欠陥は、開発者がデバッガ（debugger）や XCP 経由で挿入することが多く、時間がかかる傾向があります。

4. フォルトインジェクションがよく使われるテスト環境

● HIL（Hardware-in-the-Loop）環境

最もよく使用される環境。理由：

• センサー・アクチュエータの物理信号を扱える

• ECUと実機レベルで近い環境でテストできる

• 短絡（ショート）や断線（オープン）など物理現象を再現できる

HILでは FIU（Fault Insertion Unit） と呼ばれる装置を使い、ショート/オープンを物理的に再現します。

● SIL（Software-in-the-Loop）環境

ソフトウェアベースのインターフェース異常はSILでもテスト可能。

例：

• CANメッセージ欠損のシミュレーション

• 内部関数の異常応答

HILよりも高速かつ安価にテストできるため、可能なものはSILで前倒し実施するのがベストプラクティス。

● 開発環境（デバッガ上）

内部コードへの欠陥注入（内部変数破損など）は、

デバッガや XCP を使った「開発環境」での作業が必要なことが多いです。

5. フォルトインジェクションと「欠陥植込み（Defect Seeding）」の関係

フォルトインジェクションは、開発者が意図的に欠陥を埋め込む「Defect Seeding（欠陥植込み）」と似ています。

• Defect Seeding：テストの有効性を測るために意図的に欠陥を埋め込む

• Fault Injection：エラー処理の網羅性を高めるために異常を注入

どちらも目的は異なりますが、“意図的な異常発生”という点で共通しており、ソフトウェアの信頼性向上につながります。

6. まとめ：Fault Injection Testing は“抜け漏れしやすいエラーパス”を確実にテストするための技法

フォルトインジェクションは、通常のテストで通らない異常パスを検証するための必須技法です。

特に自動車領域では、

• 不合理値

• 通信断

• 内部異常

といった予期せぬ状況でも安全に動作できるよう、広く活用されています。

ソフトウェアテスト技法練習帳　～知識を経験に変える40問～ [ 梅津正洋、竹内亜未、伊藤由貴、浦山さつき、佐々木千絵美、高橋理、武田春恵、根本紀之、藤沢耕助、真鍋俊之、山岡悠、吉田直史［著］ ]

posted with カエレバ

楽天市場

Amazon

ソフトウェアテスト技法ドリル【第2版】 テスト設計の考え方と実際 [ 秋山 浩一 ]

posted with カエレバ

楽天市場

Amazon

自動車開発では、同じ機能を持ったソフトウェアやコンポーネントに複数の“バリアント（Variant）”が存在することがよくあります。

こうした複数バージョンの挙動を比較して、差分がないか確認する手法が Back-to-Back Testing（バック・トゥ・バックテスト） です。

この記事では、

• Back-to-Back Testing の定義

• どんな場面で使うのか

• 具体的なテストプロセス

• 実務でのメリット・注意点

• モデルベース開発（MBD）との関係

をわかりやすく解説します。

■ Back-to-Back Testing とは？

2つ以上のバリアント（またはバージョン）が同じ仕様・機能を持つ場合に、同じテストケースを実行し、結果を比較するテスト手法 を指します。

別名：

• 🚗 Comparison Testing（比較テスト）

▶ シンプルな定義

同じ入力に対して、複数のバリアントが同じ出力を返すかを検証するテスト

一致すれば OK（合格）、

差異があれば NG（差分分析が必要）となります。

■ なぜ Back-to-Back Testing を行うのか？

自動車ソフトウェアでは以下のような理由で“複数バリアント”が生まれます。

• 車種別の ECU バリアント

• 地域別（EU/US/JP）で機能が少し異なる

• センサーが異なるが共通ロジックを使う場合

• 既存バージョンを改修した新バージョン　など

このとき 「本当に同じ挙動になっているか？」 を検証する必要があり、Back-to-Back Testing が非常に有効です。

■ Back-to-Back Testing のプロセス（3ステップ）

この手法は非常にシンプルで、次の 3つのステップ で実施されます。

① テストケース準備（Test Case Preparation）

• すべてのバリアントに対して共通で使用できるテストケースを設計する

• 仕様の「共通部分」を基準にテスト観点を整理する

• 出力形式やログのフォーマットも統一しておくのが望ましい

② アプリケーション実行（Test Execution）

• 準備したテストケースを 複数バリアントに対して同じ入力で実行

• 出力結果をバリアントごとにファイルとして保存

• ファイルは必ずバージョン管理（例：Variant_A_2025_01.log）

③ 結果の比較・分析（Comparison & Analysis）

• 結果を比較ツールを使って自動で比較（Diff）

• 差分がある場合は、どのデータが相違したのかをレポート化

• 必要に応じて開発と調査を行う

■ Back-to-Back Testing のメリット

✓ 1. コスト削減（効率的）

同じテストケースを使い回せるため、環境構築や工数の削減につながります。

✓ 2. バージョン違いやバリアント差を自動検出できる

「どこが違う？」を自動で検出できる点が最大の強み。

✓ 3. モデルベース開発（MBD）に非常に向いている

• 実行可能モデル（Simulink など）

• 生成コード（Cコード）

を比較することができるため、モデルがテストオラクルとして機能します。

✓ 4. 大規模変更後のリグレッションに強い

“仕様は同じだが、内部ロジックを変えた”ケースに最適です。

例：アルゴリズム最適化、センサー変更、補正値変更 etc.

■ 注意すべきポイント

■ ①「共通仕様」に基づくことが絶対条件

バリアントごとに仕様が違う場合は比較できないため、

Core Requirements（共通要求） が明確であることが前提。

■ ② Requirements-Based Testing の代替ではない

このテストは「確認」には強いが、

「要求網羅を保証するもの」ではありません。

要求ベーステストは別途必要です。

■ 実務イメージしやすい例

【例】ACC（Adaptive Cruise Control）の制御ロジック

バリアント例：

• Variant A：欧州向け

• Variant B：北米向け

仕様共通部分：

• 車間距離制御

• 加減速アルゴリズムの基本構造

テスト内容：

1. 時速100 → 80 に減速するケース

2. 先行車が車線変更して消失するケース

3. 許容加速度範囲を超えた場合の制御

結果比較：

• A と B が同じ制御指令を出しているか？

• タイムスタンプごとに差異を比較

• 差異があれば、それが仕様差かバグか分析する

■ まとめ

Back-to-Back Testing は、

“複数バリアントの挙動が一致しているか”を高速に確認するテスト技法です。

特に以下のような場面で威力を発揮します。

• 多車種展開の制御ロジック

• バージョンアップしたソフトの比較検証

• モデルベース開発でモデルと生成コードの一致を検証

• コストを抑えて品質を担保したい時

要求ベーステストを補完しながら、差分検出に特化した非常に実務的なテクニックと言えます。

ソフトウェアテスト技法練習帳　～知識を経験に変える40問～ [ 梅津正洋、竹内亜未、伊藤由貴、浦山さつき、佐々木千絵美、高橋理、武田春恵、根本紀之、藤沢耕助、真鍋俊之、山岡悠、吉田直史［著］ ]

posted with カエレバ

楽天市場

Amazon

ソフトウェアテスト技法ドリル【第2版】 テスト設計の考え方と実際 [ 秋山 浩一 ]

posted with カエレバ

楽天市場

Amazon

はじめに

この記事では、ISTQB Automotive Tester シラバス（4章：Automotive Specific Test Techniques） の中から、

「4.2.1 条件テスト（Condition Testing）、多条件テスト（Multiple Condition Testing）、MCDC（Modified Condition Decision Coverage）」

について解説します。

この章では、動的テスト技法（Dynamic Test Techniques） の一部として、ソフトウェアコードやロジック条件に基づいたホワイトボックステスト手法を扱います。

特に自動車ソフトウェアでは、制御ロジックや安全関連条件分岐が多いため、MCDCなどの手法が非常に重要です。

1. 動的テスト技法とは？

「動的テスト技法」とは、実際にソフトウェアを実行しながら動作を確認するテスト手法のことです。

（これに対し、レビューやコード解析のように実行しないものは「静的テスト技法」と呼びます。）

動的テスト技法の中で、4.2.1では以下の3つを学びます。

2. 各テスト技法の概要と違い

2.1 条件テスト（Condition Testing）

条件テストでは、個々の条件（True / False）をすべて評価することを目的とします。

例えば、次のようなIF文を考えます。

if (A && B)

この文の中には2つの条件（AとB）が存在します。

それぞれがTrue / Falseをとることで、条件テストでは以下のように少なくとも各条件の真偽を1回ずつテストすれば良いとされます。

これで、AのTrue/False・BのTrue/Falseをそれぞれ1回ずつ評価できるため、条件テストの基準を満たします。

ただし、この場合、判定結果（全体のTrue/False）を完全にカバーしていないという欠点があります。

2.2 多条件テスト（Multiple Condition Testing）

多条件テストでは、全ての条件の組み合わせをテストします。

つまり、2条件なら「2² = 4通り」すべてを実施します。

これで、AとBの全組み合わせを網羅します。

判定結果のTrue/Falseもすべて確認できるため、より完全なカバレッジが得られます。

しかし、条件が3つ、4つと増えるとテスト数は指数的に増えます。

• 3条件 → 2³ = 8通り

• 4条件 → 2⁴ = 16通り

• 10条件 → 1024通り（！）

つまり、全組み合わせテストは現実的に不可能になることが多いのです。

2.3 MCDC（Modified Condition Decision Coverage：修正条件／判定カバレッジ）

MCDCは、多条件テストの「無駄を省いた」アプローチです。

各条件が独立して判定結果に影響を与えることを確認するだけでよい、というルールです。

MCDCの目的：

各条件が、他の条件の値に依存せず、単独で判定結果（True/False）を変えることを確認する。

✅ 例題：MCDCでのテストケース設計

再び、条件が2つの場合（A && B）を考えます。

• TC1とTC3を比較すると、Bの値の変化（False→True）が結果をFalse→Trueに変えている。

• TC2とTC3を比較すると、Aの値の変化が結果を変えている。

したがって、3ケースでMCDCを達成できます。

（多条件テストの4ケースより少ない）

3. 3つの技法の比較表

MCDCは**DO-178C（航空機）やISO 26262（自動車機能安全）**などでも推奨されています。

4. 実務での使いどころ

自動車ソフトウェアでは、以下のような制御ロジックが頻出します。

if (speed > 60 && brake == ON)

このような条件では、速度やブレーキ状態など複数の変数が組み合わされます。

そのため、すべての条件を単独にテストする必要があります。

MCDCは、安全関連システム（例：ABS、ESC、ADAS）などで特に重視されます。

5. まとめ

MCDCは、少ないテスト数で高い安全性を確保できる最も効率的な方法です。

自動車ソフトウェアテストにおいては、MCDCが最も実用的かつ推奨されるカバレッジ基準です。

💡 まとめポイント

• 条件テスト：各条件をTrue/Falseで評価

• 多条件テスト：すべての組み合わせを評価（テスト数が多くなる）

• MCDC：各条件が独立して結果に影響することを確認（効率的）

• MCDCはISO 26262などの安全基準で推奨

🔍 例題（ISTQB Automotive Tester Sample）

問題：

次の条件式 if (A && B) に対して、MCDCを達成する最小テストケース数はいくつか？

選択肢：

A. 2

B. 3

C. 4

D. 8

正解： B（3ケース）

理由：

AとBがそれぞれ独立して判定結果を変えることを確認できる3パターン（True/Falseの変化）で十分。

ソフトウェアテスト技法練習帳　～知識を経験に変える40問～ [ 梅津正洋、竹内亜未、伊藤由貴、浦山さつき、佐々木千絵美、高橋理、武田春恵、根本紀之、藤沢耕助、真鍋俊之、山岡悠、吉田直史［著］ ]

posted with カエレバ

楽天市場

Amazon

ソフトウェアテスト技法ドリル【第2版】 テスト設計の考え方と実際 [ 秋山 浩一 ]

posted with カエレバ

楽天市場

Amazon

はじめに

ISTQB Automotive Tester シラバスの第4章では、「自動車特有のテスト技法（Automotive Specific Test Techniques）」として**静的テスト（Static Testing）と動的テスト（Dynamic Testing）**を扱います。

本記事ではそのうち、**4.1.2「要求仕様レビューにおける品質特性（Quality Characteristics for Reviews of Requirements）」**について、ISO/IEC/IEEE 29148:2011の定義をもとに、レビューで注目すべきポイントを詳しく解説します。

静的テストとレビューの重要性

仕様書の欠陥は「早期発見」が命

要求仕様書（Requirements Specification）は開発とテストの両方の基礎となる文書です。

そのため、この段階での欠陥は後工程で大きなコスト・時間の損失を生みます。

• 例：

  • 要求の誤りが結合テストや受け入れテストで発覚した場合、修正には多大な再作業が必要。

  • 一方、静的レビューで早期に発見できれば、低コストで修正可能。

このように、静的テストによるレビューは「早期発見・低コスト修正」の最も有効な手段の1つです。

要求仕様レビューで確認すべき「品質特性」とは？

ISO/IEC/IEEE 29148:2011では、**単一の要求（individual requirement）および要求群（set of requirements）**に対して、以下の品質特性（Quality Characteristics）を定義しています。

各品質特性の具体的な例

1. Verifiable（検証可能）

各要求は、テストによって検証可能である必要があります。

• 良い例：

  「システムは3秒以内にブレーキ応答を行うこと」 → 測定可能で検証できる。

• 悪い例：

  「システムは迅速に反応すること」 → “迅速”が曖昧で、検証できない。

2. Unambiguous（曖昧でない）

要求が明確で、解釈の違いを生まないこと。

• 悪い例：

  「システムは通常時に動作すること」 → “通常時”の定義が不明。

• 改善例：

  「エンジン回転数が1000〜4000rpmの範囲で動作すること」。

3. Consistent（一貫性がある）

他の要求と矛盾しないこと。

• 悪い例：

  要求A：「システムは20℃で動作すること」

  要求B：「システムは10℃以下では動作しないこと」

  → この場合、10〜20℃の範囲で矛盾が生じる。

4. Complete（完全である）

すべての必要な情報が記載されていること。

• 悪い例：

  「図1に示す構造で動作する」→ 図1が添付されていない。

• 改善例：

  図や略語を明確に定義し、参照関係を示す。

5. Traceable（トレーサブル）

各要求に一意のIDがあり、テストケースや設計要素に紐づけられること。

これにより、変更影響分析（Impact Analysis）やテスト網羅性の確認が容易になります。

6. Bounded（範囲が定義されている）

開発・テストすべき範囲を明確にする。

• 例：

  「車速が0〜200km/hの範囲で速度制御を行う」

  → 境界値を定義することでテスト範囲を明確化。

7. Singular（単一である）

要求が重複せず、独立していること。

• 悪い例：

  「車速が100km/hを超えたら警報を出す、そしてライトを点滅する」

  → 複数動作を1つの要求に含めている。

• 改善例：

  • 要求A：「車速が100km/hを超えたら警報を出す」

  • 要求B：「車速が100km/hを超えたらライトを点滅させる」

静的テストにおけるチェックリスト活用

品質特性をレビューする際、**チェックリスト（Review Checklist）**の活用が有効です。

以下はその一例です。

これらを体系的に確認することで、要求仕様の品質を大幅に向上できます。

まとめ

• 静的テストは**「早期に安く欠陥を見つける」**ための最強手法。

• 要求仕様レビューでは、ISO/IEC/IEEE 29148:2011の品質特性を基準にチェックすることが重要。

• チェックリストを活用すれば、レビューの抜け漏れを防止し、品質向上につながる。

静的テストの本質は、**「後工程で問題を起こさない設計と要求の土台をつくること」**です。

次のステップでは、動的テストに進む前に、このレビュー技法をしっかり身につけましょう。

ソフトウェアテスト技法練習帳　～知識を経験に変える40問～ [ 梅津正洋、竹内亜未、伊藤由貴、浦山さつき、佐々木千絵美、高橋理、武田春恵、根本紀之、藤沢耕助、真鍋俊之、山岡悠、吉田直史［著］ ]

posted with カエレバ

楽天市場

Amazon

ソフトウェアテスト技法ドリル【第2版】 テスト設計の考え方と実際 [ 秋山 浩一 ]

posted with カエレバ

楽天市場

Amazon

MiL（Model-in-the-Loop）、SiL（Software-in-the-Loop）、HiL（Hardware-in-the-Loop）などのテスト環境に関する問題が出題されます。

本記事では、公式ISTQBサンプル問題（出典：istqb.org）をもとに、

出題傾向・出題数・各問題の正解と理由をわかりやすく解説します。

🎯 Chapter 3の出題傾向

• セクション 3.1（Test Environment）：3問

• セクション 3.2（XiL Test Environments）：9問

合計12問前後（全40問中）がこの章から出題されるため、非常に重要なパートです。

特にMiL／SiL／HiL環境の違いやOpen Loop／Closed Loopシステムの理解が鍵となります。

✅ サンプル問題①

ECUにおいて、情報の収集と分配に使用されるインターフェースはどれか？

選択肢：

A. Environment model（環境モデル）

B. Bus systems and diagnostic interface（バスシステムと診断インターフェース）

C. Watchdog and internal data memory（ウォッチドッグと内部データメモリ）

D. Analog and digital inputs, bus system, and diagnostic interface（アナログ／デジタル入力、バスシステム、診断インターフェース）

解説：

• ECU（Electronic Control Unit）は外部環境との情報交換を入力／出力インターフェースを通して行います。

• 「環境モデル（Environment Model）」は仮想テスト環境側の構成要素であり、ECUそのもののインターフェースではありません。

• 「ウォッチドッグ」はソフトウェア監視用のメカニズムであり、情報の入出力とは関係ありません。

正解： ✅ D

理由：

ECUでは、アナログ／デジタル入力、バスシステム、診断インターフェースが情報の入出力に使われます。

✅ サンプル問題②

次のうち、Closed Loopシステムに関する正しい記述はどれか？

選択肢：

A. 出力信号はテスト対象（Test Object）の入力に直接接続される。

B. 出力信号は環境モデルを介してテスト対象の入力に接続される。

C. Open Loopシステムでは出力信号が入力に直接接続される。

D. Open Loopシステムでは出力信号が環境モデルを介して入力に接続される。

解説：

• Closed Loopシステムでは、出力信号 → 環境モデル → 入力信号という流れになります。

• Open Loopシステムでは、出力が入力にフィードバックされません。

正解： ✅ B

理由：

Closed Loopでは、テスト対象の出力信号が環境モデル（Environment Model）を介して入力に戻るためです。

この点を混同しやすいので注意。

✅ サンプル問題③

Software-in-the-Loop（SiL）環境で典型的に実施されるテストはどれか？

選択肢：

A. 診断リクエストの応答時間テスト

B. 電磁適合性（EMC）テスト

C. ターゲットハードウェアの性能テスト

D. インターフェーステストおよび統合テスト

解説：

• SiLはソフトウェア単体・統合レベルで実施されるため、ハードウェア依存のテストは実施できません。

• EMCテストや性能テストは実機ハードウェアを必要とするため、HiL環境で行われます。

正解： ✅ D

理由：

SiL環境では、ソフトウェア間のインターフェーステストや統合テストが適しています。

✅ サンプル問題④

次のうち、Hardware-in-the-Loop（HiL）テスト環境の構成要素をすべて含むものはどれか？

選択肢：

A. Test case generator, Rest bus simulation, Power supply

B. Breakout box, Software compiler, Real parts

C. Power supply, Real-time capable computer, Electric error simulation

D. Electric error simulation, Signal processing, Processor simulation

解説：

• Test case generatorはツールであり、テスト環境構成要素ではありません。

• Software compilerは開発環境に属します。

• Processor simulationはSiL／MiL環境の要素で、HiLでは実機ハードウェアを使用します。

正解： ✅ C

理由：

HiLテスト環境には、以下の3要素が含まれます：

• Power supply（電源供給装置）

• Real-time capable computer（リアルタイム処理可能な計算機）

• Electric error simulation（電気的エラーシミュレーション装置）

💡 まとめ

ISTQB Automotive Tester試験では、

「どのテスト環境で何ができるのか？」を明確に理解することが合格の鍵です。

特にMiL／SiL／HiLの違い、Open/Closed Loopの概念を整理しておきましょう。

📘 学習のポイント

• 公式シラバス（ISTQB Automotive Tester Syllabus）を必ず1回は通読する

• 各XiL環境の目的・構成要素・テストレベルを比較表で覚える

• 「これはどの環境でテストする？」という出題パターンに慣れる

ソフトウェアテスト技法練習帳　～知識を経験に変える40問～ [ 梅津正洋、竹内亜未、伊藤由貴、浦山さつき、佐々木千絵美、高橋理、武田春恵、根本紀之、藤沢耕助、真鍋俊之、山岡悠、吉田直史［著］ ]

posted with カエレバ

楽天市場

Amazon

ソフトウェアテスト技法ドリル【第2版】 テスト設計の考え方と実際 [ 秋山 浩一 ]

posted with カエレバ

楽天市場

Amazon

本記事では、ISTQB Automotive Software Tester認定試験のChapter 3「仮想テスト環境でのテスト（Testing in Virtual Environments）」の中から、

**3.2.4 XiLテスト環境の比較（Part 2）**を詳しく解説します。

XiLテスト環境とは？

「XiL（X-in-the-Loop）」とは、開発フェーズに応じて以下のような3つの代表的なテスト環境を指します。

この3つの環境を適切に選択することで、コストを抑えながら、早期に欠陥を検出できるテスト戦略を構築できます。

テスト目的別：どの環境が適しているか？

以下は、各テスト目的ごとにどのXiL環境が適しているかをまとめた内容です。

記号の意味は以下の通りです：

• 「＋」：推奨される環境

• 「○」：限定的に可能（部分的に実施できる）

• 「−」：不適切または非現実的

① 顧客要求のテスト（Test Customer Requirements）

顧客要求とは、システムがユーザーやクライアントの期待を正しく満たしているかを確認することです。

例えば、「アクセルペダルを踏んだときに加速する」「ブレーキ時に安全に減速する」といった機能の検証です。

👉 解説：

ビジネス要件やエンドユーザー体験を確認するには、実機に近いHIL環境が最も効果的です。

MIL/SILでも仕様の初期検証は可能ですが、リアルタイムな挙動を再現するのは難しい場合があります。

② 欠陥検出とハンドリング（Test Mechanisms for Defect Detection and Handling）

欠陥をいかに早く見つけ、どのように安全な状態へ移行させるかを確認します。

例：ソフトウェア異常時にシステムを自動停止させる、セーフステートへの移行など。

👉 解説：

欠陥はどのフェーズでも発見できるため、全てのXiL環境で実施可能です。

ただし「早期発見・低コスト修正」の観点では、MILやSIL段階での発見が理想です。

③ 設定データの影響確認（Test Reaction to Configuration Data）

パラメータセットやバリアントコーディングなど、設定データが挙動に与える影響を確認します。

👉 例：

異なる車種設定や走行モードに応じた動作の違いを確認。

例えば、スポーツモードとエコモードでのエンジン応答性の違いなど。

④ 診断機能のテスト（Test Diagnosis Function）

診断機能とは、異常を検出してメモリに保存し、リセットできるかを確認するテストです。

👉 解説：

診断処理は実際のECU挙動を伴うため、SILまたはHIL環境でのテストが必須です。

MILでは、モデルが簡略化されており実際の診断制御ロジックは評価できません。

⑤ インターフェースと統合テスト（Test Interaction and Interfaces）

モジュール間・外部機器との通信インターフェースを確認します。

👉 解説：

SILではソフトウェア間のI/Fを、HILではセンサやアクチュエータを含むシステム全体のI/F検証が可能です。

⑥ ユーザビリティ確認（Prove Usability）

ユーザー視点での使いやすさ・直感的な操作性を確認するテストです。

👉 例：

運転支援システムの警告音が適切か、UI表示が直感的かなど。

ユーザー体験を再現できるHIL環境が最適です。

「フロントローディング」の考え方

ここで重要なのが、**Front Loading（早期テスト）**という原則です。

これはISTQB Foundation Levelでも学ぶ基本原則の一つで、

「欠陥はできるだけ早い段階で見つける方がコストも工数も少なく済む」

という考え方です。

もしHIL段階（最終統合テスト）で重大な欠陥を発見してしまうと、

再設計からやり直しになるケースもあります。

そのため、MILやSILで早期に欠陥を発見・修正することが非常に重要です。

まとめ：テスト環境と欠陥の対応関係

また、テストマネージャーはプロジェクト全体を俯瞰し、

どの環境でどの目的のテストを行うかを戦略的に割り当てる責任を負います。

これにより、最適なテストカバレッジとコスト効率が実現されます。

この記事のポイントまとめ

• XiLテスト環境は開発フェーズに応じてMIL・SIL・HILを使い分ける

• HILは最も現実的な検証環境だが、コストも高い

• **フロントローディング（早期欠陥検出）**がコスト削減の鍵

• テストマネージャーは目的別に最適な環境を計画することが重要

ソフトウェアテスト技法練習帳　～知識を経験に変える40問～ [ 梅津正洋、竹内亜未、伊藤由貴、浦山さつき、佐々木千絵美、高橋理、武田春恵、根本紀之、藤沢耕助、真鍋俊之、山岡悠、吉田直史［著］ ]

posted with カエレバ

楽天市場

Amazon

ソフトウェアテスト技法ドリル【第2版】 テスト設計の考え方と実際 [ 秋山 浩一 ]

posted with カエレバ

楽天市場

Amazon