《軟件測試》課件

軟件測試第八

章8.1軟件測試的基本概念一、軟件測試的目的和重要性因?yàn)殚_發(fā)工作的前期不可避免地會引入錯誤，測試的目的是為了發(fā)現(xiàn)和改正錯誤，這對于某些涉及人的生命安全或重要的軍事、經(jīng)濟(jì)目標(biāo)的項(xiàng)目顯得尤其重要。軟件測試是軟件開發(fā)過程中保證軟件質(zhì)量、提高軟件可靠性的最主要的手段之一，是在軟件產(chǎn)品交互用戶使用之前，對分析、設(shè)計(jì)、編碼等開發(fā)工作的最后檢查和復(fù)審，及時發(fā)現(xiàn)并校正錯誤。測試的根本目的就是發(fā)現(xiàn)盡可能多的缺陷。測試：測試由測試員完成。調(diào)試：調(diào)試由程序員完成。1963年美國飛往火星的火箭爆炸，原因是FORTRAN程序：DO5I=1，3誤寫為：DO5I=1.3損失1000萬美元。1967年蘇聯(lián)“聯(lián)盟一號”宇宙飛船返回時因忽略一個小數(shù)點(diǎn)，在進(jìn)入大氣層時打不開降落傘而燒毀。測試的目標(biāo)以最小的工作量和成本，盡可能多地發(fā)現(xiàn)軟件系統(tǒng)中潛在的各種錯誤和缺陷，以確保軟件系統(tǒng)的正確性和可靠性。二、軟件測試的特點(diǎn)1、軟件測試的開銷大 按照Boehm的統(tǒng)計(jì)，軟件測試的開銷大約占總成本的30%-50%。例如：APPOLLO登月計(jì)劃，80%的經(jīng)費(fèi)用于軟件測試。2、不能進(jìn)行“窮舉”測試 只有將所有可能的情況都測試到，才有可能檢查出所有的錯誤。但這是不可能的：例：程序P有兩個整型輸入量X、Y，輸出量為Z，在32位機(jī)上運(yùn)行。所有的測試數(shù)據(jù)組（Xi，Yi）的數(shù)目為：2

2=21毫秒執(zhí)行1次，共需5億年。323264PXYZ3、軟件測試難度大 根據(jù)上述分析，既然不能進(jìn)行

