第09九章軟件測試優(yōu)秀課件

第09九章軟件測試測試階段的信息流程2023/7/272測試階段的信息流程輸入流分軟件配置和測試配置兩項(xiàng),軟件配置由需求說明書、設(shè)計(jì)說明書和源代碼組成;測試配置中包含測試計(jì)劃、測試工具、測試用例和期望結(jié)果,有時(shí)測試配置亦作為軟件配置的一個(gè)組成部分。測試人員根據(jù)上述輸入信息測試程序并評價(jià)測試結(jié)果,當(dāng)測試結(jié)果與期望結(jié)果存在差異時(shí),往往程序有錯(cuò)。此時(shí)可采用排錯(cuò)技術(shù)定位錯(cuò)誤并改正之。通過對測試結(jié)果的收集和評價(jià),軟件質(zhì)量和軟件可靠性的一些定性指標(biāo)即能逐步確定下來。2023/7/273測試用例和場景的設(shè)計(jì)任何工程化的產(chǎn)品都有兩種測試方法:一種方法是已知產(chǎn)品應(yīng)該具有的功能,通過測試檢驗(yàn)每個(gè)功能是否都能正常使用;另一種方法是已知產(chǎn)品內(nèi)部工作過程,通過測試檢驗(yàn)產(chǎn)品內(nèi)部動作是否按照產(chǎn)品規(guī)格說明的規(guī)定正常進(jìn)行。前者稱為黑盒測試,后者稱為白盒測試。測試用例和測試場景將根據(jù)這兩種測試方法的特性制定。2023/7/274黑盒測試黑盒測試完全不考慮程序的內(nèi)部結(jié)構(gòu)和處理過程。測試僅在程序界面上進(jìn)行。設(shè)計(jì)測試用例旨在說明:①軟件的功能是否可操作;②程序能否適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)并產(chǎn)生正確的輸出結(jié)果或在可能的場景中事件驅(qū)動的效果是否盡如人意;③能否保持外部信息(如數(shù)據(jù)文件)的完整性。2023/7/275白盒測試白盒測試法密切關(guān)注處理細(xì)節(jié),針對程序的每一條邏輯路徑都要分別設(shè)計(jì)測試用例,檢查分枝和循環(huán)的情況。窮舉測試不可取,一般選用少量“最有效”,即最有可能暴露錯(cuò)誤的路徑進(jìn)行測試。測試的目的是為了找出錯(cuò)誤,所以無論采用黑盒法還是白盒法,設(shè)計(jì)測試用例時(shí)總是期望用盡可能少的時(shí)間和代價(jià)發(fā)現(xiàn)盡可能多的錯(cuò)誤。2023/7/276例：最多有1014個(gè)邏輯路徑,假設(shè)每運(yùn)行一個(gè)測試用例平均花費(fèi)1毫秒,總共需3170年才能窮盡所有測試。2023/7/277軟件測試的步驟軟件工程的開發(fā)過程和測試過程應(yīng)該是對應(yīng)的。第一章圖1.3采用V型圖表示開發(fā)—測試的對應(yīng)關(guān)系，也可以采用圖14.3所示的螺旋型圖表示。每旋轉(zhuǎn)一圈,測試的范圍加大一次:螺旋中心對應(yīng)單元測試,它測試源程序的每一模塊;下一步是綜合測試,它測試軟件總體結(jié)構(gòu);再下一步是確認(rèn)(驗(yàn)收)測試,測試軟件是否滿足需求;最后一步是系統(tǒng)測試,檢查軟件與系統(tǒng)中其他元素是否協(xié)調(diào)。2023/7/278軟件測試技術(shù)本節(jié)主要討論當(dāng)用白盒或黑盒測試法測試軟件時(shí),如何設(shè)計(jì)測試用例才能達(dá)到測試的目的。此外,對自動測試工具也作一些簡單介紹。2023/7/279白盒測試白盒測試應(yīng)該根據(jù)程序的控制結(jié)構(gòu)設(shè)計(jì)測試用例,原則是:①保證模塊中每一獨(dú)立的路徑至少執(zhí)行一次;②保證所有判斷的每一分枝至少執(zhí)行一次;③保證每一循環(huán)都在邊界條件和一般條件下至少各執(zhí)行一次;④驗(yàn)證所有內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性。2023/7/27101.基本路徑測試基本路徑測試的主要思想是，根據(jù)軟件過程性描述(詳細(xì)設(shè)計(jì)或代碼)中的控制流程確定復(fù)雜性度量,然后用此度量定義基本路徑集合,由此導(dǎo)出一組測試用例，它們能保證每個(gè)語句至少執(zhí)行一次。為了使用圖論的知識和術(shù)語,引入流圖(亦稱程序圖)的概念,流圖即把流程圖中結(jié)構(gòu)化構(gòu)件改用一般有向圖的表示形式。代表?xiàng)l件判斷的結(jié)點(diǎn)稱為謂詞結(jié)點(diǎn)。2023/7/2711結(jié)構(gòu)化構(gòu)件在流圖中的表示2023/7/2712例：流程圖2023/7/2713例：對應(yīng)的流圖2023/7/2714條件處理若判斷中含復(fù)合條件,則需增加謂詞結(jié)點(diǎn)。如OR運(yùn)算的處理。2023/7/2715基本路徑測試的思想基本路徑至少引入一個(gè)新語句或者新判斷的程序執(zhí)行通道測試用例的設(shè)計(jì)方法流程圖==>流圖==>基本路徑==>測試用例2023/7/2716Step1

