防御性編碼和單元測試“交通規則”

領測軟件測試網

級別：入門

Scott A. Will(sawill@us.ibm.com), 經理，質量保證和系統測試，IBM Corporation/Tivoli Systems Software
Theodore F. Rivera(trivera@us.ibm.com), 產品開發經理，質量保證，IBM Corporation/Tivoli Systems Software
Adam Tate(atate@us.ibm.com), 經理，質量保證和總體解決方案測試，IBM Corporation/Tivoli Systems Software

2004 年 1 月

開發人員編寫代碼。不幸的是，開發人員也編寫缺陷，其中大多數缺陷是在最初的編碼階段加入的。修復這些缺陷成本最低的地方同樣也是在開發的初始階段。如果等到功能測試或者系統測試來捕獲并修復缺陷，那么您的軟件開發成本就會高得多。在本文中，作者 Scott Will、Ted Rivera 和 Adam Tate 討論了一些基本的“防御性”編碼和單元測試實踐，讓開發人員更容易找到缺陷 —— 更重要的是，從一開始預防缺陷產生。

我們三個人的家中有四個青少年駕駛員，很快還會增加一個。不用說，我們非常熟悉在駕駛員培訓班中灌輸給我們這些新駕駛員的防御性駕駛技術。因為在我們的青少年駕駛員短短的開車期間，他們看到了打手機的男人闖紅燈、女人在拐彎的時候化妝，以及業務主管在早晨上班的路上讀報。所以孩子們很快學會如何注意可能會發生事故的區域以及如何避免這些事故。

防御性駕駛和防御性開發
大多數司機接受過防御性駕駛技術的教育 —— 這有很好的理由 —— 但是并不是所有開發人員都接受過防御性開發的教育，特別是那些沒有用匯編語言進行過多少開發（如果不是完全沒用過的話）、也沒有因內存約束和處理器限制而關心過編寫極其緊湊的代碼的年輕開發人員。本文討論防御性編碼和單元測試概念，它們可以幫助開發人員更快生成更好的代碼并且缺陷更少。

為什么防御性開發是重要的？
捕捉錯誤、問題和缺陷的最佳位置是在開發周期的早期。圖 1 展示了最容易出現缺陷的地方，以及最容易發現它們的地方，并包括了修復這些缺陷的成本（這些成本是針對 1996 年的 —— 今天的成本顯然更高）。

圖 1. 缺陷：引入階段及發現階段（包括成本）

當然，比在編碼階段找到缺陷更好的是在一開始就防止它們。防止缺陷應該是開發人員最優先考慮的。我們將分析幾個讓開發人員可以在編碼和單元測試時防止并檢測缺陷的簡單的、經過證明的方法。

在編譯前（防御性設計考慮）
防止缺陷（特別是系統性缺陷）的最有效方式是仔細檢查編碼所依據的設計。由設計缺陷導致的缺陷 —— 雖然一般不是很多 —— 通常修補成本是最高的。事前花很少的時間針對以下幾點對設計進行檢查可以得到顯著的長期回報。

設計考慮
設計是否有任何不清楚或者混亂的部分？如果是的話，在編寫任何代碼之前澄清這些問題。否則，您可能以一種方式解釋一個設計需求，而同事則以另一種方式解釋它，從而得到不兼容的實現。

如果您的代碼要訪問同時被其他組件訪問的數據，那么保證您的設計可以處理這種情況。同時，檢查設計的安全問題（請參閱參考資料）。

文章來源于領測軟件測試網 http://www.kjueaiud.com/

TAG: 編碼 單元 防御性 交通規則