測試是一個非常基礎的概念，這種基礎讓大家可以隨意在它前面添加各種定語。

盡管這種添加的背后多數是不同的分類維度，但讓測試本身成為了繁雜概念的集合，這也讓我們總有種無法把握的煩躁感。

單元測試就是這堆讓人煩躁的繁雜概念之一。

1

3種軟件測試分類及單元測試的定義

如前所述，軟件測試的分類維度非常多，我們僅從以下常見的3種方式闡釋：

按是否執行軟件分類：靜態測試和動態測試，單元測試橫跨二者。

按是否關注內部代碼分類：白盒測試和黑盒測試，單元測試屬于白盒測試。

按汽車軟件集成層次分類：從單元測試到整車驗收有各級測試（參考《汽車軟件集成的5個層次》），單元測試屬于最低一個層級。

當我們去網上搜索單元測試的定義時，往往會看到類似這樣的說法，“單元測試是指對軟件中的最小可測單元進行測試”。

但這個描述只能是一個正確的定義，仍然很難把握。什么叫最小可測單元？一個函數？一個類？一個.c？還是一個功能模塊？

爭論一直存在。

擱置爭議，我們只看汽車行業。按照慣例或標準，廣義上，可以把軟件集成測試以下所有測試都看作是單元測試。

2

單元測試的4種類型

進一步地，在汽車軟件領域，我們可以將單元測試細分為代碼評審、靜態分析、單元（代碼功能）測試和單元（代碼覆蓋度）測試。

前兩種屬于靜態測試，后兩種屬于動態測試。

2.1 代碼評審

根據形式或正式程度上的差異，代碼評審會分成很多名目，比如：

走查（Walk Through）

同行評審（Peer Review)

代碼評審（Code Revew）

結對編程（Pair Programming）

代碼審查（Code Inspection）

但簡單來說，代碼評審就是人看，一個或一組人面對可閱讀的源代碼（有時也需要結合需求或軟件文檔），進行隨意的或正式會議下的檢查。

可能會識別出如下的一些問題：

無注釋的代碼

不可達的條件路徑

太復雜的循環嵌套

無返回值的分支

未初始化的變量

空指針的引用

不規范的命名規則

......

理論上，對于手寫代碼的合理性與正確性，他人及更有經驗的他人去檢查一遍，有一定的意義，甚至某些案例下，會勝過后期測試。

比如，開發調用了名稱相似的變量，這種錯誤可能在流到很后期才會被探測到。

實際上，代碼評審也同其他評審類似，都是無奈為之而又常常流于形式的手段。

解決這類問題的方法不外乎3個：

? 用更負責且有經驗的人

?提升形式的強制性

? 積累充足的Checklist

其中，在下一節靜態分析工具使用后，人的經驗就成為了代碼評審存在的最大意義。

總之，代碼評審不算是典型的測試，但作為編碼后的第一道屏障，仍然有必要存在。

2.2 靜態分析

相較于人工代碼評審的低效，靜態分析是依賴于諸如Parasoft、Polyspace、Coverity等工具的自動化分析。

因為不需要執行軟件，所以靜態分析仍然不需要二進制代碼或可執行程序。

靜態分析工具通常主要支持以下兩種分析類型：

語法分析：主要檢查是否符合編程語言的語法規則，如MISRA C。

代碼路徑分析：主要包括控制流分析（如語句條件分支、循環迭代次數)、數據流分析（如變量值的傳遞）、代碼復雜性（如圈復雜度、路徑長度）、依賴關系（如函數之間的調用、模塊之間的依賴）等。

當對部分或全部代碼進行靜態掃描后，會得到基于內置規則集的判定結果，一般會包含分等級的規則違反情況。

如MISRA C: 2012分為強制（Mandatory）、必要（Required）和建議（Advisory）。

通常，強制項必修，必要項需要進行評審。但有時候，涉及到第三方標準庫時，就無法按照這個規則執行了，具體還是要看產品類型（如是否涉及信息安全）和公司要求。

此外，由于編譯器基本也都具備類似的代碼檢查作用，靜態分析工具也可以理解為編譯器的擴展。

因此，我們也會把編譯器警告或錯誤作為要處理的條目。

2.3單元（代碼功能）測試

這部分測試的源頭是軟件詳細設計，測試重點從代碼寫得漂不漂亮轉移到代碼寫得有沒有用，也就是是不是符合了設計。

