軟件測試流程_第1頁
軟件測試流程_第2頁
軟件測試流程_第3頁
軟件測試流程_第4頁
軟件測試流程_第5頁
已閱讀5頁,還剩65頁未讀 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

軟件測試流程第1頁,共70頁,2023年,2月20日,星期二軟件測試的復(fù)雜性和經(jīng)濟性軟件測試的相關(guān)流程:單元測試、集成測試、確認測試、系統(tǒng)測試和驗收測試等基本測試階段。第2頁,共70頁,2023年,2月20日,星期二人們在對軟件工程開發(fā)的常規(guī)認識中,認為開發(fā)程序是一個復(fù)雜而困難的過程,需要花費大量的人力、物力和時間,而測試一個程序則比較容易,不需要花費太多的精力。這其實是人們對軟件工程開發(fā)過程理解上的一個誤區(qū)。在實際的軟件開發(fā)過程中,作為現(xiàn)代軟件開發(fā)工業(yè)一個非常重要的組成部分,軟件測試正扮演著越來越重要的角色。隨著軟件規(guī)模的不斷擴大,如何在有限的條件下對被開發(fā)軟件進行有效的測試正成為軟件工程中一個非常關(guān)鍵的課題。第3頁,共70頁,2023年,2月20日,星期二設(shè)計測試用例是一項細致并且需要具備高度技巧的工作,稍有不慎就會顧此失彼,發(fā)生不應(yīng)有的疏漏。下面分析了容易出現(xiàn)問題的根源。(1)完全測試是不現(xiàn)實的在實際的軟件測試工作中,不論采用什么方法,由于軟件測試情況數(shù)量極其巨大,都不可能進行完全徹底的測試。所謂徹底測試,就是讓被測程序在一切可能的輸入情況下全部執(zhí)行一遍。通常也稱這種測試為“窮舉測試”。窮舉測試會引起以下幾種問題:輸入量太大;輸出結(jié)果太多;軟件執(zhí)行路徑太多;說明書存在主觀性。第4頁,共70頁,2023年,2月20日,星期二E.W.Dijkstra的一句名言對測試的不徹底性作了很好的注解:“程序測試只能證明錯誤的存在,但不能證明錯誤的不存在”。由于窮舉測試工作量太大,實踐上行不通,這就注定了一切實際測試都是不徹底的,也就不能夠保證被測試程序在理論上不存在遺留的錯誤。第5頁,共70頁,2023年,2月20日,星期二(2)軟件測試是有風險的窮舉測試的不可行性使得大多數(shù)軟件在進行測試的時候只能采取非窮舉測試,這又意味著一種冒險。比如在使用MicrosoftOffice工具中的Word時,可以作這樣的一個測試:①新建一個Word文檔;②在文檔中輸入漢字

“胡”;③設(shè)置其字體屬性為“隸書”,字號為初號,效果為“