“窮舉”測試，又要查出盡可能多的錯誤，軟件測試工作的難度大。只有選擇— “高效的測試用例” 什么是“高效的測試用例”？ 如何選擇“高效的測試用例”？ 這就是本章討論的主要問題！??！三、軟件測試的基本原則1、應(yīng)盡早地和不斷地進(jìn)行軟件測試。2、盡量不由程序設(shè)計(jì)者進(jìn)行測試，采用獨(dú)立測試。開發(fā)者總以為程序正確開發(fā)者對程序功能、接口十分熟悉，使用不會出錯開發(fā)者對程序的珍愛心理3、關(guān)鍵是注重測試用例的選擇。 輸入數(shù)據(jù)的組成（輸入數(shù)據(jù)、預(yù)期的輸出結(jié)果）既有合理輸入數(shù)據(jù)，也有不合理的輸入數(shù)據(jù)。用例既能檢查應(yīng)完成的任務(wù)，也能夠檢查不應(yīng)該完成的任務(wù)。長期保存測試用例。測試用例的質(zhì)量可以由以下四個特性來描述：有效性：能否發(fā)現(xiàn)軟件缺陷或至少可能發(fā)現(xiàn)軟件缺陷；可仿效性：可仿效的測試用例可以測試多項(xiàng)內(nèi)容，從而減少測試用例數(shù)量；經(jīng)濟(jì)性：測試用例的執(zhí)行分析和排錯是否經(jīng)濟(jì)；修改性：每次軟件修改后對測試用例的維護(hù)成本。四個特性之間會有影響，如可仿效性有可能導(dǎo)致經(jīng)濟(jì)性和修改性較低。因此，通常情況下，應(yīng)對上述四個特性進(jìn)行一定的權(quán)衡折衷。4、充分注意測試中的群集現(xiàn)象。群集現(xiàn)象是指，在測試過程中，發(fā)現(xiàn)錯誤比較集中的程序段，往往可能殘留的錯誤數(shù)較多。因此必須注意這種群集現(xiàn)象，對錯誤群集的程序段進(jìn)行重點(diǎn)測試，以提高測試投資的效率。5、避免測試的隨意性，制定詳細(xì)、完善的測試計(jì)劃（包括測試范圍、測試方式、測試成本、測試工作量、測試時間等）、嚴(yán)格執(zhí)行測試計(jì)劃。6、全面檢查每一個測試結(jié)果。7、妥善保管測試過程中的一切文檔，為軟件維護(hù)提供方便。測試計(jì)劃、測試用例、測試結(jié)果、出錯統(tǒng)計(jì)等都是軟件測試的重要文檔。另外，Davis也提出了一組測試原則，在設(shè)計(jì)有效地測試用例時必須理解。⑴所有的測試都應(yīng)根據(jù)用戶的需求來進(jìn)行。⑵應(yīng)該在測試工作真正開始前的較長時間內(nèi)就進(jìn)行測試計(jì)劃（測試規(guī)劃）。一般而言，測試計(jì)劃可以在需求分析完成后開始，詳細(xì)的測試用例定義可以在設(shè)計(jì)模型被確定后立即開始。因此，所有測試可以在任何代碼被編寫前進(jìn)行計(jì)劃和設(shè)計(jì)。⑶Pareto原則應(yīng)用于軟件測試。Pareto原則意味著測試發(fā)現(xiàn)的錯誤80%的很可能集中在20%的程序模塊中。⑷測試應(yīng)從“小規(guī)模”開始，逐步轉(zhuǎn)向“大規(guī)?！?。即從模塊測試開始再進(jìn)行系統(tǒng)測試。⑸窮舉測試是不可能的，因此，在測試中不可能覆蓋路徑的每一個組合，然而，充分覆蓋程序邏輯，確保覆蓋程序設(shè)計(jì)中使用的所有條件是有可能的。⑹為達(dá)到最佳的測試效果，提倡由第三方來進(jìn)行測試。四、軟件測試的過程軟件測試的過程圖測試的基本步驟模塊測試整體測試功能測試預(yù)測試系統(tǒng)測試驗(yàn)收測試安裝測試概要設(shè)計(jì)審查詳細(xì)設(shè)計(jì)審查代碼審查測試(單元測試）（組裝測試）（有效性測試）（確認(rèn)測試）{{軟件測試文檔1、測試計(jì)劃2、測試規(guī)范3、測試用例4、缺陷報告3、軟件測試文檔模塊測試報告至少選擇一個典型模塊進(jìn)行測試。A、綜合測試策略（靜態(tài)分析、白盒法為主，輔以黑盒法）B、測試情況（根據(jù)覆蓋標(biāo)準(zhǔn)列出）C、測試用例（保留）D、查錯記錄（數(shù)量、位置）、分析結(jié)果。組裝測試報告A、組裝次序、測試方法（以黑盒法為主）B、測試情況C、測試用例（保留）D、查錯記錄（數(shù)量、位置）、分析結(jié)果。功能測試與系統(tǒng)測試與上類似。8.2軟件測試方法軟件測試方法分為兩類：靜態(tài)分析、動態(tài)測試一、靜態(tài)分析方法指以人工的、非形式化的方法對程序進(jìn)行分析和測試，并不運(yùn)行程序。桌前檢查（DeskChecking）由程序員檢查自己的程序，對源代碼進(jìn)行分析、檢驗(yàn)。代碼會審（CodeReadingReview）由程序員和測試員組成評審小組，按照“常見的錯誤清單”，進(jìn)行會議討論檢查。步行檢查（Walkthroughs）最常用的靜態(tài)分析方法。與代碼會審類似，也要進(jìn)行代碼評審，但評審過程主要采取人工執(zhí)行程序的方式，故也稱為“走查”。①調(diào)用圖

無論Y為何值，都不能夠調(diào)用子程序。 READYY>0NX:=YX<0YNY調(diào)用子程序ABCDE即執(zhí)行ABC后，是不可能執(zhí)行路徑CDE的。步行檢查時，還常使用以下分析方法：①

調(diào)用圖 從語義的角度考察程序的控制路線。②數(shù)據(jù)流分析圖 檢查分析變量的定義和引用情況。②數(shù)據(jù)流分析圖節(jié)點(diǎn)—表示單個語句。有向邊—表示控制結(jié)構(gòu)。

d—定義

r—引用

u—未引用R：duuuuuS：uruuurY：uuddru R=0.5W=1/SY=A**WY=E*WZ=X+YC=Z*S123456只定義不用未定義引用連續(xù)定義二、動態(tài)測試方法（1）通過選擇適當(dāng)?shù)臏y試用例，執(zhí)行程序。常用的方法：1、白盒法 又稱結(jié)構(gòu)測試、邏輯驅(qū)動測試或基于程序的測試。分析程序的內(nèi)部邏輯結(jié)構(gòu)，注意選擇適當(dāng)?shù)母采w標(biāo)準(zhǔn)，設(shè)計(jì)測試用例，對主要路徑進(jìn)行盡可能多的測試。2、黑盒法又稱功能測試、數(shù)據(jù)驅(qū)動測試或基于規(guī)格說明的測試，是一種從用戶觀點(diǎn)出發(fā)的測試。不考慮程序的內(nèi)部結(jié)構(gòu)與特性，只根據(jù)程序功能或程序的外部特性設(shè)計(jì)測試用例。白盒法

白盒法又稱為邏輯覆蓋法，因?yàn)橐猿绦颍K）內(nèi)部的邏輯結(jié)構(gòu)為基礎(chǔ)來設(shè)計(jì)測試用例，主要用于單元測試。測試的關(guān)鍵也是如何選擇高效的測試用例，其測試用例選擇，是按照不同覆蓋標(biāo)準(zhǔn)確定的。語句覆蓋判定覆蓋條件覆蓋判定條件覆蓋條件組合覆蓋弱強(qiáng)發(fā)現(xiàn)錯誤能力①語句覆蓋：選擇足夠的測試用例，使得程序中每個語句至少都能被執(zhí)行一次。②判定覆蓋：執(zhí)行足夠的測試用例，使得程序中每個判定至少都獲得一次“真”值和“假”值。（每個分支）③條件覆蓋：執(zhí)行足夠的測試用例，使得判定中的每個條件獲得各種可能的結(jié)果。（至少滿足一次）④判定/條件覆蓋：執(zhí)行足夠的測試用例，使得判定中每個條件取到各種可能的值，并使每個判定取到各種可能的結(jié)果。⑤條件組合覆蓋：執(zhí)行足夠的例子，使得每個判定中條件的各種可能組合都至少出現(xiàn)一次。白盒法常用的覆蓋標(biāo)準(zhǔn)白盒法步驟：例：用白盒法測試以下程序段：Procedure（VARA，B，X：REAL）；BEGINIF（A>1)AND(B=0)THENX:=X/A;IF(A=2)OR(X>1)THENX:=X+1END;1）選擇邏輯覆蓋標(biāo)準(zhǔn)。2）按照覆蓋標(biāo)準(zhǔn)列出所有情況。3）選擇確定測試用例。4）驗(yàn)證分析運(yùn)行結(jié)果與預(yù)期結(jié)果。邏輯結(jié)構(gòu)A>1ANDB=0X:=X/AA=2ORX>1X:=X+1YNYN1、語句覆蓋使得程序中每個執(zhí)行語句至少都能被執(zhí)行一次。A>1ANDB=0X:=X/AA=2ORX>1X:=X+1abcde滿足語句覆蓋的情況：執(zhí)行路徑：ace選擇用例：[(2,0,4),(2,0,3)]用例格式：[輸入(A,B,X)，輸出(A,B,X)]YNYN2、判定覆蓋使得程序中每個判定至少為TRUE或FALSE各一次。A>1ANDB=0X:=X/AA=2ORX>1X:=X+1abcde覆蓋情況：應(yīng)執(zhí)行路徑ace∧abd 或：acd∧abe選擇用例(其一）：⑴[(2,0,4),(2,0,3)]ace[(1,1,1),(1,1,1)]abd⑵[(2,1,1),(2,1,2)]abe[(3,0,3),(3,1,1)]acdYYNN3、條件覆蓋A>1ANDB=0X:=X/AA=2ORX>1X:=X+1abcde使得判定中的每個條件獲得各種可能的結(jié)果。應(yīng)滿足以下覆蓋情況：判定一:A>1,A≤1,B=0,B≠0判定二:A=2,A≠2,X>1,X≤1選擇用例：[(2,0,4),(2,0,3)][(1,1,1),(1,1,1)]NNYY2A≤1A≠20B=04X>11A>1A=21B≠01X≤1注意:[(1,0,3),(1,0,4)] [(2,1,1),(2,1,2)]滿足條件覆蓋，但不滿足判定覆蓋。4、判定/條件覆蓋 同時滿足判斷覆蓋和條件覆蓋。A>1ANDB=0X:=X/AA=2ORX>1X:=X+1abcde應(yīng)滿足以下覆蓋情況：條件:A>1,A≤1,B=0,B≠0 A=2,A≠2,X>1,X≤1應(yīng)執(zhí)行路徑ace∧abd 或：acd∧abe選擇用例：[(2,0,4),(2,0,3)]（ace)[(1,1,1),(1,1,1)](abd)YYNN5、條件組合覆蓋使得每個判定中條件的各種可能組合都至少出現(xiàn)一次。A>1X:=X/AA=2X:=X+1abcdeB=0X>1YNYNYNYN編譯系統(tǒng)下的執(zhí)行情況：部分路徑未被執(zhí)行。滿足以下覆蓋情況：①A>1,B=0②A>1,B≠0③A≤1,B=0

