PAGEPAGE1目錄1.測試項目背景…………………..41）嵌入式軟件的發展趨勢…………………….42）單元測試對嵌入式軟件的重要性………….42.項目工作階段與技術應用……….53.項目中存在的問題及認識……….74.項目總結及單元測試工具市場前景10測試項目背景1.嵌入式軟件的發展趨勢自從上個世紀90年代以來，以計算機技術、通信技術和軟件技術為核心的信息技術取得了更加迅猛的發展，各種裝備與設備上嵌入式計算與系統的廣泛應用大大地推動了行業的滲透性應用。嵌入式系統被描述為：“以應用為中心、軟件硬件可裁剪的、適應應用系統對功能、可靠性、成本、體積、功耗等嚴格綜合性要求的專用計算機系統”，由嵌入式硬件和嵌入式軟件兩部分組成。硬件是支撐，軟件是靈魂，幾乎所有的嵌入式產品中都需要嵌入式軟件來提供靈活多樣、而且應用特制的功能。由于嵌入式系統應用廣泛，嵌入式軟件在整個軟件產業中占據了重要地位，并受到世界各國的廣泛關注；如今已成為信息產業中最為耀眼的“明星”之一。2.單元測試對嵌入式軟件的重要性單元測試是檢查嵌入式系統軟件缺陷的最有效的一種方法，更確切而言也即在宿主機環境下或在仿真器上進行的API測試。這能使測試盡早開始并且最大程度地降低了測試工作對目標硬件平臺的依賴性。嵌入式系統軟件的單元測試的一個前提是能夠讓軟件獨立于硬件進行測試，這是由樁函數對目標硬件平臺的模擬而實現的。在這種情況下，代碼的絕大多數功能性測試都能夠獨立于目標硬件系統進行測試。這對嵌入式系統開發者而言主要有兩方面的好處：1）單元測試能讓開發者在目標硬件平臺準備好之前就開始測試周期，開發者可以直接在宿主開發環境下開始初始測試（而不需要目標硬件平臺）。2）單元測試采取一種“各個擊破”的策略，允許用戶將復雜的系統分為相對較簡單的準獨立系統進行測試。測試工具能夠管理模塊之間的關聯性并使用樁函數來模擬這些模塊的行為。圖：使用樁函數，開發者可以模擬真實環境和程序之間的相互影響對程序的某個模塊進行測試，而不需要目標硬件平臺以及暫時還未完成的其它代碼模塊。在測試環境中，樁函數充當了為待測模塊提供外部關聯性橋梁的作用。項目工作階段與技術應用談談自己今年7-8月間在長沙做項目的認識吧。測試項目的前期階段工作第一部分是在甲方單位指定的機器上搭載環境，建立測試平臺，同時安裝以下工具軟件：1）CCS（CodeComposerStudio）2.2：是TI公司推出的DSP集成開發環境，集代碼編輯、編譯、調試等多功能于一體的工具，其主要作用是進行函數的拆分，編寫樁、驅動等功能。2）CRESTSTESS：全數字仿真平臺的自動化測試工具，全稱是基于仿真目標機的半物理仿真平臺系統CRESTS/TESSC(SCT-Cast)，以下對其進行簡介：TESSC由宿主機系統（HostSystem）和仿真處理模塊組成。仿真處理模塊包含一個目標處理器的復制（targetCPU，如DSP3X）和支持與控制系統（supportsystem）。目標處理器的復制執行匯編語言程序，Ada語言程序，C語言程序程序的最終二進制代碼。支持與控制系統控制目標處理器復制的行為并仿真低一級硬件的接口。宿主機用于應用測試和全面控制，以及提供更復雜環境的仿真模擬。匯編語言程序，高級語言程序，混合語言程序最終二進制代碼無需任何修改，直接執行于真實目標處理器的復制中，應用于目標軟件真實的外界感知環境的仿真系統中。

