|
構造的、体系的にテストすることで少ない手間で効果的なテストができる。
１．テストの目的
テストはいったい何のためにやるのでしょうか？
E.W.Dijkstra（ダイクストラ）は次のように言っています。
「テストでプログラム中のバグの存在は示せても、バグが存在しないことは示しえない。」
つまり、プログラムが正しく動作することを証明する手段はないということです。
いくらテストしても、プログラムが正しく動作することの証明にはなりません。
そもそもプログラムの仕様自体が間違っている場合もあります。
でも、誤り（バグ）は、それを示せば、存在を証明できます。
テストで見つけられるのはプログラム内の誤りだけなのです。
ただ、言えるのは誤り（バグ）を見つければ見つけるほどプログラムの品質が向上したことになり、
誤動作する可能性が減ります。
これがテストの目的なのです。
たくさんの誤り（バグ）を見つければ見つけるほど、テストは本来の目的に貢献しているのです。
これはちょっと盲点ではないでしょうか？
さて、効果的なテストは多くのバグを見つけることだとすると、いくつかの問題が出てきます。
・テストにおける問題点１：
プログラムにバグがないように作るのと、テストでバグを見つけることは矛盾する行動です。
積極的にバグを見つけることをプログラマに動機付けできるでしょうか。
誰しも自分の作品にケチを付けるのはイヤなことです。
できればバグが少ないことを確認したいと思うでしょう。
これではテストの目的は達成できなくなります。
この解決法は？
プログラム開発者（または組織）とテスト担当者（または組織）を別々にします。
これならテスト担当者は張り切ってバグを見つけるはずです。
それがテストのミッションだからです。
またプログラマも他人がテストするわけですから、コーディングに緊張感がでます。
・テストにおける問題点２：
テストでバグがもう見つからないとき、
（１）プログラムの品質は高いと確信できるでしょうか？
（２）テスト方法に問題があり、バグを叩き出せないのではないでしょうか？
どちらかなのか判断できないという問題があります。
この解決方法はちょっと難しいです。
プログラムの品質が、もうだいじょうぶという判断材料を与える手段は
色々あります。
（１）検査進捗曲線・・・テスト進捗状況と品質の判定ができます。
（２）不良件数見積・・・テストの終了判定の指針を与えます。
（３）カバーレッジ・・・機械的にテスト完了の判断材料を与えます。
ただし、最初に述べたように品質を保証する完璧な方法は存在しません。
これらの方法は各々、欠点も持っています。
使用に当たっては経験者の判断が必要であることを忘れないで下さい。
・テストにおける問題点３：
バグをたくさん見つけるには、どのようなテストをすれば良いのでしょうか？
何をどうテストすればよいのでしょうか？
またテスト件数の目標値はどの位が妥当なのでしょうか。
この解決方法として、いくつかの効果的なテスト手法があります。
ここでは私がいつも実践している手法を御紹介致します。
・トップダウン・テスト法・・・プログラムを上位機能からテストします。
・効果的テスト手法・・・・・・最も効果的なテストケースを設計します。
特に効果的テスト手法はいくつかの方法論をカスタマイズし、
私が実際の開発で使用しているものを次回以降、御紹介致します。
|
コメント（0）
