- ベストアンサー
テスト仕様書作成時の単体テスト・結合テスト・テスト仕様の詰め込み具合について
- テスト仕様書作成時において、単体テストや結合テストの詳細な仕様をどこまで詰め込むべきかについて悩んでいます。
- パターン数が多くなりがちであるため、作成・テストのコストを考慮しながら、最適な範囲を決定したいです。
- 70%のテストカバレッジが開発目標とされていますが、この基準をどのように設定すればよいかアドバイスをいただきたいです。
- みんなの回答 (3)
- 専門家の回答
質問者が選んだベストアンサー
- ベストアンサー
組み合わせが相当多いようですが、単体から総合において、組み合わせが多いということにわたしはまず設計の妥当性について危惧します。システムは、設計が悪いと、いいプログラムを製造しても、全く意味ないものになり製造よりも設計というのがわたしの考えですが、といっても、多分、設計を見直すことができないのでしょう。ではどうするか。 組合わせが多いのなら、わたしならば、まず直交表を用いてテストします。正常値、異常値、境界値ということも当然ですが、ユーザビリティーが悪いと、特に、これらの組み合わせが多くなりますね。ですから、すべては設計段階から、テスト仕様を書くことをお勧めします。設計に重点を置けば。そんなに組み合わせは多くなることはないでしょう。
その他の回答 (2)
- okg00
- ベストアンサー率39% (1322/3338)
「契約書にどうあるか」って事が前提にあるような。 例えば、人の生死に関わるようなシステムでしたら「コストはかかってもよいからクオリティを」ってなるはずですし、「コストはそれなりで品質もそれなりに」ってなってるかもしれないし。私が携わっていたのは某官庁でしたから品質には厳しかったです。 まあ、「低いクオリティでよいです」っていう顧客もいないですから、「会社としてどうするか」っていう方針にも関わってきますね。プロマネの判断なのかなあ。 ただし、後工程でバグが発覚すると時間的にも工数的にもコストは跳ね上がりますから、できるだけ単体テストで抽出しておきたいですね。自分が関わっていたのは、単体テストではすべてのパターンを網羅しておいて、連動テスト以降は正常データで試すってやり方でした。 >まずされない操作のテストパターンを大量に生成する時間があったら んー、エンジニアは「あまりないだろう」って思ってても現場ではそうでなかったりする事も多いですからね。効率よくいかにテストするかを考えた方がよいのでは。例えば、条件網羅をクリアする最低パターンを網羅するとか。 http://itpro.nikkeibp.co.jp/article/COLUMN/20060418/235585/ http://sinzo.web.infoseek.co.jp/joho/kodogogo/03kaihatu/001/001.htm
お礼
ご丁寧にご回答いただきましてありがとうございます。 ご紹介いただきましたURLもとても参考になりました。 まだまだ不勉強ですので、なんでも試してみたいと思います。 ありがとうございます。
- Wr5
- ベストアンサー率53% (2173/4061)
>パターン数がやはりべらぼうに多いので、どこまでで >割り切るかで悩んでいます。 関数への引数や、条件分岐などの場合… 「正常値(正常な範囲にある任意の値)」、「異常値(エラー処理に流れる値…準正常ともいう?)」、「境界値(条件分岐に使用している値とその前後の値3パターン)」 とかでしょうか……。 正常値を全パターン潰す必要は無いでしょう。 UNITTEST(C-UNITなど)で半自動的に処理できるのであればよもかく…。 あとは、仕様書に記載されている分を重点的に…となるでしょう。 試験項目作成中に仕様書の漏れとか発見するかも知れませんが…それはしかるべきルートで問い合わせればよいでしょう。
お礼
さっそくご回答いただきましてありがとうございます。 参考にさせていただきます。
お礼
ご回答いただきましてありがとうございます。 直交表という便利なものがあるということを初めて知りました。 早速文献をさぐっておりますが、とても使えそうです。 ありがとうございます。