測試思想 什麼是軟體測試(摘錄)

什麼是軟體測試(摘錄)

by:授客 QQ：1033553122

IEEE 标準的定義:使用人工或自動的手段來運作或測定某個系統的過程，其目的在于檢驗;它是否滿足規定的需求或是弄清預期結果與實際結果之間的差别。對軟體測試還有一些不同的定義。

G.J.Myers給出的定義:“程式測試是為了發現錯誤而執行程式的過程”。這個定義被軟體測試業界所認可，并經常被引用。但實際上，這樣的定義還不能完全反映軟體測試的内涵，它仍局限于“程式測試”。随後，G.J.Myers進一步提出了有關程式測試的3個重要觀點，那就是:

(1)測試是為了證明程式有錯，而不是證明程式無錯誤。

(2)一個好的測試用例在于它能發現至今未發現的錯誤。

(3)一個成功的測試是發現了至今未發現的錯誤的測試。

要完整地了解軟體測試，就要從不同方面和視角去辨證地審視軟體測試。概括起來，軟體測試就是貫穿整個軟體開發生命周期、對軟體産品(包括階段性産品)進行驗證和确認的活動過程，其目的是盡快盡早地發現在軟體産品中存在的各種問題—與使用者需求、預先的定義不一緻的地方。

1.軟體測試的俠義觀點和廣義觀點

G.J.Myers給出了測試定義—“程式測試是為了發現錯誤而執行程式的過程”，實際上這是一個狹義的概念，因為他認為測試是執行程式的過程，也就是傳統意義上的測試—在代碼完成後，通過運作程式來發現程式代碼或軟體系統中錯誤。但是，這種意義上的測試是不能在代碼完成之前發現軟體系統需求及設計上的問題的，把需求、發現設計上的問題遺留到後期—最

終在代碼中展現出來，這樣就可能會造成設計、程式設計的部分或全部返工。需求階段和設計階段的缺陷在開發過程中會産生擴大效應，缺陷的嚴重性随時間發展越來越

嚴重，其結果會大大增加軟體開發的成本、延長開發的周期等。這種狹義的觀點主要是受軟體開發瀑布模型的影響，而且非常不利于保證軟體品質。

延伸後的軟體測試，被認為是軟體測試的一種廣義概念。這就引出了廣義的軟體測試的兩個概念“靜态測試”和“動态測試”。這樣，靜态測試和動态測試就構成了一個全過程的、完整的軟體測試，而且靜态測試顯得更為重要。

說明：靜态測試的主要活動是評審，即通過對需求、設計、配置、程式和其他各類文檔的審查來檢驗相應的内容是否滿足使用者的需求。由于靜态測試不需要運作程式，是以測試對象是屬于靜态的.

動态測試通過運作程式來發現軟體系統中的問題，在程式運作過程中發現缺陷，它具有動态性。

  2.軟體測試的辨證觀點

G.J.Myers的第2個觀點是“測試是為了證明程式有錯，而不是證明程式無錯誤”，引出了軟體測試的另外一個争論:

  軟體測試究竟是證明所有軟體的功能特性是正确的，還是相反—對軟體系統進行各種試探和攻擊，找出軟體系統中不正常或不工作的地方，就我個人了解，這兩個方面都有一定道理，前者(證明或驗證所有軟體的功能特性是正确的)是從品質保證的角度來思考軟體測試，後者(證明程式有錯)從軟體測試的直接目标和測試效率來思考，兩者應該相輔相成。在後者的思想背景下，可以認為測試不是為了證明所有的功能都能正常工作，恰恰相反，測試就是為了找出那些不能正常工作、不一緻性的問題，也就是說，測試的工作就是發現缺陷(detect

bug

)，即在軟體開發過程中，分析、設計與編碼等工作都是建設性的，唯獨測試帶有“破壞性”，

它想方設法發現軟體所存在的問題。軟體測試就是在這兩者之間獲得平衡，但對于不同的應用領域，兩者的比重是不一樣的。例如，國防、航天、銀行等軟體系統，

承受不了系統的任何一次失效，因為任何失效都完全有可能導緻災難性的損失，是以強調前者，以保證非常高的軟體品質。而一般的軟體應用或服務，則可以強調後

者，品質目标設定在“使用者可接受水準”，以降低軟體開發成本，加快軟體釋出速度，有利于市場的擴張。

(1)驗證軟體是“工作的”，以正向思維方式，針對軟體系統的所有功能點，逐個驗證其正确性。

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

