作者 |李偉 上?？匕舶踩珳y評部總監(jiān)

來源 |鑒源實(shí)驗(yàn)室

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

引言：之前我們一直在講功能、性能、以及專項(xiàng)等相關(guān)的測試，這些測試主要集中在集成測試，系統(tǒng)驗(yàn)證等階段，從本篇開始我們將深入到代碼層面，講解單元測試中的一項(xiàng)重要工作-軟件代碼測試。

01

代碼測試對功能安全的意義

在行業(yè)內(nèi)功能安全越來越多地被提起，對于測試人員來說項(xiàng)目落地時(shí)的工作量是趨于增加的。單元測試的執(zhí)行，在功能安全整體設(shè)計(jì)要求中是不可缺少的環(huán)節(jié)，而通常情況下測試工程師對單元測試階段的任務(wù)設(shè)計(jì)是相對較少和覆蓋不全面的。

功能安全標(biāo)準(zhǔn)ISO 26262-6中提供了不同Asil等級的零部件單元測試推薦使用驗(yàn)證方法，同時(shí)也對不同安全等級要求代碼的結(jié)構(gòu)化覆蓋測試給出不同的測試方法。如下圖所示：

ISO 26262-6:2018(E) Table 9

從本篇開始我們給大家介紹軟件功能安全代碼結(jié)構(gòu)化覆蓋度量測試的3種方法，本篇將介紹語句覆蓋。

02

語句覆蓋測試能測試哪些東西

上一章節(jié)講的3種覆蓋方法（statement coverage、branch coverage、MC/DC）是從不同維度對被測試代碼進(jìn)行測試設(shè)計(jì)。我們知道代碼是從第一行開始由上向下來執(zhí)行的，在執(zhí)行過程中遇到某些循環(huán)或者邏輯判斷時(shí)部分行會跳過，簡單理解語句覆蓋就是要求所有代碼被執(zhí)行一遍，從這個(gè)維度做測試設(shè)計(jì)進(jìn)行測試。

我們用以下一段簡單代碼來舉例說明：

這段代碼總共19行，我們可以看到輸入的變量a和b決定了輸出值y，對于這段代碼的語句覆蓋率計(jì)算是看我們的代碼執(zhí)行到了哪一行，然后除以19得到的。如我們設(shè)計(jì)a=9，b=10，那么得到y(tǒng)=y+10=20,語句執(zhí)行到第9行，跳到第19行結(jié)束，總共運(yùn)行10行，這條測試用例的語句覆蓋率就是50%。

如果我們設(shè)計(jì)a=15，b=10，會執(zhí)行到第10至第14行。所以我們再設(shè)計(jì)第三條測試用例令a=30，b=10的時(shí)候，這3條測試執(zhí)行會覆蓋所有的語句，此時(shí)語句的覆蓋率就達(dá)到了100%。

在實(shí)際的工作測試中，我們碰到的代碼不可能這么簡單，當(dāng)然通常我們也都是借助工具來進(jìn)行代碼的測試工作，不會純?nèi)斯韺Υa進(jìn)行測試設(shè)計(jì)和手動測試。目前大多數(shù)測試工具都會自動生成一部分的用例來對代碼進(jìn)行測試，但覆蓋率不會達(dá)到100%，此時(shí)就需要我們通過分析代碼以及已生成的覆蓋用例，手動添加完成剩余覆蓋。

03

使用工具來進(jìn)行語句覆蓋測試

本章節(jié)我們使用SmartRocket TestGrid這款工具進(jìn)行代碼的語句覆蓋測試分析，給大家介紹工具是如何生成測試用例完成測試任務(wù)的。工具的操作使用說明篇幅過大，且不屬于我們文章分享的目的，在此我們不做過多介紹。

3.1工具測試舉例

針對如下代碼：

這段代碼我們可以看到函數(shù)的形參有兩個(gè)，分別是lua_State *L、init op，代碼邏輯也較為簡單，當(dāng)op!= LUA_OPUNM且op!= LUA_OPBNOT為真時(shí)執(zhí)行api_checknelems(L, 2)，判斷為假時(shí)執(zhí)行其他操作。

工具自動分析后會生產(chǎn)控制流圖如下：

控制流圖可以幫助我們分析代碼復(fù)雜邏輯下執(zhí)行的路徑情況，對于覆蓋統(tǒng)計(jì)有非常大的幫助。在本例中我們可以設(shè)計(jì)兩條測試用例分別覆蓋判讀邏輯為真和為假的情況，這樣就可以完成語句100%覆蓋。這兩天測試用例分別是1.op!= LUA_OPUNM為真，op!= LUA_OPBNOT為真，2.上述兩個(gè)判斷條件一真一假，或者兩個(gè)都是假。

