単体テスト、結合テスト、テスト仕様はどこまで詰め込む？

今、テスト仕様書を作成しており、
みなさまのご意見が伺えたらと思って書き込みさせていただきました。

単体テスト、結合テストの仕様書を作っているのですが、
パターン数がやはりべらぼうに多いので、どこまでで
割り切るかで悩んでいます。
考えれば考えるほどパターン数は出てくるのですが、
それらを作る工数、テストする工数を考えると、
う～ん・・・という感じです。
１００％バグのないシステムを作ることは不可能で、
そのコストは∞とされていますが、可能な限りそうしたいのは
やまやまですが。
ある本には顧客が７０％を望んでいるなら開発としては７１％を達成できたらよく、それ以上を求めることは技術者のエゴと書いてありました。
確かにまずされない操作のテストパターンを大量に生成する時間があったら、クライアントはユーザビリティを上げるなどして欲しいはずです。
でも７０％ってどうやって決めたらいいのでしょう？
何でもいいので皆さんどうされているか、アドバイスいただけたら幸いです。

No.3 ベストアンサー 回答者： noname#107252 回答日時： 2009/11/26 19:32

　組み合わせが相当多いようですが、単体から総合において、組み合わせが多いということにわたしはまず設計の妥当性について危惧します。

システムは、設計が悪いと、いいプログラムを製造しても、全く意味ないものになり製造よりも設計というのがわたしの考えですが、といっても、多分、設計を見直すことができないのでしょう。ではどうするか。
　組合わせが多いのなら、わたしならば、まず直交表を用いてテストします。正常値、異常値、境界値ということも当然ですが、ユーザビリティーが悪いと、特に、これらの組み合わせが多くなりますね。ですから、すべては設計段階から、テスト仕様を書くことをお勧めします。設計に重点を置けば。そんなに組み合わせは多くなることはないでしょう。

この回答へのお礼

ご回答いただきましてありがとうございます。
直交表という便利なものがあるということを初めて知りました。
早速文献をさぐっておりますが、とても使えそうです。
ありがとうございます。

お礼日時：2009/11/26 23:48

No.2 回答者： okg00 回答日時： 2009/11/23 19:12

「契約書にどうあるか」って事が前提にあるような。

例えば、人の生死に関わるようなシステムでしたら「コストはかかってもよいからクオリティを」ってなるはずですし、「コストはそれなりで品質もそれなりに」ってなってるかもしれないし。私が携わっていたのは某官庁でしたから品質には厳しかったです。

まあ、「低いクオリティでよいです」っていう顧客もいないですから、「会社としてどうするか」っていう方針にも関わってきますね。プロマネの判断なのかなあ。

ただし、後工程でバグが発覚すると時間的にも工数的にもコストは跳ね上がりますから、できるだけ単体テストで抽出しておきたいですね。自分が関わっていたのは、単体テストではすべてのパターンを網羅しておいて、連動テスト以降は正常データで試すってやり方でした。

>まずされない操作のテストパターンを大量に生成する時間があったら
んー、エンジニアは「あまりないだろう」って思ってても現場ではそうでなかったりする事も多いですからね。効率よくいかにテストするかを考えた方がよいのでは。例えば、条件網羅をクリアする最低パターンを網羅するとか。
http://itpro.nikkeibp.co.jp/article/COLUMN/20060 …
http://sinzo.web.infoseek.co.jp/joho/kodogogo/03 …

この回答へのお礼

ご丁寧にご回答いただきましてありがとうございます。
ご紹介いただきましたＵＲＬもとても参考になりました。
まだまだ不勉強ですので、なんでも試してみたいと思います。
ありがとうございます。

お礼日時：2009/11/24 23:06

No.1 回答者： Wr5 回答日時： 2009/11/23 15:21

>パターン数がやはりべらぼうに多いので、どこまでで

>割り切るかで悩んでいます。

関数への引数や、条件分岐などの場合…
「正常値(正常な範囲にある任意の値)」、「異常値(エラー処理に流れる値…準正常ともいう？)」、「境界値(条件分岐に使用している値とその前後の値３パターン)」
とかでしょうか……。
正常値を全パターン潰す必要は無いでしょう。
UNITTEST(C-UNITなど)で半自動的に処理できるのであればよもかく…。

あとは、仕様書に記載されている分を重点的に…となるでしょう。
試験項目作成中に仕様書の漏れとか発見するかも知れませんが…それはしかるべきルートで問い合わせればよいでしょう。

この回答へのお礼

さっそくご回答いただきましてありがとうございます。
参考にさせていただきます。

お礼日時：2009/11/23 15:50