功能安全溫度變送器的單元測試分析

蔡福全 孫京誥

(華東理工大學化工過程先進控制和優(yōu)化技術教育部重點實驗室，上海 200237)

隨著社會對功能安全領域的日益關注，與之相關的軟件測試技術也得到了迅速發(fā)展。單元測試作為軟件測試過程中的第一階段，自然占據(jù)著十分重要的地位[1]。單元測試以具體的程序模塊為研究對象，設計合理的單元測試用例[2]來提升軟件的質量。在功能安全領域，在遵循安全標準的前提下，通過單元測試，驗證具體的軟件模塊設計是否符合安全完整性等級要求。在整個驗證過程中，靜態(tài)與動態(tài)測試方法的選擇和過程分析是十分重要的研究課題。

功能安全溫度變送器的軟件開發(fā)過程需要遵循IEC61508-3中軟件開發(fā)的要求，整個過程遵循軟件安全完整性開發(fā)周期，即V模型的要求。V模型中包含兩個部分，一個是軟件的設計，另一個是軟件的驗證。

軟件設計主要包括軟件安全需求規(guī)范、軟件結構設計、軟件系統(tǒng)設計、模塊設計和編碼。軟件的驗證主要包含模型測試、集成測試、硬件與軟件的集成測試和最終的確認測試。

筆者主要研究驗證過程中的模塊測試，即功能安全溫度變送器軟件設計中功能模塊的單元測試研究。采用手動結合測試工作的方法，測試工具采用Parasoft C++test。

2 功能安全溫度變送器的模塊單元測試要求和策略

整個功能安全溫度變送器的軟件設計中，MSP430是數(shù)據(jù)處理單元的核心，軟件主要功能模塊分為主程序模塊、鍵盤處理模塊、顯示模塊、AD7794驅動模塊、ADS1110采樣模塊、AD421轉換模塊、數(shù)據(jù)轉換模塊、Flash讀寫模塊、配置模塊和診斷模塊。整個溫度變送器的軟件設計需要達到安全完整性等級SIL3，其測試工作應該包含以下技術要求：

a. 對軟件單元進行動態(tài)分析與測試之前，要求進行靜態(tài)代碼分析；

b. 對軟件設計中相關文檔規(guī)定的軟件單元的功能、性能及接口等應逐項進行測試，確保其運行結果滿足文檔中的相關要求；

c. 至少設計一個正常測試用例和一個被認可的異常測試用例去覆蓋每個程序單元的軟件特性；

d. 關于測試用例的設計，其輸入至少要包含有效等價類值、無效等價類值和邊界數(shù)據(jù)值；

e. 利用白盒測試原理，分析具體單元函數(shù)的特性，設計相關測試用例，檢驗每個單元函數(shù)的運行特性，確保行覆蓋率、語句覆蓋率、基本塊覆蓋率、判定覆蓋率、簡單條件覆蓋率和修改條件-判定覆蓋率能夠達到100%

3 模塊單元的靜態(tài)測試與結果

靜態(tài)測試[3]是指分析或者檢查軟件程序代碼的結構、邏輯及語法等的一種測試方式，而不是運行待檢測程序的方式。在測試過程中，需要通過人工對軟件的需求說明、概要設計文檔和程序源代碼進行分析，找出其中的不足，例如程序中語句的結構不合理、邏輯混亂、參數(shù)使用不合理及指針指向錯誤等。本次靜態(tài)測試通過人工結合Parasoft C++test測試軟件來實現(xiàn)。溫度變送器的軟件靜態(tài)測試主要針對程序代碼進行分析，測試步驟如下：

a. 啟動C++test，選擇保存工程的路徑，打開C++test測試工具；

b. 新建工程，選中IAR MSP430工程，將被測軟件(即功能安全變送器軟件)導入到該工程；

c. 配置C++test測試條件，按照C++test工具的使用要求定義CRules靜態(tài)測試條件，其規(guī)則包含BUG自動偵測、異常處理檢查、初始化檢查、MISRA C、MISRA C 2004及內(nèi)存資源管理等；

d. 選中被測工程，執(zhí)行配置好的CRules測試，進行靜態(tài)檢測，記錄測試結果。

通過測試，溫度變送器的軟件代碼符合各類規(guī)則的要求，結果如圖1所示。

圖1 靜態(tài)測試結果

4 模塊單元的動態(tài)測試與結果

4.1 測試模型

圖2所示為單元動態(tài)測試模型。

測試模型的核心對象為被測模塊，筆者研究的被測模塊指的是軟件設計中每個功能模塊中的每個具體函數(shù)，即單元函數(shù)。測試用例根據(jù)單元函數(shù)的要求，利用白盒測試原理[4]進行設計，用于檢測被測單元函數(shù)的完整性。在整個測試模型的設計中，需要為每個被測模塊開發(fā)驅動模塊和樁模塊。驅動模塊在整個單元測試模型中起橋梁作用，是一個將測試用例輸入被測模塊使之整體運行并且能夠輸出測試結果的主程序。樁模塊的作用是代替那些隸屬于被測模塊函數(shù)的調(diào)用函數(shù)。

