常用的測(cè)試方法和測(cè)試工具_(dá)第1頁(yè)
常用的測(cè)試方法和測(cè)試工具_(dá)第2頁(yè)
常用的測(cè)試方法和測(cè)試工具_(dá)第3頁(yè)
常用的測(cè)試方法和測(cè)試工具_(dá)第4頁(yè)
常用的測(cè)試方法和測(cè)試工具_(dá)第5頁(yè)
已閱讀5頁(yè),還剩5頁(yè)未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說(shuō)明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

1、常用的測(cè)試方法一、黑盒測(cè)試1. 黑盒測(cè)試其實(shí)是一種功能測(cè)試,主要在軟件的接口處進(jìn)行。主要測(cè)試的 以下幾類錯(cuò)誤:是否有不正確或遺漏的功能在給出的接口處正確的輸入是否有正確的輸出是否有數(shù)據(jù)結(jié)構(gòu)錯(cuò)誤或外部信息訪問(wèn)錯(cuò)誤性能上是否滿足要求是否有初始化或終止性錯(cuò)誤2. 黑盒測(cè)試用例等價(jià)類劃分等價(jià)類即輸入域的子集合 ,測(cè)試用例設(shè)計(jì)時(shí)應(yīng)設(shè)計(jì)出對(duì)應(yīng)的有效等價(jià)類和 無(wú)效等價(jià)類邊界值 邊界值法是對(duì)等價(jià)類劃分方法的補(bǔ)充,主要是測(cè)試發(fā)生在輸入和輸出域邊 界上的錯(cuò)誤 . 等價(jià)類劃分和邊界值著重考慮輸入條件 , 但測(cè)試時(shí)還應(yīng)考慮輸入條 件之間的關(guān)系,各種條件的組合情況,即因果圖因果圖根據(jù)輸入條件間的關(guān)系生成判定表,根據(jù)判定

2、表的每一列來(lái)設(shè)計(jì)測(cè)試用例 功能圖包括狀態(tài)遷移圖和邏輯模型 二、白盒測(cè)試1白盒測(cè)試是對(duì)軟件過(guò)程性細(xì)節(jié)做細(xì)致的檢查。主要對(duì)軟件程序模塊做以 下檢查:對(duì)模塊的所有路徑至少執(zhí)行一次對(duì)模塊的所有邏輯判斷,取“真”和“假”兩種情況各執(zhí)行一次在循環(huán)邊界和運(yùn)行界限內(nèi)執(zhí)行循環(huán)體測(cè)試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性 2白盒測(cè)試用例1)邏輯覆蓋語(yǔ)句覆蓋,采用條件組合分支覆蓋 對(duì)程序模塊中的每個(gè)取真分支和取假分支執(zhí)行一遍 條件覆蓋 對(duì)程序模塊中的每個(gè)判斷的每個(gè)條件執(zhí)行一遍 由于以上的測(cè)試用例都有較大的缺陷,所以一般不會(huì)使用 覆蓋更為合理有效條件組合覆蓋(邏輯覆蓋的主要方法)2)基本路徑測(cè)試用例 測(cè)試步驟: 根據(jù)詳細(xì)設(shè)計(jì)或源代碼導(dǎo)

3、出程序控制流圖 計(jì)算程序環(huán)路復(fù)雜性 ,即獨(dú)立路徑的數(shù)目 (一條新的路徑必須包含一條新邊 ) 生成測(cè)試用例 ( 輔助工具:圖形矩陣 )測(cè)試策略、單元測(cè)試1. 單元測(cè)試時(shí)主要對(duì)模塊的以下 5 個(gè)方面進(jìn)行檢查:模塊接口局部數(shù)據(jù)結(jié)構(gòu)邊界條件獨(dú)立路徑出錯(cuò)處理、集成測(cè)試1. 集成測(cè)試時(shí)主要要考察程序的以下幾個(gè)方面 :各個(gè)模塊連接時(shí),穿越模塊接口的數(shù)據(jù)是否會(huì)丟失 一個(gè)模塊是否會(huì)對(duì)另一個(gè)模塊的功能產(chǎn)生不利的影響 各個(gè)子功能組合起來(lái),能否達(dá)到預(yù)期的父功能 全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問(wèn)題單個(gè)模塊的誤差累積起來(lái),是否會(huì)被放大,從而達(dá)到不可接受的程度2. 集成測(cè)試的組織和實(shí)施中考慮的因素 :選用何種系統(tǒng)集成方法來(lái)進(jìn)行集成測(cè)試

