作者 |包丹珠上海控安產品總監

版塊 |鑒源論壇 · 觀模

社群 |添加微信號“TICPShanghai”加入“上海控安51fusa安全社區”

“軟件單元測試真的有必要嗎？”專題將分為上下兩期，深度詳解軟件單元測試的重要意義，分享目前行業內進行的單元測試探索與實踐。本文著重探討單元測試的重要性及其正面臨的困境，并介紹功能安全標準中羅列的單元測試方法。

01

前 言

元宇宙虛擬世界被大家探討得越來越深入。隨著Facebook公司更名為Meta，這場未來之戰已經吹響號角。元宇宙是虛擬的一個世界，核心是軟件創造的世界。那么，軟件定義一切對普羅大眾來說將不再是個空想，而是正在抵達的不久的將來。

如果在讀的你對軟件還沒有成熟的認知，對產品體驗始終停留在有形的實體的執念上的話，那么你要注意更新自己的認知了，要盡快做好抓住虛擬未來各種機遇的準備哦。

如果說軟件成為未來世界的基礎，那么軟件單元將是基礎中的基礎。當我們在談論軟件單元測試時，我們實際在談的是如何打好軟件基礎。讓我們把視角從未來切回到當下，一起來探討目前關于軟件單元測試所面臨的實際困境，以及如何正確面對這些困境，從而期待為基礎的軟件研發過程做好堅實的技術支撐。

02

靈魂拷問：單元測試耗時費力、成效模糊難以直觀預見，功能安全標準為何將其作為關鍵過程進行要求？

軟件單元測試不是一個新的概念。不論是工業領域，還是金融、互聯網的軟件從業人員，相信對單元測試都或多或少有一定的認知，甚至已經產生了相關的實踐。隨著IEC 61508功能安全標準體系的不斷擴充發展，安全攸關的領域最先對其引起了重視。

在快速軟件交付為王的背景之下，研發人員對單元測試的態度是認為基礎且重要，但是存在較大負擔的。

1. 首先，單元測試任務瑣碎繁重，會占用大量時間。通常情況下，對于一個小型10萬行規模的軟件，大約需要設計10000條用例去進行測試。基本上，在沒有工具支撐的情況，需要消耗同寫代碼同樣的時間去撰寫測試驅動并測試；在有工具支持的情況會有所緩解，但也至少多花費一半的時間。

2. 其次，單元測試預期能產生的效果不是能立即直觀體現出來的。軟件單元測試是在軟件開發過程中進行，軟件還未集成在一起，那么對于單元測試發現的問題不能立即直觀地體現在軟件的整體功能上的，因此一開始缺乏直觀可見的對比證據來說服開發人員或者領導單元測試的重要意義。也就是說，單元測試的好處就好比保養，在軟件開發階段是不能直觀體現出來的，需要到了軟件投入使用之后，經過同類對比，才能真正的直觀體現出來。舉個例子，兩個負責不同模塊的程序員，一個總能快速完成開發，另一個就要花較長的時間才能給出。從效率上講似乎快的能力更強。但是當給到客戶之后，你會發現完成快的模塊反饋出來奇奇怪怪的各種問題，需要很大的后期維護成本；慢的問題相對較少，漸漸地變得沒有新問題反饋出來。整體上來講，快的反而要花更長的時間，并且還消耗了口碑，投入了更多關系維護成本。

3. 再次，測試標準如何定義，何種程度可以認為是測試充分的是一個很關鍵的問題。單元測試通常會設定一些覆蓋率的指標，比如要求達到語句、分支覆蓋率100%。但是做到這些覆蓋率的指標就能證明沒有問題了嗎？很顯然不能，這是測試理論本身的通病，即只能發現問題，不能證明沒有問題。但這不是不進行單元測試的理由。這些指標要求是基礎要求，能夠完成這些指標，軟件的質量會有一個質的提升。

4. 最后，當詳細設計文檔不完善時，研發人員缺乏明確的測試依據，導致工作難以開展。軟件單元測試需要比較強的前置條件，即需要有詳細的軟件設計文檔作為測試的需求依據。然而，這個前置條件本身如果不具備的話，那么就失去了做單元測試的基礎。這種情況下，企業可能需要考慮先下決心建立軟件質量保證的流程體系，再來進一步細化具體的單元測試工作（敏捷開發對文檔沒有強制要求，敏捷開發依賴的是成員高度的共識和信息通暢，低文檔，高溝通。單元測試依據的內容本質上沒有區別，只不過更多通過溝通結果來作為無形的依據。這個有機會可以深入探討）。

