通過靜態(tài)代碼分析和動態(tài)測試提升軟件的質(zhì)量

召回活動增加,交付延誤,難以按時履行承諾的功能:軟件質(zhì)量不明顯。只有通過一致的行動、遵守標準和使用成熟的測試和質(zhì)量保證工具,才能開發(fā)出好的軟件。糟糕的軟件會導致金錢損失和公司形象的惡化.嵌入式軟件甚至更為關鍵,因為它主要用于對安全至關重要的應用程序。在這方面,軟件錯誤可能危及人的生命,因此必須不惜一切代價避免。因此,諸如ISO26262、ICC61508或DO178-C等標準對軟件的開發(fā)和測試質(zhì)量有嚴格的要求。

為了確保質(zhì)量,靜態(tài)代碼分析程序和動態(tài)分析過程中可執(zhí)行軟件的測試(包括單元測試)都是必要的。由于這兩種方法中的每一種都只揭示了現(xiàn)有缺陷的一部分,所以這兩種互補方法都是必要的。

在開發(fā)早期使用靜態(tài)分析工具

雖然動態(tài)分析要求執(zhí)行代碼,但靜態(tài)分析不需要。因此,靜態(tài)分析工具可以在開發(fā)過程的早期階段在實施階段使用。由于這個原因,靜態(tài)代碼分析為項目的成功做出了巨大貢獻--早期的錯誤被發(fā)現(xiàn),而修復的成本效益更高。

沒有編寫測試用例,靜態(tài)代碼分析工具檢查代碼的語法、語義、控制流和數(shù)據(jù)流異常、并發(fā)性問題以及編程規(guī)則。發(fā)現(xiàn)了許多錯誤和安全漏洞。

建議從開發(fā)一開始就定期對代碼進行靜態(tài)分析--最好是由單個開發(fā)人員在檢查代碼之前進行分析。當靜態(tài)代碼分析不再顯示任何錯誤時,只將代碼提交到進一步的驗證步驟是有意義的,例如代碼審查、單元測試或集成測試。有了這個程序,在交付前的最后檢查期間,錯誤消息的數(shù)量可以大大減少。

靜態(tài)分析工具在開發(fā)嵌入式系統(tǒng)中特別有用,因為在這些系統(tǒng)中使用的語言有C和C++。這些語言給了開發(fā)人員很大的自由--不幸的是,這些語言也給了開發(fā)人員編寫錯誤的源代碼的自由。諸如無點異常、緩沖溢出或全局變量問題是常見的。這種錯誤可以通過靜態(tài)代碼分析來避免.

動態(tài)測試也是必要的

一旦軟件可以執(zhí)行,靜態(tài)分析應該補充動態(tài)測試。

動態(tài)測試主要用于證明系統(tǒng)的功能正確性.通常,一旦第一個代碼組件是可執(zhí)行的,就會執(zhí)行它們。這些測試的一個重要部分是代碼覆蓋分析,它確保代碼的所有(重要)部分都將被測試。

在源代碼的所有相關點(代碼的儀器)上,測試代碼部分是否在測試運行期間執(zhí)行過,例如來自VERFY軟件技術的代碼覆蓋工具。由于嵌入式系統(tǒng)通常僅有有限的內(nèi)存空間,因此重要的是,這種儀器的開銷仍然很小。此外,代碼覆蓋工具對性能的影響應該最小,以避免在時間緊迫的系統(tǒng)中出現(xiàn)故障。覆蓋工具通常集成到開發(fā)環(huán)境中--代碼檢測是自動的。測試運行后,覆蓋分析器生成報告,允許詳細查看哪些函數(shù)執(zhí)行了,哪些函數(shù)沒有執(zhí)行。

對于安全性至關重要的軟件代碼覆蓋是強制性的。標準DO-178C(航空)、ISO26262(汽車)、IN50128(鐵路)和通用標準IC61508(鐵路)規(guī)定了高編碼覆蓋率,直至修改的條件決定覆蓋率(MC/DC),以展示軟件中所有條件或決定的測試。

需要靜態(tài)分析和動態(tài)測試,以實現(xiàn)良好的質(zhì)量

為了保證高質(zhì)量,必須結合靜態(tài)分析,在執(zhí)行與代碼覆蓋相關的軟件(動態(tài)測試)期間進行充分的測試。我們現(xiàn)實生活中的家用電器項目的例子顯示了為什么需要使用這兩種方法,為什么只有一種測試或分析技術可能導致致命的后果。

