【精品】軟件測試

1、第六章 軟件測試 6.1 基本概念 軟件開發(fā)過程必須伴有質量保證活動。 軟件測試是軟件質量保證的關鍵元素，代表了規(guī)約、設計和編碼的最終檢查。 6.1.4 測試用例設計 選擇測試用例是軟件測試員最重要 的一項工作。測試用例的屬性:屬性 描述name 測試用例的名稱 location 可執(zhí)行的完全路徑名 input 輸入數(shù)據(jù)或命令oracle 與測試輸入相比較的期待測試結果log 測試生產(chǎn)的輸出6.1.5 軟件測試信息流軟件配置測試測試配置測試工具結果分析排錯可靠性 分析測試結果錯誤預期結果出錯率 改正的軟件預測的可靠性需求規(guī)格說明書軟件設計說明書 被測源程序 測試計劃 測試用例(測試數(shù)據(jù))測試驅

2、動程序測試活動和相關工作產(chǎn)品項目協(xié)議對象設計客戶開發(fā)人員用戶集成策略系統(tǒng)分解功能性需求非功能性需求單元測試集成測試結構測試功能測試性能測試來自ODD來自TP來自SDD來自RAD來自RAD用戶手冊驗收測試安裝測試現(xiàn)場測試日常操作測試設計中需要考慮的22種測試類型黑盒測試白盒測試單元測試累計綜合測試集成測試功能測試系統(tǒng)測試端到端測試健全測試衰竭測試接受測試負載測試強迫測試性能測試可用性測試安裝/卸載測試恢復測試兼容測試安全測試比較測試Alpha測試Beta測試6.1.6 測試的方法與技術軟件測試的策略和方法靜態(tài)測試方法動態(tài)測試方法人工測試方法計算機輔助靜態(tài)分析方法白盒測試方法黑盒測試方法動態(tài)測試方

3、法(1)選取定義域有效值,或定義域 外無效值.(2)對已選取值決定預期的結果(3)用選取值執(zhí)行程序(4)執(zhí)行結果 與(2)結果相比, 不吻和程序有錯.動態(tài)黑盒測試 閉著眼睛測試軟件軟件輸入 不深入代碼細節(jié)的測試方法稱為動態(tài)黑盒測試。軟件測試員充當客戶來使用它。輸出動態(tài)白盒測試 帶上X光眼鏡測試軟件?3581322.293419985680302829734315250*(1+0.015)*(1+0.015)360-1)/0.015250*(1+0.015)*(1+0.015)360-1)/0.015 假如知道一個盒子包含一臺計算機,而另一個盒子是人用紙筆計算,就會選擇不同的測試用例了解軟件的運

4、作方式會影響測試手段6.2 兩種類型的測試6.2.1 黑盒測試 又稱:功能測試 數(shù)據(jù)驅動測試 基于規(guī)格說明書的測試6.2.2 白盒測試 又稱:開盒測試 結構測試 玻璃盒測試 基于覆蓋的測試. 根據(jù)被測程序的邏輯結構設計 測試用例; 力求提高測試覆蓋率;黑盒測試與白盒測試比較 黑盒測試是從用戶觀點，按規(guī)格說明書要求的輸入數(shù)據(jù)與輸出數(shù)據(jù)的對應關系設計測試用例,是根據(jù)程序外部特征進行測試。 白盒測試是根據(jù)程序內(nèi)部邏輯結構進行測試。 黑盒測試與白盒測試優(yōu)缺點比較 黑盒測試 白盒測試 優(yōu)點缺點性質適用于各階段測試從產(chǎn)品功能角度測試容易入手生成測試數(shù) 據(jù)可構成測試數(shù)據(jù)使特定程 序部分得到測試有一定的充分性

5、度量手段可或較多工具支持某些代碼得不到測試如果規(guī)格說明有誤， 則無法發(fā)現(xiàn)不易進行充分性測試不易生成測試數(shù)據(jù)(通常)無法對未實現(xiàn)規(guī)格說明的 部分進行測試工作量大，通常只用于單 元測試，有應用局限是一種確認技術，回答“我們在構造一個正確 的系統(tǒng)嗎？”是一種驗證技術，回答“我們在正確 地構造一個系 統(tǒng)嗎？” 不論黑盒還是白盒測試都不能進行窮盡測試, 所以軟件測試不可能發(fā)現(xiàn)程序中存在的所有錯誤, 因此需精心設計測試方案, 力爭盡可能少的次數(shù),測出盡可能多的錯誤.黑盒測試與白盒測試能發(fā)現(xiàn)的錯誤CBAD-只能用黑盒測試發(fā)現(xiàn)的錯誤A-只能用白盒測試發(fā)現(xiàn)的錯誤-兩種方法都能發(fā)現(xiàn)的錯誤-兩種方法都不能發(fā)現(xiàn)的錯誤

6、BCD6.3白盒測試的測試用例設計 6.3.1 邏輯覆蓋法(1)語句覆蓋(2)判定覆蓋(3)條件覆蓋(4)判定/條件覆蓋(5)條件組合覆蓋(6)路徑覆蓋(7)點覆蓋(8)邊覆蓋例:PROCEDURE SAMPAL (A，B：REAL； VAR X：REAL); BEGIN IF (A1) AND (B=0) THEN X:=X/A IF (A=2) OR (X1) THEN X:=X+1 END; 開始(A1) AND (B=0)(A=2) OR (X1)返回X=X/AX=X+1FFTTabdce(1)語句覆蓋使程序中每個語句至少執(zhí)行一次語句覆蓋開始(A1) AND (B=0)(A=2) OR