TESSC最重要的特性之一是目標處理器的復制和所有和它相關的時間關系都可以被支持系統與控制系統管理、控制。這就意味著在TESSC上的目標軟件（包括匯編語言程序，高級語言程序）的行為過程，完全可以控制，可以在測試期間對目標軟件內部的探查精確而詳細。可以進行更多軟件測試，對目標軟件深層問題進行探究。3）Script.NETV2（免費版）：是一個集開發、編輯的TCL腳本的工具，主要用于TCl腳本開發。4）SourceInsigh：是一個代碼瀏覽器，能夠方便你分析源代碼并在你工作的同時動態維護它自己的符號數據庫，并自動為你顯示有用的上下文信息，進行有效的代碼分析。5）Snagit9.0（試用版）屏幕截圖軟件，用于截取測試執行時需要保存的一些圖片及屏幕提示信息，達到保存屏幕信息目的。項目的前期階段工作第二部分是在測試環境建立好后，我們先對甲方提供的項目文檔進行閱讀，通過閱讀文檔，對項目有了大致的了解，除此之外仔細閱讀項目需求、概要、詳設等文檔還要對代碼進行書面審查，在這里涉及到商業機密，就不詳談了，而后按照甲方的要求，我們對其代碼進行單元測試，測試類型要求分為功能測試、邏輯測試，到了測試項目中期階段，我們的工作進入實質性階段，每個測試小組開始對各自審查的代碼進行測試用例設計，我需要設計用例的函數來自于兩個.C文件fun_1553.C和LIB_FK_861.C，共計是10個函數，分別是計算校驗和、計算關鍵性權威授權、懸掛物數據包、傳遞對準數據包、任務加載數據包、UT1553B總線發送、INT6中斷處理函數、時鐘初始化、UART初始化、UTProcess(進程處理)等函數。對每個函數測試用例設計完成后，就開始執行測試用例的工作，執行測試用例首先是在CCS（CodeComposerStudio）2.2環境中寫驅動函數，通過驅動函數調用.C源文件中的函數，之后要在CCS環境中編譯運行通過后，然后在TESS自動化測試工具中載入該添加驅動函數的.C文件工程，在TESS中通過main函數調用覆蓋被測函數后，用Script.NET編輯TCL腳本，利用腳本在驅動函數和被測函數有輸出處進行插樁、打點，驗看輸出結果的準確性。通過執行的結果，判定函數是否存在問題，若存在將其提交到Bug報告單中。到了測試項目后期階段，我們的工作是將測試用例與Bug報告單的一些基本情況進行統計，比如測試用例、Bug報告單的個數、發現問題的個數、以及用例與報告單的規范性調整，之后將統計的情況向甲方提交，并要參加由甲方組織的評審。項目中存在的問題及認識在設計測試用例過程中，第一個問題是在計算校驗和函數中出現的，該函數整體結構主要是實現一個FOR循環，在FOR循環體中通過對循環次數的控制，一些使得指針左移或右移相應位數的語句和相位與、相或與語句來生成校驗字（checkword）。從函數的結構分析，進行測試用例的設計從兩種測試類型功能測試與邏輯測試，其中邏輯測試又分為分支測試、語句測試。該函數功能測試的目的很明確，就是是否能實現生成數據幀的校驗和的結果，而分支測試（邏輯測試）的目的則是判斷函數在何種情況下執行FOR循環分支或不執行該分支時分支覆蓋率的情況，語句測試則是在上述兩種分支覆蓋的情況下，語句執行情況下，語句覆蓋率的情況。在設計該函數功能測試用例輸入數據時起初存在難點，因為該函數的兩個輸入參數一個是指針，而另一個是數據幀的長度，數據幀的長度有合理輸入范圍1-32之間，因此容易設立輸入初值，而輸入參數為指針的因為在后續的其他函數中（比如懸掛物數據包、傳遞對準數據包、任務加載數據包函數）對其均有調用，調用時對應輸入參數指針均是上述數據包頭字（headword）的地址，而該地址是由計算機隨機分配的，事先無參照值，后來想到用一組數組來代替該隨機分配得計算機地址，然后先將這些輸入數據帶入該函數，通過人工計算得出函數結果，之后再由計算機在TESS中驗看函數計算結果，通過兩個結果比對是否一致，來驗證函數的功能。執行該函數分支測試用例時，也出現了大家共同關心的問題，這一問題使大家在設計測試用例初期產生了巨大的分歧，分歧在于功能測試與邏輯測試雖然在測試概念上完全不同，但在設計用例時可能設計出來的用例完全一致，（例如在計算校驗和函數中，功能測試正反兩個用例一個是執行FOR循環分支實現函數生成校驗字功能；另一個是不執行FOR循環分支未實現函數生成校驗字功能；而分支測試正反兩個用例則與此設計完全一致）一方的意見是盡管一致但因為測試類型不同，所以測試用例還是應該分開寫；另一方的意見則是因為一致，可以考慮合并到一起，只要在測試類型處標明即可；最后大家一致認為同意將其合并，用同一組測試用例表示即可。后面的幾個函數如懸掛物數據包、傳遞對準數據包、任務加載數據包在設計測試用例時，都普遍存在一個問題，就是在來自于調用其他函數參數在給本函數參數進行傳參賦值時，都缺少對傳進來的數據進行正確性的判斷，很顯然程序員在寫這幾個函數的傳值、賦值的語句時，心安理得的認為傳值的數據正確性驗證只用在該參數賦初值的函數里完成正確性驗證即可，其他地方只要保證傳值的正常進行就可以了，而我們測試人員卻要考慮傳值數據的正確性驗證，盡管在我們測試的函數里找不到驗證性的語句，可是在測試腳本里卻要設計各種范圍的數據進行測試，這時如果在腳本里輸入非法數據，函數本身無法發現其錯誤，這里也就設計到單元測試與被測函數之間的矛盾，將被測函數納入到一個完整.C文件去看，則不存在上述問題，但是單元測試將一個.C文件中的每個函數作為一個單獨單元來進行測試，函數與函數之間的關系被測試割裂開來，使得有些函數在諸如傳遞參數方面在不具備獨立性的情況下，喪失了驗證傳參數據的正確性。但在最后測試組討論形成統一的意見是對于被測函數出現的類似的通過其他函數參數進行傳遞賦值的語句，不進行被傳參數數據正確性的驗證，一方面是不需要重復的測試（因為在參數賦初值的函數里一定會進行測試）；另一方面是由于缺少限制參數賦值范圍的語句，根本無法保證被傳參數數據的正確性，不具備作為測試點前提條件；所以也不可以作為Bug提交成報告單。還有一個問題是在函數懸掛物數據包中出現的，在該函數中If條件的嵌套層次很多，在開始設計其測試用例時，將分支測試與路徑測試混淆在一起，將基本的分支進行分支與分支進行了組合，誤認為是新的分支，其實是路徑，在糾正了這個錯誤后，該函數的測試用例個數減少了許多，也因此弄清楚了分支測試與路徑測試的區別與聯系。在進行TCL腳本語言設計時，在源代碼打點處輸出遇到函數輸出不正確的問題，這個問題是在Uart初始化函數中碰到的，在該函數中主要實現是否能正確選擇串口通道、波特率值、合法FIFO級別設置、非法中斷使能設置四項要素，如果有一項未能正確取值，則利用Return語句跳出整個函數，在該函數的TCL腳本中，是在這四個要素分別賦值，若其中由一個進行非法賦值，就跳出函數并返回該處的返回值，在插入腳本打點前期，始終都只能返回正確返回值0，而其他非法情況下的返回值1、2、3、4均不能返回，后來發現原因在于在CCS中編寫驅動函數時，在main函數中調用該初始化函數時，語句只寫到該調用語句，也就是每次執行腳本時，返回值在總是被賦初值為0時就返回了，后來在驅動函數中又加了一條語句后，每次執行腳本后，要執行到調用該初始化函數語句后面一句時，再顯示返回值時就會出現在非法情況下的返回值1、2、3、4，通過對這個問題的分析我們知道TCL腳本在執行返回值時的特點，對自己以后寫腳本時提高了一些認識吧。后來在寫Bug問題報告單時，也是這個Uart初始化函數基于其函數結構是單入口、多出口函數結構，在測試規范上要求函數結構是單入口、單出口結構，所以該函數在結構上存在問題，但是根據該函數實現的功能來看，單入口、多出口函數結構才符合其要求，這給程序員們提出了一個難題。項目總結及單元測試工具市場前景在這次測試項目中，自己了解到了做嵌入式軟件尤其是單元測試的基本操作流程和做單元測試所需的一些測試工具的使用特點，對于編寫測試腳本和選取合適的腳本插入點也形成了自己的一些認識，對于單元測試工具在做測試時需要哪些測試功能，提供給測試人員哪些信息和統計數據有助于測試人員的分析以及測試用例的設計，是評價一款單元測試工具幾個重要特征，在我們公司提供的單元測試工具TESS中，除了可以進行代碼靜態分析和插入測試人員編寫的TCL腳本以外，還可以查看各個函數調用覆蓋情況，另外還可以查看每次執行腳本后，調用的函數中的分支和語句覆蓋率的情況，對于測試人員設計的測試用例中的預期結果和實際結果的分析有很直觀的比對作用。目前嵌入式軟件測