<dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><small id="yhprb"></small><dfn id="yhprb"></dfn><small id="yhprb"><delect id="yhprb"></delect></small><small id="yhprb"></small><small id="yhprb"></small> <delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"></dfn><dfn id="yhprb"></dfn><s id="yhprb"><noframes id="yhprb"><small id="yhprb"><dfn id="yhprb"></dfn></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><small id="yhprb"></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn> <small id="yhprb"></small><delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn>
關(guān) 閉

新聞中心

EEPW首頁(yè) > 安全與國防 > 設計應用 > 嵌入式軟件技術(shù)軟件測試策略和方案設計

嵌入式軟件技術(shù)軟件測試策略和方案設計

作者: 時(shí)間:2016-12-22 來(lái)源:網(wǎng)絡(luò ) 收藏

軟硬件結合的式系統正越來(lái)越多地應用到我們常見(jiàn)的儀器設備中,領(lǐng)域目標系統的應用系統也日趨復雜,開(kāi)發(fā)技術(shù)日新月異。同時(shí),隨著(zhù)硬件技術(shù)發(fā)展的日趨穩定,而軟件故障卻日益突顯,由此軟件的重要性已逐漸引起人們的重視,越來(lái)越多的研究人員認識到式系統,優(yōu)化其測試技術(shù)已勢在必行,研究出合適的嵌入式軟件系統測試方法,正是本課題的意義所在。

本文引用地址:http://dyxdggzs.com/article/201612/333021.htm

嵌入式系統介紹及軟件特點(diǎn)

嵌入式系統簡(jiǎn)介

嵌入式系統是以應用為中心,以計算機技術(shù)為基礎,并且軟硬件可裁剪,是專(zhuān)為應用系統量身打造、是對功能、可靠性、成本、體積、功耗有嚴格要求的專(zhuān)用的計算機系統。

嵌入式系統一般指非PC類(lèi)標配系統,它也包括硬件和軟件兩部分。硬件包括處理器/微處理器、存儲器及外設器件和I/O端口、圖形控制器等。軟件部分包括操作系統軟件(OS)(要求實(shí)時(shí)和多任務(wù)操作)和應用程序。有時(shí)設計人員把這兩種軟件組合在一起。應用程序控制著(zhù)系統的運作和行為,而操作系統控制著(zhù)應用程序編程與硬件的交互作用。

嵌入式系統軟件特點(diǎn)分析

嵌入式系統開(kāi)發(fā)有其自身的特點(diǎn)。一般先進(jìn)行硬件部分的開(kāi)發(fā),主要包括形成裸機平臺,根據需要移植實(shí)時(shí)操作系統,開(kāi)發(fā)底層的硬件驅動(dòng)程序等。硬件平臺測試通過(guò)后,應用軟件的開(kāi)發(fā)調試是基于該硬件平臺進(jìn)行的,這同時(shí)也是對硬件平臺的一個(gè)測試。

嵌入式系統的開(kāi)發(fā)過(guò)程是一個(gè)軟硬件互相協(xié)調,互相反饋和互相測試的過(guò)程。一般來(lái)說(shuō),在嵌入式系統軟件中,底層驅動(dòng)程序、操作系統和應用程序的界面是不清晰的,根據需要甚至混編在一起。這主要是由于嵌入式系統中軟件對硬件的依賴(lài)性造成的?;谇度胧杰浖τ布囊蕾?lài)性,其要求軟件測試時(shí)必須最大限度地模擬被測軟件的實(shí)際運行環(huán)境,以保證測試的可靠性,而底層程序和應用程序界限的不清晰又增加了測試的難度。測試時(shí)只有確認嵌入式系統平臺及底層程序是正確的情況下才能進(jìn)行應用程序的測試,而且在系統測試時(shí),錯誤的定位較為困難。

軟件的專(zhuān)用性也是嵌入式軟件的一個(gè)重要特點(diǎn)。由于嵌入式軟件設計是以一定的目標硬件平臺為基礎的,面向固定的任務(wù)進(jìn)行的,因此,一旦被加載到目標系統上,功能必須完全確定。這個(gè)特點(diǎn)決定了嵌入式應用軟件的繼承性較差,也延長(cháng)系統的測試時(shí)間和增加了測試費用。