空心”;④將頁面的顯示比例設(shè)為“500%”。這時在“胡”字的內(nèi)部會出現(xiàn)“胡萬進印”四個字。類似問題在實際測試中如果不使用窮舉測試是很難發(fā)現(xiàn)的,而如果在軟件投入市場時才發(fā)現(xiàn)則修復(fù)代價就會非常高。這就會產(chǎn)生一個矛盾:軟件測試員不能做到完全的測試,不完全測試又不能證明軟件的百分之百的可靠。那么如何在這兩者的矛盾中找到一個相對的平衡點呢?第6頁,共70頁,2023年,2月20日,星期二如圖3-1所示的最優(yōu)測試量示意圖可以觀察到,當軟件缺陷降低到某一數(shù)值后,隨著測試從量的不斷上升軟件缺陷并沒有明顯地下降。這是軟件測試工作中需要注意的重要問題。如何把測試數(shù)據(jù)量巨大的軟件測試減少到可以控制的范圍,如何針對風險做出最明智的選擇是軟件測試人員必須能夠把握的關(guān)鍵問題。圖3-1的最優(yōu)測試量示意圖說明了發(fā)現(xiàn)軟件缺陷數(shù)量和測試量之間的關(guān)系,隨著測試量的增加,測試成本將呈幾何數(shù)級上升,而軟件缺陷降低到某一數(shù)值之后將沒有明顯的變化,最優(yōu)測量值就是這兩條曲線的交點。第7頁,共70頁,2023年,2月20日,星期二圖3-1最優(yōu)測試量示意圖第8頁,共70頁,2023年,2月20日,星期二(3)殺蟲劑現(xiàn)象1990年,BorisBeizer在其編著的《SoftwareTestingTechniques》(第二版)中提到了“殺蟲劑怪事”一詞,同一種測試工具或方法用于測試同一類軟件越多,則被測試軟件對測試的免疫力就越強。這與農(nóng)藥殺蟲是一樣的,老用一種農(nóng)藥,則害蟲就有了免疫力,農(nóng)藥就失去了作用。由于軟件開發(fā)人員在開發(fā)過程中可能碰見各種各樣的主客觀因素,再加上不可預(yù)見的突發(fā)性事件,所以再優(yōu)秀的軟件測試員采用一種測試方法或者工具也不可能檢測出所有的缺陷。為了克服被測試軟件的免疫力,軟件測試員必須不斷編寫新的測試程序,對程序的各個部分進行不斷地測試,以避免被測試軟件對單一的測試程序具有免疫力而使軟件缺陷不被發(fā)現(xiàn)。這就對軟件測試人員的素質(zhì)提出了很高的要求。第9頁,共70頁,2023年,2月20日,星期二(4)缺陷的不確定性在軟件測試中還有一個讓人不容易判斷的現(xiàn)象是缺陷的不確定性。即并不是所有的軟件缺陷都需要被修復(fù)。對于究竟什么才算是軟件缺陷是一個很難把握的標準,在任何一本軟件測試的書中都只能給出一個籠統(tǒng)的定義。實際測試中需要把這一定義根據(jù)具體的被測對象明確化。即使這樣,具體的測試人員對軟件系統(tǒng)的理解不同,還是會出現(xiàn)不同的標準。第10頁,共70頁,2023年,2月20日,星期二軟件測試的經(jīng)濟性有兩方面體現(xiàn):一是體現(xiàn)在測試工作在整個項目開發(fā)過程中的重要地位;二是體現(xiàn)在應(yīng)該按照什么樣的原則進行測試,以實現(xiàn)測試成本與測試效果的統(tǒng)一。軟件工程的總目標是充分利用有限的人力和物力資源,高效率、高質(zhì)量地完成測試。結(jié)合3.1.1節(jié)關(guān)于窮舉測試具有不可行性,就可以理解為什么要在測試量與測試成本的曲線中選取最優(yōu)測試點。第11頁,共70頁,2023年,2月20日,星期二軟件測試的充分性準則有以下幾點:對任何軟件都存在有限的充分測試集合;當一個測試的數(shù)據(jù)集合對于一個被測的軟件系統(tǒng)的測試是充分的,那么再多增加一些測試數(shù)據(jù)仍然是充分的。這一特性稱為軟件測試的單調(diào)性;即使對軟件所有成分都進行了充分的測試,也并不意味著整個軟件的測試已經(jīng)充分了。這一特性稱為軟件測試的非復(fù)合性;即使對一個軟件系統(tǒng)整體的測試是充分的,也并不意味著軟件系統(tǒng)中各個成分都已經(jīng)充分地得到了測試。這個特性稱為軟件測試的非分解性;軟件測試的充分性與軟件的需求、軟件的實現(xiàn)都相關(guān);軟件測試的數(shù)據(jù)量正比于軟件的復(fù)雜度。這一特性稱為軟件測試的復(fù)雜性;隨著測試次數(shù)的增加,檢查出軟件缺陷的幾率隨之不斷減少。軟件測試具有回報遞減率。第12頁,共70頁,2023年,2月20日,星期二隨著軟件產(chǎn)業(yè)工業(yè)化、模塊化地發(fā)展,在軟件開發(fā)組中軟件測試人員的重要性也不斷地突出。在國外,很多著名企業(yè)早已對軟件測試工作十分重視。比如著名的微軟公司,其軟件測試人員與開發(fā)人員的比例已經(jīng)達到2:1??梢娷浖y試對于一個軟件開發(fā)項目的成功與否具有十分重要的意義。但是在實際的項目開發(fā)與管理中仍然存在很多管理上或者技術(shù)上的誤區(qū):(1)期望用測試自動化代替大部分人工勞動(2)忽視需求階段的參與(3)軟件測試是技術(shù)要求不高的崗位第13頁,共70頁,2023年,2月20日,星期二1.軟件開發(fā)的V模型軟件測試是有階段性的,而軟件測試的流程與軟件設(shè)計周期究竟是什么樣的關(guān)系呢?關(guān)于軟件開發(fā)流程的V模型是一個廣為人知的模型,如圖3-2所示。在V模型中,從左到右描述了基本的開發(fā)過程和測試行為,為軟件的開發(fā)人員和測試管理者提供了一個極為簡單的框架。V模型的價值在于它非常明確地標明了測試過程中存在的不同級別,并且清楚地描述了這些測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系。在V模型中各個測試階段的執(zhí)行流程是:單元測試是基于代碼的測試,最初由開發(fā)人員執(zhí)行,以驗證其可執(zhí)行程序代碼的各個部分是否已達到了預(yù)期的功能要求;集成測試驗證了兩個或多個單元之間的集成是否正確,并且有針對性地對詳細設(shè)計中所定義的各單元之間的接口進行檢查;在單元測試和集成測試完成之后,系統(tǒng)測試開始用客戶環(huán)境模擬系統(tǒng)的運行,以驗證系統(tǒng)是否達到了在概要設(shè)計中所定義的功能和性能;最后,當技術(shù)部門完成了所有測試工作,由業(yè)務(wù)專家或用戶進行驗收測試,以確保產(chǎn)品能真正符合用戶業(yè)務(wù)上的需要。圖3-2描繪出了各個測試環(huán)節(jié)在整個軟件測試工作中的相互聯(lián)系與制約關(guān)系。第14頁,共70頁,2023年,2月20日,星期二圖3-2

