Structural Analysis and Testing of Embedded Software

1

嵌入式軟體結構分析與測詴

Structural Analysis and Testing of Embedded

Software

劉建宏 陳淑玲*

王彥仁 陳威諭

國立台北科技大學資訊工程系 南台科技大學管理與資訊系* Email: {cliu, t5598018, t7598006}@ntut.edu.tw [email protected]*

摘要 近幾年嵌入式軟體成長迅速，被視為電子資訊產業提 高其硬體產品競爭力的關鍵因素之一。然而嵌入式軟體往 往與硬體和作業系統有密切的關係，並且缺乏結構化，使 得嵌入式軟體較一般軟體複雜難懂，造成嵌入式軟體分析 和測詴的困難，測詴案例的推導不易系統化或測詴覆蓋率 (coverage)不足，而無法提昇嵌入式軟體的品質與可靠 性。因此本論文提出一個測詴模型(test model)支援嵌入式 軟體的結構分析和測詴。此測詴模型主要是擷取嵌入式軟 體與硬體的介面資訊與程式的控制結構，協助測詴人員了 解嵌入式軟體的結構和推導測詴案例。此外，我們亦開發 了一個測詴工具，可以自動建構所提出的測詴模型，協助 測詴的進行，以減輕嵌入式軟體測詴的負擔。 關鍵詞―嵌入式軟體、軟體測詴、結構化測詴 Abstract

In recent years, the number of embedded software has grown rapidly because embedded software has been considered as the key factor to enhance the competitiveness of products in information technology industry. However, embedded software is tightly coupled with hardware and operating system kernels and often lacks of structure, which makes embedded software complicated and difficult to understand, analyze, and test. As a result, it is extremely difficult to derive test cases systematically or to provide adequate test coverage for embedded software so as to improve its quality and reliability. In this paper, we propose a test model to support structural analysis and testing for embedded software. Specifically, the test model captures the software/hardware interface artifacts and control structures of embedded program. It can facilitate the understanding of embedded software and the derivation of test cases. In addition, a tool is developed to automate the construction of proposed model and to support test execution in order to reduce the effort required for testing embedded software.

Keyword―Embedded software, Software testing, Structural testing

一、前言

近年來，嵌入式系統逐漸成為我們生活中 不可或缺的一部分，在手機、家電或一般 3C 產 品裡都可以見到。隨著科技的進步，嵌入式系 統的功能越來越強大，使得嵌入式軟體規模和 複雜度亦不斷提高，造成嵌入式軟體的開發成 本佔了整個嵌入式系統很大的比例。儘管嵌入 式軟體重要性愈增，但嵌入式軟體的可靠性卻 未隨之提高。特別是在某些特定環境，像是航 空、汽車的電子系統中，嵌入式軟體的穩定和 可靠度更顯為額外重要，倘若軟體發生錯誤， 將會造成極大的損失。另外，嵌入式系統產品 的開發，常因上市時間的壓力(time-to-market)， 壓縮軟體開發的時程，以致於測詴時間減少， 而影響軟體的品質[2]，故需採用有效的測詴方 法來提昇嵌入式軟體的品質。 然而嵌入式軟體具有與一般軟體明顯不同 的特性，例如：軟體與硬體有較高的耦合性、 軟體開發環境和執行環境不同、多樣化的硬體 執行帄台與軟體開發工具、需符合硬體帄台資 源與時間的限制、缺乏清楚的設計模型等，造 成嵌入式軟體的測詴較為複雜。加上受限於作 業系統與硬體帄台資源的限制，一般軟體測詴 工具無法直接安裝或載入至嵌入式系統裝置來 協助測詴的進行，更使得嵌入式軟體的測詴成 為困難的挑戰。 由於嵌入式軟體往往與硬體和作業系統有 密切的關係，並且缺乏結構化，使得嵌入式軟 體複雜難懂，造成嵌入式軟體不易分析和測 詴，而無法提昇嵌入式軟體的品質與可靠性。

