第3章 白盒測試用例設計方法

1、軟件質(zhì)量保證與測試第第3 3章章 軟件測試的方法軟件測試的方法西安財經(jīng)學院軟件質(zhì)量保證與測試第第3 3章章 軟件測試的方法軟件測試的方法3.1 邏輯覆蓋測試邏輯覆蓋測試3.2 基本路徑測試基本路徑測試3.3 循環(huán)測試循環(huán)測試3.4 代碼檢查代碼檢查3.5 小結(jié)小結(jié)軟件質(zhì)量保證與測試方法論和具體方法方法論和具體方法p 從方法論看，更多體現(xiàn)了一種哲學的思想，例如辯證統(tǒng)一的方法，在測試中有許多對立統(tǒng)一體，如靜態(tài)測試和動態(tài)測試、白盒測試和黑盒測試、自動化測試和手工測試等。p 軟件測試的方法論來源于軟件工程的方法論，例如有面向?qū)ο蟮拈_發(fā)方法，就有面向?qū)ο蟮臏y試方法；有敏捷方法，就有和敏捷方法對應的測試方

2、法。軟件質(zhì)量保證與測試黑盒子和白盒子黑盒子和白盒子功能測試功能測試數(shù)據(jù)驅(qū)動測試數(shù)據(jù)驅(qū)動測試 結(jié)構(gòu)測試結(jié)構(gòu)測試邏輯驅(qū)動測試邏輯驅(qū)動測試 客戶需求事件驅(qū)動輸入輸出軟件質(zhì)量保證與測試靜態(tài)的和動態(tài)的靜態(tài)的和動態(tài)的主持人主持人作者記錄員列席人員內(nèi)審員內(nèi)審員技術(shù)專業(yè)人員用戶代表不正式正式互審 走讀 審查會議運行程序運行程序軟件質(zhì)量保證與測試自動測試和手工測試自動測試和手工測試手工模擬用戶手工模擬用戶操作操作軟件質(zhì)量保證與測試3.1 3.1 邏輯覆蓋測試邏輯覆蓋測試3.1.1 3.1.1 語句覆蓋語句覆蓋3.1.2 3.1.2 判定覆蓋判定覆蓋3.1.3 3.1.3 條件覆蓋條件覆蓋3.1.4 3.1.4

3、判定條件覆蓋判定條件覆蓋3.1.5 3.1.5 條件組合覆蓋條件組合覆蓋3.1.6 3.1.6 路徑覆蓋路徑覆蓋軟件質(zhì)量保證與測試白盒測試方法白盒測試方法v 白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試，是針對被測單元內(nèi)部是如何進行工作的測試。它根據(jù)程序的控制結(jié)構(gòu)設計測試用例，主要用于軟件或程序驗證。v 采用白盒測試方法必須遵循以下幾條原則，才能達到測試的目的： 保證一個模塊中的所有獨立路徑至少被測試一次。 所有邏輯值均需測試真 (true) 和假 (false) 兩種情況。 檢查程序的內(nèi)部數(shù)據(jù)結(jié)構(gòu)，保證其結(jié)構(gòu)的有效性。 在上下邊界及可操作范圍內(nèi)運行所有循環(huán)。軟件質(zhì)量保證與測試白盒測試方法白盒測試方法v

4、 白盒測試法檢查程序內(nèi)部邏輯結(jié)構(gòu)，對所有邏輯路徑進行測試，是一種窮舉路徑的測試方法。但即使每條路徑都測試過了，仍然可能存在錯誤。因為： 窮舉路徑測試無法檢查出程序本身是否違反了設計規(guī)范，即程序是否是一個錯誤的程序。 窮舉路徑測試不可能查出程序因為遺漏路徑而出錯。 窮舉路徑測試發(fā)現(xiàn)不了一些與數(shù)據(jù)相關(guān)的錯誤。軟件質(zhì)量保證與測試測試覆蓋標準測試覆蓋標準軟件質(zhì)量保證與測試測試覆蓋標準測試覆蓋標準v上頁小程序的流程圖，其中包括了一個執(zhí)行達20次的循環(huán)。那么它所包含的不同執(zhí)行路徑數(shù)高達520（1013）條，若要對它進行窮舉測試，覆蓋所有的路徑。假使測試程序?qū)γ恳粭l路徑進行測試需要1毫秒，同樣假定一天工作2

