|
慕容嫣然，某商學(xué)院畢業(yè)，現(xiàn)供職于某嵌入式企業(yè)，從事2年以上嵌入式工具開發(fā)與推廣。 我想緊接著上一篇就嵌入式軟件測試的現(xiàn)狀談一下，首先從中國的國情來說，當(dāng)國外的研發(fā)人員為自己沒有把軟件缺陷降到最低而苦悶的時候，我們的研發(fā)人員則還是為了溫飽而苦悶，為什么國內(nèi)很多研發(fā)人員到35歲左右他們就想轉(zhuǎn)行或投身于銷售或轉(zhuǎn)做管理，難道是因?yàn)樗麄円呀?jīng)做不了研發(fā)，因?yàn)楣緵]有給他們職業(yè)規(guī)劃，他們找不到自己的晉升機(jī)會，因?yàn)榈搅诉@個年齡生活已經(jīng)不是一個人的事情了，由此導(dǎo)致我們國內(nèi)IT技術(shù)人員放棄多年的研發(fā)經(jīng)驗(yàn)投身于別的產(chǎn)業(yè)，這難道不是技術(shù)人才的浪費(fèi)嗎？ 讓我們再看看軟件行業(yè)的的研發(fā)人員和軟件測試人員的人員配置比例，據(jù)調(diào)查國外軟件行業(yè)的比例是1：1或1：3，在國內(nèi)的實(shí)際比例是10：1，就工資而言國內(nèi)的測試人員的工資比研發(fā)人員的還低，所以測試人員和開發(fā)人員面臨同樣的問題就是技術(shù)熟練的時候轉(zhuǎn)行。測試之所以產(chǎn)生是因?yàn)檠邪l(fā)不能夠把軟件缺陷降到最低，所以才有了測試人員，他們的價值因?yàn)檐浖毕荻嬖�。缺陷存在，測試存在，缺陷消失，測試也會消失，當(dāng)然后者是永遠(yuǎn)不可能的！所以我們中國的軟件質(zhì)量的騰飛就全靠我們的研發(fā)人員和測試人員了！相信中國的軟件企業(yè)也會對越來越對軟件質(zhì)量加以重視，給我們的研發(fā)測試人員給予努力的動力！ 我現(xiàn)在就從上一篇文章中我介紹過測試方法，里面有些概念我想在這里做了個解釋方便沒有做過測試的人了解，也給正在做測試做個參考選擇，哪個階段應(yīng)該采用哪種測試。希望能對你們有有用的信息。 黑盒測試 (Black box testing) ── 不考慮內(nèi)部設(shè)計(jì)和代碼，根據(jù)需求和功能進(jìn)行測試。 白盒測試 (White box testing) ── 根據(jù)應(yīng)用軟件的代碼的內(nèi)部邏輯，按照代碼的語句、分支、路徑和條件進(jìn)行測試。 部件測試 (Unit testing)──最小范圍的測試，針對特定的函數(shù)和代碼模塊進(jìn)行測試。因?yàn)樾枰私獬绦虻脑O(shè)計(jì)和代碼的細(xì)節(jié)才能進(jìn)行，所以部件測試一般是由程序員，而不是由測試人員來做。除非應(yīng)用軟件的結(jié)構(gòu)設(shè)計(jì)良好，而且代碼也寫得清楚，否則部件測試并非易事。也許需要開發(fā)測試驅(qū)動模塊或測試工具。 遞增的綜合測試 (incremental integration testing) ── 不斷進(jìn)行的測試過程，每增加一個新的功能模塊，都進(jìn)行測試。這要求一個應(yīng)用軟件在最終完成之前，各功能模塊要相對獨(dú)立，或者已根據(jù)需要開發(fā)出測試驅(qū)動軟件。這種測試可由程序員或測試人員進(jìn)行。 綜合測試 (integration testing) ── 對應(yīng)用軟件的各個部件進(jìn)行組合測試，來檢查各功能模塊在一起工作是否正常�！安考笨梢允谴a模塊、獨(dú)立的應(yīng)用程序、也可以是網(wǎng)絡(luò)中的客戶/服務(wù)器應(yīng)用軟件。這種測試特別適用于客戶/服務(wù)器環(huán)境和分布式系統(tǒng)。 功能測試 (functional testing) ── 對一個應(yīng)用軟件的功能模塊進(jìn)行黑盒測試。這種測試應(yīng)當(dāng)由測試人員進(jìn)行。但這并不意味著程序員在推出軟件之前不進(jìn)行代碼檢查。(這一原則適用于所有的測試階段。) 系統(tǒng)測試 ── 針對全部需求說明進(jìn)行黑盒測試，包括系統(tǒng)中所有的部件。 端到端測試 (end-to-end testing) ── 類似于系統(tǒng)測試，但測試范圍更“宏觀”一些。模仿實(shí)際 應(yīng)用環(huán)境，對整個應(yīng)用軟件進(jìn)行使用測試。例如與數(shù)據(jù)庫進(jìn)行交互作業(yè)、使用網(wǎng)絡(luò)通信、與其他硬件、 應(yīng)用程序和系統(tǒng)之間的相互作用是否滿足要求。 健全測試 (sanity testing) ── 是一種典型的初始測試。判斷一個新的軟件版本的運(yùn)行是否正常，是否值得對它作進(jìn)一步的測試。例如，如果一個新的軟件每 5 分鐘就破壞系統(tǒng)、大大降低系統(tǒng)的運(yùn)行速度、或者破壞數(shù)據(jù)庫，那么這樣的軟件就算不上是“健全”的，不值得在目前狀態(tài)下進(jìn)行進(jìn)一步的測試。 回歸測試 (regression testing) ── 每當(dāng)軟件經(jīng)過了整理、修改、或者其環(huán)境發(fā)生變化，都重復(fù)進(jìn)行測試。很難說需要進(jìn)行多少次回歸測試，特別是是到了開發(fā)周期的最后階段。進(jìn)行此種測試，特別適于使用自動測試工具。 認(rèn)同測試 (acceptance testing) ── 基于說明書的、由最終用戶或顧客來進(jìn)行的測試�；蛘哂勺� 終用戶/顧客來進(jìn)行一段有限時間的使用。 負(fù)荷試驗(yàn) (load testing) ── 在大負(fù)荷條件下對應(yīng)用軟件進(jìn)行測試。例如測試一個網(wǎng)站在不同負(fù)荷情況下的狀況，以確定在什么情況下系統(tǒng)響應(yīng)速度下降或是出現(xiàn)故障。 壓力測試 (stress testing) ── 經(jīng)常可以與“負(fù)荷測試”或“性能測試”相互代替。這種測試是用來檢查系統(tǒng)在下列條件下的情況：在非正常的巨大負(fù)荷下、某些動作和輸入大量重復(fù)、輸入大數(shù)、對數(shù)據(jù)庫進(jìn)行非常復(fù)雜的查詢，等等。 性能測試 (performance testing) ── 經(jīng)常可以與“壓力測試”或“負(fù)荷測試”相互代替。理想的“性能測試”(也包括其他任何類型的測試) 都應(yīng)在質(zhì)量保障和測試計(jì)劃的文檔終予以規(guī)定。 可用性測試 (usability testing) ── 是專為“對用戶友好”的特性進(jìn)行測試。這是一種主觀的感 覺，取決于最終用戶或顧客�？梢赃M(jìn)行用戶會見、檢查、對用戶會議錄像、或者使用其他技術(shù)。程序員和測試人員通常不參加可用性測試。 安裝/卸載測試 (install/uninstall testing) ── 對安裝/卸載進(jìn)行測試 (包括全部、部分、升級操作)。 恢復(fù)測試 (recovery testing) ── 在系統(tǒng)崩潰、硬件故障、或者其他災(zāi)難發(fā)生之后，重新恢復(fù)系統(tǒng)的情況。 安全測試 (security testing) ── 測試系統(tǒng)在應(yīng)付非授權(quán)的內(nèi)部/外部訪問、故意的損壞時的防護(hù)情況。這需要精密復(fù)雜的測試技術(shù)。 兼容性測試 (compatability testing) ── 測試在特殊的硬件/軟件/操作系統(tǒng)/網(wǎng)絡(luò)環(huán)境下的軟件表現(xiàn)。 認(rèn)同測試 (acceptance testing) ── 看顧客是否對軟件滿意。 比較測試 (comparison testing) ── 與競爭產(chǎn)品進(jìn)行比較，以找出弱點(diǎn)和優(yōu)勢。 alpha測試 (alpha testing) ── 在開發(fā)一個應(yīng)用軟件即將完成時所進(jìn)行的測試。此時還允許有較小 的設(shè)計(jì)修改。通常由最終用戶或其他人進(jìn)行這種測試，而不是由程序員和測試人員來進(jìn)行。 beta測試 (beta testing) ── 當(dāng)開發(fā)和測試已基本完成，需要在正式發(fā)行之前最后尋找毛病而進(jìn)行的測試。通常由最終用戶或其他人進(jìn)行這種測試，而不是由程序員和測試人員來進(jìn)行。 從我們公司從事嵌入式軟件測試及軟件測試的工具推廣來的經(jīng)驗(yàn)來看，為了更好的遵循一些標(biāo)準(zhǔn)和規(guī)則，使代碼更具有具有可讀性和可維護(hù)性，建議對于寫 C 和 C++ 代碼開發(fā)的人員可以參考一下建議：當(dāng)然不太適合一切情況，僅供參考！ 1、減少或排除全局變量的使用。 2、使用說明性的函數(shù)和方法名 —— 使用大、小寫字符，避免用縮寫，使用滿足要求的說明文字來進(jìn)行充分的描述 (使用超過 20 個字符也不致超行)。取名要與功能一致。 3、使用說明性的變量名 —— 使用大、小寫字符，避免用縮寫，使用滿足要求的說明文字來進(jìn)行充分的描述 (使用超過 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)有文檔，包括程序功能的概述和流程圖 (哪怕只有幾行字，也比沒有要好)。如果可能的話，最好有單獨(dú)的流程圖和詳細(xì)的程序文檔。 13、盡最大可能使用錯誤處理過程，并對狀況和錯誤進(jìn)行記錄。 14、在使用 C++ 時，為了減少復(fù)雜程度和提高可維護(hù)性，應(yīng)當(dāng)避免類的繼承的層數(shù)過多(這取決于應(yīng)用程序的大小和復(fù)雜程度)。除要盡量減少繼承的層次以外，還應(yīng)少用超負(fù)荷運(yùn)算符 (minimize use of operatoroverloading)。使用 Java 語言可以消除多級繼承和運(yùn)算符超負(fù)荷。 15、在使用 C++ 時，保持類的方法不要太大，對于每各類的方法，代碼行不超過 50 行為最佳。 16、在使用 C++ 時，應(yīng)自由進(jìn)行例外的處理 (make liberal use of exception handlers) 軟件測試是個大工程，需要開發(fā)人員和測試人員協(xié)調(diào)配合完成，如果開發(fā)人員在編程的時候能按照一定準(zhǔn)則去編程，這對后面的單元，集成測試也是減少很多壓力，當(dāng)然每個編程人員的編程習(xí)慣不一樣，所以會按照規(guī)范去做，會和自己多年的編程的風(fēng)格有沖突，所以推動規(guī)范還是一件比較有挑戰(zhàn)的工作。這也是很多企業(yè)遇到的問題。 下面我就上一篇提到的QAC這個軟件測試工具做個介紹；它是英國ProgrammingResearch公司的，PR公司是專業(yè)從事軟件設(shè)計(jì)方法學(xué)和軟件編程規(guī)范研究的公司，是MISRA的主要起草者，QAC/C++/Java分別是針對三種源代碼語言的代碼規(guī)則檢查和靜態(tài)分析工具，用于鑒別C/C++/Java語言使用過程中出現(xiàn)的問題，這些問題包括語言中比較危險、過于復(fù)雜、不可移植、難于維護(hù)的特性，或者是編碼不符合特定的規(guī)則。而這些問題是不能靠編譯器或開發(fā)工具識別的。為什么要做代碼規(guī)則檢查？是標(biāo)準(zhǔn)要求必須進(jìn)行的軟件質(zhì)量保證過程。軍標(biāo)Z121、DO-178B標(biāo)準(zhǔn)、CMM/CMMI認(rèn)證都要求強(qiáng)制進(jìn)行代碼規(guī)則檢查。GJB5369更進(jìn)一步規(guī)定了C語言編程規(guī)范。自動代碼規(guī)則檢查能在軟件開發(fā)早期早期自動檢測出軟件錯誤和安全隱患，能夠在軟件開發(fā)的早期有效保證軟件代碼的質(zhì)量；而且可以在同一個開發(fā)團(tuán)隊(duì)形成統(tǒng)一的代碼風(fēng)格，減少代碼維護(hù)性和單元/集成測試時間，增加團(tuán)隊(duì)凝聚力和提高生產(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)完善程度的模型，用它來說明所交付的軟件的效能。它適用于大的機(jī)構(gòu)，例如美國國防部的承包商。所以，它所涉及的許多質(zhì)量控制過程適用于任何機(jī)構(gòu)，如果合理地利用它，將會獲益不淺。一個機(jī)構(gòu)經(jīng)過權(quán)威評審機(jī)構(gòu)的評估，可以得到CMM 等級 (CMM ratings)。 3、1 級──表現(xiàn)混亂，定期需要應(yīng)急措施，需要經(jīng)過很大努力才能完成項(xiàng)目。很少有適當(dāng)?shù)倪^程，成功不可重復(fù)。 4、 2 級──軟件項(xiàng)目跟蹤、需求管理、合理計(jì)劃、以及結(jié)構(gòu)管理過程適當(dāng)，成功可以重復(fù)。 5、3 級──標(biāo)準(zhǔn)軟件開發(fā)和維護(hù)處理過程完整地在整個機(jī)構(gòu)內(nèi)貫徹。有一個軟件工程處理組來堅(jiān)實(shí)軟件過程，開 設(shè)培訓(xùn)課程來確保理解和一致性。 6、4 級──對生產(chǎn)、處理和產(chǎn)品進(jìn)行跟蹤，項(xiàng)目的特性是可預(yù)見的，非常重視質(zhì)量。 7、5 級──重視持續(xù)地改善處理過程。新的處理過程和新技術(shù)的效果是可預(yù)見的，在需要時使用它們便可提高效率。 (關(guān)于 CMM 等級的前景：1992-1996 年間，共有 533 個機(jī)構(gòu)經(jīng)過評估。其中 62% 的機(jī)構(gòu)屬于 1 級，23% 為 2 級，13%為 3 級，2% 為 4 級，0.4% 是 5 級。中等大小的機(jī)構(gòu)有 100 個工程師/維護(hù)人員；31%的機(jī)構(gòu)是美國國防部的承包商。在那些CMM 等級為 1 級的機(jī)構(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)，由外部的評估人員進(jìn)行評價，適用于許多類型的生產(chǎn)和制造機(jī)構(gòu)，而不僅僅適用于軟件開發(fā)。其中最復(fù)雜的是9001，它被廣泛用于軟件開發(fā)機(jī)構(gòu)。9001 涵蓋文檔、設(shè)計(jì)、開發(fā)、生產(chǎn)、測試、安裝、服務(wù)和其他過程。ISO 9000-3 (不是9003)是 ISO 9001 用于軟件開發(fā)機(jī)構(gòu)時的指導(dǎo)方針。美國版的 ISO 9000 系列標(biāo)準(zhǔn)與國際版完全相同，被稱為 ANSI/ASQ Q9000系列。美國版可以直接從美國質(zhì)量協(xié)會 (ASQ ── American Society for Quality) 或者 ANSI購買。一個機(jī)構(gòu)要想獲得 ISO 9001 認(rèn)證，需要有第三方的評價人員進(jìn)行評估，所獲得的認(rèn)證的有效期為 3年，屆時需要進(jìn)行再評估。注意：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ì)量保障計(jì)劃 以及其他一些標(biāo)準(zhǔn)。 13、ANSI = “美國國家標(biāo)準(zhǔn)協(xié)會 (American National Standards Institute)” ──是美國主要的工業(yè)標(biāo)準(zhǔn)實(shí)體；與 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 CodingStandard，這一標(biāo)準(zhǔn)中包括了127條C語言編碼標(biāo)準(zhǔn)，通常認(rèn)為，如果能夠完全遵守這些標(biāo)準(zhǔn)，則你的C代碼是易讀、可靠、可移植和易于維護(hù)的。 DO-178B標(biāo)準(zhǔn)：飛機(jī)分成二類：軍用飛機(jī)與民用飛機(jī)。每個國家對軍用飛機(jī)的研制都有自己的標(biāo)準(zhǔn)和質(zhì)量監(jiān)督體系；但對于民用飛機(jī)說，由于一個國家研制的飛機(jī)會飛到其它國家去，這就要求有一個能夠被國際普遍認(rèn)可的標(biāo)準(zhǔn)和質(zhì)量體系來保證飛機(jī)的安全。具體地說，飛機(jī)通常需要通過四個認(rèn)證以后才可真正投入運(yùn)營：也即定型認(rèn)證（Type Certificate）、生產(chǎn)認(rèn)證（Production Certificate）、適航認(rèn)證（AirworthinessCertificate）、運(yùn)營認(rèn)證（OperationalCertificate）。這四個質(zhì)量認(rèn)證涉及的標(biāo)準(zhǔn)有很多，構(gòu)成一整套標(biāo)準(zhǔn)體系，而DO-178B標(biāo)準(zhǔn)則是對機(jī)載軟件進(jì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)威機(jī)構(gòu)在不同的國家和地區(qū)不盡相同。在歐洲，該質(zhì)量認(rèn)證由EASA（European Aviation Safety Agency）來執(zhí)行；在美國由FAA（Federal AviationAdministration）執(zhí)行；在加拿大則由TransportCanada來執(zhí)行。通常，被一個機(jī)構(gòu)認(rèn)證通過的飛機(jī)在一定條件下也會被另外一個機(jī)構(gòu)默認(rèn)通過。 Def Stan 00-55, 1997年9月英國國防頒發(fā)了Def Stan 00-55“防務(wù)裝備中與安全性有關(guān)的軟件要求”，對如何保證裝備安全性對軟件提出具體要求。 這篇文章有點(diǎn)松散，主要就一些概念的東西做個匯總，以后有時間多寫些測試的方法，測試管理等，比如動態(tài)測試?yán)锩娴拇驑叮庋b等技術(shù)，下回寫了，我要享受周末了 ！ |