7、 (X1)返回X=X/AX=X+1FFTTabdce只需設計一個測試用例:輸入數(shù)據(jù)：A=2，B=0，X=4即達到了語句覆蓋;語句覆蓋是最弱的邏輯覆蓋(2)判定覆蓋(分支覆蓋) 使每個判定的真假分支都至少執(zhí)行一次判定覆蓋開始(A1) AND (B=0)(A=2) OR (X1)返回X=X/AX=X+1FFTTabdce例:可設計兩組測試用例:A=3，B=0 ，X=3 可覆蓋c、d分支 A=2，B=1 ，X=1 可覆蓋b、e分支 兩組測試用例可覆蓋所有判定的真假分支語句覆蓋仍是弱的邏輯覆蓋(3)條件覆蓋 使每個判定的每個條件的可能取值至少執(zhí)行一次第一判定表達式:設條件 A1 取真 記為 T1 假

8、T1 條件 B=1 取真 記為 T2 假 T2第二判定表達式:設條件 A=2 取真 記為 T3 假 T3 條件 X1 取真 記為 T4 假 T4條件覆蓋開始(A1) AND (B=0)(A=2) OR (X1)返回X=X/AX=X+1FFTTabdce滿足條件: T1,T1, T2,T2 T3,T3 T4,T4測試用例 通過 滿足的 覆蓋A B X 路徑 條件 分支1 0 3 abe T1,T2,T3,T4 b,e2 1 1 abe T1,T2,T3,T4 b,e 兩個測試用例覆蓋了四個條件八種可能取值。未覆蓋c、d分支，不滿足判定覆蓋的要求.條件覆蓋不一定包含判定覆蓋判定覆蓋也不一定包含條件

9、覆蓋(4)判定/條件覆蓋 選取足夠多的測試用例，使判斷中的每個條件的所有可能取值至少執(zhí)行一次，同時每個判斷本身的所有可能判斷結果至少執(zhí)行一次.判定/條件 覆蓋開始(A1) AND (B=0)(A=2) OR (X1)返回X=X/AX=X+1FFTTabdce滿足條件: T1,T1, T2,T2 T3,T3 T4,T4測試用例 通過 滿足的 覆蓋A B X 路徑 條件 分支2 0 4 ace T1,T2,T3,T4 c,e2 1 1 abd T1,T2,T3,T4 b,d 能同時滿足判定、條件兩種覆蓋標準。取值。測試用例 通過 滿足的 覆蓋A B X 路徑 條件 分支2 0 3 ace T1,T

10、2,T3,T4 c,e2 1 1 abe T1,T2,T3,T4 b,e1 0 3 abe T1,T2,T3,T4 b,e1 1 1 abd T1,T2,T3,T4 b,d (5)條件組合覆蓋 所有可能的條件取值組合至少執(zhí)行一次 A1, B=0 A1, B0 A1, B=0 A1, B0 A=2, X1 A=2, X1 A2, X1 A2, X1測試用例 通過 滿足的 覆蓋A B X 路徑 條件 分支2 0 4 ace T1,T2,T3,T4 c,e2 1 1 abe T1,T2,T3,T4 b,e1 0 2 abd T1,T2,T3,T4 b,d1 1 1 abd T1,T2,T3,T4 b

11、,d (6)路徑覆蓋 覆蓋每一個可能的路徑測試用例 通過 滿足的 覆蓋A B X 路徑 條件 分支1 1 1 abd T1,T2,T3,T4 b,d1 1 2 abe T1,T2,T3,T4 b,e3 0 1 acd T1,T2,T3,T4 c,d2 0 4 ace T1,T2,T3,T4 c,e基本路徑測試法 通過分析由控制構造的環(huán)路的復雜性，導出基本路徑集合，從而設計測試用例，保證這些路徑至少通過一次。 基本路徑測試步驟： 導出程序流程圖的拓撲結構-流圖 (程序圖) 計算流圖G的環(huán)路復雜度V(G) 確定只包含獨立路徑的基本路徑集 設計測試用例導出程序流程圖的拓撲結構-流圖12,364,57

