你真正需要的程式碼測試覆蓋率是多少?

發表於2011-04-25

我寫這篇文章的起因是由於看了@unclebobmartin在微博上的一些看起來言之鑿鑿的話語。給那些不認識Uncle Bob的人介紹一下——他是我們軟體產業裡最著名的一個專家,是《 Clean Code(程式碼整潔之道)》這本著作的作者,是敏捷宣言(Agile Manifesto)的簽署人之一。在上世紀九十年代,他對文獻最佳物件導向實踐方法貢獻了很大的力量。所以,當他說話時,我們一定要關注一下。

他給我們日常的TDD和單元測試製訂了一個最高綱領。我們可以從他的微博裡清楚的看到這點:

“兩件事。可重複性和成本。跟自動化測試比起來,手工測試的成本高的可怕。”

“手工測試不是測試;那是在做實驗。只要有人的因素牽涉其中,那結果就必然可疑。”

“你們告訴我的實際意思就是讓我大開方便之門、不去測試某些程式。哼…”
“程式碼覆蓋率100%並不是成績,那是最低要求。即使只寫了一行程式碼,你也要測試它。”
他接著把軟體測試跟在其它領域裡常見的但被認為很關鍵的活動進行了比較:

“戰地外科醫生也許沒有最夠的時間做嚴格的消毒,但這帶來的風險可能是死亡或高昂的治療代價。”
“會計難道只會把80%的資料表做雙份備份嗎?”

“有多少回你們都看到了那些嚴重的當機事故都是因為一些愚蠢的程式設計師以為那些愚蠢的程式碼不許要經過測試而導致的?“

他的所有這些觀點都很有價值,但他只向我們展示了問題的一面。現實中並不是所有的應用都需要如此謹小慎微的測試。並不是所有的應用都跟戰地手術或鉅額資金核算那麼重要。(更不要說在很多情況下的為”合理避稅“而做的帳務:))。

一個更重要的原因是,100%的測試覆蓋率並不能保證bug的不出現。就連Uncle Bob自己也承認:

”測試並不能杜絕bug。但測試能保證程式的行為是符合預期的。“

這很顯然指的是:同一個程式設計師在程式裡埋下的概念性或邏輯性錯誤,由他自己測是絕對測不出來的。

最終,所有的問題歸結於ROI(投資收回率)和實用主義。有些應用比其它應用需要更多的測試。有些bug需要比其它bug投入更多的精力去修復。究竟是否需要在自動化測試是投入更多的時間和財力,或多少覆蓋率是合適的還是過分了,這都需要人的主觀判斷。

原作者:Philopator Ptolemy  譯文:外刊IT評論

 

相關文章