必須說明的是，對這本《軟件測試方法和技術》，我個人的評價應該是不錯的，在體系結構和組織上都比較清晰，包含的內容也比較完整。缺點可能是過于中規中舉了（個人看法：）），和國內的其他教科書一樣，沒有多少引申和深入的描述。因此，本文僅用來闡述個人對單元測試的觀點，不涉及任何對該書或是作者的評價。
《軟件測試方法和技術》中對單元測試的描述原文如下（P86）：
“單元測試是對軟件基本組成單元的測試。單元測試的對象是軟件設計的最小單位——模塊。很多參考書中將單元測試的概念誤導為一個具體函數或一個類的方法。一個最小的單元應該有明確的功能、性能定義、接口定義而且可以清晰地與其他單元區分開來。一個菜單、一個顯示界面或者能夠獨立完成的具體功能都可以是一個單元。某種意義上單元的概念已經擴展為組件（component）�！�
其實這里的觀點我大部分都同意，就是對“很多參考書中將單元測試的概念誤導為一個具體函數或一個類的方法”的說法有些存疑。毫無疑問，作者的觀點是，單元測試不應該是針對具體函數和類的方法的測試，接下來作者說明了他對單元的理解：“一個最小的單元應該有明確的功能、性能定義、接口定義而且可以清晰地與其他單元區分開來”，對這個單元的理解我完全同意，但困擾我的就是，我并沒有從這個定義中看出來一個具體函數不能作為單元測試中“單元”的理由。這段文字中提到單元是“具有明確的功能定義、性能定義、接口定義”，那我們來看看一個具體的函數，例如，C語言中的printf函數，一樣可以套用這樣的定義：
printf函數
功能定義：將輸入參數按照制定的格式打印輸出
性能定義：（略，不同平臺上應該有不同的性能標準）
接口定義：可用函數的參數作為函數對外的接口
另外，這段文字中提到的“一個菜單、一個顯示界面或者能夠獨立完成的具體功能都可以是一個單元”，在我看來仍然有些含糊——具體什么才是“能夠獨立完成的具體功能”，我想這里的“功能”不可能對應到具體的用戶需求中的功能，而是指設計中體現的功能，如果是這個概念，那么一個函數毫無疑問是具有功能的。
為了慎重，我特地查閱了一些經典的軟件測試書和定義中的單元測試內容，以下是引用和我的理解。
swebok 2004應該算得上是軟件工程領域的權威性文檔了，其中對unit testing的定義如下：
“Unit testing verifies the functioning in isolation of software pieces which are separately testable. Depending on the context, these could be the individual subprograms or a larger component made of tightly related units.”
從這里可以看到，swebok 2004對unit的定義具有這些特性：一個單元是一個“software pieces”，具有“separately testable”的特性，從這個角度來說，并沒有任何理由支持一個函數不能是單元測試對象的論據。而且，swebok 2004還明確說明了，在不同的上下文中，unit可以是子程序，也可以是緊密聯系的一些單元組成的component。
《統一軟件開發過程》中也對單元測試進行了描述（P223）：
“執行單元測試的目的是為了把已實現的構件作為個體單元進行測試，主要有以下幾類單元測試：
規格說明測試（specification testing）或“黑盒測試”，驗證單元外觀上的可觀察的行為；
結構測試（structure testing）或“白盒測試”，驗證單元的內部實現”
這里的關鍵問題在于上文中“構件”的概念，構件是RUP實現過程中的產物，在該書的P207中給出了構件的定義：“構件是模型元素（如設計模型中的設計類）的物理包”，可見，根據這樣的描述，將一個類或是一段代碼片斷作為單元測試的目標絕對是RUP所認可的。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
