嵌入式軟件測(cè)試技術(shù)研究1122

目錄第1章緒論 3 課題背景及研究意義 3 研究?jī)?nèi)容 4 國(guó)內(nèi)外關(guān)于嵌入式軟件測(cè)試的研究現(xiàn)狀 5 關(guān)于論文的組織結(jié)構(gòu) 6第2章嵌入式系統(tǒng)及其軟件 7嵌入式系統(tǒng) 7關(guān)于嵌入式系統(tǒng)及其軟件的相關(guān)特點(diǎn) 7嵌入式軟件開發(fā)模式 10嵌入式軟件三大特點(diǎn)對(duì)軟件測(cè)試的影響 13實(shí)時(shí)性的影響 13嵌入性的影響 13反應(yīng)性的影響 14第3章嵌入式系統(tǒng)軟件測(cè)試 15概述軟件測(cè)試 15軟件測(cè)試目的 15軟件測(cè)試對(duì)象 16軟件測(cè)試數(shù)據(jù)流圖 16軟件測(cè)試方法 17嵌入式軟件的測(cè)試 18關(guān)于測(cè)試策略 18測(cè)試方法 18測(cè)試工具 21嵌入式系統(tǒng)測(cè)試流程 23第4章嵌入式系統(tǒng)軟件測(cè)試模型 26嵌入式的軟件測(cè)試模型 264.1.1V測(cè)試模型 264.1.2X測(cè)試模型 274.1.3W測(cè)試模型 29提出的新的軟件測(cè)試模型 29第5章嵌入式系統(tǒng)軟件測(cè)試模型應(yīng)用 33超市倉(cāng)儲(chǔ)管理系統(tǒng)的結(jié)構(gòu)和特點(diǎn) 33超市倉(cāng)儲(chǔ)管理系統(tǒng)的結(jié)構(gòu) 33超市倉(cāng)儲(chǔ)管理系統(tǒng)的特點(diǎn) 34超市倉(cāng)儲(chǔ)管理系統(tǒng)的測(cè)試方案 34針對(duì)系統(tǒng)開發(fā)語(yǔ)言制定的測(cè)試方案 34針對(duì)用戶界面的測(cè)試方案 35單元測(cè)試的實(shí)現(xiàn) 35單元測(cè)試介紹 35單元測(cè)試的策略與實(shí)現(xiàn) 36集成測(cè)試的實(shí)現(xiàn) 39集成測(cè)試介紹 39集成測(cè)試策略 40集成測(cè)試過程的實(shí)現(xiàn) 41第6章結(jié)束語(yǔ) 44參考文獻(xiàn) 45作者簡(jiǎn)歷 49致謝 50緒論課題背景及研究意義隨著技術(shù)的發(fā)展，計(jì)算機(jī)越來越多的進(jìn)入人們生活的各個(gè)領(lǐng)域。小到電冰箱、洗衣機(jī)等家用電器，大到飛機(jī)、火箭等航空航天領(lǐng)域的設(shè)備，隨處都可以看到計(jì)算機(jī)和計(jì)算機(jī)軟件的身影。計(jì)算機(jī)的廣泛應(yīng)用，使得人們對(duì)計(jì)算機(jī)軟件的質(zhì)量提出了很高的要求，尤其是一些對(duì)軟件安全性和可靠性要求很高的領(lǐng)域如金融、通信、國(guó)防、航天等，對(duì)軟件的質(zhì)量要求更為嚴(yán)格。同時(shí)一些重大事故的發(fā)生，也使得軟件質(zhì)量問題成為人們關(guān)注的焦點(diǎn)。例如，1999年12月3日美國(guó)航天局的火星極地登陸者號(hào)探測(cè)器試圖在火星表面著陸時(shí)失蹤[1]，2002年歐洲載重10噸的阿麗亞娜5型火箭發(fā)射失敗，最后都被證實(shí)是軟件質(zhì)量問題所引發(fā)的。統(tǒng)計(jì)資料表明，目前在一些計(jì)算機(jī)系統(tǒng)中，在可靠性方面，軟件較之硬件普遍要低一個(gè)數(shù)量級(jí)[2]。軟件在武器裝備中所導(dǎo)致的失效事件也多于硬件。如：美國(guó)在對(duì)F18戰(zhàn)斗機(jī)飛行控制系統(tǒng)進(jìn)行首飛試驗(yàn)過程時(shí)[3]，2萬小時(shí)中軟件失效為309次，而硬件失效為271次。又如，曾有某艦載計(jì)算機(jī)，在其CPU運(yùn)行的850個(gè)小時(shí)內(nèi)，失效120次，而軟件失效就達(dá)70﹪；至于致命失效事件，軟件失效仍然占到了70﹪[4]。這些無疑都表明，軟件缺陷已成為了一個(gè)不容忽視的問題，如何提高軟件的可靠性也亟待解決。而在軟件開發(fā)過程中，軟件測(cè)試起到了及其重要的作用，它是提高軟件可靠性的有效手段。然而，軟件測(cè)試卻非常復(fù)雜又很耗時(shí)，嵌入式系統(tǒng)更是這樣[5]。在對(duì)嵌入式軟件進(jìn)行測(cè)試時(shí)，一方面要考慮軟件本身，另一方面還需要考慮軟件與硬件部件之間的緊密關(guān)系，而此種緊密關(guān)系常常表現(xiàn)為條件苛刻的實(shí)時(shí)要求與時(shí)間約束，以及其他性能相關(guān)的關(guān)系。目前，嵌入式系統(tǒng)已經(jīng)在工業(yè)方面獲得了極為廣泛的應(yīng)用，并且呈現(xiàn)出加速擴(kuò)張的趨勢(shì)。嵌入式軟件作為嵌入式系統(tǒng)中最重要的部分，往往對(duì)嵌入式系統(tǒng)的質(zhì)量起著決定性的作用。通常，嵌入式系統(tǒng)對(duì)于軟件的可靠性、有效性和穩(wěn)定性要求非常高，而更多的災(zāi)難性后果也往往是由于嵌入式系統(tǒng)的安全性失效所致[6]，退一步來說，即便是非安全性系統(tǒng)，大批量生產(chǎn)也可能造成嚴(yán)重的經(jīng)濟(jì)損失[7]。這無疑是在要求包括嵌入式軟件在內(nèi)的嵌入式系統(tǒng)的測(cè)試、確認(rèn)和驗(yàn)證更加的嚴(yán)格化。針對(duì)可靠性高的嵌入式設(shè)備而言，傳統(tǒng)的測(cè)試方法通常很難確保系統(tǒng)的每次軟件升級(jí)和軟件改進(jìn)都做到了萬無一失。就目前情況而言，許多軟件的測(cè)試基本上還都停留在手工階段，在工程實(shí)踐中，這必定大大提高軟件測(cè)試開銷，延長(zhǎng)軟件開發(fā)周期，難以滿足對(duì)軟件高可靠性和高可信度的需求。與此同時(shí)，測(cè)試階段對(duì)資源的巨大消耗也越來越成為降低軟件開發(fā)成本，提高軟件開發(fā)效率的瓶頸。因此，迫切需要研究適合嵌入式軟件測(cè)試的自動(dòng)化技術(shù)。一直以來，自動(dòng)化軟件測(cè)試被認(rèn)為是提高軟件測(cè)試效率、降低軟件測(cè)試成本的最為有效的手段。對(duì)于嵌入式系統(tǒng)而言，由于嵌入式設(shè)備的特殊性，往往需要一套適應(yīng)被測(cè)嵌入式系統(tǒng)自身特點(diǎn)的測(cè)試方法，以便將自動(dòng)化測(cè)試技術(shù)的理論和方法應(yīng)用到具體的嵌入式系統(tǒng)中去。研究?jī)?nèi)容本文通過對(duì)嵌入式軟件特點(diǎn)的深入分析和對(duì)軟件自動(dòng)化測(cè)試技術(shù)的理論研究和類比，著眼于將自動(dòng)化測(cè)試技術(shù)的理論成果應(yīng)用于嵌入式軟件測(cè)試的具體實(shí)踐，以求提高嵌入式軟件測(cè)試的效率并降低嵌入式軟件測(cè)試的成本。具體的研究?jī)?nèi)容包括：本文首先改進(jìn)了回歸測(cè)試，改進(jìn)的測(cè)試模型新增了指向箭頭，這些箭頭從各個(gè)不同的測(cè)試階段指向單元測(cè)試，改進(jìn)后的回歸測(cè)試均從最底層的單元開始測(cè)試，不僅可以使原有的錯(cuò)誤得到修改同時(shí)也避免了新錯(cuò)誤的出現(xiàn)。其次，本文打破了傳統(tǒng)的理想化測(cè)試模型，發(fā)掘出了包括相鄰測(cè)試階段甚至非相鄰測(cè)試階段等各個(gè)測(cè)試活動(dòng)的并行性，傳統(tǒng)測(cè)試模型嚴(yán)格分開了各個(gè)測(cè)試階段，而在新發(fā)掘出的測(cè)試模型中，各個(gè)測(cè)試階段之間沒有那么明確的時(shí)間界限。通常，軟件開發(fā)過程中，需求變更最容易被忽視，傳統(tǒng)的軟件測(cè)試方法和軟件測(cè)試模型正是如此，而改進(jìn)后的測(cè)試模型，其首先針對(duì)需求變更的類型和原因進(jìn)行了分析，然后基于需求變更對(duì)測(cè)試模型進(jìn)行了改進(jìn)，與此同時(shí)，改進(jìn)后的測(cè)試模型還將可以清晰描述出用戶需求以及需求變更的UML技術(shù)引入到了嵌入式軟件測(cè)試之中。本文研究的主要是針對(duì)某超市倉(cāng)儲(chǔ)管理系統(tǒng)進(jìn)行的。我們提出了具體的實(shí)施方案，我們的任務(wù)重點(diǎn)就是進(jìn)行全程的軟件測(cè)試工作，主要工作是針對(duì)這些超市的實(shí)際情況制定出一套切實(shí)可行的測(cè)試規(guī)范。結(jié)合實(shí)際開發(fā)過程，本文主要研究了下列內(nèi)容:(l)建立了一種適用的軟件測(cè)試模型，在該項(xiàng)目中主要強(qiáng)調(diào)群體協(xié)同工作意識(shí)，對(duì)軟件測(cè)試各個(gè)階段的計(jì)劃、實(shí)施、軟件測(cè)試用例的選擇與取舍、軟件測(cè)試總結(jié)以及軟件測(cè)試的管理、組織等進(jìn)行合理的設(shè)計(jì)與安排;(2)分析該超市倉(cāng)儲(chǔ)管理系統(tǒng)的需求，將軟件測(cè)試性設(shè)計(jì)在設(shè)計(jì)初期完成;(3)基于系統(tǒng)本身特性，尋找出可以有效測(cè)試該系統(tǒng)軟件的技術(shù)與方法。本文的研究旨在使軟件測(cè)試可以從機(jī)構(gòu)組織、測(cè)試方法和流程、測(cè)試管理等各個(gè)不同的方面確保其產(chǎn)品質(zhì)量，使產(chǎn)品達(dá)標(biāo)。制定一套合理的測(cè)試流程和組織方法，在指定的期限內(nèi)，加上合理的費(fèi)用人力物力，從而使軟件開發(fā)可以避免低效甚至杜絕無效的重復(fù)測(cè)試，以保證該軟件質(zhì)量。國(guó)內(nèi)外關(guān)于嵌入式軟件測(cè)試的研究現(xiàn)狀基于嵌入式軟件的特點(diǎn)，包括嵌入性、實(shí)時(shí)性和反應(yīng)性等，嵌入式軟件測(cè)試的困難程度和復(fù)雜性都極大地增加了，這也是關(guān)于嵌入式軟件的測(cè)試研究為何一直不能令人滿意的原因所在。國(guó)外于70年代開始了主要針對(duì)單個(gè)系統(tǒng)的嵌入式軟件測(cè)試的研究。1980年，RobertlGlass發(fā)表了“實(shí)時(shí)軟件:調(diào)試和測(cè)試的失落世界”[8]。在文章中，作者描述并分析了嵌入式軟件測(cè)試較之通用軟件測(cè)試落后的現(xiàn)實(shí)狀況，并找到了一些相應(yīng)的解決方案。之后的20年，國(guó)外許多研究機(jī)構(gòu)對(duì)嵌入式軟件的特點(diǎn)，包括嵌入性、實(shí)時(shí)性和反應(yīng)性等問題展開了大量的研究工作，并在一定程度上有了新的成果，與此同時(shí)，許多與嵌入式軟件測(cè)試相應(yīng)的工具也應(yīng)運(yùn)而生。具代表意義的有:Cantata，其作為一種強(qiáng)大的測(cè)試工具由英國(guó)IPL公司提供，而StaticAnalysis作為Cantata的靜態(tài)分析部分可完成一般的靜態(tài)測(cè)試。Cantata通過檢查并測(cè)量代碼標(biāo)準(zhǔn)及代碼復(fù)雜性，從而確定軟件的標(biāo)準(zhǔn)和可維護(hù)性。[9]Logiscope，其作為一組由Telelogic公司提供的嵌入式軟件測(cè)試工具集，不僅貫穿于軟件開發(fā)、代碼評(píng)審階段，還貫穿于單元/集成測(cè)試、系統(tǒng)測(cè)試、軟件維護(hù)階段。Logiscope針對(duì)編碼、測(cè)試和維護(hù)而面向源代碼展開工作，因此，幫助代碼評(píng)審以及動(dòng)態(tài)覆蓋測(cè)試便成為了Logiscope的重點(diǎn)所在。[10]由AMC公司提供的CodeTest，其包括分別用于嵌入式軟件開發(fā)不同階段測(cè)試的三個(gè)產(chǎn)品。在主機(jī)上完成軟件開發(fā)后，采用CodeTestNative產(chǎn)品進(jìn)行測(cè)試;而將軟件植入目標(biāo)系統(tǒng)就需要應(yīng)用CodeTestSoftware-In-Circuit產(chǎn)品，其還可以通過以太網(wǎng)連接對(duì)軟件進(jìn)行測(cè)試;用于系統(tǒng)測(cè)試的是CodeTestHardware-In-Circuit，需要軟硬件配合測(cè)試。[11]作為硬件輔助軟件測(cè)試與分析的一種工具，Code-test利用監(jiān)視系統(tǒng)總線，只有在程序運(yùn)行到插入的特殊點(diǎn)時(shí)其才會(huì)主動(dòng)到數(shù)據(jù)總線上捕獲數(shù)據(jù)回來。英國(guó)LDAR公司提供的靜態(tài)測(cè)試工具Testbed可以完成編程規(guī)則檢查、靜態(tài)數(shù)據(jù)流分析、交叉索引分析、軟件度量分析等靜態(tài)分析功能，并能插裝源代碼。[12]另外，RTInsight作為L(zhǎng)DAR公司的定時(shí)硬件數(shù)據(jù)采集器，將其同被測(cè)試系統(tǒng)的物理總線連接，并一同使用測(cè)試工具Testbed和軟件RTView，進(jìn)行實(shí)時(shí)監(jiān)控系統(tǒng)的總線讀寫，從而實(shí)現(xiàn)時(shí)間性能分析、覆蓋率分析、堆棧監(jiān)控和變量監(jiān)控及系統(tǒng)跟蹤功能。[13]國(guó)內(nèi)于90年代中后期才開始了對(duì)嵌入式軟件測(cè)試技術(shù)以及測(cè)試工具的研究，目前大型的軟件工程往往都傾向于選擇國(guó)外的軟件測(cè)試平臺(tái)，如平臺(tái)logiscope。就國(guó)內(nèi)現(xiàn)狀而言，商業(yè)化的嵌入式系統(tǒng)測(cè)試平臺(tái)尚不存在，但卻存在部分基于研究目的而開發(fā)的測(cè)試系統(tǒng)，具代表意義的為EASTT，由南京大學(xué)開發(fā)。[14]EASTT類似于logiscope，其多應(yīng)用于代碼評(píng)審和動(dòng)態(tài)調(diào)用關(guān)系分析、動(dòng)態(tài)覆蓋測(cè)試等。另外，北航軟件所的SafePro/C，主要用于測(cè)試C語(yǔ)言程序軟件，提供分支覆蓋、語(yǔ)句覆蓋、軌跡文件界面和插樁策略。[15]關(guān)于論文的組織結(jié)構(gòu)第一章主要介紹了本課題的研究背景和研究?jī)?nèi)容。對(duì)于課題所研究的問題主要的研究方法做了概括性介紹。第二章論述了嵌入式系統(tǒng)及其軟件的基本原理，主要包括軟件測(cè)試的常用方法和策略。本文針對(duì)通用軟件測(cè)試的概念、軟件測(cè)試的分類及軟件測(cè)試的過程進(jìn)行了詳細(xì)的研究。嵌入式軟件測(cè)試的特點(diǎn)做了分析。第三章論述了嵌入式系統(tǒng)軟件測(cè)試的基本原理。第四章研究比較了傳統(tǒng)的測(cè)試模型，介紹了改進(jìn)模型的思路；構(gòu)建一種改進(jìn)的嵌入式軟件測(cè)試模型；著重探討了以控制需求變更為基礎(chǔ)而針對(duì)嵌入式軟件測(cè)試模型的改進(jìn)，需求變更分為需求改變，需求減少，需求增加，改進(jìn)的測(cè)試模型以需求變更為起點(diǎn)將測(cè)試引入開發(fā)的各個(gè)不同階段，同時(shí)還打破了傳統(tǒng)的理想化測(cè)試模型，發(fā)掘出了包括相鄰測(cè)試階段甚至非相鄰測(cè)試階段等各個(gè)測(cè)試活動(dòng)的并行性，并且通過改變回歸測(cè)試的循環(huán)幅度進(jìn)而改進(jìn)了回歸測(cè)試，改進(jìn)的測(cè)試模型新增了指向單元測(cè)試的箭頭，且回歸測(cè)試的范圍均從最底層的單元開始測(cè)試。第五章闡述了超市倉(cāng)儲(chǔ)管理系統(tǒng)軟件測(cè)試的設(shè)計(jì)及其實(shí)現(xiàn)過程。嵌入式系統(tǒng)及其軟件嵌入式系統(tǒng)計(jì)算機(jī)自誕生以來便得到了快速的發(fā)展，加之網(wǎng)絡(luò)技術(shù)的迅猛發(fā)展，更多的功能被加到了計(jì)算機(jī)的操作系統(tǒng)中，并導(dǎo)致其越來越大。然而，隨著計(jì)算機(jī)的廣泛應(yīng)用，人們對(duì)計(jì)算機(jī)軟件的質(zhì)量提出了更高更嚴(yán)格的要求。為了適應(yīng)各種多樣的應(yīng)用領(lǐng)域，考慮到系統(tǒng)的可伸縮性、可裁減性、靈活性，一種以計(jì)算機(jī)技術(shù)為基礎(chǔ)、以應(yīng)用為中心、軟硬件可裁減、適應(yīng)應(yīng)用系統(tǒng)對(duì)可靠性、功能、成本、功耗、體積嚴(yán)格要求的專用計(jì)算機(jī)操作系統(tǒng)——EOS，即所謂的嵌入式系統(tǒng)便隨之誕生。當(dāng)前在對(duì)嵌入式計(jì)算機(jī)系統(tǒng)的諸多定義中，比較正式的是:以應(yīng)用為中心，軟硬件可裁減，并且符合應(yīng)用系統(tǒng)對(duì)可靠性、功能、成本、功耗、體積嚴(yán)格要求的專用計(jì)算機(jī)操作系統(tǒng)。[16]一般而言，嵌入式系統(tǒng)為非PC系統(tǒng)，其由硬件和軟件兩部分組成。處理器、存儲(chǔ)器、圖形控制器、外設(shè)器件和1/0端口等屬于硬件部分。而操作系統(tǒng)軟件和應(yīng)用程序編程則屬于軟件部分，操作系統(tǒng)軟件又包括了要求實(shí)時(shí)和多任務(wù)操作。通常，嵌入式是面向特定應(yīng)用的。就所謂的嵌入式系統(tǒng)而言，其是將先進(jìn)的計(jì)算機(jī)系統(tǒng)、電子技術(shù)、半導(dǎo)體技術(shù)與不同行業(yè)的具體應(yīng)用相結(jié)合而得的產(chǎn)物。這也決定了其必然是一個(gè)技術(shù)資金密集、不斷創(chuàng)新、用途廣泛的知識(shí)集成系統(tǒng)。關(guān)于嵌入式系統(tǒng)及其軟件的相關(guān)特點(diǎn)較之通用操作系統(tǒng)而言，嵌入式操作系統(tǒng)具有如下特征:1)小巧?；谇度胧较到y(tǒng)所提供資源的有限性，嵌入式操作系統(tǒng)必須小巧才能滿足對(duì)應(yīng)硬件的限制。2)實(shí)時(shí)性?，F(xiàn)在，大部分EOS都有RTOS內(nèi)核，windowsCE，Linux的實(shí)時(shí)性較弱，經(jīng)改進(jìn)后的Limix系統(tǒng)的實(shí)時(shí)性變得很強(qiáng)，如Rl-Limix。[17]3)強(qiáng)穩(wěn)定性與高可靠性。操作系統(tǒng)上的應(yīng)用程序能否得以順利且可靠的運(yùn)行關(guān)鍵在于任務(wù)管理與調(diào)度策略。4)移植性好。大多數(shù)EOS均可在多種嵌入式處理器中應(yīng)用，如MPU、DSP、MCU、PPC、ARM等。[18]5)可裁減。根據(jù)應(yīng)用需要，EOS可以進(jìn)行裁減，亦或去掉多余部分，亦或簡(jiǎn)化相應(yīng)模塊。[20]6)可固化代碼。鑒于EOS有限的存儲(chǔ)空間，無論是操作系統(tǒng)代碼還是應(yīng)用軟件代碼往往均需要被固化在系統(tǒng)的ROM。[21]采用專為特定用戶群設(shè)計(jì)的專用的嵌入式CPU，通常具有體積小、功耗低、集成度高等特點(diǎn)。通常而言，EOS的專用性和算法唯一性均為完成某項(xiàng)特定任務(wù)而設(shè)計(jì)，設(shè)計(jì)一旦完成便不再發(fā)生改變，其在市場(chǎng)中的生命周期一般較長(zhǎng)。軟硬件之間的相互配合與依賴，在設(shè)計(jì)初期，軟件和硬件二者就相互配合，依賴性很強(qiáng)，旨在提高效率、減少資源浪費(fèi)。結(jié)構(gòu)簡(jiǎn)潔緊湊，鑒于硅片的容量相當(dāng)有限，欲在其上實(shí)現(xiàn)特定的功能就要求其結(jié)構(gòu)盡可能的緊湊。一般而言，大部分嵌入式系統(tǒng)為實(shí)時(shí)控制系統(tǒng)，多用于特定任務(wù)：例如軍工產(chǎn)品、工業(yè)控制、通信設(shè)備等，對(duì)實(shí)時(shí)性的要求很高。關(guān)于嵌入式軟件的相關(guān)特點(diǎn): 嵌入式軟件就是針對(duì)特定的實(shí)際專業(yè)領(lǐng)域的，以相應(yīng)的嵌入式硬件為基礎(chǔ)的，可完成用戶預(yù)期任務(wù)的一種計(jì)算機(jī)軟件。較之通用軟件而言，嵌入式軟件有以下幾種特征:(1)實(shí)時(shí)性實(shí)時(shí)性，也即必須滿足時(shí)間的約束。就實(shí)時(shí)軟件的處理速度來講，其并不見得都很快，準(zhǔn)時(shí)和及時(shí)才最重要。[22]譬如，它們時(shí)間特性的可預(yù)見性。對(duì)實(shí)時(shí)軟件的正確性起決定作用的因素不僅包括系統(tǒng)的功能和行為特性，還包括系統(tǒng)的時(shí)間特性。時(shí)間特性是實(shí)時(shí)軟件區(qū)別于非實(shí)時(shí)軟件的一個(gè)重要方面，它對(duì)實(shí)時(shí)軟件的成功與否起到了關(guān)鍵的作用。而軟件或其進(jìn)程的時(shí)間約束往往是實(shí)時(shí)軟件的時(shí)間約束的主要表現(xiàn)，一般，按照滿足嚴(yán)格時(shí)間約束的軟件或者進(jìn)程來分，實(shí)時(shí)軟件可分為實(shí)時(shí)軟件和實(shí)時(shí)進(jìn)程兩種。[23](2)嵌入性嵌入性表明了嵌入式軟件之開發(fā)環(huán)境與運(yùn)行環(huán)境不一致。一般情況下，嵌入式軟件在宿主機(jī)上開發(fā)，但在目標(biāo)機(jī)上運(yùn)行。(3)反應(yīng)性嵌入式系統(tǒng)也被稱作是反應(yīng)式系統(tǒng)，故其也具備反應(yīng)性。反應(yīng)式系統(tǒng)中，與環(huán)境保持同步關(guān)系且交替經(jīng)歷兩周周期的進(jìn)程構(gòu)成了它的軟件。進(jìn)程的兩周周期為：等待周期和反應(yīng)周期。[24]一般而言，存在于反應(yīng)式系統(tǒng)的行為均為無限的，故其進(jìn)程往往也都無休止地、不間斷地響應(yīng)著來自環(huán)境的激勵(lì)。這樣以來，只能用輸入/輸出序列的二元組來描述反應(yīng)性軟件的行為。[25](4)專用性強(qiáng)和硬件依賴性由于嵌入式軟件總是在針對(duì)特定應(yīng)用領(lǐng)域的特定目標(biāo)環(huán)境下運(yùn)行，故其功能專一，專用性很強(qiáng)。另外，嵌入式軟件需要在硬件的輔助下運(yùn)行，所以，軟件與硬件有著密不可分的聯(lián)系，換句話說，也即嵌入式軟件的硬件依賴性也很強(qiáng)。然而，嵌入式軟件專用性強(qiáng)和硬件依賴性兩特性無疑也給其軟件測(cè)試帶來了挑戰(zhàn)。[26]譬如，怎樣界定軟硬件的錯(cuò)誤，無論是硬件特性還是測(cè)試所需的硬件信號(hào)驅(qū)動(dòng)以及響應(yīng)等均需要在軟件測(cè)試預(yù)于考慮。(5)小型化盡管我們不斷提高了處理的速度，也不斷增加了存儲(chǔ)器的容量，但在大部分的應(yīng)用中，存儲(chǔ)空間仍顯得十分寶貴，鑒于此，要不斷提高程序質(zhì)量，以求減少程序代碼長(zhǎng)度。(6)新的任務(wù)設(shè)計(jì)方法的引入嵌入式應(yīng)用的基本執(zhí)行單元以任務(wù)計(jì)算。系統(tǒng)設(shè)計(jì)時(shí)采用數(shù)個(gè)并發(fā)的任務(wù)替代通用軟件的多個(gè)模塊，同時(shí)也給出了應(yīng)用軟件任務(wù)間接口的定義。[27]DARTs(DesignandAnalysisofReal一Timesystems)的設(shè)計(jì)方法是嵌入式系統(tǒng)在設(shè)計(jì)任務(wù)時(shí)通常采用的方法。DARTS也給出了劃分系統(tǒng)任務(wù)的方法和任務(wù)間接口的定義機(jī)制。[28](7)需要對(duì)開發(fā)完成后的嵌入式軟件進(jìn)行固化及固化測(cè)試通用軟件的開發(fā)可在其測(cè)試完成后直接投入運(yùn)行，但嵌入式軟件則有所不同，在目標(biāo)環(huán)境下必須將嵌入式軟件存儲(chǔ)在非易失性的存儲(chǔ)器之中，以此來確保用戶關(guān)機(jī)后下次的使用。故，在完成了對(duì)嵌入式軟件的開發(fā)之后，還應(yīng)將其固化，并燒寫到目標(biāo)環(huán)境下的ROM中運(yùn)行。[29]鑒于嵌入式軟件開發(fā)調(diào)試完成后的運(yùn)行環(huán)境往往包含監(jiān)視器等調(diào)試附加程序，而這些額外代碼又不存在于固化的二進(jìn)制執(zhí)行代碼中，因此，為保證固化程序正確及安全的運(yùn)行，在固化之后要對(duì)嵌入式軟件進(jìn)行固化測(cè)試。嵌入式軟件開發(fā)模式通常，嵌入式系統(tǒng)不提供軟件的開發(fā)環(huán)境(即所謂的宿主機(jī)環(huán)境)，而只提供軟件執(zhí)行環(huán)境(即所謂的運(yùn)行環(huán)境)，這便是嵌入式系統(tǒng)的嵌入性特點(diǎn)。[29]此外，嵌入式系統(tǒng)一般都資源受限，也即嵌入式系統(tǒng)的CPU、通信資源、存儲(chǔ)器都恰到好處，這明顯區(qū)別于會(huì)給用戶預(yù)留許多資源進(jìn)行選擇的通用PC。這也決定了必須要有一套能夠提供專門的設(shè)計(jì)、編譯、調(diào)試、測(cè)試工具的專門的開發(fā)環(huán)境來對(duì)嵌入式軟件進(jìn)行開發(fā)。嵌入式系統(tǒng)開發(fā)有其自身的特點(diǎn)。一般先對(duì)硬件部分進(jìn)行開發(fā)，包括形成裸機(jī)平臺(tái)，移植實(shí)時(shí)操作系統(tǒng)，對(duì)底層的硬件驅(qū)動(dòng)程序進(jìn)行開發(fā)等。只有在硬件平臺(tái)測(cè)試通過以后才開始應(yīng)用軟件的開發(fā)。而應(yīng)用軟件的開發(fā)調(diào)試既是對(duì)硬件平臺(tái)的一個(gè)測(cè)試，又是基于該硬件平臺(tái)進(jìn)行的。[35]如下圖2-1表示的是整個(gè)嵌入式系統(tǒng)開發(fā)流程。因此，嵌入式系統(tǒng)的開發(fā)過程也可以理解為是一個(gè)軟硬件相互協(xié)調(diào)，相互反饋及相互測(cè)試的過程。一般來說，在嵌入式系統(tǒng)軟件中，底層驅(qū)動(dòng)程序、操作系統(tǒng)和應(yīng)用程序的界線是不清晰的，根據(jù)需要甚至混編在一起。這主要是由于嵌入式系統(tǒng)中軟件對(duì)硬件的依賴性造成的。[40]圖STYLEREF1\s2SEQ圖\*ARABIC\s11嵌入式系統(tǒng)開發(fā)流程嵌入式軟件的開發(fā)環(huán)境和運(yùn)行環(huán)境往往互相分離，即采用交叉開發(fā)的方式:開發(fā)工具及編輯和編譯軟件運(yùn)行在宿主機(jī)上，我們需要將編譯好的軟件下載到目標(biāo)機(jī)上，利用通訊連接起主機(jī)和目標(biāo)機(jī)，并在二者間進(jìn)行調(diào)試命令和數(shù)據(jù)的傳輸。如圖2-2。[36]而嵌入式軟件開發(fā)的復(fù)雜性也基于主機(jī)和目標(biāo)機(jī)操作系統(tǒng)的不同和處理器體系結(jié)構(gòu)的不同而被大大提高。圖STYLEREF1\s2SEQ圖\*ARABIC\s12嵌入式的交叉開發(fā)方式PC機(jī)和工作站等通用計(jì)算機(jī)都可以作為宿主機(jī)，它通過網(wǎng)絡(luò)連接或串口與目標(biāo)機(jī)進(jìn)行通訊。宿主機(jī)擁有比較豐富的軟硬件資源，如功能強(qiáng)大的操作系統(tǒng)(如Linux和windows)，[38]再如各式各樣的開發(fā)工具(如Microsoft的Embeddedvisualc++、WindRiver的Tornado等)，軟件開發(fā)的效率和進(jìn)度也基于這些輔助開發(fā)工具而大大提高。[42]在嵌入式軟件開發(fā)期間，為了與宿主機(jī)相區(qū)別，常常使用目標(biāo)機(jī)(Target)這個(gè)術(shù)語(yǔ)。嵌入式系統(tǒng)軟件在目標(biāo)機(jī)這一硬件平臺(tái)中運(yùn)行。在目標(biāo)機(jī)上運(yùn)行的軟件基于目標(biāo)機(jī)有限的硬件資源既可剪裁，也可配置。因此，目標(biāo)機(jī)通常都集成度高、體積較小，甚至軟硬件資源配置都恰到好處。另外，如要使得目標(biāo)機(jī)應(yīng)用軟件順利運(yùn)行還需綁定操作系統(tǒng)。為達(dá)到縮短開發(fā)周期減少開發(fā)的費(fèi)用的目的，可不斷增強(qiáng)宿主機(jī)的配置，甚至在宿主機(jī)上仿真目標(biāo)機(jī)。[37]嵌入式交叉開發(fā)需要用到交叉編譯器、交叉調(diào)試器和系統(tǒng)仿真器等交叉開發(fā)工具。其中交叉編譯器的功能是在宿主機(jī)上生成代碼且該代碼能夠在目標(biāo)機(jī)上運(yùn)行，而交叉調(diào)試器和系統(tǒng)仿真器的功能則是完成宿主機(jī)與目標(biāo)機(jī)之間程序代碼調(diào)試。在宿主機(jī)上運(yùn)行的交叉調(diào)試器能夠通過網(wǎng)絡(luò)連接或串口與目標(biāo)機(jī)通訊，通過使用調(diào)試器調(diào)試人員可以與目標(biāo)機(jī)端的Monitor協(xié)作，從而將要調(diào)試的程序下載到目標(biāo)機(jī)上進(jìn)行運(yùn)行和調(diào)試。[41]與通用軟件開發(fā)相比，嵌入式軟件開發(fā)的不同之處還體現(xiàn)在以下方面:(l)包括特定的外圍設(shè)備和微處理器等在內(nèi)的專門的硬件平臺(tái)是嵌入式軟件開發(fā)的前提之一。此外，軟硬件的開發(fā)在嵌入式系統(tǒng)中通常是同步進(jìn)行的，也就是說，開發(fā)者在開發(fā)初期要面臨硬件平臺(tái)不確定的狀況。(2)底層嵌入式操作系統(tǒng)(RTOS)也是嵌入式軟件開發(fā)的另一前提，其專門的RTOS可以作為任務(wù)調(diào)度平臺(tái)來調(diào)度復(fù)雜的實(shí)時(shí)多任務(wù)程序，同時(shí)在開發(fā)過程中，附帶于RTOS的集成開發(fā)環(huán)境(IDE)以及應(yīng)用程序接口(API函數(shù))也需要被用到。(3)在遵循傳統(tǒng)軟件開發(fā)模式的基礎(chǔ)上，嵌入式軟件開發(fā)還需要某些專門的開發(fā)工具，如在嵌入式軟件中起創(chuàng)建和調(diào)試作用的編譯器、匯編器和調(diào)試器。(4)考慮到軟件的運(yùn)行性能，可供嵌入式軟件選擇的編程語(yǔ)言范圍很是有限?，F(xiàn)有的如Java、Ada、C++等高級(jí)的面向?qū)ο蟮木幊陶Z(yǔ)言雖然在某種程度上可通過增強(qiáng)系統(tǒng)設(shè)計(jì)而有利于構(gòu)建與維護(hù)復(fù)雜的系統(tǒng)，但動(dòng)態(tài)對(duì)象概念的引入也額外地影響著系統(tǒng)運(yùn)行的效率。軟件開發(fā)中，可根據(jù)具體的應(yīng)用需求或具體的問題來選擇編程語(yǔ)言。設(shè)計(jì)諸如傳感器通信等中小型但執(zhí)行關(guān)鍵任務(wù)的高效的實(shí)時(shí)應(yīng)用，采用C語(yǔ)言最好;Java語(yǔ)言適于用來設(shè)計(jì)對(duì)實(shí)時(shí)性要求不高但要與用戶有良好接口與Internet連接的設(shè)備;對(duì)于如飛機(jī)、軍艦等大規(guī)模、分布式的嵌入式系統(tǒng)應(yīng)用，C++，Ada語(yǔ)言可作為選擇的對(duì)象。(5)開發(fā)資源，如成本、功耗、體積等，嚴(yán)格制約著嵌入式軟件的開發(fā)。開發(fā)者不得不去面對(duì)目標(biāo)平臺(tái)存儲(chǔ)能力和處理速度有限的事實(shí)，并盡可能滿足來自應(yīng)用的功能和非功能的要求。嵌入式軟件三大特點(diǎn)對(duì)軟件測(cè)試的影響實(shí)時(shí)性的影響嵌入式軟件測(cè)試需要滿足實(shí)時(shí)性要求。一般而言，嵌入式軟件的運(yùn)行都是連續(xù)的，其會(huì)實(shí)時(shí)地響應(yīng)外部觸發(fā)的事件，從而滿足時(shí)限要求。實(shí)時(shí)軟件不同于其他軟件，其正確性不僅依賴于行為和功能，還由其時(shí)間特性決定。因此，如何驗(yàn)證軟件的時(shí)間特性就成為了嵌入式軟件測(cè)試的其中一個(gè)核心問題。靜態(tài)時(shí)間分析以及動(dòng)態(tài)實(shí)時(shí)檢測(cè)是兩種測(cè)試軟件時(shí)間的方法。靜態(tài)時(shí)間分析是在不執(zhí)行被測(cè)程序的前提下，只是通過對(duì)程序、子程序結(jié)構(gòu)的分析來預(yù)估其各自執(zhí)行時(shí)間的方法。因?yàn)闆]有執(zhí)行被測(cè)程序，故靜態(tài)時(shí)間分析也就無從知道實(shí)際運(yùn)行時(shí)程序的循環(huán)次數(shù)和分支走向等不確定因素，其也得不到程序、子程序?qū)嶋H執(zhí)行的時(shí)間。然而，靜態(tài)分析卻有一個(gè)很重要的功能:即確定在最壞情況下程序的最大執(zhí)行時(shí)間是否滿足時(shí)間約束。計(jì)算程序的最大執(zhí)行時(shí)間是很有意義的，因?yàn)樵谌魏吻闆r下實(shí)時(shí)系統(tǒng)都需要在指定期限前完成任務(wù)。通過執(zhí)行程序來測(cè)試程序的時(shí)間特性也即所謂的動(dòng)態(tài)實(shí)時(shí)檢測(cè)。最常用的方法有指令仿真器、在線仿真器ICE和插樁工具。嵌入式軟件的測(cè)試用例因?qū)崟r(shí)性特點(diǎn)而變得編寫困難，測(cè)試用例除了對(duì)軟件的行為和功能特性進(jìn)行測(cè)試外，還要對(duì)其時(shí)間特性進(jìn)行測(cè)試，這是由于即便是同樣的輸入出現(xiàn)在不同時(shí)間其也可能導(dǎo)致不同的輸出結(jié)果，這無疑向傳統(tǒng)的測(cè)試用例生成方法提出了新問題。嵌入性的影響由于嵌入式軟件開發(fā)調(diào)試?yán)щy，有必要使用交叉開發(fā)環(huán)境。通常而言，開發(fā)平臺(tái)與運(yùn)行平臺(tái)是不一致的，在完成嵌入式軟件的開發(fā)后需要將其導(dǎo)入運(yùn)行平臺(tái)，在交叉開發(fā)環(huán)境下調(diào)試，這必然提高了嵌入式軟件開發(fā)和調(diào)試的難度。嵌入式軟件測(cè)試也因不一致的開發(fā)環(huán)境與運(yùn)行環(huán)境而產(chǎn)生了很多麻煩。(1)測(cè)試工具在宿主機(jī)上運(yùn)行，在目標(biāo)機(jī)上產(chǎn)生的測(cè)試所需要的信息需要借助某種物理/邏輯連接傳輸給宿主機(jī)并由測(cè)試工具接受。故，宿主機(jī)和目標(biāo)機(jī)間物理/邏輯連接的建立就成了解決嵌入式軟件測(cè)試數(shù)據(jù)信息傳輸問題的關(guān)鍵。(2)再充分的宿主機(jī)環(huán)境測(cè)試，也代表不了該軟件在目標(biāo)機(jī)環(huán)境下的運(yùn)行沒有問題。嵌入式軟件時(shí)刻面臨著目標(biāo)環(huán)境的測(cè)試。這種狀況既增加了測(cè)試的代價(jià)，也給嵌入式軟件測(cè)試策略帶來了問題，也即在宿主環(huán)境和目標(biāo)環(huán)境下進(jìn)行的測(cè)試應(yīng)如何分配。反應(yīng)性的影響能夠處理異步并發(fā)事件。由于嵌入式系統(tǒng)多為事件所驅(qū)動(dòng)，故其需要提供多任務(wù)處理機(jī)制來處理各種隨機(jī)的、并發(fā)的事件。能夠快速啟動(dòng)、自動(dòng)復(fù)位。一般而言，系統(tǒng)多能夠快速啟動(dòng)，遇故障能夠容錯(cuò)并自動(dòng)修復(fù)，這些均緣于嵌入式系統(tǒng)的實(shí)時(shí)性要求較高。反應(yīng)性系統(tǒng)(ReactiveSystem)在任何時(shí)刻都要對(duì)可能出現(xiàn)的事件做出適當(dāng)反應(yīng)。這類系統(tǒng)中常常存在大量復(fù)雜的控制行為，但占主要地位的總是“激勵(lì)一—響應(yīng)”。由于反應(yīng)式程序總是包含數(shù)個(gè)并發(fā)進(jìn)程，也即進(jìn)程往往并發(fā)執(zhí)行，故并發(fā)性(Concurrency)可以稱作是反應(yīng)式系統(tǒng)最基本最重要的特征。不能簡(jiǎn)單地將反應(yīng)式定義為輸入/輸出數(shù)據(jù)的函數(shù)，而需要用輸入/輸出序列的二元組來表示。經(jīng)?？梢钥吹剑幢闶峭瑯拥妮斎氤霈F(xiàn)在不同時(shí)間其也可能導(dǎo)致不同的輸出結(jié)果，這無疑給測(cè)試工作帶來了新的麻煩，也向傳統(tǒng)的測(cè)試用例生成方法提出了新問題。嵌入式系統(tǒng)軟件測(cè)試概述軟件測(cè)試軟件測(cè)試是設(shè)計(jì)測(cè)試用例，并利用測(cè)試用例運(yùn)行程序，發(fā)現(xiàn)錯(cuò)誤的過程。而測(cè)試用例的設(shè)計(jì)則需要借助軟件開發(fā)階段的規(guī)格說明書以及程序的內(nèi)部結(jié)構(gòu)。軟件測(cè)試是軟件工程研究領(lǐng)域的重要分支，是保證軟件質(zhì)量的關(guān)鍵步驟。發(fā)生于上世紀(jì)70年代末的“軟件危機(jī)”，對(duì)軟件理論的研究起到了極大的促進(jìn)作用，同時(shí)“軟件工程”作為一項(xiàng)新興學(xué)科也在此時(shí)開創(chuàng)。經(jīng)過30多年的發(fā)展，盡管沒有找到真正的“銀彈(silverbullet)”來徹底解決“軟件危機(jī)”問題，但是軟件工程的研究，在軟件開發(fā)技術(shù)和軟件項(xiàng)目管理兩大領(lǐng)域，依然碩果累累。從結(jié)構(gòu)化程序設(shè)計(jì)思想到面向?qū)ο罄碚?；從?jiǎn)單無序的手工作坊式編程到較為規(guī)范、可控制的各種開發(fā)模型；從富于個(gè)人英雄主義氣質(zhì)的牛仔式的程序員到分工明確、迅速高效的現(xiàn)代化開發(fā)團(tuán)隊(duì)；從只要求程序能夠運(yùn)行到追求程序的可靠性、兼容性、設(shè)計(jì)重用性等高質(zhì)量屬性；這一系列思想的進(jìn)步和方法的改進(jìn)，都表明了軟件工程領(lǐng)域的研究正在不斷的取得進(jìn)步。與此同時(shí)，對(duì)高質(zhì)量軟件的日益需求，促進(jìn)了軟件工程領(lǐng)域的重要內(nèi)容之一：軟件測(cè)試?yán)碚摰难芯亢蛯?shí)踐。三十多年的發(fā)展，為我們提供了豐富的經(jīng)驗(yàn)，使得軟件測(cè)試成為一門十分成熟的學(xué)科。軟件測(cè)試目的軟件測(cè)試的過程是尋找和發(fā)現(xiàn)軟件中潛在的錯(cuò)誤的過程，因此，軟件測(cè)試的首要目的是及早的發(fā)現(xiàn)軟件中所包含的各種錯(cuò)誤，以此來使軟件獲得相應(yīng)級(jí)別的質(zhì)量保證。其次，通過軟件測(cè)試，還可以驗(yàn)證軟件實(shí)現(xiàn)的功能是否符合設(shè)計(jì)說明書的要求；驗(yàn)證軟件的性能是否達(dá)到設(shè)計(jì)要求；通過收集測(cè)試過程中的各種數(shù)據(jù)，為軟件質(zhì)量的評(píng)價(jià)提供一定的依據(jù)。另外，在指定具體的測(cè)試目標(biāo)時(shí)，人們通常會(huì)將投入的時(shí)間和人力等成本考慮進(jìn)去，所以，成功的軟件測(cè)試往往是通過最少的人力和時(shí)間成本，盡可能多的找出軟件中潛在的各種錯(cuò)誤和設(shè)計(jì)缺陷。軟件測(cè)試對(duì)象一種常見的觀點(diǎn)認(rèn)為軟件測(cè)試單指程序測(cè)試，這種觀點(diǎn)顯然是不全面的。軟件測(cè)試貫穿于整個(gè)軟件定義和軟件開發(fā)過程。因此，由需求分析得到的需求說明書、由概要設(shè)計(jì)得到的概要設(shè)計(jì)說明書、由詳細(xì)設(shè)計(jì)得到的詳細(xì)設(shè)計(jì)說明書以及由程序編碼得到的源程序等，均應(yīng)該被視為軟件測(cè)試的對(duì)象。在軟件的開發(fā)過程中，越早發(fā)現(xiàn)的錯(cuò)誤，改正錯(cuò)誤的代價(jià)就越低，對(duì)于軟件開發(fā)過程的影響就越小，見圖3-1。因此，對(duì)于軟件生存周期的各個(gè)階段所要傳遞的信息，都應(yīng)該盡可能的保證理解和表達(dá)的正確性。對(duì)每個(gè)階段所得到的階段性成果，都應(yīng)該獨(dú)立的進(jìn)行確認(rèn)和驗(yàn)證，以求盡早地發(fā)現(xiàn)軟件缺陷。圖STYLEREF1\s3SEQ圖\*ARABIC\s11隨時(shí)間推移，修復(fù)軟件錯(cuò)誤費(fèi)用驚人增長(zhǎng)軟件測(cè)試數(shù)據(jù)流圖軟件測(cè)試數(shù)據(jù)流圖描述了軟件測(cè)試的基本流程，如圖3-2所示。測(cè)試過程需要兩類輸入，分別是軟件配置和測(cè)試配置。軟件配置包括：軟件需求規(guī)格說明書，軟件設(shè)計(jì)規(guī)格說明書，源代碼等；測(cè)試配置包括：測(cè)試計(jì)劃，測(cè)試用例，測(cè)試驅(qū)動(dòng)程序和測(cè)試工具等。圖STYLEREF1\s3SEQ圖\*ARABIC\s12軟件測(cè)試數(shù)據(jù)流圖軟件測(cè)試方法軟件測(cè)試的方法多種多樣，從不同的角度來看，可以有不同的分類方法。從其貫穿軟件生命周期的過程來看，可以分為模塊測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試和確認(rèn)測(cè)試等測(cè)試階段；另外，測(cè)試還可以分為靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試；在動(dòng)態(tài)測(cè)試中，又分為基于程序結(jié)構(gòu)的白盒測(cè)試和基于功能的黑盒測(cè)試?？偟膩碇v，目前軟件測(cè)試存在兩大類測(cè)試方法，第一類測(cè)試方法是將軟件在設(shè)計(jì)的環(huán)境下運(yùn)行以得出結(jié)果，并將該結(jié)果與預(yù)期結(jié)果作對(duì)照，如果二者相符則測(cè)試通過，如果二者存在出入不相符則視為錯(cuò)誤。最終在設(shè)計(jì)規(guī)定的環(huán)境中將軟件的所有功能加以運(yùn)行，以逐一發(fā)現(xiàn)錯(cuò)誤。該方法基于用戶需求和設(shè)計(jì)，將測(cè)試工作的范疇加以界定，可有針對(duì)性地部署測(cè)試的側(cè)重點(diǎn)。第二類方法與需求和設(shè)計(jì)沒有必然的聯(lián)系，更強(qiáng)調(diào)測(cè)試人員利用逆向思維發(fā)揮主觀能動(dòng)性，不斷反思開發(fā)人員的不良習(xí)慣、理解的誤區(qū)、無效數(shù)據(jù)的輸入、程序代碼的邊界以及系統(tǒng)本身的各種弱點(diǎn)，站在破壞和摧毀系統(tǒng)的角度，不斷尋找系統(tǒng)中各種各樣的問題。實(shí)踐中，結(jié)合使用以上兩種測(cè)試方法往往能夠取得較好的效果。嵌入式軟件的測(cè)試關(guān)于測(cè)試策略嵌入式平臺(tái)，資源相對(duì)稀少，但其卻是嵌入式系統(tǒng)軟件最終的運(yùn)行環(huán)境,而一般軟件可能運(yùn)行在超級(jí)計(jì)算機(jī)上或高性能的PC機(jī)上。適當(dāng)條件下,嵌入式系統(tǒng)軟件的測(cè)試同樣適用一般軟件的單元測(cè)試、系統(tǒng)測(cè)試、集成測(cè)試和確認(rèn)測(cè)試策略。我們也可以將所謂的適當(dāng)條件看作是關(guān)于嵌入式系統(tǒng)軟件測(cè)試的獨(dú)特策略。嵌入式系統(tǒng)中的開發(fā)環(huán)境和最終運(yùn)行環(huán)境又分別被稱為主機(jī)(Host)平臺(tái)和目標(biāo)(Target)平臺(tái)。兩種典型的嵌入式軟件開發(fā)方式分別為:一種是在實(shí)際目標(biāo)(Target)平臺(tái)上編輯、編譯和調(diào)試代碼進(jìn)而開發(fā)源代碼;另一種則是將編輯和編譯源代碼的工作在主機(jī)平臺(tái)上完成,而后移動(dòng)可執(zhí)行代碼到目標(biāo)機(jī)上進(jìn)行調(diào)試。第二種方法也叫做交叉開發(fā),如圖3-3所示。圖STYLEREF1\s3SEQ圖\*ARABIC\s13交叉開發(fā)選擇交叉開發(fā)方法使得目標(biāo)機(jī)和主機(jī)在運(yùn)行速度上的差別得以緩解。交叉開發(fā)環(huán)境,同時(shí)也是交叉測(cè)試環(huán)境，因?yàn)樵诮徊鏈y(cè)試過程中同樣體現(xiàn)了交叉開發(fā)的有利因素。這即是前面提到的適當(dāng)條件,即關(guān)于嵌入式軟件測(cè)試的獨(dú)特的交叉測(cè)試策略。在主機(jī)環(huán)境下，無論是嵌入式軟件的單元測(cè)試還是嵌入式軟件的集成測(cè)試均可以完成;然而關(guān)于最終的硬軟件集成測(cè)試則必須在目標(biāo)環(huán)境下,利用目標(biāo)機(jī)與主機(jī)間的信息通道,進(jìn)而實(shí)現(xiàn)測(cè)試控制和信息反饋通信。測(cè)試方法關(guān)于測(cè)試方法，覆蓋和質(zhì)量是主要的評(píng)測(cè)方法。測(cè)試覆蓋可用測(cè)試需求和測(cè)試用例的覆蓋來表示，亦可用已執(zhí)行代碼的覆蓋來表示，主要是評(píng)測(cè)測(cè)試的完全程度。將針對(duì)測(cè)試對(duì)象的穩(wěn)定性、可靠性以及性能的評(píng)測(cè)稱作是質(zhì)量。不管是對(duì)測(cè)試結(jié)果的評(píng)估，還是在測(cè)試過程中針對(duì)確定的變更請(qǐng)求(缺陷)所進(jìn)行的分析，均可作為質(zhì)量評(píng)測(cè)的基礎(chǔ)。(1)覆蓋測(cè)評(píng)測(cè)試的完全程度由覆蓋指標(biāo)表示。黑盒的測(cè)試覆蓋和白盒的測(cè)試覆蓋是最常用的覆蓋測(cè)評(píng)方法，前者是基于需求的測(cè)試覆蓋，而后者則是基于代碼的測(cè)試覆蓋。簡(jiǎn)單地說，測(cè)試覆蓋是對(duì)基于需求或基于代碼的完全程度的評(píng)測(cè)，前者是核實(shí)測(cè)試用例，后者是評(píng)測(cè)代碼執(zhí)行。系統(tǒng)的測(cè)試活動(dòng)必須以測(cè)試覆蓋策略為基礎(chǔ)，測(cè)試的一般目的由覆蓋策略陳述，用例的設(shè)計(jì)也由覆蓋策略指導(dǎo)。此外，所有性能也可由覆蓋策略的陳述簡(jiǎn)單說明。倘若已經(jīng)將需求完全分類，那么覆蓋策略基于需求足以生成測(cè)試為完全程度的可計(jì)量評(píng)測(cè)。舉例說明，如若所有性能的測(cè)試需求都已經(jīng)被確定，那么評(píng)測(cè)就可引用測(cè)試結(jié)果得到。如若應(yīng)用基于代碼的測(cè)試覆蓋，那么測(cè)試策略只能根據(jù)測(cè)試所得的已執(zhí)行的源代碼的多少來確定。對(duì)于安全之上的系統(tǒng)來說，該測(cè)試覆蓋策略類型具有非常重要的意義。在測(cè)試生命周期中，基于需求的測(cè)試覆蓋要評(píng)測(cè)數(shù)次。測(cè)試覆蓋可用以下公式計(jì)算：測(cè)試覆蓋T是用已計(jì)劃或已實(shí)施或成功的測(cè)試過程或測(cè)試用例表示的測(cè)試(Test)數(shù)。表示測(cè)試需求(RequirementforTest)總數(shù)。制定測(cè)試計(jì)劃時(shí)，通過計(jì)算測(cè)試覆蓋以確定已計(jì)劃的測(cè)試覆蓋，計(jì)算方法為：測(cè)試覆蓋(已計(jì)劃的)是已計(jì)劃測(cè)試數(shù)，其用測(cè)試過程或測(cè)試用例表示。實(shí)施測(cè)試活動(dòng)時(shí)，測(cè)試過程按照測(cè)試腳本正在實(shí)施中，可采用以下公式計(jì)算測(cè)試覆蓋：測(cè)試覆蓋(已執(zhí)行的)是已執(zhí)行的測(cè)試數(shù)，其用測(cè)試過程或測(cè)試用例表示。執(zhí)行測(cè)試活動(dòng)時(shí)，兩個(gè)測(cè)試覆蓋評(píng)測(cè)同時(shí)使用，其一用來確定由執(zhí)行測(cè)試得到的測(cè)試覆蓋，另一個(gè)用來確定執(zhí)行時(shí)未出現(xiàn)失敗即成功的測(cè)試覆蓋(如沒有缺陷出現(xiàn)或意外結(jié)果產(chǎn)生的測(cè)試)。利用以下公式計(jì)算這些覆蓋評(píng)測(cè)：測(cè)試覆蓋(已執(zhí)行的)是已執(zhí)行的測(cè)試數(shù)，其用測(cè)試過程或測(cè)試用例表示。成功的測(cè)試覆蓋(已執(zhí)行的)也是已執(zhí)行的測(cè)試數(shù)，不同的是，其是由沒有缺陷的已完成的測(cè)試過程或測(cè)試用例來表示。倘若用百分?jǐn)?shù)表示以上比率，那么以下有關(guān)基于需求的測(cè)試覆蓋的陳述同樣成立：已經(jīng)覆蓋的測(cè)試用例(同上述公式中的)為x﹪，成功率為y﹪。關(guān)于測(cè)試覆蓋的該種陳述是有意義的，其與已定義的成功標(biāo)準(zhǔn)作比較，如果不相符，則可利用此陳述為基礎(chǔ)來預(yù)測(cè)剩余測(cè)試工作?；诖a的測(cè)試覆蓋，在測(cè)試過程中，其可以測(cè)評(píng)已經(jīng)執(zhí)行的代碼的多少，而要執(zhí)行的剩余代碼則與之相對(duì)?？刂屏靼ㄕZ(yǔ)句、分支或路徑，而代碼覆蓋則即可建立在控制流上，亦可建立在數(shù)據(jù)流上。無論是測(cè)試代碼行、測(cè)試分支條件、還是測(cè)試代碼中的路徑，甚至軟件控制流中的其它元素都被當(dāng)作了控制流覆蓋的目的。數(shù)據(jù)流覆蓋的目的是利用軟件操作對(duì)數(shù)據(jù)狀態(tài)的有效與否進(jìn)行測(cè)試。例如，測(cè)試在使用之前數(shù)據(jù)元素是否已作定義。利用以下公式對(duì)基于代碼的測(cè)試覆蓋進(jìn)行計(jì)算：測(cè)試覆蓋是已執(zhí)行項(xiàng)目數(shù)，其既可用代碼語(yǔ)句、分支或路徑來表示，還可用數(shù)據(jù)元素名或數(shù)據(jù)狀態(tài)判定點(diǎn)數(shù)來表示。表示代碼中的項(xiàng)目總數(shù)。倘若用百分?jǐn)?shù)表示以上比率，那么以下有關(guān)基于代碼的測(cè)試覆蓋的陳述同樣成立：已經(jīng)覆蓋的測(cè)試用例(同上述公式中的I)為x﹪，成功率為y﹪。關(guān)于測(cè)試覆蓋的該種陳述是有意義的，其與已定義的成功標(biāo)準(zhǔn)作比較，如果不相符，則可利用此陳述為基礎(chǔ)來預(yù)測(cè)剩余測(cè)試工作。(2)質(zhì)量評(píng)測(cè)適用于硬件可靠性設(shè)計(jì)中的“簡(jiǎn)單就是可靠”原則同樣也適合軟件，隨著功能的增多或增強(qiáng)軟件需要不斷升級(jí)與補(bǔ)丁。軟件質(zhì)量是由因應(yīng)用方面和用戶觀點(diǎn)不同而各異的多種因素組成的混合體或綜合體。按照能否直接度量的標(biāo)準(zhǔn)可將影響軟件質(zhì)量的因素分為兩大類：其一是可直接度量的因素，其二是只能間接度量的因素，前者如單位時(shí)間內(nèi)所發(fā)現(xiàn)的每千行源代碼的錯(cuò)誤個(gè)數(shù)，后者如可維護(hù)性、可復(fù)用性等。以上兩大類影響軟件質(zhì)量的因素都能夠被度量，且都可以具體數(shù)據(jù)描述軟件質(zhì)量的不同方面。關(guān)于軟件的可維護(hù)性，主要有三種度量參數(shù)，分別為：Line復(fù)雜度、Halstead復(fù)雜度和McCabe復(fù)雜度。Line復(fù)雜度的計(jì)算基準(zhǔn)是代碼的行數(shù)。Halstead復(fù)雜度將程序中使用到的運(yùn)算元與運(yùn)算符數(shù)量作為直接測(cè)量指標(biāo),然后計(jì)算出程序容量和工作量等。McCabe復(fù)雜度又被稱作是圈復(fù)雜度，它定量了測(cè)試?yán)щy度以及最終可靠性指標(biāo)的度量。經(jīng)試驗(yàn)證明，McCabe度量、存在于源代碼中的錯(cuò)誤數(shù)、發(fā)現(xiàn)并糾正這些錯(cuò)誤所需的時(shí)間，該三者之間存在特定的關(guān)系。McCabe&Associates公司成立于1976年，該公司針對(duì)軟件進(jìn)行結(jié)構(gòu)測(cè)試而開發(fā)出了McCabeCylomaticComplexityMetric（圈復(fù)雜度）技術(shù)。將軟件復(fù)雜度測(cè)量的數(shù)目作為基礎(chǔ)的Meric，可幫助工程師較為輕松地識(shí)別出難于測(cè)試和維護(hù)的模塊。人們將圈復(fù)雜度作為評(píng)估軟件質(zhì)量的重要標(biāo)準(zhǔn)，利用其來衡量軟件的復(fù)雜度和質(zhì)量，奔著在成本、進(jìn)度以及性能之間尋求平衡的目的來安排工程進(jìn)度。McCabe復(fù)雜度包括基本復(fù)雜度、圈復(fù)雜度、設(shè)計(jì)復(fù)雜度、模塊設(shè)計(jì)復(fù)雜度和集成復(fù)雜度。測(cè)試工具軟件測(cè)試工具純軟件方式的測(cè)試大多都是利用軟件仿真技術(shù)，在宿主機(jī)上模擬目標(biāo)機(jī)，從而在仿真的宿主機(jī)上進(jìn)行大部分的測(cè)試?，F(xiàn)在大多數(shù)的嵌入式測(cè)試工具，包括Logiscope、CoverageScope等都采用了這種方式。作為純軟件測(cè)試工具Host/Target采用的是軟件插樁技術(shù)。將一些函數(shù)或一段語(yǔ)句插入到被測(cè)代碼中，再利用插入的函數(shù)或語(yǔ)句來生成數(shù)據(jù)，并將這些數(shù)據(jù)上送到目標(biāo)系統(tǒng)的共享內(nèi)存中。與此同時(shí)，在目標(biāo)系統(tǒng)中利用預(yù)處理任務(wù)對(duì)這些數(shù)據(jù)進(jìn)行預(yù)處理，之后通過目標(biāo)機(jī)的調(diào)試口將處理后的數(shù)據(jù)上送到主機(jī)平臺(tái)，所有的這些都在目標(biāo)處理器的參與下完成。測(cè)試者通過以上過程可以得知程序當(dāng)前的運(yùn)行狀態(tài)。插樁函數(shù)和預(yù)處理任務(wù)作為兩個(gè)特點(diǎn)必然存在于純軟件的測(cè)試方式中。而插樁函數(shù)和預(yù)處理任務(wù)的存在也增大了系統(tǒng)的代碼，更有甚者，某些代碼會(huì)極大地影響系統(tǒng)的運(yùn)行效率。預(yù)處理任務(wù)不但占用目標(biāo)系統(tǒng)CPU內(nèi)存，而且需要時(shí)間在通信通道中處理和傳送數(shù)據(jù)。鑒于這些弊端的存在，基于Host/Target的純軟件測(cè)試工具在進(jìn)行測(cè)試時(shí)，其不能對(duì)目標(biāo)系統(tǒng)進(jìn)行精確的性能分析，甚至，在分析覆蓋率時(shí)，系統(tǒng)的運(yùn)行還要受到大量插樁的影響。所以，Host/Target作為一種純軟件測(cè)試工具，其缺乏性能分析功能，既不能針對(duì)目標(biāo)系統(tǒng)中相關(guān)的時(shí)間指標(biāo)做出精確的分析，也不能動(dòng)態(tài)觀察內(nèi)存的動(dòng)態(tài)分配。硬件測(cè)試工具純硬件的手段，如萬用表、示波器、邏輯分析儀等，通常被用于設(shè)計(jì)和測(cè)試系統(tǒng)的硬件，但也可用來分析測(cè)試軟件。邏輯分析儀是最常用的一種純硬件測(cè)試工具，其通過監(jiān)控系統(tǒng)運(yùn)行時(shí)總線上的指令周期，利用一定頻率捕獲信號(hào)，分析數(shù)據(jù)，通過了解用戶系統(tǒng)的工作狀態(tài)，進(jìn)而對(duì)當(dāng)前程序運(yùn)行的狀況做出判斷。邏輯分析儀使用采樣的方式，難免會(huì)遺漏重要信號(hào)，而且，其分析范圍也非常有限。舉例說明，邏輯分析儀只能采用抽樣的方式，對(duì)有限的函數(shù)進(jìn)行性能分析，故其要得出滿意的結(jié)果十分困難。針對(duì)程序分析覆蓋率時(shí)，硬件工具需要從系統(tǒng)總線上捕獲數(shù)據(jù)，例如當(dāng)打開Cache時(shí)系統(tǒng)會(huì)基于指令預(yù)取技術(shù)，將外存中的一段代碼讀入到一級(jí)Cache中，此時(shí)，邏輯分析儀利用頻率捕獲到代碼被讀取的信號(hào)，然后報(bào)告這些代碼已被執(zhí)行，然而實(shí)際上被讀入到一級(jí)Cache中的代碼可能根本沒有被命中。只有把Cache關(guān)掉才可能避免這種誤差，而把Cache關(guān)掉之后系統(tǒng)的運(yùn)行環(huán)境就不真實(shí)了，更有甚者系統(tǒng)都可能出現(xiàn)無法正常運(yùn)行的現(xiàn)象。由此可知，純硬件工具根本不具備分析和檢查內(nèi)存分配的能力。軟硬結(jié)合測(cè)試工具所謂的軟硬結(jié)合測(cè)試工具，也即能夠利用純軟件和純硬件測(cè)試工具各自的優(yōu)點(diǎn)，并摒棄它們各自的缺點(diǎn)。例如高性能測(cè)試工具CodeTest，其采用插樁技術(shù)由AppliedMicrosystemsCorporation(AMc)公司專為嵌入式開發(fā)者而設(shè)計(jì)，可用于本機(jī)測(cè)試(native)甚至在線測(cè)試(in-circuit)。區(qū)別于純軟件測(cè)試工具，CodeTest以插入一條賦值語(yǔ)句來替代插樁函數(shù)，從而大大縮短了執(zhí)行時(shí)間，同時(shí)也避免了被中斷，相互間的影響都非常小。同時(shí)，CodeTest又吸取并改進(jìn)了純硬件測(cè)試工具里從總線捕獲數(shù)據(jù)的技術(shù)，CodeTest摒棄采樣的方式，通過監(jiān)視系統(tǒng)總線，只有在程序運(yùn)行到插入的特殊點(diǎn)時(shí)才會(huì)主動(dòng)捕獲數(shù)據(jù)總線上的數(shù)據(jù)，所以，利用CodeTest所做的數(shù)據(jù)觀察可以很精確。CodeTest主要的功能有:(l)分析性能。(2)分析測(cè)試覆蓋。(3)分析動(dòng)態(tài)存儲(chǔ)器分配。(4)分析執(zhí)行追蹤(TRACE)。所以，雖然現(xiàn)在市面上的一些測(cè)試工具在某些應(yīng)用中達(dá)到了一定或較好的效果，但由于嵌入式的多樣性，使得這些測(cè)試工具在針對(duì)某些特定的應(yīng)用時(shí)又無法達(dá)到要求的效果，故很難形成一種適合所有具體測(cè)試工作的測(cè)試方法。嵌入式系統(tǒng)測(cè)試流程關(guān)于嵌入式系統(tǒng)的完整的測(cè)試流程見圖STYLEREF1\s3SEQ圖\*ARABIC\s14:圖STYLEREF1\s3SEQ圖\*ARABIC\s15模塊化設(shè)計(jì)的嵌入式軟件四級(jí)測(cè)試流程通過觀察測(cè)試流程圖不難看出測(cè)試過程的步驟:首先將被測(cè)軟件系統(tǒng)的源碼根目錄交由測(cè)試系統(tǒng)管理，同時(shí)命名被測(cè)軟件系統(tǒng)，提供相關(guān)的簡(jiǎn)要描述以及自動(dòng)分析被測(cè)軟件的源碼。創(chuàng)建測(cè)試工程，將其與測(cè)試系統(tǒng)管理的某一個(gè)被測(cè)軟件系統(tǒng)進(jìn)行綁定，并命名該測(cè)試工程，提供相關(guān)的簡(jiǎn)要描述。創(chuàng)建測(cè)試集，在測(cè)試工程中，每個(gè)測(cè)試集對(duì)應(yīng)一個(gè)被測(cè)模塊或模塊集合。在創(chuàng)建測(cè)試集時(shí)，使用者需要將被測(cè)的一個(gè)或多個(gè)模塊加以指定，同時(shí)命名該測(cè)試集，提供相關(guān)的簡(jiǎn)要描述。創(chuàng)建測(cè)試用例，在測(cè)試集中，每個(gè)測(cè)試用例針對(duì)與其相對(duì)應(yīng)的某一個(gè)函數(shù)進(jìn)行測(cè)試，在創(chuàng)建測(cè)試用例時(shí)，使用者需要指定這個(gè)函數(shù)，同時(shí)命名該測(cè)試用例，提供相關(guān)的簡(jiǎn)要描述。關(guān)于測(cè)試用例的設(shè)計(jì)與臨時(shí)執(zhí)行，根據(jù)測(cè)試的需要，使用者可利用由測(cè)試系統(tǒng)提供的協(xié)助手段設(shè)計(jì)測(cè)試用例。使用者還可在設(shè)計(jì)過程中臨時(shí)運(yùn)行該測(cè)試用例并利用測(cè)試結(jié)果信息或是進(jìn)一步設(shè)計(jì)測(cè)試用例，或是重新創(chuàng)建設(shè)計(jì)新的測(cè)試用例。用戶在完成一個(gè)測(cè)試用例的設(shè)計(jì)之后，也可以選擇創(chuàng)建新的測(cè)試用例，或是選擇創(chuàng)建新的測(cè)試集。有關(guān)測(cè)試用例的批量執(zhí)行，用戶可針對(duì)一個(gè)測(cè)試工程中的部分或所有測(cè)試用例進(jìn)行批量的連續(xù)的執(zhí)行，同時(shí)將包括覆蓋信息在內(nèi)的所有被運(yùn)行的測(cè)試用例的結(jié)果信息加以收集。查看測(cè)試結(jié)果，包括測(cè)試用例運(yùn)行結(jié)果和代碼覆蓋信息。測(cè)試系統(tǒng)可根據(jù)測(cè)試結(jié)果信息生成測(cè)試報(bào)告。嵌入式系統(tǒng)軟件測(cè)試模型嵌入式的軟件測(cè)試模型本章對(duì)幾種傳統(tǒng)的測(cè)試模型進(jìn)行分析比較，從幾個(gè)方面簡(jiǎn)要介紹了軟件測(cè)試的改進(jìn)思路，需求變更的概念及分類，針對(duì)測(cè)試改進(jìn)方法進(jìn)行了具體說明，最后做出了改進(jìn)總結(jié)。V測(cè)試模型圖STYLEREF1\s4SEQ圖\*ARABIC\s11V字模型示意圖下面是關(guān)于V模型測(cè)試方法的一個(gè)全面的詮釋：PaulRook在上世紀(jì)80年代后期最早地提出了V模型，V模型也曾被英國(guó)包含在國(guó)家計(jì)算中心文獻(xiàn)中發(fā)布，以求改進(jìn)軟件開發(fā)的效率及效果。在歐洲尤其是在英國(guó)，V模型被當(dāng)作是瀑布模型的替代品并被接受。瀑布模型認(rèn)為重要的開發(fā)活動(dòng)完成之后，測(cè)試只是并不主要的收尾工作，這確實(shí)給人們?cè)斐闪瞬涣嫉挠绊?。傳統(tǒng)開發(fā)過程往往只是將測(cè)試過程當(dāng)作是需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)以及編碼后的一個(gè)階段，而V模型是針對(duì)此進(jìn)行的改進(jìn)。[32]觀察圖4-1，V模型描述了對(duì)應(yīng)生命周期不同階段的一些不同的測(cè)試級(jí)別。開發(fā)過程各階段是左邊下降的部分，而右邊上升的部分則是測(cè)試過程中的各個(gè)階段。不同的組織中，命名測(cè)試階段可能有所區(qū)別。V模型中開發(fā)階段一側(cè)，首先從需求分析開始，然后不斷地將需求轉(zhuǎn)換為概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)，最后完成程序代碼的開發(fā)。V模型中測(cè)試執(zhí)行階段一側(cè)分四個(gè)不同階段，其依次為：?jiǎn)卧獪y(cè)試、集成測(cè)試、系統(tǒng)測(cè)試以及確認(rèn)測(cè)試。V模型非常清楚地描述了測(cè)試過程中的不同級(jí)別，以及測(cè)試階段和開發(fā)各階段的對(duì)應(yīng)關(guān)系，這是其價(jià)值所在。然而V模型自身也存在很明顯的問題：V模型在表示上認(rèn)為開發(fā)和測(cè)試是一種線性的前后關(guān)系，只有當(dāng)嚴(yán)格的指令明確表示了上一階段已安全結(jié)束，下一個(gè)階段才可正式開始。這樣顯然使迭代、自發(fā)性、變更調(diào)整無法得以保持。V模型中存在的另一個(gè)問題是，其一定要將系統(tǒng)開發(fā)過程嚴(yán)格地分為有邊界的各個(gè)不同階段，這無疑阻礙了人們?cè)诟麟A段的邊界間進(jìn)行交接以及交換測(cè)試信息。同時(shí)，V模型也欠缺關(guān)于需求和設(shè)計(jì)文檔的定義問題的說明，其也沒有說明各測(cè)試階段的測(cè)試設(shè)計(jì)應(yīng)如何進(jìn)行。我們可以說V模型適用于幾乎所有類型的開發(fā)過程，但針對(duì)開發(fā)和測(cè)試過程的所有方面，V模型并不一定適用。不管是批處理還是GUI、Web還是大型機(jī)、Cobol還是Java，它們都需要單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試以及確認(rèn)測(cè)試。但V模型本身并沒有告訴你應(yīng)怎樣定義單元測(cè)試或集成測(cè)試的內(nèi)容、怎樣進(jìn)行具體的測(cè)試設(shè)計(jì)，也不會(huì)告訴你輸入或輸出怎樣的數(shù)據(jù)，其結(jié)果才是正確的。X測(cè)試模型盡最大努力彌補(bǔ)V模型存在的一些缺陷是X模型的目標(biāo)。X模型也切實(shí)地解決了出現(xiàn)在測(cè)試過程各方面的問題，如交接、信息交換，探索性測(cè)試（Exploratorytesting）作為一個(gè)亮點(diǎn)也代表了X模型的意義。見圖STYLEREF1\s4SEQ圖\*ARABIC\s12：[39]圖STYLEREF1\s4SEQ圖\*ARABIC\s13X模型結(jié)構(gòu)示意圖人們認(rèn)為作為一個(gè)模型，其必須能夠應(yīng)對(duì)并處理開發(fā)所有方面可能出現(xiàn)的問題，如交接，頻繁重復(fù)的集成，需求文檔的缺乏等，因此，V模型不能引導(dǎo)項(xiàng)目的全部過程就成為了其最大的缺陷。觀察X模型的結(jié)構(gòu)示意圖，其左邊針對(duì)相互分離的單獨(dú)程序片段進(jìn)行各自的測(cè)試，然后頻繁交接，最終集成為可執(zhí)行的程序。X模型右上半部分所表示的可執(zhí)行程序還需要測(cè)試。成品一旦通過集成測(cè)試，其即可封版后提交給用戶，亦可用來組成更大規(guī)模和范圍的集成。而變更可發(fā)生在各個(gè)部分，其由多根并行的曲線所表示。此外，如圖STYLEREF1\s4SEQ圖\*ARABIC\s14右下方所示，X模型還定位了不進(jìn)行事先計(jì)劃的探索性測(cè)試。諸如“這樣測(cè)試一下會(huì)得出怎樣的結(jié)果？”，這一方式對(duì)于有經(jīng)驗(yàn)的測(cè)試人員來講，其往往能對(duì)發(fā)現(xiàn)測(cè)試計(jì)劃之外的更多的軟件錯(cuò)誤提供很大幫助。X模型的不足在于其不能將一個(gè)軟件開發(fā)周期加以完整地描述，但其仍然有自身的意義，即表示測(cè)試和開發(fā)迭代，為探索性測(cè)試提供機(jī)會(huì)以求“發(fā)現(xiàn)錯(cuò)誤”測(cè)試真諦。W測(cè)試模型由于錯(cuò)誤可能隨時(shí)產(chǎn)生在軟件開發(fā)過程的各個(gè)階段，具傳遞性特點(diǎn)的軟件錯(cuò)誤的發(fā)現(xiàn)與解決具有放大性。所以可以做這樣的理解，越早進(jìn)行測(cè)試工作，發(fā)現(xiàn)與解決錯(cuò)誤所付出的代價(jià)越小，風(fēng)險(xiǎn)越小。據(jù)此，以V模型作為基礎(chǔ)的W模型由SystemEvolutif公司所提出，見圖4-3。[43]圖STYLEREF1\s4SEQ圖\*ARABIC\s15W模型結(jié)構(gòu)示意圖W模型由表示開發(fā)過程的一個(gè)“V”和表示測(cè)試過程的一個(gè)“V”重疊而成，開發(fā)過程中包括需求分析階段、規(guī)格書生成階段、軟件設(shè)計(jì)階段、代碼編程階段、軟件構(gòu)建階段、系統(tǒng)構(gòu)建以及安裝階段等。測(cè)試過程包括需求測(cè)試活動(dòng)、規(guī)格測(cè)試活動(dòng)、單元測(cè)試活動(dòng)、集成測(cè)試活動(dòng)、系統(tǒng)測(cè)試活動(dòng)以及確認(rèn)測(cè)試活動(dòng)等，且各項(xiàng)測(cè)試活動(dòng)分別對(duì)應(yīng)開發(fā)過程的各階段。按照W模型，開發(fā)過程各階段的可交付產(chǎn)品都要進(jìn)行測(cè)試，盡可能即時(shí)地發(fā)現(xiàn)并解決所出現(xiàn)的錯(cuò)誤。提出的新的軟件測(cè)試模型無論是X測(cè)試模型還是V測(cè)試模型，它們所表述的內(nèi)容都較為片面，不過就開發(fā)和測(cè)試的本質(zhì)要求而言，該二者是完全一致的。X測(cè)試模型將軟件測(cè)試的設(shè)計(jì)及各個(gè)階段的迭代關(guān)系表示得很好，V模型的重點(diǎn)在于表示測(cè)試與軟件構(gòu)造各個(gè)階段的對(duì)應(yīng)關(guān)系。W模型以V模型作為基礎(chǔ)，為了達(dá)到保證需求的準(zhǔn)確性、一致性、完整性、可測(cè)試性和可實(shí)現(xiàn)性以及設(shè)計(jì)對(duì)需求的正確性、規(guī)范性、可追蹤性和可測(cè)試性等目的，其增加了需求測(cè)試、規(guī)格測(cè)試以及設(shè)計(jì)測(cè)試。同時(shí)也增加了測(cè)試的對(duì)象。一般的軟件測(cè)試模型還有螺旋模型、增量模型等，雖然它們都有各自的特點(diǎn)，不過它們也都有自己無法克服的致命缺點(diǎn)。這些測(cè)試模型在那些項(xiàng)目較小、投資成本比較少、系統(tǒng)分析比較簡(jiǎn)單的中小型軟件項(xiàng)目中比較適用。但是對(duì)于大中型項(xiàng)目來說，其開發(fā)過程必然涉及到許多人員和部門，各種角色之間的交流和溝通是個(gè)很復(fù)雜的問題。在這些項(xiàng)目中，如果我們使用傳統(tǒng)模型這種從一而終的測(cè)試方法，我們可以想象有些是不可實(shí)現(xiàn)的。本文針對(duì)傳統(tǒng)的V和W測(cè)試模型的不足，提出了一種改進(jìn)的、更加合理的軟件測(cè)試模型。該模型保留了V測(cè)試模型的測(cè)試活動(dòng)分層和分階段的特性，但與之不同的是:在該測(cè)試模型中，需求分析、規(guī)格說明、程序設(shè)計(jì)及代碼編寫仍然是一系列的串行活動(dòng)，但彼此間有的只是相對(duì)性的獨(dú)立，彼此交錯(cuò)，有一定的牽制性，見圖4-4。該模型利用時(shí)間軸表示事件相對(duì)的先后順序。開發(fā)與測(cè)試并行開始于t1時(shí)間。首先根據(jù)用戶需求設(shè)計(jì)系統(tǒng)測(cè)試用例，需求被逐步明確后，最終形成用戶需求說明書。設(shè)計(jì)功能測(cè)試用例開始于t2時(shí)間。軟件開發(fā)的概要設(shè)計(jì)開始于t3時(shí)間，此時(shí)，有關(guān)設(shè)計(jì)系統(tǒng)測(cè)試用例的活動(dòng)逐步停止，以需求說明書和概要設(shè)計(jì)文檔為基礎(chǔ)開始了與集成測(cè)試用例相關(guān)的設(shè)計(jì)活動(dòng)。到t4時(shí)間時(shí)，設(shè)計(jì)活動(dòng)逐步停止，此時(shí)單元測(cè)試用例成為了設(shè)計(jì)的重點(diǎn)。t5時(shí)間進(jìn)入編碼階段，實(shí)現(xiàn)并執(zhí)行單元測(cè)試用例，集成測(cè)試已經(jīng)集成的模塊。集成好的功能模塊在集成測(cè)試完成3/4左右后就比較穩(wěn)定了，此時(shí)，功能測(cè)試就可以開始了。系統(tǒng)測(cè)試在編碼階段后期進(jìn)行。單元測(cè)試和集成測(cè)試要在編碼階段結(jié)束時(shí)完成，而此時(shí)功能測(cè)試和系統(tǒng)測(cè)試及分析仍在繼續(xù)，直到軟件質(zhì)量足夠好。該模型在執(zhí)行測(cè)試用例時(shí)將錯(cuò)誤反饋給開發(fā)人員，然后再修改、重復(fù)執(zhí)行測(cè)試用例。鑒于軟件開發(fā)過程每個(gè)階段的結(jié)果都可能影響到前一個(gè)階段的測(cè)試用例，測(cè)試人員還需要返回修改被影響的測(cè)試用例。與原有的測(cè)試模型相比較，這種新的軟件測(cè)試模型具有以下優(yōu)勢(shì)：(l)測(cè)試與開發(fā)并行化軟件測(cè)試與開發(fā)過程的其他階段不再是串行工作方式，而是與整個(gè)開發(fā)過程并行進(jìn)行。同時(shí)，將制定、設(shè)計(jì)測(cè)試計(jì)劃和編寫測(cè)試用例工作與軟件開發(fā)過程中的需求分析、軟件設(shè)計(jì)和編寫代碼工作并行，并做好充分的準(zhǔn)備，克服了原有測(cè)試工作的盲目性。(2)可用來設(shè)計(jì)測(cè)試用例的信息更廣泛新的測(cè)試模型不再僅僅依據(jù)文檔設(shè)計(jì)測(cè)試用例，其使用的是可執(zhí)行程序、源碼等所有能獲得的信息。就目前產(chǎn)品而言，擁有完善文檔的很少，而且其更新速度遠(yuǎn)落后于代碼變化的速度。同代碼一樣，文檔也會(huì)存在錯(cuò)誤，因此，要設(shè)計(jì)出更深入的測(cè)試用例僅僅依據(jù)軟件設(shè)計(jì)留下來的文檔可能性不太大。而新的測(cè)試模型可使用執(zhí)行程序、源碼等信息來幫助設(shè)計(jì)測(cè)試用例。(3)編碼和測(cè)試的混沌狀態(tài)V測(cè)試模型中，編碼在前，測(cè)試在后，其劃分很清晰。然而如此清晰的劃分在實(shí)際開發(fā)過程中并不存在，通常，編程人員都會(huì)有這樣的感受，倘若等到完成所有的編碼之后再開始單元測(cè)試，惡夢(mèng)也必定會(huì)開始。比較容易被編程人員所接受的方法為:開發(fā)一段，測(cè)試一點(diǎn);然后再開發(fā)，再測(cè)試。因此，我們將編碼和測(cè)試這種反復(fù)輪換的狀態(tài)稱為“混沌狀態(tài)”。(4)關(guān)于測(cè)試的循環(huán)幅度新的測(cè)試模型增加了指向箭頭，這些箭頭從各測(cè)試階段指向單元測(cè)試，意在表明發(fā)現(xiàn)并修改了該階段的錯(cuò)誤以后還需要回歸測(cè)試的范圍：都以最底層的單元測(cè)試為起點(diǎn)開始，正確地規(guī)范了回歸測(cè)試的應(yīng)用范圍，從而保證原有錯(cuò)誤的徹底修改以及新錯(cuò)誤的徹底避免。(5)分析、設(shè)計(jì)及代碼編寫具有漸進(jìn)性該改進(jìn)型測(cè)試模型保留了V測(cè)試模型的測(cè)試活動(dòng)分層和分階段的特性，但與之不同的是:在該測(cè)試模型中，需求分析、系統(tǒng)設(shè)計(jì)及代碼編寫仍然是一系列的串行活動(dòng)，但彼此之間已不是完全獨(dú)立的階段，而是彼此交錯(cuò)，相對(duì)性的獨(dú)立，存在一定牽制性。軟件開發(fā)是智力創(chuàng)作過程，不能單純用線性思維來實(shí)現(xiàn)，例如一個(gè)軟件開發(fā)的需求不可避免地要經(jīng)常變動(dòng)，那么只有先確定下穩(wěn)定的需求和易變的需求，針對(duì)穩(wěn)定需求制定核心的系統(tǒng)設(shè)計(jì)，才能進(jìn)行主要的代碼編寫。而易變的需求則使得這三個(gè)過程，甚至是后面的測(cè)試工作都會(huì)反復(fù)進(jìn)行，實(shí)質(zhì)上，改進(jìn)型也是一種漸進(jìn)型。(6)不斷回顧并維護(hù)原有的測(cè)試用例在概要設(shè)計(jì)階段所設(shè)計(jì)出的測(cè)試用例，由于獲取的信息不充分，在詳細(xì)設(shè)計(jì)完成后其仍有出現(xiàn)錯(cuò)誤的可能，而新的模型不斷回顧并維護(hù)原有的測(cè)試用例，從而保證了測(cè)試用例的及時(shí)修改，確保軟件新版本發(fā)布時(shí)，所用的測(cè)試用例集(testSuite)都是針對(duì)最新版本的。圖STYLEREF1\s4SEQ圖\*ARABIC\s16新的軟件測(cè)試過程框架模型嵌入式系統(tǒng)軟件測(cè)試模型應(yīng)用前幾章對(duì)軟件測(cè)試基本情況進(jìn)行了探討，之后在傳統(tǒng)模型的基礎(chǔ)上，根據(jù)超市倉(cāng)儲(chǔ)管理系統(tǒng)的特點(diǎn)提出了新的軟件測(cè)試模型。我們將在本章詳細(xì)的介紹如何選用合適的軟件測(cè)試方法和技術(shù)，測(cè)試的各個(gè)階段是如何實(shí)現(xiàn)的，并制定出合理的軟件測(cè)試策略對(duì)系統(tǒng)進(jìn)行測(cè)試。根據(jù)新模型結(jié)合本實(shí)例，我們將測(cè)試分成了兩個(gè)部分:即單元測(cè)試、集成測(cè)試。下面將一一予以介紹。超市倉(cāng)儲(chǔ)管理系統(tǒng)的結(jié)構(gòu)和特點(diǎn)超市倉(cāng)儲(chǔ)管理系統(tǒng)的結(jié)構(gòu)現(xiàn)根據(jù)該超市倉(cāng)儲(chǔ)管理系統(tǒng)的需求繪制HIPO圖(Hierarchyplusinputprocessingoutput，是美國(guó)IBM公司70年代發(fā)展起來的表示軟件系統(tǒng)結(jié)構(gòu)的工具分層圖)，如圖5-1所示。圖STYLEREF1\s5SEQ圖\*ARABIC\s11超市倉(cāng)儲(chǔ)管理系統(tǒng)的需求繪制HIPO圖超市倉(cāng)儲(chǔ)管理系統(tǒng)的特點(diǎn)(l)需要指出的是，超市倉(cāng)儲(chǔ)管理系統(tǒng)PB編寫的程序基于模塊化思想設(shè)計(jì)，在實(shí)時(shí)多任務(wù)操作系統(tǒng)上進(jìn)行實(shí)現(xiàn)，依功能劃分模塊，據(jù)任務(wù)機(jī)制實(shí)現(xiàn)模塊，采用多任務(wù)同步機(jī)制，通過傳送消息實(shí)現(xiàn)各模塊間的通信。以這一事實(shí)為基礎(chǔ)，本課題的研究針對(duì)測(cè)試也必然想到了這點(diǎn)。(2)超市倉(cāng)儲(chǔ)管理系統(tǒng)軟件提供的用戶操作界面比較豐富，而且部分模塊之間關(guān)系緊密。超市倉(cāng)儲(chǔ)管理系統(tǒng)共有四大功能模塊，涉及到用戶界面包括功能中的子界面12個(gè)，很多模塊之間有著緊密的關(guān)系。超市倉(cāng)儲(chǔ)管理系統(tǒng)的測(cè)試方案由于超市倉(cāng)儲(chǔ)管理系統(tǒng)具備的上述特點(diǎn)，使超市倉(cāng)儲(chǔ)管理軟件測(cè)試變得復(fù)雜，決不能僅僅應(yīng)用通用軟件的測(cè)試方法來對(duì)其實(shí)施測(cè)試。本課題的測(cè)試研究針對(duì)超市倉(cāng)儲(chǔ)管理系統(tǒng)的每一個(gè)特點(diǎn)，制定了以下的測(cè)試方案。針對(duì)系統(tǒng)開發(fā)語(yǔ)言制定的測(cè)試方案超市倉(cāng)儲(chǔ)管理系統(tǒng)軟件采用面向?qū)ο蟮恼Z(yǔ)言編碼，語(yǔ)言是高級(jí)語(yǔ)言，編寫出的程序是結(jié)構(gòu)化的。優(yōu)點(diǎn)是程序可讀性強(qiáng)，結(jié)構(gòu)化程度高，這給測(cè)試帶來了便利，但也要針對(duì)面向?qū)ο箝_發(fā)語(yǔ)言的特點(diǎn)，在測(cè)試工作中考慮以下幾點(diǎn):(1)針對(duì)面向?qū)ο筌浖袀}(cāng)儲(chǔ)管理系統(tǒng)軟件利用提供的圖形類庫(kù)來完成用戶交互界面設(shè)計(jì)，遵循面向?qū)ο笏枷胧褂谜Z(yǔ)言進(jìn)行開發(fā)。系統(tǒng)具有多態(tài)、繼承、封裝等屬于面向?qū)ο筌浖闹T多特征，并通過消息機(jī)制積極響應(yīng)交互事件。而傳統(tǒng)的面向過程軟件，其測(cè)試方法僅考慮過程調(diào)用關(guān)系，因此會(huì)遺漏一些錯(cuò)誤也是難以避免的。(2)針對(duì)面向過程軟件超市倉(cāng)儲(chǔ)管理系統(tǒng)軟件的開發(fā)采用的是面向?qū)ο蟮木幊陶Z(yǔ)言，然而在成員函數(shù)內(nèi)部仍然大量存在了面向過程編程語(yǔ)言的痕跡。鑒于面向?qū)ο蟮能浖y(cè)試方法無法實(shí)現(xiàn)針對(duì)整個(gè)系統(tǒng)的測(cè)試，故應(yīng)結(jié)合使用面向過程的軟件測(cè)試方法進(jìn)行單元測(cè)試。一般而言，面向過程的軟件測(cè)試都會(huì)從兩方面入手：功能性測(cè)試和結(jié)構(gòu)性測(cè)試，也即所謂的黑盒測(cè)試和白盒測(cè)試。鑒于功能模塊之間關(guān)系都比較緊密的特點(diǎn)，因而基于此制定出的測(cè)試方案在測(cè)試開始后，需要側(cè)重對(duì)以下幾個(gè)方面的測(cè)試:在進(jìn)行單元測(cè)試前，針對(duì)源代碼做靜態(tài)分析時(shí)，務(wù)必要認(rèn)真作好對(duì)數(shù)據(jù)流的分析工作。在不同模塊操作同一數(shù)據(jù)區(qū)是模塊之間緊密聯(lián)系的主要體現(xiàn)，因此，需要將關(guān)鍵數(shù)據(jù)的流程跟蹤作為測(cè)試的重點(diǎn)，否則就很容易出現(xiàn)諸如對(duì)于同一數(shù)據(jù)不同文件都會(huì)重復(fù)申請(qǐng)內(nèi)存或者重復(fù)賦值等錯(cuò)誤。在對(duì)測(cè)試用例進(jìn)行設(shè)計(jì)前，要借助函數(shù)關(guān)系圖、文件關(guān)系圖等方法充分分析模塊與模塊間的關(guān)系。針對(duì)用戶界面的測(cè)試方案針對(duì)用戶界面制定的測(cè)試方案，其提供的用戶操作界面比較豐富，包括菜單、工具欄、命令按鈕、滾動(dòng)條、下拉列表等控件，大部分操作界面之間還可進(jìn)行切換。目前，測(cè)試領(lǐng)域中還沒有出現(xiàn)針對(duì)用戶界面的具體成熟的測(cè)試方案，這里借助需求分析和設(shè)計(jì)過程，將完成一個(gè)用例的操作過程加以確定，同時(shí)將可能出現(xiàn)的誤操作和異常列舉出來。在測(cè)試過程中，主要是考核這些操作的結(jié)果，確保完成用戶的目標(biāo)，并驗(yàn)證誤操作和異常對(duì)系統(tǒng)沒有影響。單元測(cè)試的實(shí)現(xiàn)單元測(cè)試介紹軟件單元測(cè)試(unitTesting)是檢驗(yàn)程序的最小單位，是在軟件開發(fā)過程中實(shí)施的最低級(jí)別的測(cè)試活動(dòng)，即檢查單元程序模塊有無錯(cuò)誤。單元測(cè)試是在編碼完成后必須進(jìn)行的測(cè)試工作，又稱為模塊測(cè)試。在單元測(cè)試活動(dòng)中，可并行測(cè)試系統(tǒng)內(nèi)的多個(gè)模塊。單元測(cè)試主要包括五大任務(wù)，分別是：局部數(shù)據(jù)結(jié)構(gòu)測(cè)試、模塊接口測(cè)試、路徑測(cè)試、邊界測(cè)試以及錯(cuò)誤處理測(cè)試。以上這些測(cè)試的目的在于盡可能發(fā)現(xiàn)模塊內(nèi)部的側(cè)重于算法方面程序差錯(cuò)，進(jìn)而保證每個(gè)軟件模塊的行為符合規(guī)格說明。在單元測(cè)試中，依據(jù)詳細(xì)設(shè)計(jì)的說明書將軟件的獨(dú)立單元分離出來進(jìn)行測(cè)試。較多情況下，單元測(cè)試都采用以白盒測(cè)試為主，輔之以黑盒測(cè)試的方法，針對(duì)重要的控制路徑設(shè)計(jì)測(cè)試用例，使之能鑒別和響應(yīng)任何合理與不合理的輸入，從而發(fā)現(xiàn)模塊內(nèi)部的錯(cuò)誤。從如下幾個(gè)方面就可以看出單元測(cè)試的重要性:(1)測(cè)試成本:在單元測(cè)試階段某些問題很容易被發(fā)現(xiàn)，可是若在后期的測(cè)試中發(fā)現(xiàn)，花費(fèi)的成本以及定位問題和解決問題的費(fèi)用將成倍上升。同理，認(rèn)真做好單元測(cè)試，將會(huì)在系統(tǒng)集成時(shí)節(jié)約時(shí)間。(2)測(cè)試效果:單元測(cè)試是測(cè)試階段的基礎(chǔ)，能發(fā)現(xiàn)較深層次的問題，同時(shí)單元測(cè)試關(guān)注的范圍不僅是程序代碼，最重要的是關(guān)注代碼如何解決問題。(3)產(chǎn)品質(zhì)量:單元測(cè)試完成的好壞直接影響到產(chǎn)品的質(zhì)量等級(jí)，有時(shí)代碼中的某一個(gè)小錯(cuò)誤可能導(dǎo)致整個(gè)產(chǎn)品的質(zhì)量降低一個(gè)指標(biāo)，這些問題需要通過單元測(cè)試工作解決和避免。測(cè)試的目的有很多，很多開發(fā)人員習(xí)慣地認(rèn)為單元測(cè)試是為了檢測(cè)代碼中的錯(cuò)誤，顯然這一觀點(diǎn)是不嚴(yán)謹(jǐn)?shù)?。通常，軟件的開發(fā)質(zhì)量往往都是從過程上進(jìn)行保證的。編碼前，如果詳細(xì)設(shè)計(jì)的質(zhì)量很大程度上已經(jīng)能夠得到保證，那么單元測(cè)試不僅要檢測(cè)代碼的錯(cuò)誤，同時(shí)還需要測(cè)試代碼與詳細(xì)設(shè)計(jì)是否一致。故，單元測(cè)試主要有以下目的:第一、驗(yàn)證代碼與設(shè)計(jì)相符與否;第二、跟蹤需求，實(shí)現(xiàn)設(shè)計(jì);第三、從設(shè)計(jì)和需求中發(fā)現(xiàn)錯(cuò)誤;第四、發(fā)現(xiàn)編碼過程引入的錯(cuò)誤。綜合而言，構(gòu)筑產(chǎn)品質(zhì)量的基石是單元測(cè)試，倘若放棄了單元測(cè)試，后期就需要花費(fèi)加倍的時(shí)間來彌補(bǔ)。對(duì)于軟件開發(fā)團(tuán)隊(duì)來講，任何人都不愿意只為節(jié)約早期單元測(cè)試的時(shí)間，最終造成開發(fā)的整個(gè)產(chǎn)品失敗或重來。單元測(cè)試的策略與實(shí)現(xiàn)所示。圖STYLEREF1\s5SEQ圖\*ARABIC\s12單元測(cè)試環(huán)境一般的單元測(cè)試策略有三種:(1)由頂向下進(jìn)行單元測(cè)試，該方法可以省去驅(qū)動(dòng)模塊的設(shè)計(jì);(2)由底向上進(jìn)行單元測(cè)試，該方法可以省去樁模塊的設(shè)計(jì);(3)獨(dú)立的單元測(cè)試，即不與任何模塊發(fā)生關(guān)系，所有需要用到的其他單元都要做樁模塊，驅(qū)動(dòng)模塊也要自己設(shè)計(jì)。前兩種方法綜合了集成的概念，隨著單元測(cè)試的進(jìn)行，可以看到系統(tǒng)一個(gè)初步集成的概貌。但是覆蓋率會(huì)越來越難以保證，并且在每個(gè)單元測(cè)試之前都必須保證相關(guān)單元的正確性。方法三比較獨(dú)立，覆蓋率容易保證，并且可以并行進(jìn)行，但工作量最大。對(duì)此，在本實(shí)例中我們要按照實(shí)際情況選擇合適的策略進(jìn)行單元測(cè)試。我們選取源代碼中最簡(jiǎn)單的一個(gè)小程序來舉例:PublicvoidfuncA(inta,intb){if(max(a,b)<0){system.out.println(“所有輸入值都是負(fù)數(shù)!\n”).}Else{system.out.println(“至少有一個(gè)輸入的是0或自然數(shù)!恤”);}}intmax(inta,intb){if(a>=b){returna}else{returnb}為了減輕樁模塊工作量，我們采用由底向上的測(cè)試策略，因此先對(duì)max函數(shù)進(jìn)行單元測(cè)試，然后直接使用max做樁來測(cè)試funcA函數(shù)。但根據(jù)策略二的方法，我們?cè)跍y(cè)試funcA的時(shí)候是把funcA和max代碼作為一個(gè)整體進(jìn)行測(cè)試的，因此要求測(cè)試用例能夠同時(shí)覆蓋這兩個(gè)函數(shù)。在此借鑒獨(dú)立測(cè)試策略，盡管我們直接使用了max，但仍把它理解為樁，因此在設(shè)計(jì)用例時(shí)，我們不關(guān)注max本身怎么執(zhí)行，而關(guān)注該樁要返回一個(gè)小于零和大于等于零的值，以驗(yàn)證funcA能否在這種情況下輸出需要的信息。同時(shí)在考慮覆蓋率時(shí)，也只考慮funcA的覆蓋率，而不必考慮max的覆蓋率。還有，本例的銷售通知單中(如圖5-3)，銷售數(shù)量一欄中的合法輸入值一定為正整數(shù)，我們通過輸入負(fù)值或其他類型的數(shù)值，檢測(cè)該程序能否正確的輸出或提示報(bào)警，通過對(duì)不同輸入值的鍵入，來考查源程序的覆蓋率。圖