美女看嵌入式工具市場的發展

我想緊接著上一篇就嵌入式軟件測試的現狀談一下，首先從中國的國情來說，當國外的研發人員為自己沒有把軟件缺陷降到最低而苦悶的時候，我們的研發人員則還是為了溫飽而苦悶，為什么國內很多研發人員到35歲左右他們就想轉行或投身于銷售或轉做管理，難道是因為他們已經做不了研發，因為公司沒有給他們職業規劃，他們找不到自己的晉升機會，因為到了這個年齡生活已經不是一個人的事情了，由此導致我們國內IT技術人員放棄多年的研發經驗投身于別的產業，這難道不是技術人才的浪費嗎？

讓我們再看看軟件行業的的研發人員和軟件測試人員的人員配置比例，據調查國外軟件行業的比例是1：1或1：3，在國內的實際比例是10：1，就工資而言國內的測試人員的工資比研發人員的還低，所以測試人員和開發人員面臨同樣的問題就是技術熟練的時候轉行。測試之所以產生是因為研發不能夠把軟件缺陷降到最低，所以才有了測試人員，他們的價值因為軟件缺陷而存在。缺陷存在，測試存在，缺陷消失，測試也會消失，當然后者是永遠不可能的！所以我們中國的軟件質量的騰飛就全靠我們的研發人員和測試人員了！相信中國的軟件企業也會對越來越對軟件質量加以重視，給我們的研發測試人員給予努力的動力！

我現在就從上一篇文章中我介紹過測試方法，里面有些概念我想在這里做了個解釋方便沒有做過測試的人了解，也給正在做測試做個參考選擇，哪個階段應該采用哪種測試。希望能對你們有有用的信息。

黑盒測試 (Black box testing) ── 不考慮內部設計和代碼，根據需求和功能進行測試。

白盒測試 (White box testing) ── 根據應用軟件的代碼的內部邏輯，按照代碼的語句、分支、路徑和條件進行測試。

部件測試 (Unit testing) ── 最小范圍的測試，針對特定的函數和代碼模塊進行測試。因為需要了解程序的設計和代碼的細節才能進行，所以部件測試一般是由程序員，而不是由測試人員來做。除非應用軟件的結構設計良好，而且代碼也寫得清楚，否則部件測試并非易事。也許需要開發測試驅動模塊或測試工具。

遞增的綜合測試 (incremental integration testing) ── 不斷進行的測試過程，每增加一個新的功能模塊，都進行測試。這要求一個應用軟件在最終完成之前，各功能模塊要相對獨立，或者已根據需要開發出測試驅動軟件。這種測試可由程序員或測試人員進行。

綜合測試 (integration testing) ── 對應用軟件的各個部件進行組合測試，來檢查各功能模塊在一起工作是否正常。“部件”可以是代碼模塊、獨立的應用程序、也可以是網絡中的客戶/服務器應用軟件。這種測試特別適用于客戶/服務器環境和分布式系統。

功能測試 (functional testing) ── 對一個應用軟件的功能模塊進行黑盒測試。這種測試應當由測試人員進行。但這并不意味著程序員在推出軟件之前不進行代碼檢查。(這一原則適用于所有的測試階段。)

系統測試 ── 針對全部需求說明進行黑盒測試，包括系統中所有的部件。

端到端測試 (end-to-end testing) ── 類似于系統測試，但測試范圍更“宏觀”一些。模仿實際

應用環境，對整個應用軟件進行使用測試。例如與數據庫進行交互作業、使用網絡通信、與其他硬件、

應用程序和系統之間的相互作用是否滿足要求。

健全測試 (sanity testing) ── 是一種典型的初始測試。判斷一個新的軟件版本的運行是否正常，是否值得對它作進一步的測試。例如，如果一個新的軟件每 5 分鐘就破壞系統、大大降低系統的運行速度、或者破壞數據庫，那么這樣的軟件就算不上是“健全”的，不值得在目前狀態下進行進一步的測試。

