網羅テストがなぜだめなのか

  • 投稿日:
  • by



あるモジュールにバグが10個含まれているとします。


この絶対数はあらかじめ知ることはできませんが、推定したり見積もったりすることはできます。


# 白いカラスはいないと証明できない


# 詳細は「白いカラス」でぐぐれば分かります。


さて、この10個を摘出するためのテストを計画しましょう。



計画A


全パス、全変数の定義域の総当りをチェックします。


テスト項目は25,000項目。そのうち20,000は単体テストフレームワークによる自動化テスト。


残りは人海戦術で5人月。




計画B


プロジェクトの性質と過去の傾向から分析して、摘出率が高そうなテストに絞って実行します。


テスト項目は200程度、半自動で1人月です。



計画Aではバグが9個摘出されました。計画Bでは8個です。


これらの結果について考察してみて下さい。


ポイントは以下に挙げます。



  • 計画Aにおいて、結果がOKになると分かっている大多数のテストにかかるコストは本当に必要なのか?

  • 網羅テストしたのに10個摘出できない理由として考えられるのは何か?

  • 計画Bにもっとコストをかければ、9個目も摘出できるのか?計画Aと同じくらいかければどうか?

  • 通りすがりのテスタは計画Bを立案できないのではないか?



開発者が『全部網羅した』と報告するときそれは100%ウソです。開発者が自分で気づいた項目について全て網羅しただけのことです。


例えばmallocが失敗することがあるということを知らない開発者とfopenが実はバグ満載だと知っている開発者では、真の網羅性はぜんぜん違いますので。



この真の網羅性にまつわるエトセトラが白いカラスはいないという命題なのです。