4、各個(gè)模塊連接的順序模塊代碼編制和測(cè)試進(jìn)度是否集成測(cè)試的順序是否一致測(cè)試過(guò)程中是否需要有專門的硬件3. 集成測(cè)試完成的標(biāo)志成功執(zhí)行了測(cè)試計(jì)劃中規(guī)定的所有組裝測(cè)試修正了所發(fā)現(xiàn)的錯(cuò)誤測(cè)試結(jié)果通過(guò)了專門小組的評(píng)審、確認(rèn)測(cè)試1. 確認(rèn)測(cè)試流程 :進(jìn)行有效性測(cè)試,即在模擬的環(huán)境下(可能是開發(fā)環(huán)境),運(yùn)用黑盒測(cè)試 的方法,驗(yàn)證所沒(méi)軟件是否滿足需求說(shuō)明書列出的需求。 對(duì)于測(cè)試結(jié)果與預(yù)期結(jié) 果不相符進(jìn),要提交一份問(wèn)題報(bào)告。軟件配置復(fù)查 軟件配置復(fù)查的目的是保證軟件配置的所有成份都齊全,各方面的質(zhì)量 都符合要求。a測(cè)試和?測(cè)試a測(cè)試是一個(gè)用戶在開發(fā)環(huán)境下進(jìn)行的測(cè)試, 也可以是開發(fā)機(jī)構(gòu)內(nèi)部的 用戶在模擬實(shí)際操作環(huán)境

5、下進(jìn)行的測(cè)試。 ?測(cè)試是由軟件的多個(gè)用戶在一個(gè)或多 個(gè)用戶的實(shí)際使用環(huán)境下進(jìn)行的測(cè)試驗(yàn)收測(cè)試驗(yàn)收測(cè)試時(shí)軟件開發(fā)人員和 QA人員也應(yīng)參加,由用戶參加設(shè)計(jì)測(cè)試用 例,使用用戶界面輸入測(cè)試數(shù)據(jù),并分析測(cè)試結(jié)果。四、系統(tǒng)測(cè)試即通過(guò)確認(rèn)測(cè)試的軟作為整個(gè)系統(tǒng)中的一個(gè)元素而進(jìn)行的測(cè)試。嵌入式系統(tǒng)測(cè)試方法及工具通常嵌入式系統(tǒng)對(duì)可靠性的要求比較高。 嵌入式系統(tǒng)安全性的失效可能會(huì)導(dǎo) 致災(zāi)難性的后果, 即使是非安全性系統(tǒng), 由于大批量生產(chǎn)也會(huì)導(dǎo)致嚴(yán)重的經(jīng)濟(jì)損 失。這就要求對(duì)嵌入式系統(tǒng),包括嵌入式軟件進(jìn)行嚴(yán)格的測(cè)試、確認(rèn)和驗(yàn)證。一般來(lái)說(shuō),軟件測(cè)試有 7 個(gè)基本階段,即單元或模塊測(cè)試、集成測(cè)試、外部 功能測(cè)試、回歸測(cè)試

6、、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試、安裝測(cè)試。嵌入式軟件測(cè)試在 4 個(gè)階段上進(jìn)行,即模塊測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、硬件 / 軟件集成測(cè)試。前 3 個(gè)階段適用于任何軟件的測(cè)試, 硬件/ 軟件集成測(cè)試階段是嵌入式軟件所特有的, 目的是驗(yàn)證嵌入式軟件與其所控制的硬件設(shè)備能否正確地交互。1. 白盒測(cè)試與黑盒測(cè)試由于嚴(yán)格的安全性和可靠性的要求, 嵌入式軟件測(cè)試同非嵌入式軟件測(cè)試相 比,通常要求有更高的代碼覆蓋率。 對(duì)于嵌入式軟件, 白盒測(cè)試一般不必在目標(biāo) 硬件上進(jìn)行, 更為實(shí)際的方式是在開發(fā)環(huán)境中通過(guò)硬件仿真進(jìn)行, 所以選取的測(cè) 試工具應(yīng)該支持在宿主環(huán)境中的測(cè)試。因?yàn)楹诤袦y(cè)試與需求緊密相關(guān),需求規(guī)格說(shuō)明的質(zhì)量會(huì)直接影

7、響測(cè)試的結(jié) 果,黑盒測(cè)試只能限制在需求的范圍內(nèi)進(jìn)行。 在進(jìn)行嵌入式軟件黑盒測(cè)試時(shí), 要 把系統(tǒng)的預(yù)期用途作為重要依據(jù),根據(jù)需求中對(duì) 負(fù)載、定時(shí)、性能 的要求,判斷 軟件是否滿足這些需求規(guī)范。 為了保證正確地測(cè)試, 還須要檢驗(yàn)軟硬件之間的接 口。嵌入式軟件黑盒測(cè)試的一個(gè)重要方面是極限測(cè)試。 在使用環(huán)境中, 通常要求 嵌入式軟件的失效過(guò)程要平穩(wěn), 所以,黑盒測(cè)試不僅要檢查軟件工作過(guò)程, 也要 檢查軟件換效過(guò)程。2、目標(biāo)環(huán)境測(cè)試和宿主環(huán)境測(cè)試在嵌入式軟件測(cè)試中, 常常要在基于目標(biāo)的測(cè)試和基于宿主的測(cè)試之間作出 折衷?;谀繕?biāo)的測(cè)試消耗較多的經(jīng)費(fèi)和時(shí)間, 而基于宿主的測(cè)試代價(jià)較小, 但 畢竟是在模擬環(huán)