12、10611a節(jié)點邊R4區(qū)域12345873911程序流程圖89R1R2R3計算流圖G的環(huán)路復雜度V(G) V(G)= 區(qū)域個數(shù)=4 V(G)=邊的條數(shù)-節(jié)點個數(shù)+2=4 V(G)=判定節(jié)點個數(shù)+1=4確定只包含獨立路徑的基本路徑集path1:1-11path1:1-2-3-4-5-10-1-11path1:1-2-3-6-8-9-10-1-11path1:1-2-3-6-7-9-10-1-11 一條新路徑必須包含一條新邊。 這4條路徑組成了一個基本路徑集。4(環(huán)路復雜度V(G)是構成這個基本路徑集的獨立路徑數(shù)的上界，也是設計測試用例的數(shù)目。 設計測試用例，保證基本路徑集中每條路徑的執(zhí)行。6.4

13、黑盒測試的測試用例設計6.4.1 等價類劃分法 把所有可能的輸入數(shù)據(jù)(有效的和無效的)劃分成若干個等價的子集(稱為等價類)， 使得每個子集中的一個典型值在測試中的作用與這一子集中所有其它值的作用相同. 可從每個子集中選取一組數(shù)據(jù)來測試程序例:某報表處理系統(tǒng)要求用戶輸入處理 報表的日期，日期限制在2001年1 月至2005年12月，即系統(tǒng)只能對該 段期間內(nèi)的報表進行處理，如日期 不在此范圍內(nèi)，則顯示輸入錯誤信 息。 系統(tǒng)日期規(guī)定由年、月的6位數(shù)字 字符組成，前四位代表年，后兩位 代表月。 如何用等價類劃分法設計測試用例, 來測試程序的日期檢查功能？如何劃分等價類？有效等價類(合理等價類)無效等價

14、類(不合理等價類) 劃分等價類的標準：覆蓋不相交代表性劃分等價類的規(guī)則 (1)如果輸入條件規(guī)定了取值范圍， 可定義一個有效等價類和兩個無 效等價類。例 輸入值是學生成績，范圍是01000 100 有效等價類1成績100無效等價類 成績100 無效等價類 成績0劃分等價類的規(guī)則：(2)如果輸入條件代表集合的某 個元素，則可定義一個有效 等價類和一個無效等價類。劃分等價類的規(guī)則：(3)如規(guī)定了輸入數(shù)據(jù)的一組值，且 程序對不同輸入值做不同處理， 則每個允許的輸入值是一個有 效等價類，并有一個無效等價類 (所有不允許的輸入值的集合)。例：輸入條件說明學歷可為:?？?、本科、 碩士、博士四種之一，則分別取

15、這四 種這四個值作為四個有效等價類，另 外把四種學歷之外的任何學歷作為無 效等價類劃分等價類的規(guī)則：(4)如果規(guī)定了輸入數(shù)據(jù)必須遵循的規(guī) 則，可確定一個有效等價類（符合 規(guī)則）和若干個無效等價類（從不 同角度違反規(guī)則)。(5)如已劃分的等價類各元素在程序中 的處理方式不同，則應將此等價 類進一步劃分成更小的等價類。用等價類劃分法設計測試用例步驟：(1)形成等價類表，每一等價類規(guī)定 一個唯一的編號；(2)設計一測試用例，使其盡可能多 地覆蓋尚未覆蓋的有效等價類， 重復這一步驟，直到所有有效等 價類均被測試用例所覆蓋；(3)設計一新測試用例，使其只覆蓋 一個無效等價類，重復這一步驟 直到所有無效等

16、價類均被覆蓋；第一步：等價類劃分輸入等價類 有效等價類 無效等價類 報表日期的類型及長度3位數(shù)字字符(1)有非數(shù)字字符 (4)少于6個數(shù)字字符 (5)多于6個數(shù)字字符 (6)年份范圍在20012005之間 (2)小于2001 (7)大于2005 (8)月份范圍在112之間(3)“報表日期”輸入條件的等價類表小于1 (9)大于12 (10)第二步：為有效等價類設計測試用例 對表中編號為1,2,3的3個有效等價類 用一個測試用例覆蓋： 測試數(shù)據(jù) 期望結果 覆蓋范圍200105等價類(1)(2)(3)輸入有效第三步：為每一個無效等價類設至少 計一個測試用例 測試數(shù)據(jù) 期望結果 覆蓋范圍001MAY等

17、價類(4)輸入無效20015等價類(5)輸入無效2001005等價類(6)輸入無效200005等價類(7)輸入無效200805等價類(8)輸入無效200100等價類(9)輸入無效200113等價類(10)輸入無效不能出現(xiàn)相同的測試用例本例的10個等價類至少需要8個測試用例例:對招干考試系統(tǒng)“輸入學生成績” 子模塊設計測試用例 招干考試分三個專業(yè),準考證號第一位 為專業(yè)代號,如: 1-行政專業(yè), 2-法律專業(yè), 3-財經(jīng)專業(yè). 行政專業(yè)準考證號碼為:110001111215法律專業(yè)準考證號碼為:210001212006財經(jīng)專業(yè)準考證號碼為:310001314015例:準考證號碼的等價類劃分 有效

18、等價類: (1) 110001 111215 (2) 210001 212006 (3) 310001 314015 無效等價類: (4) - 110000 (5) 111216 210000 (6) 212007 31000 (7) 314016 + 例:計算給定月份中天數(shù)的方法接口(java):Class MyGregorianCalender public static in getNumDaysInMonth(int month,int year)getNumDaysInMonth( )方法有兩個參數(shù), 月和年,年份的有效輸入是從0到maxInt. 等價類劃分即把輸入空間分解成一系列子

19、域，軟件在一個子域內(nèi)的行為應是等價的。 軟件錯誤分為兩類：計算錯誤 域錯誤針對計算錯誤的測試方法針對域錯誤的測試方法:測試域邊界 劃定的正確性6.4.2 邊界值分析法邊界值分析法與等價類劃分法區(qū)別(1)邊界值分析不是從某等價類中 隨便挑一個作為代表，而是使 這個等價類的每個邊界都要作 為測試條件。(2)邊界值分析不僅考慮輸入條件， 還要考慮輸出空間產(chǎn)生的測試 情況被測試子 域測試內(nèi)點測試外點軟件邊界與懸崖很類似邊界條件類型 如果軟件測試問題包含確定的邊界,那么數(shù)據(jù)類型可能是:數(shù)值字符位置數(shù)量速度地址尺寸還要考慮數(shù)據(jù)類型的特征:第一個/最后一個最小值/最大值開始/完成空/滿最慢/最快相鄰/最遠超

