實時軟件測試[2] 軟件測試
顯然在提高軟件質量和可靠性方面，路徑測試覆蓋技術是最有效的。這樣最大限度的路徑測試覆蓋將降低其它相關覆蓋測試的成本。
越來越多的軟件開發者在轉向商業的軟件測試工具來協助復雜的測試過程。有些軟件也集成了規則分析和其它的靜態分析技術來進行單元級(單個函數)到子系統級以及系統級(多文件)測試。
需要覆蓋率工具提供什么功能呢?
1. 能進行全面地覆蓋分析(最好能識別不可行代碼和不可達代碼)。
2. 能從單元級開始向上輔助自動測試用例/向量生成工具進行覆蓋分析。
3. 能提供直觀的可視化的報告以便于工程分析和指導。
結合工具的使用，開發者考慮按照下面的步驟將能更高效、低成本的到達覆蓋分析的目的：
第一步：根據對被測程序的期望實現功能的了解來構造最有可能的功能測試。這些應該從軟件需求說明書、軟件規格或用戶文檔獲得。在加載測試數據的情況下，應該能夠通過測試工具監控源代碼的執行。當實現功能測試的數據用完后，檢查覆蓋率來發現程序中的哪些部分仍然沒有被測到。應該進一步的構造測試數據并進行執行、分析。覆蓋率會隨著每一組測試數據的執行而累加并且每一組測試數據都會顯示執行了程序中的哪些部分。
上面的過程應該一直持續到進行功能測試的數據被執行完或者達到所需的測試度量標準。如果是前一種情況(測試數據執行完)那么進行第二步;否則的話(達到測試度量標準的要求)那么任務就完成了。
第二步：檢查測試覆蓋度量指標。如果語句覆蓋率沒有達到完全覆蓋(也就是說不是每條語句都被執行了)，那么可能是由于某個特殊的用例運行失敗，錯誤退出，等造成的。由于這些可能性的存在，需要對執行歷史剖面進行累積，因為為了將代碼中的每一行都執行到，將程序執行多次通常是必須的。通常功能測試只能覆蓋程序中40%到60%的可執行語句。
當語句覆蓋達到完全，每一條語句都被執行時，便可進行第三步。
第三步：檢查所有沒有被執行的分支。通常這些分支中的一部分可以通過構造專門的用例實現對它們的測試。因為為找出程序中未執行分支而進行的程序分析和為了找出程序中的未執行路徑所要做得分析工作很相似，所以在將分支測試這種策略充分實施后再進行第四步——測試路徑覆蓋，將更加節約成本。
第四步：有些沒有執行到的分支和路徑，是由于相關的測試用例只有在程序執行出錯或者計算出錯的錯誤狀態下才能實現。這些通常是和程序的冗余保護設計相關,這樣的路徑應該完整的保留。
最后：
在進一步的檢查后會發現，通常很多沒有被執行的路徑都是不可行的，也就是說，在使用任何測試數據的情況下這些路徑都不可能被執行到。這意味著代碼的相關部分應該重新寫，因為這些代碼要么是無效的要么是不正確的。此外，當這些代碼重寫后，和這些代碼相關的其它一些測試路徑可能也會被去掉。如果是由于上面已知的原因，導致測試路徑不能被執行到，那么即使沒有達到覆蓋率標準，這些測試路徑也是可以忽略不計的。
一旦不可行測試路徑被去掉，那么源代碼將會更加有效、健壯并且占用更少的空間。
文章來源于領測軟件測試網 http://www.k11sc111.com/
