猫でも使えるソフトウェアのテスト網羅（2）：パス網羅の種類と内包する問題点：山浦恒央の“くみこみ”な話（85）（1/4 ページ）

趣味ならとにかく、ビジネスとしてのプログラミングに「網羅的なテスト」は欠かせません。網羅的なテストの代表的な手法である「制御パス・テスト」の手法について、解説していきます。

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

1.はじめに

　ソフトウェアを作るのは簡単ですが（実際には超級大変なんですが……）、デバッグやテストはもっと大変です。世界中にプログラミングが大好きな少年少女はニューヨーク市の人口の何倍もいるでしょうが、「テストとデバッグが趣味です」なんて殊勝な中学高校生は沖永良部島の人口の10分の1程度でしょう（根拠はありませんが）。

　趣味のプログラミングではシリアスなテストは必要ありませんが、ビジネスとしてプログラムを作る場合（*1）、テストは最重要課題です。その課題に答えるヒントとして、前回から「制御パス・テスト」を取り上げています。読者自身で、「テストとはこうあるべきだ」的な哲学を確立する上で、一助になれば幸いです。

（沖永良部島の浜辺ではありません）

*1：誤解しないでいただきたいのですが、個人の趣味で作るプログラムはレベルが低く、市販する商用ソフトウェアがエラいといっているのではありません。どちらにも良い面と悪い面があります。趣味のプログラミングの代表例が、UNIXやLINUXでしょう。個人の楽しみとして、時間とお金を無制限に注ぎ込んで世界が共通に使うOSが完成したのです。投入する時間とコストを度外視して開発することは（大学での研究もこっち系です）、ビジネスではあり得ません。

コンピュータ・システムの進歩と発展は、個人の趣味のプログラミングに「おんぶにだっこ」状態かもしれません。ただし、趣味のプログラムでは、スケジュール管理、品質制御、コスト管理をしません。いつ、どんなものが出てくるか予想できず、「小学生の夏休みの宿題」ほど信頼性がありません。ビジネスとしてのプログラミングは、契約が絡みますので、納期や品質には非常に厳格です。

2.テスト方式の分類

　テストの方式には、いろいろな分類法があります。代表的な分類法が以下の2つでしょう。

• プログラムを何で実行するかによる分類

（1）机上テスト ： 開発者の「頭脳」をCPUにしてソフトウェアを実行する（*2）

（2）マシン・テスト ： 実機のCPUでソフトウェアを実行する

• 視点の違いによる分類

（1）ブラックボックス・テスト ： ユーザー視点によるテスト

（2）ホワイトボックス・テスト ： 設計者視点によるテスト

*2：机上テストは、もちろん、海外の開発プロジェクトでも実施されます。海外のエンジニアと話していて、机上テストの話になることがよくあります。日本のミーティングでも、時々、「デスク・デバッギング」と言うこともあり、「The desk debugging is ……」とアメリカ人プログラマーに話すと、相手は、「エッ、それなに？」と必ず聞き返されます。自動車関係の英語は90％が和製英語で（例えば、ハンドル、バックミラー、フロントガラス）、海外では通じませんが、コンピュータ系は99％が通じます。例外の1％が「デスク・デバッギング」と「NG（エヌジー）」でしょう。「code inspection（あるいは、walkthrough）」と「not good」と表現しないと通じません。

　テストの網羅（パス網羅）は、上記の「視点の違いによる分類」では、ホワイトボックス・テストであり、「プログラムを何で実行するかによる分類」では、マシン・テストが90％、机上テストが10％です。

　パス網羅の基本的な考え方として、よく聞かれるのは「自動車を作る場合、1回もテストしたことがないスイッチがあると、そんな自動車は怖くて出荷できない。ソフトウェアも同様で、1度も実行していないソースコードがあるプログラムは出荷できない」といった言い回しです。ここから、プログラマーの地獄が始まります。