20、過/在內(nèi)測試邊界線測試臨近邊界的合法數(shù)據(jù),以及剛超過邊界的非法數(shù)據(jù).越界測試通常簡單地加1或很小的數(shù) (對于最大值)和減1或很小的數(shù)(對于最小值). 輸入條件報表日期的類型及長度1個數(shù)字字符5個數(shù)字字符7個數(shù)字字符有1個非數(shù)字字符全部是非數(shù)字字符6個數(shù)字字符顯示出錯顯示出錯顯示出錯顯示出錯顯示出錯輸入有效日期范圍月份范圍“報表日期”邊界值分析法測試用例測試用例說明測試數(shù)據(jù)期望結果選取理由52001520010052001.5MAY-200105月份為1月月份為12月月份12200101200112200100200113200101200512200100200513輸入有效輸入有效顯示出錯顯

21、示出錯輸入有效輸入有效顯示出錯顯示出錯在有效范圍邊界上選取數(shù)據(jù)僅有1個合法字符比有效長度少1比有效長度多1只有1個非法字符6個非法字符類型及長度均有效最小日期最大日期剛好小于最小日期剛好大于最大日期最小月份最大月份剛好小于最小月份剛好大于最大月份6.4.3 錯誤推測法(error guessing)根據(jù)經(jīng)驗來設計測試用例的方法例如，數(shù)據(jù)測試中的:缺省值空白空值零值無 6.4.4 狀態(tài)測試 軟件必須測試程序的狀態(tài)及其轉換。測試軟件的邏輯流程建立狀態(tài)轉換圖減少要測試的狀態(tài)及轉換的數(shù)量空閑等待用戶輸入命令按下Esc鍵顯示口令框口令錯誤 消除口令正確初始狀態(tài)消失空閑等待用戶輸入命令按下Esc鍵口令正確

22、口令錯誤不同形式的狀態(tài)轉換圖 設置2Bwatch 上的時間的順序圖:2Bwatch用戶按下按鈕1和2:2Bwatch輸入:2Bwatch顯示:2Bwatch時間時間按下按鈕1按下按鈕2按下按鈕1和2閃爍小時閃爍分鐘增加分鐘刷新提交更新時間停止閃爍2Bwatch 設置時間功能的狀態(tài)圖和測試結果 按左按鈕 按右按鈕按左按鈕 按右按鈕4. 2分鐘以后測量時間設置時間電池沒電3.按下左右按鈕5.按下左右按鈕/蜂鳴8. 20年以后7. 20年以后6.2.1.激勵因素空集合測量時間1.初始變遷測試的變遷預期結果狀態(tài)按下左邊按鈕測量時間2.同時按下兩個按鈕設置時間3.等2分鐘測量時間4.超時失敗狀態(tài)測試找到

23、測試軟件失敗的案例。競爭條件和時序錯亂重復壓迫重負應聯(lián)合使用，同時進行有效等價類和用來測試getNumDaysInMonth()方法所選的有效輸入 有效等價類一個月有31天,非閏年19017(七月)一個月有31天, 閏年19047(七月)一個月有30天,非閏年19016(六月)一個月有30天, 閏年19046(六月)一個月為28或29天,非閏年19012(二月)月份輸入值年份輸入值一個月為28或29天, 閏年2(二月)1904用來測試getNumDaysInMonth()方法的附加邊界值 等價類可以被400整除的閏年20002(二月)可以被100整除的非閏年19002(二月)非正數(shù)無效月份12

24、910正數(shù)無效月份131513月份輸入值年份輸入值6.4.5 因果圖法 因果圖適合于描述對于多種輸入條件的組合，相應產(chǎn)生多個動作的形式來設計測試用例。 因果圖方法最終生成的是判定表。因果圖方法實例某電力公司有A、B、C、D四類收費標準,并規(guī)定：居民用電 100度/月 按A類收費 100度/月按B類收費動力用電 10000度/月,非高峰,B類收費 10000度/月,非高峰,C類收費 10000度/月, 高峰,C類收費 10000度/月, 高峰,D類收費用因果圖表明輸入和輸出間的邏輯關系1I12B4AC35DI4I3I2把因果圖轉換為判定表組合條件條件(原因) 動作(結果)ABC123123456

25、101100011000110000100001104101050011D000110010000測試用例為判定表每一列設計一個測試用例:1列 居民電,90度/月 A2列 居民電,110度/月 B3列 動力電,非高峰,8000度/月 B4列 動力電,非高峰,1.2萬度/月 C5列 動力電, 高峰,0.9萬度/月 C6列 動力電, 高峰,1.1萬度/月 D 條件 測試用例 預期結果組合 (輸入數(shù)據(jù)) (輸出動作)6.5 針對專門環(huán)境和應用的測試6.5.1 GUI測試常見GUI測試指南：對于窗口對于菜單和鼠標操作對于數(shù)據(jù)項6.5.2 C/S體系結構的測試 整體C/S測試策略(三個不同層次)客戶端應