V模型示意圖第15頁,共70頁,2023年,2月20日,星期二2.軟件測試過程軟件測試過程按各測試階段的先后順序可分為單元測試、集成測試、確認(有效性)測試、系統(tǒng)測試和驗收(用戶)測試5個階段,如圖3-3所示。(1)單元測試:測試執(zhí)行的開始階段。測試對象是每個單元。測試目的是保證每個模塊或組件能正常工作。單元測試主要采用白盒測試方法,檢測程序的內(nèi)部結(jié)構(gòu)。(2)集成測試:也稱組裝測試。在單元測試基礎(chǔ)上,對已測試過的模塊進行組裝,進行集成測試。測試目的是檢驗與接口有關(guān)的模塊之間的問題。集成測試主要采用黑盒測試方法。(3)確認測試:也稱有效性測試。在完成集成測試后,驗證軟件的功能和性能及其他特性是否符合用戶要求。測試目的是保證系統(tǒng)能夠按照用戶預(yù)定的要求工作。確認測試通常采用黑盒測試方法。(4)系統(tǒng)測試:在完成確認測試后,為了檢驗它能否與實際環(huán)境(如軟硬件平臺、數(shù)據(jù)和人員等)協(xié)調(diào)工作,還需要進行系統(tǒng)測試??梢哉f,系統(tǒng)測試之后,軟件產(chǎn)品基本滿足開發(fā)要求。(5)驗收測試:測試過程的最后一個階段。驗收測試主要突出用戶的作用,同時軟件開發(fā)人員也應(yīng)該參與進去。第16頁,共70頁,2023年,2月20日,星期二軟件測試階段的輸入信息包括兩類:軟件配置:指測試對象。通常包括需求說明書、設(shè)計說明書和被測試的源程序等;測試配置:通常包括測試計劃、測試步驟、測試用例以及具體實施測試的測試程序、測試工具等。對測試結(jié)果與預(yù)期的結(jié)果進行比較以后,即可判斷是否存在錯誤,決定是否進入排錯階段,進行調(diào)試任務(wù)。對修改以后的程序要進行重新測試,因為修改可能會帶來新的問題。通常根據(jù)出錯的情況得到出錯率來預(yù)估被測軟件的可靠性,這將對軟件運行后的維護工作有重要價值。第17頁,共70頁,2023年,2月20日,星期二圖3-3測試各階段示意圖第18頁,共70頁,2023年,2月20日,星期二1.單元測試的定義單元測試(UnitTesting)是對軟件基本組成單元進行的測試。單元測試的對象是軟件設(shè)計的最小單位——模塊。很多人將單元的概念誤解為一個具體函數(shù)或一個類的方法,這種理解并不準確。作為一個最小的單元應(yīng)該有明確的功能定義、性能定義和接口定義,而且可以清晰地與其他單元區(qū)分開來。一個菜單、一個顯示界面或者能夠獨立完成的具體功能都可以是一個單元。從某種意義上單元的概念已經(jīng)擴展為組件(component)。第19頁,共70頁,2023年,2月20日,星期二2.單元測試的目標單元測試的主要目標是確保各單元模塊被正確地編碼。單元測試除了保證測試代碼的功能性,還需要保證代碼在結(jié)構(gòu)上具有可靠性和健全性,并且能夠在所有條件下正確響應(yīng)。進行全面的單元測試,可以減少應(yīng)用級別所需的工作量,并且徹底減少系統(tǒng)產(chǎn)生錯誤的可能性。如果手動執(zhí)行,單元測試可能需要大量的工作,自動化測試會提高測試效率。第20頁,共70頁,2023年,2月20日,星期二3.單元測試的內(nèi)容單元測試的主要內(nèi)容有:模塊接口測試;局部數(shù)據(jù)結(jié)構(gòu)測試;獨立路徑測試;錯誤處理測試;邊界條件測試。如圖3-4所示,這些測試都作用于模塊,共同完成單元測試任務(wù)。模塊接口測試:對通過被測模塊的數(shù)據(jù)流進行測試。為此,對模塊接口,包括參數(shù)表、調(diào)用子模塊的參數(shù)、全程數(shù)據(jù)、文件輸入/輸出操作都必須檢查。第21頁,共70頁,2023年,2月20日,星期二局部數(shù)據(jù)結(jié)構(gòu)測試:設(shè)計測試用例檢查數(shù)據(jù)類型說明、初始化、默認值等方面的問題,還要查清全程數(shù)據(jù)對模塊的影響。獨立路徑測試:選擇適當?shù)臏y試用例,對模塊中重要的執(zhí)行路徑進行測試?;韭窂綔y試和循環(huán)測試可以發(fā)現(xiàn)大量的路徑錯誤,是最常用且最有效的測試技術(shù)。錯誤處理測試:檢查模塊的錯誤處理功能是否包含有錯誤或缺陷。例如,是否拒絕不合理的輸入;出錯的描述是否難以理解、是否對錯誤定位有誤、是否出錯原因報告有誤、是否對錯誤條件的處理不正確;在對錯誤處理之前錯誤條件是否已經(jīng)引起系統(tǒng)的干預(yù)等。邊界條件測試:要特別注意數(shù)據(jù)流、控制流中剛好等于、大于或小于確定的比較值時出錯的可能性。對這些地方要仔細地選擇測試用例,認真加以測試。此外,如果對模塊運行時間有要求的話,還要專門進行關(guān)鍵路徑測試,以確定最壞情況下和平均意義下影響模塊運行時間的因素。這類信息對進行性能評價是十分有用的。第22頁,共70頁,2023年,2月20日,星期二4.單元測試的步驟通常單元測試在編碼階段進行。當源程序代碼編制完成,經(jīng)過評審和驗證,確認沒有語法錯誤之后,就開始進行單元測試的測試用例設(shè)計。利用設(shè)計文檔,設(shè)計可以驗證程序功能、找出程序錯誤的多個測試用例。對于每一組輸入,應(yīng)有預(yù)期的正確結(jié)果。模塊接口測試中的被測模塊并不是一個獨立的程序,在考慮測試模塊時,同時要考慮它和外界的聯(lián)系,用一些輔助模塊去模擬與被測模塊相關(guān)聯(lián)的模塊。這些輔助模塊可分為兩種:(1)驅(qū)動模塊(driver):相當于被測模塊的主程序。它接收測試數(shù)據(jù),把這些數(shù)據(jù)傳送給被測模塊,最后輸出實測結(jié)果。(2)樁模塊(stub):用以代替被測模塊調(diào)用的子模塊。樁模塊可以做少量的數(shù)據(jù)操作,不需要把子模塊所有功能都帶進來,但不允許什么事情也不做。第23頁,共70頁,2023年,2月20日,星期二被測模塊、與它相關(guān)的驅(qū)動模塊以及樁模塊共同構(gòu)成了一個“測試環(huán)境”,如圖3-5所示。如果一個模塊要完成多種功能,并且以程序包或?qū)ο箢惖男问匠霈F(xiàn),例如Ada中的包,MODULA中的模塊,C++中的類,這時可以將模塊看成由幾個小程序組成。對其中的每個小程序先進行單元測試要做的工作,對關(guān)鍵模塊還要做性能測試。對支持某些標準規(guī)程的程序,更要著手進行互聯(lián)測試。有人把這種情況特別稱為模塊測試,以區(qū)別單元測試。第24頁,共70頁,2023年,2月20日,星期二圖3-4單元測試任務(wù)第25頁,共70頁,2023年,2月20日,星期二5.采用單元測試的原因程序員編寫代碼時,一定會反復(fù)調(diào)試保證其能夠編譯通過。如果是編譯沒有通過的代碼,沒有任何人會愿意交付給自己的老板。但代碼通過編譯,只是說明了它的語法正確,程序員卻無法保證它的語義也一定正確。沒有任何人可以輕易承諾這段代碼的行為一定是正確的。單元測試這時會為此做出保證。編寫單元測試就是用來驗證這段代碼的行為是否與軟件開發(fā)人員期望的一致。有了單元測試,程序員可以自信的交付自己的代碼,而沒有任何的后顧之憂。第26頁,共70頁,2023年,2月20日,星期二圖3-5單元測試環(huán)境第27頁,共70頁,2023年,2月20日,星期二通過單元測試,測試人員可以驗證開發(fā)人員所編寫的代碼是按照先前設(shè)想的方式進行的,輸出結(jié)果符合預(yù)期值,這就實現(xiàn)了單元測試的目的。與后面的測試相比,單元測試創(chuàng)建簡單,維護容易,并且可以更方便的進行重復(fù)。《實用軟件度量》(CapersJones,McGraw-Hill1991)列出了準備測試、執(zhí)行測試和修改缺陷所花費的時間(以一個功能點為基準),這些測試顯示出了單元測試的成本效率大約是集成測試的兩倍、系統(tǒng)測試的三倍,如圖3-6所示。術(shù)語域測試是指軟件在投入使用后,針對某個領(lǐng)域所作的所有測試活動。第28頁,共70頁,2023年,2月20日,星期二圖3-6各測試階段發(fā)現(xiàn)缺陷的耗時第29頁,共70頁,2023年,2月20日,星期二1.集成測試的定義在完成單元測試的基礎(chǔ)上,需要將所有模塊按照設(shè)計要求組裝成為系統(tǒng)。這時需要考慮以下問題:在把各個模塊連接起來的時候,穿越模塊接口的數(shù)據(jù)是否會丟失;一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響;各個子功能組合起來,能否達到預(yù)期要求的父功能;全局數(shù)據(jù)結(jié)構(gòu)是否有問題;單個模塊的誤差累積起來,是否會放大,從而達到不能接受的程度;單個模塊的錯誤是否會導(dǎo)致數(shù)據(jù)庫錯誤。第30頁,共70頁,2023年,2月20日,星期二集成測試(IntegrationTesting)是介于單元測試和系統(tǒng)測試之間的過渡階段,與軟件開發(fā)計劃中的軟件概要設(shè)計階段相對應(yīng),是單元測試的擴展和延伸。集成測試的定義是根據(jù)實際情況對程序模塊采用適當?shù)募蓽y試策略組裝起來,對系統(tǒng)的接口以及集成后的功能進行正確校驗的測試工作。第31頁,共70頁,2023年,2月20日,星期二2.集成測試的層次軟件的開發(fā)過程是一個從需求分析到概要設(shè)計、詳細設(shè)計以及編碼實現(xiàn)的逐步細化的過程,那么單元測試到集成測試再到系統(tǒng)測試就是一個逆向求證的過程。集成測試內(nèi)部對于傳統(tǒng)軟件和面向?qū)ο蟮膽?yīng)用系統(tǒng)有兩種層次的劃分。對于傳統(tǒng)軟件來講,可以把集成測試劃分為三個層次:模塊內(nèi)集成測試;子系統(tǒng)內(nèi)集成測試;子系統(tǒng)間集成測試。對于面向?qū)ο蟮膽?yīng)用系統(tǒng)來說,可以把集成測試分為兩個階段:類內(nèi)集成測試;類間集成測試。第32頁,共70頁,2023年,2月20日,星期二3.集成測試的模式選擇什么方式把模塊組裝起來形成一個可運行的系統(tǒng),直接影響到模塊測試用例的形式、所用測試工具的類型、模塊編號的次序和測試的次序、生成測試用例的費用和調(diào)試的費用。集成測試模式是軟件集成測試中的策略體現(xiàn),其重要性是明顯的,直接關(guān)系到軟件測試的效率、結(jié)果等,一般是根據(jù)軟件的具體情況來決定采用哪種模式。通常,把模塊組裝成為系統(tǒng)的測試方式有兩種:⑴一次性集成測試方式(No-IncrementalIntegration)一次性集成測試方式也稱作非增值式集成測試。先分別測試每個模塊,再把所有模塊按設(shè)計要求放在一起結(jié)合成所需要實現(xiàn)的程序。第33頁,共70頁,2023年,2月20日,星期二如圖3-7是所示按照一次性集成測試方式的實例。如圖3-7(a)所示表示的是整個系統(tǒng)結(jié)構(gòu),共包含6個模塊。具體測試過程如下:如圖3-7(b)所示,為模塊B配備驅(qū)動模塊D1,來模擬模塊A對B的調(diào)用。為模塊B配備樁模塊S1,來模擬模塊E被B調(diào)用。對模塊B進行單元測試;如圖3-7(d)所示,為模塊D配備驅(qū)動模塊D3,來模擬模塊A對D的調(diào)用。為模塊D配備樁模塊S2,來模擬模塊F被D調(diào)用。對模塊D進行單元測試;如圖3-7(c)、圖3-7(e)、圖3-7(f)所示,為模塊C、E、F分別配備驅(qū)動模塊D2、D4、D5。對模塊C、E、F分別進行單元測試;如圖3-7(g)表示,為主模塊A配備三個樁模塊S3、S4、S5。對模塊A進行單元測試;在將模塊A、B、C、D、E分別進行了單元測試之后,再一次性進行集成測試;測試結(jié)束。第34頁,共70頁,2023年,2月20日,星期二圖3-7一次性集成測試方式第35頁,共70頁,2023年,2月20日,星期二⑵增值式集成測試方式把下一個要測試的模塊同已經(jīng)測好的模塊結(jié)合起來進行測試,測試完畢,再把下一個應(yīng)該測試的模塊結(jié)合進來繼續(xù)進行測試。在組裝的過程中邊連接邊測試,以發(fā)現(xiàn)連接過程中產(chǎn)生的問題。通過增值逐步組裝成為預(yù)先要求的軟件系統(tǒng)。增值式集成測試方式有三種:自頂向下增值測試方式(Top-downIntegration)主控模塊作為測試驅(qū)動,所有與主控模塊直接相連的模塊作為樁模塊;根據(jù)集成的方式(深度或廣度),每次用一個模塊把從屬的樁模塊替換成真正的模塊;在每個模塊被集成時,都必須已經(jīng)進行了單元測試;進行回歸測試以確定集成新模塊后沒有引入錯誤。這種組裝方式將模塊按系統(tǒng)程序結(jié)構(gòu),沿著控制層次自頂向下進行組裝。自頂向下的增值方式在測試過程中較早地驗證了主要的控制和判斷點。選用按深度方向組裝的方式,可以首先實現(xiàn)和驗證一個完整的軟件功能。第36頁,共70頁,2023年,2月20日,星期二如圖3-8所示表示的是按照深度優(yōu)先方式遍歷的自頂向下增值的集成測試實例。具體測試過程如下:在樹狀結(jié)構(gòu)圖中,按照先左后右的順序確定模塊集成路線;如圖3-8(a)所示,先對頂層的主模塊A進行單元測試。就是對模塊A配以樁模塊S1、S2和S3,用來模擬它所實際調(diào)用的模塊B、C、D,然后進行測試;