嵌入式軟件的另外一個(gè)重要特點(diǎn)就是實(shí)時(shí)性。這是基于軟件的執行角度而言的,也就是說(shuō)嵌入式軟件的執行要滿(mǎn)足一定的時(shí)間約束。嵌入式系統中,應用軟件自身算法的復雜度和操作系統任務(wù)調度,決定了系統資源的分配和消耗。因此,對系統實(shí)時(shí)性進(jìn)行測試時(shí),要借助一定的測試工具對應用程序算法復雜度和操作系統任務(wù)調度進(jìn)行分析測試??梢?jiàn)嵌入式軟件與傳統的面向對象和面向過(guò)程的軟件相比有其自身的特點(diǎn)。所以嵌入式軟件的開(kāi)發(fā)和測試也就與一般商用軟件的開(kāi)發(fā)和測試策略有了很大的不同,可以說(shuō)嵌入式軟件是最難測試的一種軟件。針對這些特點(diǎn)對嵌入式軟件的測試進(jìn)行研究是必要的和有意義的。

嵌入式軟件測試

軟件測試是軟件質(zhì)量保證的關(guān)鍵因素,代表了規約、設計和編碼的最終檢查。是從經(jīng)濟、效率的角度出發(fā),對軟件代碼進(jìn)行質(zhì)量、正確性保證的一個(gè)過(guò)程。軟件測試是軟件開(kāi)發(fā)中的一個(gè)重要環(huán)節,也是軟件從開(kāi)發(fā)過(guò)程到應用過(guò)程的關(guān)鍵一環(huán),嵌入式軟件也不例外。

嵌入式軟件測試策略和方案設計

討論嵌入式軟件測試首先就會(huì )遇到一個(gè)問(wèn)題:為什么不把所有測試都放在目標上進(jìn)行呢?因為若所有測試都放在目標平臺上有很多不利的因素:

可能會(huì )造成與目標環(huán)境開(kāi)發(fā)者爭奪時(shí)間的瓶頸,避免提供更多的目標環(huán)境;

目標環(huán)境可能還不可行;

比起主機平臺環(huán)境,目標環(huán)境通常是不精密的和不方便的;

提供給開(kāi)發(fā)者的目標環(huán)境和開(kāi)發(fā)環(huán)境通常是很昂貴的;

開(kāi)發(fā)和測試工作可能會(huì )妨礙目標環(huán)境已存在持續的應用。

確定目標主機(host-target)測試環(huán)境后,開(kāi)發(fā)測試人員又會(huì )遇到以下的問(wèn)題:

1)多少開(kāi)發(fā)人員會(huì )進(jìn)行測試工作?

2)多少軟件應該測試,測試會(huì )花費多長(cháng)時(shí)間?

3)主機環(huán)境和目標環(huán)境有哪些軟件工具,價(jià)格怎樣?

4)多少目標環(huán)境可以提供給開(kāi)發(fā)者?

5)主機和目標主機之間的連接怎樣?

6)被測軟件下載到目標主機有多快?

7)使用主機與目標環(huán)境之間有什么限制?

進(jìn)行嵌入式軟件的測試都應深入考慮以上問(wèn)題,結合自身實(shí)際情況,選定合理測試策略和方案。

嵌入式軟件測試流程及方法

根據不同的指標,軟件測試有不同的劃分方法。

從軟件開(kāi)發(fā)過(guò)程中測試所處的不同階段可分為模塊測試、集成測試和系統測試;根據是否需要運行目標代碼又可分為動(dòng)態(tài)測試和靜態(tài)測試;根據目標代碼的可見(jiàn)性還可分為白盒測試(結構測試)和黑盒測試(功能測試)。

在軟件測試中,每種測試方法都不是孤立的。為了最經(jīng)濟最有效地達到測試的目的,各種測試方法往往是互相嵌套的。例如,在軟件的單元測試階段,可以用黑盒測試和白盒測試的方法分別進(jìn)行動(dòng)態(tài)測試。

近年來(lái),在軟件測試中,測試代碼的覆蓋率逐漸成為軟件測試的統一標準,因此不管采用何種測試方法,盡可能地提高軟件測試中的代碼覆蓋率是必需的。軟件測試代碼覆蓋率是基于白盒測試方法的,因此,為了提高軟件測試的代碼覆蓋率,測試人員必須清楚源代碼的結構,擁有程序設計文檔,以便設計測試用例,使測試盡可能地覆蓋程序內部結構的每條語(yǔ)句,提高代碼的覆蓋率。

嵌入式軟件測試流程

根據嵌入式系統的開(kāi)發(fā)流程,為了最經(jīng)濟地實(shí)現系統的功能,采用自頂向下、層層推進(jìn)的方法對嵌入式系統進(jìn)行測試,采用如下圖所示的測試流程。

平臺測試:這部分包括硬件電路測試、操作系統及底層驅動(dòng)程序測試等。

