はじめに
本記事では、ISTQB Automotive Software Tester シラバスの**Chapter 2（Automotive SPICE）**の中から、
「2.1.2 Requirements of the Standard（Part-3）」＝ユニット検証戦略（Unit Verification Strategy）
について詳しく解説します。
前回（Part-1とPart-2）では、Automotive SPICE（以下A-SPICE）の要求事項や能力レベルの構造を学びました。今回はさらに一歩進んで、ユニットレベルでの検証方針とトレーサビリティの考え方を整理します。
1. ユニット検証戦略（Verification Strategy）とは
A-SPICEでは、開発の各工程において「検証（Verification）」を行うことが求められています。
その中でも、**SWE.4（Software Unit Verification）**プロセスでは、個々のソフトウェアユニットが設計通りに動作するかを確認するための戦略が必要です。
🔹ユニット検証戦略の目的
-
各ユニットが**詳細設計（Detailed Design）**に従って実装されているか確認する
-
**機能要件（Functional Requirements）と非機能要件（Non-Functional Requirements）**の両方に適合しているか検証する
-
静的および動的テスト技法を組み合わせて検証する
🔹ユニット検証戦略に含まれる内容
ユニット検証戦略（Verification Strategy）には、以下のような内容を含めます：
|
内容 |
説明 |
|---|---|
|
検証対象 |
どのユニット（ソースコードやモジュール）を検証するのか |
|
使用技法 |
静的解析、コードレビュー、ユニットテストなど |
|
必要データ |
テストデータ、検証結果、コードメトリクスなど |
|
実施手順 |
テストの順序、責任者、使用ツール |
|
成果物 |
検証結果レポート、トレーサビリティ表など |
例：
たとえば、ECUソフトウェアの中で「車速センサー入力を処理する関数」がある場合、
-
静的解析：MISRA-Cルール違反がないか
-
動的テスト：入力0km/h〜250km/hの範囲で正しく変換されるか
-
コードレビュー：変数名やコメントが設計仕様に一致しているか
を検証します。
2. 動的テスト戦略との違い
A-SPICEでは、ユニット検証戦略（Verification Strategy）のほかに、
SWE.5・SWE.6・SYS.4・SS.5などのプロセスで「テスト戦略（Test Strategy）」が求められます。
|
種類 |
対象 |
内容 |
|---|---|---|
|
テスト戦略（Test Strategy） |
システム/統合レベル |
主に動的テスト（実行を伴うテスト） |
|
検証戦略（Verification Strategy） |
ユニットレベル |
静的＋動的技法の両方を含む |
つまり、テスト戦略は主に「実行ベース」、一方で検証戦略は「コードレビューや静的解析」も含めた、より包括的な計画です。
3. 検証基準（Verification Criteria）とは
A-SPICEでは、各検証に「何をもって合格とするか」を明確にするための**検証基準（Criteria）**を設定します。
これらは「受け入れ基準」「エントリ/エグジット基準」と似た考え方で、
ユニットレベルでの達成条件を定義します。
🔹代表的な検証基準の例
|
検証基準の種類 |
内容の例 |
|---|---|
|
✅ ユニットテストケースとデータ |
設計通りに全てのパスを網羅しているか |
|
✅ カバレッジ目標 |
ステートメント・デシジョン・条件カバレッジなど |
|
✅ 静的解析結果 |
コーディング規約（例：MISRA-C）遵守率 |
|
✅ コードレビュー |
静的解析ツールで検出できないロジックや命名の妥当性を確認 |
|
✅ 結果の記録 |
全テストのログやレポートを保管し、トレーサビリティを確保 |
4. 変更管理とリグレッションテスト
ユニットに変更（修正・改善・リファクタリングなど）が加わった場合、
**リグレッションテスト（回帰テスト）**を実施して影響範囲を確認します。
🔹ポイント
-
変更理由：不具合修正、機能改善、コード最適化など
-
影響分析（Impact Analysis）：どのテストを再実施すべきかを判断
-
結果：以前成功していたテストが再度成功するか確認
5. トレーサビリティ（Traceability）の重要性
A-SPICEでは、**双方向トレーサビリティ（Bi-Directional Traceability）**が求められます。
これは、上流工程の成果物と下流工程の成果物が「双方向にリンク」していることを意味します。
🔹トレーサビリティの2つの軸
|
種類 |
説明 |
|---|---|
|
垂直トレーサビリティ（Vertical Traceability） |
上流（要件）→下流（ソフトウェアコンポーネント）をリンク。開発階層全体の一貫性を確保。 |
|
水平トレーサビリティ（Horizontal Traceability） |
同レベル内（例：テスト仕様書 ↔ テスト結果）の整合性を確認。 |
🔹例：
-
要件「ブレーキ信号を0.1秒以内に反映する」
→ 設計仕様 → コード → テストケース → テスト結果
という流れがすべてリンクされていることが理想です。
🔹変更要求とのリンク（SUP.10）
A-SPICEのサポートプロセス SUP.10 “Change Request Management” では、
変更要求（Change Request）と影響を受ける成果物との双方向トレーサビリティを要求しています。
これにより、変更による漏れや不整合を防止できます。
6. Automotive SPICEでの文書化ルール
A-SPICEでは、ユニット検証戦略を**ユニットレベルのテスト計画（Test Plan）**の一部として文書化することが定められています。
つまり、プロジェクトで「テスト計画書」を作成する際には、
以下を明確に記載しておく必要があります：
-
検証戦略（Verification Strategy）
-
検証基準（Verification Criteria）
-
トレーサビリティ方針
-
静的/動的技法の適用範囲
まとめ
ユニット検証戦略は、A-SPICEの品質保証の根幹を支える重要なプロセスです。
静的・動的技法の両面からユニットを評価し、トレーサビリティで一貫性を担保することで、
ソフトウェア品質を継続的に向上させることができます。
次回は「AUTOSAR（Automotive Open System Architecture）」に進み、A-SPICEと連携する開発基盤の理解を深めます。
🧭 補足：学習ポイントまとめ
-
ユニット検証戦略はSWE.4で定義される
-
検証戦略 ≠ テスト戦略（静的技法を含む点が異なる）
-
検証基準はテスト合格条件やカバレッジ目標などを明確化する
-
トレーサビリティは垂直・水平・変更要求間で確保する
-
検証戦略はユニットレベルのテスト計画書に文書化する
コメント