根據(jù)程序的邏輯結(jié)構(gòu)畫出流程圖voidFunc(intnPosX,intnPosY){ while(nPosX>0){ intnSum=nPosX+nPosY; if(nSum>1){ nPosX--;nPosY--; } else{ if(nSum<-1)nPosX-=2; elsenPosX-=4; } } //endofwhile}2023/7/2717Step1

根據(jù)程序的邏輯結(jié)構(gòu)畫出流程圖2023/7/2718Step2

根據(jù)流程圖畫出流圖2023/7/2719Step3確定基本路徑的集合基本路徑流圖的Cyclomatic復(fù)雜度正好是基本路徑的數(shù)目V(G)=E–N+2V(G)=11-9+2=42023/7/2720

Step3確定基本路徑的集合1-111-2,3-4,5-10-1-111-2,3-6-7-9-10-1-111-2,3-6-8-9-10-1-112023/7/2721Step4對每條基本路徑設(shè)計(jì)測試用例對于路徑1–11nPosX取-1,nPosY取任意值1-2,3-4,5-10-1-11nPosX取1,nPosY取1對于路徑1-2,3-6-7-9-10-1–11nPosX取1,nPosY取-11-2,3-6-8-9-10-1-11

nPosX取1,nPosY取-32023/7/27222.控制結(jié)構(gòu)測試基本路徑測試是控制結(jié)構(gòu)測試技術(shù)的一種,下面介紹其他形式的控制結(jié)構(gòu)測試,它們比基本路徑測試法覆蓋程度更大,進(jìn)一步提高了白盒測試的質(zhì)量。2023/7/2723條件測試法條件測試主要考慮程序中的條件判斷,以期發(fā)現(xiàn)條件判斷內(nèi)部的錯(cuò)誤和程序中其他一些錯(cuò)誤。程序中“條件”分為簡單條件和復(fù)合條件。簡單條件為一個(gè)布爾變量或一個(gè)關(guān)系表達(dá)式(可能前綴邏輯非),復(fù)合條件由簡單條件通過邏輯運(yùn)算符(OR、AND、NOT)和括號連接而成。因此條件中可能出現(xiàn)的錯(cuò)誤類型包括:布爾運(yùn)算符錯(cuò)、布爾變量錯(cuò)、括號錯(cuò)、關(guān)系運(yùn)算符錯(cuò)和算術(shù)表達(dá)式錯(cuò)。最簡單的條件測試是分支測試。2023/7/2724分支和關(guān)系運(yùn)算測試法BRO能用少于2n次測試發(fā)現(xiàn)條件中大多數(shù)錯(cuò)誤,采用該方法的前提是條件中每個(gè)布爾變量和關(guān)系運(yùn)算符至多出現(xiàn)一次并無公共變量。BRO方法引入條件約束的概念,含n個(gè)簡單條件的復(fù)合條件C之約束D表示為(D1,D2,…Dn),Di(0＜i≤n)一般為某種符號,它指明簡單條件Ci在C中出現(xiàn)的約束。C的一次執(zhí)行覆蓋約束條件D指，C中出現(xiàn)的每個(gè)簡單條件Ci在這次執(zhí)行中都滿足D中對應(yīng)的約束Di。對于一個(gè)布爾表達(dá)式,出現(xiàn)約束或?yàn)檎?t)或?yàn)榧?f);對于一個(gè)關(guān)系表達(dá)式,出現(xiàn)約束用符號＞、＜或＝表示。2023/7/2725數(shù)據(jù)流測試法數(shù)據(jù)流測試法是根據(jù)程序中變量定義和引用的位置選擇測試路徑。為說明數(shù)據(jù)流測試法,假設(shè)程序中每個(gè)語句都被賦與一個(gè)唯一的標(biāo)號,并且每個(gè)函數(shù)都不修改其參數(shù)和全局變量,對以S為標(biāo)號的語句定義下面兩個(gè)集合:DEF(S)={X|語句S中含X的定義}USE(S)={X|語句S中含對X的引用}當(dāng)S為分支或循環(huán)語句時(shí),DEF集合為空,USE集合由S所含條件確定。如果從語句S到語句S’存在一條路徑并且在S’中不存在X的再定義,則稱在S中定義的X在S’處活躍。2023/7/2726數(shù)據(jù)流測試法（續(xù)）定義變量X的定義—引用鏈(DU鏈)為［X,S,S’］,其中S,S’為標(biāo)號,X∈DEF(S)∩USE(S’)且S中定義的X在S’處活躍。一種簡單的數(shù)據(jù)流測試策略即對每條DU鏈至少覆蓋一次,稱為DU測試策略,它對于測試含嵌套IF語句和多重循環(huán)語句的程序特別有效。2023/7/2727循環(huán)測試循環(huán)是大多數(shù)算法的基礎(chǔ),循環(huán)測試的目的是檢查循環(huán)結(jié)構(gòu)的有效性。循環(huán)分為簡單循環(huán)、并列循環(huán)、嵌套循環(huán)和非結(jié)構(gòu)循環(huán)四類：2023/7/27282023/7/2729循環(huán)測試（續(xù)）對于最多為n次的簡單循環(huán),應(yīng)作下列測試:1)完全跳過循環(huán);2)僅循環(huán)一次;3)循環(huán)兩次;4)循環(huán)m次,m＜n;5)分別循環(huán)(n-1)次,n次,n+1次。2023/7/2730循環(huán)測試（續(xù)）對于嵌套循環(huán)若生搬硬套簡單循環(huán)的測試策略。可能使測試次數(shù)成幾何級數(shù)增長,減少測試次數(shù)的具體措施包括:1)從最內(nèi)層循環(huán)開始測試,此時(shí)所有外層循環(huán)都取最小值,內(nèi)層循環(huán)按簡單循環(huán)的測試策略測試;2)由里向外,回退到上一層循環(huán)測試,這層循環(huán)的所有外層循環(huán)仍取最小值,由該層循環(huán)嵌套的那些循環(huán)取一些典型值。3)繼續(xù)向外擴(kuò)展,直至所有循環(huán)測試完畢。對于并置循環(huán)分兩種情況,若兩個(gè)循環(huán)完全獨(dú)立,采用簡單循環(huán)的測試策略,反之,若第一循環(huán)的計(jì)數(shù)器用作第二循環(huán)的初值,即兩循環(huán)不獨(dú)立,需用嵌套循環(huán)測試策略測試。非結(jié)構(gòu)化的循環(huán)需按結(jié)構(gòu)化程序設(shè)計(jì)的思想首先將程序結(jié)構(gòu)化然后再進(jìn)行測試。2023/7/2731黑盒測試黑盒測試旨在測試軟件是否滿足功能要求,它主要診斷下列幾類錯(cuò)誤:(1)不正確或遺漏的功能;(2)界面錯(cuò)誤;(3)數(shù)據(jù)結(jié)構(gòu)或外部數(shù)據(jù)庫訪問錯(cuò)誤;(4)性能錯(cuò)誤;(5)初始化和終止條件錯(cuò)誤。值得指出的是,黑盒測試法與白盒測試法不能互相替代,相反兩者應(yīng)互為補(bǔ)充,在測試的不同階段為發(fā)現(xiàn)不同類型的錯(cuò)誤而靈活選用。2023/7/27321.等價(jià)分類法等價(jià)分類法的主要思想是把程序的輸入數(shù)據(jù)集合按輸入條件劃分為若干個(gè)等價(jià)類,每一等價(jià)類相對于輸入條件表示為一組有效或無效的輸入,然后為每一等價(jià)類設(shè)計(jì)一個(gè)測試用例,這樣即可大大減小測試的次數(shù)又不丟失發(fā)現(xiàn)錯(cuò)誤的機(jī)會。因此等價(jià)分類法的關(guān)鍵是根據(jù)輸入數(shù)據(jù)的類型和程序的功能說明劃分等價(jià)類。2023/7/2733等價(jià)分類法常用的一些規(guī)則:(1)如果能為輸入條件指定一個(gè)范圍,則可劃分出一個(gè)有效的等價(jià)類(輸入值落在此范圍內(nèi))和兩個(gè)無效的等價(jià)類(大于最大值的輸入和小于最小值的輸入);(2)如果能為輸入條件指定一個(gè)特定值,則可類似地劃分出一個(gè)有效等價(jià)類和兩個(gè)無效等價(jià)類;(3)如果能為輸入條件指定一個(gè)集合,則可劃分出一個(gè)有效等價(jià)類(此集合)和一個(gè)無效等價(jià)類(此集合的補(bǔ)集);(4)如果能為輸入條件指定一個(gè)布爾量,則可劃分出一個(gè)有效等價(jià)類(此布爾量)和一個(gè)無效布爾量(此布爾量之非)。2023/7/27342.邊界值分析法經(jīng)驗(yàn)表明,大多數(shù)錯(cuò)誤都發(fā)生在輸入的邊界值上。為此,專門引入邊界值分析(BoundaryValueAnalysis)技術(shù),旨在選擇測試用例,強(qiáng)迫程序在邊界值上執(zhí)行。BVA技術(shù)是對等價(jià)分類技術(shù)的補(bǔ)充,即在一個(gè)等價(jià)類中不是任選一個(gè)元素作為此等價(jià)類的代表進(jìn)行測試,而是選擇此等價(jià)類邊界上的值。此外,采用BVA技術(shù)導(dǎo)出測試用例時(shí),不僅要考慮輸入條件,還要考慮輸出的狀態(tài)。2023/7/2735邊界值分析法采用BVA技術(shù)設(shè)計(jì)測試用例與等價(jià)分類法有許多相似之處:1)如果輸入條件指定了由值a,b括起來的一個(gè)范圍,那么值a、值b和緊挨a、b左右的值應(yīng)分別作為測試用例;2)如果輸入條件指定為一組數(shù),那么這組數(shù)中最大者、最小者和次大、次小者應(yīng)作為測試用例;3)應(yīng)用規(guī)則1)、2)于輸出條件。例如,假設(shè)某程序輸出為一張溫度壓力對照表,此時(shí)應(yīng)設(shè)計(jì)測試用例正好產(chǎn)生表項(xiàng)所允許的最大和最小值。4)如果內(nèi)部數(shù)據(jù)結(jié)構(gòu)是有界的(例如,某數(shù)組有100個(gè)元素),那么應(yīng)設(shè)計(jì)測試數(shù)據(jù)，使之能檢查該數(shù)據(jù)結(jié)構(gòu)的邊界。2023/7/27363.對比測試法在一些可靠性要求很高的系統(tǒng)中,經(jīng)常使用冗余的軟、硬件,以減少錯(cuò)誤發(fā)生的可能性。這時(shí),不同的軟件版本由不同的開發(fā)小組根據(jù)同一需求說明書開發(fā),并用相同的測試數(shù)據(jù)對它們進(jìn)行測試,保持結(jié)果一致。此后各版本并行執(zhí)行并實(shí)時(shí)地比較結(jié)果,確保系統(tǒng)的正確性。受此思想起發(fā),許多關(guān)鍵軟件，即使最后交付時(shí)只要求一個(gè)版本,開發(fā)時(shí)也另外產(chǎn)生一個(gè)獨(dú)立版本供測試使用。這種黑盒測試方法稱為對比測試或背靠背測試2023/7/2737軟件測試策略軟件測試策略主要考慮，如何把設(shè)計(jì)測試用例的技術(shù)組織成一個(gè)系統(tǒng)的、有計(jì)劃的測試步驟。測試策略應(yīng)包含測試規(guī)劃、測試用例設(shè)計(jì)、測試實(shí)施和測試結(jié)果收集評估等。其中測試規(guī)劃包括：測試的步驟、工作量、進(jìn)度和資源等本節(jié)重點(diǎn)討論測試步驟，測試中的排錯(cuò)技術(shù)2023/7/27381單元測試單元測試的對象是軟件設(shè)計(jì)的最小單位——模塊。單元測試的依據(jù)是詳細(xì)設(shè)計(jì)描述，單元測試應(yīng)對模塊內(nèi)所有重要的控制路徑設(shè)計(jì)測試用例,以便發(fā)現(xiàn)模塊內(nèi)部的錯(cuò)誤。單元測試多采用白盒測試技術(shù),系統(tǒng)內(nèi)多個(gè)模塊可以并行地進(jìn)行測試。2023/7/27391.1單元測試任務(wù)單元測試任務(wù)包括:1)模塊接口測試;2)模塊局部數(shù)據(jù)結(jié)構(gòu)測試;3)模塊邊界條件測試;4)模塊中所有獨(dú)立執(zhí)行通路測試;5)模塊的各條錯(cuò)誤處理通路測試。模塊接口測試是單元測試的基礎(chǔ)。只有在數(shù)據(jù)能正確流入、流出模塊的前提下,其他測試才有意義2023/7/2740測試接口考慮的因素①輸入的實(shí)際參數(shù)與形式參數(shù)的個(gè)數(shù)是否相同;②輸入的實(shí)際參數(shù)與形式參數(shù)的屬性是否匹配;③輸入的實(shí)際參數(shù)與形式參數(shù)的量綱是否一致;④調(diào)用其他模塊時(shí)所給實(shí)際參數(shù)的個(gè)數(shù)是否與被調(diào)模塊的形參個(gè)數(shù)相同;⑤調(diào)用其他模塊時(shí)所給實(shí)際參數(shù)的屬性是否與被調(diào)模塊的形參屬性匹配;⑥調(diào)用其他模塊時(shí)所給實(shí)際參數(shù)的量綱是否與被調(diào)模塊的形參量綱一致;⑦調(diào)用預(yù)定義函數(shù)時(shí)所用參數(shù)的個(gè)數(shù)、屬性和次序是否正確;⑧是否存在與當(dāng)前入口點(diǎn)無關(guān)的參數(shù)引用;⑨是否修改了只讀型參數(shù);10對全程變量的定義各模塊是否一致;11是否把某些約束作為參數(shù)傳遞。2023/7/2741測試接口考慮的因素（續(xù)）如果模塊內(nèi)包括外部輸入輸出,還應(yīng)該考慮下列因素:①文件屬性是否正確;②OPEN/CLOSE語句是否正確;③格式說明與輸入輸出語句是否匹配;④緩沖區(qū)大小與記錄長度是否匹配;⑤文件使用前是否已經(jīng)打開;⑥是否處理了文件尾;⑦是否處理了輸入/輸出錯(cuò)誤;⑧輸出信息中是否有文字性的錯(cuò)誤。2023/7/2742單元測試的任務(wù)（續(xù)）局部數(shù)據(jù)結(jié)構(gòu)往往是錯(cuò)誤的根源,應(yīng)仔細(xì)設(shè)計(jì)測試用例,力求發(fā)現(xiàn)下面幾類錯(cuò)誤:①不合適或不相容的類型說明;②變量無初值;③變量初始化或省缺值有錯(cuò);④不正確的變量名(拚錯(cuò)或不正確地截?cái)?;⑤出現(xiàn)上溢、下溢和地址異常。2023/7/2743單元測試的任務(wù)（續(xù)）在模塊中應(yīng)對每一條獨(dú)立執(zhí)行路徑進(jìn)行測試,單元測試的基本任務(wù)是保證模塊中每條語句至少執(zhí)行一次。此時(shí)設(shè)計(jì)測試用例是為了發(fā)現(xiàn)因錯(cuò)誤計(jì)算、不正確的比較和不適當(dāng)?shù)目刂屏髟斐傻腻e(cuò)誤。此時(shí)基本路徑測試和循環(huán)測試是最常用且最有效的測試技術(shù)。2023/7/2744單元測試的任務(wù)（續(xù)）計(jì)算中常見的錯(cuò)誤包括:①誤解或用錯(cuò)了算符優(yōu)先級;②混合類型運(yùn)算;③變量初值錯(cuò);④精度不夠;⑤表達(dá)式符號錯(cuò)。2023/7/2745單元測試的任務(wù)（續(xù)）比較判斷與控制流常常緊密相關(guān),測試用例還應(yīng)致力于發(fā)現(xiàn)下列錯(cuò)誤:①不同數(shù)據(jù)類型的對象之間進(jìn)行比較;②錯(cuò)誤地使用邏輯運(yùn)算符或優(yōu)先級;③因計(jì)算機(jī)表示的局限性，期望理論上相等而實(shí)際上不相等的兩個(gè)量相等;④比較運(yùn)算或變量出錯(cuò);⑤循環(huán)終止條件不合適或不可能出現(xiàn);⑥迭代發(fā)散時(shí)不能退出;⑦錯(cuò)誤地修改了循環(huán)變量。2023/7/2746單元測試的任務(wù)（續(xù)）一個(gè)好的設(shè)計(jì)應(yīng)能預(yù)見各種出錯(cuò)條件,并預(yù)設(shè)各種錯(cuò)誤處理通路,錯(cuò)誤處理通路同樣需要認(rèn)真測試,測試應(yīng)著重檢查下列問題:①輸出的錯(cuò)誤信息難以理解;②記錄的錯(cuò)誤與實(shí)際遇到的錯(cuò)誤不相符;③在程序自定義的錯(cuò)誤處理段運(yùn)行之前,系統(tǒng)已介入;④異常處理不當(dāng);⑤錯(cuò)誤陳述中未能提供足夠的定位錯(cuò)誤信息。2023/7/27471.2單元測試過程一般認(rèn)為單元測試應(yīng)緊接在編碼之后,當(dāng)源程序編制完成并通過復(fù)審和編譯檢查,便可開始單元測試。為測試模塊開發(fā)一個(gè)驅(qū)動模塊(driver)和(或)若干個(gè)樁模塊(stub)。驅(qū)動模塊和樁模塊是測試使用的軟件,而不是軟件產(chǎn)品的組成部分,但它需要一定的開發(fā)費(fèi)用。僅用簡單的驅(qū)動模塊和樁模塊不能完成某些模塊的測試任務(wù),這些模塊的單元測試只能采用下面討論的綜合測試方法。提高模塊的內(nèi)聚度可簡化單元測試,如果每個(gè)模塊只完成一個(gè)功能,所需測試用例數(shù)目將顯著減少,模塊中的錯(cuò)誤也更容易發(fā)現(xiàn)。2023/7/2748單元測試環(huán)境2023/7/27492綜合測試綜合測試是組裝軟件的系統(tǒng)測試技術(shù),按設(shè)計(jì)要求把通過單元測試的各個(gè)模塊組裝在一起之后,進(jìn)行綜合測試以便發(fā)現(xiàn)與接口有關(guān)的各種錯(cuò)誤。某些軟件設(shè)計(jì)人員習(xí)慣于把所有模塊按設(shè)計(jì)要求一次全部組裝起來,然后進(jìn)行整體測試,這稱為非增量式集成。這種方法容易出現(xiàn)混亂。與之相反的是增量式集成方法,程序一段一段地?cái)U(kuò)展,測試的范圍一步一步地增大,錯(cuò)誤易于定位和糾正,界面的測試亦可做到完全徹底。2023/7/27502.1自頂向下集成自頂向下集成是構(gòu)造程序結(jié)構(gòu)的一種增量式方式,它從主控模塊開始,按照軟件的控制層次結(jié)構(gòu),以深度優(yōu)先或廣度優(yōu)先的策略,逐步把各個(gè)模塊集成在一起。深度優(yōu)先策略首先把主控制路徑上的模塊集成在一起,至于選擇哪一條路徑作為主控制路徑多少帶點(diǎn)隨意性,一般根據(jù)問題的特性確定。2023/7/2751例：2023/7/2752步驟1)以主控模塊作為測試驅(qū)動模塊,把對主控模塊進(jìn)行單元測試時(shí)引入的所有樁模塊用實(shí)際模塊替代;2)依據(jù)所選的集成策略(深度優(yōu)先或廣度優(yōu)先),每次只替代一個(gè)樁模塊;3)每集成一個(gè)模塊立即測試一遍;4)只有每組測試完成后,才著手替換下一個(gè)樁模塊;5)為避免引入新錯(cuò)誤,須不斷進(jìn)行回歸測試(即全部或部分地重復(fù)已做過的測試)。從第二步開始,循環(huán)執(zhí)行上述步驟,直至整個(gè)程序結(jié)構(gòu)構(gòu)造完畢。2023/7/2753優(yōu)缺點(diǎn)自頂向下集成的優(yōu)點(diǎn)在于能盡早地對程序的主要控制和決策機(jī)制進(jìn)行檢驗(yàn),因此較早地發(fā)現(xiàn)錯(cuò)誤。缺點(diǎn)是在測試較高層模塊時(shí),低層處理采用樁模塊替代,不能反映真實(shí)情況,重要數(shù)據(jù)不能及時(shí)回送到上層模塊,因此測試并不充分。2023/7/27542.2自底向上集成自底向上測試是從“原子”模塊(即軟件結(jié)構(gòu)最低層的模塊)開始組裝和測試,因測試到較高層模塊時(shí),所需的下層模塊功能均已具備,所以不再需要樁模塊。自底向上綜合測試的步驟分為:1)把低層模塊組織成實(shí)現(xiàn)某個(gè)子功能的模塊群(cluster);2)開發(fā)一個(gè)測試用驅(qū)動模塊,控制測試數(shù)據(jù)的輸入和測試結(jié)果的輸出;3)對每個(gè)模塊群進(jìn)行測試;4)刪除測試使用的驅(qū)動模塊,用較高層模塊把模塊群組織成為完成更大功能的新模塊群;從第一步開始循環(huán)執(zhí)行上述各步驟,直至整個(gè)程序構(gòu)造完畢。2023/7/2755例：2023/7/2756優(yōu)缺點(diǎn)自底向上集成方法不用樁模塊,測試用例的設(shè)計(jì)亦相對簡單,但缺點(diǎn)是程序最后一個(gè)模塊加入時(shí)才具有整體形象。它與自頂向下綜合測試方法的優(yōu)缺點(diǎn)正好相反。因此,在測試軟件系統(tǒng)時(shí),應(yīng)根據(jù)軟件的特點(diǎn)及工程的進(jìn)度,選用適當(dāng)?shù)臏y試策略,有時(shí)混合使用兩種策略更為有效,上層模塊用自頂向下的方法,下層模塊用自底向上的方法。2023/7/2757關(guān)鍵模塊在綜合測試過程中尤其要注意關(guān)鍵模塊,所謂關(guān)鍵模塊一般都具有下述一或多個(gè)特征:①對應(yīng)幾條需求;②具有高層控制功能;③復(fù)雜易出錯(cuò);④有特殊的性能要求。關(guān)鍵模塊應(yīng)盡早測試,并反復(fù)進(jìn)行回歸測試。2023/7/27582.3綜合測試文檔測試說明書(TestSpecifications)應(yīng)給出軟件集成的總體規(guī)劃和某些特殊測試的描述。綜合測試文檔將作為軟件配置的一部分交給用戶。2023/7/2759測試說明書提綱Ⅰ測試范圍Ⅱ測試計(jì)劃