硬件電路測試需要用專(zhuān)門(mén)的測試工具進(jìn)行測試,這里不再多述。操作系統和底層驅動(dòng)程序的測試主要包括測試操作系統的任務(wù)調度、實(shí)時(shí)性能、通信端口的數據傳輸率。該階段測試完成后,系統應為一個(gè)完整的嵌入式系統平臺,用戶(hù)只需添加應用程序即可完成特定的任務(wù)。

模塊測試:把大型的嵌入式軟件系統劃分為若干個(gè)相對較小的任務(wù)模塊,由不同的程序員分別同時(shí)對其進(jìn)行編碼。編碼完成后,把各個(gè)模塊集成起來(lái)前,必須對單個(gè)模塊進(jìn)行測試。由于沒(méi)有其它數據模塊進(jìn)行數據傳遞的支持,該階段測試一般是在宿主機上進(jìn)行的(宿主機有豐富的資源和方便的調試環(huán)境)。此階段主要是進(jìn)行白盒測試,盡可能地測試每一個(gè)函數、每一個(gè)條件分支、每一個(gè)程序語(yǔ)句,提高代碼測試的覆蓋率。由于只有單個(gè)模塊正確才有整體集成的必要性,因此,單個(gè)模塊測試一定要充分、完整。模塊測試階段,測試用例的構造不但要測試系統正常的運行情況,還要進(jìn)行邊界測試。邊界測試就是進(jìn)行某一數據變量的最大值和最小值的測試,同時(shí)進(jìn)行越界測試,即輸入不該輸入的數據變量測試系統的運行情況。理想的嵌入式系統是不應該由于用戶(hù)的信息交互而導致死機的,這也是嵌入式設計的一個(gè)基本要求。因此,不論進(jìn)行何種測試,系統死機都該被作為測試錯誤處理。

在模塊測試階段,也可以把大的模塊劃分成小的模塊。在程序內部,小模塊之間數據傳遞的入口設計接口函數,要用于快速地定位錯誤。用模塊嵌套的思想進(jìn)行軟件測試,需要模塊內部結構清晰,數據鏈路簡(jiǎn)單。

集成測試:?jiǎn)蝹€(gè)軟件模塊測試正確之后,將所有模塊集成起來(lái)進(jìn)行測試。本階段主要是找出各模塊之間數據傳遞和系統組成后的邏輯結構的錯誤。在宿主機上采用黑盒與白盒相結合的方法進(jìn)行測試,要最大限度地模擬實(shí)際運行環(huán)境,可以屏蔽掉一些不影響系統執行的和數據傳遞難以模擬的函數。

集成測試是嵌入式軟件測試優(yōu)點(diǎn)充分體現的階段。集成測試前,應該由程序員根據模塊之間的數據的輸入輸出編寫(xiě)模塊接口函數,這需要負責不同軟件模塊的程序員共同協(xié)調完成,然后將模塊接口函數集成到接收數據模塊的入口處。單鏈路數據傳遞的軟件模塊集成測試時(shí)容易定位錯誤所在的軟件模塊。一個(gè)軟件模塊的數據不一定只有另外一個(gè)模塊提供,即軟件模塊的數據鏈路不一定只是單鏈路的,測試時(shí)可以把復雜鏈路結構的數據傳遞劃分為單鏈路結構數據傳送進(jìn)行錯誤定位。

集成測試是在擁有程序設計文檔、程序結構和數據結構時(shí),對軟件模塊在集成中出現的錯誤進(jìn)行測試。

系統測試:集成測試完成后,退出宿主機測試環(huán)境,把系統移植到目標機上來(lái),完成應用到現場(chǎng)環(huán)境中的移植,從用戶(hù)的角度對系統進(jìn)行黑盒測試,以驗證每一項具體的功能。由于測試者對程序內容、程序執行情況一無(wú)所知,因此本測試階段的錯誤定位比較困難。系統測試階段應該進(jìn)行意外測試和破壞性測試,即測試系統正常執行情況下不該發(fā)生的活動(dòng)和人為的破壞性的測試,進(jìn)一步驗證系統性能。系統測試階段不應該確定錯誤后立即修改代碼,應根據一定的錯誤發(fā)生頻率,確定測試周期,在每個(gè)測試周期結束時(shí)修改代碼,進(jìn)行反復測試;否則,不但增加了完全測試的任務(wù)量,而且降低了測試的可信度。

測試結果分析:測試結果分析可以定位錯誤,指導程序員修改代碼,同時(shí)指出進(jìn)行測試的程序進(jìn)一步測試的方向。測試結果分析是一個(gè)由測試結果和測試預得結果進(jìn)行分析、比較和定位錯誤的過(guò)程。測試結果分析是一次測試的最后環(huán)節,分析時(shí)應該考慮軟件的運行環(huán)境與實(shí)際運行環(huán)境的差異,以及各種外界因素的影響等。