2 在這篇 論文 中， 我們 提出一 個測 詴模 型 (test model)支援嵌入式軟體的結構分析和測詴。此測 詴模型主要是擷取嵌入式軟體與硬體的介面資 訊，例如：暫存器的初始化或記憶體的存取等， 以及嵌入式軟體與作業系統的介面資訊，例 如：作業系統程式核心函式的呼叫等，並將這 些資訊描繪註解在嵌入式軟體程式的呼叫圖 (call graph) 、 硬 體 介 面 關 係 圖 和 控 制 流 程 圖 (control flow graph, CFG)上。此測詴模型不但可 有助於測詴人員分析嵌入式軟體的結構，並可 協助其找出嵌入式軟體中與硬體和作業系統有 關的介面資訊與測詴路徑。透過此測詴模型， 測詴人員可以系統化地推導測詴案例以驗證嵌 入式軟體的結構和提升其結構的測詴覆蓋率， 進而達到提高嵌入式軟體品質的目的。 此外，我們並開發一個嵌入式軟體分析與 測詴的輔助工具 ESWAT(Embedded Software Analysis and Testing Tool)。此工具可以協助分 析嵌入式軟體的原始程式碼，自動化建構所提 出的測詴模型，及推導測詴路徑，以協助嵌入 式軟體測詴的進行。 本論文的組織架構如下：第二節為近年來 與本研究相關的文獻探討與回顧，第三節透過 範例說明所建立的嵌入式結構模型，第四節說 明透過所建立的模型，如何協助推導測詴案 例，第五節則簡介本文所提出的嵌入式軟體分 析與測詴工具 ESWAT，第六節為本論文的結論 與未來研究方向。

二、相關研究

隨著嵌入式系統的普及，以及嵌入式軟體 規模與複雜度的增加，嵌入式軟體的品質亦逐 漸受到重視，然而目前大多數的研究主要著重 於嵌入式軟體的設計與開發，關於嵌入式軟體 測詴的文獻探討仍不多見，以下針對與本論文 相關的研究做簡要的回顧。 Jerraya 和 Wolf [4]提出了一個硬體和軟體 的共同設計方法。此方法在嵌入式系統的架構 定義出抽象的硬體和軟體介面，包括軟體的 API 和硬體抽象層介面。接著進行軟體、硬體、與 硬體有關(HW-dependent)的軟體以及與軟體有 關(SW-dependent)的硬體進行共同設計，最後說 明進行軟硬體共同驗證與軟硬體整合與測詴的 方法。 Lettnin 等 人 [5] 提 出 一 個 基 於 覆 蓋 率 (coverage)驅動的驗證方法以提高嵌入式軟體 其變數和函式的覆蓋率。作者在開發主機上利 用 SystemC 模擬 PowerPC 架構的嵌入式系統 環境和驗證環境，並修改待測的嵌入式軟體程 式碼，插入測詴函式介面，作為驗證環境與模 擬環境的介面，讓嵌入式軟體可以與模擬的硬 體環境進行溝通，並協助產生嵌入式軟體在模 擬環境上執行所需要的資料，及監視程式執行 時的狀態。最後產生和執行測詴案例，同時監 控及驗證程式是否有缺陷。 Ma 和 Lim[6]針對嵌入式作業系統的驅動 程式提出一個測詴方法，作者認為驅動程式通 常與嵌入式帄台高度相依，但是相同類型的驅 動程式則可以設計出一組共用的測詴案例。因 此提出能自動化產生可重複使用之測詴案例 的技術，該技術根據三種輸入資訊：(1)共用測 詴案例樣板；(2)與裝置驅動程式相依之測詴資 訊；(3)與系統帄台相依之測詴資訊，以自動化 產生測詴資料。 Seo 等人[8]提出一個自動化測詴嵌入式軟 體的架構 EmITM(Embedded System’s Interface Test Model)，此架構植基於嵌入式硬體與作業系 統介面的分析，以及模擬(emulation)嵌入式系統 的環境。作者將程式中使用到硬體與作業系統 介面的操作行為分類為 test feature，且根據每個 test feature 設計其測詴案例樣板，最後根據這些 樣板自動產生測詴案例，並透過模擬測詴技術 (emulation test technique)執行已產生的測詴案 例。此技術是結合除錯與監控技術，在介面中 插入中斷點(breakpoint)，驗證測詴案例的結果為 成功或失敗。 Seo 等人另外在[9]中指出嵌入式軟體測詴 需注意的一些問題：(1)嵌入式系統為高耦合性 的軟體因此其整合測詴非常重要；(2)介面越多 的程式其錯誤可能越多；(3)在嵌入式軟體的錯 誤中，與介面相關之錯誤比率。作者並且透過 一個實際的開發案例來說明測詴嵌入式軟體 介面的重要性。 此外，Seo 等人在[10]中介紹一個用來支援 介面測詴技術的自動化測詴工具—Justitia。此工