5、4小時，一年工作365，那么要想把如圖所示的小程序的所有路徑測試完，則需要3170年。軟件質(zhì)量保證與測試白盒測試方法白盒測試方法v 白盒測試主要是檢查程序的內(nèi)部結(jié)構(gòu)、邏輯、循環(huán)和路徑。常用測試用例設計方法有： 邏輯覆蓋邏輯覆蓋：以程序的內(nèi)部邏輯結(jié)構(gòu)為基礎，分為語句覆蓋、判定覆蓋、條件覆蓋、判定-條件覆蓋、條件組合覆蓋等。 基本路徑測試基本路徑測試：在程序控制流程的基礎上，分析控制構(gòu)造的環(huán)路復雜性，導出基本可執(zhí)行路徑集合，從而設計測試用例。軟件質(zhì)量保證與測試例：實現(xiàn)一個簡單的數(shù)學運算例：實現(xiàn)一個簡單的數(shù)學運算v Dim a,b As Integerv Dim c As Doublev If (a

6、0 And b0) Thenv c=c/av End ifv If (a1 or c1) Thenv c=c+1v End if1. c=b+c軟件質(zhì)量保證與測試3.1.13.1.1 語句覆蓋語句覆蓋p語句覆蓋法的基本思想是設計若干測試用例，運行被測程序，使程序中的每個可執(zhí)行語句至少被執(zhí)行一次軟件質(zhì)量保證與測試續(xù)續(xù)只需設計一個測試用例: a=2，b=1，c=6；即達到了語句覆蓋。軟件質(zhì)量保證與測試續(xù)續(xù)v 【優(yōu)點】【優(yōu)點】 ：可以很直觀地從源代碼得到測試用例，無須細分每條判定表達式。v 【缺點】【缺點】 ：由于這種測試方法僅僅針對程序邏輯中顯式存在的語句，但對于隱藏的條件是無法測試的。如在多分支

7、的邏輯運算中無法全面的考慮。語句覆蓋是最弱的邏輯覆蓋。軟件質(zhì)量保證與測試3.1.23.1.2 判定覆蓋判定覆蓋p判定覆蓋法的基本思想是設計若干用例，運行被測程序，使得程序中每個判斷的取真分支和取假分支至少經(jīng)歷一次，即判斷真假值均曾被滿足。p一個判定往往代表著程序的一個分支，所以判定覆蓋也被稱為分支覆蓋。軟件質(zhì)量保證與測試續(xù)續(xù) a=2，b=1 ，c=6可覆蓋判斷M的Y分支和判斷N的Y分支； a=-2，b=-1 ，c=-3可覆蓋判斷M的N分支和判斷N的N分支 。 這兩組測試用例可覆蓋所有判定的真假分支。判斷M判斷N軟件質(zhì)量保證與測試續(xù)續(xù) a=1，b=1 ，c=-3 可覆蓋判斷M的Y分支和判斷N的N

8、分支 ； a=1，b=-2 ，c=3可覆蓋判斷M的N分支和判斷N的Y分支 ； 同樣的這兩組測試用例也可覆蓋所有判定的真假分支。判斷M判斷N軟件質(zhì)量保證與測試續(xù)續(xù)v 【優(yōu)點】【優(yōu)點】：判定覆蓋具有比語句覆蓋更強的測試能力。同樣判定覆蓋也具有和語句覆蓋一樣的簡單性，無須細分每個判定就可以得到測試用例。v 【缺點】【缺點】：往往大部分的判定語句是由多個邏輯條件組合而成，若僅僅判斷其整個最終結(jié)果，而忽略每個條件的取值情況，必然會遺漏部分測試路徑。判定覆蓋仍是弱的邏輯覆蓋。軟件質(zhì)量保證與測試3.1.33.1.3 條件覆蓋條件覆蓋p條件覆蓋的基本思想是設計若干測試用例，執(zhí)行被測程序以后，要使每個判斷中每個