白盒測試方法

白盒測試也稱(chēng)結構測試或邏輯驅動(dòng)測試,它是知道產(chǎn)品內部工作過(guò)程,可通過(guò)測試來(lái)檢測產(chǎn)品內部動(dòng)作是否按照規格說(shuō)明書(shū)的規定正常進(jìn)行,按照程序內部的結構測試程序,檢驗程序中的每條通路是否都能按預定要求正確工作的功能,白盒測試的主要方法有邏輯驅動(dòng)、基路測試等,主要用于軟件驗證。“白盒”法要求全面了解程序內部邏輯結構、對所有邏輯路徑進(jìn)行測試。“白盒”法是窮舉路徑測試。在使用這一方案時(shí),測試者必須檢查程序的內部結構,從檢查程序的邏輯著(zhù)手,得出測試數據。

黑盒測試方法

黑盒測試也稱(chēng)功能測試或數據驅動(dòng)測試,它是在已知產(chǎn)品所應具有的功能,通過(guò)測試來(lái)檢測每個(gè)功能是否都能正常使用。在測試時(shí),把程序看作一個(gè)不能打開(kāi)的黑盆子,在完全不考慮程序內部結構和內部特性的情況下,測試者在程序接口進(jìn)行測試。它只檢查程序功能是否按照需求規格說(shuō)明書(shū)的規定正常使用,程序是否能適當地接收輸入數鋸而產(chǎn)生正確的輸出信息,并且保持外部信息(如數據庫或文件)的完整性。黑盒測試方法主要有等價(jià)類(lèi)劃分、邊值分析、因果圖、錯誤推測等,主要用于軟件確認測試。“黑盒”法著(zhù)眼于程序外部結構、不考慮內部邏輯結構、針對軟件界面和軟件功能進(jìn)行測試。“黑盒”法是窮舉輸入測試,只有把所有可能的輸入都作為測試情況使用,才能以這種方法查出程序中所有的錯誤。

測試用例的構造

測試用例是為了測試目標程序設計的,包括輸入項和預得結果的一種文件。根據測試環(huán)境和測試目標程序的不同,可分為某種格式的文檔或某種輸入行為(如一次按鍵)等。測試用例的構造要盡可能覆蓋所有可能的取值范圍,使測試盡可能地覆蓋所有程序代碼,提高代碼的測試覆蓋率,同時(shí)又不作多余、重復和無(wú)意義的測試。在嵌入式軟件測試的不同階段,要構造不同的測試用例;在系統平臺測試階段,要構造針對系統任務(wù)調度、實(shí)時(shí)性能和底層驅動(dòng)程序的測試用例;在模塊測試階段,應構造針對某一模塊進(jìn)行測試的測試用例;在集成測試階段,針對系統集成時(shí)數據傳遞、結構連接的問(wèn)題構造相應的測試用例;在系統測試階段,要構造針對某項功能的或多項功能結合在一起的測試用例,或使用已經(jīng)在同類(lèi)產(chǎn)品上已經(jīng)驗證正確的測試用例,測試用例是可復用的。

結語(yǔ)

嵌入式設計已經(jīng)成為工業(yè)現代化、智能化的必經(jīng)之路,嵌入式產(chǎn)品已經(jīng)深入到各行各業(yè)。嵌入式系統的專(zhuān)用程度較高,系統的整體繼承性相對較小,為了保證系統的穩定性,軟件測試成為嵌入式開(kāi)發(fā)的一個(gè)重要環(huán)節。由于嵌入式軟件自身的特點(diǎn),傳統的軟件測試理論不能直接用于嵌入式軟件的測試。文章對嵌入式軟件的特點(diǎn)作了分析,總結了嵌入式軟件測試的策略和方案設計,提出了嵌入式軟件測試流程和測試方法。本文的研究?jì)热輰η度胧杰浖臏y試有重要意義。



關(guān)鍵詞: 嵌入

評論


相關(guān)推薦

技術(shù)專(zhuān)區

關(guān)閉
国产精品自在自线亚洲|国产精品无圣光一区二区|国产日产欧洲无码视频|久久久一本精品99久久K精品66|欧美人与动牲交片免费播放
<dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><small id="yhprb"></small><dfn id="yhprb"></dfn><small id="yhprb"><delect id="yhprb"></delect></small><small id="yhprb"></small><small id="yhprb"></small> <delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"></dfn><dfn id="yhprb"></dfn><s id="yhprb"><noframes id="yhprb"><small id="yhprb"><dfn id="yhprb"></dfn></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><small id="yhprb"></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn> <small id="yhprb"></small><delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn>