測試是一個非?；A(chǔ)的概念，這種基礎(chǔ)讓大家可以隨意在它前面添加各種定語。
盡管這種添加的背后多數(shù)是不同的分類維度，但讓測試本身成為了繁雜概念的集合，這也讓我們總有種無法把握的煩躁感。
單元測試就是這堆讓人煩躁的繁雜概念之一。
1 3種軟件測試分類及單元測試的定義
如前所述，軟件測試的分類維度非常多，我們僅從以下常見的3種方式闡釋：
- 按是否執(zhí)行軟件分類：靜態(tài)測試和動態(tài)測試，單元測試橫跨二者。
- 按是否關(guān)注內(nèi)部代碼分類：白盒測試和黑盒測試，單元測試屬于白盒測試。
- 按汽車軟件集成層次分類：從單元測試到整車驗收有各級測試（參考《汽車軟件集成的5個層次》），單元測試屬于最低一個層級。
當(dāng)我們?nèi)ゾW(wǎng)上搜索單元測試的定義時，往往會看到類似這樣的說法，“單元測試是指對軟件中的最小可測單元進(jìn)行測試”。
但這個描述只能是一個正確的定義，仍然很難把握。什么叫最小可測單元？一個函數(shù)？一個類？一個.c？還是一個功能模塊？
爭論一直存在。
擱置爭議，我們只看汽車行業(yè)。按照慣例或標(biāo)準(zhǔn)，廣義上，可以把軟件集成測試以下所有測試都看作是單元測試。
2 單元測試的4種類型
進(jìn)一步地，在汽車軟件領(lǐng)域，我們可以將單元測試細(xì)分為代碼評審、靜態(tài)分析、單元（代碼功能）測試和單元（代碼覆蓋度）測試。
前兩種屬于靜態(tài)測試，后兩種屬于動態(tài)測試。
2.1 代碼評審
根據(jù)形式或正式程度上的差異，代碼評審會分成很多名目，比如：
- 走查（Walk Through）
- 同行評審（Peer Review)
- 代碼評審（Code Revew）
- 結(jié)對編程（Pair Programming）
- 代碼審查（Code Inspection）
但簡單來說，代碼評審就是人看，一個或一組人面對可閱讀的源代碼（有時也需要結(jié)合需求或軟件文檔），進(jìn)行隨意的或正式會議下的檢查。
可能會識別出如下的一些問題：
- 無注釋的代碼
- 不可達(dá)的條件路徑
- 太復(fù)雜的循環(huán)嵌套
- 無返回值的分支
- 未初始化的變量
- 空指針的引用
- 不規(guī)范的命名規(guī)則
- ......
理論上，對于手寫代碼的合理性與正確性，他人及更有經(jīng)驗的他人去檢查一遍，有一定的意義，甚至某些案例下，會勝過后期測試。
比如，開發(fā)調(diào)用了名稱相似的變量，這種錯誤可能在流到很后期才會被探測到。
實際上，代碼評審也同其他評審類似，都是無奈為之而又常常流于形式的手段。
解決這類問題的方法不外乎3個：
- 用更負(fù)責(zé)且有經(jīng)驗的人
- 提升形式的強制性
- 積累充足的Checklist
其中，在下一節(jié)靜態(tài)分析工具使用后，人的經(jīng)驗就成為了代碼評審存在的最大意義。
總之，代碼評審不算是典型的測試，但作為編碼后的第一道屏障，仍然有必要存在。
2.2 靜態(tài)分析
相較于人工代碼評審的低效，靜態(tài)分析是依賴于諸如Parasoft、Polyspace、Coverity等工具的自動化分析。
因為不需要執(zhí)行軟件，所以靜態(tài)分析仍然不需要二進(jìn)制代碼或可執(zhí)行程序。
靜態(tài)分析工具通常主要支持以下兩種分析類型：
- 語法分析：主要檢查是否符合編程語言的語法規(guī)則，如MISRA C。
- 代碼路徑分析：主要包括控制流分析（如語句條件分支、循環(huán)迭代次數(shù))、數(shù)據(jù)流分析（如變量值的傳遞）、代碼復(fù)雜性（如圈復(fù)雜度、路徑長度）、依賴關(guān)系（如函數(shù)之間的調(diào)用、模塊之間的依賴）等。
當(dāng)對部分或全部代碼進(jìn)行靜態(tài)掃描后，會得到基于內(nèi)置規(guī)則集的判定結(jié)果，一般會包含分等級的規(guī)則違反情況。
如MISRA C: 2012分為強制（Mandatory）、必要（Required）和建議（Advisory）。
通常，強制項必修，必要項需要進(jìn)行評審。但有時候，涉及到第三方標(biāo)準(zhǔn)庫時，就無法按照這個規(guī)則執(zhí)行了，具體還是要看產(chǎn)品類型（如是否涉及信息安全）和公司要求。
此外，由于編譯器基本也都具備類似的代碼檢查作用，靜態(tài)分析工具也可以理解為編譯器的擴展。
因此，我們也會把編譯器警告或錯誤作為要處理的條目。
2.3 單元（代碼功能）測試
這部分測試的源頭是軟件詳細(xì)設(shè)計，測試重點從代碼寫得漂不漂亮轉(zhuǎn)移到代碼寫得有沒有用，也就是是不是符合了設(shè)計。
汽車軟件用例的設(shè)計，一般有如下兩種密切相關(guān)的方法：
2.3.1 等價類劃分法
等價類劃分是將軟件單元的輸入數(shù)據(jù)劃分為等價數(shù)據(jù)（即可以導(dǎo)致相同的輸出）的分區(qū)，而后用測試用例去至少覆蓋每個分區(qū)一次。
其背后的訴求是，通過劃分輸入數(shù)據(jù)的類別來限定測試用例的數(shù)量。舉一個例子。
一個函數(shù)輸入的范圍是1~100，如果要窮舉式測試，我們需要為輸入?yún)?shù)編寫100個測試用例。
而使用等價類劃分法的話，測試用例就可以分為三類：
- 有效（1~100）
- 以下無效（例如0）
- 以上無效（>100）
于是，用例也就可以縮減為3個。
可能有人很快會有疑問，按照等價輸入數(shù)據(jù)進(jìn)行測試，會不會有遺漏呢？
沒錯，尤其是邊界值處很容易出錯。這就是第二個方法要解決的問題。
2.3.2 邊界值法
仍然以上一個案例展開。使用邊界值法的話，我們可為等價類劃分法定義的測試用例作如下補充：
- 剛好在邊界（1，100）
- 剛好在邊界以下（0，99）
- 剛剛越過邊界（2，101）
經(jīng)過兩種方法的結(jié)合，缺陷發(fā)現(xiàn)的能力會進(jìn)一步提高。
2.4 單元（代碼覆蓋度）測試
單元（代碼功能）測試完成后，夠了嗎？不夠。
我們沒測出bug，代表的不是軟件沒bug，而是沒測夠。
沒測夠的典型表現(xiàn)是測試用例對代碼的覆蓋程度不足，這就是本節(jié)要處理的問題。
主要的代碼覆蓋度測試類型包括以下4種，嚴(yán)格程度從上到下依次增強：
- 語句覆蓋（Statement Coverage）：這是最基本的覆蓋度類型，它確保每個代碼語句至少執(zhí)行一次，100%的語句覆蓋率可以保證沒有死代碼，屬于入門級別的測試。
- 分支覆蓋（Branch Coverage）：分支覆蓋確保每個分支語句（通常是if語句）都被覆蓋到，即每個分支的真和假兩種情況都被測試到，有助于揭示一些邏輯錯誤，如if a and b then...，用例為a真+b真（分支為真）、a真+b假（分支為假，與其他條件組合等價）即可100%。
- 條件覆蓋（Condition Coverage）：條件覆蓋要求每個分支語句的每個條件都被覆蓋，即每個條件的真和假兩種情況都被測試到，它比分支覆蓋更為嚴(yán)格，因為它會關(guān)注條件的組合覆蓋，如if a and b then...，用例為a真+b真、a真+b假、a假+b真、a假+b假才可100%。
- 修改條件/判定組合覆蓋（Modified Condition/Decision Combination Coverage）：這一級別的覆蓋要求同時滿足條件覆蓋和判定覆蓋，以確保條件和判定之間的組合覆蓋，是一種更加嚴(yán)格的覆蓋度測試。
不同的項目和產(chǎn)品可能需要不同類型的代碼覆蓋度測試。
通常，基礎(chǔ)的覆蓋度（如語句覆蓋和分支覆蓋）是必要的起點，而在需要更高可靠性和安全性的項目中，可能會選擇更嚴(yán)格的MC/DC覆蓋度，比如，涉及ASIL D的模塊。
3 單元測試意義的思考
說意義的話，我們可以很快說出一大堆，bug提前暴露、提升軟件質(zhì)量、軟件更加健壯、利于重構(gòu)、清除技術(shù)債務(wù)、積累組織資產(chǎn)......
問題在于，在不好言明的價值和巨大的交付壓力之下，單元測試太容易被權(quán)衡掉了，誰還沒有個意義呢？
實際上，管中窺豹，對這類重要但不緊急事情的意義的探討會折射出很多面的信息，比如下面這個算式。
自動化的程度+對軟件的理解+產(chǎn)品的競爭力+公司的文化+行業(yè)的生態(tài)=單元測試的意義
4 全文小結(jié)
本文主要在講單元測試的一些基本概念和應(yīng)用場景。
首先，從是否執(zhí)行軟件、是否關(guān)注內(nèi)部代碼和汽車軟件分層集成這3個方面解釋了單元測試的特點。進(jìn)而，引申出汽車軟件單元測試的概念。
接著，將單元測試細(xì)分為代碼評審、靜態(tài)分析、代碼功能測試、代碼覆蓋度測試，并分別進(jìn)行了描述。
由于單元測試離客戶需求太遠(yuǎn)，往往被務(wù)實的我們忽略，如何看待其價值需要探討，第3小節(jié)對此做了簡單分析。
5 寫在最后
不只是單元測試，軟件大舉進(jìn)入汽車行業(yè)的過程中，未來無形不可見和當(dāng)下有形可見的價值沖突持續(xù)在上演。
如何把握向左還是向右的分寸始終是一個巨大的決策考驗。
轉(zhuǎn)自汽車ECU開發(fā)
