軟件驗證和測試是軟件開發(fā)必不可少的部分。投入到特定項目中的努力和預(yù)算取決于許多因素，如項目的功能安全性、業(yè)務(wù)風(fēng)險水平或組織的質(zhì)量文化。不管是什么因素促使組織實施質(zhì)量管控，生產(chǎn)安全和高質(zhì)量的軟件產(chǎn)品需要的不僅僅是決心。

選擇合適的測試方法是一項具有挑戰(zhàn)性的任務(wù)。技術(shù)正在快速發(fā)展，公司必須選擇采用哪種軟件測試工具。許多情況下，在開源和商業(yè)產(chǎn)品之間進行選擇也很困難。

這篇文章解釋了自動化測試技術(shù)，如高級靜態(tài)分析，運行時內(nèi)存監(jiān)控，自動化單元測試和數(shù)據(jù)流分析，可以組合使用以提高軟件質(zhì)量,并確定使用測試工具的好處。我們討論的話題是通用的，可以適用于任何編程語言，但這里的例子是C和C++編程語言，我們使用Parasoft C/C++test。

缺陷類與工具自動化

當(dāng)考慮到可能的高級軟件故障時，可以將軟件錯誤分為幾種類型：由于缺失需求而導(dǎo)致的錯誤、由指定需求引起的錯誤以及由于需求被錯誤編碼而產(chǎn)生的錯誤。前兩類軟件缺陷屬于需求工程范疇，在這里將不再討論。我們這里關(guān)注的是需求的錯誤實現(xiàn)，其中包括許多團隊所面臨的各種各樣的潛在軟件問題。那么，需求的不正確編碼意味著什么呢？它能導(dǎo)致很多種情況，例如：需求的實現(xiàn)不正確——需求相關(guān)的單元測試失敗并且自動化測試工具報告出缺陷。另一個例子,運行時分析工具可以在單元測試中檢測到無法從單元測試結(jié)果單獨檢測到的關(guān)鍵存儲器訪問錯誤。不同的工具更好地檢測某些類型的錯誤，如下所示。

▲

圖 1. 軟件缺陷和檢查策略圖

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

不愿意使用多種的測試技術(shù)往往源于這樣一種擔(dān)心：使用多種技術(shù)會給開發(fā)速度帶來巨大的開銷，更不用說預(yù)算了。如果團隊決定選擇未知的工具，這些問題就更加明顯。多個單獨工具的成本、學(xué)習(xí)曲線以及在不同的使用模型和接口之間切換的必要性都是需要考慮的。因此，開發(fā)人員可能會避免使用工具和自動化，因為這將他們的注意力從編寫代碼轉(zhuǎn)向工具使用，從而降低了他們的生產(chǎn)率。

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

在討論一個統(tǒng)一的測試工具的價值之前，一定要詳細說明對它的期望。理想情況下,一個工具應(yīng)該具有以下功能：

·支持多種測試技術(shù)

·使用簡單

·檢測函數(shù)問題和回歸測試

· 提供從需求到測試的可追溯性

·度量代碼的復(fù)雜性、可移植性和可維護性

·通過在編寫代碼時提供即時反饋來改善開發(fā)人員代碼編寫習(xí)慣

·提供開發(fā)程序進度的信息

·綜合多種技術(shù)的高級分析結(jié)果

一個統(tǒng)一的、集成的測試工具可以避免許多問題：

·多個學(xué)習(xí)曲線和可用性問題，使用不同接口的獨立工具

·分散開發(fā)人員編寫代碼

·防止工具鏈的不同元素之間的信息交換

盡可能多的檢測缺陷

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

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

但是有一天，最有可能在發(fā)布之后，內(nèi)存布局產(chǎn)生改變，第16行的操作會破壞應(yīng)用程序。有趣的是，由于用于計算索引的循環(huán)，靜態(tài)分析也不能標(biāo)記這個問題。由于性能原因，在靜態(tài)分析工具中使用的數(shù)據(jù)和控制流分析會使用試探法和簡化法來確保在合理的時間內(nèi)完成代碼分析，并且通常它們也會應(yīng)用于循環(huán)中，這意味著可能會丟失一些錯誤。