8、境中進(jìn)行的。目前的趨勢(shì)是把更多的測(cè)試轉(zhuǎn)移到宿主環(huán)境中進(jìn) 行,但是,目標(biāo)環(huán)境的復(fù)雜性和獨(dú)特性不可能完全模擬。在兩個(gè)環(huán)境中可以出現(xiàn)不同的軟件缺陷, 重要的是目標(biāo)環(huán)境和宿主環(huán)境的測(cè) 試內(nèi)容有所選擇。 在宿主環(huán)境中, 可以進(jìn)行邏輯或界面的測(cè)試、 以及與硬件無(wú)關(guān) 的測(cè)試。在模擬或宿主環(huán)境中的測(cè)試消耗時(shí)間通常相對(duì)較少, 用調(diào)試工具可以更 快地完成調(diào)試和測(cè)試任務(wù)。 而與定時(shí)問(wèn)題有關(guān)的白盒測(cè)試、 中斷測(cè)試、 硬件接口 測(cè)試只能在目標(biāo)環(huán)境中進(jìn)行。在軟件測(cè)試周期中,基于目標(biāo)的測(cè)試是在較晚的 “硬件/ 軟件集成測(cè)試”階段開始的, 如果不更早地在模擬環(huán)境中進(jìn)行白盒測(cè)試, 而是等到“硬件 / 軟件集成測(cè)試”階段進(jìn)行全部

9、的白盒測(cè)試,將耗費(fèi)更多的財(cái)力 和人力。2. 常用的嵌入式軟件測(cè)試工具1)內(nèi)存分析工具軟件和硬件的。在嵌入式系統(tǒng)中,內(nèi)存約束通常是有限的。內(nèi)存分析工具用來(lái)處理在動(dòng)態(tài)內(nèi) 存分配中存在的缺陷。 當(dāng)動(dòng)態(tài)內(nèi)存被錯(cuò)誤地分配后, 通常難以再現(xiàn), 可能導(dǎo)致的 失效難以追蹤, 使用內(nèi)存分析工具可以避免這類缺陷進(jìn)入功能測(cè)試階段。 目前有 兩類內(nèi)存分析工具軟件和硬件的。 基于軟件的內(nèi)存分析工具可能會(huì)對(duì)代碼的 性能造成很大影響, 從而嚴(yán)重影響實(shí)時(shí)操作; 基于硬件的內(nèi)存分析工具價(jià)格昂貴, 而且只能在工具所限定的運(yùn)行環(huán)境中使用。2)性能分析工具在嵌入式系統(tǒng)中, 程序的性能通常是非常重要的。 經(jīng)常會(huì)有這樣的要求, 在 特定

10、時(shí)間內(nèi)處理一個(gè)中斷, 或生成具有特定定時(shí)要求的一幀。 開發(fā)人面臨的問(wèn)題 是決定應(yīng)該對(duì)哪一部分代碼進(jìn)行優(yōu)化來(lái)改進(jìn)性能, 常常會(huì)花大量的時(shí)間去優(yōu)化那 些對(duì)性能沒(méi)有任何影響的代碼。 性能分析工具會(huì)提供有關(guān)的數(shù)據(jù), 說(shuō)明執(zhí)行時(shí)間 是如何消耗的,是什么時(shí)候消耗的,以及每個(gè)例程所用的時(shí)間。根據(jù)這些數(shù)據(jù), 確定哪些例程消耗部分執(zhí)行時(shí)間, 從而可以決定如何優(yōu)化軟件, 獲得更好的時(shí)間 性能。對(duì)于大多數(shù)應(yīng)用來(lái)說(shuō), 大部分執(zhí)行時(shí)間用在相對(duì)少量的代碼上, 費(fèi)時(shí)的代 碼估計(jì)占所有軟件總量的 5%-20%。性能分析工具不僅能指出哪些例程花費(fèi)時(shí)間, 而且與調(diào)試工具聯(lián)合使用可以引導(dǎo)開發(fā)人員查看需要優(yōu)化的特定函數(shù), 性能分析

