通過(guò)測試避免嵌入式軟件缺陷
商務(wù)期望與在開(kāi)發(fā)和測試過(guò)程中的要求演變之間的這種隔閡原因比字面意義上要深刻得多。這是與傳統組織文化相關(guān)的典型癥狀,即工程師認為商務(wù)人員不理解軟件開(kāi)發(fā)過(guò)程的復雜性。與此同時(shí),組織的商務(wù)側人員認為工程師患有聰明開(kāi)發(fā)人員綜合病癥(SDS)——一種病態(tài)失調,即工程師所做的都是他們認為最好的,因為他們聰明嘛。
實(shí)現策略
那么解決方案是什么?一個(gè)組織如何在商務(wù)目標和開(kāi)發(fā)過(guò)程之間架起溝通的橋梁?策略是確保工程師提供滿(mǎn)足期望值的軟件的關(guān)鍵,并且將品質(zhì)意識根植于軟件開(kāi)發(fā)流程。通過(guò)實(shí)現策略驅動(dòng)的開(kāi)發(fā)方法,組織就可以在從創(chuàng )建到支持的整個(gè)軟件開(kāi)發(fā)周期內降低風(fēng)險、提高產(chǎn)能并降低成本。策略驅動(dòng)的開(kāi)發(fā)基礎是三個(gè)核心行動(dòng):
1. 定義策略形式的期望值,并以此指導工程師如何開(kāi)發(fā)和測試軟件
2. 在驅動(dòng)這些策略的商務(wù)目標方面培訓工程師
3. 在適當的基礎設施幫助下自動(dòng)監視策略的堅持力
清晰地定義可實(shí)施和可測量的策略可形成前后一致性和很高的精度,確保用文字定義的嚴格質(zhì)量過(guò)程能夠貫徹實(shí)行。此外,為了高效地達到清晰性和可測量性,策略增強自動(dòng)化很有必要。
指導方針還是策略
如果你詢(xún)問(wèn)一個(gè)組織的開(kāi)發(fā)策略,許多人會(huì )很快指向他們的最佳實(shí)踐和指導方針。但指導方針和策略是不可互換的兩個(gè)概念。指導方針描述建議的行為,而策略描述期望的行為。所有策略都有以下三個(gè)組成部分:
● 策略必須是自動(dòng)可實(shí)施的:人工檢查工程師是否遵循策略是不可行的。必須使用某種自動(dòng)機制來(lái)檢查違例并加以提醒。
● 策略違例提醒必須有針對性:只有所編寫(xiě)的代碼違反策略的工程師才應被提醒。這樣,符合策略的工程師可以繼續不中斷地工作。
● 必須制定糾正策略違例的自動(dòng)化工作流程:應該定義工程師發(fā)現和處理策略違例的方法并實(shí)現自動(dòng)化。
對嵌入式軟件組織來(lái)說(shuō)好消息是,有現成的技術(shù)可用來(lái)自動(dòng)執行策略,如果執行正確的話(huà),可以改善質(zhì)量、提高產(chǎn)能、降低開(kāi)發(fā)成本和風(fēng)險。
策略與過(guò)程的匹配
“胡佛水壩必須滴水不漏”是一個(gè)合理的策略,它以平實(shí)明確的語(yǔ)言確立了一個(gè)組織的目標?,F在考慮“每天檢查一次漏水情況”的策略。表面上,這個(gè)策略似乎可以推動(dòng)組織朝目標邁進(jìn),但更仔細的檢查可以暴露出在許多嵌入式開(kāi)發(fā)商店中流行的缺點(diǎn)類(lèi)型。
這種策略達不到預期效果的地方是它允許問(wèn)題先發(fā)生。它不是支持第一個(gè)策略的目標,而只是檢查與不能滿(mǎn)足在“胡佛水壩必須滴水不漏”中確定的組織目標相關(guān)的癥狀。遺憾的是,許多開(kāi)發(fā)測試實(shí)踐都遵循這種治標不治本的模型。
一個(gè)好得多的策略是“每天加強水壩的最弱點(diǎn)”。通過(guò)匹配策略和過(guò)程來(lái)滿(mǎn)足想要的商務(wù)目標,你可以創(chuàng )建一個(gè)框架來(lái)確保并保持嵌入式軟件的強度、安全性和可靠性。
圖1:靜態(tài)增強編碼策略的開(kāi)發(fā)測試平臺。
策略與開(kāi)發(fā)測試
開(kāi)發(fā)測試是在整個(gè)開(kāi)發(fā)過(guò)程中對軟件測試行為的持續整合。它可以減少技術(shù)過(guò)失,防止缺陷生成,這是在應用生命期內提高效率和降低風(fēng)險的關(guān)鍵。開(kāi)發(fā)測試平臺是實(shí)現開(kāi)發(fā)測試實(shí)踐一致性應用自動(dòng)化的基礎設施,這些實(shí)踐活動(dòng)包括靜態(tài)分析、單元測試、對端檢查、覆蓋率分析、運行時(shí)錯誤檢測,以及精確和客觀(guān)地測量產(chǎn)能和應用質(zhì)量。
每個(gè)組織可能發(fā)現不同的開(kāi)發(fā)測試活動(dòng)在特定環(huán)境下更有價(jià)值。策略驅動(dòng)的開(kāi)發(fā)測試可以確保這些開(kāi)發(fā)測試活動(dòng)以?xún)r(jià)值集中的、風(fēng)險明確的、可核查的方式得到正確實(shí)施。開(kāi)發(fā)測試平臺接受策略形式的輸入,并將它們翻譯成一套定義一個(gè)或更多過(guò)程的規則。這種平臺使該過(guò)程自動(dòng)化、跟蹤策略的持續性并驗證結果是否符合期望值。也就是說(shuō),開(kāi)發(fā)測試平臺可以讓商務(wù)領(lǐng)導更好地控制開(kāi)發(fā)過(guò)程,并更好地觀(guān)察過(guò)程改變的效果。
本文小結
值得注意的是,開(kāi)發(fā)測試并不能替代品質(zhì)管理(QA),而是作為確認軟件功能是否正確實(shí)現了最初意圖的一個(gè)過(guò)程。開(kāi)發(fā)測試也不只是測試過(guò)程的“左移”。開(kāi)發(fā)測試的出現代表了與業(yè)界組織目前采用的更多反復、更為靈活的開(kāi)發(fā)過(guò)程的一致性。開(kāi)發(fā)測試是軟件開(kāi)發(fā)行為的一種模型,如果能夠貫徹執行,將形成一種軟件缺陷無(wú)法生存的環(huán)境。
評論