④A≤1,B≠0⑤A=2,X>1

⑥A=2,X≤1

⑦A≠2,X>1

⑧A≠2,X≤1選擇用例：[(2,0,4),(2,0,3)]①⑤[(2,1,1),(2,1,2)]②⑥[(1,0,3),(1,0,4)]③⑦[(1,1,1),(1,1,1)]④⑧二、動態(tài)測試方法（2）等價分類法邊值分析法錯誤推測法因果圖法(2)黑盒法

不考慮程序的內(nèi)部結(jié)構(gòu)與特性，只根據(jù)程序功能或程序的外部特性設(shè)計(jì)測試用例。黑盒測試法注重于測試軟件的功能需求，主要試圖發(fā)現(xiàn)下列幾類錯誤：功能不對或遺漏；性能錯誤；初始化和終止錯誤；界面錯誤；數(shù)據(jù)結(jié)構(gòu)或外部數(shù)據(jù)庫訪問錯誤。1.等價分類法基本思想：根據(jù)程序的I/O特性，將程序的定義域劃分為有限個等價區(qū)段—“等價類”，從等價類中選擇出的用例，具有“代表性”。等價類分為：有效等價類—對于程序的規(guī)格說明，是合理的、有意義的輸入數(shù)據(jù)構(gòu)成的集合。無效等價類—對于程序的規(guī)格說明，是不合理的、沒有意義的輸入數(shù)據(jù)構(gòu)成的集合。等價分類法步驟

應(yīng)按照輸入條件（如輸入值的范圍，值的個數(shù)，值的集合，輸入條件必須如何）劃分為有效等價類和無效等價類。例如：每個學(xué)生可選修1-3門課程可以劃分一個有效等價類：選修1-3門課程?？梢詣澐謨蓚€無效等價類：未選修課，選修課超過3門。①劃分“等價類”

顯然，關(guān)鍵是如何劃分等價類A為每個等價類編號；B使一個測試用例盡可能覆蓋多個有效等價類C特別要注意：一個測試用例只能覆蓋一個無效等價類。②選擇測試用例等價分類法步驟2.邊值分析法

基本思想：選擇等價類的邊緣值作為測試用例，讓每個等價類的邊界都得到測試，選擇測試用例既考慮輸入亦考慮輸出。

分析步驟：

A先劃分等價類。

B選擇測試用例，測試等價類邊界。邊界選擇原則：

A按照輸入值范圍的邊界。

B按照輸入/輸出值個數(shù)的邊界。

C輸出值域的邊界。

D輸入/輸出有序集的邊界。

A按照輸入值范圍的邊界。例如：輸入值的范圍是-1.0至1.0，則可選擇用例:–1.0、1.0、-1.001、1.001。

B按照輸入/輸出值個數(shù)的邊界。

例如：輸入文件可有1-255個記錄，則設(shè)計(jì)用例：文件的記錄數(shù)為0個、1個、255個、256個。

