從70年代末的簡(jiǎn)單控制發(fā)展到今天的高端應(yīng)用,嵌入式系統(tǒng)已經(jīng)變成一個(gè)復(fù)雜的高技術(shù)系統(tǒng),要在短時(shí)間開發(fā)出所需功能的難度大大提升,但是市場(chǎng)競(jìng)爭(zhēng)又要求產(chǎn)品能夠快速面市同時(shí)必須確保產(chǎn)品的質(zhì)量和性能,這里面工具就起著很重要的作用。這其中,對(duì)工具的仿真功能更很高的要求。如何幫助工程師完成系統(tǒng)設(shè)計(jì),成功地實(shí)現(xiàn)讓多種內(nèi)核在同一個(gè)系統(tǒng)中的協(xié)同工作是嵌入式系統(tǒng)工具必須達(dá)到的目標(biāo)。可以說,是嵌入式開發(fā)工具在幫助實(shí)現(xiàn)應(yīng)用。當(dāng)然,反過來,嵌入式應(yīng)用的發(fā)展也在推動(dòng)著工具的發(fā)展。 目 前應(yīng)用市場(chǎng)最大、最快的變化就是有越來越多的工程師從4位和8位設(shè)計(jì)轉(zhuǎn)向了32位設(shè)計(jì)。對(duì)于他們來說,是否有便利的工具幫助他們實(shí)現(xiàn)這種無縫轉(zhuǎn)變將是非常 重要的。這就需要工具供應(yīng)商提供具有這些工程師所熟悉的界面和接口的工具,此外,在32位開發(fā)中一般都會(huì)用到SDRAM,工具對(duì)多種閃存編程的支持也就變 得非常重要。在8位MCU市場(chǎng)上有很多不同供應(yīng)商提供的產(chǎn)品,在32位市場(chǎng)中也有很多公司提供基于ARM的產(chǎn)品,工具是否能夠支持這些來自不同供應(yīng)商的產(chǎn) 品也很重要。例如旋極公司的TRACE-ICP支持AMD、ATMEL、 FREESCALE、 FUJISTU、 HYNIX、INFINEON、INTEL 、MACRONIX、MICRON、NEC、PHILIPS、SAMSUNG、SHARP、SST、ST、TOSHIBA、WINBOND…等供應(yīng)商基于 ARM處理器的在線FLASH在線編程、TRACE-ICP支持操作系統(tǒng)調(diào)試如:ECOS、 Linux、 Nucleus、 OSE、 pSOS、 QNX、symbian、uclinux、 uC/OS-II、 VxWorks、 WinCE 等。 縱觀開發(fā)工具領(lǐng)域,目 前越來越多的嵌入式系統(tǒng)軟件供應(yīng)商推出個(gè)性化的開發(fā)工具套件,但是它們來自不同的供應(yīng)商,從而導(dǎo)致在通用性支持方面不夠好,未來在這方面還需要工具提供商 的共同努力。除提供標(biāo)準(zhǔn)的編譯器、編輯器、調(diào)試器,還提供增強(qiáng)的操作系統(tǒng)內(nèi)核級(jí)調(diào)試手段和高級(jí)的系統(tǒng)分析工具,如內(nèi)存泄漏檢測(cè)、實(shí)時(shí)追蹤代碼的運(yùn)行等。在 我們對(duì)眾多客戶了解其需求及期望值來看,嵌入式開發(fā)工具將向高度集成、編譯優(yōu)化、具有系統(tǒng)設(shè)計(jì)、可視化建模、仿真和驗(yàn)證功能方向發(fā)展! 目前有很多工程師在設(shè)計(jì)嵌入式系統(tǒng)的時(shí)候往往選擇最底層的工具,把絕大部分的時(shí)間都花在了底層的細(xì)節(jié),而往往忽視了創(chuàng)新性和系統(tǒng)級(jí)的把握。工程師無論是為了自身的發(fā)展還是為了所設(shè)計(jì)產(chǎn)品的競(jìng)爭(zhēng)力,這兩點(diǎn)其實(shí)都是至關(guān)重要的。 嵌入式系統(tǒng)的開發(fā)通常是硬件和軟件同時(shí)進(jìn)行的,其在開發(fā)過程中出現(xiàn)不良狀況的原因有可能是硬件或是軟件,有時(shí)甚至可能是兩者同時(shí)發(fā)生故障。在這樣的狀況下,就要求從事硬件的技術(shù)人員要相當(dāng)程度的懂得軟件,從事軟件的技術(shù)開發(fā)人員也要在一定程度上懂得硬件。 目
前該行業(yè)存在最終產(chǎn)品的壽命縮短的趨勢(shì),這就意味著每年都有必要開發(fā)新的產(chǎn)品。但是從初級(jí)階段進(jìn)行開發(fā),需要花費(fèi)大量的開發(fā)成本及開發(fā)時(shí)間。因此,有效地
歸納總結(jié)現(xiàn)有的開發(fā)成果,并有效地投入新開發(fā)中加以利用是十分重要的。例如,為了讓源代碼、電路圖等可以直接投入利用,通俗易懂地進(jìn)行注釋是其中 另外我想談?wù)勡浖䴗y(cè)試的質(zhì)量和軟件測(cè)試的一些策略!下面我來舉幾個(gè)例子來說明軟件測(cè)試的其重要性! 1998 年 4 月,美國(guó)的一個(gè)重要的數(shù)據(jù)通訊網(wǎng)絡(luò)出現(xiàn)了長(zhǎng)達(dá) 24 小時(shí)的故障,使大部分美國(guó)的信用卡管理系統(tǒng)交易受到影響。受到影響 1999
年 10 月,耗資 1.25 億美元的 NASA
的火星氣象衛(wèi)星失蹤,據(jù)信這是由于簡(jiǎn)單的數(shù)據(jù)轉(zhuǎn)換錯(cuò)誤所導(dǎo)致的。人們發(fā)現(xiàn)衛(wèi)星軟件中,有些數(shù)據(jù)使用英制,它們應(yīng)被轉(zhuǎn)換成公制。這個(gè)衛(wèi)星應(yīng)當(dāng)充當(dāng)另一項(xiàng)任務(wù)
中的火星極地著陸項(xiàng)目的通信轉(zhuǎn)發(fā)器,那個(gè)任務(wù)也失敗了,原 下面是2002年的歐洲阿麗亞娜5火箭的第一次鑒定發(fā)射失敗例子; double d_bh; short s_bh; sense_horizontal_velocity(&d_bh); s_bh = d_bh; // OPERAND ERROR 隨 著軟件測(cè)試在龐大軟件系統(tǒng)中發(fā)揮的作用日益重要,早在60年代軟件危機(jī)初期,人們就認(rèn)識(shí)到了軟件復(fù)雜度高,開發(fā)周期長(zhǎng),可靠性差,開發(fā)和維護(hù)費(fèi)用大等問 題。其中可靠性差就是軟件質(zhì)量問題的集中表現(xiàn),而軟件質(zhì)量差又是軟件維護(hù)費(fèi)用大的主要因素之一。近年來,隨著計(jì)算機(jī)應(yīng)用領(lǐng)域的迅速擴(kuò)大,人們對(duì)軟件質(zhì)量提 出了新的、更高的要求。在航空應(yīng)用領(lǐng)域中,軟件質(zhì)量往往關(guān)系到人的生命安危。這類稱為安全性第一的軟件具有高質(zhì)量要求、高復(fù)雜度、高開發(fā)代價(jià)的特征。其 中,許多安全性第一的軟件是實(shí)時(shí)和嵌入式系統(tǒng)。 軟件開發(fā)模式以V模型和瀑布模型為主,在這兩種開發(fā)模型中,軟件測(cè)試一般分為:?jiǎn)卧獪y(cè)試,配置項(xiàng)測(cè)試和系統(tǒng)測(cè)試。單元測(cè)試是開 下面介紹一些測(cè)試方法:(如有不對(duì)之處請(qǐng)大家多多指教,) 靜態(tài)分析很重要 Watts S. Humphrey的說法 靜態(tài)分析的重要內(nèi)容——代碼規(guī)則檢查 動(dòng)態(tài)測(cè)試不可少 動(dòng)態(tài)測(cè)試是驗(yàn)證軟件功能最直接、最有效的手段 通過運(yùn)行被測(cè)程序驗(yàn)證其功能、性能,檢查代碼的執(zhí)行情況 與靜態(tài)分析相輔相成 需要事先設(shè)計(jì)詳細(xì)、完備的測(cè)試用例 可用白盒、黑盒等方法 工作量較大、較枯燥 動(dòng)態(tài)測(cè)試的主要內(nèi)容 功能、性能驗(yàn)證,是否符合需求定義 代碼覆蓋。哪些代碼執(zhí)行了,哪些沒有執(zhí)行,其比例如何 白盒黑盒相輔成 白盒測(cè)試與黑盒測(cè)試是軟件測(cè)試最常用、最常規(guī)的兩種技術(shù) 白盒測(cè)試 把測(cè)試對(duì)象看作一個(gè)透明的盒子,測(cè)試人員從其邏輯結(jié)構(gòu)入手,設(shè)計(jì)和選擇測(cè)試用例,對(duì)路徑、控制結(jié)構(gòu)、數(shù)據(jù)流等進(jìn)行測(cè)試 通過插裝檢查程序的狀態(tài),確定是否與預(yù)期的狀態(tài)一致 側(cè)重于代碼運(yùn)行的過程 靜態(tài)分析也是一種白盒測(cè)試 黑盒測(cè)試 把測(cè)試對(duì)象看做一個(gè)黑盒子,測(cè)試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu),只依據(jù)其需求定義,檢查程序運(yùn)行的結(jié)果 多用于功能測(cè)試和性能分析 在程序的接口上進(jìn)行 需要設(shè)計(jì)“驅(qū)動(dòng)”和“打樁” 單元集成兩步走 單元測(cè)試和集成測(cè)試是軟件測(cè)試的兩個(gè)階段 單元測(cè)試 將被測(cè)軟件分解為單元,逐個(gè)測(cè)試 單元測(cè)試需要從程序的內(nèi)部結(jié)構(gòu)和功能出發(fā)設(shè)計(jì)測(cè)試用例。 多個(gè)模塊可以平行地獨(dú)立進(jìn)行單元測(cè)試 可用白盒、黑盒等方法 集成測(cè)試 在單元測(cè)試的基礎(chǔ)上,將所有模塊按照設(shè)計(jì)要求組裝起來測(cè)試 主要測(cè)試內(nèi)容 接口間參數(shù)傳遞 集成的功能實(shí)現(xiàn) 模塊間的影響 先靜后動(dòng),從小到大 先靜態(tài),后動(dòng)態(tài) 從代碼規(guī)則檢查做起 測(cè)試開展得越早,付出的代價(jià)就越小 靜態(tài)分析簡(jiǎn)單、方便,成本低、見效快 靜態(tài)分析為動(dòng)態(tài)測(cè)試打下良好基礎(chǔ) 大大降低了測(cè)試的成本 先單元,后集成 單元測(cè)試是集成測(cè)試的基礎(chǔ) 單元測(cè)試得越好,集成測(cè)試的工作量就越小 另外我想重點(diǎn)介紹一下靜態(tài)規(guī)范檢查工具! 如 果軟件企業(yè)都能在代碼編寫的階段都能遵循一定的代碼規(guī)則,這對(duì)我們的軟件產(chǎn)品的質(zhì)量將回大有益處,首先,在同一個(gè)開發(fā)團(tuán)隊(duì)中使用代碼規(guī)則,可以形成這個(gè)開 發(fā)團(tuán)隊(duì)統(tǒng)一的開發(fā)風(fēng)格,產(chǎn)品個(gè)性;其次,遵循一定的代碼規(guī)則,可以提高模塊的可移植性和可維護(hù)性,最后,代碼規(guī)則檢查也是提高代碼質(zhì)量最有效、最直接的手 段。 目前編碼規(guī)則檢查目前存在的問題是: 1)代碼規(guī)則檢查需要付出很繁重的勞動(dòng)——重新理解代碼,國(guó)內(nèi)一些軟件工程發(fā)展到現(xiàn)在,已經(jīng)有了專職的測(cè)試人員,即使非常專業(yè)的測(cè)試人員,理解別人寫的代碼也是一項(xiàng)很繁瑣的工作。 2)時(shí)間和資源的限制,我們說,任何一個(gè)企業(yè)都可以做出優(yōu)秀的軟件,前提是給他足夠的時(shí)間和物質(zhì)資源,可現(xiàn)實(shí)的軟件開發(fā)的矛盾卻是:在有限的時(shí)間內(nèi)、利用有限的經(jīng)費(fèi),來做高可靠性的軟件。 3)很多人不重視代碼規(guī)則檢查,包括很多軟件企業(yè)的領(lǐng)導(dǎo)、項(xiàng)目負(fù)責(zé)人等,認(rèn)為代碼規(guī)則檢查浪費(fèi)人力和物力,恰恰相反,這種觀點(diǎn)就把軟件中存在的問題留到了最后,在軟件維護(hù)過程中會(huì)付出昂貴的代價(jià)。經(jīng)驗(yàn)表明,軟件中的問題發(fā)現(xiàn)的越早,要克服這個(gè)問題付出的代價(jià)越小 。 國(guó) 內(nèi)的軍工行業(yè)(包括軍隊(duì)、航天、航空、船舶、兵器)目前也意識(shí)到在軟件開發(fā)中實(shí)施代碼規(guī)則檢查的重要性,有些單位已經(jīng)購(gòu)置并且搭建了一些代碼規(guī)則的統(tǒng)一檢 查平臺(tái),如航天三院、五院統(tǒng)購(gòu)了QAC工具,并參照GJB5369定制了適合本系統(tǒng)的代碼規(guī)則院標(biāo),推廣到所下屬各個(gè)研究所中。 隨著軍工行業(yè)軟件開發(fā)管理水平的提高,和GJB5000的推廣和實(shí)施,推廣和實(shí)施代碼規(guī)則檢查是刻不容緩的,是必然的趨勢(shì)。 作者簡(jiǎn)介 慕容嫣然,某商學(xué)院畢業(yè),現(xiàn)供職于某嵌入式企業(yè),從事2年以上嵌入式工具開發(fā)與推廣。 |