因此，耗時費力，成效模糊難以直觀預見是軟件研發人員進行單元測試時需要排除的困難，而不是單元測試沒有意義的原因。在來談困難以及解決辦法之前，我們應當先明確什么是對的。單元測試是很有必要的，功能安全標準制定者將其作為關鍵的軟件驗證過程是有很高的指導意義的。軟件單元測試可以有效提升軟件整體的質量和健壯性。除非極簡單的軟件系統，單元測試如果不充分，做再多的系統測試也是不夠的，就好比掃雷不徹底，始終有觸雷的隱患。

03

單元測試到底在做什么，要做到什么程度？

軟件單元是軟件最小的設計單位，軟件單元的實現需要依據軟件設計需求。根據IEC 61508的要求，即“每個軟件模塊應當按軟件設計所規定的進行測試。這些測試應當表明每個軟件模塊將執行其預期功能，且不會執行非預期功能”。因此單元測試的核心目標是確保軟件單元同軟件設計的一致性。

為了確保一致性，功能安全標準列出了多種單元測試的方法。其中等價類測試和基于結構的測試對于單元測試來說是充足的。邊界值測試和控制流程分析可以有效降低測試用例的數目。用盡可能少的用例來完成充足的測試是單元測試的最高追求。

1. 等價類測試

等價類測試指的是將測試的輸入分成幾類，每一類提供一個有代表性的輸入進行測試即可。這種方法免除了窮盡所有可能性的不切實際的測試方法，通過減少測試用例的數目到可接受的程度，可以有效提升測試的成效。

等價類劃分的方法有兩種：

1）從設計需求推導等價類。可以從輸入數據的角度，或者從輸出數據的角度進行劃分。

2）

從程序的內部結構推導等價類。可以根據靜態分析后的程序路徑來進行劃分。

2. 基于結構的測試

基于結構的測試，又稱白盒測試，是基于代碼來進行測試的一種技術。該測試方法關注代碼的內部結構，需要研發或測試人員詳細了解代碼的內部結構。同時測試充分性有確定的覆蓋度量方法，可以通過系統性的增加測試用例來提升覆蓋率。

基于結構的測試方法有多種，比較基礎的包含以下四種。

1）調用圖覆蓋。也叫做入口點測試，或者調用覆蓋測試。調用圖指的是子程序調用的樹形圖。該測試方法的目的是確保所有的子程序都被至少調用一次。

2）語句覆蓋。語句覆蓋是最基礎的測試方法，需要確保所有的語句都至少被測試一次。該方法較為簡單，然而對于測試來講精確度不是很高。

3）分支覆蓋。分支覆蓋指的是對于代碼的分支結構，需要確保所有的分支都被至少測試一次。該方法相對語句覆蓋，其測試精確度有較明顯的提升。

4）

MC/DC 覆蓋。修正的條件判定覆蓋，其針對的是程序的分支結構，并且影響分支走向的是多種條件的組合判定。該方法需要確保所有條件均能夠至少影響分支走向一次。該測試方法相對分支覆蓋，其測試精確度有了更高的提升。并且可以確保以最少的用例數目，達到更精確化測試的目的。以上是IEC 61508功能安全標準對基于結構測試的基礎推薦方法。其中每一種測試覆蓋方法，均要達到100%的覆蓋。更高級的基于結構的測試方法還有LCSAJ線性代碼序列和跳轉測試、數據流、基本路徑等覆蓋測試方法。有興趣的讀者可以進一步研究，并結合代碼特征靈活進行選用。

3. 邊界值測試

通常軟件錯誤通常會出現在軟件參數的邊界點。邊界值測試要求測試應涵蓋等價類的邊界和極端情況，同時還要檢查需求中的邊界同程序中的邊界是否一致。通常情況下，零值特別容易引起錯誤，需要特別注意零值的測試。如：

1）除零錯誤

2）空ASCII字符

3）空棧或者表元素

4）滿矩陣

5）

0表項

4. 控制流分析

控制流分析是為了尋找程序結構潛在錯誤的一種測試方法。它通過采用靜態測試技術來分析程序的控制流程圖，然后進一步分析控制流程圖來發現不良的程序實踐。通過控制流程圖分析，可以發現以下問題。

1）

不可達代碼。也被稱為死代碼，指的是永遠不會被觸發執行到的代碼。

2）

打結的代碼。良好的代碼通常可以將其控制流程圖簡化為一個單節點，相反的，不良的代碼則會簡化為一個環狀結構。

因此，軟件單元測試是一項有明確的測試方法指導，并且具備充分性度量的標準的一項測試工作。在設定測試方法時，可以根據待測軟件的質量或安全要求級別，選取適合的測試方法組合。

在下一期“軟件單元測試真的有必要嗎？（下）”中，將深入探討單元測試過程中，如何在保質保量完成測試任務的同時，縮減時間成本、提高測試效率，并分享目前行業內的實踐經驗以及相關自動化測試工具。

審核編輯 黃宇