C輸出值域的邊界。

例如：檢索文獻(xiàn)摘要，最多4篇。設(shè)計(jì)用例：可檢索0篇、1篇、4篇，和5篇（錯誤）。

D輸入/輸出有序集（如順序文件、線性表）的邊界。

應(yīng)選擇第一個元素和最后一個元素。邊值分析法舉例黑盒法應(yīng)用實(shí)例

對FORTRAN編譯系統(tǒng)中的DIMENSION語句進(jìn)行測試。語句格式為：DIMENSIONad[,ad]…ad為數(shù)組描述符，形式為n（d[,]…其中：n－數(shù)組名，字母打頭的字母數(shù)字串，長6。D為界偶（1-7個）：[ld:]ndld和nd的值為1-65535，ld缺省為1。輸入條件合理的等價類不合理的等價類數(shù)組描述的個數(shù)1個（1）、多于1個（2）沒有數(shù)組描述（3）數(shù)組名的字符數(shù)1—6個（4）0（5），>6（6）數(shù)組名有字母（7）有數(shù)字（8）有其他字符（9）數(shù)組名的第1個字符為字母是（10）不是（11）維數(shù)1—7（12）0（13），>7（14）上界常數(shù)（15）數(shù)組元素名（1640個等價類3.錯誤推測法 憑經(jīng)驗(yàn)或直覺推測可能的錯誤，列出程序中可能有的錯誤和容易發(fā)生錯誤的特殊情況，選擇測試用例。 把輸入條件視為“因”，把輸出條件視為“果”，將黑盒看成是從因到果的網(wǎng)絡(luò)圖，采用邏輯圖的形式來表達(dá)功能說明書中輸入條件的各種組合與輸出的關(guān)系。根據(jù)這種關(guān)系可選擇高效的測試用例。因果圖是一種形式化語言，是一種組合邏輯網(wǎng)絡(luò)圖。因果圖法的基本原理是通過因果圖，把自然語言描述的功能說明轉(zhuǎn)換為判定表，然后為判定表的每一列設(shè)計(jì)一個測試用例。4.因果圖法（causeeffectgraphics）⑴因果圖的基本符號 0-表示“不出現(xiàn)” 1-表示“出現(xiàn)” 恒等 若a為1，則b為1，否則b為0。 “非”函數(shù)

若a為1，則b為0，否則b為1。 “或”函數(shù)若a或b為1，則d為1，否則d為0。 “與”函數(shù)若a與b同為1，則d為1，否則d為0。abababd∨abd∧對“與”、“或”函數(shù)的限制符號

E約束（異）—排斥 即a、b不能同時為1。

I約束（或）—包容

a、b、c不能同時為0。

O約束（唯一）—選一

a、b中僅有一個為1。

R約束（要求）—需要

a為1時，b必須為1

M約束（強(qiáng)制）—屏蔽若a為1時，則b強(qiáng)制為1。abEabcIabRabOabM⑵因果圖法的步驟

分析規(guī)范，即將問題分為若干可工作的步驟。標(biāo)識出規(guī)范中的原因與結(jié)果。 原因—輸入條件 結(jié)果—輸出或系統(tǒng)變換將因果圖轉(zhuǎn)換為有限項(xiàng)判斷表。將判斷表的每一列，轉(zhuǎn)換為一個測試用例。

分析規(guī)范語義、內(nèi)容，轉(zhuǎn)換為因果圖。

⑶因果圖法應(yīng)用舉例規(guī)范：文件名第一列字符必須為A或B，第二列字符必須為數(shù)字。滿足則修改文件。第一字符不正確發(fā)出信息X12，第二個字符不正確發(fā)出信息X13。1.分析規(guī)范

原因 結(jié)果1—第一列字符為A 50—修改文件2—第一列字符為B 51—發(fā)信息X123—第二列字符為數(shù)字52—發(fā)信息X132.畫出因果圖中間結(jié)點(diǎn) 是導(dǎo)出結(jié)果的進(jìn)一步原因。

考慮到原因1、2不可能同時為1，加上E約束。

1111∨5150352∧12E發(fā)X12發(fā)X13

修改文件3.將因果圖轉(zhuǎn)換為判斷表

12345678條件原因①11110000②11001100③10101010111100動作結(jié)果000011101000010101測試用例A3A8AMA？B5B4BNB！C2X6DYPI11515052白盒測試與黑盒測試兩類方法的對比條件組合覆蓋等價分類法邊界值分析法錯誤推測法因果圖法8.3軟件測試的步驟測試步驟及策略

所有測試過程都應(yīng)采用綜合測試策略；即先作靜態(tài)分析，再作動態(tài)測試。并事先制訂測試計(jì)劃。測試過程通常可分4步進(jìn)行：單元測試單元測試單元測試被測模塊被測模塊集成測試設(shè)計(jì)信息已測試的模塊確認(rèn)測試已集成的模塊軟件需求系統(tǒng)測試已確認(rèn)的軟件可交付的軟件系統(tǒng)其他元素一、模塊測試（ModuleTesting）1.測試內(nèi)容模塊模塊接口測試局部數(shù)據(jù)結(jié)構(gòu)測試重要路徑測試錯誤處理測試邊界條件測試I/O參數(shù)值的個數(shù)、類型、次序、格式是否正確，I/O文件屬性、操作是否正確等。數(shù)據(jù)說明是否正確、一致，變量及其初值定義是否正確等。檢查“錯誤處理程序”本身的錯誤。邊界條件常包括循環(huán)邊界，最大最小值、控制流中等于、大于、小于的比較值等。重要路徑通常是指完成模塊功能的主要路徑，一般是控制結(jié)構(gòu)。也稱單元測試（unittesting)以白盒法為主2.模塊測試步驟