如圖3-8(b)所示,用實際模塊B替換掉樁模塊S1,與模塊A連接,再對模塊B配以樁模塊S4,用來模擬模塊B對E的調(diào)用,然后進行測試;圖3-8(c)是將模塊E替換掉樁模塊S4并與模塊B相連,然后進行測試;判斷模塊E沒有葉子結(jié)點,也就是說以A為根結(jié)點的樹狀結(jié)構(gòu)圖中的最左側(cè)分支深度遍歷結(jié)束。轉(zhuǎn)向下一個分支;圖3-8(d)所示,模塊C替換掉樁模塊S2,連到模塊A上,然后進行測試;判斷模塊C沒有樁模塊,轉(zhuǎn)到樹狀結(jié)構(gòu)圖的最后一個分支;如圖3-8(e)所示,模塊D替換掉樁模塊S3,連到模塊A上,同時給模塊D配以樁模塊S5,來模擬其對模塊F的調(diào)用。然后進行測試;如圖3-8(f)所示,去掉樁模塊S5,替換成實際模塊F連接到模塊D上,然后進行測試;對樹狀結(jié)構(gòu)圖進行了完全測試,測試結(jié)束。第37頁,共70頁,2023年,2月20日,星期二圖3-8自頂向下增值測試方式第38頁,共70頁,2023年,2月20日,星期二②自底向上增值測試方式(Bottom-upIntegration)組裝從最底層的模塊開始,組合成一個構(gòu)件,用以完成指定的軟件子功能。編制驅(qū)動程序,協(xié)調(diào)測試用例的輸入與輸出;測試集成后的構(gòu)件;按程序結(jié)構(gòu)向上組裝測試后的構(gòu)件,同時除掉驅(qū)動程序。這種組裝的方式是從程序模塊結(jié)構(gòu)的最底層的模塊開始組裝和測試。因為模塊是自底向上進行組裝,對于一個給定層次的模塊,它的子模塊(包括子模塊的所有下屬模塊)已經(jīng)組裝并測試完成,所以不再需要樁模塊。在模塊的測試過程中如果需要從子模塊得到信息時可以直接運行子模塊獲得。如圖3-9表示的是按照自底向上增值的集成測試例子。首先,對處于樹狀結(jié)構(gòu)圖中葉子結(jié)點位置的模塊E、C、F進行單元測試,如圖3-9(a)、圖3-9(b)和圖3-9(c)所示,分別配以驅(qū)動模塊D1、D2和D3,用來模擬模塊B、模塊A和模塊D對它們的調(diào)用。然后,如圖3-9(d)和圖3-9(e)所示,去掉驅(qū)動模塊D1和D3,替換成模塊B和D分別與模塊E和F相連,并且設(shè)立驅(qū)動模塊D4和D5進行局部集成測試。最后,如圖3-9(f)所示,對整個系統(tǒng)結(jié)構(gòu)進行集成測試。第39頁,共70頁,2023年,2月20日,星期二圖3-9自底向上增值測試方式第40頁,共70頁,2023年,2月20日,星期二③混合增值測試方式(ModifiedTop-downIntegration)自頂向下增值的方式和自底向上增值的方式各有優(yōu)缺點。自頂向下增值方式的缺點是需要建立樁模塊。要使樁模塊能夠模擬實際子模塊的功能是十分困難的,同時涉及復(fù)雜算法。真正輸入/輸出的模塊處在底層,它們是最容易出問題的模塊,并且直到組裝和測試的后期才遇到這些模塊,一旦發(fā)現(xiàn)問題,會導(dǎo)致過多的回歸測試。自頂向下增值方式的優(yōu)點是能夠較早地發(fā)現(xiàn)在主要控制方面存在問題。自底向上增值方式的缺點是“程序一直未能作為一個實體存在,直到最后一個模塊加上去后才形成一個實體”。就是說,在自底向上組裝和測試的過程中,對主要的控制直到最后才接觸到。自底向上增值方式的優(yōu)點是不需要樁模塊,建立驅(qū)動模塊一般比建立樁模塊容易,同時由于涉及到復(fù)雜算法和真正輸入/輸出的模塊最先得到組裝和測試,可以把最容易出問題的部分在早期解決。此外自底向上增值的方式可以實施多個模塊的并行測試。第41頁,共70頁,2023年,2月20日,星期二有鑒于此,通常是把以上兩種方式結(jié)合起來進行組裝和測試。改進的自頂向下增值測試:基本思想是強化對輸入/輸出模塊和引入新算法模塊的測試,并自底向上組裝成為功能相當完整且相對獨立的子系統(tǒng),然后由主模塊開始自頂向下進行增值測試;自底向上—自頂向下的增值測試(混和法):首先對含讀操作的子系統(tǒng)自底向上直至根結(jié)點模塊進行組裝和測試,然后對含寫操作的子系統(tǒng)做自頂向下的組裝與測試;回歸測試:這種方式采取自頂向下的方式測試被修改的模塊及其子模塊,然后將這一部分視為子系統(tǒng),再自底向上測試,以檢查該子系統(tǒng)與其上級模塊的接口是否適配。第42頁,共70頁,2023年,2月20日,星期二⑶一次性集成測試方式與增值式集成測試方式的比較增值式集成方式需要編寫的軟件較多,工作量較大,花費的時間較多。一次性集成方式的工作量較?。辉鲋凳郊煞绞桨l(fā)現(xiàn)問題的時間比一次性集成方式早;增值式集成方式比一次性集成方式更容易判斷出問題的所在,因為出現(xiàn)的問題往往和最后加進來的模塊有關(guān);增值式集成方式測試的更為徹底;使用一次性集成方式可以多個模塊并行測試。這兩種模式各有利弊,在時間條件允許的情況下采用增值式集成測試方式有一定的優(yōu)勢。第43頁,共70頁,2023年,2月20日,星期二⑷集成測試的組織和實施集成測試是一種正規(guī)測試過程,必須精心計劃,并與單元測試的完成時間協(xié)調(diào)起來。在制定測試計劃時,應(yīng)考慮如下因素:是采用何種系統(tǒng)組裝方法來進行組裝測試;組裝測試過程中連接各個模塊的順序;模塊代碼編制和測試進度是否與組裝測試的順序一致;測試過程中是否需要專門的硬件設(shè)備。(5)集成測試完成的標志判定集成測試過程是否完成,可按以下幾個方面檢查:成功地執(zhí)行了測試計劃中規(guī)定的所有集成測試;修正了所發(fā)現(xiàn)的錯誤;測試結(jié)果通過了專門小組的評審。第44頁,共70頁,2023年,2月20日,星期二(6)采用集成測試的原因所有的軟件項目都不能擺脫系統(tǒng)集成這個階段。不管采用什么開發(fā)模式,具體的開發(fā)工作總得從一個一個的軟件單元做起,軟件單元只有經(jīng)過集成才能形成一個有機的整體。第45頁,共70頁,2023年,2月20日,星期二1.確認測試的定義確認測試最簡明、最嚴格的解釋是檢驗所開發(fā)的軟件是否能按用戶提出的要求運行。若能達到這一要求,則認為開發(fā)的軟件是合格的。因而有的軟件開發(fā)部門把確認測試稱為合格性測試(QualificationTesting)。確認測試又稱為有效性測試。它的任務(wù)是驗證軟件的功能和性能及其特性是否與客戶的要求一致。對軟件的功能和性能要求在軟件需求規(guī)格說明中已經(jīng)明確規(guī)定。確認測試階段工作如圖3-10所示:第46頁,共70頁,2023年,2月20日,星期二圖3-10

