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

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

5. 現実的なパス網羅

　パス網羅によるテストは、意外に、「労多くして、実が少ない」ことがお分かりいただけたと思います（網羅率は、80％まですぐに到達しますが、そこからなかなか進みません）。しかし、パス網羅は、強力なテスト手法ですし、達成度（網羅率）は数字でキチンと表現できるところも魅力です。

　「パス網羅を実施したいけれど、その時間とコストがない」とか、「効果が期待できて現実的なパス網羅を実施したい」と考えているエンジニアの方々に使えそうな方法を列記します。

• （1） モジュール間の網羅をチェックする
• （2） 重要な機能に限定する
• （3） モジュールを限定する
• （4） エラー処理は1つと見なす
• （5） 机上での実行も「実行済み」と見なす

5.1 モジュール間の網羅をチェックする

　パス網羅が面倒なのは、対象となる命令語やパスが細かくて非常に多いためです。モジュールのように、対象がもっと大きく簡易なものになれば、網羅は簡単になります。全てのモジュールが1回はコールされたか、コールのパスは全て通ったかをチェックするだけでも、多くのバグが見つかります。

5.2 重要な機能に限定する

　プログラムの全ての命令語やパスを網羅しようとすると膨大な時間とコストがかかります。マキャベリズムで有名なニッコロ・マキャベリの有名な言葉、「分割して統治せよ（*6）」を応用し、重要な機能に限定してパス網羅を実施すれば、労力は一挙に減少します。あるいは、トリアージュのように、機能に「松」「竹」「梅」のように優先順位を付け、これに従って、パス網羅を実施することも考慮するといいでしょう。

*6： 英語では「Divide and conquer」。人類が作った物の中で、圧倒的に大きくて複雑なのがソフトウェア。複雑性を下げて、系統的に開発する方法が、機能を分割し、段階的に詳細化する「構造化技法」です。この基本思想は、「分割して統治せよ」と完全に同じです。

5.3 モジュールを限定する

　上記の「重要な機能に限定する」と同じ考え方は、モジュールに応用できます。重要なモジュール、いろいろな場所から呼び出される共通ルーティンに限定して、パス網羅を実施すると、意外に短時間で大きな効果が出ます。

5.4 エラー処理は1つと見なす

　テストで一番面倒なのが、異常処理系の検証です。ソースコードの半分が異常系のような気がします。異常系処理の細かいところまで網羅しようとするとものすごく大変ですが、異常系の処理部分のソースコード群を1つのブラックボックスと見なすと、パス網羅を単純化できます。

5.5 机上での実行も「実行済み」と見なす

　マシン上だけで実行してパスを網羅するのは大変です。実行のための条件をそろえるのが面倒な異常処理やタイミングに絡む処理は、机上で実行した分もカウントすることも考慮してはどうでしょう。

6. 終わりに

　全ての分野のプロは、時間当たりの生産物を最大にしたいと思っています。プログラマーは、その最たるものでしょう。パス網羅は、キチンとテストを実施でき、定量的に進捗度を把握できますが、効率はそれほどよくありません。パス網羅の長所を享受しつつ、うまく応用していただければと思います。

　次回は、パス網羅では避けて通れないツールの使い方を解説します。

【 筆者紹介 】

山浦 恒央（やまうら つねお）

東海大学 大学院 組込み技術研究科 非常勤講師（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科准教授、2016年より非常勤講師。

主な著書・訳書は、「Advances in Computers」 （Academic Press社、共著）、「ピープルウエア 第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ 第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。