個人微信號是Shalayang，如下是個人二維碼名片，歡迎添加。編程
問題1：bug率有什麼做用？微信
my opion：用處有不少，須要具體狀況具體分析，不過主要做用通常是來評價工做產品的質量。若是bug率較高，說明系統質量較差，須要大量的返工。項目經理就須要作好缺陷分析（缺陷的類型、分佈、嚴重程度等），找出緣由，以便作好下一階段的缺陷預防工做。除此以外，還能夠結合其它方面的信息，判斷是否一些工做不充分。譬如，若是缺陷密度太低，有兩個緣由：可能工做產品質量確實高；也可能評審或測試不充分，更多的缺陷沒有發現。在某些公司，bug率也做爲項目度量考覈的一項指標。編程語言
問題2：bug率的計算公式是什麼？工具
流行的公式主要如下兩個：測試
觀點1、bug率=bug數/代碼行數編碼
觀點2、bug率=bug數/功能點數spa
my opion：.net
網上對於這兩個公式的爭議比較多，這個問題上，我的以爲不必爭哪一個纔是正道。說句惟心主義的話，存在便是合理，每一個公式都有他生存的環境和產生的根源，對於咱們須要用到它的時候，只須要根據公司須要進行擇優選擇就行了，不是嗎。設計
問題3：哪一種方法更有效，更合理可行呢？orm
my opion：
使用代碼行進行計算，優勢是能夠經過自動統計工具計算（特別是對於大型項目，確定會計算代碼行數），比較方便，因此該方法比較廣泛，是大多數公司或項目運用的計算方法。但它的缺點是受開發人能力影響大（畢竟不一樣開發人員的編碼能力不同），且不用編程語言差異較大。
使用功能點進行計算，優勢是計算方法適用性強，不一樣語言之間也有可比性，但缺點是參數較多，比較複雜，並且目前尚未比較方便的工具。其次，計算功能點雖然與開發人員的代碼能力無關，可是與計算功能點的人有關，對於沒有根基的人而言，能準確的計算出功能點也不是一件容易的事。並且功能點涉及的內容也比較多。
網上看過有人說到「功能點與不一樣語言的代碼行數之間有一個對應，能夠在統計出代碼行數後根據比例換算成功能點」， 具體對應關係是什麼我沒有查到，但願有知道的童鞋告知一下。
問題4：bug率計算公式中的bug數怎麼取值？
在看到上面的公式後，也許有人疑惑：
能很方便的統計出新版本變化的代碼行數嗎？
分子中的bug數是本次剩餘的bug數呢，仍是總共的bug數？
若是代碼行數爲總行數，那麼bug數就應該爲總的bug數呢？即全部bug的和呢？並且若是是總的bug數那麼對於後期的僅僅改錯的階段而言，可能代碼的增長會不多，可是這時bug數會不斷增長，這樣一來，bug率豈不是在不斷的升高？可是按常理而言是應該減小的呀，應該越到後期bug率越小纔對，是不？
或者bug數取剩餘的bug總數（上幾個版本剩餘未修改的bug和本版本的新bug）呢？而代碼行數仍然是總的代碼行數。這樣是否是有問題呢？
解惑：
一、代碼統計工不少都能作到新舊兩個版本對比,很容易獲得版本變化的代碼行數.
2-三、那就看你用這個度量項來講明什麼問題：若是是評價新增代碼的質量，那不該該包括之前未解決的Bug，能夠用「新增的bug數/新增+修改+刪除代碼行數」，若是是當前版本的整個系統的代碼質量-----總的bug數/總代碼行數。
四、這個就是至關於統計bug收斂率了。
是這樣嗎？
問題5：對於迭代方式開發的缺陷統計怎麼作？
如今有不少項目是採用迭代的方式來進行的，每次可能添加的代碼部分比較少，那如何來計算其bug率呢？是用新增的bug數/新增的代碼行數？仍是總的bug數/ 總的代碼行數？
my opion：
採用何種統計策略，還要看該統計項目的，若是用於評價新開發工做的質量，那就不能把原有系統缺陷統計在內；若是不做爲評價新的開發工做，那就都統計在一塊兒（譬若有的只是跟蹤版本質量）。
每個統計項都應有它的目的，不該該機械地去作統計，還要看設計該統計項的目的是什麼。
本文分享自微信公衆號 - 軟件測試經驗與教訓（udatest）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。