考慮到被測模塊與其它模塊的聯(lián)系，因此測試時需要使用兩類輔助模塊來模擬其他模塊。

驅(qū)動模塊（driver）—模擬主程序功能，用于向被測模塊傳遞數(shù)據(jù)，接收、打印從被測模塊返回的數(shù)據(jù)。

樁模塊（stub）—又稱為假模塊，用于模擬那些由被測模塊所調(diào)用的下屬模塊功能。

一般，驅(qū)動模塊比樁模塊容易設(shè)計(jì)。但都是額外開銷。測試方法以白盒法為主。被測模塊驅(qū)動模塊樁模塊樁模塊樁模塊二、組裝測試（IntegrationTesting）1.組裝測試的任務(wù)①確定模塊組裝方案，將經(jīng)過測試的模塊組裝為一個完整的系統(tǒng)。組裝方案分為漸增式及非漸增式。②測試方法以黑盒法為主，按照組裝方案進(jìn)行測試。 也稱為聯(lián)合測試或集成測試，重點(diǎn)測試模塊的接口部分，需設(shè)計(jì)測試過程使用的驅(qū)動模塊或樁模塊。問題：漸增式與非漸增式各有何優(yōu)、缺點(diǎn)？為什么通常采用漸增式？2.漸增式組裝測試 漸增式是先進(jìn)行模塊測試，然后將這些模塊逐步組裝成較大的系統(tǒng)，每連接一個模塊進(jìn)行一次測試。兩種方案：設(shè)計(jì)驅(qū)動模塊或樁模塊，對每一個新組裝的子系統(tǒng)進(jìn)行測試，對發(fā)現(xiàn)問題較多的子系統(tǒng)或模塊應(yīng)該用白盒法作回歸測試。自頂而下增值自底而上增值自頂而下增值M1M4M3M2M6M5程序模塊示意圖S5M1S1S1S1S2S2S2S3S3S3第一步，測試主控模塊M1設(shè)計(jì)樁模塊S1、S2、S3，模擬被M1調(diào)用的M2、M3、M4。M2M3M4第二步，依次用M2、M3、M4替代樁模塊S1、S2、S3，每替代一次進(jìn)行一次測試。S4S4S4S5S5第三步，對由主控模塊M1和模塊M2、M3、M4構(gòu)成的子系統(tǒng)進(jìn)行測試，設(shè)計(jì)樁模塊S4、S5。M5M6第四步，依次用模塊M5和M6替代樁模塊S4、S5，并同時進(jìn)行新的測試。組裝測試完畢。自底而上增值M3M6M5D1D2D3D1D1D2D2D3D3M2M4M1第四步，把已測試的子系統(tǒng)按程序結(jié)構(gòu)連接起來完成程序整體的組裝測試。D4D4D4D5D5D5M1M4M3M2M6M5程序模塊示意圖第一步，對最底層的模塊M3、M5、M6進(jìn)行測試,設(shè)計(jì)驅(qū)動模塊D1、D2、D3來模擬調(diào)用。第三步，設(shè)計(jì)驅(qū)動模塊D4、D5和D6模擬調(diào)用，分別對新子系統(tǒng)進(jìn)行測試。第二步，用實(shí)際模塊M2、M1和M4替換驅(qū)動模塊D1、D2、D3。D6深度優(yōu)先與寬度優(yōu)先

無論是自頂而下增值還是自底而上增值，還可選擇深度優(yōu)先或者寬度優(yōu)先增值。

舉例：按自頂而下增值法，寫出下圖中分別按照深度優(yōu)先或者寬度優(yōu)先增值的模塊組裝次序。ABCDHGJEFIKLMN確定集成過程的原則自頂而下增值優(yōu)點(diǎn)：能夠盡早發(fā)現(xiàn)系統(tǒng)主控方面的問題。缺點(diǎn)：無法驗(yàn)證樁模塊是否完全模擬了下屬模塊的功能。自底而上增值優(yōu)點(diǎn)：驅(qū)動模塊較容易編寫，能夠盡早查出底層涉及較復(fù)雜的算法和實(shí)際的I/O模塊中的錯誤。缺點(diǎn)：最后才能發(fā)現(xiàn)系統(tǒng)主控方面的問題。集成過程的原則①盡早測試關(guān)鍵模塊。②盡早測試包含I/O的模塊。3.混合增值常見的混合增值方案：衍變的自頂而下先自底而上集成子系統(tǒng)，再自頂而下集成總系統(tǒng)。自底而上—自頂而下增值對含有讀操作的子系統(tǒng)采用自底而上。對含有寫操作的子系統(tǒng)采用自頂而下。回歸測試在回歸測試中自底而上，對其余部分（引起是對修改過的子系統(tǒng)）采用自頂而下。問題（1）自頂而下增值與自底而上增值各有何優(yōu)、缺點(diǎn)？（2）為什么在實(shí)際的組裝測試中，都應(yīng)該采用混合增值的方法？（3）請自己設(shè)計(jì)2-3個混合增值的測試方法。三、確認(rèn)測試(validationtesting)

1.任務(wù)