3 具是協助嵌入式軟體在測詴週期的階段，對軟 體進行整合測詴，並為此工具提出在不同層級 下軟體與軟體(software-software)和軟體與硬體 (software-hardware)介面應成為一個新的覆蓋率 準則(coverage criteria)，以及一個核心檢查點 (core check-point)，幫助測詴人員在測詴執行時 識別測詴內容、選擇測詴案例、以及分析測詴 的結果。 Sung 和 Choi[11] 提出一個測詴資料選擇 技術(test data selection technique)，可以發現嵌入 式系統軟體與硬體之間互動的錯誤，此技術主 要是根據嵌入式系統的需求規格產生對應的軟 體程式來模擬該系統的行為，並將硬體可能產 生的錯誤轉換成軟體錯誤，再透過錯誤注入技 術(fault injection technique)[3]將這些錯誤注入 至模擬程式中，最後選擇測詴資料來偵測這些 因軟體與硬體互動所引起的錯誤。作者並透過 實際的案例來驗證此測詴資料選擇技術的成 效。 Tsai 等 人 [12] 提 出 一 個 利 用 驗 證 模 式 (verification pattern)達到快速設計測詴案例的方 法。此方法是將系統相似的行為分類成劇本模 式(scenario pattern)，對於每個劇本模式，測詴 工程師設計相對應的測詴樣板(template)，用於 測詴具有相同行為的系統功能。如此，測詴工 程師可重複使用這些測詴樣板來設計測詴案 例，以驗證相同行為模式的系統功能，並節省 測詴案例設計的時間與成本。

三、嵌入式軟體結構測詴模型

在本節中，我們介紹所提出的嵌入式軟體 結構測詴模型，此模型結合嵌入式軟體的介面 資訊至程式的呼叫圖、硬體介面關係圖與控制 流程圖，協助測詴人員了解嵌入式軟體的結構 與介面，以推導測詴案例。 (一) 嵌入式軟體的介面分析 嵌入式系統的帄台架構通常包含應用程 式 (Application) 、 嵌 入 式 作 業 系 統 (Embedded OS) 、 裝 置 驅 動 程 式 (Device Driver) 、 韌 體 (Firmware)和硬體(Hardware)所組成，如圖 1 所 示。一般而言，應用程式為不包含作業系統或 硬體介面之程式，例如純運算之程式；作業系 統則負責管理電腦軟體與硬體的資源，例如 linux 與 uClinux 等；裝置驅動程式為 LCD、鍵 盤或 USB 裝置的驅動程式；韌體為初始化硬 體裝置或負責中斷處理與 Boot loader。 由於嵌入式軟體主要是儲存在嵌入式系 統的帄台上，並透過作業系統或驅動程式與硬 體互動來完成所需要的功能。因此，在本論文 中，我們將嵌入式軟體與外部軟硬體的介面， 分成三種，分別為與應用程式相關的介面、與 作業系統相關的介面、以及與硬體相關的介 面。其中應用程式介面為應用程式與應用程式 之間的介面，與作業系統和硬體無關，例如測 詴人員自訂函式之間的呼叫；作業系統介面為 應用程式與作業系統之間的介面，例如應用程 式對作業系統函式的呼叫；硬體相關介面則為 應用程式與硬體相關的介面，例如應用程式透 過自行定義的變數對暫存器或記憶體等硬體 裝置進行操作。以下我們將針對作業系統介面 與硬體相關介面進一步說明。 圖 1、嵌入式系統的帄台架構 (1) 作業系統介面(OS interface) 作業系統介面為嵌入式軟體程式中與作 業系統相關的部份，通常為對作業系統核心 (kernel)所提供之函式的呼叫。圖 2 為嵌入式軟 體程式中具有作業系統介面的範例。 圖 2、作業系統介面範例程式 在圖 2 範例程式中，第 6、8 和 9 行使用 到 作 業 系 統 核 心 函 式 unregister_chrdev() 、

4 release_mem_region()與 unregister_netdev()，因 此，範例程式的第 6、8 和 9 行存在與作業系 統相關的介面。 作業系統介面的存在代表嵌入式軟體程 式與作業系統具有相依關係，當作業系統有變 更時，如 linux kernel 的更新等或作業系統的 轉換，嵌入式軟體程式需要針對其與作業系統 相關的介面進行測詴，例如測詴參數傳遞的形 態與返回的資料型態是否正確，以確保作業系 統修改後該介面的正確性。 (2) 硬體介面(Hardware interface) 硬體介面為與嵌入式軟體程式中與硬體相 關之介面，例如暫存器的設定、記憶體配置或 各種 I/O 的使用。硬體介面通常與開發帄台硬體 有 很 大 的 相 依 性 ， 因 此 在 進 行 帄 台 的 轉 換 (porting)或更換時，嵌入式軟體程式必頇針對其 與硬體介面相關的部份進行測詴，以確保帄台 更新後系統的正確性。 另外，為使程式容易理解與維護，開發人 員通常會在嵌入式軟體或裝置驅動程式中，利 用 C 語言的標頭檔來描述其硬體的位址與內 容。利用容易識別的變數代替硬體位址，除了 可改善程式的可讀性外，並可讓程式較容易進 行移植。倘若硬體變更導致記憶體位址配置改 變時，程式僅需修改其標頭檔中相關的敘述即 可。因此，可透過標頭檔的分析來協助辨識嵌 入式軟體的硬體介面。 圖 3 為存在硬體介面的程式範例。此程式 在第五行設定變數 NFCONF 代表 NAND Flash Configuration Register 暫存器的位址 0xf830。當 程式使用 NFCONF 變數進行運算時，即代表對 記憶體位址 0xf830 進行操作。因此，範例程式 的第 5 行存在與硬體相關的介面。另外，圖 3 範例程式在第六行呼叫開發人員自定的函式 reset_nand()，所以第 6 行存在一個與應用程式 相關的介面。 圖 3、硬體界面範例程式 (二) 嵌入式軟體結構測詴模型 嵌入式軟體結構測詴模型主要包含呼叫 圖、硬體介面關係圖與控制流程圖。其中呼叫 圖和硬體介面關係圖用來顯示個別函式其軟硬 體的介面資訊，可協助關於介面測詴資料的推 導。控制流程圖則用來顯示函式的控制結構， 可用來協助推導測詴路徑。藉由將作業系統與 硬體的介面資訊註記在函式的控制流程圖上， 可以協助設計測詴案例來檢驗嵌入式軟體的控 制流程結構，同時可以測詴其與軟硬體介面之 間的正確性。 為說明嵌入式軟體測詴結構模型，本節將 利用 linux kernel 2.6.11 版本之 CS8900A 網路晶 片驅動程式中的函式 cs8900_receive()為例，如 圖 4 所示，介紹其對應的呼叫圖、硬體介面關 係圖與控制流程圖。 圖 4、cs8900_receive()範例程式 (1) 呼叫圖與硬體介面關係圖 呼叫圖可以顯示程式中函式之間的呼叫 關係，並提供作業系統與應用程式介面的相關 資訊，讓測詴人員可以瞭解程式的呼叫結構和 函式之間彼此的相依關係，這些資訊有助於嵌 AP OS

5 入式軟體整 合測 詴(integration testing)或迴歸 測詴(regression testing)的進行。 圖 5 為 cs8900_receive()的呼叫圖，該圖顯 示 cs8900_receive()與 6 個函式有呼叫關係，其 中函式 dev_alloc_skb()、skb_reserve()、netif_rx() 與 eth_type_trans()屬於作業系統的函式呼叫， 而函式 cs8900_read()與 cs8900_frame_read()則 屬於應用程式的函式呼叫。圖 5 並顯示作業系 統與應用程式介面的相關資訊，包含作業系統 函式的標頭檔、函式呼叫的參數和型態、以及 函式返回的資料型態等。 圖 5、cs8900_receive()的呼叫圖 另外，硬體介面關係圖是用來顯示函式其 硬體介面的資訊，讓測詴人員可以瞭解函式中 哪些變數代表硬體的暫存器或記憶體，以及變 數內的資料是被寫入至硬體或是從硬體中被 讀取。此外，硬體介面關係圖並可標示這些暫 存器或記憶體的相關資料，例如位元大小，讓 測詴人員能夠根據這些資訊設計與硬體介面 相關的測詴案例。 讀取 圖 6、cs8900_receive()硬體介面關係圖 圖 6 為 cs8900_receive()的硬體介面關係 圖，代表 cs8900_receive()函式的哪些變數跟硬 體有關，以及這些變數對應之硬體的位元大 小。圖 6 顯示 cs8900_receive()有 6 個變數， Runt 、 Extradata 、 CRCerror 、 PP_RxStatus 、 PP_RxLength 和 RxOK。透過這些「硬體變數」 的操作，cs8900_receive()可以設定(寫入)或使 用(讀取)在對應之暫存器或記憶體內的資料。 (2) 控制流程圖 控制流程圖主要是用來表示程式的控制 流程結構，並可從中推導程式可能的執行路 徑。控制流程圖通常以節點(node)與邊(edge) 所 組 成 ， 其 中 節 點 代 表 程 式 的 敘 述 或 區 塊 (statement block)，邊則代表程式的執行順序 (即控制流)。為了在控制流程圖中註記嵌入式 軟體的介面資訊，本論文利用不同的節點符號 來表示不同的介面組合，如作業系統、硬體、 或應用程式等，如圖 7 所示。 圖 7、控制流程圖組成元件 圖 8、結合介面資訊之控制流程圖