確認測試階段的工作第47頁,共70頁,2023年,2月20日,星期二2.確認測試的準則經(jīng)過確認測試,應(yīng)該為已開發(fā)的軟件做出結(jié)論性評價。這不外乎是以下兩種情況之一:經(jīng)過檢驗的軟件功能、性能及其他要求均已滿足需求規(guī)格說明書的規(guī)定,因而可被接受,視為是合格的軟件;經(jīng)過檢驗發(fā)現(xiàn)與需求說明書有相當?shù)钠x,得到一個各項缺陷的清單。對于第二種情況,往往很難在交付期以前把發(fā)現(xiàn)的問題糾正過來。這就需要開發(fā)部門和客戶進行協(xié)商,找出解決的辦法。第48頁,共70頁,2023年,2月20日,星期二3.進行確認測試確認測試是在模擬的環(huán)境(可能是就是開發(fā)的環(huán)境)下,運用黑盒測試的方法,驗證所測試件是否滿足需求規(guī)格說明書列出的需求。4.確認測試的結(jié)果在全部軟件測試的測試用例運行完后,所有的測試結(jié)果可以分為兩類:測試結(jié)果與預(yù)期的結(jié)果相符。說明軟件的這部分功能或性能特征與需求規(guī)格說明書相符合,從而這部分程序被接受;測試結(jié)果與預(yù)期的結(jié)果不符。說明軟件的這部分功能或性能特征與需求規(guī)格說明不一致,因此要為它提交一份問題報告。通過與用戶的協(xié)商,解決所發(fā)現(xiàn)的缺陷和錯誤。確認測試應(yīng)交付的文檔有:確認測試分析報告、最終的用戶手冊和操作手冊、項目開發(fā)總結(jié)報告。第49頁,共70頁,2023年,2月20日,星期二5.軟件配置審查軟件配置審查是確認測試過程的重要環(huán)節(jié)。其的目的是保證軟件配置的所有成分都齊全,各方面的質(zhì)量都符合要求,具備維護階段所必需的細資料并且已經(jīng)編排好分類的目錄。除了按合同規(guī)定的內(nèi)容和要求,由工人審查軟件配置之外,在確認測試的過程,應(yīng)當嚴格遵守用戶手冊和操作手冊中規(guī)定的使用步驟,以便檢查這些文檔資料的完整性和正確性。必須仔細記錄發(fā)現(xiàn)的遺漏和錯誤,并且適當?shù)匮a充和改正。第50頁,共70頁,2023年,2月20日,星期二1.系統(tǒng)測試的定義在軟件的各類測試中,系統(tǒng)測試是最接近于人們的日常測試實踐。它是將已經(jīng)集成好的軟件系統(tǒng),作為整個計算機系統(tǒng)的一個元素,與計算機硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起,在實際運行環(huán)境下,對計算機系統(tǒng)進行一系列的組裝測試和確認測試。第51頁,共70頁,2023年,2月20日,星期二2.系統(tǒng)測試的流程系統(tǒng)測試流程如圖3-11所示。由于系統(tǒng)測試的目的是驗證最終軟件系統(tǒng)是否滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計,所以在完成產(chǎn)品需求和系統(tǒng)設(shè)計文檔之后,系統(tǒng)測試小組就可以提前開始制定測試計劃和設(shè)計測試用例,不必等到集成測試階段結(jié)束。這樣可以提高系統(tǒng)測試的效率。第52頁,共70頁,2023年,2月20日,星期二圖3-11系統(tǒng)測試流程第53頁,共70頁,2023年,2月20日,星期二3.系統(tǒng)測試的目標確保系統(tǒng)測試的活動是按計劃進行的;驗證軟件產(chǎn)品是否與系統(tǒng)需求用例不相符合或與之矛盾;建立完善的系統(tǒng)測試缺陷記錄跟蹤庫;確保軟件系統(tǒng)測試活動及其結(jié)果及時通知相關(guān)小組和個人。第54頁,共70頁,2023年,2月20日,星期二4.系統(tǒng)測試的方針為項目指定一個測試工程師負責貫徹和執(zhí)行系統(tǒng)測試活動;測試組向各事業(yè)部總經(jīng)理/項目經(jīng)理報告系統(tǒng)測試的執(zhí)行狀況;系統(tǒng)測試活動遵循文檔化的標準和過程;向外部用戶提供經(jīng)系統(tǒng)測試驗收通過的項目;建立相應(yīng)項目的(BUG)缺陷庫,用于系統(tǒng)測試階段項目不同生命周期的缺陷記錄和缺陷狀態(tài)跟蹤;定期對系統(tǒng)測試活動及結(jié)果進行評估,向各事業(yè)部經(jīng)理/項目辦總監(jiān)/項目經(jīng)理匯報項目的產(chǎn)品質(zhì)量信息及數(shù)據(jù)。第55頁,共70頁,2023年,2月20日,星期二5.系統(tǒng)測試的設(shè)計為了保證系統(tǒng)測試質(zhì)量,必須在測試設(shè)計階段就對系統(tǒng)進行嚴密的測試設(shè)計。這就需要在測試設(shè)計中,從多方面考慮系統(tǒng)規(guī)格的實現(xiàn)情況。通常需要從以下幾個層次來進行設(shè)計:用戶層、應(yīng)用層、功能層、子系統(tǒng)層、協(xié)議層。第56頁,共70頁,2023年,2月20日,星期二6.幾種常見的系統(tǒng)測試方法(1)恢復(fù)測試也叫容錯測試,用來檢查系統(tǒng)的容錯能力。通常若計算機系統(tǒng)出現(xiàn)錯誤,就必須在一定時間內(nèi)從錯誤中恢復(fù)過來,修正錯誤并重新啟動系統(tǒng)。恢復(fù)測試是通過各種手段,讓軟件強制性地出錯,使其不能正常工作,從而檢驗系統(tǒng)的恢復(fù)能力。對于自動恢復(fù)系統(tǒng),即由系統(tǒng)自身完成恢復(fù)工作,則應(yīng)該檢驗重新初始化、檢查點、數(shù)據(jù)恢復(fù)和重新啟動等機制的正確性。對于人工干預(yù)恢復(fù)系統(tǒng),要評估平均修復(fù)時間是否在可接受的范圍。(2)安全測試安全測試的目的在于檢查系統(tǒng)對外界非法入侵的防范能力。在安全測試過程中,測試者扮演著非法入侵者,采用各種手段試圖突破防線,攻擊系統(tǒng)。例如,測試者可以嘗試通過外部的手段來破譯系統(tǒng)的密碼,或者可以有目的地引發(fā)系統(tǒng)錯誤,試圖在系統(tǒng)恢復(fù)過程中侵入系統(tǒng)等。系統(tǒng)的安全測試要設(shè)置一些測試用例試圖突破系統(tǒng)的安全保密防線,用來查找系統(tǒng)的安全保密的漏洞。系統(tǒng)安全測試的準則是讓非法侵入者攻擊系統(tǒng)的代價大于保護系統(tǒng)安全的價值。第57頁,共70頁,2023年,2月20日,星期二(3)強度測試也稱壓力測試、負載測試。強度測試是要破壞程序,檢測非正常的情況系統(tǒng)的負載能力。強度測試模擬實際情況下的軟硬件環(huán)境和用戶使用過程的系統(tǒng)負荷,長時間或超負荷地運行測試軟件來測試系統(tǒng),以檢驗系統(tǒng)能力的最高限度,從而了解系統(tǒng)的可靠性、穩(wěn)定性等。例如,將輸入的數(shù)據(jù)值提高一個或幾個數(shù)量級來測試輸入功能的響應(yīng)等。實際上,強度測試就是在一些特定情況下所做的敏感測試。比如數(shù)學算法中,在一個有效的數(shù)據(jù)范圍內(nèi)定義一個極小范圍的數(shù)據(jù)區(qū)間,這個數(shù)據(jù)區(qū)間中的數(shù)據(jù)本應(yīng)該是合理的,但往往又可能會引發(fā)異常的狀況或是引起錯誤的運行,導(dǎo)致程序的不穩(wěn)定性。敏感測試就是為了發(fā)現(xiàn)這種在有效的輸入數(shù)據(jù)區(qū)域內(nèi)可能會引發(fā)不穩(wěn)定性或者引起錯誤運行的數(shù)據(jù)集合和組合。(4)性能測試性能測試用來測試軟件在系統(tǒng)運行時的性能表現(xiàn),比如運行速度、系統(tǒng)資源占有或響應(yīng)時間等情況。對于實時系統(tǒng)或嵌入式系統(tǒng),若只能滿足功能需求而不能滿足性能需求,是不能被接受的。性能測試可以在測試過程的任意階段進行,例如,在單元層,一個獨立的模塊也可以運用白盒測試方法進行性能評估。但是,只有當一個系統(tǒng)的所有部分都集成后,才能檢測此系統(tǒng)的真正性能。第58頁,共70頁,2023年,2月20日,星期二(5)容量測試容量測試是指在系統(tǒng)正常運行的范圍內(nèi)測定系統(tǒng)能夠處理的數(shù)據(jù)容量,測試系統(tǒng)承受超額數(shù)據(jù)容量的能力。系統(tǒng)容量必須滿足用戶需求,如果不能滿足實際要求,必須努力改進,尋求解決辦法。暫時無法解決的需要在產(chǎn)品說明書中給予說明。(6)正確性測試正確性測試是為了檢測軟件的各項功能是否符合產(chǎn)品規(guī)格說明的要求。軟件的正確性與否關(guān)系著軟件的質(zhì)量好壞,所以非常重要。正確性測試的總體思路是設(shè)計一些邏輯正確的輸入值,檢查運行結(jié)果是不是期望值。正確性測試主要有兩種方法,一個是枚舉法,另一個是邊界值法。第59頁,共70頁,2023年,2月20日,星期二(7)可靠性測試可靠性測試是從驗證的角度出發(fā),檢驗系統(tǒng)的可靠性是否達到預(yù)期的目標,同時給出當前系統(tǒng)可能的可靠性增長情況??煽啃詼y試需要從用戶角度出發(fā),模擬用戶實際使用系統(tǒng)的情況,設(shè)計出系統(tǒng)的可操作視圖。(8)兼容性測試現(xiàn)今,客戶對各個開發(fā)商和各種軟件之間相互兼容、共享數(shù)據(jù)的能力要求越來越高,所以對于軟件兼容性的測試就非常重要。軟件兼容性測試是檢測各軟件之間能否正常地交互、共享信息,能否正確地和軟件合作完成數(shù)據(jù)處理。從而保障軟件能夠按照客戶期望的標準進行交互,多個軟件共同完成指定的任務(wù)。第60頁,共70頁,2023年,2月20日,星期二(9)Web網(wǎng)站測試Web網(wǎng)站測試是面向因特網(wǎng)Web頁面的測試。眾所周知,因特網(wǎng)網(wǎng)頁是由文字、圖形、聲音、視頻和超級鏈接等組成的文檔。網(wǎng)絡(luò)客戶端用戶通過在瀏覽器中的操作,搜索瀏覽所需要的信息資源。針對Web網(wǎng)站這一特定類型軟件的測試,包含了許多測試技術(shù),如功能測試、壓力/負載測試、配置測試、兼容性測試、安全性測試等。黑盒測試、白盒測試、靜態(tài)測試和動態(tài)測試都有可能被采用。第61頁,共70頁,2023年,2月20日,星期二1.驗收測試的定義驗收測試(AcceptanceTesting)是向未來的用戶表明系統(tǒng)能夠像預(yù)定要求的那樣工作。通過綜合測試之后,軟件已完全組裝起來,接口方面的錯誤也已排除,軟件測試的最后一步——驗收測試即可開始。驗收測試的目的是確保軟件準備就緒,并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務(wù)。驗收測試是檢驗軟件產(chǎn)品質(zhì)量的最后一道工序。驗收測試通常更突出客戶的作用,同時軟件開發(fā)人員也有一定的參與。如何組織好驗收測試并不是一件容易的事。以下對驗收測試的任務(wù)、目標以及驗收測試的組織管理給出詳細介紹。第62頁,共70頁,2023年,2月20日,星期二2.驗收測試的內(nèi)容軟件驗收測試應(yīng)完成的工作內(nèi)容如下:要明確驗收項目,規(guī)定驗收測試通過的標準;確定測試方法;決定驗收測試的組織機構(gòu)和可利用的資源;選定測試結(jié)果分析方法;指定驗收測試計劃并進行評審;設(shè)計驗收測試所用的測試用例;審查驗收測試的準備工作;執(zhí)行驗收測試;分析測試結(jié)果;做出驗

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論