Jianyuan Lab
發(fā)布時間：2023-09-08 作者：上海工業(yè)控制安全創(chuàng)新科技有限公司 點擊次數(shù)：次
引言： 之前我們一直在講功能、性能、以及專項等相關(guān)的測試，這些測試主要集中在集成測試，系統(tǒng)驗證等階段，從本篇開始我們將深入到代碼層面，講解單元測試中的一項重要工作-軟件代碼測試。
01
代碼測試對功能安全的意義
在行業(yè)內(nèi)功能安全越來越多地被提起，對于測試人員來說項目落地時的工作量是趨于增加的。單元測試的執(zhí)行，在功能安全整體設(shè)計要求中是不可缺少的環(huán)節(jié)，而通常情況下測試工程師對單元測試階段的任務設(shè)計是相對較少和覆蓋不全面的。
功能安全標準ISO 26262-6中提供了不同Asil等級的零部件單元測試推薦使用驗證方法，同時也對不同安全等級要求代碼的結(jié)構(gòu)化覆蓋測試給出不同的測試方法。如下圖所示：
ISO 26262-6:2018(E) Table 9
從本篇開始我們給大家介紹軟件功能安全代碼結(jié)構(gòu)化覆蓋度量測試的3種方法，本篇將介紹語句覆蓋。
02
語句覆蓋測試能測試哪些東西
上一章節(jié)講的3種覆蓋方法（statement coverage、branch coverage、MC/DC）是從不同維度對被測試代碼進行測試設(shè)計。我們知道代碼是從第一行開始由上向下來執(zhí)行的，在執(zhí)行過程中遇到某些循環(huán)或者邏輯判斷時部分行會跳過，簡單理解語句覆蓋就是要求所有代碼被執(zhí)行一遍，從這個維度做測試設(shè)計進行測試。
我們用以下一段簡單代碼來舉例說明：
這段代碼總共19行，我們可以看到輸入的變量a和b決定了輸出值y，對于這段代碼的語句覆蓋率計算是看我們的代碼執(zhí)行到了哪一行，然后除以19得到的。如我們設(shè)計a=9，b=10，那么得到y(tǒng)=y+10=20,語句執(zhí)行到第9行，跳到第19行結(jié)束，總共運行10行，這條測試用例的語句覆蓋率就是50%。
如果我們設(shè)計a=15，b=10，會執(zhí)行到第10至第14行。所以我們再設(shè)計第三條測試用例令a=30，b=10的時候，這3條測試執(zhí)行會覆蓋所有的語句，此時語句的覆蓋率就達到了100%。
在實際的工作測試中，我們碰到的代碼不可能這么簡單，當然通常我們也都是借助工具來進行代碼的測試工作，不會純?nèi)斯韺Υa進行測試設(shè)計和手動測試。目前大多數(shù)測試工具都會自動生成一部分的用例來對代碼進行測試，但覆蓋率不會達到100%，此時就需要我們通過分析代碼以及已生成的覆蓋用例，手動添加完成剩余覆蓋。
03
使用工具來進行語句覆蓋測試
本章節(jié)我們使用SmartRocket TestGrid這款工具進行代碼的語句覆蓋測試分析，給大家介紹工具是如何生成測試用例完成測試任務的。工具的操作使用說明篇幅過大，且不屬于我們文章分享的目的，在此我們不做過多介紹。
針對如下代碼：
這段代碼我們可以看到函數(shù)的形參有兩個，分別是lua_State *L、init op，代碼邏輯也較為簡單，當op!= LUA_OPUNM且op!= LUA_OPBNOT為真時執(zhí)行api_checknelems(L, 2)，判斷為假時執(zhí)行其他操作。
工具自動分析后會生產(chǎn)控制流圖如下：
控制流圖可以幫助我們分析代碼復雜邏輯下執(zhí)行的路徑情況，對于覆蓋統(tǒng)計有非常大的幫助。在本例中我們可以設(shè)計兩條測試用例分別覆蓋判讀邏輯為真和為假的情況，這樣就可以完成語句100%覆蓋。這兩天測試用例分別是1.op!= LUA_OPUNM為真，op!= LUA_OPBNOT為真，2.上述兩個判斷條件一真一假，或者兩個都是假。
我們通過查看項目頭文件可以得到LUA_OPUNM、LUA_OPBNOT兩個常量的值分別為12和13，下圖為工具自動生成的測試用例1：
我們主要看輸入形參的賦值和輸出指針目標的預期賦值，本函數(shù)中未編寫對判斷做出相應的返回值，只是針對不同判斷結(jié)果執(zhí)行了一些操作，因此工具沒有對實際值和預期值分別進行賦值。本例中變量op賦值了14，所以這條測試用例覆蓋的是代碼中為真的分支語句。
下圖為測試用例2：
本例中變量op賦值12，判斷條件一真一假，所以覆蓋的是代碼中判斷結(jié)果為假語句分支代碼。對于形參L的賦值，需要查看代碼中對于lua_State的定義，雖然這段代碼沒有返回值，但是兩個分支都執(zhí)行了某些操作執(zhí)行，這些執(zhí)行都涉及到了形參L。
我們可以看到工具通過這兩條測試用例分別覆蓋了兩個判斷的分支，把所有代碼都執(zhí)行了一遍，所以這段代碼的測試覆蓋率就是100%。
04
測試小結(jié)
在實際的代碼覆蓋度測試中，測試對象為軟件代碼，在代碼測試的層面我們有幾點總結(jié)跟大家分享，希望給大家?guī)韼椭?/span>
1. 工具自動生成的測試用例在某些情況下不能自動達到100%，此時就需要我們分析代碼，以及已有用例的覆蓋情況，對未覆蓋部分進行人工補充。
2. 在代碼中有部分是天然達不到100%覆蓋的，這部分代碼有些是做了故意的設(shè)計，對系統(tǒng)在代碼層面做保護，對于這種情況需要手動補充說明，如設(shè)計中止函數(shù)自動退出此處代碼執(zhí)行等。
3. 使用測試工具的不同會遇到代碼測試統(tǒng)計結(jié)果上的差異，如代碼總行數(shù)會因為空行、注釋、頭文件等統(tǒng)計方法的不同，得到的最終代碼總行數(shù)不同，還有覆蓋率計算，有部分工具對于代碼中函數(shù)“{}”等的統(tǒng)計方法不同，會出現(xiàn)即使同樣測試語句覆蓋用例設(shè)計，但最終工具給出的統(tǒng)計結(jié)果不一樣。
4. 使用工具自動測試過程中通常會提示各種錯誤，這些錯誤通常是由頭文件、宏定義、數(shù)組越界等問題導致，經(jīng)過調(diào)整后會大大提升工具的自動測試覆蓋率。
5. 既然測試對象是純代碼，所以嚴格意義上來說，對于測試人員代碼覆蓋度測試是沒有很大的行業(yè)壁壘劃分的。也就是我們的測試標準可以分為汽車行業(yè)軟件功能安全標準、軌交行業(yè)功能安全標準、航空行業(yè)軟件功能安全標準等等，但這些軟件可能都是基于C、C++語言編寫，對于測試人員只要是同一種語言編寫的軟件我們不會因為行業(yè)不同會遇到不同的測試技術(shù)上的問題，測試人員在代碼測試的跨行業(yè)通用性上特別有利。
6. 測試行業(yè)在近幾年互聯(lián)網(wǎng)、計算機、軟件工程等專業(yè)爆火的同時得到了快速發(fā)展，功能測試、性能測試、自動化測試、兼容性測試、健壯性測試等等測試技術(shù)也日趨完善，測試期待著新的技術(shù)普及點。代碼測試以前在很多行業(yè)會省略這個驗證過程，或者是由開發(fā)人員自測，現(xiàn)在伴隨著功能安全乘勢而起，對于提高測試工程師個人能力也有極大的幫助，我們也希望通過本課程更大家?guī)砀嗟奶嵘?/span>
參考資料：
[1] ISO 26262-6-2018 Road vehicles - Functional safety - Part 6 Product development at the software