11、工具還可以引導(dǎo)開發(fā)人員發(fā)現(xiàn)在系統(tǒng)調(diào)用中存在的錯(cuò)誤以及程序結(jié)構(gòu)上的缺陷。3)GUI 測(cè)試工具很多嵌入式應(yīng)用帶有某種形式的圖形用戶界面進(jìn)行交互, 有些系統(tǒng)性能測(cè)試 足根掘用戶輸入響應(yīng)時(shí)間進(jìn)行的。 GUI 測(cè)試工具可以作為腳本工具有開發(fā)環(huán)境中 運(yùn)行測(cè)試用例, 其功能包括對(duì)操作的記錄和回放、 抓取屏幕顯示供以后分析和比 較、設(shè)置和管理測(cè)試過(guò)程。很多嵌入式設(shè)備沒(méi)有 GUI,但常??梢詫?duì)嵌入式設(shè)備 進(jìn)行插裝來(lái)運(yùn)行GUI測(cè)試腳本,雖然這種方式可能要求對(duì)被測(cè)代碼進(jìn)行更改, 是節(jié)省了功能測(cè)試和回歸測(cè)試的時(shí)間。4)覆蓋分析工具在進(jìn)行白盒測(cè)試時(shí), 可以使用代碼覆蓋分析工具追蹤哪些代碼被執(zhí)行過(guò)。 析過(guò)程可以通過(guò)插裝來(lái)

12、完成, 插裝可以是在測(cè)試環(huán)境中嵌入硬件, 也可以是在可 執(zhí)行代碼中加入軟件, 也可以是二者相結(jié)合。 測(cè)試人員對(duì)結(jié)果數(shù)據(jù)加以總結(jié), 確 定哪些代碼被執(zhí)行過(guò), 哪些代碼被巡漏了。 覆蓋分析工具一般會(huì)提供有關(guān)功能覆 蓋、分支覆蓋、條件覆蓋的信息。對(duì)于嵌入式軟件來(lái)說(shuō),代碼覆蓋分析工具可能 侵入代碼的執(zhí)行, 影響實(shí)時(shí)代碼的運(yùn)行過(guò)程。 基于硬件的代碼覆蓋分析工具的侵 入程度要小一些,但是價(jià)格一般比較昂貴,而且限制被測(cè)代碼的數(shù)量。嵌入式測(cè)試的十大秘訣在嵌入式軟件開發(fā)過(guò)程中,一般來(lái)說(shuō),花在測(cè)試和花在編碼的時(shí)間比為 3:1( 實(shí) 際上可能更多 ) 。這個(gè)比例隨著你的編程和測(cè)試水平的提高而不斷下降,但不論 怎樣,

13、對(duì)一般人來(lái)講很重要。 很多年前, 一位開發(fā)人員為了對(duì)嵌入式有更深層次 的理解,向 Oracle 詢問(wèn)了這樣的一個(gè)問(wèn)題 : 我怎么才能知道并懂得我的系統(tǒng)到底 在干些什么呢 ? Oracle 面對(duì)這個(gè)問(wèn)題有些吃驚,因?yàn)樵诋?dāng)時(shí)沒(méi)有人這么問(wèn)過(guò), 而同時(shí)代的嵌入式開發(fā)人員問(wèn)的最多的大都圍繞 “我怎么才能使程序跑的更快” 、 “什么編譯器最好” 等膚淺的問(wèn)題。 所以,面對(duì)這個(gè)不同尋常卻異乎成熟的問(wèn)題, Oracle 感到欣喜并認(rèn)真回復(fù)了他 : 你的問(wèn)題很有深度很成熟, 因?yàn)橹挥胁粩嗟厝?深入理解才有可能不斷地提高水平。并且 Oracle 為了鼓勵(lì)這位執(zhí)著的程序員, 把10條關(guān)于嵌入式軟件開發(fā)測(cè)試的秘訣告訴

14、了他 :1. 懂得使用工具2. 盡早發(fā)現(xiàn)內(nèi)存問(wèn)題3. 深入理解代碼優(yōu)化4. 不要讓自己大海撈針5. 重現(xiàn)并隔離問(wèn)題6. 以退為進(jìn)7. 確定測(cè)試的完整性8. 提高代碼質(zhì)量意味著節(jié)省時(shí)間9. 發(fā)現(xiàn)它,分析它,解決它10. 利用初學(xué)者的思維 這十條秘訣在業(yè)界廣為流傳,使很多人受益。本文圍繞這十條秘訣展開論述。1. 懂得使用工具通常嵌入式系統(tǒng)對(duì)可靠性的要求比較高。 嵌入式系統(tǒng)安全性的失效可能會(huì)導(dǎo) 致災(zāi)難性的后果,即使是非安全性系統(tǒng), 由于大批量生產(chǎn)也會(huì)導(dǎo)致嚴(yán)重的經(jīng)濟(jì)損 失。這就要求對(duì)嵌入式系統(tǒng),包括嵌入式軟件進(jìn)行嚴(yán)格的測(cè)試、確認(rèn)和驗(yàn)證。隨 著越來(lái)越多的領(lǐng)域使用軟件和微處理器控制各種嵌入式設(shè)備, 對(duì)門益