回歸測試 (regression testing) ── 每當軟件經過了整理、修改、或者其環境發生變化，都重復進行測試。很難說需要進行多少次回歸測試，特別是是到了開發周期的最后階段。進行此種測試，特別適于使用自動測試工具。

認同測試 (acceptance testing) ── 基于說明書的、由最終用戶或顧客來進行的測試。或者由最

終用戶/顧客來進行一段有限時間的使用。

負荷試驗 (load testing) ── 在大負荷條件下對應用軟件進行測試。例如測試一個網站在不同負荷情況下的狀況，以確定在什么情況下系統響應速度下降或是出現故障。

壓力測試 (stress testing) ── 經常可以與“負荷測試”或“性能測試”相互代替。這種測試是用來檢查系統在下列條件下的情況：在非正常的巨大負荷下、某些動作和輸入大量重復、輸入大數、對數據庫進行非常復雜的查詢，等等。

性能測試 (performance testing) ── 經常可以與“壓力測試”或“負荷測試”相互代替。理想的“性能測試”(也包括其他任何類型的測試) 都應在質量保障和測試計劃的文檔終予以規定。

可用性測試 (usability testing) ── 是專為“對用戶友好”的特性進行測試。這是一種主觀的感

覺，取決于最終用戶或顧客。可以進行用戶會見、檢查、對用戶會議錄像、或者使用其他技術。程序員和測試人員通常不參加可用性測試。

安裝/卸載測試 (install/uninstall testing) ── 對安裝/卸載進行測試 (包括全部、部分、升級操作)。

恢復測試 (recovery testing) ── 在系統崩潰、硬件故障、或者其他災難發生之后，重新恢復系統的情況。

安全測試 (security testing) ── 測試系統在應付非授權的內部/外部訪問、故意的損壞時的防護情況。這需要精密復雜的測試技術。

兼容性測試 (compatability testing) ── 測試在特殊的硬件/軟件/操作系統/網絡環境下的軟件表現。

認同測試 (acceptance testing) ── 看顧客是否對軟件滿意。

比較測試 (comparison testing) ── 與競爭產品進行比較，以找出弱點和優勢。

alpha測試 (alpha testing) ── 在開發一個應用軟件即將完成時所進行的測試。此時還允許有較小

的設計修改。通常由最終用戶或其他人進行這種測試，而不是由程序員和測試人員來進行。

beta測試 (beta testing) ── 當開發和測試已基本完成，需要在正式發行之前最后尋找毛病而進行的測試。通常由最終用戶或其他人進行這種測試，而不是由程序員和測試人員來進行。

從我們公司從事嵌入式軟件測試及軟件測試的工具推廣來的經驗來看，為了更好的遵循一些標準和規則，使代碼更具有具有可讀性和可維護性，建議對于寫 C 和 C++ 代碼開發的人員可以參考一下建議：當然不太適合一切情況，僅供參考！

1、減少或排除全局變量的使用。

2、使用說明性的函數和方法名 —— 使用大、小寫字符，避免用縮寫，使用滿足要求的說明文字來進行充分的描述 (使用超過 20 個字符也不致超行)。取名要與功能一致。

3、使用說明性的變量名 —— 使用大、小寫字符，避免用縮寫，使用滿足要求的說明文字來進行充分的描述 (使用超過 20 個字符也不致超行)。取名要與功能一致。

4、函數和方法的大小要盡可能小 —— 最好不超過 100 行，少于 50 行最好。

5、在函數代碼前面的函數的說明文字應當清楚。

6、書寫代碼應便于閱讀。

7、在水平方向和垂直方向都留出足夠的空間

8、每行代碼字符數不超過 70 個

9、每條語句占 1 行

10、一個程序內的代碼風格應一致 (在使用括弧、縮排、和命名方式等方面)

11、注釋內容寧多勿少，通常注釋行的數量 (包括開始部分) 應當不少于代碼行的數量

