MC/DC準則基礎下的嵌入式軟件測試

閆曉艷

摘要：MC/DC準則是現行軟件覆蓋率的驗證準則，具有高安全性、實用性及有效性強的特點，被廣泛應用于嵌入式軟件獨立測試當中，應用時可以結合該準則及嵌入式軟件測試要求構建測試技術方案，經測試可知嵌入式軟件在MC/DC準則中的覆蓋率，覆蓋率越高則代表軟件越優秀，否則反之。本文將對嵌入式軟件測試要求與MC/DC準則概念進行論述，并提出一種以MC/DC準則為基礎的嵌入式軟件測試技術方案，驗證該方案的有效性。

關鍵詞：MC/DC準則;嵌入式軟件;測試技術

引言

嵌入式軟件與嵌入主體本質上是兩個個體，嵌入式軟件與嵌入主體不匹配，可能造成巨大的負面影響，導致系統主體的穩定性大幅下降，因嵌入式軟件問題，使得系統主體出現可靠性、安全性上的問題，在嵌入式軟件嵌入系統主體之前，必須對軟件進行測試，確保軟件嵌入不會對系統造成負面影響。嵌入式軟件作為獨立開發軟件程序，其測試不能依照傳統方法來進行，必須在專門的準則及環境中開展，這時MC/DC準則（Modified Condition/Decision Coverage，修訂的條件/判定覆蓋）就提供了一種可用于嵌入式軟件測試的環境，對此進行研究可以利用該準則對不同嵌入式軟件進行測試，此舉具有一定現實意義。

1 嵌入式軟件測試要求與MC/DC準則概念

1.1嵌入式軟件測試要求

嵌入式軟件本身具有實時性、可移植性強，軟硬件可靈活調整，硬件平臺及操作系統多樣，缺陷不易修復，成本昂貴的特征，這些特征使得其在測試中對測試技術有較高的要求，一般不能采用單一技術進行測試，需要將整個測試流程分為不同階段，再針對各個階段設定測試技術，最終形成測試技術綜合方案來進行測試。根據嵌入式軟件本身特征及測試技術要求，通常可以將測試流程分為分析階段、設計階段、實現階段、驗證階段四個部分，以IV&V（Independent Verification and Validation，獨立驗證與確認）為測試導向，采用靜態代碼分析/動態覆蓋測試技術方案，針對各階段采用相關方法進行覆蓋測試，具體如下。表1為靜態代碼分析/動態覆蓋測試技術方案概況。

1.1.1靜態代碼分析

靜態代碼分析是嵌入式軟件最基本的測試策略，主要目的是檢查嵌入式軟件源代碼是否正確、質量如何，分析可以分為兩個步驟：①通過人工逐條觀察嵌入式軟件的源代碼，對照編碼規范進行檢查，確認源代碼中沒有錯誤代碼（如果代碼編制存在語法等方法的基本錯誤也需要指出）;（2）在確認源代碼正確的情況下，需要對代碼進行語義、數據流進行分析，若源代碼在這兩個層面存在誤差（如語義描述不準確）則必須在需求、設計等階段盡快調整。

1.1.2動態覆蓋測試

與靜態代碼分析不同，動態覆蓋測試需要在嵌入式軟件運行的狀態下進行，主要涉及到兩種測試方法，分別為黑盒測試、白盒測試。黑盒測試主要用于嵌入式軟件的功能測試中，可知軟件功能的覆蓋率，若測試結果顯示軟件功能覆蓋率未達到100%就必須進行修補，若軟件功能覆蓋率達到100%則進行白盒測試。

1.2 MC/DC準則概念

根據靜態代碼分析/動態覆蓋測試技術方案可知，通過這種方案單獨對嵌入式軟件進行測試，可知嵌入式軟件在IV&V中的需求覆蓋、結構覆蓋表現，前者代表軟件內所有目標函數是否被正確執行，則代表軟件源代碼是否充分及可實現性如何，在測試當中存在相輔相成關系，通過完整測試可判斷嵌入式軟件是否嚴格、是否完整。可見兩個覆蓋測試步驟是分開的，說明靜態代碼分析/動態覆蓋測試技術方案在單獨應用中會忽略條件覆蓋與判定覆蓋相組合的情況，代表該測試方法有缺陷。這一條件下MC/DC準則就對此進行了優化，即MC/DC準則的核心在于條件/判定覆蓋，主要以條件覆蓋結果為基礎，以優化軟件結構為目的提出結構覆蓋準則，受該準則影響，測試中需要對嵌入式軟件代碼內的所有可能都進行至少一次的輸入/輸出取值，所有覆蓋條件都進行輸出，輸出結果應當覆蓋所有可能，若輸出結果中沒有某個可能的結果，則說明軟件覆蓋率不足100%，存在缺陷。

2 以MC/DC準則為基礎的嵌入式軟件測試技術方案

2.1基本原理

關于MC/DC準則原理，首先要設定條件判定語句，通常使用布爾操作符構成布爾表達式，通過多個布爾表達式可構成條件判定語句，隨之將每個判定中的條件均視為不同條件（即使是相同條件多次出現于相同判定中，所有條件也被視為不同條件），由此進行判定。其次根據條件判定語句，對布爾表達式進行調整，比較常見的A and B就是邏輯布爾表達式，其中A、B均為布爾變量，可取值為{0，1}，整體可輸出結果C，結果C代表A and B的完備測試用例集。表2為MC/DC準則條件判定語句A and B邏輯與測試集。