9、條件的可能取值至少滿足一次。result=maxint（iN) and (result=maxint)TrueFalsei0 取真 記為 T1 取假 記為 F1 條件 b0 取真 記為 T2 取假 記為 F2v 判斷Q表達式:設條件 a1 取真 記為 T3 取假 記為 F3 條件 c1 取真 記為 T4 取假 記為 F4判斷M判斷N軟件質(zhì)量保證與測試續(xù)續(xù)它覆蓋了判定M的N分支和判斷N的Y分支。我們用條件覆蓋設計的思想就是讓測試用例能覆蓋T1、T2、T3、T4、F1、F2、F3、F4判斷M判斷N軟件質(zhì)量保證與測試續(xù)續(xù)v 【優(yōu)點】【優(yōu)點】：增加了對條件判定情況的測試，增加了測試路徑。v 【缺點】【

10、缺點】：條件覆蓋不一定包含判定覆蓋。例如，我們剛才設計的用例就沒有覆蓋判斷M的Y分支和判斷N的N分支。條件覆蓋只能保證每個條件至少有一次為真，而不考慮所有的判定結(jié)果。軟件質(zhì)量保證與測試3.1.43.1.4 判定條件覆蓋判定條件覆蓋p判定-條件覆蓋是判定和條件覆蓋設計方法的交集，即設計足夠的測試用例，使得判斷條件中的所有條件可能取值至少執(zhí)行一次，同時，所有判斷的可能結(jié)果至少執(zhí)行一次軟件質(zhì)量保證與測試判斷M判斷N續(xù)續(xù)按照判定條件覆蓋的要求，我們設計的測試用例要滿足如下條件：1.所有條件可能至少執(zhí)行一次取值；2.2.所有判斷的可能結(jié)果至少執(zhí)行一次。所有判斷的可能結(jié)果至少執(zhí)行一次。要滿足要滿足T1、T

11、2、 T3 、T4F1、 F2 、F3、F4軟件質(zhì)量保證與測試續(xù)續(xù)判斷M判斷N要滿足要滿足T1、T2、 T3 、T4F1、 F2 、F3、F4軟件質(zhì)量保證與測試續(xù)續(xù)v 【優(yōu)點】【優(yōu)點】 ：能同時滿足判定、條件兩種覆蓋標準。v 【缺點】【缺點】 ：判定/條件覆蓋準則的缺點是未考慮條件的組合情況。軟件質(zhì)量保證與測試3.1.53.1.5 條件組合覆蓋條件組合覆蓋p條件組合覆蓋的基本思想是設計足夠的測試用例，使得程序中每個判斷的所有可能的條件取值組合都至少出現(xiàn)一次。p它與條件覆蓋的差別是它不是簡單地要求每個條件都出現(xiàn)“真”與“假”兩種結(jié)果，而是要求讓這些結(jié)果的所有可能組合都至少所有可能組合都至少出現(xiàn)一