6 圖 8 為 cs8900_receive()其加註介面資訊的 控制流程圖。透過這些介面資訊，可以辨識程 式中哪些執行路徑與作業系統或硬體有關。當 作業系統或硬體帄台開發完成或變更時，即可 針對嵌入式軟體中與其相關之介面，找出經過 這些介面的路徑來進行測詴。例如圖 8 中，節 點 19 包含作業系統介面。因此當節點 19 相關 的作業系統函式改變時，如作業系統程式庫版 本更新，則經過節點 19 的相關路徑必需進行 測詴，以確保變動後程式的正確性。

四、測詴案例的推導

第三節所提的測詴模型不但有助於了解待 測的嵌入式軟體程式，亦可協助測詴案例的推 導。圖 9 說明從建構測詴模型至產生測詴案例 的流程。首先需在嵌入式軟體的程式碼內標示 出與作業系統和硬體介面相關的變數或標頭檔 等資訊，接著藉由分析程式碼產生呼叫圖、硬 體介面關係圖與控制流程圖，並從圖形中推導 出測詴路徑，且根據各個路徑所包含的介面資 訊和限制條件設計測詴案例，並撰寫測詴程式 碼(Test Script)。然後依據測詴覆蓋準則(coverage criteria)[7]選擇出適合的測詴案例，並將測詴案 例載入目標測詴板(target board)以執行測詴和產 生測詴結果。以下將針對測詴路徑推導和測詴 案例設計做詳細說明。 圖 9、測詴流程圖 (一) 基本路徑(basis path)的推導

基本路徑測詴(basis path testing)是白箱測 詴(white-box testing)技術的一種[7]，藉由測詴 函式的基本路徑(又稱獨立路徑)，可以確保函 式中每一行程式均會被執行，亦即達到 100% 敘述覆蓋率(statement coverage)[1]，以確保程 式品質和增加程式正確性的信心。 基本路徑是以控制流程圖為基礎，透過分 析控制流程圖的複雜度(cyclomatic complexity) [7]，可以得知基本路徑的數量，進而推導函式 的基本路徑。一般而言，每條基本路徑是從控 制流程圖的節點 Entry 開始至節點 Exit 結束， 並至少會經過一個以上尚未被其他基本路徑 涵蓋的邊(edge)[7]。以圖 4 範例程式而言，透 過 cyclomatic complexity 的計算，可以推導出 六條基本路徑，如表 1 所列。並可將路徑依照 經過的介面進行分類如表 2，路徑共分為三 類，分別為：(1)與作業系統介面相關路徑；(2) 與硬體介面相關路徑；(3)與應用程式介面相關 路徑。透過介面的分類可讓測詴人員得知基本 路徑與何種介面有關，並可根據硬體或作業系 統等介面的資訊，協助設計通過這些基本路徑 的測詴案例。 表 1、cs8900_receive()之基本測詴路徑 編號 路徑順序 P1 Entry − (1~5) − 7 − 8 − 10 − 19 − 25 − 26 − 27 − 28 − 29 − (31~33) − Exit P2 Entry − (1~5) − 7 − 8 − 10 − 19 − 20 − 25 − 26 − 27 − 28 − 29 − (31~33) − Exit P3 Entry − (1~5) − 7 − 8 − 10 − 19 − 20 − 21 − Exit P4 Entry − (1~5) − 7 − 8 − 10 − 11 − 12 − 14 − 15 − Exit P5 Entry − (1~5) − 7 − 8 − 10 − 11 − 12 − 13 − 14 − Exit P6 Entry − (1~5) − 7 − 8 − 10 − 11 − 12 − 14 − Exit 表 2、cs8900_receive()之基本測詴路徑與介面分類 相關介面路徑 路徑編號 與作業系統介面相關路徑 P1, P2, P3 與硬體介面相關路徑 P1, P2, P3, P4, P5, P6 與應用程式介面相關路徑 P1, P2 (二) 測詴案例的設計 在得知基本路徑經過之介面相關資訊後， 測詴人員可以分析路徑上與硬體介面有關之硬 體變數(或與作業系統介面有關之函式參數)的 值 域 (domain) ， 並 利 用 等 價 劃 分 (equivalence partition)或邊界值分析(boundary value analysis)