又稱為有效性測試或功能測試。其任務(wù)是在開發(fā)環(huán)境下驗(yàn)證系統(tǒng)的功能、性能等特性是否符合需求規(guī)格說明。以黑盒法為主。選擇測試人員選擇測試用例實(shí)際運(yùn)行測試軟件計(jì)劃用戶文檔開發(fā)文檔源程序文本支持環(huán)境有效性測試軟件配置審查管理機(jī)構(gòu)裁決專家鑒定會交用戶運(yùn)行維護(hù)測試報告軟件配置2.確認(rèn)測試步驟（1）有效性測試 制定測試計(jì)劃，運(yùn)用黑盒法，驗(yàn)證軟件特性是否與需求符合。（2）軟件配置復(fù)查 軟件配置—指軟件工程過程中所產(chǎn)生的所有信息項(xiàng)：文檔、報告、程序、表格、數(shù)據(jù)。隨著軟件工程過程的進(jìn)展軟件配置項(xiàng)（SCIsoftwareConfigurationItem）快速增加和變化。應(yīng)復(fù)查SCI是否齊全。 （3）測試和

測試 測試是在開發(fā)機(jī)構(gòu)的監(jiān)督下，由個別用戶在確認(rèn)測試階段后期對軟件進(jìn)行測試，目的是評價軟件的FLURPS（功能、局域化、可使用性、可靠性、性能和支持），注重界面和特色。

測試由支持軟件預(yù)發(fā)行的客戶對FLURPS進(jìn)行測試，主要目的是測試系統(tǒng)的可支持性。FunctionTesting功能測試

LocalAreaTesting局域化測試

UsabilityTesting可使用性測試

RegressionTesting回歸測試

PerformanceTesting性能測試

SupportabilityTesting可支持性測試四、系統(tǒng)測試（systemtesting）將經(jīng)過確認(rèn)測試的軟件，與計(jì)算機(jī)硬件、外設(shè)、支持軟件等一起，在實(shí)際運(yùn)行環(huán)境下測試。五、驗(yàn)收測試（acceptancetesting）驗(yàn)收測試是以用戶為主的測試。步驟：（1）由課題組根據(jù)測試用例，自己演示系統(tǒng)所有功能。（2）由用戶進(jìn)行測試。8.3.6綜合測試策略

軟件測試是保證軟件可靠性的主要手段，也是軟件開發(fā)過程中最艱巨、最繁雜的任務(wù)。軟件測試方案是測試階段的關(guān)鍵技術(shù)問題，基本目標(biāo)是選擇最少量的高效測試用例，從而盡可能多地發(fā)現(xiàn)軟件中的問題。因此，無論哪一個測試階段，都應(yīng)該采用綜合測試策略，才能夠?qū)崿F(xiàn)測試的目標(biāo)。

一般都應(yīng)該先進(jìn)行靜態(tài)測試，再考慮動態(tài)測試。最后進(jìn)行驗(yàn)收測試（AcceptanceTesting），是以用戶為主的測試，測試過程、方法和測試內(nèi)容與系統(tǒng)測試基本相同。有時也將驗(yàn)收測試與系統(tǒng)測試合二為一，此時，參加測試的人員最好包括：有經(jīng)驗(yàn)的系統(tǒng)測試專家，用戶代表，軟件開發(fā)人員及QA（質(zhì)量保證）人員也應(yīng)參加。8.4面向?qū)ο蟮臏y試

而面向?qū)ο蟮臏y試貫穿軟件開發(fā)的全過程，是與開發(fā)過程密切相關(guān)，而又分離出來的過程。

面向?qū)ο蟮臏y試，既要使用許多傳統(tǒng)的成熟的軟件測試方法和技術(shù)，也有其不同的特點(diǎn)；主要反映在測試對象和內(nèi)容的不同。

傳統(tǒng)的觀點(diǎn)認(rèn)為測試要在編碼之后才進(jìn)行，主要測試的對象是程序代碼。面向?qū)ο蟮臏y試更關(guān)注對象，而不是完成單一的輸入/輸出功能，因此測試可以在分析和設(shè)計(jì)階段介入，可以更好地配合軟件生產(chǎn)過程。8.4.1面向?qū)ο鬁y試的特點(diǎn)1.強(qiáng)調(diào)需求或設(shè)計(jì)的測試，通常以兩種方式進(jìn)行：

在沒有代碼的情況下進(jìn)行測試；在有代碼的情況下進(jìn)行測試。2.在傳統(tǒng)測試方法的基礎(chǔ)上，根據(jù)面向?qū)ο蟮闹饕匦?，需要改變測試策略和方法。例如：封裝—對數(shù)據(jù)的隱蔽，減少了對數(shù)據(jù)非法操作，可簡化該類測試。繼承—提高了代碼復(fù)用性，但錯誤也會以同樣方式被復(fù)用。多態(tài)性—提供強(qiáng)大的處理能力，但也增加測試的復(fù)雜性。8.4.2面向?qū)ο鬁y試類型模型測試類測試交互測試系統(tǒng)（子系統(tǒng)）測試驗(yàn)收和發(fā)布測試采用正式技術(shù)評審的方法，檢查分析與設(shè)計(jì)模型的正確性、完整性和一制性。模型測試方法包括：

用例場景測試；

系統(tǒng)原型走查；

需求模型一致性檢查；

分析模型的檢查和走查。8.4.2面向?qū)ο鬁y試類型模型測試類測試交互測試系統(tǒng)（子系統(tǒng)）測試驗(yàn)收和發(fā)布測試

類測試即傳統(tǒng)測試中的單元測試，即驗(yàn)證類的實(shí)現(xiàn)與類的規(guī)約是否一致的活動。完整的類測試包括：

類屬性的測試

類操作的測試

可能狀態(tài)下的對象測試注意：不能“孤立”進(jìn)行測試，操作測試應(yīng)該包括其可能被調(diào)用的各種情況。8.4.2面向?qū)ο鬁y試類型模型測試類測試交互測試系統(tǒng)（子系統(tǒng)）測試驗(yàn)收和發(fā)布測試交互測試用于代替?zhèn)鹘y(tǒng)測試方法中的集成測試。將類進(jìn)行聯(lián)合測試，以確定它們能否在一起共同工作。交互測試的方法有：