使用內(nèi)存監(jiān)控工具，通過注入特殊檢查和報告不正確的內(nèi)存操作來檢測源代碼，肯定會檢測到這個錯誤。運行時分析工具只在實際執(zhí)行的路徑上檢測軟件問題，而不進行任何猜測——這是靜態(tài)分析的一大優(yōu)勢，因為報告的問題的準確性非常高。

在本例中，Parasoft的內(nèi)存錯誤檢測很容易發(fā)現(xiàn)問題:

相反的情況也是存在的——靜態(tài)分析可以檢測運行時內(nèi)存監(jiān)視無法識別的問題。例如，在下面的代碼段中，第27/28行有一個空指針引用的可能性。使用的person指針參數(shù)為Null時，調(diào)用storePersonToFile函數(shù)會發(fā)生錯誤，但是只有當(dāng)retrivePersonFromDB函數(shù)返回null時才會報錯。在系統(tǒng)測試期間不太可能出現(xiàn)這種情況，因為數(shù)據(jù)庫連接很可能像預(yù)期的那樣運行，所以運行時內(nèi)存監(jiān)測工具并不能發(fā)現(xiàn)問題。然而，靜態(tài)分析工具中的流分析很容易檢測到要從這個函數(shù)返回的空指針，并報告一個潛在的空指針引用問題。

▲

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

檢查函數(shù)問題和回歸測試

那些總是執(zhí)行起來無缺陷，但不符合要求的代碼呢？靜態(tài)和動態(tài)分析在識別這類問題時沒有用處。要檢測預(yù)期結(jié)果與實際結(jié)果之間的差異，需要將計算結(jié)果與預(yù)定義值進行比較。實現(xiàn)這種檢查有許多的方法，包括手動系統(tǒng)級測試、集成測試和單元測試。在許多領(lǐng)域，統(tǒng)一的測試工具可以促進單元測試過程。優(yōu)點如下：

·在創(chuàng)建測試用例時提高開發(fā)人員的執(zhí)行力，例如，通過提供圖形向?qū)韯?chuàng)建、編輯和配置測試用例

·與Test Double框架相結(jié)合,允許簡單的mock和stub來模擬復(fù)雜的測試場景，而不涉及大型代碼庫。

·相關(guān)測試用例代碼覆蓋率報告評估測試的完整性

·通過自動計算驗證代碼增量所需的最小測試用例集來優(yōu)化測試用例

·將代碼覆蓋率報告與其他測試技術(shù)相結(jié)合，如手動或系統(tǒng)級測試或集成測試以識別未經(jīng)測試的代碼

·跟蹤結(jié)果并與需求關(guān)聯(lián)以更好的理解失敗測試的影響

使用圖形化向?qū)Щ蚓庉嬈鲃?chuàng)建測試，可以讓QA團隊參與到編寫單元測試的過程，從而提高整個組織的生產(chǎn)力，使他們積極地為開發(fā)過程做出貢獻。對于QA團隊成員來說，使用圖形向?qū)П仍诖a編輯器中編寫適當(dāng)?shù)臏y試代碼更容易，因為使用輸入表單(如下所示)配置值不需要高級的編碼技能，而且更省時，尤其是在團隊成員缺乏經(jīng)驗的情況下。例如，下面的屏幕截圖顯示了Parasoft C/ C++test在實現(xiàn)C/C++單元測試能力的一個示例，該向?qū)椭鷦?chuàng)建單元測試。

使用統(tǒng)一測試工具的另一個好處是它提供了關(guān)于測試完整性和關(guān)鍵業(yè)務(wù)需求的狀態(tài)反饋。MC/DC覆蓋率報告中的低數(shù)字可能表明分支覆蓋率不足，即使報表覆蓋報告顯示了高值。這種分析需要一個支持多覆蓋率度量的工具鏈，允許團隊從簡單的東西開始，比如行或語句覆蓋率，并在改進測試用例的過程中繼續(xù)進行更徹底的代碼覆蓋率。

測試可追溯性需求

