有一種東西，

如果它太小，需要付出的努力就太大；如果它太大，就很難測試。

沒錯！它是單元。

但是什么才是一個好的單元定義呢?為什么它如此重要?

單元的定義對測試過程有很大的影響，但同時單元的定義也是不精確的。如果以一種不恰當的方式定義單位，這可能意味著大量的努力甚至麻煩。術語“單元”的定義可見于ISO 26262、ISTQB、ASPICE和許多其他文件。

我們的結論是:單元是一個小的可測試的軟件組件。不幸的是，這種定義非常模糊。這樣的定義不是用于工具，而是用于評估和審計。因此，在大多數組織中，這個術語是單獨指定的。

定義術語“單元”有兩種方法:通用描述和體系結構描述。

在通用描述中，單元將被定義為一個文件或一個函數。從特定的、體系結構的角度來看，單元是軟件體系結構中的一個元素。基于體系結構的特定定義可以減少單元測試中測試對象的數量。以這種方式定義的單元可以包含多個文件中的多個函數。

這種方法不違反ISO 26262或ASPICE的要求。此外，如果體系結構是自上向下開發的，您可以將體系結構的更高級別指定為純集成測試，從而也將減少單元測試級別的測試對象。在單元級別省略的測試會在之后的軟件集成測試(SWE.5)中執行。

一些組織通過調整單元的定義來縮小他們自己的需求之間的差距。典型的補充包括:

更精確地定義單元，例如，在編程語言C中，將單元定義為函數級別的數據和指令的封裝，或者

為單元構造過程提出要求，例如指定最大圈復雜度。

專業建議：對于具體項目來說，如果需求是好的，但太過籠統或太過嚴格，可以與客戶討論和協商，以定義一個一致的解決方案作為替代措施。這可以大大減少工作量。從風險的角度來看，定義單元的時間應該越早越好。

TPT可以測試所有類型的單元定義。從工具的角度來看，這并不是最重要的。為了將測試過程中產生的總工作量減少到最小，我們建議不要籠統地定義單元。這會為重構活動提供便利并減少額外的工作。