Coverity談“開發中測試”與程式設計師最常犯的編碼錯誤

Coverity公司位於美國加州舊金山，他們的產品包括Coverity Integrity Control、Coverity Static Analysis等一系列程式碼分析工具與解決方案。日前，Coverity公司產品副總Ezi Boteach先生就“開發中測試”、程式碼複查和開發人員最常犯的編碼錯誤接受了採訪。

　　問題：能否介紹下Coverity的“開發中測試”理念和你們的Development Testing Platform？

　　Ezi：“開發中測試”是新出現的一種技術，包括一系列流程和軟體，例如靜態分析。開發中測試的目的是要幫助開發人員、管理層和業務人員能在開發週期的早期，找到並修復質量和安全方面的問題，這些程式碼還在開發之中，不會影響上市時間、成本或客戶滿意度。

　　“開發中測試”擴大了傳統測試範圍，可以包括功能測試、效能測試和安全稽核，為開發團隊提供更快、更便捷的方式來測試程式碼中的缺陷，而且是以非侵入的方式。這種方式下，開發人員能夠把注意力集中在創新上，管理層能夠在開發週期早期儘早瞭解問題以作出決策，業務人員能持續向市場交付高質量的產品，獲得競爭優勢。

　　問題：程式碼複查是人們高度推薦的程式設計實踐。如果使用你們的產品，對於程式碼複查，您有什麼建議？

　　Ezi：程式碼複查是軟體“開發中測試”很重要的部分，而且其成本很高，因為需要另一個開發人員來複審程式碼，很多時候這個開發人員還必須是資深人員。在程式碼複查之前先做靜態分析，這能讓程式碼複審過程更快，而且成本更低。使用自動化分析來檢查變更以及於系統其他部分的整合點，以此來識別和消滅程式碼錯誤，程式碼複審就可以更集中於邏輯和功能錯誤，而不是程式碼的缺陷，這樣做更划算，能夠自動化，而且易於重複。

　　我們推薦測試驅動開發所有的工具和實踐，包括程式碼複審、單元測試和程式碼覆蓋率。當然，要是能和Coverity的自動化程式碼測試工具一起使用就更好了。

　　問題：你們的產品如何與像xUnit這樣的工具一起配合使用？

　　Ezi：單元測試是“開發中測試”的重要組成，需要支援測試驅動開發。使用Coverity 5.5，我們引入了“開發中測試”的平臺，能夠讓多種不同工具與測試工作流整合。目前我們還不能專門與xUnit整合在一起，但是我們的客戶現在能夠很方便地把他們使用的測試工具與Coverity Development Testing平臺整合。舉個例子：Coverity 5.5.1版本包括與常用Java靜態分析工具FindBugs的整合。這樣的整合讓管理人員能夠降低維護多個測試工具的成本，並通過統一的工具來推行策略。開發人員也有統一的介面來檢視缺陷，並排定解決的優先順序。

　　問題：你們的產品是否能與持續交付流程整合？

　　Ezi：Coverity Static Analysis可以與多個構建系統整合，包括Jenkins這個常用的持續整合系統。一般來說，與Jenkins和持續整合系統的整合是為了確保所有的持續構建都能執行自動化程式碼測試工具。如果分析中發現了新的缺陷，一個構建版本就是失敗的。這確保新的缺陷不會引入到交付的軟體的主幹程式碼中，而交付過程是持續交付流程的一部分。這也能保證失敗的構建版本不會進入流程的下一個階段，一般來說是QA階段。Coverity就像是交付過程中的一道閘門。

　　問題：除了使用你們的產品，您是否還能為開發人員和架構師提供一些其他的原則與實踐？

　　Ezi：確保軟體的質量，防止安全漏洞，這需要良好協作、工具和開發流程管理這幾方面的結合。從清晰的需求文件開始，這是開發任何新功能的基礎。需求文件之後，就是功能和系統架構師完成的功能和需求設計。程式碼開發完成後，“開發中測試”應該是這個流程的有機部分。不僅僅是一個產品，而應該是流程和技術的組合，幫助開發組織在開發週期早期、撰寫程式碼的時候，就能修復軟體的問題，確保代價高昂的缺陷不會進入後續階段和生產環境。

　　架構師要確保軟體的架構良好。這需要人工複審和架構分析，此外還要有經過考驗的軟體開發方法論。與之類似，開發人員也要保證，除了使用靜態和動態分析的自動化測試之外，也要使用程式碼複審和單元測試。質量保證（QA）是任何軟體開發過程中都很重要的階段，以確保功能測試和效能測試順利通過。最後，安全稽核也很重要，保證在識別、修復、移除程式碼缺陷時不會帶入新的安全漏洞。

　　問題：根據Coverity收集的資料，您能否列舉一些開發人員最常犯的錯誤？

　　Ezi：開源專案SCAN（scan.coverity.com）能夠很好地發現開發人員常犯的錯誤。從2006年開始，Coverity與美國國土安全部一起，研發了Coverity SCAN專案，來保證開源軟體的安全性和完整性。Coverity SCAN分析了超過290個開源專案，包括Linux、Apache、PHP和Android，識別出49，654個缺陷，開源軟體開發人員已經修復了超過15，000個缺陷。蝦米的表格就展示出了開源軟體中最常出現的缺陷，商業軟體也與之類似。

	SCAN專案中的出現頻率	風險程度
NULL指標引用	27.60%	中
資源洩露	23.19%	高
非原意圖表示式	9.76%	中
讀未初始化的值	8.41%	高
釋放後使用	5.91%	高
緩衝區溢位	5.52%	高

　　很重要的一點要指出：像NULL指標引用、記憶體洩露和緩衝區溢位常常會帶來很嚴重的質量和安全風險。很多這樣的缺陷，使用傳統的測試方法，有時難以找到。使用Coverity的工具會更易於發現類似問題。

　　要想了解更多關於SCAN專案的資訊，可以訪問 2010 SCAN報告，其中包括對於Android核心程式碼的分析結果。

　　問題：對於程式碼分析視覺化的重要性，程式設計師們認識得越來越明白了。您能否列出3個最重要的相關分析圖？

　　Ezi：Coverity的Development Testing平臺能以程式碼視覺化形式讓開發人員和管理層看到程式碼的質量。視覺化能夠在幾個方面起到幫助作用：它有助於標識程式碼的所有者和缺陷，能幫助展示出軟體程式碼的整體可讀性，以及質量和安全風險較高的程式碼區域，還能有助於推行程式碼完整性的檢查策略。

　　只談3個圖很困難，但我想選的是：未解決的缺陷與已解決的缺陷的對比、每個軟體元件中的缺陷個數、新的Integrity Control熱度圖。

本文出自seven的測試人生公眾號最新內容請見作者的GitHub頁：http://qaseven.github.io/