15、復(fù)雜的嵌入 式軟件進(jìn)行快速有效的測(cè)試愈加顯得重要。就象修車需要工具一樣, 好的程序員應(yīng)該能夠熟練運(yùn)用各種軟件工具。 不同 的工具,有不同的使用范圍,有不同的功能。使用這些工具,你可以看到你的系 統(tǒng)在干些什么, 它又占用什么資源, 它到底和哪些外界的東西打交道。 讓你郁悶 好幾天的問(wèn)題可能通過(guò)某個(gè)工具就能輕松搞定, 可惜你就是不知道。 那么為什么 那么多的人總是在折騰個(gè)半死之后才想到要用呢?原因很多, 主要有兩個(gè)。 一個(gè) 是害怕,另一個(gè)是惰性。 害怕是因?yàn)榧尤霚y(cè)試用具或測(cè)試模塊到代碼需要技巧同 時(shí)有可能引入新的錯(cuò)誤, 所以他們總喜歡寄希望于通過(guò)不斷地修改重編譯代碼來(lái) 消除 bug, 結(jié)果卻無(wú)濟(jì)于

16、事。 懶惰是因?yàn)樗麄兞?xí)慣了使用 printf 之類的簡(jiǎn)單測(cè)試 手段。下面來(lái)介紹一些嵌入式常用的。. 源碼級(jí)調(diào)試器 Source-level Debugger這種調(diào)試器一般提供單步或多步調(diào)試、斷點(diǎn)設(shè)置、內(nèi)存檢測(cè)、變量查看等功能, 是嵌入式調(diào)試最根本有效的調(diào)試方法。 比如 VxWorks TornadoII 提供的 gdb 就屬 于這一種。. 簡(jiǎn)單實(shí)用的打印顯示工具 printfprintf 或其它類似的打印顯示工具估計(jì)是最靈活最簡(jiǎn)單的調(diào)試工具。打印代碼 執(zhí)行過(guò)程中的各種變量可以讓你知道代碼執(zhí)行的情況。但是, printf 對(duì)正常的 代碼執(zhí)行干擾比較大(一般printf占用CPU比較長(zhǎng)的時(shí)間),需

17、要慎重使用,最 好設(shè)置打印開關(guān)來(lái)控制打印。.ICE 或 JTAG調(diào)試器In-circuit EmulatorICE是用來(lái)仿真CPU核心的設(shè)備,它可以在不干擾運(yùn)算器的正常運(yùn)行情況下,實(shí) 時(shí)的檢測(cè)CPU的內(nèi)部工作情況。像桌面調(diào)試軟件所提供的:復(fù)雜的條件斷點(diǎn)、先 進(jìn)的實(shí)時(shí)跟蹤、性能分析和端口分析這些功能,它也都能提供。ICE 一般都有一個(gè)比較特殊的CPU稱為外合(bond-out)CPU。這是一種被打開了封裝的CPU并 且通過(guò)特殊的連接,可以訪問(wèn)到CPU勺內(nèi)部信號(hào),而這些信號(hào),在CPU被封裝時(shí), 是沒(méi)法“看到”的。當(dāng)和工作站上強(qiáng)大的調(diào)試軟件聯(lián)合使用時(shí),ICE就能提供你CPI所更換。JTAGJoint

18、 Test Action Group) 雖IC 和電路連接,但是這種串行接口擴(kuò)展了用途, Blackfin 設(shè)計(jì)的 Visual Dsp+ 就支持高速的 JTA所能找到的最全面的調(diào)試功能。但 ICE 同樣有一些缺點(diǎn):昂貴;不能全速工作; 同樣,并不是所有的CPU都可以作為外合CPU的,從另一個(gè)角度說(shuō),這些外合 C PU也不大可能及時(shí)的被新出的 然它最初開發(fā)出來(lái)是為了監(jiān)測(cè) 包括對(duì)調(diào)試的支持。AD公司為 G調(diào)試。.ROM監(jiān)視器ROM MonitorROM監(jiān)控器是一小程序,駐留在嵌入系統(tǒng) ROM中,通過(guò)串行的或網(wǎng)絡(luò)的連接和運(yùn) 行在工作站上的調(diào)試軟件通信。這是一種便宜的方式,當(dāng)然也是最低端的技術(shù)。 它

19、除了要求一個(gè)通信端口和少量的內(nèi)存空間外, 不需要其它任何專門的硬件。 并 提供了如下功能:下載代碼、運(yùn)行控制、斷點(diǎn)、單步步進(jìn)、以及觀察、修改寄存 器和內(nèi)存。因?yàn)镽OM監(jiān)控器是操作軟件的一部分,只有當(dāng)你的應(yīng)用程序運(yùn)行時(shí), 它才會(huì)工作。如果你想檢查CPU和應(yīng)用程序的狀態(tài),你就必須停下應(yīng)用程序,再 次進(jìn)入ROM監(jiān)控器。.Data 監(jiān)視器 Data Monitor這種監(jiān)視器在不停止CPU運(yùn)行的情況下不僅可以顯示指定變量?jī)?nèi)容,還可以收集 并以圖形形式顯示各個(gè)變量的變化過(guò)程。.OS 監(jiān)視器 Operating System Monitor 操作系統(tǒng)監(jiān)視器可以顯示諸如任務(wù)切換、信號(hào)量收發(fā)、中斷等事件。一方面

