關鍵字：軟件測試 起源 發展
軟件測試的概念與定義 軟件測試是伴隨著軟件的產生而產生的。早期的軟件開發過程中，那時軟件規模都很小、復雜程度低，軟件開發的過程混亂無序、相當隨意，測試的含義比較狹窄，開發人員將測試等同于“調試”，目的是糾正軟件中已經知道的故障，常常由開發人員自己完成這部分的工作。對測試的投入極少，測試介入也晚，常常是等到形成代碼，產品已經基本完成時才進行測試。
直到1957年，軟件測試才開始與調試區別開來，作為一種發現軟件缺陷的活動。由于一直存在著“為了讓我們看到產品在工作，就得將測試工作往后推一點”的思想，潛意識里對測試的目的就理解為“使自己確信產品能工作”。測試活動始終后于開發的活動，測試通常被做為軟件生命周期中最后一項活動而進行。當時也缺乏有效的測試方法，主要依靠“錯誤推測 Error Guessing”來尋找軟件中的缺陷。因此，大量軟件交付后，仍存在很多問題，軟件產品的質量無法保證。
到了20世紀70年代，這個階段開發的軟件仍然不復雜，但人們已開始思考軟件開發流程的問題，盡管對“軟件測試”的真正含義還缺乏共識，但這一詞條已經頻繁出現，一些軟件測試的探索者們建議在軟件生命周期的開始階段就根據需求制訂測試計劃，這時也涌現出一批軟件測試的宗師，Bill Hetzel 博士就是其中的領導者。1972年，軟件測試領域的先驅Bill Hetzel博士（代表論著《The Complete Guide to Software Testing》），在美國的北卡羅來納大學組織了歷史上第一次正式的關于軟件測試的會議。在1973年，他首先給軟件測試一個這樣的定義：“就是建立一種信心，認為程序能夠按預期的設想運行。Establish confidence that a program does what it is supposed to do. ”后來在1983年他又將定義修訂為：“評價一個程序和系統的特性或能力，并確定它是否達到預期的結果。軟件測試就是以此為目的的任何行為。Any activities aimed at evaluating an attribute or capability of a program or system. ”在他的定義中的“設想”和“預期的結果”其實就是我們現在所說的用戶需求或功能設計。他還把軟件的質量定義為“符合要求”。他的思想的核心觀點是：測試方法是試圖驗證軟件是“工作的”，所謂“工作的”就是指軟件的功能是按照預先的設計執行的，以正向思維，針對軟件系統的所有功能點，逐個驗證其正確性。軟件測試業界把這種方法看作是的軟件測試的第一類方法。
盡管如此，這一方法還是受到很多業界權威的質疑和挑戰。代表人物是Glenford J. Myers（代表論著《The Art of Software Testing》）。他認為測試不應該著眼于驗證軟件是工作的，相反應該首先認定軟件是有錯誤的，然后用逆向思維去發現盡可能多的錯誤。他還從人的心理學的角度論證，如果將 “驗證軟件是工作的”作為測試的目的，非常不利于測試人員發現軟件的錯誤。于是他于1979年提出了他對軟件測試的定義：“測試是為發現錯誤而執行的一個程序或者系統的過程。The process of executing a program or system with the intent of finding errors.”這個定義，也被業界所認可，經常被引用。除此之外， Myers還給出了與測試相關的三個重要觀點，那就是：
1、 測試是為了證明程序有錯，而不是證明程序無錯誤；
2、 一個好的測試用例是在于它能發現至今未發現的錯誤；
3、 一個成功的測試是發現了至今未發現的錯誤的測試；
這就是軟件測試的第二類方法，簡單地說就是驗證軟件是“不工作的”，或者說是有錯誤的。Myers認為，一個成功的測試必須是發現Bug的測試，不然就沒有價值。這就如同一個病人（假定此人確有�。�，到醫院做一項醫療檢查，結果各項指標都正常，那說明該項醫療檢查對于診斷該病人的病情是沒有價值的，是失敗的。Myers提出的“測試的目的是證偽”這一概念，推翻了過去“為表明軟件正確而進行測試”的錯誤認識，為軟件測試的發展指出了方向，軟件測試的理論、方法在之后得到了長足的發展。第二類軟件測試方法在業界也很流行，受到很多學術界專家的支持。
然而，對Glenford Myers先生“測試的目的是證偽”這一概念的理解也不能太過于片面。在很多軟件工程學、軟件測試方面的書籍中都提到一個概念：“測試的目的是尋找錯誤，并且是盡最大可能找出最多的錯誤”。這很容易讓人們認為測試人員就是“挑毛病”的，而由此帶來諸多問題。大家熟悉的Ron Patton在《軟件測試》（中文版由機械工業出版社出版，此書是目前國內測試新手入門的經典教材）一書的第10頁，有一個明確而簡潔的定義：“軟件測試人員的目標是找到軟件缺陷，盡可能早一些，并確保其得以修復�！边@樣的定義具有一定的片面性，帶來的結果是：
1、 若測試人員以發現缺陷為唯一目標，而很少去關注系統對需求的實現，測試活動往往會存在一定的隨意性和盲目性；
2、 若有些軟件企業接受了這樣的方法，以Bug數量來做為考核測試人員業績的唯一指標，也不太科學。
總的來說，第一類測試可以簡單抽象地描述為這樣的過程：在設計規定的 環境下運行軟件的功能，將其結果與用戶需求或設計結果相比較，如果相符則測試通過，如果不相符則視為Bug。這一過程的終極目標是將軟件的所有功能在所有設計規定的環境全部運行，并通過。在軟件行業中一般把第一類方法奉為主流和行業標準。第一類測試方法以需求和設計為本，因此有利于界定測試工作的范疇，更便于部署測試的側重點，加強針對性。這一點對于大型軟件的測試，尤其是在有限的時間和人力資源情況下顯得格外重要。
而第二類測試方法與需求和設計沒有必然的關聯，更強調測試人員發揮主觀能動性，用逆向思維方式，不斷思考開發人員理解的誤區、不良的習慣、程序代碼的邊界、無效數據的輸入以及系統各種的弱點，試圖破壞系統、摧毀系統，目標就是發現系統中各種各樣的問題。這種方法往往能夠發現系統中存在的更多缺陷。
到了上世紀80年代初期，軟件和IT行業進入了大發展，軟件趨向大型化、高復雜度，軟件的質量越來越重要。這個時候，一些軟件測試的基礎理論和實用技術開始形成，并且人們開始為軟件開發設計了各種流程和管理方法，軟件開發的方式也逐漸由混亂無序的開發過程過渡到結構化的開發過程，以結構化分析與設計、結構化評審、結構化程序設計以及結構化測試為特征。人們還將“質量”的概念融入其中，軟件測試定義發生了改變，測試不單純是一個發現錯誤的過程，而且將測試作為軟件質量保證（SQA）的主要職能，包含軟件質量評價的內容，Bill Hetzel在《軟件測試完全指南》（Complete Guide of Software Testing）一書中指出：“測試是以評價一個程序或者系統屬性為目標的任何一種活動。測試是對軟件質量的度量�！边@個定義至今仍被引用。軟件開發人員和測試人員開始坐在一起探討軟件工程和測試問題。軟件測試已有了行業標準（IEEE/ANSI ），1983年IEEE提出的軟件工程術語中給軟件測試下的定義是：“使用人工或自動的手段來運行或測定某個軟件系統的過程，其目的在于檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別”。這個定義明確指出：軟件測試的目的是為了檢驗軟件系統是否滿足需求。它再也不是一個一次性的，而且只是開發后期的活動，而是與整個開發流程融合成一體。軟件測試已成為一個專業，需要運用專門的方法和手段，需要專門人才和專家來承擔。
軟件測試成熟度
隨著軟件產業界對軟件過程的不斷研究，美國工業界和政府部門開始認識到，軟件過程能力的不斷改進才是增進軟件開發組織的開發能力和提高軟件質量的第一要素。在這種背景下，由美國卡內基-梅隆大學軟件工程研究所（SEI）研制并推出了軟件能力成熟度模型SW-CMM，CMM逐漸成為了評估軟件開發過程的管理以及工程能力的標準。從80年代中期開始，軟件生產開始進入以個體軟件過程PSP(Personal Software Process)、過程成熟度模型CMM和群組軟件過程TSP(Team Software Process)為標志的、以過程為中心的第二階段。
但是令人遺憾的是，CMM 沒有充分的定義軟件測試，沒有提及測試成熟度的概念，沒有對測試過程改進進行充分說明，在 KPA 中沒有定義測試問題，與質量相關的測試問題如可測性，充分測試標準，測試計劃等方面也沒有滿意的闡述。僅在第三級的軟件產品工程（SPE）KPA中提及軟件測試職能，但對于如何有效提高機構的測試能力和水平沒有提供相應指導，無疑是一種不足。為此，許多研究機構和測試服務機構從不同角度出發提出有關軟件測試方面的能力成熟度模型，作為SEI-CMM的有效補充，比較有代表性的包括：美國國防部提出一個CMM軟件評估和測試KPA建議；Gelper博士提出一個測試支持模型（TSM）評估測試小組所處環境對于他們的支持程度；Burgess/Drabick I.T.I.公司提出的測試能力成熟度模型（Testing Capability Maturity Model）則提供了與CMM完全一樣的5級模型。Burnstein博士提出了測試成熟度模型（TMM），依據CMM的框架提出測試的5個不同級別，關注于測試的成熟度模型。它描述了測試過程，是項目測試部分得到良好計劃和控制的基礎。 TMM 測試成熟度分解為 5 級別，關注于 5 個成熟度級別遞增：
Phase 0 ：測試和調試沒有區別，初了支持調試外，測試沒有其他目的
Phase 1 ：測試的目的是為了表明軟件能夠工作
Phase 2 ：測試的目的是為了表明軟件不能夠能夠正常工作
Phase 3 ：測試的目的不是要證明什么，而是為了把軟件不能正常工作的預知風險降低到能夠接受的程度
Phase 4 ： 測試不是行為，而是一種自覺的約束 (mental discipline) ，不用太多的測試投入產生低風險的軟件上的 。
軟件測試模型的演變
軟件測試模型與軟件測試標準的研究也隨著軟件工程的發展而越來越深入，在２０世紀８０年代后期Paul Rook提出了著名的軟件測試的V模型，旨在改進軟件開發的效率和效果。Ｖ模型反映出了測試活動與分析設計活動的關系。在圖1-1中，從左到右描述了基本的開發過程和測試行為，非常明確的標注了測試過程中存在的不同類型的測試，并且清楚的描述了這些測試階段和開發過程期間各階段的對應關系。
圖 1-1
V模型指出，單元和集成測試應檢測程序的執行是否滿足軟件設計的要求；系統測試應檢測系統功能、性能的質量特性是否達到系統要求的指標；驗收測試確定軟件的實現是否滿足用戶需要或合同的要求。但V模型存在一定的局限性，它僅僅把測試作為在編碼之后的一個階段，是針對程序進行的尋找錯誤的活動，而忽視了測試活動對需求分析、系統設計等活動的驗證和確認的功能。
Evolutif公司針對V模型的缺陷，相對于V模型，提出了W模型的概念，W模型增加了軟件各開發階段中應同步進行的驗證和確認活動。如圖1-2所示，W模型由兩個V字型模型組成，分別代表測試與開發過程，圖中明確表示出了測試與開發的并行關系。
W模型強調：測試伴隨著整個軟件開發周期，而且測試的對象不僅僅是程序，需求、設計等同樣要測試，也就是說，測試與開發是同步進行的。W模型有利于盡早地全面的發現問題。例如，需求分析完成后，測試人員就應該參與到對需求的驗證和確認活動中，以盡早地找出缺陷所在。同時，對需求的測試也有利于及時了解項目難度和測試風險，及早制定應對措施，這將顯著減少總體測試時間，加快項目進度。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/