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

版塊 |鑒源論壇 · 觀模

社群 |添加微信號(hào)“TICPShanghai”加入“上?？匕?1fusa安全社區(qū)”

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

01

前 言

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

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

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

02

靈魂拷問：單元測試耗時(shí)費(fèi)力、成效模糊難以直觀預(yù)見，功能安全標(biāo)準(zhǔn)為何將其作為關(guān)鍵過程進(jìn)行要求？

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

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

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

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

3. 再次，測試標(biāo)準(zhǔn)如何定義，何種程度可以認(rèn)為是測試充分的是一個(gè)很關(guān)鍵的問題。單元測試通常會(huì)設(shè)定一些覆蓋率的指標(biāo)，比如要求達(dá)到語句、分支覆蓋率100%。但是做到這些覆蓋率的指標(biāo)就能證明沒有問題了嗎？很顯然不能，這是測試?yán)碚摫旧淼耐ú。粗荒馨l(fā)現(xiàn)問題，不能證明沒有問題。但這不是不進(jìn)行單元測試的理由。這些指標(biāo)要求是基礎(chǔ)要求，能夠完成這些指標(biāo)，軟件的質(zhì)量會(huì)有一個(gè)質(zhì)的提升。

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

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

03

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

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

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

1. 等價(jià)類測試

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

等價(jià)類劃分的方法有兩種：

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

2）

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

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

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

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

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

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

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

4）

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

3. 邊界值測試

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

1）除零錯(cuò)誤

2）空ASCII字符

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

4）滿矩陣

5）

0表項(xiàng)

4. 控制流分析

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

1）

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

2）

打結(jié)的代碼。良好的代碼通?？梢詫⑵淇刂屏鞒虉D簡化為一個(gè)單節(jié)點(diǎn)，相反的，不良的代碼則會(huì)簡化為一個(gè)環(huán)狀結(jié)構(gòu)。

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

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

審核編輯 黃宇