[個體軟體過程]之缺陷管理--程式碼複查 (轉)[@more@]

第四章

u  什麼是缺陷:namespace prefix = o ns = "urn:schemas--com::office" />

u  缺陷查詢技術

u  程式碼複查

u  缺陷預測

4.3 程式碼複查

程式碼複查就是研究，並從中發現錯誤。程式碼複查更有效的原因是：在複查時看到的是問題本身而不是徵兆。從頭到尾複查程式碼時，考慮的是應該做什麼。因此，當看到某些地方不正確時，就可以看到可能的問題是什麼，並立即去驗證程式碼。複查的缺點是：非常耗時，而且很難恰當的進行；複查時一種技能，當然可以透過學習和實踐來提高。

程式碼複查的第一步是瞭解自己引入的缺陷的種類，這是收集缺陷資料的主要原因。因為在下一個程式中引入的缺陷種類一般會與前面的基本類似，只要採用同樣的開發方法，情況會一直如此。另一方面來說，當你有了技能和或改變了過程，缺陷的型別和數目會隨之變化。但是到了一定程度後，改進就變得非常困難了。這是，就必須研究缺陷，這可以幫助你找到更好的發現和修復缺陷的方法。

如何進行程式碼複查。程式碼複查的目標是在軟體過程中儘可能早和儘可能多的發現缺陷，缺陷發現時間越少越好。採用表4.3描述的一個有序的檢查方法，在編譯之前進行程式碼複查，是完成目標最好的方法。

  表4.3  程式碼複查指令碼

入口條件

在複查前，檢查下列產品是否已經準備好：

u  需求規格說明；

u  文件；

u  程式的原始碼清單；

u  編碼標準；

u  程式碼複查檢查表；

一般性說明

使用程式碼複查檢查表；

在複查時遵照程式碼複查檢查表的使用說明；

在複查結束時，填寫累計、累計百分比和總結欄目；

1  複查規程

首先，完成源程式編碼；

然後，在進行編譯和測試之前，列印一份源程式清單；

下一步，進行程式碼複查；

進行程式碼複查時，仔細檢查每一行源程式，以儘可能多地發現和修復缺陷；

2  修復缺陷

修復所發現的每一個缺陷；

確保所作的修復正確無誤；

將缺陷登入在缺陷記錄日誌。

3  覆蓋率複查

驗證程式設計覆蓋了需求規格說明中描述的每一個功能；

驗證程式程式碼實現了所有的設計。

4  程式邏輯複查

驗證程式設計在邏輯上是正確的；

驗證程式程式碼正確的實現了設計中的邏輯。

5  命名和型別檢查

驗證所有的名字和型別已經正確的宣告；

檢查整型、長整型和浮點型是否正確宣告。

6  變數檢查

確保每個變數已初始化；

檢查上溢、下溢或越界問題。

7  程式語法檢查

驗證程式程式碼符合語言的規格說明

 出口條件

在複查結束時，應該有：

完整的、修復過的源程式清單；

填寫完整的時間記錄日誌；

填寫完成的缺陷記錄日誌。

 

編譯之前進行復查。有幾個原因說明應在編譯之前進行程式碼複查：不論編譯前或編譯後，進行完整的程式碼複查的時間大約相同；不論編譯前或編譯後，對檢查語法有效性的效果是一樣的；先做複查將節省大量編譯時間，若不做程式碼複查，一般要花12％～15％的開發時間進行編譯，一旦使用程式碼複查後，編譯時間可以縮短至3％或更少；編譯程式後，程式碼一般複查很難徹底的進行； 經驗證明，在編譯階段有大量的缺陷時，一般在測試階段也有許多缺陷。

建立個人程式碼複查檢查表。如果想發現和改正程式中的每一個缺陷，就必須遵照一個精確的規程。檢查表可以確保遵循這個規程，它包括一系列程式的步驟。按照檢查表去作時，就知道如何進行程式碼複查。

如果能夠正確使用檢查表，還能知道每個步驟發現了多少缺陷。這樣就能測量出複查過程的，並進一步改進檢查表。檢查表包括了個人的經驗。透過不斷的使用和改進個人檢查表，就可以幫助你用較少的時間發現這些缺陷。表4.4是一個C++程式程式碼複查表的範例。