3.軟體測試的風險觀點

  測試被定義為“對軟體系統中潛在的各種風險進行評估的活動”，這就引出軟體測試的風險觀點。軟體測試自身的風險性是大家公認的，測試的覆寫率不能做到100%;另

外一方面，軟體測試的标準有時不清楚，軟體規格說明書是測試中的一個标準，但也不是唯一的标準。因為規格說明書本身的内容完全有可能是錯誤的，它所定義的

國内特性不是使用者所需要的。是以，我們常常強調軟體測試人員應該站在客戶的角度去進行測試，除了發現程式中的錯誤，還要發現需求定義的錯誤、設計規格說明

書的缺陷。但是，測試在大多數時間/情況下是由工程師完成的，而不是客戶自己來做，是以又怎麼能保證工程師和客戶想得一樣呢?

有人把開發比作打靶，目标明确，就是按照設計規格說明書去實作系統的功能。而把測試比作撈魚，目标不明确，自己判斷哪些地方魚多，就去哪些地方撈:如果隻撈大魚(嚴重缺陷)，網眼就可以大些、撒網區域相對比較集中(測試點集中在主要功能上)。如果想把大大小小的魚都撈上來，網眼就要小，普遍撒網，不放過任何一塊區域(測試點遍及所有功能)。

在“風險”觀點的架構下，軟體測試可以被看作是一個動态的監控過程，對軟體開發全過程進行檢測，随時發現不健康的征兆，發現問題、報告問題，并重新評估新的風險，設定新的監控基準，不斷地持續下去，包括回歸測試。這時，軟體測試完全可以看作是軟體品質控制的過程。

對應這種觀點，産生基于風險的測試政策，首先評估測試的風險，每個功能出問題的機率有多大?根據Pareto原則(也叫80/20原則)，哪些功能是使用者最常用的功能(約占20%)?如果某個功能出問題，其對使用者的影響又有多大?然後根據風險大小确定測試的優先級。優先級高的功能特性，測試優先得到執行。一般來講，針對使用者最常用的這20%功能(優先級高)的測試會得到完全地、充分地執行，而低優先級功能的測試(使用者不常用的功能，約占80%

)就可能由于時間或經費的限制，降低測試的要求、減少測試工作最，這樣做風險性并不是很大。

4.軟體測試的經濟學觀點

一個好的測試用例在于它能發現至今未發現的錯誤”，

這展現了軟體測試的經濟學觀點。實際上，軟體測試經濟學問題至今仍是業界關注的問題之一。經濟學的核心就是要盈利，盈利的基礎就是要有一個清楚的商業性目

标。同樣，商業性目标是否正确，直接決定了企業是否盈利。在多數情況下，軟體測試是在公司内執行的。正是公司的行為目的，決定了軟體測試含義或定義經濟性

的一面。正如對軟體質最的定義不僅僅局限于“和客戶需求的一緻性、适用性”，而且要增加其他的要求—“開發成本控制在預算内、按時釋出軟體、系統易于維護”等。

軟體測試也一樣，要盡快盡早地發現更多的缺陷，并督促和幫助開發人員修正缺陷。原因很簡單，缺陷發現得越早，所付出的代價就越低，例如在程式設計階段發現一個需求定義上的錯誤，其代價将10倍于在需求階段就發現該缺陷的代價。這就是從經濟學的觀點來說明測試進行得越早越好這樣一個道理。

5.軟體測試的标準觀點

從标準觀點來看，可以定義為“驗證”和“有效性确認”活動夠成的整體，即軟體測試=V&V

“驗證”是檢驗軟體是否已正确地實作了軟體需求規格說明書所定義的系統功能和特性。驗證過程提供證據表明軟體相關産品與所有生命周期活動的要求(如正确性、完整性、一緻性、準确性等)一緻。相當于以軟體産品設計規格說明書為标準進行軟體測試的活動。

 “有效性确認”是确認所開發的軟體是否滿足使用者真正需求的活動。一切從客戶出發，了解客戶的需求，并對軟體需求定義和設計存疑，以發現需求定義和産品設計中的問題。主要通過各種軟體評審活動來實作，保證讓客戶參加評審和測試活動。

當然，軟體測試的對象是産品(包括階段性産品，如市場需求說明書、産品規格說明書、技術設計文檔、資料字典、程式包、使用者文檔等)，而品質保證和管理的對象集中于軟體開發的标準、流程和方法等上。