作者 |包丹珠上?？匕伯a(chǎn)品總監(jiān)

版塊 |鑒源論壇 · 觀模

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

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

01

前 言

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

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

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

02

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

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

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

1. 首先，單元測試任務(wù)瑣碎繁重，會占用大量時間。通常情況下，對于一個小型10萬行規(guī)模的軟件，大約需要設(shè)計10000條用例去進行測試?；旧希跊]有工具支撐的情況，需要消耗同寫代碼同樣的時間去撰寫測試驅(qū)動并測試；在有工具支持的情況會有所緩解，但也至少多花費一半的時間。

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

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

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

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

03

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

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

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

1. 等價類測試

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

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

1）從設(shè)計需求推導等價類?？梢詮妮斎霐?shù)據(jù)的角度，或者從輸出數(shù)據(jù)的角度進行劃分。

2）

從程序的內(nèi)部結(jié)構(gòu)推導等價類?？梢愿鶕?jù)靜態(tài)分析后的程序路徑來進行劃分。

2. 基于結(jié)構(gòu)的測試

基于結(jié)構(gòu)的測試，又稱白盒測試，是基于代碼來進行測試的一種技術(shù)。該測試方法關(guān)注代碼的內(nèi)部結(jié)構(gòu)，需要研發(fā)或測試人員詳細了解代碼的內(nèi)部結(jié)構(gòu)。同時測試充分性有確定的覆蓋度量方法，可以通過系統(tǒng)性的增加測試用例來提升覆蓋率。

基于結(jié)構(gòu)的測試方法有多種，比較基礎(chǔ)的包含以下四種。

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

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

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

4）

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

3. 邊界值測試

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

1）除零錯誤

2）空ASCII字符

3）空?；蛘弑碓?/p>

4）滿矩陣

5）

0表項

4. 控制流分析

控制流分析是為了尋找程序結(jié)構(gòu)潛在錯誤的一種測試方法。它通過采用靜態(tài)測試技術(shù)來分析程序的控制流程圖，然后進一步分析控制流程圖來發(fā)現(xiàn)不良的程序?qū)嵺`。通過控制流程圖分析，可以發(fā)現(xiàn)以下問題。

1）

不可達代碼。也被稱為死代碼，指的是永遠不會被觸發(fā)執(zhí)行到的代碼。

2）

打結(jié)的代碼。良好的代碼通常可以將其控制流程圖簡化為一個單節(jié)點，相反的，不良的代碼則會簡化為一個環(huán)狀結(jié)構(gòu)。

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

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

審核編輯 黃宇