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