プログラミングの開発を何年も行い、コーディングにも慣れてくると、"バグを無くしたい"と誰もが思うのではないでしょうか。バグにより徹夜して直した、なんていう苦い経験をした方も多いと思います。
今回はバグについての考え方やバグを見つける方法について記載したいと思います。
まず、"ソフトウェアにバグがないと証明することは不可能"
と証明されています。これは事実ですので、バグがないソフトウェアを作るのは無理です、というか証明できません。組み合わせ、タイミング等、無限ですので、全てを確認することは不可能なのです。
私たちが考えなければならないのは、全てのバグを見つけるということではなく、効率的にバグを見つけることです。そして、ユーザーが不便に思うようなバグがないソフトウェアを作ることです。
私もいろいろと効率的にバグを見つける手法はないか、考えてきました。大企業であれば、評価専門部署があり、十分に評価に時間や工数が使えるのかもしれませんが、中小企業ではそんな時間、工数をかける余裕はありません。
今回は私が有効だと思ったあまり時間をかけずに、大きく効果がある評価手法を紹介したいと思います。
同値分割、境界値分析
バグが発生する場所はある程度決まっていると思います。例えば、下記のような判定文があったとします。
if( 3 < num < 10 ){
...}
このとき、3、4、9、10という4パターンでテストをし、問題なければこの処理はたぶん問題ないと言えます(完全にバグがないとは言い切れないのでたぶんという枕詞を付けています)。これが境界値の考え方です。
ソフトウェアはデジタルですので、3以下、4～9、10以上の3つのグループに分けることができ、そのグループは同じ動作をすると考えられます。4でバグが見つかったのなら、ほかの5、6、7、8、9でも同じバグが発生するはずです。これが同値分解の考え方です。
この2つの方法を組み合わせて、テストパターンを考えると、少ないテストパターンでかつ効率的にバグを見つけることが可能になります。
All Pair法
ソフトウェアはとにかく複雑で、パラメータがどうしても多くなります。全パラメータの組み合わせでテストすることはほぼ不可能です。そんな時に便利なのが、All Pair法です。
2つのパラメータの組み合わせを全て網羅することで、約9割程度バグがないことを保証できるという手法です。3つ以上のパラメータの組み合わせで数パーセントバグが発生する可能性があるかもしれませんが、発生頻度も少ないことが多く、それは諦めるという考え方です。
そもそも全パラメータを確認することは現実的にできないので、2つのパラメータの組み合わせで9割以上の動作保証しで良しとします。
All PairはPICTというツールで簡単にパラメータの組み合わせを作ることができますので、興味のある方は試してみてください。
バグがないコードを積みげていく
バグというものは本当にやっかいですね。絶対に動くと思うような修正をして、全く動作確認をせずにビルドすると、動かないなんてことが本当によくあります。面倒くさがらず、必ず1回は実際に動かしてみないとダメです。これも大事なことだと思います。
バグがあると2度手間になりますので、急がば回れ、で確認しながら着実に動くコードを積み上げていくことが大切だと思います