A測試的各個(gè)階段和劃分模塊群情況

B進(jìn)度安排

C開銷軟件(驅(qū)動和樁模塊)D環(huán)境和資源Ⅲ測試過程n(關(guān)于第n個(gè)模塊群測試過程的描述)A集成順序

1用途

2被測模式

B模塊群中各模塊的單元測試情況

2023/7/2760測試說明書提綱（續(xù)）

1模塊m的測試描述

2開銷軟件描述

3期望結(jié)果

C測試環(huán)境

1特殊工具或技術(shù)

2開銷軟件的描述

D測試用例

E模塊群n的期望結(jié)果Ⅳ實(shí)際測試結(jié)果Ⅴ參考文獻(xiàn)Ⅵ附錄2023/7/27613確認(rèn)測試通過綜合測試之后,軟件已完全組裝起來,接口方面的錯(cuò)誤也已排除,軟件測試的最后一步——確認(rèn)測試即可開始。確認(rèn)測試應(yīng)檢查軟件能否按合同要求進(jìn)行工作,即是否滿足軟件需求說明書中的確認(rèn)標(biāo)準(zhǔn)。2023/7/27623.1確認(rèn)測試標(biāo)準(zhǔn)實(shí)現(xiàn)軟件確認(rèn)要通過一系列黑盒測試。確認(rèn)測試同樣需要制訂測試計(jì)劃和過程,測試計(jì)劃應(yīng)規(guī)定測試的種類和測試進(jìn)度,測試過程則定義一些特殊的測試用例,旨在說明軟件與需求是否一致。無論是計(jì)劃還是過程,都應(yīng)該著重考慮軟件是否滿足合同規(guī)定的所有功能和性能,文檔資料是否完整、準(zhǔn)確,人機(jī)界面和其他方面(例如,可移植性、兼容性、錯(cuò)誤恢復(fù)能力和可維護(hù)性等等)是否令用戶滿意。2023/7/27633.2配置復(fù)審確認(rèn)測試的另一個(gè)重要環(huán)節(jié)是配置復(fù)審。復(fù)審的目的在于保證軟件配置齊全、分類有序,并且包括軟件維護(hù)所必需的細(xì)節(jié)。2023/7/27643.3α、β測試軟件是否真正滿足最終用戶的要求應(yīng)由用戶進(jìn)行一系列“驗(yàn)收測試”。驗(yàn)收測試既可以是非正式的測試,也可以是有計(jì)劃、有系統(tǒng)的測試。有時(shí),驗(yàn)收測試長達(dá)數(shù)周甚至數(shù)月,不斷暴露錯(cuò)誤,導(dǎo)致開發(fā)延期。一個(gè)軟件產(chǎn)品,將有眾多用戶,不可能由每個(gè)用戶驗(yàn)收,此時(shí)多采用稱為α、β測試的過程,以期發(fā)現(xiàn)那些似乎只有最終用戶才能發(fā)現(xiàn)的問題。2023/7/2765α、β測試α測試是指軟件開發(fā)公司組織內(nèi)部人員模擬各類用戶行為對即將面市的軟件產(chǎn)品(稱為α版本)進(jìn)行測試，試圖發(fā)現(xiàn)錯(cuò)誤并修正。α測試的關(guān)鍵在于盡可能逼真地模擬實(shí)際運(yùn)行環(huán)境和用戶對軟件產(chǎn)品的操作，并盡最大努力涵蓋所有可能的用戶操作方式。經(jīng)過α測試調(diào)整的軟件產(chǎn)品稱為β版本。緊隨其后的β測試是指軟件開發(fā)公司組織各方面的典型用戶在日常工作中實(shí)際使用β版本，并要求用戶報(bào)告異常情況、提出批評意見。然后軟件開發(fā)公司再對β版本進(jìn)行改錯(cuò)和完善。2023/7/27664系統(tǒng)測試計(jì)算機(jī)軟件是基于計(jì)算機(jī)系統(tǒng)的一個(gè)重要組成部分,軟件開發(fā)完畢后應(yīng)與系統(tǒng)中其他成份集成在一起,此時(shí)需要進(jìn)行一系列系統(tǒng)集成和確認(rèn)測試。在系統(tǒng)測試之前，軟件工程師應(yīng)完成下列工作:1)為測試軟件系統(tǒng)的輸入信息，設(shè)計(jì)錯(cuò)誤處理通路;2)設(shè)計(jì)測試用例,模擬錯(cuò)誤數(shù)據(jù)和軟件界面可能發(fā)生的錯(cuò)誤,記錄測試結(jié)果,為系統(tǒng)測試提供經(jīng)驗(yàn)和幫助；3)參與系統(tǒng)測試的規(guī)劃和設(shè)計(jì),保證軟件測試的合理性。2023/7/27674.1恢復(fù)測試恢復(fù)測試主要檢查系統(tǒng)的容錯(cuò)能力。當(dāng)系統(tǒng)出錯(cuò)時(shí)，能否在指定的時(shí)間間隔內(nèi)修正錯(cuò)誤并重新啟動系統(tǒng)?；謴?fù)測試首先要采用各種辦法強(qiáng)迫系統(tǒng)失敗，然后驗(yàn)證系統(tǒng)是否能盡快恢復(fù)。對于自動恢復(fù)系統(tǒng)，需驗(yàn)證重新初始化、檢查點(diǎn)、數(shù)據(jù)恢復(fù)和重新啟動等機(jī)制的正確性；對于人工干予的恢復(fù)系統(tǒng)，還需估測平均修復(fù)時(shí)間，確定其是否在可接受的范圍內(nèi)。2023/7/27684.2安全測試安全測試檢查系統(tǒng)對非法侵入的防范能力。安全測試期間，測試人員假扮非法入侵者，采用各種辦法試圖突破防線。例如，(1)想方設(shè)法截取或破譯口令；(2)專門定做軟件破壞系統(tǒng)的保護(hù)機(jī)制；(3)故意導(dǎo)致系統(tǒng)失敗，企圖趁恢復(fù)之機(jī)非法進(jìn)入；(4)試圖通過瀏覽非保密數(shù)據(jù)，推導(dǎo)所需信息等等。理論上講，只要有足夠的時(shí)間和資源，沒有不可進(jìn)入的系統(tǒng)。因此系統(tǒng)安全設(shè)計(jì)的準(zhǔn)則是，使非法侵入的代價(jià)超過被保護(hù)信息的價(jià)值。此時(shí)非法侵入者已無利可圖。2023/7/27694.3強(qiáng)度測試強(qiáng)度測試檢查程序?qū)Ξ惓Ｇ闆r的抵抗能力。強(qiáng)度測試總是迫使系統(tǒng)在異常的資源配置下運(yùn)行。例如：(1)當(dāng)中斷的正常頻率為每秒一至兩個(gè)時(shí)，運(yùn)行每秒產(chǎn)生十個(gè)中斷的測試用例；(2)定量地增長數(shù)據(jù)輸入率，檢查輸入子功能的反映能力；(3)運(yùn)行需要最大存儲空間(或其他資源)的測試用例；(4)運(yùn)行可能導(dǎo)致虛存操作系統(tǒng)崩潰或磁盤數(shù)據(jù)劇烈抖動的測試用例；等等。2023/7/27704.4性能測試對于那些實(shí)時(shí)和嵌入式系統(tǒng)，軟件部分既使?jié)M足功能要求，也未必能夠滿足性能要求。雖然從單元測試起，每一測試步驟都包含性能測試，但只有當(dāng)系統(tǒng)真正集成之后，在真實(shí)環(huán)境中才能全面、可靠地測試運(yùn)行性能，系統(tǒng)性能測試是為了完成這一任務(wù)。性能測試有時(shí)與強(qiáng)度測試相結(jié)合，經(jīng)常需要其他軟、硬件的配套支持。2023/7/27715排錯(cuò)排錯(cuò)與成功的測試形影相隨。測試成功的標(biāo)志是發(fā)現(xiàn)了錯(cuò)誤。根據(jù)錯(cuò)誤跡象確定錯(cuò)誤的原因和準(zhǔn)確位置,并加以改正的任務(wù)主要依靠排錯(cuò)技術(shù)。2023/7/27725.1排錯(cuò)過程排錯(cuò)過程開始于一個(gè)測試用例的執(zhí)行,若測試結(jié)果與期望結(jié)果有出入,即出現(xiàn)了錯(cuò)誤征兆,排錯(cuò)過程首先要找出錯(cuò)誤原因,然后對錯(cuò)誤進(jìn)行修正。因此排錯(cuò)過程有兩種可能,一是找到了錯(cuò)誤原因并糾正了錯(cuò)誤,另一種可能是錯(cuò)誤原因不明,排錯(cuò)人員只得作某種推測,然后再設(shè)計(jì)測試用例證實(shí)這種推測,若一次推測失敗,再作第二次推測,直至發(fā)現(xiàn)并糾