20、,這 些監(jiān)視器能夠?yàn)槟愠尸F(xiàn)事件之間的關(guān)系和時(shí)間聯(lián)系; 另一方面, 還可以提供對(duì)信 號(hào)量?jī)?yōu)先級(jí)反轉(zhuǎn)、死鎖和中斷延時(shí)等問(wèn)題的診斷。. 性能分析工具 Profiler可以用來(lái)測(cè)試CPU到底耗在那里。Profiler 工具可以讓你知道系統(tǒng)的瓶頸在那 里、CPU的使用率以及需要優(yōu)化的地方。. 內(nèi)存 Memory Teseter 可以找到內(nèi)存使用的問(wèn)題所在,比如內(nèi)存泄露、內(nèi)存碎片、內(nèi)存崩潰等問(wèn)題。如 果發(fā)現(xiàn)系統(tǒng)出現(xiàn)一些不可預(yù)知的或間歇性的問(wèn)題,就應(yīng)該使用內(nèi)存測(cè)測(cè)看。. 運(yùn)行跟蹤器 Execution Tracer可以顯示CPU執(zhí)行了哪些函數(shù)、誰(shuí)在調(diào)用、參數(shù)是什么、何時(shí)調(diào)用等情況。這種 工具主要用于測(cè)試代碼

21、邏輯,可以在大量的事件中發(fā)現(xiàn)異常的那些。. 覆蓋工具 Coverage Tester主要顯示CPU具體執(zhí)行了那些代碼,并讓你知道那些代碼分支沒(méi)有被執(zhí)行到。這樣有助于提高代碼質(zhì)量并消除無(wú)用代碼。.GUIGUI Tester 很多嵌入式應(yīng)用帶有某種形式的圖形用戶界面進(jìn)行交互, 有些系統(tǒng)性能測(cè)試足根 掘用戶輸入響應(yīng)時(shí)間進(jìn)行的。GUI可以作為腳本工具有開發(fā)環(huán)境中運(yùn)行測(cè)試用 例,其功能包括對(duì)操作的記錄和回放、 抓取屏幕顯示供以后分析和比較、 設(shè)置和 管理測(cè)試過(guò)程 (Rational 公司的 robot 和 Mercury 的 Loadrunner 工具是杰出的 代表)。很多嵌入式設(shè)備沒(méi)有GUI,但常???/p>

22、以對(duì)嵌入式設(shè)備進(jìn)行插裝來(lái)運(yùn)行 GU I 測(cè)試腳本,雖然這種方式可能要求對(duì)被測(cè)代碼進(jìn)行更改,但是節(jié)省了功能測(cè)試 和回歸測(cè)試的時(shí)間。. 自制工具 Home-made tester在嵌入式應(yīng)用中, 有時(shí)候?yàn)榱颂囟ǖ哪康模?需要自行編寫一些工具來(lái)達(dá)到某種測(cè) 試目的。本人曾經(jīng)編寫的視頻流錄顯工具在測(cè)試視頻會(huì)議數(shù)據(jù)流向和變化上幫了 大忙, 幫公司找到了幾個(gè)隱藏很深的 bug。2. 盡早發(fā)現(xiàn)內(nèi)存問(wèn)題內(nèi)存問(wèn)題危害很大,不容易排查,主要有三種類型 : 內(nèi)存泄露、內(nèi)存碎片和 內(nèi)存崩潰。對(duì)于內(nèi)存問(wèn)題態(tài)度必須要明確,那就是早發(fā)現(xiàn)早“治療”。在軟件設(shè) 計(jì)中,內(nèi)存泄露的“名氣”最大,主要由于不斷分配的內(nèi)存無(wú)法及時(shí)地被釋放

23、, 久而久之,系統(tǒng)的內(nèi)存耗盡。即使細(xì)心的編程老手有時(shí)后也會(huì)遭遇內(nèi)存泄露問(wèn)題。 有測(cè)試過(guò)內(nèi)存泄露的朋友估計(jì)都有深刻地體驗(yàn), 那就是內(nèi)存泄露問(wèn)題一般隱藏很 深,很難通過(guò)代碼閱讀來(lái)發(fā)現(xiàn)。 有些內(nèi)存泄露甚至可能出現(xiàn)在庫(kù)當(dāng)中。 有可能這 本身是庫(kù)中的bug,也有可能是因?yàn)槌绦騿T沒(méi)有正確理解它們的接口說(shuō)明文檔造 成錯(cuò)用。在很多時(shí)候,大多數(shù)的內(nèi)存泄露問(wèn)題無(wú)法探測(cè),但可能表現(xiàn)為隨機(jī)的故障。 程序員們往往會(huì)把這種現(xiàn)象怪罪于硬件問(wèn)題。如果用戶對(duì)系統(tǒng)穩(wěn)定性不是很高, 那么重啟系統(tǒng)問(wèn)題也不大;但,如果用戶對(duì)系統(tǒng)穩(wěn)定很高,那么這種故障就有 可能使用戶對(duì)產(chǎn)品失去信心,同時(shí)也意味著你的項(xiàng)目是個(gè)失敗的項(xiàng)目。 由于內(nèi) 存泄露危