4.2 測試案例分析

4.2.1單元函數(shù)動態(tài)分析

以診斷函數(shù)中的傳感器熱電阻兩線制型號斷線診斷為例，論述單元測試方法的具體應用和對斷線診斷函數(shù)的動態(tài)測試分析，圖3為傳感器斷線診斷的程序流程。

圖3 熱電阻二線制斷線診斷函數(shù)流程

如圖3所示，變量Sensor_type用來判斷傳感器的類型，當其采樣值位于10～11之間時，可判斷傳感器類型為熱電阻RTD型，然后使用變量(*ptrConfig).Channel.Sensor.Connection判定幾線制，其值為2U時表示二線制連接方式。最后根據(jù)P1IN的采樣值判定是否存在斷線故障，二線制斷線口用A、B表示，分別對應硬件接口P1.3、P1.1，斷線情況見表1。

表1 P1IN數(shù)值及其含義

根據(jù)黑盒測試中的邊界值分析法與白盒測試中的邏輯覆蓋測試原理對傳感器斷線診斷模塊進行案例設計。函數(shù)中涉及到Sensor_type、P1IN和(*ptrConfig).Channel.Sensor.Connection3個變量采樣值，設計測試案例對這3個變量進行賦值。

根據(jù)邊界值分析原理和源程序，Sensor_type取值為9、10、11、12，同時這些值也滿足白盒測試邏輯覆蓋原理中的判定-條件覆蓋原理，包括了判定覆蓋和條件覆蓋。斷線診斷中，判定條件中“(P1IN & 0x0002)==0x00U”，則P1IN取值0x0000U，為了滿足條件覆蓋率達到100%，該情況下還要考慮其不等于0x0000U的情況，則P1IN可取值0x0008U。

傳感器斷線診斷模塊的測試用例及其功能測試的輸出結果見表2，測試覆蓋率的結果如圖4所示。

表2 斷線診斷模塊測試用例及其功能輸出結果

圖4 傳感器斷線診斷模塊測試覆蓋率

4.2.2插樁技術的使用

在測試具體的單元函數(shù)時，常常需要在原來的程序中插入一些打印語句，然后在執(zhí)行程序時，能夠打印出最為關心的信息，進一步通過這些信息了解執(zhí)行過程中的一些動態(tài)特性。研究中，筆者將樁函數(shù)用作替代調(diào)用模塊及硬件設備讀取采用值等，減少了大量的I/O操作[5,6]，插樁原理如圖5所示。

以AD信號讀取采樣值模塊函數(shù)為例，論述樁函數(shù)的使用情況。如圖6所示，流程圖中存在兩個調(diào)用其他函數(shù)的命令，一個為讀寄存器命令，一個為讀寄存器的值。單元測試中，最小單元函數(shù)為被測對象，不與任何硬件設備連接。在該情況下，就無法正常按照程序流程讀取相關采樣值，這里的調(diào)用函數(shù)被如圖7所示的樁函數(shù)取代。圖中所示的樁函數(shù)在程序運行中取代了調(diào)用函數(shù)，并且將調(diào)用函數(shù)的返回值設置為0，因此最后的返回值也為0。接下來按照正常的動態(tài)分析完成測試工作。

圖5 插樁原理

圖6 AD信號讀取采樣值模塊流程

圖7 AD779X_ReadADSample測試樁函數(shù)

5 結束語

單元測試在功能安全驗證中占據(jù)很重要的位置，需要集合整體的軟件設計對其中每個單元模塊的程序進行測試分析和探討。通過測試找出軟件程序在結構及功能等方面存在的問題，使其符合功能安全完整性等級要求。筆者認為在功能安全領域的從業(yè)者，應該不斷完善單元測試在具體產(chǎn)品中的測試策略，如動態(tài)測試的用例設計，使設計出來的產(chǎn)品更好地符合功能安全的要求。

[1] 董威.單元測試及測試工具的研究與應用[J].微型電腦應用,2008,24(5):24～26，23,5.

[2] 魏銀英,楊苗.一種基于cantata的單元測試用例設計方法[J].電子世界,2014,(7):119.

[3] Larson E.SUDS:An Infrastructure for Creating Dynamic Software Defect Detection Tools[J].Automated Software Engineering,2010,17(3):301～346.

[4] 王敏,陳少敏,陳亞光,等.基本路徑測試用例設計算法[J].計算機應用,2013,33(11):3262～3266.

[5] Chen T Y,Kuo F C, Merkel R.On the Statistical Properties of Testing Effectiveness Measures[J].Journal of Systems and Software,2006,79(5):591～601.

[6] 張榮,王曙燕.基于插樁技術的動態(tài)測試研究與實現(xiàn)[J].現(xiàn)代電子技術,2011,34(4):50～52,55.