26、以“分離的”模式被測試 (不考慮服務器和底層網(wǎng)絡的運行)客戶端軟件和關聯(lián)的服務器端應用被一起測試(網(wǎng)絡運行不被明顯考慮)完整的C/S體系結構(包括網(wǎng)絡運行和性能)被測試 C/S常用測試方法客戶端應用功能測試服務器測試（協(xié)調(diào)和數(shù)據(jù)管理功能、性能）數(shù)據(jù)庫測試事務測試網(wǎng)絡通信測試6.5.3 實時系統(tǒng)測試可采用以下四步策略：(1) 任務測試(2) 行為測試(3) 任務間測試(4) 系統(tǒng)測試(1) 任務測試 (task testing) 對每一個任務進行單獨測試(白盒、黑盒測試)，發(fā)現(xiàn)邏輯和功能上錯誤，不能發(fā)現(xiàn)定時上和行為上錯誤 。(2)行為測試(behavioral testing) 用CASE工具創(chuàng)

27、建應用系統(tǒng)模型，模擬實時系統(tǒng)行為。 按類測試各種事件(如中斷、控制信號、數(shù)據(jù))。 測試過的事件以隨機次序、隨機頻率送給系統(tǒng),檢查軟件行為方面的錯誤.(3)任務間測試(intertask testing) 檢查與時間有關錯誤。 如用不同數(shù)據(jù)速率、處理負載 測試相互通信的異步任務。 通過消息隊列或數(shù)據(jù)存儲測試 任務間的通信來找出數(shù)據(jù)存儲區(qū)錯 誤的范圍。(4) 系統(tǒng)測試 (system testing) 軟件、硬件組裝后，找出軟、硬件接口錯誤。軟件測試的過程被測模塊單元測試設計信息集成測試被測模塊單元測試被測模塊單元測試測試過的模塊確認測試系統(tǒng)測試軟件需求其它系統(tǒng)元素裝配好的軟件 確認的軟件可運行的

28、軟件6.6軟件測試的步驟軟件測試策略單元測試UCDRSIVST集成測試確認測試系統(tǒng)測試系統(tǒng)工程軟件需求分析軟件設計代碼編寫6.6.1 單元測試一.單元測試的內(nèi)容主要對模塊的五個基本特性進行評價模塊錯誤處理模塊接口局部數(shù)據(jù)結構 重要的執(zhí)行路徑邊界條件1.常見錯誤類型 接口錯誤I/O錯誤數(shù)據(jù)結構錯誤算法錯誤比較及控制邏輯錯誤錯誤處理錯誤2. 模塊測試基本原則 至少一次測試所有語句測試所有可能的執(zhí)行或邏輯路徑的組合測試每個模塊的所有入口和出口3. 確定單元測試數(shù)據(jù)集 值域值類離散值值的次序集(測試順序文件和表) 二. 單元測試的方法單元測試一般為編碼步驟的附屬部分.模塊不是獨立的程序,自己不能運行,

29、要靠其它部分來調(diào)用和驅動,要為每個單元測試開發(fā)兩個軟件:(1)驅動模塊(驅動程序):相當于主模塊(2)樁模塊(測試存根、連接程序) : 代替所測模塊調(diào)用的子模塊單元測試的測試環(huán)境舉例:BACDE待測試模塊單元測試的測試環(huán)境舉例:被測模塊 B 驅動模塊(模擬模塊A)樁模塊(測試存根)(模擬模塊E)測試用例測試結果許多模塊不能用簡單的軟件進行充分的單元測試, 此時, 完全的測試可放到集成測試階段再進行.單元測試的測試環(huán)境舉例: 實際軟件華氏到懾氏轉換模塊溫度數(shù)據(jù)實際配置測試用例數(shù)據(jù)結果 測試驅動軟件華氏到懾氏轉換模塊結果測試驅動際配置單元測試的測試環(huán)境舉例 溫度顯示模塊溫度接口模塊實際配置測試驅動

30、際配置 溫度顯示模塊程序員編寫的樁模塊(測試存根)溫度值的測試文件結構性模式(structural patterns)適配器模式(Adapter)打包器(Wrapper)橋模式(Bridge)句柄(Handle)組合模式(Composite) 修飾模式(Decorator)包裝器(Wrapper)外觀模式(Facade)輕量模式 (Flyweight)代理模式(Proxy)6.6.2 集成測試(組裝測試)集成測試需考慮的問題:數(shù)據(jù)穿越接口可能丟失.一模塊可能破壞另一模塊功能.子功能組裝可能未產(chǎn)生所要求的 主功能.全程數(shù)據(jù)結構可能出問題.誤差累積問題.集成測試方法通常采用黑盒測試技術實施策略:非

31、漸增式測試漸增式測試 深度優(yōu)先廣度優(yōu)先自頂向下結合自底向上結合一. 非漸增式集成方式 一次就把所有通過了單元測試的模塊組合在一起進行全程序的測試.缺點:發(fā)現(xiàn)錯誤難以診斷定位. 又稱“莽撞測試” .二. 漸增式集成方式 從一個模塊開始,測一次添加一個模塊，邊組裝邊測試，以發(fā)現(xiàn)與接口相聯(lián)系的問題。自頂向下結合方式舉例:ADBE模塊測試結合順序CF深度優(yōu)先:A、B、E、C、D、F廣度優(yōu)先:A、B、C、D、E、F自頂向下結合方式舉例:(深度優(yōu)先)A測試 AS2S1S3A加入BS2BS3S4A加入ES2BS3EA加入CCBS3E加入DCBDE加入FCBDEAAFS5自底向上結合方式舉例:ACBDFEEd

