前一講我們提到了一些廣為統計,但是實際上卻可能沒有指導意義的資料。那麼這一講,我們將來闡述那些需要統計並對項目產生積極影響的資料。
一般來說,軟體項目最關心的就是Quality (品質)、Cost (成本)、 Delivery(交貨期)。管理者希望以不同的角度,不同的形式通過資料形式將這些屬性展示出來。那麼我們所統計的資料也就是圍繞著三方面的。而同時,我們也要關係這些資料將為未來的改進提供什麼樣的協助。
1.循環複雜度
循環複雜度無疑是衡量軟體品質的一個指標。循環複雜度有現成的工具來統計。C#.Net的NUnit,Java的Google Code Pro*,Matrix等都可以統計這個資料。循環複雜度的推薦指標為不超過10。超過10的代碼應該被改進。而過分的求低可能從ROI(投資報酬率)上來說不一定值得。
2. 平均Bug修複時間
和統計Bug收斂趨勢,Bug數量,二次Bug率,Bug分布,Bug原因統計等不同,統計平均Bug修複時間有助於瞭解組織在市場中的競爭力。Bug平均修複時間越短說明發布的周期越短,組織也就越具有競爭力。Bug修複的時間應該從Bug登記開始計算,到Bug被徹底修複(即通過已知的全集測試沒有測試出二次Bug)為止。這其中還包括等待時間,測試時間,所以想要有短的Bug修複時間,就需要有好的測試機制。關於如何建立好的迴歸測試機制,在以後的章節中將會詳細討論,這裡只強調為了能夠縮短Bug平均修複時間必須採用自動化測試。
3. 測試覆蓋率
測試覆蓋率說明了測試的覆蓋程度,但是現在的測試載入器基本上只能在C0層級上給出資料。而且,代碼被執行了並不代表代碼被測試了。所以,現在的測試覆蓋率統計工具的資料只能作為參考。為了能夠更好地掌握測試覆蓋程度,測試代碼的複查是不可或缺的。為了能夠保障測試的品質應該儘可能的增多不同類別的測試案例。對於測試類別的涵蓋程度也是比較重要的審核方面。為了能夠更好地說明這個問題,舉例如下:
對於一個只能夠輸入正整數的文字框的校正測試應該有哪些測試資料這個問題,很多人給出的答案僅限於,整數、小數、正數、負數、0等幾個條件。
實際上,下面這些也是至關重要的測試案例:
a. 中文、日文、韓文、法文、英文、羅馬字等各種語言的數字。例如:quatre
b. 半形、全形的數字。例如:8
c. 帶括弧、帶圓圈的數字。例如:㈥⑦
d. 帶加號的數字。例如:+6
e. 分數。例如:3/5
f. 科學計數法。例如:2e5
g.符號。例如:$
h.英文。例如:ask
i.8進位,16進位數字。例如:0x52, FF,
j.以小數點結尾的數字,例如:2.
k.最大值與最小值:例如:Integer.MAX,Integer.MIN
l.百分比。例如37%
4. 測試案例數量
測試案例的數量可以反映測試的力度。
5. 到完成任務所需要的時間
這是用來取代百分比進度報告的。前文已經討論過百分比進度報告無法給出足夠的資訊。到完成任務所需要的時間是一個可調整的數字,今天估算剩餘工時是10小時,經過了8小時,明天應該還剩餘2小時,但是由於今天開會等原因,可以剩餘4小時。這樣的數字往往比較準確。注意,其值不宜超過20小時,如果超過,應該考慮將任務分解。另外,當任務發現有估算條件遺漏時,可以對數字進行擴大,即,今天估算的剩餘工時為10小時,經過了8小時之後,原來應該為2小時,但是由於發現一塊重大遺漏,可以變為12小時。至於什麼原因導致遺漏是另外需要解決的問題,但是就工時和進度本身,通過這樣的資料統計就可以更為準確的把握了。
6. 進度偏差
實際的議程和計劃之間有什麼樣的偏差。這樣可以為調整進度或者削減功能提供參考依據。
7. 所用工時
所用工時應該單獨列出。尤其是對於逾時工作的情況。逾時工作(加班)往往帶來負面效果。進行實際情況的統計,並且分析投入的工時和產出的價值之間的關係。如果加班時間超過了法定的上限就是一件更為嚴重的事情。
8. 投入和預算之間的偏差
項目的投入不僅僅包括工時上的投入,還包括因為項目開發需要所產生的機器裝置折舊、房租、通訊費、差旅費、交通費、項目活動經費、採購的軟硬體設施費、外包費、諮詢費等各種費用。這些實際花費的費用和當初的預算費用之間的關係究竟如何。如果忘記了某些費用,下次應該如何改進。
9. 程式碼數
統計這個不是為了計算Bug密度、測試密度、生產效率的。前文已經說過。統計這個是為了瞭解代碼規模,進而瞭解代碼是否有些臃腫。可以通過對比類似項目的程式碼數來看技術上是否得到了改進。例如:某30萬行代碼的項目,改寫之後程式碼數為3萬。