ソフトの品質基準について

質問

Javaで開発したソースに対して単体テストを行います。
一般的に1ksあたり何項目のテストケース抽出が主流であり、1ksあたり何件のバグ抽出が妥当とされているのでしょうか？また、ブラックボックステスト時にも同様に基準があるのでしょうか？わかる方いらっしゃいますか？

回答No.2

lawson · ベストアンサー

※No1にの修正

正)
・
完全にプログラマの裁量で、

誤)
・
完全にプログラムの裁量で、

※No2の本文

>1ksあたり何件のバグ抽出が妥当とされているのでしょうか？また、

単体レベルのクセに
バグがあって妥当だなんて、変です。
よっぽど、スケジュールが厳しい時は
別にして、
そんな状態で、「できました」ということ
自体恥じです。

単体レベルであれば、
仕様漏れや、結合テストレベルに
ならないと、わからないような
バグ以外は、ほとんどゼロの状態まで
もっていくように
限られたスケジュールの中で
仕事をして、
週末の休みを勝ち取るために、
平日にがんばるものだと思います。

単体レベルで
つぶせて当然であるような
基本的な間違いが
たくさん、
残っていると、
結合テストや総合テストで
思うように、スケジュールが
すすまずに、四苦八苦してしまいます。

いろんなかたがたに迷惑をかけてしまいます。
いろんなかたがたが休日出勤してしまいます。

限られたスケジュールで
単体レベルの精度をあげるのは、
理論より、技術が大事だと思います。
プログラミングしなくても、
システムができるような、
人工知能のようなしくみが
できない限り
この考え方は
今も昔も未来も
かわらないと
私は思います。

あと、

>1ksあたり何件のバグ抽出が妥当とされているのでしょうか？また、

とありますが、
ks単位で
単体レベルの
テスト項目を抽出する
なんて、
頭が変になりそうです。
パターンが多すぎて・・・
すくなくとも、私の頭では、
無理です。

もっと小さい単位で
単体の確認すべきです。

多くのテストパターンの確認がとれた
信頼のおけるちいさな
ルーチンを使って、
また、別のルーチンを作って
いくような方法をとる
のがよいと思います。

回答No.1

lawson

そんなむずかしい話はよく知りません。

JAVAで開発する人は
そんな、ソフトウェア工学的な
かたい考え方はあまり、もっていないかもしれません。
JUnitなどのツールでテストするかもしれません。
単体テストレベルであれば、
完全にプログラムの裁量で、
処理ルーチンごとに確認作業をしながら、
作りこむでしょう。
他の処理のからみが激しい部分の
修正作業や、
複数の既存モジュールからアクセスされる
データ領域に対する更新処理等を
行ったときは、仲間と相談しながら、
デグレードの確認作業をするでしょう。

SEが結合テストや総合テストレベルで考えるようなものであれば、
テスト項目の抽出は重要です。

単体テストレベルであれば
メソッドのなどの小さい単位で
多くのパターンを試しながら、
段階的に開発するのが、
効率がよいと思います。

あってるのか、まちがっているのか
よく確認もせずに、いっきにたくさん
コードを書いて最後に
ドバっとテストする方法を
とると、確認すべきパターンが多すぎて、
効率悪いですよ。