用例或基于場景的測試

線程測試

對象的測試。8.4.2面向?qū)ο鬁y試類型模型測試類測試交互測試系統(tǒng)（子系統(tǒng)）測試驗(yàn)收和發(fā)布測試

測試系統(tǒng)或獨(dú)立子系統(tǒng)，確保系統(tǒng)無明顯故障，并滿足用戶需求。系統(tǒng)測試包括：

功能測試

壓力測試

安全測試

兼容性測試

安裝測試

恢復(fù)測試8.4.2面向?qū)ο鬁y試類型模型測試類測試交互測試系統(tǒng)（子系統(tǒng)）測試驗(yàn)收和發(fā)布測試

驗(yàn)收測試：交付用戶前的系統(tǒng)測試。

發(fā)布測試：為了確保系統(tǒng)安裝軟件包能夠正常交付使用。8.4.3分析模型測試2、需求測試可以較早地發(fā)現(xiàn)需求中問題

如：不合理的項(xiàng)目，以及錯誤地理解了用戶需求的項(xiàng)目，避免對于成本和資源的消耗。1、需求的質(zhì)量影響并決定了設(shè)計(jì)的質(zhì)量在軟件開發(fā)過程模型中，需求、設(shè)計(jì)和編碼總是有一定的時序特性。而且，需求模型、設(shè)計(jì)模型和實(shí)現(xiàn)代碼之間還具備解釋特性。一、分析模型測試的重要性3、減少需求的模糊性

用戶需求是用戶對待實(shí)現(xiàn)的系統(tǒng)的要求，通常以一種非正規(guī)的形式給出，具有一定的模糊性。這種模糊性帶入了設(shè)計(jì)，甚至代碼中，將可能引發(fā)幾倍，甚至幾十倍的錯誤，這必將極大消耗系統(tǒng)的資源和成本。

測試實(shí)際上也是一個項(xiàng)目。測試也有需求、設(shè)計(jì)和實(shí)現(xiàn)，并且測試本身也會有測試(測試中的測試)。測試作為項(xiàng)目開發(fā)活動中的一部分，在時間上應(yīng)該有明確的要求，測試計(jì)劃對于測試來說也是至關(guān)重要的。

UML分析模型的每個模式，從嚴(yán)格意義上說都應(yīng)該經(jīng)過測試。實(shí)際上，通常對用例模型、類對象模型以及用例中典型場景進(jìn)行測試。二、測試過程通常測試步驟如下：測試用例模型測試某些用例中的典型場景類及對象模型某些類測試其狀態(tài)模型

單個用例測試采取典型應(yīng)用場景的測試方法，用例模型的測試相當(dāng)于系統(tǒng)測試，測試的主要目標(biāo)是用例模型對于用戶需求的可跟蹤性。以系統(tǒng)的用戶為主要的出發(fā)點(diǎn)設(shè)計(jì)測試用例，通過模擬某個系統(tǒng)用戶的行為來測試整個系統(tǒng)，對于該用戶的服務(wù)提供情況，從而檢查系統(tǒng)功能的完整性，用戶需求可跟蹤性等情況。用例模型的測試從系統(tǒng)用戶的角度測試系統(tǒng)的服務(wù)，并不關(guān)心每個測試用例所實(shí)現(xiàn)的功能如何，所以應(yīng)該是黑盒測試。三、用例模型的測試下面以一個訂貨中心系統(tǒng)的用例模型為例說明測試用例的設(shè)計(jì)。有一個訂貨中心，接受客戶的電話、傳真、電子郵件、信件和Web主頁表單等形式的訂貨請求，建立訂單。根據(jù)客戶要求的發(fā)貨目的地，訂貨中心將以最經(jīng)濟(jì)的方式確定一家倉庫來負(fù)責(zé)向客戶發(fā)貨。當(dāng)倉庫收到訂單后，按照一定的策略進(jìn)行發(fā)貨，在填寫發(fā)貨的有關(guān)信息后，將訂單返回訂貨中心。案例訂貨中心系統(tǒng)

識別五個主要的系統(tǒng)角色(用戶)：

管理者(Manager)、發(fā)貨人員(Shipper)

收款人員(Tollcollector)、商務(wù)客戶(Customer)

信用卡(Creditcard)

從各個角色出發(fā)，通過下邊的問題識別用例：

角色要求系統(tǒng)提供的功能有哪些？系統(tǒng)在提供這些功能的時候該角色需要做什么？角色需要創(chuàng)建、閱讀、銷毀或存儲系統(tǒng)的哪些信息？系統(tǒng)中的哪些事件需要通知該角色？以管理者為例：(1)管理者要求系統(tǒng)為他提供什么功能？管理者需要做哪些工作？

答：管理者要求系統(tǒng)提供：

a.接受顧客訂貨請求并創(chuàng)建訂單；

b.計(jì)算訂單的價錢；

c.根據(jù)訂單信息選擇倉庫，并將訂單發(fā)送給倉庫；

d.查詢訂單貨物發(fā)送情況；

e.查詢客戶訂單付款情況；

f.評價商務(wù)結(jié)果；

g.顧客退貨處理；

h.把倉庫返回的訂單發(fā)送到收費(fèi)處；

i.商品價格更新。

管理者需要做：生成訂單；查詢訂單時輸入訂單號。(2)管理者需要閱讀創(chuàng)建、銷毀、更新或者存儲系統(tǒng)哪些信息？

