検索
連載

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

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

Share
Tweet
LINE
Hatena

1.はじめに

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

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

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

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

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

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

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

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る