12、次。出現(xiàn)一次。軟件質(zhì)量保證與測試續(xù)續(xù)v 按照條件組合覆蓋的基本思想，對于前面的例子，我們把每個判斷中的所有條件進行組合，設計組合條件如表所示，而我們設計的測試用例就要包括所有的組合條件。軟件質(zhì)量保證與測試續(xù)續(xù)覆蓋了所有組合，但覆蓋路徑有限，1-2-5 沒被覆蓋軟件質(zhì)量保證與測試續(xù)續(xù)要滿足要滿足1、2、3、4、5、6、7、8條件組合條件組合軟件質(zhì)量保證與測試續(xù)續(xù)v 【優(yōu)點】【優(yōu)點】：條件組合覆蓋準則滿足判定覆蓋、條件覆蓋和判定/條件覆蓋準則。v 【缺點】【缺點】：線性地增加了測試用例的數(shù)量。軟件質(zhì)量保證與測試3.1.63.1.6覆蓋覆蓋p顧名思義，路徑覆蓋就是設計所有的測試用例，來覆蓋程序中的所

13、有可能的執(zhí)行路徑。軟件質(zhì)量保證與測試續(xù)續(xù)軟件質(zhì)量保證與測試續(xù)續(xù)v 【優(yōu)點】【優(yōu)點】 ：這種測試方法可以對程序進行徹底的測試，比前面五種的覆蓋面都廣。v 【缺點】【缺點】 ：需要設計大量、復雜的測試用例，使得工作量呈指數(shù)級增長，不見得把所有的條件組合都覆蓋。軟件質(zhì)量保證與測試 從前面的例子我們可以看到，采用任何一種覆蓋方法都不能滿足我們的要求，所以，在實際的測試用例設計過程中，可以根據(jù)需要將不同的覆蓋方法組合起來使用，以實現(xiàn)最佳的測試用例設計 。軟件質(zhì)量保證與測試邏輯覆蓋法邏輯覆蓋法v 根據(jù)覆蓋目標的不同，邏輯覆蓋又可分為語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、組合覆蓋和路徑覆蓋。 語句覆

14、蓋：選擇足夠多的測試用例，使得程序中的每個可執(zhí)行語句至少執(zhí)行一次。 判定覆蓋：通過執(zhí)行足夠的測試用例，使得程序中的每個判定至少都獲得一次“真”值和“假”值， 也就是使程序中的每個取“真”分支和取“假”分支至少均經(jīng)歷一次，也稱為“分支覆蓋”。 條件覆蓋：設計足夠多的測試用例，使得程序中每個判定包含的每個條件的可能取值（真/假）都至少滿足一次。軟件質(zhì)量保證與測試邏輯覆蓋法（續(xù)）邏輯覆蓋法（續(xù)） 判定/條件覆蓋：設計足夠多的測試用例，使得程序中每個判定包含的每個條件的所有情況（真/假）至少出現(xiàn)一次，并且每個判定本身的判定結(jié)果（真/假）也至少出現(xiàn)一次。 滿足判定/條件覆蓋的測試用例一定同時滿足判定覆蓋

15、和條件覆蓋。 組合覆蓋：通過執(zhí)行足夠的測試用例，使得程序中每個判定的所有可能的條件取值組合都至少出現(xiàn)一次。 滿足組合覆蓋的測試用例一定滿足判定覆蓋、條件覆蓋和判定/條件覆蓋。 路徑覆蓋：設計足夠多的測試用例，要求覆蓋程序中所有可能的路徑。 軟件質(zhì)量保證與測試3.2 3.2 基本路徑測試基本路徑測試v 程序流程圖又稱框圖，是我們最熟悉，也是最容易理解的一種程序控制結(jié)構(gòu)的圖形表示了。在這種圖上的框里面常常標明了處理要求或者條件，但是，這些標注在做路徑分析時是不重要的。為了了更加突出控制流的結(jié)構(gòu)，需要對程序流程圖做一些簡化。v 控制流圖（可簡稱流圖）是對程序流程圖進行簡化后得到的，它可以更加突出的表

