集成到開發(fā)人員IDE中的統(tǒng)一測試工具為開發(fā)測試提供了最高效的環(huán)境。諸如Parasoft C/C++test之類的統(tǒng)一工具使團隊能夠?qū)y試的重點放在高風險和最新修改的代碼上。

軟件驗證和確認是軟件開發(fā)的固有部分。特定V＆V項目的投入和預算取決于許多因素，例如項目的功能安全目標，業(yè)務風險級別或組織的質(zhì)量文化。無論什么因素促使組織實施質(zhì)量計劃和流程，生產(chǎn)安全和高質(zhì)量的軟件產(chǎn)品都需要付出更多的決心。

由于許多原因，選擇適當?shù)臏y試方法是一項艱巨的任務。技術(shù)發(fā)展日新月異，公司必須選擇采用哪種軟件測試工具。在許多情況下，在開源產(chǎn)品和商業(yè)產(chǎn)品之間進行選擇也很困難。

這篇文章說明了如何結(jié)合使用自動化測試技術(shù)（例如高級靜態(tài)分析，運行時內(nèi)存監(jiān)視，自動化單元測試和流分析）來改善質(zhì)量保證流程，并確定實現(xiàn)統(tǒng)一測試工具的好處。此處討論的概念是通用的，可以應用于任何編程語言，但是此處的示例考慮了使用Parasoft C/C++test創(chuàng)建的C和C++編程語言。

缺陷類別和工具自動化

在考慮可能的高級軟件故障時，可以區(qū)分幾類軟件錯誤：由于缺少需求而導致的錯誤，由錯誤指定的需求引起的錯誤以及由于需求編碼不正確而發(fā)生的錯誤。前兩類軟件缺陷屬于需求工程類別，這里不再討論。在這里，我將重點介紹由于實施不當而導致的錯誤，其中包括許多團隊都在努力解決的各種潛在軟件問題。

那么，需求編碼不正確意味著什么？可能有很多事情。以不正確實施的需求為例-旨在檢查正確的實施失敗和測試自動化工具檢測并報告缺陷的單元測試。在另一個示例中，運行時分析工具可能會在單元測試期間檢測到嚴重的內(nèi)存訪問錯誤，而該錯誤僅從單元測試結(jié)果中無法檢測到。如下所示，使用不同的工具更好地檢測某些類型的錯誤。

圖1.軟件缺陷和檢測策略概況。

顯然，并非所有軟件項目都需要使用所有可用技術(shù)來測試和提高軟件質(zhì)量，并且組織面臨著如何平衡預算和質(zhì)量的難題。與功能安全相關(guān)的項目可能會選擇所有可用技術(shù)，以確保質(zhì)量不受影響，并符合軟件安全標準（例如ISO 26262）。其他團隊可能會決定只選擇靜態(tài)分析和單元測試，因為它們似乎涵蓋了很大一部分軟件缺陷，而有些團隊可能會發(fā)現(xiàn)一個開源的單元測試框架就足夠了。

人們不愿實施多種測試技術(shù)，通常是因為擔心使用多種技術(shù)會給開發(fā)速度帶來巨大的開銷，更不用說預算了。如果團隊決定選擇未集成的工具，那么這更可能是一個真正的問題。多個單獨工具的成本，學習曲線以及在不同使用模型和界面之間進行切換的必要性可能會成問題。結(jié)果，開發(fā)人員可能會避免使用工具和自動化，因為這會將他們的注意力從編寫代碼重定向到使用工具，從而降低了生產(chǎn)率。

統(tǒng)一測試工具的價值

在討論其價值之前，指定一個統(tǒng)一測試工具的期望值很重要。理想情況下，工具應：

• 支持多種測試技術(shù)
• 易于使用
• 檢測功能問題和回歸
• 提供從需求到測試的可追溯性
• 衡量代碼的復雜性，可移植性和可維護性
• 通過在編寫代碼時提供即時反饋來教育開發(fā)人員
• 提供有關(guān)開發(fā)進度的信息
• 結(jié)合不同技術(shù)的結(jié)果進行高級分析

統(tǒng)一和集成的測試工具可幫助避免許多問題：

• 通過使用具有不同接口的分離式工具，出現(xiàn)多個學習曲線和可用性問題
• 分散開發(fā)人員編寫代碼的注意力
• 防止工具鏈的不同元素之間的信息交換

檢測盡可能多的缺陷

軟件缺陷分為不同的類別，因此不能期望通過一種測試技術(shù)來識別所有缺陷。例如，手動系統(tǒng)級測試。為了提供更具體的示例，請遵循以下示例代碼片段：