答：信息包括：訂單、職員(倉庫人員、收費(fèi)人員等)信息、顧客信息、物品條目及價格信息、倉庫信息和稅務(wù)信息。(3)系統(tǒng)中的事件一定要告訴管理者嗎？

答：是。這些事件包括：倉庫有關(guān)物品短缺以致無法滿足某訂單；訂單數(shù)據(jù)出現(xiàn)錯誤；顧客超過期限未付款。

可見，管理者要使用系統(tǒng)的十個功能，因此至少可以設(shè)計(jì)出十個測試用例。

以第三條功能“根據(jù)訂單信息選擇倉庫，并將訂單發(fā)送給該倉庫”為例，說明用例的選擇。假設(shè)訂貨中心共有三個倉庫，管理者要決定應(yīng)該選擇哪個倉庫處理訂單。倉庫名稱倉庫位置存貨品名及數(shù)量訂單處理客戶信譽(yù)度A東城G1(200)，G5(100)，G6(1000)，G10(70)，G11(90)85B西城G1(1000)，G2(100)，G5(550)，G8(150)，G10(980)95C北城G1(220)，G4(300)，G5(350)，G7(400)，G10(700)80訂單主要信息：訂單號、送貨地點(diǎn)、貨物名稱及數(shù)量等。管理者考慮將訂單分配到某倉庫的因素：

(1)首先倉庫必須能夠滿足訂單上的貨物要求；

(2)選擇地理位置與發(fā)貨點(diǎn)較近的倉庫發(fā)貨；

(3)信譽(yù)滿意度越高的客戶就越應(yīng)該以較高的服務(wù)質(zhì)量來回報。結(jié)合考慮上面三個因素，以最少的成本取得最好的收益，三個訂單信息如下：訂單號送貨地點(diǎn)貨物名稱及數(shù)量客戶信譽(yù)訂單1北城某集團(tuán)公司G1(200)，G5(100)，G10(40)95訂單2東城某街道

G5(10)，G6(5)80訂單3北城某街道

G4(10)85倉庫名稱倉庫位置存貨品名及數(shù)量訂單處理客戶信譽(yù)度A東城G1(200)，G5(100)，G6(1000)，G10(70)，G11(90)85B西城G1(1000)，G2(100)，G5(550)，G8(150)，G10(980)95C北城G1(220)，G4(300)，G5(350)，G7(400)，G10(700)80訂單號送貨地點(diǎn)貨物名稱及數(shù)量客戶信譽(yù)訂單1北城某集團(tuán)公司G1(200)，G5(100)，G10(40)95訂單2東城某街道

G5(10)，G6(5)80訂單3北城某街道

G4(10)85測試用例1：輸入：訂單1

預(yù)期結(jié)果：選擇倉庫B來處理訂單(三個均可，大宗訂單，客戶信譽(yù)度高)；測試用例2：輸入：訂單2

預(yù)期結(jié)果：選擇倉庫A來處理訂單(個人訂單，客戶信譽(yù)一般)；測試用例3：輸入：訂單3

預(yù)期結(jié)果：選擇倉庫C來處理訂單。

以上測試未涉及某個具體用例，體現(xiàn)了用例模型測試和用例測試的區(qū)別。8.4.4類的測試類測試即傳統(tǒng)測試中的單元測試，即驗(yàn)證類的實(shí)現(xiàn)與類的規(guī)約是否一致的活動。

類測試包括：類屬性的測試、類操作的測試等。

例2Date類是一個描述日期的類，其屬性為三個成員變量：年、月、日，在Date類中，操作decrease（）是使Date類的對象改變?yōu)楫?dāng)前日期的前一天。printDate（）是打印日期信息。而Date類的三個成員變量所屬的類是calendarUnit類的子類。在calendarUnit類中，也有操作decrease（），并通過繼承關(guān)系在Day、Month、Yers三個類中重寫。設(shè)計(jì)測試用例，對Date類的操作decrease（）進(jìn)行測試。8.4.4類的測試datedd:Daymm:Monthyy:YersDate(pDay:integer,pMonth:integer,pYers:integer)decrease(argname)printDate()calendarUnitcurrentVal:IntegerCalenderUnit(pVal:Integer)SetValue(pVal:Integer)decrease()DayMonthYers注意：操作測試應(yīng)該考慮其可能被調(diào)用的各種情況。圖8.16calendarUnit類的繼承關(guān)系calendarUnitcurrentVal:IntegerCalenderUnit(pVal:Integer)SetValue(pVal:Integer)decrease():BooleanDaymm:MonthDay（pDay:integer,pMonth:Month）setDay（pDay:integer,pMonth:Month）getDay():integerdecrease():BooleanYersYear(pYear:Integer)getYear():Intgerdecrease():BooleanisLeap():BooleanMonthyy:Yearsizeindex:integer[]={31,28,31,30,31,30,3131,30,31,30,31}Month(pMonth::integer,pYear:Year)get(Month():integergetMonthSize():Integerdecrease():Boolean例如：對date類中的decrease方法進(jìn)行測試,在設(shè)計(jì)測試用例時，采用等價分類法。劃分等價類時要考慮邊界及閏年等情況。有效等價類:D1=|一個月的第一天與最后一天之間|D2=|一個月的第一天|D3=|1月1日|M1=|前一個月是30天|M2=|前一個月是31天|M3=|前一個月是2月|Y1=|非閏年|Y2=|閏年|Y3=|2005年|無效等價類:D4=|<本月的第一天|D4=|>本月的最后一天|M4=|<1|M5=|>12|Y=|<0|用例ID月日年預(yù)期結(jié)果171919981998年7月18日