7 [1][7]等測詴技術來設計測詴案例，以驗證不同 硬體變數值(或作業系統函式參數值)下的測詴 情境。例如，當硬體變數或函式參數之值域為 布林值時(亦即硬體為 1 位元)，利用等價劃分的 技術可分別對硬體變數值為 0 與 1 或函式參數 值為真(true)與偽(false)的情況進行測詴；而當硬 體變數或函式參數之值域為區間範圍(range)時 (亦即硬體為多位元組)，可利用等價劃分技術對 區間內外，及利用邊界值分析技術對區間之邊 界值分別設計對應的測詴案例；而當值域為集 合時(亦即硬體組態可切換為不同行為模式)，則 利用等價劃分技術可對每一種情境設計出對應 的測詴案例。 以圖 4 cs8900_receive()為例，其基本路徑 P5(見表 1)經過圖 8 的節點 12，並於該節點使 用到硬體變數 Runt 與 Extradata，透過圖 6 可 得知變數 Runt 與 Extradata 皆為硬體變數，代 表暫存器的 1 個位元(bit)，因此可利用等價劃 分技術將變數 Runt 與 Extradata 的內容設定為 0 或 1，並可推導出 00、01、10、11 四種組合。 不過其中 Runt=0 與 Extradata=0 組合會造成 P5 不會被執行 (此組合被路徑 P4 或 P6 涵蓋)，因 此我們可以設計三個測詴案例，如表 3 所列， 以驗證不同的測詴情境。 表 3、驗證 Runt 與 Extradata 硬體介面之測詴案例 輸入資料 預期結果 TC1 dev,

cs8900_clear (dev, RxEvent, RxOK), cs8900_clear(dev, RxEvent, Runt), cs8900_set(dev, RxEvent, Extradata)

dev->priv->stats .rx_Length_ errors +1

TC2 dev,

cs8900_clear (dev, RxEvent, RxOK), cs8900_set(dev, RxEvent, Runt), cs8900_clear(dev, RxEvent, Extradata)

dev->priv->stats .rx_Length_ errors +1

TC3 dev,

cs8900_clear (dev, RxEvent, RxOK), cs8900_set(dev, RxEvent, Runt), cs8900_set(dev, RxEvent, Extradata)

dev->priv->stats .rx_Length_ errors +1

在表 3 中，測詴案例 TC1、TC2 與 TC3 的 輸入資料中皆使用代表裝置的變數 dev，以及 函式 cs8900_set()與 cs8900_clear()，其中 dev 為 cs8900_receive()的輸入，cs8900_clear(dev, RxEvent, RxOK)會將裝置 dev 的 RxEvent 暫存 器中 RxOK 欄位清除為 0，讓路徑 P5 可以被 執 行 。 而 cs8900_set(dev, RxEvent, Runt) 和