12、不管應用程序多么小，都應有文檔，包括程序功能的概述和流程圖 (哪怕只有幾行字，也比沒有要好)。如果可能的話，最好有單獨的流程圖和詳細的程序文檔。

13、盡最大可能使用錯誤處理過程，并對狀況和錯誤進行記錄。

14、在使用 C++ 時，為了減少復雜程度和提高可維護性，應當避免類的繼承的層數過多 (這取決于應用程序的大小和復雜程度)。除要盡量減少繼承的層次以外，還應少用超負荷運算符 (minimize use of operator overloading)。使用 Java 語言可以消除多級繼承和運算符超負荷。

15、在使用 C++ 時，保持類的方法不要太大，對于每各類的方法，代碼行不超過 50 行為最佳。

16、在使用 C++ 時，應自由進行例外的處理 (make liberal use of exception handlers)

軟件測試是個大工程，需要開發人員和測試人員協調配合完成，如果開發人員在編程的時候能按照一定準則去編程，這對后面的單元，集成測試也是減少很多壓力，當然每個編程人員的編程習慣不一樣，所以會按照規范去做，會和自己多年的編程的風格有沖突，所以推動規范還是一件比較有挑戰的工作。這也是很多企業遇到的問題。

下面我就上一篇提到的QAC這個軟件測試工具做個介紹；它是英國Programming Research公司的，PR公司是專業從事軟件設計方法學和軟件編程規范研究的公司，是MISRA的主要起草者，QA C/C++/Java分別是針對三種源代碼語言的代碼規則檢查和靜態分析工具，用于鑒別C/C++/Java語言使用過程中出現的問題，這些問題包括語言中比較危險、過于復雜、不可移植、難于維護的特性，或者是編碼不符合特定的規則。而這些問題是不能靠編譯器或開發工具識別的。為什么要做代碼規則檢查？是標準要求必須進行的軟件質量保證過程。軍標Z121、DO-178B標準、CMM/CMMI認證都要求強制進行代碼規則檢查。GJB5369更進一步規定了C語言編程規范。自動代碼規則檢查能在軟件開發早期早期自動檢測出軟件錯誤和安全隱患，能夠在軟件開發的早期有效保證軟件代碼的質量；而且可以在同一個開發團隊形成統一的代碼風格，減少代碼維護性和單元/集成測試時間，增加團隊凝聚力和提高生產效率。

下面簡單銜接一下關于行業內的常見一些認證及標準做了個簡要解釋；

1、SEI = “軟件工程研究所 (Software Engineering Institute)”，設在卡內基梅隆大學，為改善軟件開發過程，由美國國防部創建。

2、CMM = “性能完善模型 (Capability Maturity Model)”，由 SEI 開發。它是一個分 5 級的、可以描述結構完善程度的模型，用它來說明所交付的軟件的效能。它適用于大的機構，例如美國國防部的承包商。所以，它所涉及的許多質量控制過程適用于任何機構，如果合理地利用它，將會獲益不淺。一個機構經過權威評審機構的評估，可以得到CMM 等級 (CMM ratings)。

3、1 級──表現混亂，定期需要應急措施，需要經過很大努力才能完成項目。很少有適當的過程，成功不可重復。

4、 2 級──軟件項目跟蹤、需求管理、合理計劃、以及結構管理過程適當，成功可以重復。

5、3 級──標準軟件開發和維護處理過程完整地在整個機構內貫徹。有一個軟件工程處理組來堅實軟件過程，開

設培訓課程來確保理解和一致性。

6、4 級──對生產、處理和產品進行跟蹤，項目的特性是可預見的，非常重視質量。

7、5 級──重視持續地改善處理過程。新的處理過程和新技術的效果是可預見的，在需要時使用它們便可提高效率。