24、害巨大, 現(xiàn)在已經(jīng)有許多工具來(lái)解決這個(gè)問(wèn)題。 這些工具通過(guò)查找沒(méi)有 引用或重復(fù)使用的代碼塊、 垃圾內(nèi)存收集、庫(kù)跟蹤等技術(shù)來(lái)發(fā)現(xiàn)內(nèi)存泄露的問(wèn)題。 每個(gè)工具都有利有弊,不過(guò)總的來(lái)說(shuō),用要比不用好??傊?fù)責(zé)的開發(fā)人員應(yīng) 該去測(cè)試內(nèi)存泄露的問(wèn)題,做到防患于未然。內(nèi)存碎片比內(nèi)存泄露隱藏還要深。 隨著內(nèi)存的不斷分配并釋放, 大塊內(nèi)存不 斷分解為小塊內(nèi)存,從而形成碎片,久而久之,當(dāng)需要申請(qǐng)大塊內(nèi)存是,有可能 就會(huì)失敗。 如果系統(tǒng)內(nèi)存夠大, 那么堅(jiān)持的時(shí)間會(huì)長(zhǎng)一些, 但最終還是逃不出分 配失敗的厄運(yùn)。在使用動(dòng)態(tài)分配的系統(tǒng)中,內(nèi)存碎片經(jīng)常發(fā)生。目前,解決這個(gè) 問(wèn)題最效的方法就是使用工具通過(guò)顯示系統(tǒng)中內(nèi)存的使用

25、情況來(lái)發(fā)現(xiàn)誰(shuí)是導(dǎo)致 內(nèi)存碎片的罪魁禍?zhǔn)祝缓蟾倪M(jìn)相應(yīng)的部分。由于動(dòng)態(tài)內(nèi)存管理的種種問(wèn)題,在嵌入式應(yīng)用中,很多公司干脆就禁用 ma lloc/free 的以絕后患。內(nèi)存崩潰是內(nèi)存使用最嚴(yán)重的結(jié)果, 主要原因有數(shù)組訪問(wèn)越界、 寫已經(jīng)釋放 的內(nèi)存、指針計(jì)算錯(cuò)誤、 訪問(wèn)堆棧地址越界等等。 這種內(nèi)存崩潰造成系統(tǒng)故障是 隨機(jī)的,而且很難查找,目前提供用于排查的工具也很少??傊?,如果要使用內(nèi)存管理單元的話, 必須要小心, 并嚴(yán)格遵守它們的使用 規(guī)則,比如誰(shuí)分配誰(shuí)釋放。3. 深入理解代碼優(yōu)化講到系統(tǒng)穩(wěn)定性, 人們更多地會(huì)想到實(shí)時(shí)性和速度, 因?yàn)榇a效率對(duì)嵌入式 系統(tǒng)來(lái)說(shuō)太重要了。知道怎么優(yōu)化代碼是每個(gè)嵌入式軟

26、件開發(fā)人員必須具備的技 能。就象女孩子減肥一樣, 起碼知道她哪個(gè)地方最需要減, 才能去購(gòu)買減肥藥或 器材來(lái)減掉它。 可見(jiàn),代碼優(yōu)化的前提是找到真正需要優(yōu)化的地方, 然后對(duì)癥下 藥,優(yōu)化相應(yīng)部分的代碼。 前面提到的 profile( 性能分析工具, 一些功能齊全 I DE都提供這種內(nèi)置的工具)能夠記錄各種情況比如各個(gè)任務(wù)的 CPI占用率、各個(gè) 任務(wù)的優(yōu)先級(jí)是否分配妥當(dāng)、 某個(gè)數(shù)據(jù)被拷貝了多少次、 訪問(wèn)磁盤多少次、 是否 調(diào)用了網(wǎng)絡(luò)收發(fā)的程序、測(cè)試代碼是否已經(jīng)關(guān)閉等等。但是, profile 工具在分析實(shí)時(shí)系統(tǒng)性能方面還是有不夠的地方。一方面, 人們使用Profile 工具往往是在系統(tǒng)出現(xiàn)問(wèn)題即C

