Java 理論與實踐: 平衡測試，第 1 部分

對于許多團隊來說，單元測試現在是開發過程的一個主要部分；JUnit 之類的框架可以進行無損測試，盡管我們并不喜歡它，寧愿為某些 代碼編寫某些 測試。單元測試運行效率很低，只能測試單個代碼片段，并且，一般情況下，測試代碼的重用性通常很也低 —— 昨天為組件 A 編寫的測試不能很好地用于測試組件 B（示例代碼除外）。

典型的單元測試場景

在發現 bug 時，要做的第一件事是什么？您可能只是想去修復它，但是，在長時間的運行中，這不是一個最有效的方法。在許多開發部門中，處理 bug 的過程如下：

針對 bug 編寫測試用例
確保測試用例在遇到 bug 時運行失敗
修復 bug
確保測試用例通過
確保其他測試套件仍能通過
檢查修正和測試用例，形成版本控制
將修正記錄在 bug 跟蹤系統中
盡管此方法在短期內比僅修復 bug 要多做許多工作，但它提供了許多更有價值的東西：獲得修復 bug 的更多信心，因為您已經對它進行了測試；獲得 bug 將不會再出現的更多信心，因為測試用例是回歸測試套件的一部分。在版本控制系統和 bug 跟蹤系統之間，還可以獲得一個記錄，該記錄描述了 bug 是什么以及如何修復它 —— 這是非常有用的信息，其他人會從中受益。

如果進取心較強，那么可以思考一下 bug 是怎樣出現的，并在其他位置查找同一錯誤。如果在別處發現同一錯誤，那么可以對這些 bug 進行測試和修復。單元測試作為質量管理工具的主要弱點是每個測試用例只能測試一個代碼片段。因為測試用例是專為每個組件和每個潛在錯誤模式設計的，所以只有編寫足夠多的單元測試才能測試大量的產品，這非常耗時并且代價高昂。

QA 經濟

測試是一種基本的質量管理工具，我們知道僅有多組測試用例還不足以找出復雜軟件片段中的所有 bug。事實上，對于任何優秀程序而言，“查找所有 bug” 是不可能實現的目標。據估計，NASA 向每個開發人員提供了 20 個測試程序（大大超過任何商業實體）來負責質量評價 (QA) —— 但軟件仍有缺陷。因此，質量評價的目標不應是查找所有的 bug，因為這是不可能的。相反，質量評價的目標應該是提高代碼運行良好的信心，從而最大程度地提供可用資源。

要高效運行質量評估量 (QA)，則需要對可用 QA 方法中的可用資源做預算，這樣才能最大限度地提高信心。覆蓋范圍大的測試套件可以提高我們對代碼使用的信心，因為它進行了一次徹底的代碼審查。執行兩次比執行一次較果好，因為每次都會發現另一次可能錯過的錯誤。兩次同樣遵循收益遞減規則，所以測試價值為 X 美元和代碼審查價值為 Y 的 QA 計劃要比價值為 X+Y 的任何一次測試或代碼審查的效果好。

添加靜態分析

靜態分析是在不運行代碼的情況下對其進行分析的過程，它與進行前面的代碼審查時我們執行的操作非常相似，或者與標記可疑結構時 IDE 執行的操作非常相似。靜態分析是添加到 QA 混合（QA mix）中的一項優良技術，因為它擅長查找其他方法（如測試和代碼審查）可能錯過的錯誤。靜態分析相對比較容易一些，不像單元測試那樣必須為要測試的每個類重新編寫測試，您可以在任何代碼上運行靜態分析工具。

FindBugs 是一種開放源碼的靜態分析工具，它包含用于許多常見 bug 模式的 bug 模式檢測器，令人驚訝的是，即使在測試良好的軟件中，FindBugs 也常常會發現一些 “沉默” 的 bug，但是單元測試和專業代碼審查都可能錯過這些 bug。FindBugs 還允許編寫新的 bug 模式檢測器，并將它們包裝為插件，所以如果一組標準的檢測器不能按您的需要執行，那么您可以很容易地編寫自已的檢測器。此擴展性使 FindBugs 成為非常強大的質量管理工具，因為當發現新類型的錯誤時，可以針對該錯誤編寫檢測器，并在整個代碼基址中搜索該錯誤。

靜態分析的主要作用是分析輸出，并確定報告的條目是真的 bug 還是假警報。編寫的部分優秀分析工具或 bug 模式檢測器會管理誤報率；核心 FindBugs 包中的檢測器已經進行了調優，目的是使誤報率不超過 50 ％，這樣分析輸出時不會有太多的煩麻。（將此閾值與針對 C 的 lint-like 工具進行比較，后者常常發出許多假警報，使用時相當耗時。）