(關于 CMM 等級的前景：1992-1996 年間，共有 533 個機構經過評估。其中 62% 的機構屬于 1 級，23% 為 2 級，13% 為 3 級，2% 為 4 級，0.4% 是 5 級。中等大小的機構有 100 個工程師/維護人員；31% 的機構是美國國防部的承包商。在那些CMM 等級為 1 級的機構里，有問題的關鍵處理領域在于軟件質量保障。)

8、ISO = “國際標準化組織 (International Organisation for Standards)” ── ISO9001、9002 和9003是針對質量系統的標準，由外部的評估人員進行評價，適用于許多類型的生產和制造機構，而不僅僅適用于軟件開發。其中最復雜的是 9001，它被廣泛用于軟件開發機構。9001 涵蓋文檔、設計、開發、生產、測試、安裝、服務和其他過程。ISO 9000-3 (不是9003) 是 ISO 9001 用于軟件開發機構時的指導方針。美國版的 ISO 9000 系列標準與國際版完全相同，被稱為 ANSI/ASQ Q9000 系列。美國版可以直接從美國質量協會 (ASQ ── American Society for Quality) 或者 ANSI 購買。一個機構要想獲得 ISO 9001 認證，需要有第三方的評價人員進行評估，所獲得的認證的有效期為 3 年，屆時需要進行再評估。注意：ISO 9000 并不是表明產品質量所必需的，它只是表示文檔所規定的處理過程都

被遵循。

9、 IEEE = “電學和電子工程師協會 (Institute of Electrical and Electronics Engineers)” ── 除作其他事情以外，還制定了以下標準：

10、IEEE/ANSI Standard 829 ── 軟件測試文檔標準

11、IEEE/ANSI Standard 1008 ── 軟件部件測試 (Unit Testing) 標準

12、 IEEE/ANSI Standard 730 ── 軟件質量保障計劃

以及其他一些標準。

13、 ANSI = “美國國家標準協會 (American National Standards Institute)” ── 是美國主要的工業標準實體；與 IEEE 和 ASQ (American Society for Quality ── 美國質量協會) 協力，也出版了一些與軟件有關的標準。

14、除 CMM 或 ISO 9000 以外，其他的軟件開發過程評估方法有：SPICE，Trillium，TickIT。和Bootstrap

MISRA (The Motor Industry Software Reliability Association 汽車工業軟件可靠性聯會) 是位于英國的一個跨國汽車工業協會，其成員包括了大部分歐美汽車生產商。其核心使命是為汽車工業提供服務和協助，幫助廠方開發安全的、高可靠性的嵌入式軟件。這個組織最出名的成果是所謂的MISRA C Coding Standard，這一標準中包括了127條C語言編碼標準，通常認為，如果能夠完全遵守這些標準，則你的C代碼是易讀、可靠、可移植和易于維護的。

DO-178B標準：飛機分成二類：軍用飛機與民用飛機。每個國家對軍用飛機的研制都有自己的標準和質量監督體系；但對于民用飛機說，由于一個國家研制的飛機會飛到其它國家去，這就要求有一個能夠被國際普遍認可的標準和質量體系來保證飛機的安全。具體地說，飛機通常需要通過四個認證以后才可真正投入運營：也即定型認證（Type Certificate）、生產認證（Production Certificate）、適航認證（Airworthiness Certificate）、運營認證（Operational Certificate）。這四個質量認證涉及的標準有很多，構成一整套標準體系，而DO-178B標準則是對機載軟件進行適航認證時適用的標準，是整個民航標準體系的比較重要的一個標準。

執行DO-178B標準質量認證的權威機構在不同的國家和地區不盡相同。在歐洲，該質量認證由EASA（European Aviation Safety Agency）來執行；在美國由FAA（Federal Aviation Administration）執行；在加拿大則由Transport Canada來執行。通常，被一個機構認證通過的飛機在一定條件下也會被另外一個機構默認通過。

Def Stan 00-55, 1997年9月英國國防頒發了Def Stan 00-55“防務裝備中與安全性有關的軟件要求”，對如何保證裝備安全性對軟件提出具體要求。