單元測試和系統(tǒng)測試覆蓋報告是關(guān)于測試過程的一大信息源，尤其是當(dāng)它們結(jié)合在一起時。但是，如果測試結(jié)果與需求不相關(guān)，團隊就會缺少一些關(guān)鍵信息。通過查看測試到可追溯性的需求報告，您可以快速確定需求覆蓋率的狀態(tài)。此種情況的一個例子如下：

將需求與來自不同類型測試的結(jié)果關(guān)聯(lián)起來的能力是使用統(tǒng)一測試工具的一大好處。單元測試，系統(tǒng)測試，集成測試結(jié)果，編碼標(biāo)準和代碼度量結(jié)果可以通過關(guān)聯(lián)來提供對關(guān)鍵和非關(guān)鍵需求的狀態(tài)反饋。

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

當(dāng)你組合來自項目中使用的各種測試技術(shù)的數(shù)據(jù)時，你可以獲得二級度量和更復(fù)雜的分析。使用統(tǒng)一的測試工具使團隊能夠從全新的角度來審查代碼。單元測試用例執(zhí)行失敗對于開發(fā)人員來說可能有不同的含義，這取決于它是發(fā)生在代碼度量分析中的高風(fēng)險還是低風(fēng)險代碼中。如果將這些信息與來自源碼控制的統(tǒng)計信息進一步結(jié)合，并與需求相關(guān)聯(lián)，團隊就可以更好地決定何時以及如何糾正代碼。

使用Parasoft的工具套件，你可以利用基于變更的測試來提高團隊的生產(chǎn)力。基于變更的測試通過捕獲源代碼、測試用例和代碼覆蓋結(jié)果之間的關(guān)系，來計算并驗證特定代碼增量相關(guān)測試用例的最優(yōu)集。實際上，團隊可以通過只運行整個回歸套件的一小部分測試來限制他們的測試會話。這種只專注于絕對需要部分的測試，節(jié)省了大量的時間與資金，特別是對于中型或大型項目更是如此。

結(jié)合使用：ParasoftC/C++test and DTP

上面討論的所有測試技術(shù)都可以在Parasoft C/C++test和Parasoft DTP中使用。Parasoft C/C++test是針對C和C++項目的統(tǒng)一測試工具。C/C++test 作為插件嵌入當(dāng)前主流的IDE中,如 Eclipse和Visual Studio與IDE的緊密集成可以防止上面討論的問題。開發(fā)人員在編寫代碼時即可立即運行編碼標(biāo)準遵從性檢查或執(zhí)行單元測試。QA團隊成員可以執(zhí)行手動測試場景，同時監(jiān)視應(yīng)用程序的代碼覆蓋率和運行時錯誤。離線分析，例如由靜態(tài)分析提供的流分析，可以在連續(xù)集成階段中執(zhí)行。使用支持命令行接口的服務(wù)器會話，將分析結(jié)果報告給Parasoft DTP，以便于收集來自開發(fā)環(huán)境的信息。Parasoft DTP提供了廣泛的報告能力，包括集成來自第三方工具的數(shù)據(jù)、在工作流的每個階段提供測試反饋的能力，這加速了敏捷開發(fā)并降低了符合安全標(biāo)準的成本。

還應(yīng)該注意到，這里討論的質(zhì)量保證相關(guān)的過程和體系結(jié)構(gòu)并不局限于C/C++項目。Parasoft為Java和C#/.NET提供相似的解決方案。

總結(jié)

軟件質(zhì)量改進不是同質(zhì)化的工作，它需要不同的技術(shù)來消除不同類型的軟件缺陷。關(guān)鍵的挑戰(zhàn)是如何以一種有效的方式來實現(xiàn)這個目標(biāo)，從而避免破壞項目預(yù)算并削弱開發(fā)人員的積極性。集成到開發(fā)人員IDE中的統(tǒng)一測試工具為開發(fā)測試提供了最有效的環(huán)境。一個統(tǒng)一的工具，比如Parasoft的C/ C++ test，它具有統(tǒng)一測試軟件各個方面的能力，并提供統(tǒng)一的度量和結(jié)果，允許團隊將測試集中在高風(fēng)險和最近修改的代碼上，從而提供了更多的好處。