軟體質量到底誰來把關？

01-30

軟體測試是軟體開發的重要、必要部分，是通過找出缺陷和問題評估產品質量並間接改進產品質量的手段。

從軟體工程的觀點看，預防程序問題要比改正問題重要得多，因此，必須首先把軟體測試看做是檢驗預防程序錯誤的機制是否有效的主要手段，同時又是找出程序異常的手段。

甲、乙、丙三人對「所有奇數都是質數」這個假設進行測試。
甲說：「3是質數，5是質數，7是質數。看起來這個假設沒錯。」
乙說：「3是質數，5是質數，7是質數，9是質數，11是質數……」

丙說：「錯!9就是一個非質數奇數。」

軟體測試就是從一個錯誤陳述(「系統能正常運行」)開始，從無限種可能中選出與該陳述矛盾的輸入。

必須避免甲犯過的錯誤(沒有驗證合適的值)，也要避免犯乙犯過的錯誤(驗證了合適的值，但是沒有發現矛盾之處)，需要像丙那樣，用最小工作量找出合適的反例。

IEEE把軟體測試定義為:從通常是無限大的執行域中恰當地選取一組有限測試用例，對照程序已經定義的預期行為，動態地檢驗程序的行為。

從這個定義可以看出軟體測試的四個特點：

1、首先是「動態」，軟體測試總要通過一組輸入執行程序。但是，單靠輸入值並不總能充分地確定一個測試，因為對於複雜、非確定的系統，由於系統會處於不同的狀態，因此對於同樣的輸入可能產生不同的響應。所以，特定的輸入通常還要指定系統的特定狀態。

2、其次是「有限」，在測試中實際能夠觀察的執行數量是有限的。測試永遠都意味著有限資源和計划進度與本質上是無限測試需求之間的折衷：

正是這種矛盾帶來了大家經常提到的技術(測試充分性評判準則)和管理(測試工作量估計)兩個方面的測試問題。

3、接著是「選取」，很多測試手段的本質區別就是如何選擇有限的測試集。針對特定條件確定最合適的選取準則是一個非常複雜的問題，在實踐中需要運用風險分析技術和測試工程專門知識。

4、最後是「預期」，必須能夠確定所觀察到的程序執行輸出是不是可接受的，否則測試工作就是無用的。

軟體測試通常要在不同層次上執行，大體上劃分為三大階段：單元測試、集成測試和系統測試。

1、單元測試檢驗獨立軟體模塊的機能，軟體模塊可以是獨立子程序，也可以是由緊密相關的數個單元組成的較大構件，單元測試一般需要對被測代碼進行訪問並藉助調試工具的支持，並且可能需要被測代碼編程人員的介入;

2、集成測試檢驗系統各部件間的交互性。

經典的集成測試策略有自頂向下或自底向上兩種，用於傳統的、分級的結構化軟體系統。

現代的集成測試策略更多是結構驅動的，這意味著對軟體部件或子系統的集成是基於確定的功能線程，因此集成測試是一個連續活動，在每一階段測試人員必須抽象出低一級的情況並集中於正在處理的這一級的狀況;

3、系統測試關注的則是整個系統的行為，它需要將系統與非功能性系統需求進行比較，非功能性系統需求指系統的安全性、速率、精確性、可靠性等。

系統與其它軟體、應用程序、硬體設備或操作環境的外部介面評估也在系統測試中進行。

測試技術分類

從軟體生產發達國家來看，20世紀60年代，軟體測試主要以代碼調試為主;70年代主要以演示軟體系統的正確性為主;80年代到90年代中期，主要以檢查程序錯誤為主;

90年代中期以後，軟體測試開始更注重軟體質量特性的整體評估。目前軟體測試最主要的目標是評估軟體功能，但一般也要測試軟體的非功能屬性。

目前應用於軟體測試領域的技術有很多，而且差別很大，大致有兩種分類方法。

1、第一種是按測試的生成來源劃分，

即基於測試人員的直覺和經驗(即興測試)、需求規格說明(包括等價類劃分、邊界值分析、判定表、基於有限狀態機、形式化語言轉換和隨機測試等)、代碼結構(基於流程圖、調用關係圖等參考模型、基於控制流標準、基於數據流的標準)、發現的錯誤(以過去經驗為基礎的錯誤推測法、增加一個被測程序變種的變異測試)、被測程序的使用領域(操作剖面、軟體可靠性工程測試)和被測程序類型(面向對象、基於構件、網站、GUI、並發程序、協議一致性、分散式系統、實時系統、科學計算軟體測試)的測試技術。

2、第二種是經典的分類方法，即黑盒測試和白盒測試。

依賴於被測軟體設計及編碼信息進行的測試稱為白盒測試(基於代碼測試的參考模型、基於控制流標準、基於數據流標準和變異測試等)，只依靠被測軟體輸入/輸出行為而沒有關於輸入/輸出之間信息狀況的測試稱為黑盒測試(等價類劃分、邊界值分析、判定表、基於有限狀態機、源於形式化需求規格說明、錯誤推測法、隨機測試、操作剖面和軟體可靠性工程測試等)。

在實際測試中，往往綜合採用這些技術，測試過程有章可循。

1、過程是一組把輸入轉換為輸出的相關活動。

不同層次上的測試活動必須與人員、工具、政策、度量一起組織於一個良定義的過程中，這一過程是軟體生命周期的完整組成部分。測試過程需要加以控制並進行持續改進。

2、軟體測試過程的決定性因素是人。

對於成功的測試來說，一個必要條件是人員對測試活動所採取的積極和相互協作的態度。另外，應該使軟體產品涉及的所有人員都認識到：及早發現軟體錯誤是大家共同的目標，而不僅僅是測試人員的責任。

3、文檔是測試過程規範化的一個完整組成部分。

IEEE 829完整描述了各種測試文檔、文檔間關聯及文檔與測試過程間的關聯。

測試文檔包括測試計劃、測試設計說明、測試過程說明、測試案例說明、測試日誌和測試事件或問題報告等。

用於測試過程式控制制與改進的度量包括:設計的測試用例數、執行的測試用例數、通過的測試用例數、失敗的測試用例數等。

3、測試管理的一個關鍵性任務是決定什麼樣的測試是充分的，某個測試階段何時可以終止。

對此，充分性度量和錯誤密度估價、操作可靠性評估都可提供有益支持，但只有這些還不充分。

決策還應考慮潛在的遺留失效可能造成的損失和風險，並將之與進一步測試所需成本進行對比。為使測試和維護工作有組織、成本效益高，應將各測試手段系統化地加以重用。

為此，應在測試的各個層次，對測試腳本、測試用例和預期結果進行精心定義並記錄。

用於特定環境、特定類型程序的測試方案，以及決策動機，構成了測試模式。測試模式本身也可文檔化，並可重用於以後的類似項目。