猫でも分かるソフトウェアのテスト網羅（5）：C2カバレッジはエベレスト登山か？：山浦恒央の“くみこみ”な話（88）（1/3 ページ）

1．はじめに

　1万行超のプログラムは、多数の命令文、経路、入出力値で構成されています。このプログラムの「全要素をテストすること」は、理論上は可能ですが、これには、リリース時期を10万年後に設定し、数億人年の莫大な人月（コスト）を投入せねばなりません。現実のプロジェクトでは、多くても、開発期間やコストの30％〜40％しかテストやデバッグに投入できません（＊1）。完全にテストすることは、現実的には不可能なのです。限りある工数の中で、重要な部分だけをテストし、市場にリリースするケースが大半です。このように、理論上は可能でも、現実には不可能な事象が数多く存在します。ソフトウェアのテストでは、どの作業をサボって、どこを真面目にやるかという「エンジニアリング的な手抜き」が極めて重要になります。

＊1：NASAのソフトウェア開発では、超高信頼性が要求されるため、人月や開発期間の90％をテストに投入するそうです。世界のソフトウェア開発者の平均的な生産性は、1カ月1000ステップといわれていますが、NASAでは、100ステップほど。これだけテストしても、完全にバグは除去できませんが、システムは正しく動作して宇宙でのミッションを遂行しています。これは、テストにメリハリをつけ、重要度の低いバグの摘出には時間をかけず、高重要度の不良を完全に除去している結果です。

　「猫でも分かるソフトウェアのテスト網羅」シリーズでは、命令文、分岐、条件を網羅的にテストする手法である「制御パステスト」をテーマにしています。前回は、プログラムの分岐に着目するC1カバレッジの利点と欠点を紹介しました。

　C1カバレッジを100％網羅することで、プログラムの「分岐」と「命令文」は少なくとも1回は実行でき、ある程度の網羅的なテストができますが、条件文の組み合わせは考慮していません。一方、今回取り上げるC2カバレッジでは、条件文の「真」と「偽」の組み合わせを全てテストするため、理論的には網羅的なテストができます。ただし、テスト工数が莫大となり、現実的に達成が困難です。

　高信頼性を求めるソフトウェア開発の管理者や発注者は、C2網羅が大好きで、「C2カバレッジ最強」「C2を100％網羅したらバグはゼロになる」「このソフトウェアは、C2を100％網羅しないとダメだ」と考えている人が非常に多くいます。それで苦労するのは、実際にC2網羅をやらされるプログラマです。土日も出勤し、朝から最終電車の直前まで3カ月以上テストをしても80％ほどしか網羅できず、しかも、重大なバグは検知できないというトホホホな結果になります。上司や発注者が、「C2を100％網羅せよ」と無理難題を吹っかけてきた場合、このコラムの内容で反撃して、何としても止めさせてください。

　今回は、C2カバレッジについて説明し、その限界を考察します。

2．「理論上可能」と「現実的に可能」

※写真はイメージです

　現実世界でも、理論上可能なことが、現実にはできないことが多くあります。例えば、紙を折り続けた際の厚さを考えます。厚さ1mmの紙を半分に折り続けます。1mmは薄いのですが、チリも積もれば山となり、折り続けると非常にぶ厚く（高く？）なります。1回折ると1×2＝2mm、2回目で2×2＝4mmとなり、23回折り続けると、エベレスト山の標高を超えるそうです。

　筆者は、手元のA4用紙で折ってみましたが、6回目からは苦しくなり、7回目で限界でした。やろうと思えばそれ以上できるでしょうが、エベレストには到達できません。このように、理論的には可能でも、現実は不可能なことは多くあります。パスのカバレッジもその1つです。