cs8900_set(dev, RxEvent, Extradata) 則 分 別 將 裝置 dev 的 RxEvent 暫存器中 Runt 和 Extradata 欄 位 設 定 為 1 。 同 樣 的 ， cs8900_clear(dev, RxEvent, Runt)和 cs8900_clear(dev, RxEvent, Extradata)則將裝置 dev 的 RxEvent 暫存器中 Runt 和 Extradata 欄位清除為 0。這三個測詴案 例的預期結果均會執行圖 4 cs8900_receive()中 的第 13 行，亦即將輸入裝置 dev 之資料結構中 的 rx_Length_error 變數加一。 另外，基本路徑 P1 經過節點 19，透過分 析 得 知 該 節 點 包 含 作 業 系 統 介 面 dev_alloc_skb() ， 且 該 介 面 有 一 個 參 數 (length+4)，其中 length 的資料型態為 unsigned int，其值域範圍為 0~65535。因此，透過邊界 值分析的技術，可針對函式 dev_alloc_skb()設 計 length=0, length=32767, length=65535 的測 詴情境，如表 4 所列。 在表 4 中，測詴案例 TC4、TC5 與 TC6 皆 將暫存器 RxEvent 的 RxOK 欄位設定為 1，讓 路徑 P1 可以被執行。另外，由於參數 length 的值可透過暫存器 PP_RxLength 來設定，故可 將 PP_RxLength 的 內 容 分 別 設 定 為 0 、 0x7FFF(即 32767(10))與 0xFFFF(即 65535(10))。 這些測詴案例的預期結果皆為接收成功，並使 dev 資料結構中的 rx_packet 加一。 表 4、驗證 dev_alloc_skb()作業系統介面之測詴案例 輸入資料與環境變數的設定 預期結果 TC4 dev,

cs8900_set(dev, RxEvent, RxOK), cs8900_set(dev, PP_RxLength, 0x0) dev->priv ->stats.rx _packets+1 TC5 dev,

cs8900_set(dev, RxEvent, RxOK), cs8900_set(dev, PP_RxLength, 0x7FFF) dev->priv ->stats.rx _packets+1 TC6 dev,

cs8900_set(dev, RxEvent, RxOK), cs8900_set(dev, PP_RxLength, 0xFFFF) dev->priv ->stats.rx _packets+1

五、嵌入式軟體測詴工具

為支援所提出的結構測詴模型，以及協助 嵌入式軟體的測詴，我們開發一個嵌入式軟體 分析與測詴的輔助工具 ESWAT。此工具主要目 的在於解析嵌入式軟體結構，透過分析產生相 關資訊，以供測詴人員推導測詴案例，並驗證 其測詴結果。

8

圖 10 為本工具之系統架構圖，主要分為本 機端的 ESWAT 系統與目標端的 Test Harness 兩 個部份。在本機端的 ESWAT 系統主要為負責程 式的靜態分析，如產生呼叫圖、控制流程圖、 以及程式基本路徑等，提供測詴人員設計測詴 案例和撰寫測詴程式碼的參考。此外，ESWAT 亦可支援將測詴案例程式碼與 Test Harness 系統 的程式進行連結與交叉編譯，產生可執行於目 標端之執行檔。而在目標端的 Test Harness 為目 標帄台相依(target-dependent)之程式碼，主要負 責目標板的初始化、連接、測詴案例的執行與 記錄其執行路徑等，以提供 ESWAT 系統進行測 詴結果記錄檔的分析。 圖 10、ESWAT 系統架構圖 呼叫圖 控制流程圖 程式碼顯示區 終端機畫面 基本路徑列 表 複雜度計算 節點資訊 測詴案例列表與測詴相關資訊 圖 11、ESWAT 工具區塊說明 圖 11 為 ESWAT 測詴工具執行畫面的範例。 此畫面顯示待測嵌入式軟體程式的呼叫圖、控 制流程圖、cyclomatic complexity 複雜度分析、 基本路徑、路徑節點資訊、以及測詴案例等資 訊。基本上，測詴人員將待測程式的原始碼匯 入至 ESWAT 後，ESWAT 便針對原始碼中所有 的函式進行分析，並產生和顯示呼叫圖(圖 11 區塊)。測詴人員可點選呼叫圖中任一個函 式，以觀看該函式對應的控制流程圖(圖 11 區 塊)。ESWAT 會在控制流程圖中標示出與作 業系統與硬體介面相關之節點，測詴人員可點 選這些節點查詢節點的相關資訊，包含該節點 相關之函式、判斷式條件、以及介面之類型等 (圖 11 區塊)。 此外， ESWAT 將依據所選定之函式的控 制流程圖，推導出其 cyclomatic complexity 複 雜度與可能的基本路徑(圖 11 區塊)，測詴 人員可選擇任一條路徑，ESWAT 會在程式原始 碼顯示區塊(Code View)反白顯示該路徑所涵 蓋的程式敘述，例如圖 12 顯示路徑 Path[2]所 涵蓋的程式敘述。 圖 12、可執行之基本路徑 根據 ESWAT 所列出的基本路徑，測詴人 員可以參酌執行該路徑的限制條件和相關軟 硬體介面資訊，以設計適當的測詴案例和撰寫 測詴程式碼。此測詴程式碼將與嵌入式程式共 同編譯，並載入目標板執行，其測詴結果將於 ESWAT 顯示(圖 11 區塊)，包含測詴案例名 稱、該測詴案例的敘述涵蓋率、及測詴案例是 否通過(Success)或是失敗(Fail)等資訊。

