軟件質量誰把關?

　　軟件測試是軟件開發的重要、必要部分，是通過找出缺陷和問題評估產品質量并間接改進產品質量的手段。從軟件工程的觀點看，預防程序問題要比改正問題重要得多，因此，必須首先把軟件測試看做是檢驗預防程序錯誤的機制是否有效的主要手段，同時又是找出程序異常的手段。

　　從一段對話談起

　　甲、乙、丙三人對“所有奇數都是質數”這個假設進行測試。

　　甲說：“3是質數，5是質數，7是質數?？雌饋磉@個假設沒錯。”

　　乙說：“3是質數，5是質數，7是質數，9是質數，11是質數……”

　　丙說：“錯!9就是一個非質數奇數。”

　　軟件測試就是從一個錯誤陳述(“系統能正常運行”)開始，從無限種可能中選出與該陳述矛盾的輸入。必須避免甲犯過的錯誤(沒有驗證合適的值)，也要避免犯乙犯過的錯誤(驗證了合適的值，但是沒有發現矛盾之處)，需要像丙那樣，用最小工作量找出合適的反例。

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

　　從這個定義可以看出軟件測試的四個特點：首先是“動態”，軟件測試總要通過一組輸入執行程序。但是，單靠輸入值并不總能充分地確定一個測試，因為對于復雜、非確定的系統，由于系統會處于不同的狀態，因此對于同樣的輸入可能產生不同的響應。所以，特定的輸入通常還要指定系統的特定狀態。其次是“有限”，在測試中實際能夠觀察的執行數量是有限的。測試永遠都意味著有限資源和計劃進度與本質上是無限測試需求之間的折衷：正是這種矛盾帶來了大家經常提到的技術(測試充分性評判準則)和管理(測試工作量估計)兩個方面的測試問題。接著是“選取”，很多測試手段的本質區別就是如何選擇有限的測試集。針對特定條件確定最合適的選取準則是一個非常復雜的問題，在實踐中需要運用風險分析技術和測試工程專門知識。最后是 “預期”，必須能夠確定所觀察到的程序執行輸出是不是可接受的，否則測試工作就是無用的。

　　軟件測試通常要在不同層次上執行，大體上劃分為三大階段：單元測試、集成測試和系統測試。單元測試檢驗獨立軟件模塊的機能，軟件模塊可以是獨立子程序，也可以是由緊密相關的數個單元組成的較大構件，單元測試一般需要對被測代碼進行訪問并借助調試工具的支持，并且可能需要被測代碼編程人員的介入;集成測試檢驗系統各部件間的交互性。經典的集成測試策略有自頂向下或自底向上兩種，用于傳統的、分級的結構化軟件系統?，F代的集成測試策略更多是結構驅動的，這意味著對軟件部件或子系統的集成是基于確定的功能線程，因此集成測試是一個連續活動，在每一階段測試人員必須抽象出低一級的情況并集中于正在處理的這一級的狀況;系統測試關注的則是整個系統的行為，它需要將系統與非功能性系統需求進行比較，非功能性系統需求指系統的安全性、速率、精確性、可靠性等。系統與其它軟件、應用程序、硬件設備或操作環境的外部接口評估也在系統測試中進行。

　　測試技術分類

　　從軟件生產發達國家來看，20世紀60年代，軟件測試主要以代碼調試為主;70年代主要以演示軟件系統的正確性為主;80年代到90年代中期，主要以檢查程序錯誤為主;90年代中期以后，軟件測試開始更注重軟件質量特性的整體評估。目前軟件測試最主要的目標是評估軟件功能，但一般也要測試軟件的非功能屬性。

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

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

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

原文轉自：http://www.uml.org.cn/Test/200811282.asp