轉帖|行業資訊|編輯:蔣永|2016-11-02 14:28:56.000|閱讀 401 次
概述:您知道分析一些測試工具所產生的問題報告時間遠超您的預估時間嗎?還記得我們開始去接觸測試工具和使用工具的初衷嗎?
# 界面/圖表報表/文檔/IDE等千款熱門軟控件火熱銷售中 >>
最近Parasoft做過一個關于測試工具尤其是靜態分析技術的調查報告,收集大家對于測試工具的使用印象和技術總結。其中有一個經驗豐富的資深軟件工程師Brian,他在靜態分析工具上頗有經驗,但他反饋的結果是這些工具報告的很多問題總是類似“編譯器警告”,并非絕對的潛在漏洞(bug)或軟件缺陷。深入溝通交流后發現,他的這些印象最主要的原因是因為他所采用的測試工具大部分是免費軟件,而且所接受的相關培訓很多時候僅限于網絡論壇,這樣帶來的結果必然是測試工具并不能實際解決問題,反而用于學習工具的時間超過了實際解決問題的時間,這有些本末倒置了。
所以,測試工具的要求(尤其是靜態分析技術)除了通常大家所知的自動化屬性,其實還需要更多考量測試報告結果的度量性和有效性,以用戶角度去幫助客戶快速應用先進測試技術并解決代碼問題。眾所周知,嵌入式行業的軟件復雜性高,設計的平臺豐富,各種不同的芯片和架構,紛繁的編譯器種類等等。這必然要求一個成熟的開發測試平臺體系,以及專業的技術支持服務,尤其是對于嵌入式行業。
各大嵌入式行業如醫療、汽車、鐵路、航空航天等的軟件開發者每天都可能會遇到校驗軟件問題(bug)的有效性挑戰,接受從客戶、技術支持團隊及質量測試部門的反饋結果并及時調查給予響應。對于開發人員來說,有時候昨天已經做過的修復工作都有可能產生新的軟件問題從而加大工作任務。
所以軟件問題的結果驗證是一個值得非常關注的問題,需要能夠有效并快速地區分各種性質的問題,對不同的問題進行自動優先級排序,將重心放在有價值的問題上,快速高效地推進問題的解決。如果這只是一個低等級的警告問題,它不是一個錯誤或潛在bug,并不值得浪費太多時間或優先處理。
目前的情況是,許多開發測試工具無法用一個簡潔方便的方式幫助用戶定位真正有價值的問題。所以,這里對于一個成熟的靜態分析測試工具基本提出了以下關鍵技術屬性需求點:
針對Java、C/C++、.Net等主流語言的軟件產品開發, Parasoft公司提供了一個企業級的開發測試解決方案。除了全方位的靜態代碼分析能力如模式匹配分析、數據流分析和度量分析等,該開發測試平臺還具備良好的擴展性,包括了單元測試,集成測試,運行時錯誤檢測,代碼審查,覆蓋率分析等功能,可以自動化生成測試用例,執行單元測試的同時提供多種視角的覆蓋率分析,提供圖形化報表系統,是一個完善的方案級平臺,全方位落實自動化缺陷預防政策,保障客戶產品質量的同時提高軟件產品交付速度。
很多免費測試工具或不成熟的測試產品有時會報告超過20000個任務給到具體的一個開發人員,這其實是缺乏一定的測試規控,沒有人能夠一天處理這么多的事情。一個成熟的開發測試策略將根據任務的嚴重性和風險劃分優先等級。此外,它將根據整個團隊的工作負載進行工作分配并利用個人優勢區別劃分測試任務。
Parasoft某醫療行業軟件客戶:“當我和我的新朋友確定,他認為每天修復5個靜態分析的違反規則是沒有問題的。如果他有一個十人的團隊,每個人每天修復5個靜態分析違反規則,然后他需要大約400天才能看到優美的代碼。”
讓我們再進一步。不是所有的靜態分析行為都是平等的。如果我們將最高等級的風險、最嚴峻的問題提前嘗試解決,那么軟件的質量、安全性、可靠性將被在1-2個月內梳理的非常合理。而每個問題都僅需要分配幾乎忽略不計的5分鐘,這將比之前很多所經歷的發布周期耗時更短更高效。
更棒的是,一個成熟的開發測試平臺將自動管理靜態分析任務的優先級和分配給不同的負責人。作為管理者,在一開始就設置一些團隊測試政策,這些政策將確保團隊里的每一個成員每天都得到適量的最高優先級的任務,從而實現快速高效的團隊工作流程。
本文來自()
活動時間:11月1日-11月30日
本站文章除注明轉載外,均為本站原創或翻譯。歡迎任何形式的轉載,但請務必注明出處、不得修改原文相關鏈接,如果存在內容上的異議請郵件反饋至chenjj@fc6vip.cn