上面的幾行代碼包含幾個問題。具體來說，在第16行中，開發(fā)人員試圖使用在calculateIdx()函數(shù)中計算出的索引值來初始化全局緩沖區(qū)，但是他們無法驗證其是否在允許范圍內(nèi)。即使運行了幾十個手動測試會話，它們也可能不會顯示此問題，因為將整數(shù)值寫入隨機存儲器位置很少會立即產(chǎn)生引人注目的效果。

但是有一天，很可能是在發(fā)布之后，內(nèi)存布局可能會發(fā)生變化，第16行的操作會使應用程序崩潰。有趣的是，由于用于計算索引的循環(huán)，靜態(tài)分析也可能無法標記該問題。由于性能原因，靜態(tài)分析工具中使用的數(shù)據(jù)和控制流分析必須在合理的時間內(nèi)應用啟發(fā)式方法和簡化方法來完成代碼分析，并且通常將它們循環(huán)應用，這意味著可能會遺漏一些錯誤。

一個內(nèi)存監(jiān)視工具可以檢測到此錯誤，該工具通過注入特殊檢查來檢測源代碼并報告不正確的內(nèi)存操作。運行時分析工具僅在實際執(zhí)行的路徑上檢測軟件問題，而無需做出任何猜測——與靜態(tài)分析相比，這是一個很大的優(yōu)勢，因為報告的問題的準確性非常高。

在此示例中，Parasoft的內(nèi)存錯誤檢測功能很容易確定問題所在：

同樣可能出現(xiàn)相反的情況——靜態(tài)分析可能會檢測到運行時內(nèi)存監(jiān)視無法識別的問題。例如，在下面的代碼片段中，第27/28行可能會取消空指針的引用。在人員指針參數(shù)為null的情況下調(diào)用storePersonToFile函數(shù)會導致錯誤，但這僅在retrivePersonFromDB函數(shù)返回null時才會發(fā)生。在系統(tǒng)測試會話期間不太可能出現(xiàn)這種情況，因為數(shù)據(jù)庫連接很可能按預期運行，因此運行時內(nèi)存監(jiān)視工具保持沉默。但是，靜態(tài)分析工具中的流分析很容易檢測到從該函數(shù)返回的空指針，并報告潛在的空指針解除引用問題。

圖4.靜態(tài)分析結(jié)果示例。

檢測功能性問題和回歸

總是完美執(zhí)行但不符合要求的代碼又如何呢？靜態(tài)和動態(tài)分析對識別此類問題沒有用。要檢測預期結(jié)果與實際結(jié)果之間的差異，需要將計算結(jié)果與預定義值進行比較。有許多實現(xiàn)此類檢查的流行方法，包括手動系統(tǒng)級測試，集成測試和單元測試。

在許多領(lǐng)域中，統(tǒng)一的測試工具可以促進單元測試過程。福利清單包括：

• 例如，通過提供用于創(chuàng)建、編輯和配置測試用例的圖形向?qū)В趧?chuàng)建測試用例時提高開發(fā)人員的生產(chǎn)力
• 與Test Double框架集成，可輕松進行模擬和存根，以模擬復雜的測試場景，而無需涉及大型代碼庫
• 將測試用例與代碼覆蓋率報告相關(guān)聯(lián)，以評估測試的完整性
• 通過自動計算驗證代碼增量所需的最少測試用例集來優(yōu)化測試會話
• 合并其他測試技術(shù)（例如手動/系統(tǒng)級測試或集成測試）的代碼覆蓋率報告，以識別未經(jīng)測試的代碼
• 將結(jié)果追溯到需求，以更好地了解失敗的測試的影響

通過使QA團隊參與編寫單元測試的過程，使用圖形向?qū)Щ?編輯器創(chuàng)建測試可以提高整個組織的生產(chǎn)率，從而使他們?yōu)殚_發(fā)過程做出積極的貢獻。對于QA團隊成員而言，使用圖形向?qū)П仍诖a編輯器中編寫適當?shù)臏y試代碼要容易得多，因為使用輸入表單（如下所示）配置值不需要高級編碼技能，并且耗時更少，尤其是在團隊成員缺乏經(jīng)驗的情況下。例如，下面的屏幕截圖顯示了Parasoft C/C++test的C/C++單元測試功能示例，該向?qū)Э蓭椭鷦?chuàng)建單元測試。

