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

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

根據(jù)程序的邏輯結構畫出流程圖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ù)程序的邏輯結構畫出流程圖2023/7/2718Step2

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

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

B進度安排

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

1用途

2被測模式

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

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

1模塊m的測試描述

2開銷軟件描述

3期望結果

C測試環(huán)境

1特殊工具或技術

2開銷軟件的描述

D測試用例

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