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

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

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

1.はじめに

　ソフトウェア開発でエンジニアが最も悩むのは、「作成したソフトウェアのバグを全てたたき出したか？」という問題です。成果物を納品した後でバグが見つかると、顧客にはビジネス停止など大きな損害を与え、開発側は修正作業に追われて現在開発中の作業が止まったりします（*1）。ソフトウェア開発の品質制御での重要な課題が、「網羅的なテスト」です。

　開発エンジニアから、「網羅的なテストが出来ない」という話をよく聞きますし、経験的に、開発側が「十分にテストしました」は、あてにならないことが少なくありません。『ソフトウェア開発55の真実と10のウソ[1]』によると、十分にテストしたとプログラマーが自信を持っているソフトウェアでも、全パスの55〜60％程度しか網羅できていません。まずは、関数やメソッドを検証する「単体テスト」をキチンと実施する必要があります。

　単体テスト手法の代表的な手法に「制御パス・テスト」があります。制御パス・テストとは、モジュール中のソースコードの「命令文」「分岐した経路」「条件」のいずれかに着目し、全て実行したかを確認する手法です[2]。この手法は、テスト量が定量的な数値で表せるので、テストの量、充分性、進捗度を具体的な数字で示すことが可能です。

　新シリーズでは、複数回にわたって制御パス・テストの基礎を紹介します。

*1：重要なプロジェクトなのに、スケジュールが異常に遅れている、いわゆる「問題プロジェクト」は、そのプロジェクト自体が遅れるだけでなく、遅延回復のために他のプロジェクトから要員を抜いて投入するため、プログラマーを引き抜かれたプロジェクトも「遅延のお裾分け」を受けます。この「遅延のドミノ倒し現象」は、意外に表面に出てこず、ボディーブローとしてじんわり、でも、しっかりと効くので注意が必要です。30年以上、いろんな企業のエンジニアとお話ししたところ、超一流のソフトウェア開発会社でも、実働プロジェクトの2〜3％が問題プロジェクトのように思います。

2. 制御パス・テスト再入門

　制御パス・テストの詳細を説明します。この手法は、コード内のある「要素」に着目してテストする手法です。要素にはいろいろありますが、代表的なのが、ソースコード（例えば、itemID=itemID+1;）、分岐（例えば、if文）、条件文（例えば、if (a >= 1) )です。着目した要素が全てテストできれば「完了」、そうでない場合は「再テスト」となります。例から考えてみましょう（図.1）。

図.1 プログラムのフローの例

　図.1は、2つの条件文A、Bと、4つの命令文A〜Dを持ったプログラムのフロー例です。この図で注目している要素は「分岐」です。テスト済みのパスは黒線、未達パスは赤線で表しました。全部の要素をテストするには、赤線を通るテスト項目（条件文Aの結果が偽になる）を作成する必要があります。

　制御パス・テストでは、テストの実施量をパーセントで表せます。割合の考え方は、算数と同じです。例えば、10本あるパスのうち9本をテストすると、9/10 = 0.9となり、「90％テストした」と表せます。図.1の場合、条件文は2つで、それぞれ2通りのテストが必要なので、パス数は全部で4本（*1）です。「全パスのうち何本のテストを実施したか？」を考えると、以下のようになります。

　テストの実施量 = テスト済みのパス本数 / 要素の合計パス本数　…… 式I

　式Iに上記の図の値を入れると、3/4 = 0.75となり、「全体のパスの75％を網羅した」となります。このようなテストの量を表す指標は、一般的に「パス・カバレッジ（パス網羅）」と呼びます。パス・カバレッジが、自社の基準（あるいは、顧客の要求値）を満たせば「終了」、そうでなければ「再テスト」となります。パス・カバレッジは、プロジェクトの進捗（「3日遅れ」や「5日前倒し」など）を表す場合の指標にもなるため、導入している企業は少なくありません。

*2　条件文Aの結果が「真」「偽」、条件文Bの結果が「真」「偽」の全部で4通り