32、1Cd3Fd4Bd2EDd5F自底向上結合方式舉例:McD1MaMbD2D3簇1簇2簇3 自頂向下 自底向上優(yōu)點 可在測試早期 設計測試用例容易 實現(xiàn)并驗證系 統(tǒng)主要功能 不需驅動模塊 不需樁模塊 缺點 需樁模塊 只有到最后程序才 能作為一個整體3. 混合集成測試方法一般對軟件結構的上層使用自頂向下結合的方法;對下層使用自底向上結合的方法;6.6.3 確認測試 (有效性測試)有效 性測試軟件配置審查管理機構裁決選擇測試人員軟件計劃用戶文檔開發(fā)文檔源程序文本支持環(huán)境交用戶 運行 維護測試報告軟件配置構造測試用例(驗收測試)實際運行測試專家鑒定 會一.有效性測試 通過黑盒測試,證實軟件功能與用戶需

33、求是否一致.二.軟件配置審查與驗收確認測試軟件配置審查主管部門批準集成的軟件軟件需求用戶文檔設計文檔源程序測試文檔交付的軟 件確認的軟 件確認的配 置三. 人工測試靜態(tài)分析對源程序進行靜態(tài)分析的方法： 生成各類引用表 靜態(tài)錯誤分析類型和單位分析引用分析表達式分析接口分析對源程序進行靜態(tài)分析的方法：(1)桌前檢查檢查變量、標號的交叉引用檢查子程序、宏、函數(shù)、常量檢查標準、風格檢查(2)代碼會審(3)走查四. 確認測試結果測試完成后可能出現(xiàn)兩種情況:(1)測試與預期相符, 可接受.(2)不相符,列出軟件缺陷表,與用戶協(xié)商解 決.五. 測試和測試測試(Alpha)在開發(fā)者的場所由用戶進行,在開發(fā)著關

34、注和控制的環(huán)境下進行.測試(Beta)最終用戶在自己的場所進行.6.6.4 系統(tǒng)測試 軟件只是計算機系統(tǒng)的一個元素，軟件最終要與其他系統(tǒng)元素（如新硬件、信息等)相結合，進行各種集成測試和確認測試.用于系統(tǒng)測試的測試類型:(1)恢復測試(2)安全性測試(3)強度測試(4)性能測試推測殘留在程序中的錯誤數(shù)錯誤植入模型 Mills將播種模型用于程序中殘留錯誤的估算,稱錯誤植入模型播種模型：N： 程序中原有殘留的錯誤數(shù)Nt：新植入的錯誤數(shù)n: 測試發(fā)現(xiàn)的原有錯誤數(shù)nt :測試發(fā)現(xiàn)的植入錯誤數(shù)NNnnttNNnnt=tHyman對錯誤植入模型的改進ET: 程序中原有的殘留錯誤數(shù)E1: 1號測試員在某一時

35、間內(nèi)發(fā)現(xiàn)的錯誤數(shù)E2: 2號測試員在同一時間內(nèi)發(fā)現(xiàn)的錯誤數(shù)E0: 兩位測試員共同發(fā)現(xiàn)的錯誤數(shù)EEEE10=2TETE1E2/E0(1)恢復測試以不同的方式強使軟件出現(xiàn)故障,檢測軟件能否恰當?shù)赝瓿苫謴? 自動恢復:檢測重新初始化、 檢測點設置、 數(shù)據(jù)恢復、 重新啟動等是否正確.人工干預恢復:檢測平均恢復時間是 否在允許范圍內(nèi).(2)安全性測試設計測試用例,突破軟件安全保護機構的安全保密措施,檢驗系統(tǒng)預防機制的漏洞.(3)強度測試 設計測試用例, 檢驗系統(tǒng)能力最高能達到的實際限度, 讓系統(tǒng)處于資源的異常數(shù)量、異常頻率、異常批量的條件下測試系統(tǒng)的承受能力. 一般比平常限度高5-10倍的限度做測 試用

36、例.6.6 面向對象的軟件測試測試目標：在現(xiàn)實的時間跨度內(nèi)應用可管理 的工作量去發(fā)現(xiàn)最大可能數(shù)量的 錯誤基本目標不變，但由于OO程序的性質改變了測試策略 和測試戰(zhàn)術更多的設計模式復用是否將減輕OO系統(tǒng)的繁重測試？Binder,R.V.在“Object-Oriented Software Testing”中討論改問題:“每次復用是一個新的使用語境,并且重新測試是謹慎的.為了獲得面向對象系統(tǒng)的高可靠性,似乎可能需要更多而不是更少的測試.”強度測試是一種敏感性測試技術,某種情況下,一包含在程序有效數(shù)據(jù)邊界內(nèi)的非常小范圍的數(shù)據(jù)變動可能導致極端的, 甚至錯誤的處理, 或使系統(tǒng)性能嚴重下降.敏感性測試用來

37、發(fā)現(xiàn)可能導致不穩(wěn)定或不正確處理的有效輸入類中的數(shù)據(jù)組合.(4)性能測試 設計測試用例，并記錄軟件運行性能，與性能要求比較，檢驗是否達到性能要求規(guī)格。6.6.5 測試的步驟及 相應的測試種類6.6 面向對象的軟件測試測試目標：在現(xiàn)實的時間跨度內(nèi)應用可管理 的工作量去發(fā)現(xiàn)最大可能數(shù)量的 錯誤基本目標不變，但由于OO程序的性質改變了測試策略 和測試戰(zhàn)術更多的設計模式復用是否將減輕OO系統(tǒng)的繁重測試？Binder,R.V.在“Object-Oriented Software Testing”中討論改問題:“每次復用是一個新的使用語境,并且重新測試是謹慎的.為了獲得面向對象系統(tǒng)的高可靠性,似乎可能需要更

