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