16、示程序控制流的結(jié)構(gòu)。v 控制流圖中包括兩種圖形符號：節(jié)點和控制流線。 節(jié)點由帶標號的圓圈表示，可代表一個或多個語句、一個處理框序列和一個條件判定框（假設不包含復合條件）。 控制流線由帶箭頭的弧或線表示，可稱為邊。它代表程序中的控制流。軟件質(zhì)量保證與測試續(xù)續(xù)在控制流圖中只有兩種圖形符號，它們是：1.節(jié)點：以標有編號的圓圈表示。它代表了程序流程圖中矩形框表示的處理、菱形表示的兩個到多個出口判斷以及兩條到多條流線相交的匯合點。2.控制流線或?。阂约^表示。它與程序流程圖中的流線是一致的，表明了控制的順序。為了方便討論，控制流線通常標有名字，如圖中所標的a、b、c等。在下圖中，給出了簡化的例子。其中（

17、a）圖示一個含有兩個出口判斷和循環(huán)的程序流程圖，我們把它簡化成（b）的形式，稱這種簡化了的程序流程圖叫做控制流圖。 （a） （b）軟件質(zhì)量保證與測試基本路徑測試法基本路徑測試法1.依據(jù)代碼繪制流程圖2.確定流程圖的圈復雜度（cyclomatic complexity ）3.確定線性獨立路徑的基本集合( basis set )4.設計測試用例覆蓋每條基本路徑軟件質(zhì)量保證與測試示例示例 源代碼源代碼Procedure: process records1.Do While records remain2.Read record;3.If record field 1 = 0 Then4.store

18、in buffer;5.increment counter;6.Else If record field 2 = 0 Then7.reset counter;8.Else store in file;9.End If10.End If11. End DoEnd軟件質(zhì)量保證與測試示例示例 流程圖流程圖1910112457836V(G) = 4軟件質(zhì)量保證與測試基本路徑測試基本路徑測試:流程圖簡化流程圖簡化12,387694,51011有的時候，我們可以把幾個節(jié)點合并成一個，合并的原則是：若在一個節(jié)點序列中沒有分支，則我們可以把這個序列的節(jié)點都合并成一個節(jié)點。軟件質(zhì)量保證與測試流程圖的圈復雜度流程

19、圖的圈復雜度 V(G) = 區(qū)域數(shù)量(由節(jié)點、連線包圍的區(qū)域，包括圖形外部區(qū)域) V(G) = 連線數(shù)量 - 節(jié)點數(shù)量 + 2 V(G) = 簡單可預測節(jié)點數(shù)量 + 1圈復雜度（圈復雜度（Cyclomatic complexityCyclomatic complexity）: :代碼邏輯復雜度的 度量，提供了被測代碼的路徑數(shù)量。復雜度越高，出錯的概率越大。V(G)modules軟件質(zhì)量保證與測試流程圖復雜度例子流程圖復雜度例子V(G)=412,378694,51011Region 1Region 2Region 3Region 4軟件質(zhì)量保證與測試確定線性獨立的路徑集合確定線性獨立的路徑集合

20、獨立路徑獨立路徑： 至少引入一系列新的處理語句或條件的任何路徑 基本集基本集： 由獨立路徑構(gòu)成的集合 由基本集導出的測試用例測試用例，保證每行代碼語句至少被執(zhí)行一次 基本集合基本集合不一定唯一軟件質(zhì)量保證與測試 Path1: 1-2-3-6-7-9-10-1-11示例：基本路徑測試用例示例：基本路徑測試用例 Path2: 1-2-3-6-8-9-10-1-11 Path3: 1-2-3-4-5-10-1-11Path4: 1-111910112458736軟件質(zhì)量保證與測試測試用例覆蓋集合中每條路徑測試用例覆蓋集合中每條路徑基本路徑測試并不是測試所有路徑的組合，僅僅保證每條基本路徑被執(zhí)行一次

