通過靜態(tài)代碼分析和動(dòng)態(tài)測試提升軟件的質(zhì)量
召回活動(dòng)增加,交付延誤,難以按時(shí)履行承諾的功能:軟件質(zhì)量不明顯。只有通過一致的行動(dòng)、遵守標(biāo)準(zhǔn)和使用成熟的測試和質(zhì)量保證工具,才能開發(fā)出好的軟件。糟糕的軟件會(huì)導(dǎo)致金錢損失和公司形象的惡化.嵌入式軟件甚至更為關(guān)鍵,因?yàn)樗饕糜趯Π踩陵P(guān)重要的應(yīng)用程序。在這方面,軟件錯(cuò)誤可能危及人的生命,因此必須不惜一切代價(jià)避免。因此,諸如ISO26262、ICC61508或DO178-C等標(biāo)準(zhǔn)對軟件的開發(fā)和測試質(zhì)量有嚴(yán)格的要求。
為了確保質(zhì)量,靜態(tài)代碼分析程序和動(dòng)態(tài)分析過程中可執(zhí)行軟件的測試(包括單元測試)都是必要的。由于這兩種方法中的每一種都只揭示了現(xiàn)有缺陷的一部分,所以這兩種互補(bǔ)方法都是必要的。
在開發(fā)早期使用靜態(tài)分析工具
雖然動(dòng)態(tài)分析要求執(zhí)行代碼,但靜態(tài)分析不需要。因此,靜態(tài)分析工具可以在開發(fā)過程的早期階段在實(shí)施階段使用。由于這個(gè)原因,靜態(tài)代碼分析為項(xiàng)目的成功做出了巨大貢獻(xiàn)--早期的錯(cuò)誤被發(fā)現(xiàn),而修復(fù)的成本效益更高。
沒有編寫測試用例,靜態(tài)代碼分析工具檢查代碼的語法、語義、控制流和數(shù)據(jù)流異常、并發(fā)性問題以及編程規(guī)則。發(fā)現(xiàn)了許多錯(cuò)誤和安全漏洞。
建議從開發(fā)一開始就定期對代碼進(jìn)行靜態(tài)分析--最好是由單個(gè)開發(fā)人員在檢查代碼之前進(jìn)行分析。當(dāng)靜態(tài)代碼分析不再顯示任何錯(cuò)誤時(shí),只將代碼提交到進(jìn)一步的驗(yàn)證步驟是有意義的,例如代碼審查、單元測試或集成測試。有了這個(gè)程序,在交付前的最后檢查期間,錯(cuò)誤消息的數(shù)量可以大大減少。
靜態(tài)分析工具在開發(fā)嵌入式系統(tǒng)中特別有用,因?yàn)樵谶@些系統(tǒng)中使用的語言有C和C++。這些語言給了開發(fā)人員很大的自由--不幸的是,這些語言也給了開發(fā)人員編寫錯(cuò)誤的源代碼的自由。諸如無點(diǎn)異常、緩沖溢出或全局變量問題是常見的。這種錯(cuò)誤可以通過靜態(tài)代碼分析來避免.
動(dòng)態(tài)測試也是必要的
一旦軟件可以執(zhí)行,靜態(tài)分析應(yīng)該補(bǔ)充動(dòng)態(tài)測試。
動(dòng)態(tài)測試主要用于證明系統(tǒng)的功能正確性.通常,一旦第一個(gè)代碼組件是可執(zhí)行的,就會(huì)執(zhí)行它們。這些測試的一個(gè)重要部分是代碼覆蓋分析,它確保代碼的所有(重要)部分都將被測試。
在源代碼的所有相關(guān)點(diǎn)(代碼的儀器)上,測試代碼部分是否在測試運(yùn)行期間執(zhí)行過,例如來自VERFY軟件技術(shù)的代碼覆蓋工具。由于嵌入式系統(tǒng)通常僅有有限的內(nèi)存空間,因此重要的是,這種儀器的開銷仍然很小。此外,代碼覆蓋工具對性能的影響應(yīng)該最小,以避免在時(shí)間緊迫的系統(tǒng)中出現(xiàn)故障。覆蓋工具通常集成到開發(fā)環(huán)境中--代碼檢測是自動(dòng)的。測試運(yùn)行后,覆蓋分析器生成報(bào)告,允許詳細(xì)查看哪些函數(shù)執(zhí)行了,哪些函數(shù)沒有執(zhí)行。
對于安全性至關(guān)重要的軟件代碼覆蓋是強(qiáng)制性的。標(biāo)準(zhǔn)DO-178C(航空)、ISO26262(汽車)、IN50128(鐵路)和通用標(biāo)準(zhǔn)IC61508(鐵路)規(guī)定了高編碼覆蓋率,直至修改的條件決定覆蓋率(MC/DC),以展示軟件中所有條件或決定的測試。
需要靜態(tài)分析和動(dòng)態(tài)測試,以實(shí)現(xiàn)良好的質(zhì)量
為了保證高質(zhì)量,必須結(jié)合靜態(tài)分析,在執(zhí)行與代碼覆蓋相關(guān)的軟件(動(dòng)態(tài)測試)期間進(jìn)行充分的測試。我們現(xiàn)實(shí)生活中的家用電器項(xiàng)目的例子顯示了為什么需要使用這兩種方法,為什么只有一種測試或分析技術(shù)可能導(dǎo)致致命的后果。
制造商為洗衣機(jī)生產(chǎn)線的控制單元開發(fā)了一個(gè)軟件.它是用C寫的,應(yīng)該是在單片機(jī)上運(yùn)行的。這一相同的控制單元和相同的軟件打算用于這一產(chǎn)品系列的所有機(jī)器;因此,特定的功能將分別與機(jī)器類型打開或關(guān)閉。例如,更昂貴的機(jī)器配備了傳感器,測量洗衣的"染色度",并使程序能夠定制主清洗周期的持續(xù)時(shí)間。更簡單的沒有傳感器的機(jī)器的清洗時(shí)間保持不變.
在MC/DC代碼覆蓋率100%的規(guī)定下,開發(fā)了確保充分軟件質(zhì)量的測試案例。制造商認(rèn)為靜態(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:用于計(jì)算主洗滌周期持續(xù)時(shí)間的功能.
圖1中的函數(shù)根據(jù)所選的清洗程序以及洗衣的負(fù)載大小和"染色度"來計(jì)算清洗周期的持續(xù)時(shí)間。與此功能相關(guān)的是,圖2中列出的測試用例是在模塊測試期間執(zhí)行的,其中"染色度"是測試期間評估的一個(gè)因素。"產(chǎn)品版本"對這個(gè)結(jié)果的影響程度將在后面討論。
|
測試案例編號(hào) |
產(chǎn)品_版本 |
行騙者 |
裝載量 |
染色 |
結(jié)果 |
預(yù)期成果 |
|
1 |
11 |
3 |
4 |
3 |
15 |
15 |
|
2 |
11 |
5 |
4 |
3 |
15 |
15 |
|
3 |
11 |
7 |
4 |
3 |
15 |
15 |
|
4 |
11 |
3 |
6 |
3 |
27 |
27 |
|
5 |
12 |
4 |
2 |
1 |
8 |
7 |
|
6 |
12 |
6 |
2 |
1 |
8 |
7 |
|
7 |
13 |
4 |
4 |
1 |
8 |
8 |
|
8 |
13 |
6 |
4 |
1 |
8 |
8 |
圖2:與功能有關(guān)的已執(zhí)行測試用例 durationMainWashCycle() .
然而,所考慮的功能的測試覆蓋率僅為71%。關(guān)于測試覆蓋率的報(bào)告(圖3)和測試結(jié)果立即揭示了一個(gè)問題:在第31行開頭具有IF-條件的程序路徑
else if (((prog == 4) || (prog == 6)) && (load < 3)) {
return staining * 7;
雖然相關(guān)測試案例(第5號(hào)和第6號(hào))被執(zhí)行,但沒有通過。此外,這些測試案例的實(shí)際測試結(jié)果與預(yù)期結(jié)果不同。測試覆蓋率報(bào)告說明28行的if-狀態(tài)是通過的。
在代碼中交換這兩個(gè)其他條件消除了錯(cuò)誤?，F(xiàn)在,一個(gè)新的測試運(yùn)行使測試覆蓋率達(dá)到95%,與實(shí)際和預(yù)期的測試結(jié)果相匹配。
測試覆蓋率報(bào)告顯示,需要增加一個(gè)測試用例,以達(dá)到100%的測試覆蓋率:
|
測試案例編號(hào) |
產(chǎn)品_版本 |
行騙者 |
裝載量 |
染色 |
結(jié)果 |
預(yù)期成果 |
|
9 |
14 |
6 |
6 |
1 |
9 |
9 |
由于缺少測試用例,達(dá)到了100%的規(guī)定測試覆蓋率。
在成功完成集成測試并解決了一些小問題之后,洗衣機(jī)投入生產(chǎn)并交付。過了一段時(shí)間,一些不高興的顧客抱怨起來.有些機(jī)器的清洗效果不佳,這是因?yàn)榍逑粗芷谔崆敖K止。還有報(bào)告說,機(jī)器將主清洗周期延長幾個(gè)小時(shí)。復(fù)制這種行為證明是不可能的。
最初,有人懷疑染色傳感器出現(xiàn)故障。因此,它們是在保證范圍內(nèi)交換的。然而,很快就清楚,這并沒有解決這個(gè)問題。
在更仔細(xì)地檢查了投訴案件之后,顯然這些案件只限于生產(chǎn)線中的一種特定的機(jī)器類型。因此,考慮了軟件出錯(cuò)的可能性,并委托外部服務(wù)提供者運(yùn)行靜態(tài)代碼分析。
第12型的所有模型對染色傳感器和其他所有模型在恒定染色值下工作的規(guī)定執(zhí)行不當(dāng)。如圖4所示,模型12的變量"Y"在函數(shù)"獲得級別"()仍然沒有初始化,通過一個(gè)未定義的染色度值。
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)品版本而定的染色度的測定。
由于該值在模塊測試中不明顯,所以這個(gè)錯(cuò)誤仍未被發(fā)現(xiàn)。
此外,對簡化代碼的靜態(tài)源代碼分析結(jié)果表明,以前描述的不可訪問代碼部分的錯(cuò)誤很可能已經(jīng)在實(shí)施過程的早期發(fā)現(xiàn)。
只有通過靜態(tài)分析和動(dòng)態(tài)分析才能發(fā)現(xiàn)錯(cuò)誤.不幸的是,靜態(tài)代碼分析只能追溯執(zhí)行洗衣機(jī)制造商。在開發(fā)階段,錯(cuò)誤修正會(huì)更經(jīng)濟(jì).及時(shí)的靜態(tài)分析和動(dòng)態(tài)測試將避免昂貴的產(chǎn)品召回和相關(guān)的形象損失。該電器制造商目前使用靜態(tài)分析和動(dòng)態(tài)測試,對其所有軟件項(xiàng)目進(jìn)行測試覆蓋。
下載文檔