制造商為洗衣機生產(chǎn)線的控制單元開發(fā)了一個軟件.它是用C寫的,應該是在單片機上運行的。這一相同的控制單元和相同的軟件打算用于這一產(chǎn)品系列的所有機器;因此,特定的功能將分別與機器類型打開或關閉。例如,更昂貴的機器配備了傳感器,測量洗衣的"染色度",并使程序能夠定制主清洗周期的持續(xù)時間。更簡單的沒有傳感器的機器的清洗時間保持不變.

在MC/DC代碼覆蓋率100%的規(guī)定下,開發(fā)了確保充分軟件質(zhì)量的測試案例。制造商認為靜態(tài)分析是可消耗的。

我們需要查看源代碼(圖1)來描述由此產(chǎn)生的問題。

size_t durationMainWashCycle(size_t prog, size_t load, size_t staining) {

if (((prog == 3) || (prog == 5) || (prog == 7)) && (load < 5)) {

return staining * 5;

}

else if (((prog == 4) || (prog == 6)) && (load < 5)) {

return staining * 8;

}

else if (((prog == 4) || (prog == 6)) && (load < 3)) {

return staining * 7;

}

else {

return staining * 9;

}

}

圖1:用于計算主洗滌周期持續(xù)時間的功能.

圖1中的函數(shù)根據(jù)所選的清洗程序以及洗衣的負載大小和"染色度"來計算清洗周期的持續(xù)時間。與此功能相關的是,圖2中列出的測試用例是在模塊測試期間執(zhí)行的,其中"染色度"是測試期間評估的一個因素。"產(chǎn)品版本"對這個結果的影響程度將在后面討論。

圖2:與功能有關的已執(zhí)行測試用例 durationMainWashCycle() .

然而,所考慮的功能的測試覆蓋率僅為71%。關于測試覆蓋率的報告(圖3)和測試結果立即揭示了一個問題:在第31行開頭具有IF-條件的程序路徑

else if (((prog == 4) || (prog == 6)) && (load < 3)) {

return staining * 7;

雖然相關測試案例(第5號和第6號)被執(zhí)行,但沒有通過。此外,這些測試案例的實際測試結果與預期結果不同。測試覆蓋率報告說明28行的if-狀態(tài)是通過的。

在代碼中交換這兩個其他條件消除了錯誤?，F(xiàn)在,一個新的測試運行使測試覆蓋率達到95%,與實際和預期的測試結果相匹配。

測試覆蓋率報告顯示,需要增加一個測試用例,以達到100%的測試覆蓋率:

由于缺少測試用例,達到了100%的規(guī)定測試覆蓋率。

在成功完成集成測試并解決了一些小問題之后,洗衣機投入生產(chǎn)并交付。過了一段時間,一些不高興的顧客抱怨起來.有些機器的清洗效果不佳,這是因為清洗周期提前終止。還有報告說,機器將主清洗周期延長幾個小時。復制這種行為證明是不可能的。

最初,有人懷疑染色傳感器出現(xiàn)故障。因此,它們是在保證范圍內(nèi)交換的。然而,很快就清楚,這并沒有解決這個問題。

在更仔細地檢查了投訴案件之后,顯然這些案件只限于生產(chǎn)線中的一種特定的機器類型。因此,考慮了軟件出錯的可能性,并委托外部服務提供者運行靜態(tài)代碼分析。

第12型的所有模型對染色傳感器和其他所有模型在恒定染色值下工作的規(guī)定執(zhí)行不當。如圖4所示,模型12的變量"Y"在函數(shù)"獲得級別"()仍然沒有初始化,通過一個未定義的染色度值。

size_t getStainingLevel(size_t product_version) {

size_t y;

if (product_version < 12) { //products w/o staining sensor

y = 3;

}

else if (product_version > 12) { //products with staining sensor

y = readStainingSensor();

}

return y;

}

圖4:視產(chǎn)品版本而定的染色度的測定。

由于該值在模塊測試中不明顯,所以這個錯誤仍未被發(fā)現(xiàn)。

此外,對簡化代碼的靜態(tài)源代碼分析結果表明,以前描述的不可訪問代碼部分的錯誤很可能已經(jīng)在實施過程的早期發(fā)現(xiàn)。

只有通過靜態(tài)分析和動態(tài)分析才能發(fā)現(xiàn)錯誤.不幸的是,靜態(tài)代碼分析只能追溯執(zhí)行洗衣機制造商。在開發(fā)階段,錯誤修正會更經(jīng)濟.及時的靜態(tài)分析和動態(tài)測試將避免昂貴的產(chǎn)品召回和相關的形象損失。該電器制造商目前使用靜態(tài)分析和動態(tài)測試,對其所有軟件項目進行測試覆蓋。