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

面向方面編程（AOP）是項大有前途的新技術，但是采用新技術可能有風險（當然，不 采用新技術也會有風險）。與所有的新技術一樣，通常來說，最好是沿著一條可以管理風險的路徑來采用它們。如果用 AOP 來執行策略和測試，就可以從 AOP 得到降低風險的好處。因為方面不會進入生產，所以不會出現技術破壞代碼穩定性或開發過程的風險，但卻會有助于開發質量更好的軟件。用方面進行測試也是學習方面的工作方式，并體驗這項激動人心的新技術的好方法。

組合測試方法

正如我在 第 1 部分 中討論過的，QA 的目的不是找到所有可能有的 bug —— 因為這是不可能的 —— 而是提升我們對代碼按預期工作的確信程度。對于管理有效的 QA 組織，它的挑戰就是最大化所花費資源的回報，即確信度。因為所有的測試方法最終都會表現出回報消退（對于等量的付出增加，得到的確信度增加越來越少），而且不同的方法適合尋找不同類型的錯誤，所以把 QA 付出分散在測試、代碼審查和靜態分析上，要比把整個 QA 預算只花在其中一項措施上，回報要更好。

FindBugs 這樣的靜態分析工具是不精確的，但是不精確的分析對于提高軟件質量仍然是非常有用和有效的。它們可能發出假警告，例如在無害的構造上觸發警告，也可能忽略了 bug，例如沒有找出與特定 bug 模式匹配的全部 bug。但是它們仍然能發現真正的 bug，而且只要誤報率沒有高到讓用戶厭煩的程度，那么它們仍然對測試付出提供了有價值的回報。

從測試的角度來說，使用 AOP 來驗證設計規則與使用靜態分析有許多共同之處。靜態分析和面向方面編程都不用為了特定的方法或類設計測試用例，而是都鼓勵找出違犯規則的全部分類，并創建能夠發現代碼體中任何違規的工件。另一個相似性就是它們不必非常完善也能夠發揮作用；盡管 bug 探測器或測試方面都不能找出所有可能的 bug，甚至有些會發出假警告，它們仍然是非常有用的工具，可以驗證代碼是否按期望的那樣工作。有些 bug 模式用靜態工具更容易找出，而另一些用方面會更容易找出 —— 這使得方面成為參與 QA 過程的一個有用的方法。

簡單的測試方面

FindBugs 這樣的靜態分析工具審計代碼但不執行代碼；面向方面的工具既提供靜態類工具，也提供動態類工具。靜態方面可以生成編譯時警告或錯誤；動態方面可以把錯誤檢測代碼插入類。

在 第 1 部分 中，我提供了一個簡單的 FindBugs 探測器，查找可能潛伏在庫中的對 System.gc() 的調用。靜態分析能探測的許多 bug 模式（包括這個模式）也能被方面探測到；根據具體的 bug 模式，用靜態分析或用方面來做可能會更容易，所以把它們都放在工具庫中，可以提高效果。

清單 1 顯示了一個簡單的動態方面，在要調用 System.gc() 時，拋出 AssertionError。（因為這類 bug 探測器的一個重要作用是不僅要找到您自己代碼中的錯誤，還要找到代碼依賴的庫中的錯誤，所以可能需要告訴工具還要分析或處理這些庫。）