根據表2，組別1-2測試中可取條件A的所有取值，要求所有取值均出現一次，在條件B不變的情況下，條件A要具備獨立影響對應判定結果的能力;組別1-3測試中可取條件B的所有取值，要求所有取值均出現一次，且在條件A不變的情況下，條件B要具備獨立影響對應判定結果的能力，由此取得組別1-2-3交集生成邏輯、最小測試用例集。組別7-8測試中可取條件A的所有取值，要求所有取值均出現一次，在條件B不變的情況下，條件A要具備獨立影響對應判定結果的能力;組別6-8測試中可取條件B的所有取值，要求所有取值均出現一次，在條件A不變的情況下，條件B要具備獨立影響對應判定結果的能力，由此取得組別6-7-8交集生成邏輯、最小測試用例集。

2.2測試技術方案

根據MC/DC準則的基本原理，下文將提出MC/DC準則嵌入式軟件測試方案，并接受方案測試流程。

2.2.1 MC/DC準則嵌入式軟件測試方案

因為MC/DC準則的泛用性較強，且測試性能優異，所以經過長期研究出現了很多支持MC/DC準則測試的自動化測試工具，例如Cantata++、VectorCAST，兩者均可實現自動化MC/DC準則度量。這一條件下，本文出于便捷性考慮選擇了VectorCAST（因VectorCAST可應用于比較常見的Windows、Linux開發平臺，所以適用性更好，應用更加便捷），使用該工具即可進行嵌入式軟件MC/DC準則測試。

2.2.2 MC/DC準則嵌入式軟件方案測試流程

雖然利用VectorCAST即可進行測試，但測試之前必須做好流程規劃工作，對此在本文測試方案中測試流程可以分為四個步驟：①在VectorCAST基礎上創立工作環境，將待測試嵌入式軟件源代碼導入，實現條件判定語句及MC/DC插樁，并分離出具有獨立影響能力的布爾表達式;②確認每個獨立影響布爾表達式的真值，可得每個表達式的最小測試集，根據測試需求將所有最小測試集集成，可得最小測試用例集;③腳本編寫后執行最小測試用例集，對測試結果進行分析，可知軟件是否存在缺陷。

3 MC/DC準則嵌入式軟件測試技術方案驗證

3.1測試案例

選擇某塑料光譜分選打包控制系統作為測試案例（該系統為嵌入式軟件），使用MC/DC準則嵌入式軟件測試技術方案進行測試。該系統主控（包括光譜儲料倉A閥門、光譜儲料倉B閥門）及打包（大件打包C閥門、小件打包D閥門）系統控制配有狀態指示燈，根據指示燈顏色不同代表不同含義，藍色燈為閥門閉合狀態、綠色燈為閥門正常開啟狀態、紅色燈為物料阻塞狀態），系統需要根據閥門電路狀態對指示燈進行控制。依照系統設計，本文對其進行了剖析，獲取了電路狀態表達式，具體如下：

if（ValveA->SelectedⅡValveB->Selected）&&（ValveC->SelectedⅡValveD->Selected）then ValveSetStatus（Open）;else;ValveSetStatus（Close）

3.2測試驗證

該系統表達式本質上不屬于布爾表達式，因此無法直接應用于MC/DC準則檢測當中，必須先進行簡化，對此依照準則原理本文將其簡化為相關布爾表達式，即if（A or B）and（C or D）then Statement1;else;Statement2，式中A、B、C、D分別代表了一種電路狀態，與相關提示等顏色對應，隨后考慮到測試驗證的便捷性，需要對該表達式進行進一步簡化，再針對布爾表達式進一步簡化，可得Z=X and Y，式中X代表A or B、Y代表C or D。其次依照簡化后得布爾表達式，獲取系統中獨立影響結果的最小測試集（見表3）進行測試。

依照表3進行方案設置（詳見2.2測試技術方案-MC/DC準則嵌入式軟件測試方案），完成后進行1-5、1-3、2-4、2-3四個組別的測試，要求1-5組別中條件A具有獨立影響判定結果的能力;1-3組別中條件B具有獨立影響判定結果的能力;2-4組別中條件C具有獨立影響判定結果的能力;2-3組別中條件D具有獨立影響判定結果的能力，這一基礎上可得組別1-2-3-4-5測試用例。結果顯示四組測試均可生成最小測試集，代表該系統MC/DC準則下的覆蓋率達到100%，系統可靠性、穩定性良好。

4 結語

本文對基于MC/DC準則的嵌入式軟件測試技術進行了研究，闡述了嵌入式軟件測試要求與MC/DC準則概念，并以MC/DC準則設計了測試技術方案，同時對方案進行了驗證。通過文中設計方式可得MC/DC準則嵌入式軟件測試技術方案，該方案在驗證中具有完整性強、測試準確率高的特點，可起到對嵌入式軟件進行全面測試，獲取其覆蓋率的作用。

參考文獻

[1]葛德明.實時嵌入式軟件的測試技術[J].電子測試，2018，000（010）：88-89.

[2]謝祥南，魏延棟.耦合條件的MC/DC測試用例集生成算法[J].計算機系統應用，2017（06）：166-171.