21、不需要活動圖, 但最好繪制程序流程圖 計算每個邏輯測試，也就是布爾操作符數(shù)加1 最好每個單元都進行基本路徑測試，對關(guān)鍵組件則是必要的軟件質(zhì)量保證與測試3.3 循環(huán)測試循環(huán)測試v簡單循環(huán)v串接循環(huán)v嵌套循環(huán)v復雜循環(huán)軟件質(zhì)量保證與測試n目標: 在循環(huán)內(nèi)部及邊界上執(zhí)行測試循環(huán)測試循環(huán)測試 1 11.簡單循環(huán)簡單循環(huán)(迭代次數(shù)n) 完全跳過循環(huán) 只經(jīng)過循環(huán)一次 經(jīng)過循環(huán)兩次 經(jīng)過循環(huán)m（ m n ）次 分別經(jīng)過循環(huán)n-1, n, n+1 次軟件質(zhì)量保證與測試循環(huán)測試循環(huán)測試 2 22. 2. 嵌套嵌套（Nested）循環(huán)循環(huán)在最里面的循環(huán)完成前面所述的簡單循環(huán)測試，同時設定外部循環(huán)的最小迭代次數(shù)逐步

22、向外循環(huán)進行直到所有循環(huán)被測試軟件質(zhì)量保證與測試循環(huán)測試循環(huán)測試 3 34.4.其它非結(jié)構(gòu)循環(huán)其它非結(jié)構(gòu)循環(huán)重新設計重新設計! !3.3.串行連接的循環(huán)串行連接的循環(huán)獨立循環(huán) 可以分別看著簡單循環(huán)測試依賴性循環(huán) 可以看著是嵌套循環(huán)軟件質(zhì)量保證與測試靜態(tài)測試定義靜態(tài)測試定義v靜態(tài)測試不實際運行軟件，主要對軟件的編程格式、結(jié)構(gòu)等方面進行評估。v可以有人工進行，充分發(fā)揮人的邏輯思維優(yōu)勢，也可以借助軟件工具自動進行。軟件質(zhì)量保證與測試 靜態(tài)測試的方法靜態(tài)測試的方法u代碼檢查 代碼審查 代碼走查 桌面檢查 同行評分（略）u靜態(tài)結(jié)構(gòu)分析u代碼質(zhì)量度量軟件質(zhì)量保證與測試3.4 代碼檢查代碼檢查3.4.1 代

23、碼審查v以組為單位閱讀代碼，是一系列規(guī)程和錯誤檢查技術(shù)的集合。v通常由4人組成，其中一人是協(xié)調(diào)人，一人是程序的編寫者，其他人員通常是程序的設計人員以及測試專家軟件質(zhì)量保證與測試協(xié)調(diào)人的職責？協(xié)調(diào)人的職責？v為代碼檢查分發(fā)材料、安排進程v在代碼檢查中起主導作用v記錄發(fā)現(xiàn)的所有錯誤v確保所有錯誤隨后得到改正軟件質(zhì)量保證與測試代碼審查活動安排代碼審查活動安排v在審查的前幾天，協(xié)調(diào)人將程序清單和設計規(guī)范分發(fā)給其他成員。所有成員在檢查之前熟悉這些材料。v審查時，由編碼人員逐條語句講述程序的邏輯結(jié)構(gòu)。在講述的過程當中，小組的其他成員提問題、判斷是否存在錯誤。v對照歷來常見的編碼錯誤列表分析程序軟件質(zhì)量保證

24、與測試注意事項注意事項v協(xié)調(diào)人負責保證會的討論高效的進行，每個參與者都將注意力集中在查找錯誤而不是修正錯誤v會后要確保錯誤得到修正v對錯誤清單要分析、歸納，用以提煉錯誤列表v會議時間在90-120分鐘，不間斷v每小時大約閱讀150行代碼，不要過多軟件質(zhì)量保證與測試代碼審查的作用？代碼審查的作用？v發(fā)現(xiàn)錯誤v程序員會在編程風格、算法選擇及編程技術(shù)等方面得到反饋v其他參與者通過他人的錯誤、風格等受益匪淺v能夠較早的發(fā)現(xiàn)程序中容易出錯的部分，為后面的測試找到側(cè)重點軟件質(zhì)量保證與測試用于代碼審查的錯誤列表用于代碼審查的錯誤列表-part11.是否有引用的變量未賦值或初始化2.下標的值是否在范圍之內(nèi)3.

