猫でも使えるソフトウェアのテスト網羅（3）：無料ツールで単体テストを楽に実行しよう：山浦恒央の“くみこみ”な話（86）（1/4 ページ）

組み込み開発の大規模化により、プログラムテストの重要性が高まっています。パス網羅をベースにする単体テストは困難な作業ではありませんが、ツールを導入することで効率化できます。今回はGcovを用いたテスト手法を紹介します。

[山浦恒央 東海大学 大学院 組込み技術研究科 非常勤講師（工学博士），MONOist]

1.はじめに

　ソフトウェアにおけるブラックボックス・テストの王様が「同値分割」と「境界値分析」なら、ホワイトボックス・テストの帝王が「パス網羅」です。

　パス網羅は、実行しうるパスの何パーセントをテストで網羅したかが、キチンとした数字で計算できるので客観性がありますし、「一度もテストしていないスイッチがある自動車は、怖くて運転したくないし、市場にリリースできないでしょ？」と前置きして、C0パス網羅100％を求めるクライアントも少なくありません（*1）。

　組み込み開発の大規模化により、単体テストの重要性が高まっています。システム全体を組み上げてからC0網羅を100％実施するには、多大な時間と労力が必要ですが、単体テストレベルでの（モジュール単位での）C0100％網羅はそれほど難しくありません。

　ただし、パス網羅自体のアイデアは非常にシンプルですが、単体テストであっても、パス網羅ツールを使わないと、網羅の抜けや、二重カウントが発生し、面倒なことになります。今回は、単体テストで実際にパス網羅ツールを使い（しかも、無料ソフトウェア）、「パス網羅」の食わず嫌いを直していただければ幸いです。

「パス網羅」の食わず嫌いを克服しましょう

*1：私は、この「自動車のスイッチ」のアナロジーには少し否定的です。自動車の場合、運転手はほとんどのスイッチを使うと思いますが、ソフトウェアでは、ソースコードの半分が「エラーケース」「異常時の処理」「特殊ケース」であり、数年間の稼働期間中、1回も通らないソースコードが少なくないと思っています。そして高信頼性が要求されるソフトウェアほど、この傾向は顕著になると考えています。

　FA（フライトアテンダント。「スチュワーデス」は古語になりました）の訓練は、エンジン停止、山や海への不時着など、過酷な異常事態を想定して実施しますが、実際に事故に遭遇するFAはほとんどおらず、飛行中の仕事は乗客へのサービスがほとんどという状況に似ています。

　ただし、ソフトウェアのテストで、「FAの訓練」をアナロジーにすると、「重大事故だけど、50年に1回しか起きない事象だったら手を抜ける」と考える不届き者が少なからず湧いて出てきます。「高信頼性が要求されるソフトウェアほど、手抜きが発生する（あるいは、手を抜くつもりはなくても、テストが難しいため、実質的にテストが未実施になる場合がある）」という「高信頼ソフトウェアのジレンマ」が発生します。というわけで、「FAの訓練」のアナロジーが採用されることは（まず）ないでしょう。