軟體測試的風險論

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

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

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

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

本文內容整理自網絡, 文中所有觀點看法不代表淘大白的立場