単体テストとは何か、なぜ必要なのか【後編】：はじめての単体テスト（4/4 ページ）
前編では、単体テストと機能安全の関わり、単体テストの重要性と組み込み業界の現状、単体テストの自動化について解説しました。後編では、ソフトウェアの品質管理や単体テストの手法について解説します。
5.3.2.4 コンディションカバレッジ（条件網羅／C2）
コンディションカバレッジは、カバレッジ基準の中で最も厳格なコードカバレッジです。
テスト対象の条件分岐に複合条件が使われる場合でも、各条件の真偽全ての組み合わせをテストします。ソースコードに対する網羅性が高い一方で、テストケース数が膨大になるため、規模の大きなソフトウェアでコンディションカバレッジまで網羅されているケースは少ないといえます。
5.3.2.5 MC／DCカバレッジ（Modified Condition/Decision Coverage）
MC／DCカバレッジは、「Modified Condition/Decision Coverage」の略です。
コンディションカバレッジと同様にコードの網羅性が非常に高いため、航空機向けソフトウェアや自動車に搭載するソフトウェアなど、高い安全性が求められるケースにおいてはMC／DCカバレッジ基準を用います。複数あるカバレッジ基準の中で、現実的かつ最も厳しい基準がMC／DCであるといえるでしょう。
MC／DCカバレッジの定義は下記の通りです（※5）。
- MC/DC requires all of the below during testing
- Each entry and exit point is invoked.
- Each decision takes every possible outcome.
- Each condition in a decision takes every possible outcome.
- Each condition in a decision is shown to independently affect the outcome of the decision.
（※5）「A Practical Tutorial on Modified Condition/Decision Coverage」;NASA/TM-2001-210876;May 2001;https://shemesh.larc.nasa.gov/fm/papers/Hayhurst-2001-tm210876-MCDC.pdf
抄訳になりますが、MC／DCカバレッジはテストで以下の要件を確認することを求めています。
- プログラムの全ての入口と出口を通過していること
- プログラムの各判定式が、全ての取りうる結果を出力すること
- プログラムの判定式の各条件が、全ての取りうる結果を出力すること
- プログラムの判定式の各条件が、判定結果に単独で影響すること
例えば、とある複合条件式がある命令において「A and Bが真の時、処理2を実行する」場合、Aが真であれば、Bが真偽のどちらかによって判定の出力が変化しますが、Aが偽であれば、Bの真偽がどちらでも判定は偽になります。つまり、Aが偽のテストケースは1つでよいため、このソースコードにおけるMC／DCのカバレッジを100％にするためのテストケースは3通りということになります。
6 まとめ
手作業での単体テストには膨大な工数が発生します。ブラックボックステスト、ホワイトボックステスト、それ以外のテストをどのような基準で行うのか。各製品ドメインに求められる品質基準を考慮しながらテスト計画を定め、きちんと運用していくことが重要です。
また、手作業でのテストにはヒューマンエラーが介在しますので、各種国際認証におけるテストエビデンスにはなり得ません。そのため、何かしらの自動化ツールを導入してヒューマンエラーを排除し、均一的なテストエビデンスを作成できるような環境を整えることが重要です。
会社紹介
ベクター・ジャパン株式会社
ベクターは、創立から30年以上にわたり、カーエレクトロニクス開発の頼れるパートナーとしてお客様をサポート。現在、世界各国30拠点以上でベクター社員が、自動車業界および関連する業界のメーカー様とサプライヤー様に、組込システム開発に必要なツール、ソフトウェアコンポーネント、サービスなど、プロフェッショナルな開発プラットフォームを提供している。
▼ベクター・ジャパン
▼VectorCASTページ
https://www.vector.com/jp/ja/products/products-a-z/software/vectorcast/
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
HILSとは何か
最新の高級自動車は200個ものコンピュータを搭載しているといわれる。ECU（電子制御ユニット）と呼ばれるこのコンピュータが、正しく動作するかどうかを試験するテスト装置として注目を集めているのがHILSだ。本連載では、HILSの導入や、HILSを使ってECUのテストを行うための基本的な知識の提供を目指す。連載第1回は「HILSとは何か」だ。
次世代の車載ネットワーク「CAN FD」とは
セキュリティ対応や自動運転などの車両の高機能化に伴い、より高速な車載ネットワークが求められている。本稿では次世代の車載ネットワークの1つとして考えられているCAN FD導入の背景やプロトコルの概要ついて紹介する。
イーサネットがなぜクルマに必要？ 期待される役割は
インターネット経由で誰とでもつながる時代。個人が持つ端末はワイヤレス接続が大半を占めていますが、オフィスなどではいまだに有線によるローカルエリアネットワーク（LAN）が使われています。そのLANの基盤技術の1つとして広く使われているイーサネット（およびTCP/IP）が、次世代の車載ネットワーク技術として注目を浴びています。本稿では注目される背景、役割や規格動向から、関連するプロトコルの概要まで、複数回にわたり幅広く解説していきます。
レッドハットが車載ソフトウェア、車載Linuxの機能安全対応や保守管理を支援
Red Hat（レッドハット）が車載ソフトウェアに参入する。車載情報機器で採用拡大が見込まれる車載Linux向けに、開発ツールやコンポーネントを展開する。車載情報機器向けのOSはGoogle（グーグル）の「Android」と車載Linuxの2つが主流となっており、グーグルへの依存を懸念する自動車メーカーやサプライヤーが車載Linuxに注目している状況だ。
トヨタデンソーアイシンの車載ソフト会社が新体制に、目指すは「自動車のWindows」
トヨタ自動車グループの自動運転開発体制で先行開発を担ってきたTRI-AD（Toyota Research Institute Advanced Development）は、2021年1月から新体制で動き出した。これまでは車載ソフトウェアの開発会社だったが、スマートシティのように自動車やモビリティを超えた取り組みに挑むため役割分担を明確にする。
自動車に「ソフトウェアファースト」がもたらす競争力を考える
今後、ソフトウェアが担う役割を拡大していく要因は、クルマがユーザーの手元に来た後に機能を拡充するアップデートを行おうとしている点です。以前は車両購入後のソフトウェア更新というと、ナビゲーションシステムの地図データのアップデートや、クルマの修理で制御プログラムを修正するのが中心でした。スマートフォンで好みのアプリを追加したり、より良い最新の状態にアップデートしたりするようにクルマが変わっていけば、クルマの使い方や価値も大きく変化します。