検索
連載

猫でも使えるソフトウェアのテスト網羅(1):基本のC0パス・カバレッジ山浦恒央の“くみこみ”な話(84)(2/3 ページ)

ソフトウェアのバグが全て取れたか?は開発における最大の関心事でしょう。網羅的テストはもちろんですが、その前に単体テストが必要です。代表的な手法である「制御パス・テスト」の基礎を紹介していきます。

Share
Tweet
LINE
Hatena

3. いろいろなパス・カバレッジ

 上記では、分岐に着目したパス・カバレッジについて説明しました。この章では、各パス・カバレッジの詳細を説明します。表.1に代表的なパス・カバレッジの概要と難易度を示します。

表.1 パス・カバレッジの詳細
パス・カバレッジ 詳細 達成難度
C0(命令網羅) 全命令語を最低一回はテストする 容易
C1(分岐網羅) 条件文の結果が「真」、「偽」になる両方をテストする そこそこ
C2(複合条件網羅) 条件文の「真」と「偽」の組み合わせをテストする 非常に困難

3.1 C0パス・カバレッジ

 C0(シーゼロと読みます)パス・カバレッジは命令網羅とも呼び、プログラムの「命令文」に着目し、各命令語を最低1回は実行するパス網羅です。命令文とは「a = a + 1;」や「if (a == 1)」などが当たります。

 C0パス・カバレッジには、いろいろな誤解や落とし穴があります。C0パス・カバレッジの基本的な考え方としてよく言われるのは、「自動車の製造で1回もテストしたことがないスイッチがある場合、そんな製品は怖くてマーケットに出せない。ソフトウェアも同様で、1度も実行していないソースコードがあるプログラムは安心して出荷できない」です。

 こう言われると、「なるほど、C0パス・カバレージを100%網羅することは必須だ」と思うのですが、自動車のスイッチとソフトウェア製品は同じではありません。自動車の運転席にあるスイッチ類は(多分)いつか必ず使いますので、全スイッチのテストを実施せねばなりません。一方、ソフトウェアのソースコードでは、10年間連続稼働させても、1回も実行しないソースコードはいくらでもあります。

 例えば「原子力発電所制御プログラムで、炉心溶融が発生した場合、ゲート03を閉鎖し、バルブV006を開けて……」という異常処理のソースコードは、まず、「プログラムの一生」で実行されることはありません。私のざっくりとした感覚では、全ソースコードの半分以上は何らかの異常処理用ではないかと思います。

 高い信頼性が要求される機器のソフトウェアでは、必然的に異常時の処理が多く複雑になります。ソフトウェアのソースコードをお料理のレシピと見なし、「カレーのレシピ」には「牛肉を200g、人参1本、玉ねぎ1個、ジャガイモ3個を用意する」と書いてあったとします。冷蔵庫に牛肉があればいいのですが、「なければ、近くのスーパーマーケットへ買いに行く」とソースコードに書いてあるとします。

 それで、いつものスーパーへ行ったところ、水曜日で定休日だった。隣町のスーパーへ行こうと電車に乗ったが列車事故で途中駅に止まったため、バスに乗り継いで隣町のスーパーに行ったところ、牛肉が売り切れていた……。

 テキトーに動けばよい「趣味のプログラミング」ならば、冷蔵庫に牛肉がない時点で、「カレーを作らない」と終了してもいいのですが、一般販売用のソフトウェアではいろいろな異常事態に対応し、なんとか救おうとします(特に、外部デバイスに対する入出力異常系)。こんな複雑怪奇な異常時の処理を全て実行してテストするには、非常に大きな工数と時間がかかります。

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る