38、多而不是更少的測試.”6.6.1 OOA和OOD的 模型測試 每個階段的所有面向對象模型都應被測試。 OOA和OOD的模型不能被執(zhí)行，對它們不能進行傳統(tǒng)意義上的測試。 可通過技術復審檢查OOA和OOD的模型的正確性和一致性。擴大測試的視角6.6.2 面向對象測試策略信息隱蔽對測試的影響封裝和繼承對測試的影響面向對象程序的特點對軟件測試的影響：單元和集成測試策略必須有很大的改變測試用例的設計必須考慮OO軟件的特征 1. OO的單元測試一個類可以包含一組不同的操作，而一個特定 的操作也可能存在于一組不同的類中。不再孤 立地測試單個操作(這是傳統(tǒng)單元測試的視角)OO軟件的類測試等價于傳統(tǒng)的單元測試.

39、傳統(tǒng)軟件的單元測試關注算法細節(jié)和模塊接口 間流動的數(shù)據(jù) OO軟件的類測試是由封裝在類中的操作和類的 狀態(tài)行為驅動的單元概念的變化封裝的類或對象作為最小 的可測試單位 2. OO的集成測試 OO軟件沒有層次的控制結構,傳統(tǒng)的自頂向下和自底向上的集成策略沒有意義.OO軟件的集成兩種策略:基于線程的測試(thread-based testing) 集成響應系統(tǒng)的一個輸入或事件所需的一組類,每個線程被個體地集成和測試,通過回歸測試保證沒有副作用產(chǎn)生;基于使用的測試(use-based testing) 通過測試幾乎不使用服務器的類(獨立類)來開始系統(tǒng)的構造,測試完獨立類后,使用獨立類按層逐步完成依賴類

40、的測試直至完整的系統(tǒng)被構造; 3. OO的確認測試在確認和系統(tǒng)測試層次,類連接的細節(jié)消失.和傳統(tǒng)的確認測試一樣,OO軟件的確認關注 用戶可見的動作和用戶可識別的系統(tǒng)輸出.為輔助確認測試的導出, 應利用分析模型中的 用例圖提供的場景來提高交互需求中發(fā)現(xiàn)錯誤 的可能性6.6.3 OO軟件的測試用例設計每個測試用例應被唯一標識，并應顯式地和與被 測試類相關聯(lián)測試的目的應被陳述對每個測試應開發(fā)一組測試步驟，包括：將被測試對象的一組特定狀態(tài)將被作為測試的結果使用的一組消息和操作當對象被測試時可能產(chǎn)生的一組異常一組外部條件(進行測試必須的軟件外部環(huán)境的變化)將輔助理解或實現(xiàn)測試的補充信息OO軟件的測試用例

41、設計還處于成型期.Binder,R.V.在“Essays on Object-Oriented Software Engineering”中建議了對OO軟件的測試用例設計的整體方法:1. OO概念的測試用例設計的含義封裝可能會成為測試的障礙 測試需要報告對象的具體和抽象狀態(tài)，而封裝 使得對象的狀態(tài)快照難于獲得。繼承，特別是多繼承使測試復雜化子類繼承或重載的父類成員函數(shù)的測試問題繼承的成員函數(shù)是否都不需要測試? 對父類中已經(jīng)測試過的成員函數(shù),兩種情況需要 在子類中重新測試: 繼承的成員函數(shù)在子類中做了改動; 成員函數(shù)調(diào)用了改動過的成員函數(shù)的部分;例如: 父類Base有兩個成員函數(shù)Inherite

42、d()和Redefined(), 子類Derived只對Redefined() 做了改動. Derived Redefined() 需要重新測試 Derived Inherited() 如果它調(diào)用了Redefined() 的 語句,則需重新測試,否則不必子類繼承或重載的父類成員函數(shù)的測試問題對父類的測試是否能夠照搬到子類? 上例中: BaseRedefined() 和Derived Redefined() 已是兩個不同的成員函數(shù), 照理應對Derived Redefined() 重新進行測試分析, 設計測試用例,但由于它們的相似性,只需在BaseRedefined() 的測試要求和測試用例上添

43、加對Derived Redefined() 的新的測試要求和增補相應的測試用例.2. 傳統(tǒng)測試用例設計方法的可用性白盒測試方法可用于類定義的操作的測試對具有簡潔結構的類，白盒測試最好用于類級別 的測試黑盒測試方法也適合OO系統(tǒng)6.6.4 測試單個類的方法（1）隨機測試例:銀行系統(tǒng)的account(帳戶)類有下列操作：open(打開)setup(建立)deposit(存款)withdraw(取款)balance(余額)summarize(清單)creditLimit(透支限額)close(關閉)系統(tǒng)對操作的限制：必須在應用其它操作之前先打開帳戶,在完成了 全部操作之后才能關閉帳戶;在限制下還是存

