究竟什麼是軟體測試

軟體測試是貫穿整個軟體開發生命週期、對軟體產品（包括階段性產品）進行驗證和確認的活動過程，其目的是儘快儘早地發現在軟體產品中所存在的各種問題——與使用者需求、預先定義的不一致性。為了更早地發現問題，所以將軟體測試延伸到需求評審、設計審查活動中去，也就是將“軟體質量保證”的部分活動歸為軟體測試活動。實際上，在軟體開發實際操作中，常常將軟體測試和質量保證——這兩種努力（efforts）合併起來。

延伸後的軟體測試，被認為是一種軟體測試的廣義概念。這就引出軟體測試的兩個概念“靜態測試”和“動態測試”，如測試方法的辯證統一（1）所述，這樣就由靜態測試和動態測試構成一個全過程的、完整的軟體測試，而且靜態測試顯得更為重要。

1.軟體測試的辨證論

G.J.Myers的第2個觀點“測試是為了證明程式有錯，而不是證明程式無錯誤”，引出了軟體測試的另外一個爭論，軟體測試究竟是證明所有軟體的功能特性是正確的呢？還是其反向思維——對軟體系統進行各種試探和攻擊，找出軟體系統中不正常或不工作的地方呢？從我個人理解，這兩個方面都有一定道理，前者（證明所有軟體的功能特性是正確的）是從質量保證的角度來思考軟體測試，後者（證明程式有錯）從軟體測試的直接目標和測試效率來思考，兩者應該相輔相成。在後者的思想背景下，我們認為，測試不是為了證明所有的功能可以正常工作，恰恰相反，測試就是為了找出那些不能正常工作、不一致性的地方。也就是說，測試的一般工作就是發現缺陷(detect bug)，即在軟體開發過程中，分析、設計與編碼等工作都是建設性的，而測試是帶有“破壞性”的工作。

對於不同的應用領域，兩者的比重是不一樣的，如國防、航天、銀行等軟體系統，承受不了任何系統失效，因為一次系統的失效完全有可能導致災難性的損失，所以強調前者以保證非常高的軟體質量。而一般的軟體服務應用則不同，強調後者，質量目標設定在“使用者可接受水平”，不要國度追求質量，從而可以降低軟體開發成本。作者建議，在我們實際操作中，可以分階段實施不同的測試思想，在早期階段集中在“證明程式有錯”——發現Bug，後期集中在驗證所有特性是否正常工作——降低風險，見作者的另外一篇討論：測試執行中非常有效的策略

下面就是這兩種觀點的基本描述：

驗證軟體是驗證軟體是“工作的”，以正向思維，針對軟體系統的所有功能點，逐個驗證其正確性。其代表人物是軟體測試領域的先驅Dr. Bill Hetzel（代表論著《The Complete Guide to Software Testing》)。

證明軟體是“不工作的”，以反向思維方式，不斷思考開發人員理解的誤區、不良的習慣、程式程式碼的邊界、無效資料的輸入以及系統的弱點，試圖破壞系統、摧毀系統，目標就是發現系統中各種各樣的問題。其代表人物就是上面多次提到的G.J.Myers。他強調，一個成功的測試必須是發現BugBug的測試，不然就沒有價值。

2.軟體測試的風險論

測試被定義為“對軟體系統中潛在的各種風險進行評估的活動”，這就是軟體測試的風險論。軟體測試自身的風險性是大家公認的，測試的覆蓋度不能做到100％。測試的這種風險定義一方面源於這層含義，另外軟體測試的標準有時不清楚，“軟體規格說明書（Specification/ Spec）”是其中的一個標準，但也不是唯一的，因為Spec中有些內容完全有可能是錯誤的。所以，我們常常強調軟體測試人員應該站在客戶的角度去進行測試，除了發現程式中的錯誤，還要發現需求定義的錯誤、設計上的缺陷，可以針對Spec去報Bug。但是，測試在大多數時間/情況下,是由工程師完成，而不是客戶自己來做，所以又怎麼能保證工程師和客戶想得一樣呢？

有人把開發比作打靶，目標明確，就是按照Spec去實現系統的功能。而把測試比作撈魚，目標不明確，自己判斷哪些地方魚多，就去哪些地方撈；如果只撈大魚（嚴重缺陷），網眼就可以大些、撒網區域相對比較集中（測試點集中在主要功能-major features）。如果想把大大小小的魚撈上來，網眼就要小、普遍撒網，不放過任何一塊區域（測試點遍及所有功能——all features）。

在“風險”論的框架下，軟體測試可以被看作是一個動態的監控過程，對軟體開發全過程進行檢測，隨時發現不健康的徵兆，發現問題、報告問題，並重新評估新的風險，設定新的監控基準，不斷地持續下去，包括迴歸測試。這時，軟體測試可以完全看作是軟體質量控制的過程。

對應這種觀點，產生基於風險的測試策略，首先評估測試的風險，功能出問題的概率有多大？哪些是使用者最常用的20％功能——Pareto原則（也叫80/20原則）？如果某個功能出問題，其對使用者的影響有多大？然後根據風險大小確定測試的優先順序。優先順序高的測試，優先得到執行，一般來講，針對使用者最常用的20％功能（優先順序高）的測試會得到完全執行，而低優先順序的測試（另外使用者不經常用的80％功能）就不是必要的，如果時間或經費不夠，就暫時不做或少做。

本文轉載自51Testing軟體測試網（檢視全文）：http://www.51testing.com/html/34/n-7134.html

[@more@]

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/11323760/viewspace-1023132/，如需轉載，請註明出處，否則將追究法律責任。