25、是否存在非整數(shù)下標4.是否存在虛調(diào)用(dangling reference)對于所有的通過指針或引用變量的引用,當前引用的內(nèi)存單元是否分配?5.當使用別名時屬性是否匹配6.記錄和結(jié)構(gòu)的屬性是否匹配,即變量值的類型或?qū)傩允欠衽c編譯器所預期的一致7.是否計算位串的地址?是否傳遞位串參數(shù)?8.基礎的存儲屬性是否正確9.跨過程的結(jié)構(gòu)定義是否匹配10.索引或下標操作是否有”僅差一個”的錯誤11. 繼承需求是否得到滿足軟件質(zhì)量保證與測試v 運算錯誤：運算錯誤：1 1是否存在非算術(shù)變量間的運算？是否存在非算術(shù)變量間的運算？2 2是否存在混合模式的運算？是否存在混合模式的運算？3 3是否存在不同字長變量間的運

26、算？是否存在不同字長變量間的運算？4 4目標變量的大小是否小于賦值大??？目標變量的大小是否小于賦值大小？5 5中間結(jié)果是否上溢或下溢？中間結(jié)果是否上溢或下溢？6 6是否存在被是否存在被0 0除？除？7 7是否存在二進制的不精確度？是否存在二進制的不精確度？8 8變量的值是否超過了有意義的范圍？變量的值是否超過了有意義的范圍？9 9操作符的優(yōu)先順序是否被正確理解？操作符的優(yōu)先順序是否被正確理解？10. 10. 整數(shù)除法是否正確？整數(shù)除法是否正確？用于代碼審查的錯誤列表用于代碼審查的錯誤列表-part2軟件質(zhì)量保證與測試v數(shù)據(jù)聲明錯誤：1.是否所有的變量都已聲明？2.默認的屬性是否被正確理解？3.

27、數(shù)組和字符串的初始化是否正確？4.變量是否賦予了正確的長度、類型和存儲類？5.初始化是否與存儲類相一致？6.是否有相似的變量名？軟件質(zhì)量保證與測試v比較錯誤：1.是否存在不同類型變量間的比較？2.是否存在混合模式的比較運算？3.比較運算符是否正確？4.布爾表達式是否正確？ 5.比較運算是否與布爾表達式相混合？6.是否存在二進制小數(shù)的比較？7.操作符的優(yōu)先順序是否被正確理解？8.編譯器對布爾表達式的計算方式是否被正確理解？軟件質(zhì)量保證與測試v控制流程錯誤：1.是否超出了多條分支路徑？2.是否每個循環(huán)都終止了？3.是否每個程序都終止了？4.是否存在由于入口條件不滿足而跳過循環(huán)體？5.可能的循環(huán)越界

28、是否正確？6.是否存在“僅差一個”的迭代錯誤？7.DO/END語句是否匹配？8.是否存在不能窮盡的判斷？9.輸出信息中是否有文字或語法錯誤？軟件質(zhì)量保證與測試v輸入/輸出錯誤：1.文件屬性是否正確？2.OPEN語句是否正確？3.I/O語句是否符合格式規(guī)范？4.緩沖大小與記錄大小是否匹配？5.文件在使用前是否打開？6.文件在使用后是否關(guān)閉？7.文件結(jié)束條件是否被正確處理？8.是否處理了I/O錯誤？軟件質(zhì)量保證與測試v 接口錯誤：1.形參的數(shù)量是否等于實參的數(shù)量？2.形參的屬性是否與實參的屬性相匹配？3.形參的量綱是否與實參的量綱相匹配？4.傳遞給被調(diào)用模塊的實參個數(shù)是否等于其形參個數(shù)？5.傳遞給

