作者 |李偉 上海控安安全測評部總監

來源 |鑒源實驗室

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

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

01

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

在行業內功能安全越來越多地被提起，對于測試人員來說項目落地時的工作量是趨于增加的。單元測試的執行，在功能安全整體設計要求中是不可缺少的環節，而通常情況下測試工程師對單元測試階段的任務設計是相對較少和覆蓋不全面的。

功能安全標準ISO 26262-6中提供了不同Asil等級的零部件單元測試推薦使用驗證方法，同時也對不同安全等級要求代碼的結構化覆蓋測試給出不同的測試方法。如下圖所示：

ISO 26262-6:2018(E) Table 9

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

02

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

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

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

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

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

在實際的工作測試中，我們碰到的代碼不可能這么簡單，當然通常我們也都是借助工具來進行代碼的測試工作，不會純人工來對代碼進行測試設計和手動測試。目前大多數測試工具都會自動生成一部分的用例來對代碼進行測試，但覆蓋率不會達到100%，此時就需要我們通過分析代碼以及已生成的覆蓋用例，手動添加完成剩余覆蓋。

03

使用工具來進行語句覆蓋測試

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

3.1工具測試舉例

針對如下代碼：

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

工具自動分析后會生產控制流圖如下：

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

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

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

下圖為測試用例2：

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

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

04

測試小結

在實際的代碼覆蓋度測試中，測試對象為軟件代碼，在代碼測試的層面我們有幾點總結跟大家分享，希望給大家帶來幫助。

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

2.在代碼中有部分是天然達不到100%覆蓋的，這部分代碼有些是做了故意的設計，對系統在代碼層面做保護，對于這種情況需要手動補充說明，如設計中止函數自動退出此處代碼執行等。

3.使用測試工具的不同會遇到代碼測試統計結果上的差異，如代碼總行數會因為空行、注釋、頭文件等統計方法的不同，得到的最終代碼總行數不同，還有覆蓋率計算，有部分工具對于代碼中函數“{}”等的統計方法不同，會出現即使同樣測試語句覆蓋用例設計，但最終工具給出的統計結果不一樣。

4.使用工具自動測試過程中通常會提示各種錯誤，這些錯誤通常是由頭文件、宏定義、數組越界等問題導致，經過調整后會大大提升工具的自動測試覆蓋率。

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

6.測試行業在近幾年互聯網、計算機、軟件工程等專業爆火的同時得到了快速發展，功能測試、性能測試、自動化測試、兼容性測試、健壯性測試等等測試技術也日趨完善，測試期待著新的技術普及點。代碼測試以前在很多行業會省略這個驗證過程，或者是由開發人員自測，現在伴隨著功能安全乘勢而起，對于提高測試工程師個人能力也有極大的幫助，我們也希望通過本課程更大家帶來更多的提升。

參考資料：

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

審核編輯 黃宇