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

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

讓我們?cè)倏纯窜浖袠I(yè)的的研發(fā)人員和軟件測(cè)試人員的人員配置比例，據(jù)調(diào)查國(guó)外軟件行業(yè)的比例是1：1或1：3，在國(guó)內(nèi)的實(shí)際比例是10：1，就工資而言國(guó)內(nèi)的測(cè)試人員的工資比研發(fā)人員的還低，所以測(cè)試人員和開(kāi)發(fā)人員面臨同樣的問(wèn)題就是技術(shù)熟練的時(shí)候轉(zhuǎn)行。測(cè)試之所以產(chǎn)生是因?yàn)檠邪l(fā)不能夠把軟件缺陷降到最低，所以才有了測(cè)試人員，他們的價(jià)值因?yàn)檐浖毕荻嬖凇Ｈ毕荽嬖冢瑴y(cè)試存在，缺陷消失，測(cè)試也會(huì)消失，當(dāng)然后者是永遠(yuǎn)不可能的！所以我們中國(guó)的軟件質(zhì)量的騰飛就全靠我們的研發(fā)人員和測(cè)試人員了！相信中國(guó)的軟件企業(yè)也會(huì)對(duì)越來(lái)越對(duì)軟件質(zhì)量加以重視，給我們的研發(fā)測(cè)試人員給予努力的動(dòng)力！

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

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

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

部件測(cè)試 (Unit testing) ── 最小范圍的測(cè)試，針對(duì)特定的函數(shù)和代碼模塊進(jìn)行測(cè)試。因?yàn)樾枰私獬绦虻脑O(shè)計(jì)和代碼的細(xì)節(jié)才能進(jìn)行，所以部件測(cè)試一般是由程序員，而不是由測(cè)試人員來(lái)做。除非應(yīng)用軟件的結(jié)構(gòu)設(shè)計(jì)良好，而且代碼也寫(xiě)得清楚，否則部件測(cè)試并非易事。也許需要開(kāi)發(fā)測(cè)試驅(qū)動(dòng)模塊或測(cè)試工具。

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

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

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

系統(tǒng)測(cè)試 ── 針對(duì)全部需求說(shuō)明進(jìn)行黑盒測(cè)試，包括系統(tǒng)中所有的部件。

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

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

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

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

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

認(rèn)同測(cè)試 (acceptance testing) ── 基于說(shuō)明書(shū)的、由最終用戶(hù)或顧客來(lái)進(jìn)行的測(cè)試。或者由最

終用戶(hù)/顧客來(lái)進(jìn)行一段有限時(shí)間的使用。

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

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

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

可用性測(cè)試 (usability testing) ── 是專(zhuān)為“對(duì)用戶(hù)友好”的特性進(jìn)行測(cè)試。這是一種主觀的感

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

安裝/卸載測(cè)試 (install/uninstall testing) ── 對(duì)安裝/卸載進(jìn)行測(cè)試 (包括全部、部分、升級(jí)操作)。

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

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

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

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

比較測(cè)試 (comparison testing) ── 與競(jìng)爭(zhēng)產(chǎn)品進(jìn)行比較，以找出弱點(diǎn)和優(yōu)勢(shì)。

alpha測(cè)試 (alpha testing) ── 在開(kāi)發(fā)一個(gè)應(yīng)用軟件即將完成時(shí)所進(jìn)行的測(cè)試。此時(shí)還允許有較小

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

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

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

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

2、使用說(shuō)明性的函數(shù)和方法名 —— 使用大、小寫(xiě)字符，避免用縮寫(xiě)，使用滿(mǎn)足要求的說(shuō)明文字來(lái)進(jìn)行充分的描述 (使用超過(guò) 20 個(gè)字符也不致超行)。取名要與功能一致。

3、使用說(shuō)明性的變量名 —— 使用大、小寫(xiě)字符，避免用縮寫(xiě)，使用滿(mǎn)足要求的說(shuō)明文字來(lái)進(jìn)行充分的描述 (使用超過(guò) 20 個(gè)字符也不致超行)。取名要與功能一致。

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

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

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

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

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

9、每條語(yǔ)句占 1 行

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

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

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

13、盡最大可能使用錯(cuò)誤處理過(guò)程，并對(duì)狀況和錯(cuò)誤進(jìn)行記錄。

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

15、在使用 C++ 時(shí)，保持類(lèi)的方法不要太大，對(duì)于每各類(lèi)的方法，代碼行不超過(guò) 50 行為最佳。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

被遵循。

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

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

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

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

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

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

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

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

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

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

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