原創|使用教程|編輯:鄭恭琳|2020-12-21 11:21:46.773|閱讀 222 次
概述:集成到開發人員IDE中的統一測試工具為開發測試提供了最高效的環境。諸如Parasoft C/C++test之類的統一工具使團隊能夠將測試的重點放在高風險和最新修改的代碼上。
# 界面/圖表報表/文檔/IDE等千款熱門軟控件火熱銷售中 >>
集成到開發人員IDE中的統一測試工具為開發測試提供了最高效的環境。諸如Parasoft C/C++test之類的統一工具使團隊能夠將測試的重點放在高風險和最新修改的代碼上。
軟件驗證和確認是軟件開發的固有部分。特定V&V項目的投入和預算取決于許多因素,例如項目的功能安全目標,業務風險級別或組織的質量文化。無論什么因素促使組織實施質量計劃和流程,生產安全和高質量的軟件產品都需要付出更多的決心。
由于許多原因,選擇適當的測試方法是一項艱巨的任務。技術發展日新月異,公司必須選擇采用哪種軟件測試工具。在許多情況下,在開源產品和商業產品之間進行選擇也很困難。
這篇文章說明了如何結合使用自動化測試技術(例如高級靜態分析,運行時內存監視,自動化單元測試和流分析)來改善質量保證流程,并確定實現統一測試工具的好處。此處討論的概念是通用的,可以應用于任何編程語言,但是此處的示例考慮了使用Parasoft C/C++test創建的C和C++編程語言。
在考慮可能的高級軟件故障時,可以區分幾類軟件錯誤:由于缺少需求而導致的錯誤,由錯誤指定的需求引起的錯誤以及由于需求編碼不正確而發生的錯誤。前兩類軟件缺陷屬于需求工程類別,這里不再討論。在這里,我將重點介紹由于實施不當而導致的錯誤,其中包括許多團隊都在努力解決的各種潛在軟件問題。
那么,需求編碼不正確意味著什么?可能有很多事情。以不正確實施的需求為例-旨在檢查正確的實施失敗和測試自動化工具檢測并報告缺陷的單元測試。在另一個示例中,運行時分析工具可能會在單元測試期間檢測到嚴重的內存訪問錯誤,而該錯誤僅從單元測試結果中無法檢測到。如下所示,使用不同的工具更好地檢測某些類型的錯誤。
圖1.軟件缺陷和檢測策略概況。
顯然,并非所有軟件項目都需要使用所有可用技術來測試和提高軟件質量,并且組織面臨著如何平衡預算和質量的難題。與功能安全相關的項目可能會選擇所有可用技術,以確保質量不受影響,并符合軟件安全標準(例如ISO 26262)。其他團隊可能會決定只選擇靜態分析和單元測試,因為它們似乎涵蓋了很大一部分軟件缺陷,而有些團隊可能會發現一個開源的單元測試框架就足夠了。
人們不愿實施多種測試技術,通常是因為擔心使用多種技術會給開發速度帶來巨大的開銷,更不用說預算了。如果團隊決定選擇未集成的工具,那么這更可能是一個真正的問題。多個單獨工具的成本,學習曲線以及在不同使用模型和界面之間進行切換的必要性可能會成問題。結果,開發人員可能會避免使用工具和自動化,因為這會將他們的注意力從編寫代碼重定向到使用工具,從而降低了生產率。
在討論其價值之前,指定一個統一測試工具的期望值很重要。理想情況下,工具應:
統一和集成的測試工具可幫助避免許多問題:
軟件缺陷分為不同的類別,因此不能期望通過一種測試技術來識別所有缺陷。例如,手動系統級測試。為了提供更具體的示例,請遵循以下示例代碼片段:
上面的幾行代碼包含幾個問題。具體來說,在第16行中,開發人員試圖使用在calculateIdx()函數中計算出的索引值來初始化全局緩沖區,但是他們無法驗證其是否在允許范圍內。即使運行了幾十個手動測試會話,它們也可能不會顯示此問題,因為將整數值寫入隨機存儲器位置很少會立即產生引人注目的效果。
但是有一天,很可能是在發布之后,內存布局可能會發生變化,第16行的操作會使應用程序崩潰。有趣的是,由于用于計算索引的循環,靜態分析也可能無法標記該問題。由于性能原因,靜態分析工具中使用的數據和控制流分析必須在合理的時間內應用啟發式方法和簡化方法來完成代碼分析,并且通常將它們循環應用,這意味著可能會遺漏一些錯誤。
一個內存監視工具可以檢測到此錯誤,該工具通過注入特殊檢查來檢測源代碼并報告不正確的內存操作。運行時分析工具僅在實際執行的路徑上檢測軟件問題,而無需做出任何猜測——與靜態分析相比,這是一個很大的優勢,因為報告的問題的準確性非常高。
在此示例中,Parasoft的內存錯誤檢測功能很容易確定問題所在:
同樣可能出現相反的情況——靜態分析可能會檢測到運行時內存監視無法識別的問題。例如,在下面的代碼片段中,第27/28行可能會取消空指針的引用。在人員指針參數為null的情況下調用storePersonToFile函數會導致錯誤,但這僅在retrivePersonFromDB函數返回null時才會發生。在系統測試會話期間不太可能出現這種情況,因為數據庫連接很可能按預期運行,因此運行時內存監視工具保持沉默。但是,靜態分析工具中的流分析很容易檢測到從該函數返回的空指針,并報告潛在的空指針解除引用問題。
圖4.靜態分析結果示例。
總是完美執行但不符合要求的代碼又如何呢?靜態和動態分析對識別此類問題沒有用。要檢測預期結果與實際結果之間的差異,需要將計算結果與預定義值進行比較。有許多實現此類檢查的流行方法,包括手動系統級測試,集成測試和單元測試。
在許多領域中,統一的測試工具可以促進單元測試過程。福利清單包括:
通過使QA團隊參與編寫單元測試的過程,使用圖形向導或編輯器創建測試可以提高整個組織的生產率,從而使他們為開發過程做出積極的貢獻。對于QA團隊成員而言,使用圖形向導比在代碼編輯器中編寫適當的測試代碼要容易得多,因為使用輸入表單(如下所示)配置值不需要高級編碼技能,并且耗時更少,尤其是在團隊成員缺乏經驗的情況下。例如,下面的屏幕截圖顯示了Parasoft C/C++test的C/C++單元測試功能示例,該向導可幫助創建單元測試。
使用統一測試工具的另一個好處是它提供有關測試的完整性和關鍵業務需求的運行狀況的反饋。即使語句覆蓋率報告顯示較高的值,MC/DC覆蓋率報告中的數字較低也可能表示分支覆蓋范圍不足。這種分析需要一個支持多個覆蓋率指標的工具鏈,從而使團隊可以從簡單的事情開始,例如行或語句覆蓋率,并在改進測試用例的過程中逐步實現更徹底的代碼覆蓋率。
單元測試和系統測試覆蓋率報告是有關測試過程的大量信息來源,尤其是結合使用時。但是,如果測試結果與需求不相關,則團隊將缺少一些關鍵信息。通過查看“測試到需求”可追溯性報告,您可以快速確定需求覆蓋的狀態。此類報告的示例如下所示:
將需求與不同類型的測試結果相關聯的能力是使用統一測試工具的巨大好處。可以將單元測試、系統測試、集成測試結果以及編碼標準和代碼度量結果進行關聯,以提供有關關鍵和非關鍵需求的運行狀況的反饋。
當您將項目中使用的各種測試技術中的數據組合在一起時,您可以獲得二級指標和更復雜的分析。使用統一的測試工具,團隊可以從全新的角度查看代碼。失敗的單元測試用例對開發人員而言可能具有不同的含義,這取決于發生在通過代碼度量分析評定為高風險或低風險的代碼中。如果將此信息與源代碼控制中的統計信息進一步結合在一起,并與需求相關聯,則團隊可以就何時以及如何更正代碼做出更好的決策。
使用Parasoft工具套件,您可以利用基于變更的測試來提高團隊生產力。基于變更的測試技術捕獲源代碼,測試用例和代碼覆蓋率結果之間的關系,以計算最佳的測試用例集,以驗證和確認特定的代碼增量。實際上,團隊可以通過只運行一小部分測試而不是完整的回歸套件來限制其測試會話。這種只測試絕對必要條件的方法可以節省大量資金,特別是對于中型或大型項目。
上面討論的所有測試技術都可以在Parasoft C/C++test和Parasoft DTP中使用。Parasoft C/C++test是用于C和C++項目的統一測試工具。C/C++test可作為流行IDE(如Eclipse和Visual Studio)的插件提供。與IDE的緊密集成可防止上述問題。開發人員可以在編寫代碼時立即運行編碼標準符合性檢查或執行單元測試。質量保證小組成員可以在監視應用程序的代碼覆蓋率和運行時錯誤的同時執行手動測試方案。離線分析(例如靜態分析提供的流量分析)可以在連續集成階段中執行。服務器會話由方便的命令行界面支持,可將分析結果報告給Parasoft DTP,后者會匯總來自開發環境的信息。Parasoft DTP提供了廣泛的報告功能,包括集成來自第三方工具的數據,將測試結果發送到開發人員的IDE以及計算高級分析的能力。在工作流的每個階段提供的連續反饋可加快敏捷開發速度,并降低達到安全標準要求的成本。
還應注意,此處討論的質量保證過程和體系結構的方法不限于C/C++項目。Parasoft為Java和C#/.NET提供了類似的解決方案。
軟件質量改進不是一項統一的工作,它需要不同的技術來消除不同類型的軟件缺陷。關鍵的挑戰是如何以有效和高效的方式做到這一點,從而避免破壞性的項目預算并損害開發人員的士氣。集成到開發人員IDE中的統一測試工具為開發測試提供了最高效的環境。諸如Parasoft C/C++test之類的統一工具具有統一測試各個方面的指標和結果的能力,通過允許團隊將測試重點放在高風險和最新修改的代碼上,從而提供了額外的好處。
本站文章除注明轉載外,均為本站原創或翻譯。歡迎任何形式的轉載,但請務必注明出處、不得修改原文相關鏈接,如果存在內容上的異議請郵件反饋至chenjj@fc6vip.cn