美女看嵌入式工具市場的發(fā)展

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

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

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

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

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

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

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

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

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

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

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

應(yīng)用環(huán)境，對整個應(yīng)用軟件進行使用測試。例如與數(shù)據(jù)庫進行交互作業(yè)、使用網(wǎng)絡(luò)通信、與其他硬件、

應(yīng)用程序和系統(tǒng)之間的相互作用是否滿足要求。

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

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

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

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

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

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

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

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

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

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

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

安全測試 (security testing) ── 測試系統(tǒng)在應(yīng)付非授權(quán)的內(nèi)部/外部訪問、故意的損壞時的防護情況。這需要精密復(fù)雜的測試技術(shù)。

兼容性測試 (compatability testing) ── 測試在特殊的硬件/軟件/操作系統(tǒng)/網(wǎng)絡(luò)環(huán)境下的軟件表現(xiàn)。

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

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

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

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

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

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

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

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

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

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

5、在函數(shù)代碼前面的函數(shù)的說明文字應(yīng)當(dāng)清楚。

6、書寫代碼應(yīng)便于閱讀。

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

8、每行代碼字符數(shù)不超過 70 個

9、每條語句占 1 行

10、一個程序內(nèi)的代碼風(fēng)格應(yīng)一致 (在使用括弧、縮排、和命名方式等方面)

11、注釋內(nèi)容寧多勿少，通常注釋行的數(shù)量 (包括開始部分) 應(yīng)當(dāng)不少于代碼行的數(shù)量

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

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

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

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

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

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

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

下面簡單銜接一下關(guān)于行業(yè)內(nèi)的常見一些認(rèn)證及標(biāo)準(zhǔn)做了個簡要解釋；

1、SEI = “軟件工程研究所 (Software Engineering Institute)”，設(shè)在卡內(nèi)基梅隆大學(xué)，為改善軟件開發(fā)過程，由美國國防部創(chuàng)建。

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

3、1 級──表現(xiàn)混亂，定期需要應(yīng)急措施，需要經(jīng)過很大努力才能完成項目。很少有適當(dāng)?shù)倪^程，成功不可重復(fù)。

4、 2 級──軟件項目跟蹤、需求管理、合理計劃、以及結(jié)構(gòu)管理過程適當(dāng)，成功可以重復(fù)。

5、3 級──標(biāo)準(zhǔn)軟件開發(fā)和維護處理過程完整地在整個機構(gòu)內(nèi)貫徹。有一個軟件工程處理組來堅實軟件過程，開

設(shè)培訓(xùn)課程來確保理解和一致性。

6、4 級──對生產(chǎn)、處理和產(chǎn)品進行跟蹤，項目的特性是可預(yù)見的，非常重視質(zhì)量。

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

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

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

被遵循。

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

10、IEEE/ANSI Standard 829 ── 軟件測試文檔標(biāo)準(zhǔn)

11、IEEE/ANSI Standard 1008 ── 軟件部件測試 (Unit Testing) 標(biāo)準(zhǔn)

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

以及其他一些標(biāo)準(zhǔn)。

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

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

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

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

執(zhí)行DO-178B標(biāo)準(zhǔn)質(zhì)量認(rèn)證的權(quán)威機構(gòu)在不同的國家和地區(qū)不盡相同。在歐洲，該質(zhì)量認(rèn)證由EASA（European Aviation Safety Agency）來執(zhí)行；在美國由FAA（Federal Aviation Administration）執(zhí)行；在加拿大則由Transport Canada來執(zhí)行。通常，被一個機構(gòu)認(rèn)證通過的飛機在一定條件下也會被另外一個機構(gòu)默認(rèn)通過。

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