汽車軟件用例的設計，一般有如下兩種密切相關的方法：

2.3.1 等價類劃分法

等價類劃分是將軟件單元的輸入數據劃分為等價數據（即可以導致相同的輸出）的分區，而后用測試用例去至少覆蓋每個分區一次。

其背后的訴求是，通過劃分輸入數據的類別來限定測試用例的數量。

舉一個例子。

一個函數輸入的范圍是1~100，如果要窮舉式測試，我們需要為輸入參數編寫100個測試用例。

而使用等價類劃分法的話，測試用例就可以分為三類：

有效（1~100）

以下無效（例如0）

以上無效（>100）

于是，用例也就可以縮減為3個。

可能有人很快會有疑問，按照等價輸入數據進行測試，會不會有遺漏呢？

沒錯，尤其是邊界值處很容易出錯。這就是第二個方法要解決的問題。

2.3.2 邊界值法

仍然以上一個案例展開。

使用邊界值法的話，我們可為等價類劃分法定義的測試用例作如下補充：

剛好在邊界（1，100）

剛好在邊界以下（0，99）

剛剛越過邊界（2，101）

經過兩種方法的結合，缺陷發現的能力會進一步提高。

2.4單元（代碼覆蓋度）測試

單元（代碼功能）測試完成后，夠了嗎？不夠。

我們沒測出bug，代表的不是軟件沒bug，而是沒測夠。

沒測夠的典型表現是測試用例對代碼的覆蓋程度不足，這就是本節要處理的問題。

主要的代碼覆蓋度測試類型包括以下4種，嚴格程度從上到下依次增強：

語句覆蓋（Statement Coverage）：這是最基本的覆蓋度類型，它確保每個代碼語句至少執行一次，100%的語句覆蓋率可以保證沒有死代碼，屬于入門級別的測試。

分支覆蓋（Branch Coverage）：分支覆蓋確保每個分支語句（通常是if語句）都被覆蓋到，即每個分支的真和假兩種情況都被測試到，有助于揭示一些邏輯錯誤，如if a and b then...，用例為a真+b真（分支為真）、a真+b假（分支為假，與其他條件組合等價）即可100%。

條件覆蓋（Condition Coverage）：條件覆蓋要求每個分支語句的每個條件都被覆蓋，即每個條件的真和假兩種情況都被測試到，它比分支覆蓋更為嚴格，因為它會關注條件的組合覆蓋，如if a and b then...，用例為a真+b真、a真+b假、a假+b真、a假+b假才可100%。

修改條件/判定組合覆蓋（Modified Condition/Decision Combination Coverage）：這一級別的覆蓋要求同時滿足條件覆蓋和判定覆蓋，以確保條件和判定之間的組合覆蓋，是一種更加嚴格的覆蓋度測試。

不同的項目和產品可能需要不同類型的代碼覆蓋度測試。

通常，基礎的覆蓋度（如語句覆蓋和分支覆蓋）是必要的起點，而在需要更高可靠性和安全性的項目中，可能會選擇更嚴格的MC/DC覆蓋度，比如，涉及ASIL D的模塊。

3

單元測試意義的思考

說意義的話，我們可以很快說出一大堆，bug提前暴露、提升軟件質量、軟件更加健壯、利于重構、清除技術債務、積累組織資產......

問題在于，在不好言明的價值和巨大的交付壓力之下，單元測試太容易被權衡掉了，誰還沒有個意義呢？

實際上，管中窺豹，對這類重要但不緊急事情的意義的探討會折射出很多面的信息，比如下面這個算式。

自動化的程度+對軟件的理解+產品的競爭力+公司的文化+行業的生態=單元測試的意義

4

全文小結

本文主要在講單元測試的一些基本概念和應用場景。

首先，從是否執行軟件、是否關注內部代碼和汽車軟件分層集成這3個方面解釋了單元測試的特點。進而，引申出汽車軟件單元測試的概念。

接著，將單元測試細分為代碼評審、靜態分析、代碼功能測試、代碼覆蓋度測試，并分別進行了描述。

由于單元測試離客戶需求太遠，往往被務實的我們忽略，如何看待其價值需要探討，第3小節對此做了簡單分析。

5

寫在最后

不只是單元測試，軟件大舉進入汽車行業的過程中，未來無形不可見和當下有形可見的價值沖突持續在上演。

如何把握向左還是向右的分寸始終是一個巨大的決策考驗。