構造カバレッジ解析について

構造カバレッジは、要件ベーステスト手順の実行中にどのコード構造とコンポーネントインターフェースがテストされたかを特定し、要件ベーステストの有効性を実証的に測定することを容易にします。その名の通り、構造カバレッジ解析では、構造カバレッジを精査し、十分に実行されていないコード部分があるかどうか、また、もし実行されていない部分があればその理由を特定します。
 
DO-178C セクション 6.4.4 では、設計保証レベル (DAL：Design Assurance Level) に応じて、100% のMC/DCカバレッジ 、デシジョンカバレッジ、およびステートメントカバレッジを達成するための要件が詳細に規定されています。DO-178C の表 A-5 から:　
 

 
構造カバレッジメトリクスの照合は、通常、ソースコードのコピーを「インスツルメント」（つまり、カバレッジデータを収集する関数呼出しを挿入する）し、そのインスツルメントされたコードを要件ベースのテストケースを用いて実行することで実現されます。これらのテストケースは主に高レベル要件を参照し、必要に応じて低レベル要件によって補足します。
 
次に、構造カバレッジ解析を適用し、コードがどの程度実行されたかを測定することで、このテストの有効性を評価します。これまで実行されていないコード部分を実行するには、追加のテストケースの作成や既存のテストケースの修正、要件の変更、不要なコードの削除、あるいは無効化されたコードとその結果生じる意図しない機能の特定も必要になる場合があります。ソフトウェアカバレッジの目標が達成されていることを確認するには、通常、「レビュー、解析、検証」という反復的なサイクルが必要であり、LDRAツールスイートが提供するグラフィカルな表現（下記参照）が非常に役立ちます。
 

　　　　　LDRA ツールスイートのフローグラフでコードカバレッジをグラフィカルに視覚化
 
要件からコードおよびテストケースまでの完全なトレーサビリティと、包括的な機能テストカバレッジおよび構造カバレッジ目標の達成を組み合わせることで、システム要件が正しく分解、実装、検証されていることを示すことができます。
 

DO-178C、ステートメントカバレッジ、デシジョン/ブランチカバレッジ（Decision/Branch Coverage）

ステートメントカバレッジとデシジョンカバレッジは、DO-178Cで活用されるカバレッジメトリクスの中で最もシンプルな2つの形式です。（この文脈では、デシジョンカバレッジとブランチカバレッジは同義語です。）ステートメントカバレッジは、コード内のすべての実行文がテスト中に少なくとも1回実行されたことを保証します。一方、デシジョンカバレッジは、すべてのデシジョンポイント（if/else、ループなど）がすべての可能な結果（trueとfalse）を少なくとも1回実行したことを保証します。
 

DO-178C、Modified Condition / Decision Coverage（MC/DC）　　

レベルAのソフトウェアでは、ステートメントとデシジョンカバレッジに加えて、MC/DCが必須です。MC/DCでは、「デシジョン（条件判定全体）内の各コンディション（条件）が、その判定結果に独立して影響を与えることが示されている」（DO-178C用語集）ことが求められます。
条件判定全体に複数の条件が含まれる場合、考えられるすべての組み合わせをテストするのが正しい行動方針だと考えられるかもしれません。しかし、４つ以上の条件が含まれるようになると、必要なテストの量は膨大になり、許容範囲を超えてしまいます（下記参照）。　
 

 
MC/DCは、複数条件からなる判定におけるカバレッジメトリクスです。すべての可能な組み合わせを実行する必要はなく、理想的なケースでは、関係する条件の数よりも1つ多いテストのみが必要です。この例では条件が6つあり、合計64通りの組み合わせが可能ですが、MC/DCカバレッジを達成するために必要なテストはわずか7つです。
しかし、これらのテストでは、各条件が独立して結果に影響を与えることを示す必要があり、どの入力値がそれを達成できるかは必ずしも明らかではありません。MC/DCテストケースプランナーを使用すると、適切な値の選択がはるかに容易になります。
 

 

DO-178C、ソースからオブジェクトコードへのトレーサビリティ

レベルAのシステムでは、ソースレベルでの構造カバレッジだけでは不十分です。コンパイラはしばしばコードを追加したり制御フローを変更したりし、どのように変更されるかを前もって知ることは困難です。正しい動作が損なわれないようにするため、DO-178Cのセクション6.4.4.2.bでは、次のように規定されています。
 
「ソフトウェアレベルがAであり、コンパイラ、リンカ、またはその他の手段によってソースコードステートメントに直接追跡できない追加コードが生成される場合、生成されたコードシーケンスの正しさを確認するために追加の検証を実行する必要がある」
 
ソースコードからオブジェクトコードへのトレーサビリティの証拠を提供する自動化メカニズムがあれば、そのプロセスははるかに効率的になります。オブジェクトコードとアセンブリコードの間には直接的な1対1の関係があるため、ツールでこれを表現する一つの方法は、ソースコードのグラフィカル表現と、それに相当するアセンブリコードの表現を並べて表示することです。オブジェクトコード検証（OCV）は、ソースコードとアセンブリコードをそれぞれ順番にインスツルメントすることで、両方のレベルでコードカバレッジを測定します。
 

 
このアプローチは、ターゲットシステム上の実行可能オブジェクトコード（EOC：Executable Object Code）の実証可能かつ決定論的な検証手段を提供します。OCVが効果的に機能するには、そのシステムに導入されているマイクロプロセッサ、関連命令セット、およびコンパイラをサポートする必要があります。テストケースは、3種の個別モードで実行され、規格で参照される「追加コード」を迅速に特定し、煩雑な手作業による解析を大幅に削減します。
 

1. 正しい機能を確認するために、テストケースをインスツルメントなしで実行する
2. テストケースをソースコードレベルでインスツルメントして実行する
3. 最後に、アセンブリコードレベルでインスツルメントしてテストケースを実行し、コンパイルおよびリンクプロセス中に挿入または変更された可能性のある、カバーされていないステートメントまたはブランチが識別される

 
この追加コードを検証するために、一般的には要件ベースのテストをいくつか追加することで、DO-178Cセクション6.4.4.2.bの目標を満たすことができます。自動化されたインスツルメントとカバレッジ解析の仕組みは拡張性と適応性に優れ、クロスコンパイラ、ターゲット、インサーキットエミュレータ、その他の組み込み環境に幅広く適応します。ターゲット統合は高度に拡張可能で、シンプルな8ビットデバイスから高性能マルチコアアーキテクチャ、IDE、I/O統合まで、幅広いプロセッサをサポートします。
 

要約

構造カバレッジ解析は、DO-178Cの要件ベーステストの有効性を実証する上で重要な役割を果たします。基本的なステートメントおよびデシジョンカバレッジから、高度なMC/DCおよびオブジェクトコード検証まで、コンプライアンスを達成するには、意図しないコードや検証されていないコードが残らないようにするための厳格なテスト、トレーサビリティ、そしてツールサポートが必要です。
 
この記事の原文（英語版）