29、被調(diào)用模塊的實參屬性是否與其形參屬性匹配？6.傳遞給被調(diào)用模塊的實參量綱是否與其形參量綱匹配？7.調(diào)用內(nèi)部函數(shù)的實參的數(shù)量、屬性、順序是否正確？8.是否引用了與當前入口點無關(guān)的形參？9.是否改變了某個原本僅為輸入值的形參？10.全局變量的定義在模塊間是否一致？11.常數(shù)是否以實參形式傳遞過？軟件質(zhì)量保證與測試3.3.2 代碼走查代碼走查v人員：協(xié)調(diào)人、秘書、測試人員、程序員等。v區(qū)別：不同于僅閱讀程序或使用錯誤列表，代碼走查的參與者“使用了計算機”，被指定為測試員的人會帶著一些書面的測試用例參加會議。v每個測試用例都在人們腦中進行推演，程序狀態(tài)記錄在紙上。v提供了啟動代碼走查和質(zhì)疑程序員邏輯思

30、路及其設想的手段軟件質(zhì)量保證與測試3.4.3 桌面檢查桌面檢查v由一個人閱讀程序，對照錯誤列表檢查程序，對程序推測測試數(shù)據(jù)，可視為由單人進行的代碼檢查或代碼走查。v效率非常低，why?（1）完全沒有約束）完全沒有約束（2）開發(fā)人員測試自己的程序）開發(fā)人員測試自己的程序（3）沒有展示自己能力，缺乏良好的效應）沒有展示自己能力，缺乏良好的效應結(jié)論：桌面檢查勝于沒有檢查，但其效果遠遠遜于代碼審結(jié)論：桌面檢查勝于沒有檢查，但其效果遠遠遜于代碼審查和代碼走查查和代碼走查軟件質(zhì)量保證與測試2.2靜態(tài)結(jié)構(gòu)分析靜態(tài)結(jié)構(gòu)分析v 靜態(tài)結(jié)構(gòu)分析主要是以圖形的方式表現(xiàn)程序的內(nèi)部結(jié)構(gòu)。 例如函數(shù)調(diào)用關(guān)系圖、函數(shù)內(nèi)部控制

31、流圖。其中： 函數(shù)調(diào)用關(guān)系圖以直觀的圖形方式描述一個應用程序中各個函數(shù)的調(diào)用和被調(diào)用關(guān)系； 控制流圖顯示一個函數(shù)的邏輯結(jié)構(gòu)，由許多節(jié)點組成，一個節(jié)點代表一條語句或數(shù)條語句，連接結(jié)點的叫邊，邊表示節(jié)點間的控制流向。軟件質(zhì)量保證與測試2.3代碼質(zhì)量度量代碼質(zhì)量度量根據(jù)ISO/IEC9126國際標準的定義，軟件質(zhì)量包括六個方面：v功能性(functionality)v可靠性(reliability)v可用性(usability)v有效性(efficiency)v可維護性(maintainability)v輕便性(portability)軟件的質(zhì)量是軟件屬性的各種標準度量的組合。？軟件質(zhì)量保證與測試3.5.3 3.5.3 基于模型的軟件測試基于模型的軟件測試v 基于模型的測試（Model-based testing，MBT）是利用模型來生成相應的測試用例，然后根據(jù)實際結(jié)果和原先預想的結(jié)果的差異來測試系統(tǒng)v 先從概念上形成模型，然后試圖用數(shù)學的方法來描述這個模型，形成仿真模型，完成所需的測試軟件質(zhì)量保證與測試MBTMBT的優(yōu)缺點的優(yōu)缺點v 測試效率高v 對邏輯復雜故障測試效果好v 容易實現(xiàn)自動化測試優(yōu)點優(yōu)點缺點缺點n誤報問題誤報問題n漏報問題漏報問題n模型機理模型機理軟件質(zhì)量保證與測試軟件測試模型軟件測試模型v 故