27、PU耗盡之后,而profile 工具 本身對(duì)CPU占用較大,所以Profile 對(duì)這種情況很可能不起作用。根據(jù) Heisenb erg 效應(yīng),任何測(cè)試手段或多或少都會(huì)改變系統(tǒng)運(yùn)行,這個(gè)對(duì) profiler 同樣適 用!總之,提高運(yùn)行效率的前提是你必須要知道 CPU到底干了些什么干的怎么 樣。4.不要讓自己大海撈針大海撈針只是對(duì)調(diào)試的一種生動(dòng)比喻。 經(jīng)常聽到組里有人對(duì)自己正在調(diào)試的代碼說(shuō) shit !可以理解,因?yàn)榇a不 是他寫的,他有足夠的理由去 shit bug 百出的代碼,只要他自己不要寫出這種 代碼,否則有一天同組的其它人可能同樣會(huì) shit 他寫的代碼。 為何會(huì)有大海撈 針呢?肯定是有

28、人把針掉到海里咯; 那針為何會(huì)掉在海里呢?肯定是有人不小心 或草率唄。 所以當(dāng)你在抱怨針那么難找的時(shí)候, 你是否想過(guò)是你自己草率地丟掉 的。同樣,當(dāng)你調(diào)試個(gè)半死的時(shí)候,你是否想過(guò)你要好好反省一下當(dāng)初為了尋 求捷徑可能沒(méi)有嚴(yán)格地遵守好的編碼設(shè)計(jì)規(guī)范、沒(méi)有檢測(cè)一些假設(shè)條件或算法 的正確性、沒(méi)有將一些可能存在問(wèn)題的代碼打上記號(hào)呢? 關(guān)于如何寫高質(zhì)量請(qǐng)參 考林銳的咼質(zhì)量C+/C編程指南或關(guān)于C的0x8本“經(jīng)書”(。如果你確實(shí)已經(jīng)把針掉在海里是, 為了防止在找到之前刺到自己, 你必須要 做一些防范工作,比如戴上安全手套。同樣,為了盡能地暴露和捕捉問(wèn)題根源, 我們可以設(shè)計(jì)比較全面的錯(cuò)誤跟蹤代碼。 怎么來(lái)做

29、呢?盡可能對(duì)每個(gè)函數(shù)調(diào)用失 敗作出處理,盡可能檢測(cè)每個(gè)參數(shù)輸入輸出的有效性包括指針以及檢測(cè)是否過(guò)多 或過(guò)少地調(diào)用某個(gè)過(guò)程。錯(cuò)誤跟蹤能夠讓你知道你大概把針掉在哪個(gè)位置。5.重現(xiàn)并隔離問(wèn)題如果你不是把針掉在大海了, 而是掉在草堆里, 那要好辦寫。 因?yàn)橹辽傥覀?可以把草堆分成很多塊, 一塊一塊的找。 對(duì)于模塊獨(dú)立的大型項(xiàng)目, 使用隔離方 法往往是對(duì)付那些隱藏極深 bug 的最后方法。如果問(wèn)題的出現(xiàn)是間歇性的 , 我們 有必要設(shè)法去重現(xiàn)它并記錄使其重現(xiàn)的整個(gè)過(guò)程以備在下一次可以利用這些條 件去重現(xiàn)問(wèn)題。 如果你確信可以使用記錄的那些條件去重現(xiàn)問(wèn)題, 那么我們就可 以著手去隔離問(wèn)題。 怎么隔離呢?我們

30、可以用 #ifdef 把一些可能和問(wèn)題無(wú)關(guān)的 代碼關(guān)閉,把系統(tǒng)最小化到仍能夠重現(xiàn)問(wèn)題的地步。 如果還是無(wú)法定位問(wèn)題所在, 那么有必要打開“工具箱” 了。可以試著用ICE或數(shù)據(jù)監(jiān)視器去查看某個(gè)可疑變 量的變化;可以使用跟蹤工具獲得函數(shù)調(diào)用的情況包括參數(shù)的傳遞; 檢查內(nèi)存是 否崩潰以及堆棧溢出的問(wèn)題。6.以退為進(jìn)獵人為了不使自己在森林里迷路,他常常會(huì)在樹木上流下一些標(biāo)記,以備 自己將來(lái)有一天迷路時(shí)可以根據(jù)這些標(biāo)記找到出路。 對(duì)過(guò)去代碼的修改進(jìn)行跟蹤 記錄對(duì)將來(lái)出現(xiàn)問(wèn)題之后的調(diào)試很有幫助。 假如有一天, 你最近一次修改的程序 跑了很久之后忽然死掉了,那么你這時(shí)的第一反映就是我到底改動(dòng)了些什么呢, 因?yàn)樯洗涡薷闹笆呛玫摹?那么如何檢測(cè)這次相對(duì)于上次的修改呢?沒(méi)錯(cuò), 代碼 控制系統(tǒng) SCS或稱版本控制系統(tǒng) VCS(Concurrent Version Control,CVS是 VCS的演化版本 ) 。將上個(gè)版本 check in 下來(lái)后和當(dāng)前測(cè)試版本比較。 比較的工具可 以是SCS/VCS/CV自帶的diff 工具或其它功能更強(qiáng)的比較工具, 比如BeyondCo mpare和ExamDiff。通過(guò)

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

評(píng)論

0/150

提交評(píng)論