使用統(tǒng)一測試工具的另一個好處是它提供有關(guān)測試的完整性和關(guān)鍵業(yè)務需求的運行狀況的反饋。即使語句覆蓋率報告顯示較高的值，MC/DC覆蓋率報告中的數(shù)字較低也可能表示分支覆蓋范圍不足。這種分析需要一個支持多個覆蓋率指標的工具鏈，從而使團隊可以從簡單的事情開始，例如行或語句覆蓋率，并在改進測試用例的過程中逐步實現(xiàn)更徹底的代碼覆蓋率。

測試可追溯性的要求

單元測試和系統(tǒng)測試覆蓋率報告是有關(guān)測試過程的大量信息來源，尤其是結(jié)合使用時。但是，如果測試結(jié)果與需求不相關(guān)，則團隊將缺少一些關(guān)鍵信息。通過查看“測試到需求”可追溯性報告，您可以快速確定需求覆蓋的狀態(tài)。此類報告的示例如下所示：

將需求與不同類型的測試結(jié)果相關(guān)聯(lián)的能力是使用統(tǒng)一測試工具的巨大好處。可以將單元測試、系統(tǒng)測試、集成測試結(jié)果以及編碼標準和代碼度量結(jié)果進行關(guān)聯(lián)，以提供有關(guān)關(guān)鍵和非關(guān)鍵需求的運行狀況的反饋。

結(jié)合不同技術(shù)的結(jié)果進行高級分析

當您將項目中使用的各種測試技術(shù)中的數(shù)據(jù)組合在一起時，您可以獲得二級指標和更復雜的分析。使用統(tǒng)一的測試工具，團隊可以從全新的角度查看代碼。失敗的單元測試用例對開發(fā)人員而言可能具有不同的含義，這取決于發(fā)生在通過代碼度量分析評定為高風險或低風險的代碼中。如果將此信息與源代碼控制中的統(tǒng)計信息進一步結(jié)合在一起，并與需求相關(guān)聯(lián)，則團隊可以就何時以及如何更正代碼做出更好的決策。

使用Parasoft工具套件，您可以利用基于變更的測試來提高團隊生產(chǎn)力。基于變更的測試技術(shù)捕獲源代碼，測試用例和代碼覆蓋率結(jié)果之間的關(guān)系，以計算最佳的測試用例集，以驗證和確認特定的代碼增量。實際上，團隊可以通過只運行一小部分測試而不是完整的回歸套件來限制其測試會話。這種只測試絕對必要條件的方法可以節(jié)省大量資金，特別是對于中型或大型項目。

放在一起：Parasoft C/C++test和DTP

上面討論的所有測試技術(shù)都可以在Parasoft C/C++test和Parasoft DTP中使用。Parasoft C/C++test是用于C和C++項目的統(tǒng)一測試工具。C/C++test可作為流行IDE（如Eclipse和Visual Studio）的插件提供。與IDE的緊密集成可防止上述問題。開發(fā)人員可以在編寫代碼時立即運行編碼標準符合性檢查或執(zhí)行單元測試。質(zhì)量保證小組成員可以在監(jiān)視應用程序的代碼覆蓋率和運行時錯誤的同時執(zhí)行手動測試方案。離線分析（例如靜態(tài)分析提供的流量分析）可以在連續(xù)集成階段中執(zhí)行。服務器會話由方便的命令行界面支持，可將分析結(jié)果報告給Parasoft DTP，后者會匯總來自開發(fā)環(huán)境的信息。Parasoft DTP提供了廣泛的報告功能，包括集成來自第三方工具的數(shù)據(jù)，將測試結(jié)果發(fā)送到開發(fā)人員的IDE以及計算高級分析的能力。在工作流的每個階段提供的連續(xù)反饋可加快敏捷開發(fā)速度，并降低達到安全標準要求的成本。

還應注意，此處討論的質(zhì)量保證過程和體系結(jié)構(gòu)的方法不限于C/C++項目。Parasoft為Java和C#/.NET提供了類似的解決方案。

結(jié)論

軟件質(zhì)量改進不是一項統(tǒng)一的工作，它需要不同的技術(shù)來消除不同類型的軟件缺陷。關(guān)鍵的挑戰(zhàn)是如何以有效和高效的方式做到這一點，從而避免破壞性的項目預算并損害開發(fā)人員的士氣。集成到開發(fā)人員IDE中的統(tǒng)一測試工具為開發(fā)測試提供了最高效的環(huán)境。諸如Parasoft C/C++test之類的統(tǒng)一工具具有統(tǒng)一測試各個方面的指標和結(jié)果的能力，通過允許團隊將測試重點放在高風險和最新修改的代碼上，從而提供了額外的好處。