24小時(shí)聯(lián)系電話:18217114652、13661815404
中文
技術(shù)專題
基于標(biāo)準(zhǔn)的開發(fā)實(shí)踐
整個(gè)行業(yè)都圍繞著以功能安全性，安全性和編碼標(biāo)準(zhǔn)（例如IEC 61508，ISO 26262，IEC 62304，MISRA C和CWE）為支持的驗(yàn)證和確認(rèn)實(shí)踐而發(fā)展。當(dāng)然，并非所有人都有義務(wù)遵循這些標(biāo)準(zhǔn)所倡導(dǎo)的正式流程和方法，尤其是在其軟件不需要滿足這些標(biāo)準(zhǔn)的嚴(yán)格要求的情況下。但是標(biāo)準(zhǔn)支持最佳實(shí)踐，因?yàn)榻?jīng)驗(yàn)表明，它們代表了獲得高質(zhì)量，可靠和強(qiáng)大的軟件的最有效方法。
遵循這些標(biāo)準(zhǔn)的最佳實(shí)踐開發(fā)技術(shù)可幫助確保一開始就不會在代碼中引入錯(cuò)誤，從而減少了對大量調(diào)試活動的需求，這些活動可能會縮短上市時(shí)間并增加成本。當(dāng)然，并非所有開發(fā)人員都擁有在航空航天，汽車或醫(yī)療設(shè)備行業(yè)中看到的應(yīng)用程序所能承受的時(shí)間和預(yù)算。但是，無論關(guān)鍵性是否強(qiáng)制使用它們，他們部署的技術(shù)對于任何開發(fā)團(tuán)隊(duì)而言都具有巨大的潛在利益。
錯(cuò)誤類型和解決方法
在軟件中可以找到兩種關(guān)鍵類型的錯(cuò)誤，并使用防止錯(cuò)誤引入的工具進(jìn)行了處理：
編碼錯(cuò)誤。一個(gè)示例是嘗試訪問數(shù)組范圍之外的代碼。可以通過執(zhí)行靜態(tài)分析來檢測這些類型的問題。
應(yīng)用程序錯(cuò)誤。只有通過確切了解應(yīng)用程序應(yīng)該做什么才能檢測到這些，這意味著需要進(jìn)行測試。
編碼錯(cuò)誤和代碼檢查
靜態(tài)分析是檢測編碼錯(cuò)誤的有效技術(shù)，尤其是從項(xiàng)目開始部署時(shí)。一旦分析了代碼，就可以查看不同類型的結(jié)果。在代碼審查中，將根據(jù)諸如MISRA C：2012之類的編碼標(biāo)準(zhǔn)來檢查代碼，這是我們在本文中重點(diǎn)介紹的內(nèi)容。
理想情況下，所有嵌入式項(xiàng)目都應(yīng)使用安全語言（例如Ada）。Ada具有許多特性，可以強(qiáng)制執(zhí)行思考過程，從而自然地減少錯(cuò)誤（例如，嚴(yán)格鍵入）。不幸的是，很難找到具有Ada知識和經(jīng)驗(yàn)的程序員，因此大多數(shù)公司都使用C和/或C ++。但是，即使是經(jīng)驗(yàn)豐富的開發(fā)人員，這些語言也會帶來陷阱。幸運(yùn)的是，通過執(zhí)行代碼審查，可以避免大多數(shù)這些潛在的陷阱。
避免代碼缺陷的最佳方法是避免將其放置在此處。這聽起來很明顯，但這正是編碼標(biāo)準(zhǔn)所做的。在C和C ++世界中，大約80％的軟件缺陷是由錯(cuò)誤使用大約20％的語言引起的。如果限制使用該語言以避免該語言的已知部分出現(xiàn)問題，則可以避免出現(xiàn)缺陷，從而大大提高軟件質(zhì)量。
C / C ++編程語言與語言相關(guān)的故障的根本原因是未定義的行為，實(shí)現(xiàn)定義的行為和未指定的行為。這些行為導(dǎo)致軟件錯(cuò)誤和安全問題。
作為實(shí)現(xiàn)定義的行為的示例，請考慮當(dāng)有符號整數(shù)右移時(shí)的高階位的傳播。結(jié)果是0x40000000還是0xC0000000？
某些C和C ++構(gòu)造的行為取決于所使用的編譯器
答案取決于您使用的是哪個(gè)編譯器（圖1）。可能是。函數(shù)參數(shù)的求值順序未在C語言中指定。在圖2所示的代碼中（其中rollDice（）函數(shù)僅從持有值“ 1、2、3和4”的循環(huán)緩沖區(qū)中讀取下一個(gè)值），期望的返回值為1234。但是，沒有為此，至少一個(gè)編譯器將生成返回值3412的代碼。
圖2：某些C和C ++構(gòu)造的行為未由語言指定
C / C ++語言存在許多類似的陷阱，但是通過使用編碼標(biāo)準(zhǔn)，可以避免這些未定義，未指定和實(shí)現(xiàn)定義的行為。同樣，使用諸如goto或malloc之類的構(gòu)造會導(dǎo)致缺陷，因此可以使用編碼標(biāo)準(zhǔn)來防止使用這些構(gòu)造。混合有符號和無符號值時(shí)會發(fā)生許多問題，這在大多數(shù)情況下不會產(chǎn)生問題，但是有時(shí)可能會出現(xiàn)極端情況，即有符號的值溢出并變?yōu)樨?fù)數(shù)。
編碼標(biāo)準(zhǔn)還可以檢查代碼是否以特定樣式編寫。例如，驗(yàn)證未使用制表符，縮進(jìn)是特定大小還是括號位于特定位置。這很重要，因?yàn)閷⑿枰M(jìn)行一些手動代碼審查，并且在其他選項(xiàng)卡字符大小不同的編輯器中查看代碼時(shí)，奇怪的布局分散了審查者的注意力，使他們無法集中精力審查代碼。
一些開發(fā)人員對編寫“聰明的”代碼感到內(nèi)gui，這些代碼可能是高效且緊湊的，但也可能是晦澀復(fù)雜的，這使得其他人難以理解。最好保持簡單，讓編譯器負(fù)責(zé)制作高效的二進(jìn)制文件。再次，使用編碼標(biāo)準(zhǔn)可以幫助防止開發(fā)人員創(chuàng)建未記錄且過于復(fù)雜的代碼。
最著名的編程標(biāo)準(zhǔn)可能是MISRA標(biāo)準(zhǔn)，該標(biāo)準(zhǔn)于1998年首次發(fā)布給汽車行業(yè)。這些標(biāo)準(zhǔn)的普及反映在提供某種級別的MISRA檢查的嵌入式編譯器中。MISRA的最新版本是MISRA C：2012，其頁數(shù)幾乎是其前身的兩倍。這些附加文檔中的大多數(shù)包含有關(guān)每個(gè)規(guī)則為何存在的有用解釋，以及該規(guī)則的各種例外的詳細(xì)信息。MISRA有幾個(gè)準(zhǔn)則，并且在適用時(shí)，它們包含對標(biāo)準(zhǔn)或未定義，未指定和實(shí)現(xiàn)定義的行為的引用。這樣的一個(gè)例子可以在圖3中看到。
圖3：MISRA C引用了未定義，未指定和實(shí)現(xiàn)定義的行為
MISRA的大多數(shù)指南都是“可判定的”，這意味著工具應(yīng)該能夠識別是否存在違規(guī)行為。但是，一些準(zhǔn)則是“不確定的”，這意味著工具并非總是可能推斷出是否存在違規(guī)行為。例如，將未初始化的變量作為輸出參數(shù)傳遞給應(yīng)該對其進(jìn)行初始化的系統(tǒng)函數(shù)時(shí)。但是，除非靜態(tài)分析可以訪問系統(tǒng)功能的源代碼，否則它將無法在該功能初始化之前就知道該功能是否使用了該變量。如果使用簡單的MISRA檢查器，則它可能不會報(bào)告此違規(guī)，可能導(dǎo)致假陰性。或者，如果不確定MISRA檢查器，則它可以報(bào)告違規(guī)情況，可能導(dǎo)致假陽性。什么是最好的？不知道可能有問題嗎？還是確切地知道在哪里花費(fèi)時(shí)間來確保絕對沒有問題？當(dāng)然，假陽性比假陰性更可取。
2016年4月，MISRA委員會發(fā)布了對MISRA C：2012的修訂，其中增加了14條準(zhǔn)則，以幫助確保MISRA不僅適用于安全性至關(guān)重要的軟件，還適用于安全性至關(guān)重要的軟件。這些準(zhǔn)則之一就是指令4.14，如圖4所示，該準(zhǔn)則有助于防止由于未定義行為引起的陷阱。
圖4：MISRA和安全注意事項(xiàng)
應(yīng)用程序錯(cuò)誤和需求測試
應(yīng)用程序錯(cuò)誤只能通過測試產(chǎn)品是否達(dá)到了預(yù)期功能才能找到，這意味著有要求。避免應(yīng)用程序錯(cuò)誤既需要設(shè)計(jì)正確的產(chǎn)品，又需要設(shè)計(jì)正確的產(chǎn)品。
設(shè)計(jì)正確的產(chǎn)品意味著預(yù)先建立需求，并確保需求和源代碼之間的雙向可追溯性，以便已實(shí)現(xiàn)每個(gè)需求，并且每個(gè)軟件功能都可以追溯到需求。任何缺少的或不必要的功能（不符合要求）也是應(yīng)用程序錯(cuò)誤。設(shè)計(jì)產(chǎn)品權(quán)利是確認(rèn)開發(fā)的系統(tǒng)代碼滿足項(xiàng)目要求的過程，可以通過執(zhí)行基于需求的測試來實(shí)現(xiàn)。
圖5顯示了雙向可追溯性的示例。在這個(gè)簡單的示例中，選擇了一個(gè)功能，并突出了從功能到低層需求，然后是高層需求，最后是系統(tǒng)層需求的上游可追溯性。
圖5：雙向可追溯性，已選擇功能
在圖6中，選擇了一個(gè)高級需求，并且高亮顯示了對系統(tǒng)級別需求的上游可追溯性和對低級別需求以及源代碼功能的下游可追溯性。
圖6：雙向可追溯性，已選擇要求
這種可視化可追溯性的能力可以導(dǎo)致在生命周期的早期發(fā)現(xiàn)可追溯性問題（應(yīng)用程序錯(cuò)誤）。
測試代碼功能需要了解它應(yīng)該做什么，這意味著具有低級要求來陳述每個(gè)功能的作用。圖7顯示了一個(gè)低級別需求的示例，在這種情況下，它完整地描述了一個(gè)功能。
圖7：低級別需求示例
測試用例源自表1中所示的低級需求。
表1：來自低級需求的測試用例
然后使用單元測試工具在主機(jī)或目標(biāo)上執(zhí)行這些測試用例，以確保代碼的行為符合要求。圖8顯示所有測試用例均已回歸并通過。
圖8：執(zhí)行單元測試
測試用例運(yùn)行后，應(yīng)測量結(jié)構(gòu)覆蓋范圍，以確保所有代碼都已執(zhí)行。如果覆蓋率不是100％，則可能需要更多的測試用例，或者有多余的代碼應(yīng)刪除。