つれづれなる技術屋日記

しがない技術屋。専門は情報工学で、「つれづれ技術屋」って呼んで。

バグカーブの理想曲線

今朝のブログ(「コーダーとテスターのパラドックス」)に引き続き、バグカーブ関連。具体的な(理想的な)バグの累積曲線を考えてみた。 前提は、今朝と同じく以下。 ・バグは均一 ・ソフトの生産性(修正スピード)は一定 ・テスト件数のスピードは一定 以下の数値を設定するものとする。 ・全体行数(初期のソースコード行数) ・テスト密度(行辺りのテスト件数) ・単位時間(1日の最大)テスト件数 ・テストに対するバグ率 ちなみに、1バグに対する修正行は、テスト相当行数*バグ件数とする。 (テスト相当行数=テスト1件に相当する行数=テスト密度の逆数) 多少乱暴な仮定かも知れないが、修正とか修正確認などを考えると、それほどかけ離れているとも思えない。

f:id:honda-jimusyo:20200916115735p:plain


それをエクセルにしたのが左。(次の写真を含め、ダブルクリック等で拡大できる。) a2: =F1 b2: =IF(A2>(1/$F$2)*$F$3,$F$3,ROUNDUP(A2*$F$2,0)) c2: =ROUND($F$4*B2,0) a3: =A2-(B2-C2)*ROUNDUP(1/$F$2,0)
a15は、3960行のテストすべき行が残っており、1日10件のテストをしたので、100行分はテスト完了。ただし、バグが2件発生したので、その対策として20行テストすべき行として追加された事を意味する。(結果的に次の日=a16では、3880行のテストすべき行が残っていることを示す。)

f:id:honda-jimusyo:20200916115739p:plain終盤が左。テストすべき行数が減って、テスト件数も減る。(テスト出来る件数分テストしても良いけど)テストで見つかるバグ件数も減って、追加される修正行数も減ることになる。
横軸をテスト件数、縦軸を累積のバグ件数とすると、当初からほとんどが直線(1次曲線)となり、終盤が減衰する曲線となる。それを理想カーブとして良いかと思われる。(行数前提への意見とか色々あるかもしれないけど、行→FPなどの場合でも考え方は同じになると思う。) なお当然だけど、回帰分析などでカーブを求める場合、何らかの数式になっている方がよい。しかも、原点から連続したものが操作も楽である。今回示したカーブが、回帰分析で使えるような関数の格好になっていればいいのだが、すぐには見つかりそうにない。(もし判明したら、連絡もらえれば幸い。)  捕捉:カーブが求まらないか、少し考えてみた。

f:id:honda-jimusyo:20200916115743p:plainこちらは、終盤でのテスト件数やバグ件数を、整数化しなかったもの。

 

f:id:honda-jimusyo:20200916115732p:plainこちらも、テスト件数やバグ件数を整数化しなかったもの。ただし、初期の行数を調整して、終盤で一旦(テストと行数の関係で切りの良い)100行にしたもの。
2つの終盤で、整数化しないことではっきりするけど、テスト件数がバグ率による等比数列になっていく。バグ件数も、バグ率による等比数列になっていく。 なので、バグ件数は、 k*a^x の指数関数となる。kは、終盤(最大テスト件数を処理する必要のない段階)での初期の値で終盤の行数に依存する。今回のグラフの例だと1から9かな。aはバグ率。 (表の意味するxはテスト件数により離散的だけど、テスト件数をlimで1件などに考えて行けば、指数関数と考えてOKそう。) で、指数関数とすると、バグ件数の累積=積分も指数関数のカーブになる。(積分することで係数は違ってくる。特にバグ率は少数以下なので、係数がマイナスになることで上下反転する。)  終盤のバグ累積件数を指数関数で近似するのは悪くないだろうが、テスト開始からを指数関数で近似するのは多少無理があるかもしれない。なっ、この辺りになると、実際のデータでの近似曲線間の決定係数の比較になるだろう。 結構自分なりには、すっきりしたかな。

©2005-2020 ほんだ事務所(honda-jimusyo) All rights reserved.