44、在操作的許多排列一個account類實例的最小行為歷史包括下列操作:open . setup . deposit . withdraw . close account類的最小測試序列大量的其它行為可能在下面序列中發(fā)生:open . setup . deposit . deposit | withdraw | balance | summarize | creditLimit n . withdraw . close 一系列不同的操作序列可以隨機地產(chǎn)生,例如:測試用例r1: open.setup.deposit.deposit.balance. summarize.creditLimit.wit

45、hdraw.close 測試用例r2: open.setup.deposit.withdraw.deposit. balance. creditLimit.withdraw.close這些和其它的隨機順序測試被進行,以測試不同的類實例的生存歷史.測試單個類的方法（2）劃分測試(partition testing) 與測試傳統(tǒng)軟件時采用的等價類劃分方法類似. 劃分類別的方法:基于狀態(tài)的劃分基于屬性的劃分基于功能的劃分基于狀態(tài)的劃分 根據(jù)類操作改變類狀態(tài)的能力來劃分類操作.例：銀行系統(tǒng)的account(帳戶)類 狀態(tài)操作包括: deposit(存款) withdraw(取款) 非狀態(tài)操作包括:ba

46、lance(余額) summarize(清單) creditLimit(透支限額)測試用例p1(測試改變狀態(tài)的操作): open.setup.deposit.deposit.withdraw.close 測試用例p2 (測試不改變狀態(tài)的操作,在最小測試序列中 的操作除外) : open.setup.deposit.summarize. creditLimit.withdraw.close基于屬性的劃分 根據(jù)類操作使用的屬性來劃分類操作.例：銀行系統(tǒng)的account(帳戶)類可根據(jù)balance屬 性來定義劃分,把操作劃分為三個類別: 使用balance的操作 修改balance的操作 不使用也

47、不修改balance的操作 為上述每個類別設計測試序列基于功能的劃分 根據(jù)類操作所完成的功能來劃分類操作.例：銀行系統(tǒng)的account(帳戶)類中的操作可劃分 為三個類別: 初始化操作(open, setup) 計算操作(deposit, withdraw) 查詢操作(balance, summarize, creditLimit) 終止操作(close) 為上述每個類別設計測試序列測試類和方法（3）基于故障的測試(fault_based testing)與測試傳統(tǒng)軟件時采用的錯誤推測法類似. 6.6.5 面向對象的集成測試 (類間測試用例的設計) 在OO系統(tǒng)的集成開始時, 開始類間的協(xié)作測試

48、. 和單個類的測試一樣, 類協(xié)作測試可通過隨機和劃分方法以及基于場景的測試和行為測試來完成. ATMBank銀行系統(tǒng)的類協(xié)作圖ATMUserInterfaceAccountCashierverifyAcctverifyPINverifyPolicywithdrawReqdepositReqacctInfoReqcardInsertedpassworddepositwithdrawaccentStatusterminatevalidPINvalidAcctcreditLimitaccentTypebalancewithdrawdepositcloseopenAcctinitialDeposita

49、uthorizeCarddeuthorizecloseAcctValidationInfoverifyStatusdepositStatusdispenseCaseprintAccentStatreadCardInfogetCaseAmnt OO集成測試方法（1）多個類測試 Kirani,S.and W.T.Tsai,在“Specification and Verification of Object-Oriented Programs” 中建議了下面的步驟序列以生成多個類隨機測試用例:1.對每個客戶類,使用類操作列表來生成一系列隨機測試序列,這些操作發(fā)送消息給服務器類;2.對生成的每個消息,

50、確定在服務器對象中的協(xié)作者類和對應的操作;3.對服務器對象中的每個操作(已經(jīng)被來自客戶對象的消息調(diào)用),確定傳遞的消息;4.對每個消息,確定下一層被調(diào)用的操作,并把這些操作結合進測試序列中. ATMBank銀行系統(tǒng)的類協(xié)作圖ATMUserInterfaceAccountCashierverifyAcctverifyPINverifyPolicywithdrawReqdepositReqacctInfoReqcardInsertedpassworddepositwithdrawaccentStatusterminatevalidPINvalidAcctcreditLimitaccentTypeb

51、alancewithdrawdepositcloseopenAcctinitialDepositauthorizeCarddeuthorizecloseAcctValidationInfoverifyStatusdepositStatusdispenseCaseprintAccentStatreadCardInfogetCaseAmnt銀行系統(tǒng)中Bank類和ATM類的操作序列:verifyAcct verifyPIN verifyPolicy withdrawReq | depositReq | acctInfoReqn對Bank類的隨機測試用例可能是:測試用例r3: verifyAcct v

52、erifyPIN depositReq為了考慮測試中涉及的協(xié)作者,需要考慮與測試用例r3中每個操作相關聯(lián)的消息:Bank必須和ValidationInfo協(xié)作以執(zhí)行verifyAcct和verifyPINBank還必須和Account協(xié)作以執(zhí)行depositReq因此,測試這些協(xié)作的新的測試用例是: 測試用例r4:verifyAcctBank validAcctValidationInfo verifyPINBank validPINValidationInfo depositReq depositAccount OO集成測試方法（2）從動態(tài)模型導出測試用例 設計的測試用例應達到完全的狀態(tài)覆蓋,即操作序列應導致account類的變遷穿越所有允許的狀態(tài):測試用例s1: opensetupAccent deposit(initial) withdraw(final) close(最小測試序列) 向最小序列中加入附加的測試序列,例如:測試用例s2:opensetupAccent deposit(in