《軟件測試》課件

軟件測試第八

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

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

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

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

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

d—定義

r—引用

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

白盒法又稱為邏輯覆蓋法，因為要以程序（模塊）內部的邏輯結構為基礎來設計測試用例，主要用于單元測試。測試的關鍵也是如何選擇高效的測試用例，其測試用例選擇，是按照不同覆蓋標準確定的。語句覆蓋判定覆蓋條件覆蓋判定條件覆蓋條件組合覆蓋弱強發(fā)現錯誤能力①語句覆蓋：選擇足夠的測試用例，使得程序中每個語句至少都能被執(zhí)行一次。②判定覆蓋：執(zhí)行足夠的測試用例，使得程序中每個判定至少都獲得一次“真”值和“假”值。（每個分支）③條件覆蓋：執(zhí)行足夠的測試用例，使得判定中的每個條件獲得各種可能的結果。（至少滿足一次）④判定/條件覆蓋：執(zhí)行足夠的測試用例，使得判定中每個條件取到各種可能的值，并使每個判定取到各種可能的結果。⑤條件組合覆蓋：執(zhí)行足夠的例子，使得每個判定中條件的各種可能組合都至少出現一次。白盒法常用的覆蓋標準白盒法步驟：例：用白盒法測試以下程序段：Procedure（VARA，B，X：REAL）；BEGINIF（A>1)AND(B=0)THENX:=X/A;IF(A=2)OR(X>1)THENX:=X+1END;1）選擇邏輯覆蓋標準。2）按照覆蓋標準列出所有情況。3）選擇確定測試用例。4）驗證分析運行結果與預期結果。邏輯結構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覆蓋情況：應執(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使得判定中的每個條件獲得各種可能的結果。應滿足以下覆蓋情況：判定一: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應滿足以下覆蓋情況：條件:A>1,A≤1,B=0,B≠0 A=2,A≠2,X>1,X≤1應執(zhí)行路徑ace∧abd 或：acd∧abe選擇用例：[(2,0,4),(2,0,3)]（ace)[(1,1,1),(1,1,1)](abd)YYNN5、條件組合覆蓋使得每個判定中條件的各種可能組合都至少出現一次。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)黑盒法

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

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

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

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

分析步驟：

A先劃分等價類。

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

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

B按照輸入/輸出值個數的邊界。

C輸出值域的邊界。

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

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

B按照輸入/輸出值個數的邊界。

例如：輸入文件可有1-255個記錄，則設計用例：文件的記錄數為0個、1個、255個、256個。

C輸出值域的邊界。

例如：檢索文獻摘要，最多4篇。設計用例：可檢索0篇、1篇、4篇，和5篇（錯誤）。

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

應選擇第一個元素和最后一個元素。邊值分析法舉例黑盒法應用實例

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

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

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

I約束（或）—包容

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

O約束（唯一）—選一

a、b中僅有一個為1。

R約束（要求）—需要

a為1時，b必須為1

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

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

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

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

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

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

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

修改文件3.將因果圖轉換為判斷表

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

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

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

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

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

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

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

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

1.任務

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

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

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

LocalAreaTesting局域化測試

UsabilityTesting可使用性測試

RegressionTesting回歸測試

PerformanceTesting性能測試

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

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

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

而面向對象的測試貫穿軟件開發(fā)的全過程，是與開發(fā)過程密切相關，而又分離出來的過程。

面向對象的測試，既要使用許多傳統(tǒng)的成熟的軟件測試方法和技術，也有其不同的特點；主要反映在測試對象和內容的不同。

傳統(tǒng)的觀點認為測試要在編碼之后才進行，主要測試的對象是程序代碼。面向對象的測試更關注對象，而不是完成單一的輸入/輸出功能，因此測試可以在分析和設計階段介入，可以更好地配合軟件生產過程。8.4.1面向對象測試的特點1.強調需求或設計的測試，通常以兩種方式進行：

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

用例場景測試；

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

需求模型一致性檢查；

分析模型的檢查和走查。8.4.2面向對象測試類型模型測試類測試交互測試系統(tǒng)（子系統(tǒng)）測試驗收和發(fā)布測試

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

類屬性的測試

類操作的測試

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

用例或基于場景的測試

線程測試

對象的測試。8.4.2面向對象測試類型模型測試類測試交互測試系統(tǒng)（子系統(tǒng)）測試驗收和發(fā)布測試

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

功能測試

壓力測試

安全測試

兼容性測試

安裝測試

恢復測試8.4.2面向對象測試類型模型測試類測試交互測試系統(tǒng)（子系統(tǒng)）測試驗收和發(fā)布測試

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

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

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

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

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

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

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

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

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

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

信用卡(Creditcard)

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

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

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

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

b.計算訂單的價錢；

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

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

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

f.評價商務結果；

g.顧客退貨處理；

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

i.商品價格更新。

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

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

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

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

以第三條功能“根據訂單信息選擇倉庫，并將訂單發(fā)送給該倉庫”為例，說明用例的選擇。假設訂貨中心共有三個倉庫，管理者要決定應該選擇哪個倉庫處理訂單。倉庫名稱倉庫位置存貨品名及數量訂單處理客戶信譽度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訂單主要信息：訂單號、送貨地點、貨物名稱及數量等。管理者考慮將訂單分配到某倉庫的因素：

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

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

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

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

G4(10)85倉庫名稱倉庫位置存貨品名及數量訂單處理客戶信譽度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訂單號送貨地點貨物名稱及數量客戶信譽訂單1北城某集團公司G1(200)，G5(100)，G10(40)95訂單2東城某街道

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

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

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

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

預期結果：選擇倉庫C來處理訂單。

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

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

例2Date類是一個描述日期的類，其屬性為三個成員變量：年、月、日，在Date類中，操作decrease（）是使Date類的對象改變?yōu)楫斍叭掌诘那耙惶臁rintDate（）是打印日期信息。而Date類的三個成員變量所屬的類是calendarUnit類的子類。在calendarUnit類中，也有操作decrease（），并通過繼承關系在Day、Month、Yers三個類中重寫。設計測試用例，對Date類的操作decrease（）進行測試。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注意：操作測試應該考慮其可能被調用的各種情況。圖8.16calendarUnit類的繼承關系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方法進行測試,在設計測試用例時，采用等價分類法。劃分等價類時要考慮邊界及閏年等情況。有效等價類:D1=|一個月的第一天與最后一天之間|D2=|一個月的第一天|D3=|1月1日|M1=|前一個月是30天|M2=|前一個月是31天|M3=|前一個月是2月|Y1=|非閏年|Y2=|閏年|Y3=|2005年|無效等價類:D4=|<本月的第一天|D4=|>本月的最后一天|M4=|<1|M5=|>12|Y=|<0|用例ID月日年預期結果171919981998年7月18日