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

網羅しようにもできないからです。

網羅テストできないシステムは目の前にたくさんあります。

今日はひとつだけ例を挙げます。

例：『数学的演算を含むもの』

例えばintとintの足し算をする関数があるとして、網羅テストはできませんね。

入力と出力の定義域から、端っこと真ん中と後二つくらい特異点を選んで5点ずつ、などと勝手に丸めるのは網羅テストとは言いません。

こういうことを書くと、

そんなこといってたら、CPUの加算命令だってテストしなきゃいけないのかよ

と激昂する人が10人に1人くらいおられます。

CPUどころか、ただのメモリを2GB積むだけで、おかしなバグに悩まされること間違いなしなのです。

HPCに必須のECCメモリ

http://www.hpc.co.jp/hit/support/ecc_memory.html

網羅テストから話がずれました。戻します。

そして、こんなことを言う人もいます。

intとintの加算の網羅？

それこそ「OKになると分かりきってるやるだけムダなテスト」じゃねぇか

しかしですね。たとえば足し算の対象が金額などの場合、

その組み合わせはテストしてませんでした

ではすまない場合があります。

自動販売機系はマジでやばいです。缶飲料のように、商品の金額と投入できる金額の最大が決まっている場合は、それでもまだ網羅が可能です。

しかし駅の券売機は、もうお手上げです。投入金額も大きいですし、買う切符の金額の種類も多く、さらに複数枚数や小人用など分岐が多すぎます。

それらを順列組み合わせで網羅するととてつもないコストがかかってしまいます。これは品質工学の直交表のサンプルとして、券売機が出てくる理由にもなっていると思います。

実務テスターの多くが、さまざまのポリシーや方針に従って、「端折って」います。

それら多くのポリシーや方針が、属する組織や団体の色を出すと言えばソレまでですが、ある程度の客観性と明文化が無いと、結局は

勘と経験に頼ったデバッグ

と同じ低いレベルに陥ってしまうと思います。

せっかくヒトモノカネを使ってテストするのであれば、綺麗に引いたレールの上で作業したいものですね。

なお、金額を扱うプログラムで32ビットintなどというものを用いるのは余程簡易的なものでないかぎりオススメできません。理由は最大値を円で表せばすぐに分かります。

リンク

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

IGINブルネイ/syasudaの日記(MT版)