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