在嵌入式軟件開發(fā)過程中,一般來說,花在測(cè)試和花在編碼的時(shí)間比為3:1(實(shí)際上可能更多)。這個(gè)比例隨著你的編程和測(cè)試水平的提高而不斷下降,但不論怎樣,軟件測(cè)試對(duì)一般人來講很重要。很多年前,一位開發(fā)人員為了對(duì)嵌入式有更深層次的理解,向Oracle詢問了這樣的一個(gè)問題:我怎么才能知道并懂得我的系統(tǒng)到底在干些什么呢?Oracle面對(duì)這個(gè)問題有些吃驚,因?yàn)樵诋?dāng)時(shí)沒有人這么問過,而同時(shí)代的嵌入式開發(fā)人員問的最多的大都圍繞“我怎么才能使程序跑的更快”、“什么編譯器最好”等膚淺的問題。所以,面對(duì)這個(gè)不同尋常卻異乎成熟的問題,Oracle感到欣喜并認(rèn)真回復(fù)了他:你的問題很有深度很成熟,因?yàn)橹挥胁粩嗟厝ド钊肜斫獠庞锌赡懿粩嗟靥岣咚剑⑶襉racle為了鼓勵(lì)這位執(zhí)著的程序員,把10條關(guān)于嵌入式軟件開發(fā)測(cè)試的秘訣告訴了他:
1.懂得使用工具
2.盡早發(fā)現(xiàn)內(nèi)存問題
3.深入理解代碼優(yōu)化
4.不要讓自己大海撈針
5.重現(xià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ǐng)域使用軟件和微處理器控制各種嵌入式設(shè)備,對(duì)門益復(fù)雜的嵌入式軟件進(jìn)行快速有效的測(cè)試愈加顯得重要。
就象修車需要工具一樣,好的程序員應(yīng)該能夠熟練運(yùn)用各種軟件工具。不同的工具,有不同的使用范圍,有不同的功能。使用這些工具,你可以看到你的系統(tǒng)在干些什么,它又占用什么資源,它到底和哪些外界的東西打交道。讓你郁悶好幾天的問題可能通過某個(gè)工具就能輕松搞定,可惜你就是不知道。那么為什么那么多的人總是在折騰個(gè)半死之后才想到要用測(cè)試工具呢?原因很多,主要有兩個(gè)。一個(gè)是害怕,另一個(gè)是惰性。害怕是因?yàn)榧尤霚y(cè)試用具或測(cè)試模塊到代碼需要技巧同時(shí)有可能引入新的錯(cuò)誤,所以他們總喜歡寄希望于通過不斷地修改重編譯代碼來消除bug,結(jié)果卻無濟(jì)于事。懶惰是因?yàn)樗麄兞?xí)慣了使用printf之類的簡(jiǎn)單測(cè)試手段。下面來介紹一些嵌入式常用的測(cè)試工具。
.源碼級(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í)用的打印顯示工具[printf]
printf或其它類似的打印顯示工具估計(jì)是最靈活最簡(jiǎn)單的調(diào)試工具。打印代碼執(zhí)行過程中的各種變量可以讓你知道代碼執(zhí)行的情況。但是,printf對(duì)正常的代碼執(zhí)行干擾比較大(一般printf占用CPU比較長(zhǎng)的時(shí)間),需要慎重使用,最好設(shè)置打印開關(guān)來控制打印。
.ICE或JTAG調(diào)試器[In-circuit Emulator]
ICE是用來仿真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,并且通過特殊的連接,可以訪問到CPU的內(nèi)部信號(hào),而這些信號(hào),在CPU被封裝時(shí),是沒法“看到”的。當(dāng)和工作站上強(qiáng)大的調(diào)試軟件聯(lián)合使用時(shí),ICE就能提供你所能找到的最全面的調(diào)試功能。但I(xiàn)CE同樣有一些缺點(diǎn):昂貴;不能全速工作;同樣,并不是所有的CPU都可以作為外合CPU的,從另一個(gè)角度說,這些外合CPU也不大可能及時(shí)的被新出的CPU所更換。JTAG(Joint Test Action Group)雖然它最初開發(fā)出來是為了監(jiān)測(cè)IC和電路連接,但是這種串行接口擴(kuò)展了用途,包括對(duì)調(diào)試的支持。AD公司為Blackfin設(shè)計(jì)的Visual Dsp++就支持高速的JTAG調(diào)試。
.ROM監(jiān)視器[ROM Monitor]
ROM監(jiān)控器是一小程序,駐留在嵌入系統(tǒng)ROM中,通過串行的或網(wǎng)絡(luò)的連接和運(yùn)行在工作站上的調(diào)試軟件通信。這是一種便宜的方式,當(dāng)然也是最低端的技術(shù)。它除了要求一個(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è)變量的變化過程。
.OS監(jiān)視器[Operating System Monitor]
操作系統(tǒng)監(jiān)視器可以顯示諸如任務(wù)切換、信號(hào)量收發(fā)、中斷等事件。一方面,這些監(jiān)視器能夠?yàn)槟愠尸F(xiàn)事件之間的關(guān)系和時(shí)間聯(lián)系;另一方面,還可以提供對(duì)信號(hào)量?jī)?yōu)先級(jí)反轉(zhuǎn)、死鎖和中斷延時(shí)等問題的診斷。
.性能分析工具[Profiler]
可以用來測(cè)試CPU到底耗在那里。profiler工具可以讓你知道系統(tǒng)的瓶頸在那里、CPU的使用率以及需要優(yōu)化的地方。
.內(nèi)存測(cè)試工具[Memory Teseter]
可以找到內(nèi)存使用的問題所在,比如內(nèi)存泄露、內(nèi)存碎片、內(nèi)存崩潰等問題。如果發(fā)現(xiàn)系統(tǒng)出現(xiàn)一些不可預(yù)知的或間歇性的問題,就應(yīng)該使用內(nèi)存測(cè)試工具測(cè)測(cè)看。
.運(yùn)行跟蹤器[Execution Tracer]
可以顯示CPU執(zhí)行了哪些函數(shù)、誰在調(diào)用、參數(shù)是什么、何時(shí)調(diào)用等情況。這種工具主要用于測(cè)試代碼邏輯,可以在大量的事件中發(fā)現(xiàn)異常的那些。
.覆蓋工具[Coverage Tester]
主要顯示CPU具體執(zhí)行了那些代碼,并讓你知道那些代碼分支沒有被執(zhí)行到。這樣有助于提高代碼質(zhì)量并消除無用代碼。
.GUI測(cè)試工具[GUI Tester]
很多嵌入式應(yīng)用帶有某種形式的圖形用戶界面進(jìn)行交互,有些系統(tǒng)性能測(cè)試足根掘用戶輸入響應(yīng)時(shí)間進(jìn)行的。GUI測(cè)試工具可以作為腳本工具有開發(fā)環(huán)境中運(yùn)行測(cè)試用例,其功能包括對(duì)操作的記錄和回放、抓取屏幕顯示供以后分析和比較、設(shè)置和管理測(cè)試過程(Rational公司的robot和Mercury的Loadrunner工具是杰出的代表)。很多嵌入式設(shè)備沒有GUI,但常常可以對(duì)嵌入式設(shè)備進(jìn)行插裝來運(yùn)行GUI測(cè)試腳本,雖然這種方式可能要求對(duì)被測(cè)代碼進(jìn)行更改,但是節(jié)省了功能測(cè)試和回歸測(cè)試的時(shí)間。
.自制工具[Home-made tester]
在嵌入式應(yīng)用中,有時(shí)候?yàn)榱颂囟ǖ哪康模枰孕芯帉懸恍┕ぞ邅磉_(dá)到某種測(cè)試目的。本人曾經(jīng)編寫的視頻流錄顯工具在測(cè)試視頻會(huì)議數(shù)據(jù)流向和變化上幫了大忙,幫公司找到了幾個(gè)隱藏很深的bug。
2.盡早發(fā)現(xiàn)內(nèi)存問題
內(nèi)存問題危害很大,不容易排查,主要有三種類型:內(nèi)存泄露、內(nèi)存碎片和內(nèi)存崩潰。對(duì)于內(nèi)存問題態(tài)度必須要明確,那就是早發(fā)現(xiàn)早“治療”。在軟件設(shè)計(jì)中,內(nèi)存泄露的“名氣”最大,主要由于不斷分配的內(nèi)存無法及時(shí)地被釋放,久而久之,系統(tǒng)的內(nèi)存耗盡。即使細(xì)心的編程老手有時(shí)后也會(huì)遭遇內(nèi)存泄露問題。有測(cè)試過內(nèi)存泄露的朋友估計(jì)都有深刻地體驗(yàn),那就是內(nèi)存泄露問題一般隱藏很深,很難通過代碼閱讀來發(fā)現(xiàn)。有些內(nèi)存泄露甚至可能出現(xiàn)在庫當(dāng)中。有可能這本身是庫中的bug,也有可能是因?yàn)槌绦騿T沒有正確理解它們的接口說明文檔造成錯(cuò)用。
在很多時(shí)候,大多數(shù)的內(nèi)存泄露問題無法探測(cè),但可能表現(xiàn)為隨機(jī)的故障。程序員們往往會(huì)把這種現(xiàn)象怪罪于硬件問題。如果用戶對(duì)系統(tǒng)穩(wěn)定性不是很高,那么重啟系統(tǒng)問題也不大;但,如果用戶對(duì)系統(tǒng)穩(wěn)定很高,那么這種故障就有可能使用戶對(duì)產(chǎn)品失去信心,同時(shí)也意味著你的項(xiàng)目是個(gè)失敗的項(xiàng)目。由于內(nèi)存泄露危害巨大,現(xiàn)在已經(jīng)有許多工具來解決這個(gè)問題。這些工具通過查找沒有引用或重復(fù)使用的代碼塊、垃圾內(nèi)存收集、庫跟蹤等技術(shù)來發(fā)現(xiàn)內(nèi)存泄露的問題。每個(gè)工具都有利有弊,不過總的來說,用要比不用好。總之,負(fù)責(zé)的開發(fā)人員應(yīng)該去測(cè)試內(nèi)存泄露的問題,做到防患于未然。
內(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è)問題最效的方法就是使用工具通過顯示系統(tǒng)中內(nèi)存的使用情況來發(fā)現(xiàn)誰是導(dǎo)致內(nèi)存碎片的罪魁禍?zhǔn)祝缓蟾倪M(jìn)相應(yīng)的部分。
由于動(dòng)態(tài)內(nèi)存管理的種種問題,在嵌入式應(yīng)用中,很多公司干脆就禁用malloc/free的以絕后患。
內(nèi)存崩潰是內(nèi)存使用最嚴(yán)重的結(jié)果,主要原因有數(shù)組訪問越界、寫已經(jīng)釋放的內(nèi)存、指針計(jì)算錯(cuò)誤、訪問堆棧地址越界等等。這種內(nèi)存崩潰造成系統(tǒng)故障是隨機(jī)的,而且很難查找,目前提供用于排查的工具也很少。
總之,如果要使用內(nèi)存管理單元的話,必須要小心,并嚴(yán)格遵守它們的使用規(guī)則,比如誰分配誰釋放。
3.深入理解代碼優(yōu)化
講到系統(tǒng)穩(wěn)定性,人們更多地會(huì)想到實(shí)時(shí)性和速度,因?yàn)榇a效率對(duì)嵌入式系統(tǒng)來說太重要了。知道怎么優(yōu)化代碼是每個(gè)嵌入式軟件開發(fā)人員必須具備的技能。就象女孩子減肥一樣,起碼知道她哪個(gè)地方最需要減,才能去購買減肥藥或器材來減掉它。可見,代碼優(yōu)化的前提是找到真正需要優(yōu)化的地方,然后對(duì)癥下藥,優(yōu)化相應(yīng)部分的代碼。前面提到的profile(性能分析工具,一些功能齊全I(xiàn)DE都提供這種內(nèi)置的工具)能夠記錄各種情況比如各個(gè)任務(wù)的CPU占用率、各個(gè)任務(wù)的優(yōu)先級(jí)是否分配妥當(dāng)、某個(gè)數(shù)據(jù)被拷貝了多少次、訪問磁盤多少次、是否調(diào)用了網(wǎng)絡(luò)收發(fā)的程序、測(cè)試代碼是否已經(jīng)關(guān)閉等等。
但是,profile工具在分析實(shí)時(shí)系統(tǒng)性能方面還是有不夠的地方。一方面,人們使用profile工具往往是在系統(tǒng)出現(xiàn)問題即CPU耗盡之后,而profile工具本身對(duì)CPU占用較大,所以profile對(duì)這種情況很可能不起作用。根據(jù)Heisenberg效應(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)試的代碼說shit!可以理解,因?yàn)榇a不是他寫的,他有足夠的理由去shit bug百出的代碼,只要他自己不要寫出這種代碼,否則有一天同組的其它人可能同樣會(huì)shit他寫的代碼。為何會(huì)有大海撈針呢?肯定是有人把針掉到海里咯;那針為何會(huì)掉在海里呢?肯定是有人不小心或草率唄。所以當(dāng)你在抱怨針那么難找的時(shí)候,你是否想過是你自己草率地丟掉的。同樣,當(dāng)你調(diào)試個(gè)半死的時(shí)候,你是否想過你要好好反省一下當(dāng)初為了尋求捷徑可能沒有嚴(yán)格地遵守好的編碼設(shè)計(jì)規(guī)范、沒有檢測(cè)一些假設(shè)條件或算法的正確性、沒有將一些可能存在問題的代碼打上記號(hào)呢?關(guān)于如何寫高質(zhì)量請(qǐng)參考林銳的《高質(zhì)量c++/c編程指南》或《關(guān)于C的0x8本“經(jīng)書”》。
如果你確實(shí)已經(jīng)把針掉在海里是,為了防止在找到之前刺到自己,你必須要做一些防范工作,比如戴上安全手套。同樣,為了盡能地暴露和捕捉問題根源,我們可以設(shè)計(jì)比較全面的錯(cuò)誤跟蹤代碼。怎么來做呢?盡可能對(duì)每個(gè)函數(shù)調(diào)用失敗作出處理,盡可能檢測(cè)每個(gè)參數(shù)輸入輸出的有效性包括指針以及檢測(cè)是否過多或過少地調(diào)用某個(gè)過程。錯(cuò)誤跟蹤能夠讓你知道你大概把針掉在哪個(gè)位置。
5.重現(xiàn)并隔離問題
如果你不是把針掉在大海了,而是掉在草堆里,那要好辦寫。因?yàn)橹辽傥覀兛梢园巡荻逊殖珊芏鄩K,一塊一塊的找。對(duì)于模塊獨(dú)立的大型項(xiàng)目,使用隔離方法往往是對(duì)付那些隱藏極深bug的最后方法。如果問題的出現(xiàn)是間歇性的,我們有必要設(shè)法去重現(xiàn)它并記錄使其重現(xiàn)的整個(gè)過程以備在下一次可以利用這些條件去重現(xiàn)問題。如果你確信可以使用記錄的那些條件去重現(xiàn)問題,那么我們就可以著手去隔離問題。怎么隔離呢?我們可以用#ifdef把一些可能和問題無關(guān)的代碼關(guān)閉,把系統(tǒng)最小化到仍能夠重現(xiàn)問題的地步。如果還是無法定位問題所在,那么有必要打開“工具箱”了。可以試著用ICE或數(shù)據(jù)監(jiān)視器去查看某個(gè)可疑變量的變化;可以使用跟蹤工具獲得函數(shù)調(diào)用的情況包括參數(shù)的傳遞;檢查內(nèi)存是否崩潰以及堆棧溢出的問題。
6.以退為進(jìn)
獵人為了不使自己在森林里迷路,他常常會(huì)在樹木上流下一些標(biāo)記,以備自己將來有一天迷路時(shí)可以根據(jù)這些標(biāo)記找到出路。對(duì)過去代碼的修改進(jìn)行跟蹤記錄對(duì)將來出現(xiàn)問題之后的調(diào)試很有幫助。假如有一天,你最近一次修改的程序跑了很久之后忽然死掉了,那么你這時(shí)的第一反映就是我到底改動(dòng)了些什么呢,因?yàn)樯洗涡薷闹笆呛玫摹D敲慈绾螜z測(cè)這次相對(duì)于上次的修改呢?沒錯(cuò),代碼控制系統(tǒng)SCS或稱版本控制系統(tǒng)VCS(Concurrent Version Control,CVS是VCS的演化版本)。將上個(gè)版本check in下來后和當(dāng)前測(cè)試版本比較。比較的工具可以是SCS/VCS/CVS自帶的diff工具或其它功能更強(qiáng)的比較工具,比如BeyondCompare和ExamDiff。通過比較,記錄所有改動(dòng)的代碼,分析所有可能導(dǎo)致問題的可疑代碼。
7.確定測(cè)試的完整性
你怎么知道你的測(cè)試有多全面呢?覆蓋測(cè)試(coverage testing)可以回答這個(gè)問題。覆蓋測(cè)試工具可以告訴你CPU到底執(zhí)行了那些代碼。好的覆蓋工具通常可以告訴你大概20%到40%代碼沒有問題,而其余的可能存在bug。覆蓋工具有不同的測(cè)試級(jí)別,用戶可以根據(jù)自己的需要選擇某個(gè)級(jí)別。即使你很確信你的單元測(cè)試已經(jīng)很全面并且沒有dead code,覆蓋工具還是可以為你指出一些潛在的問題,看下面的代碼:
if (i >= 0 && (almostAlwaysZero == 0 || (last = i)))
如果almostAlwaysZero為非0,那么last="i"賦值語句就被跳過,這可能不是你所期望的。這種問題通過覆蓋工具的條件測(cè)試功能可以輕松的被發(fā)現(xiàn)。
總之,覆蓋測(cè)試對(duì)于提高代碼質(zhì)量很有幫助。
8.提高代碼質(zhì)量意味著節(jié)省時(shí)間
有研究表明軟件開發(fā)的時(shí)間超過80%被用在下面幾個(gè)方面:
.調(diào)試自己的代碼(單元測(cè)試)
.調(diào)試自己和其他相關(guān)的代碼(模塊間測(cè)試)
.調(diào)試整個(gè)系統(tǒng)(系統(tǒng)測(cè)試)
更糟糕的是你可能需要花費(fèi)10-200倍的時(shí)間來找一個(gè)bug,而這個(gè)bug在開始的時(shí)候可能很容易就能找到。一個(gè)小bug可能讓你付出巨大的代價(jià),即使這個(gè)bug對(duì)整個(gè)系統(tǒng)的性能沒有太大的影響,但很可能會(huì)影響讓那些你可以看得到的部分。所以我們必須要養(yǎng)成良好的編碼和測(cè)試手段以求更高的代碼質(zhì)量,以便縮短調(diào)試的代碼。
9.發(fā)現(xiàn)它,分析它,解決它
這世界沒有萬能的膏藥。profile再強(qiáng)大也有力不從心的時(shí)候;內(nèi)存監(jiān)視器再好,也有無法發(fā)現(xiàn)的時(shí)候;覆蓋工具再好用,也有不能覆蓋的地方。一些隱藏很深的問題即使用盡所有工具也有可能無法查到其根源,這時(shí)我們能做的就是通過這些問題所表現(xiàn)出來的外在現(xiàn)象或一些數(shù)據(jù)輸出來發(fā)現(xiàn)其中的規(guī)律或異常。一旦發(fā)現(xiàn)任何異常,一定要深入地理解并回溯其根源,直到解決為止。
10.利用初學(xué)者的思維
有人這樣說過:“有些事情在初學(xué)者的腦子里可能有各種各樣的情況,可在專家的頭腦里可能就很單一”。有時(shí)候,有些簡(jiǎn)單的問題會(huì)被想的很復(fù)雜,有些簡(jiǎn)單的系統(tǒng)別設(shè)計(jì)的很復(fù)雜,就是由于你的“專家思維”。當(dāng)你被問題難住時(shí),關(guān)掉電腦,出去走走,把你的問題和你的朋友甚至你的小狗說說,或許他們可以給你意想不到的啟發(fā)。
總結(jié):嵌入式調(diào)試也是一門藝術(shù)。就想其它的藝術(shù)一樣,如果你想取得成功,你必須具備智慧、經(jīng)驗(yàn)并懂得使用工具。只要我們能夠很好地領(lǐng)悟Oracle這十條秘訣,我相信我們?cè)谇度胧綔y(cè)試方面就能夠取得成功。
-
嵌入式
+關(guān)注
關(guān)注
5082文章
19104瀏覽量
304829 -
甲骨文
+關(guān)注
關(guān)注
0文章
113瀏覽量
16128
原文標(biāo)題:Oracle的嵌入式軟件測(cè)試的十大秘籍!
文章出處:【微信號(hào):mcuworld,微信公眾號(hào):嵌入式資訊精選】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論