軟件測試流程

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

“胡”；③設(shè)置其字體屬性為“隸書”，字號(hào)為初號(hào)，效果為“

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

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

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

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