我們通過查看項(xiàng)目頭文件可以得到LUA_OPUNM、LUA_OPBNOT兩個(gè)常量的值分別為12和13，下圖為工具自動生成的測試用例1：

我們主要看輸入形參的賦值和輸出指針目標(biāo)的預(yù)期賦值，本函數(shù)中未編寫對判斷做出相應(yīng)的返回值，只是針對不同判斷結(jié)果執(zhí)行了一些操作，因此工具沒有對實(shí)際值和預(yù)期值分別進(jìn)行賦值。本例中變量op賦值了14，所以這條測試用例覆蓋的是代碼中為真的分支語句。

下圖為測試用例2：

本例中變量op賦值12，判斷條件一真一假，所以覆蓋的是代碼中判斷結(jié)果為假語句分支代碼。對于形參L的賦值，需要查看代碼中對于lua_State的定義，雖然這段代碼沒有返回值，但是兩個(gè)分支都執(zhí)行了某些操作執(zhí)行，這些執(zhí)行都涉及到了形參L。

我們可以看到工具通過這兩條測試用例分別覆蓋了兩個(gè)判斷的分支，把所有代碼都執(zhí)行了一遍，所以這段代碼的測試覆蓋率就是100%。

04

測試小結(jié)

在實(shí)際的代碼覆蓋度測試中，測試對象為軟件代碼，在代碼測試的層面我們有幾點(diǎn)總結(jié)跟大家分享，希望給大家?guī)韼椭?/p>

1.工具自動生成的測試用例在某些情況下不能自動達(dá)到100%，此時(shí)就需要我們分析代碼，以及已有用例的覆蓋情況，對未覆蓋部分進(jìn)行人工補(bǔ)充。

2.在代碼中有部分是天然達(dá)不到100%覆蓋的，這部分代碼有些是做了故意的設(shè)計(jì)，對系統(tǒng)在代碼層面做保護(hù)，對于這種情況需要手動補(bǔ)充說明，如設(shè)計(jì)中止函數(shù)自動退出此處代碼執(zhí)行等。

3.使用測試工具的不同會遇到代碼測試統(tǒng)計(jì)結(jié)果上的差異，如代碼總行數(shù)會因?yàn)榭招?、注釋、頭文件等統(tǒng)計(jì)方法的不同，得到的最終代碼總行數(shù)不同，還有覆蓋率計(jì)算，有部分工具對于代碼中函數(shù)“{}”等的統(tǒng)計(jì)方法不同，會出現(xiàn)即使同樣測試語句覆蓋用例設(shè)計(jì)，但最終工具給出的統(tǒng)計(jì)結(jié)果不一樣。

4.使用工具自動測試過程中通常會提示各種錯(cuò)誤，這些錯(cuò)誤通常是由頭文件、宏定義、數(shù)組越界等問題導(dǎo)致，經(jīng)過調(diào)整后會大大提升工具的自動測試覆蓋率。

5.既然測試對象是純代碼，所以嚴(yán)格意義上來說，對于測試人員代碼覆蓋度測試是沒有很大的行業(yè)壁壘劃分的。也就是我們的測試標(biāo)準(zhǔn)可以分為汽車行業(yè)軟件功能安全標(biāo)準(zhǔn)、軌交行業(yè)功能安全標(biāo)準(zhǔn)、航空行業(yè)軟件功能安全標(biāo)準(zhǔn)等等，但這些軟件可能都是基于C、C++語言編寫，對于測試人員只要是同一種語言編寫的軟件我們不會因?yàn)樾袠I(yè)不同會遇到不同的測試技術(shù)上的問題，測試人員在代碼測試的跨行業(yè)通用性上特別有利。

6.測試行業(yè)在近幾年互聯(lián)網(wǎng)、計(jì)算機(jī)、軟件工程等專業(yè)爆火的同時(shí)得到了快速發(fā)展，功能測試、性能測試、自動化測試、兼容性測試、健壯性測試等等測試技術(shù)也日趨完善，測試期待著新的技術(shù)普及點(diǎn)。代碼測試以前在很多行業(yè)會省略這個(gè)驗(yàn)證過程，或者是由開發(fā)人員自測，現(xiàn)在伴隨著功能安全乘勢而起，對于提高測試工程師個(gè)人能力也有極大的幫助，我們也希望通過本課程更大家?guī)砀嗟奶嵘?/p>

參考資料：

[1]ISO 26262-6-2018 Road vehicles - Functional safety - Part 6 Product development at the software

審核編輯 黃宇