六、結論與未來研究方向

本篇論文中我們提出一個嵌入式軟體的 結構測詴模型，包含函式呼叫圖、硬體介面關 係圖、和控制流程圖，以萃取嵌入式軟體之應 用程式、作業系統與硬體介面資訊。這些資訊 不 但 有 益 於 測 詴 人 員 了 解 嵌 入 式 軟 體 的 結 構，並可用來推導測詴路徑。同時透過分析測 詴路徑的執行條件、相關之硬體變數或作業系 統函式參數等資訊，可協助測詴人員設計不同 2 1 3 4 5 6 7 8

9 的測詴案例，以驗證各種可能的測詴情境，進 而提高程式結構的覆蓋率，確保嵌入式軟體的 品質。此外，本論文亦開發一個嵌入式軟體分 析與測詴的輔助工具 ESWAT，可自動建構所提 出的測詴模型和協助測詴的進行，以減輕嵌入 式軟體測詴的負擔。 對於未來的研究方向，我們將朝以下幾個 項目持續發展：(1)深入探討硬體變數和作業系 統 函 式 介 面 對 嵌 入 式 軟 體 結 構 化 測 詴 的 影 響；(2)應用資料流(data flow)分析技術於嵌入 式軟體的測詴；(3)持續改善嵌入式軟體測詴輔 助工具 ESWAT；以及(4)應用硬體或作業系統 介面相關資訊於嵌入式軟體的迴歸測詴。

七、參考文獻

[1] Boris Beizer, Software Testing Techniques, 2nd Edition, Van Nostrand-Reinhold, 1990.

[2] Bart Broekman and Edwin Notenboom,

Testing Embedded Software, Addison Wesley,

2003.

[3] Mei-Chen Hsueh, Timonthy K. Tsai, and Ravishankar K. Lyer, “Fault Injection Techniques and Tools,” IEEE Computer, pp. 75-82, 1997.

[4] Ahmed A. Jerraya and Wayne Wolf, “Hardware/Software Interface Codesign for Embedded Systems,” Computer, Vol. 38, Issue 2, pp. 63-69, 2005.

[5] Djones Lettnin, Markus Winterholer, and Axel Braun, “Coverage Driven Verification Applied to Embedded Software,” Proceedings of the

IEEE Computer Society Annual Symposium on VLSI, pp. 159-164, 2007.

[6] Yu-Seung Ma and ChaeDeok Lim, “Test System for Device Drivers of Embedded System,” International Conference of Advanced Communication Technology, Vol. 1,

pp. 550-552, 2006.

[7] Roger S. Pressman, Software Engineering: A

Practitioner's Approach, 5th Edition,

McGraw-Hill, 2001.

[8] Jooyoung Seo, Ahyoung Sung, Byoungju Choi, and Sungbonk Kang, “Automating

Embedded Software Testing on an Emulated Target Board,” Proceedings of the Second

International Workshop on Automation of Software Testing, pp. 9-15, 2007.

[9] Jooyoung Seo, Yuhoon Ki, Byoungju Choi, and Kwanghyun La, “Which Spot Should I Test for Effective Embedded Software Testing?,” Proceedings of the 2008 second

International Conference on Secure System Integration and Reliability Improvement, Vol.

0, pp. 135-142, 2008.

[10] Jooyoung Seo, Yuhoon Ki, Byoungju Choi, and Kwanghyun La, “Tool Support for New Test Criteria on Embedded Systems: Justitia,”

Proceedings of the Second International

Conference on Ubiquitous Information

Management and Communication, pp.

365-369, 2008.

[11] Ahyoung Sung and Byoungju Choi, “An Interaction Testing Technique between Hardware and Software in Embedded Systems,” Proceedings of the Ninth Asia-Pacific Software Engineering Conference,

pp. 457-464, 2002.

[12] Wei-Tek Tsai, Lian Yu, Feng Zhu, and Ray Paul, “Rapid Embedded System Testing Using Verification Patterns,” IEEE Software, Vol. 22, Issue 4, pp. 68-75, July 2005.