軟件工程第11章 軟件測試

軟件工程第11章軟件測試2/161內容摘要軟件測試基礎白盒測試黑盒測試測試策略面向對象測試測試完成標準調試3/161內容摘要軟件測試基礎白盒測試黑盒測試測試策略面向對象測試測試完成標準調試4/161軟件測試基礎軟件測試的目的軟件測試的基本原則白盒測試和黑盒測試5/161有關軟件測試的錯誤觀點“軟件測試是為了證明程序是正確的，即測試能發(fā)現程序中所有的錯誤”。事實上這是不可能的。要通過測試發(fā)現程序中的所有錯誤，就要窮舉所有可能的輸入數據。對于一個輸入三個16位字長的整型數據的程序，輸入數據的所有組合情況有248

3*1014，如果測試一個數據需1ms，則即使一年365天一天24小時不停地測試，也需要約1萬年。6/161對一個具有多重選擇和循環(huán)嵌套的程序，不同的路徑數目可能是天文數字。例如一個小程序的流程圖，它包括了一個執(zhí)行20次的循環(huán)，其循環(huán)體有五個分支。這個循環(huán)的不同執(zhí)行路徑數達520條，如果對每一條路徑進行測試需要1毫秒，那么即使一年工作365×24小時，要想把所有路徑測試完，大約需3170年。7/1618/161“程序測試是證明程序正確地執(zhí)行了預期的功能”。實際上，一個程序不僅要完成它所需完成的功能，而且不應完成它不該做的事。如不能把邊長為0、0、0的三條邊判斷為等邊三角形。9/161軟件測試的目的GlenMyers給出的軟件測試目的：測試是一個為了發(fā)現錯誤而執(zhí)行程序的過程一個好的測試用例是指很可能找到迄今為至尚未發(fā)現的錯誤的測試用例一個成功的測試是指揭示了迄今為至尚未發(fā)現的錯誤的測試根據這個測試目的，我們應該排除對測試的錯誤觀點，設計合適的測試用例，用盡可能少的測試用例，來發(fā)現盡可能多的軟件錯誤。10/161軟件測試的原則Davis提出了一組指導軟件測試的基本原則：1.所有的測試都應可追溯到客戶需求2.應該在測試工作真正開始前的較長時間就進行測試計劃3.Pareto原則：測試中發(fā)現的80%的錯誤可能來自于20%的程序代碼4.測試應從“小規(guī)?！遍_始，逐步轉向“大規(guī)?！?.窮舉測試是不可能的6.為了達到最有效的測試，應由獨立的第三方來承擔測試11/161其他的測試原則：1.在設計測試用例時，應包括合理的輸入條件和不合理的輸入條件2.嚴格執(zhí)行測試計劃，排除測試的隨意性3.應當對每一個測試結果做全面檢查4.妥善保存測試計劃、測試用例、出錯統(tǒng)計和最終分析報告，為維護提供方便5.檢查程序是否做了應做的事僅是成功的一半，另一半是檢查程序是否做了不該做的事6.在規(guī)劃測試時不要設想程序中不會查出錯誤12/161白盒測試與黑盒測試測試用例的設計是軟件測試的關鍵所在設計盡可能少的測試用例來發(fā)現盡可能多的錯誤設計最有可能發(fā)現軟件錯誤的測試用例，同時避免使用發(fā)現錯誤效果相同的測試用例測試用例的設計方法大體可分為兩類：白盒測試和黑盒測試，也稱白箱測試和黑箱測試13/161白盒測試（又稱為結構測試）把測試對象看作一個透明的盒子，測試人員根據程序內部的邏輯結構及有關信息設計測試用例，檢查程序中所有邏輯路徑是否都按預定的要求正確地工作。白盒測試主要用于對模塊的測試，包括：程序模塊中的所有獨立路徑至少執(zhí)行一次對所有邏輯判定的取值（“真”與“假”）都至少測試一次在上下邊界及可操作范圍內運行所有循環(huán)測試內部數據結構的有效性等14/161黑盒測試（又稱行為測試）把測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能需求。黑盒測試可用于各種測試，它試圖發(fā)現以下類型的錯誤：不正確或遺漏的功能接口錯誤，如輸入/輸出參數的個數、類型等數據結構錯誤或外部信息(如外部數據庫)訪問錯誤性能錯誤初始化和終止錯誤15/161內容摘要軟件測試基礎白盒測試黑盒測試測試策略面向對象測試測試完成標準調試16/161白盒測試常用的白盒測試方法有：邏輯覆蓋測試基本路徑覆蓋測試數據流測試循環(huán)測試17/161邏輯覆蓋測試

語句覆蓋判定覆蓋條件覆蓋

判定－條件覆蓋條件組合覆蓋路徑覆蓋邏輯覆蓋主要考察使用測試數據運行被測程序時對程序邏輯的覆蓋程度。通常希望選擇最少的測試用例來滿足所需的覆蓋標準。主要的覆蓋標準有：18/161例：對下列子程序進行測試procedureexample(y,z:real;varx:real);beginif(y>1)and(z=0)thenx:=x/y;if(y=2)or(x>1)thenx:=x+1;end;

該子程序接受x、y、z的值，并將計算結果x的值返回給調用程序。與該子程序對應的流程圖如下：19/161入口s(y>1)and(z=0)a(y=2)or(x>1)c返回ebx=x/yftdx=x+1ft20/161該子程序有兩個判定：a:(y>1)and(z=0)c:(y=2)or(x>1)判定a中有兩個判定條件：y>1、z=0判定c中有兩個判定條件：y=2、“x>1”

根據程序的執(zhí)行流程不同，判定c中的“x>1”的含義也不同。當判定a為“真”時，

“x>1”實際是“x/y>1”，即“x>y”；當判定a為“假”時，

“x>1”仍是“x>1”。21/161該子程序有四條可執(zhí)行路徑：路徑1sabcde

，其執(zhí)行條件（L1）是a為“t”且c為“t”L1={(y>1)and

(z=0)}and{(y=2)or

(x/y>1)}=(y>1)and(z=0)and(y=2)or(y>1)and(z=0)and(x>y)=(y=2)and

(z=0)

or

(y>1)and(z=0)and

(x>y)seacbdtffta:(y>1)and(z=0)c:(y=2)or(x>1)22/161路徑2sace，其執(zhí)行條件（L2）是a為“f”且c為“f”)L2=not{(y>1)and(z=0)}

and

not{(y=2)or(x>1)}={not(y>1)ornot(z=0)}and

{

not(y=2)andnot(x>1)}=

not(y>1)andnot(y=2)andnot(x>1)

or

not(z=0)andnot(y=2)andnot(x>1)=(y≤1)and(y≠2)and(x≤1)

or

(z≠0)and(y≠2)and(x≤1)seacbdtffta:(y>1)and(z=0)c:(y=2)or(x>1)23/161路徑3sacde，其執(zhí)行條件（L3）是a為“f”且c為“t”)L3=not{(y>1)

and(z=0)}and

{(y=2)or(x>1)}={not(y>1)ornot(z=0)}and

{(y=2)or(x>1)}=not(y>1)and(y=2)or

not(y>1)and(x>1)or

not(z=0)and(y=2)ornot(z=0)and(x>1)=(y≤1)and(y=2)or

(y≤1)and(x>1)

or

(z≠0)

and(y=2)

or(z≠0)and(x>1)seacbdtffta:(y>1)and(z=0)c:(y=2)or(x>1)24/161路徑4sabce，其執(zhí)行條件（L4）是a為“t”且c為“f”)L4={(y>1)and

(z=0)}

and

not

{(y=2)or(x/y>1)}=(y>1)and(z=0)andnot

(y=2)andnot(x>y)=(y>1)and(z=0)and(y≠2)and

(x≤y)seacbdtffta:(y>1)and(z=0)c:(y=2)or(x>1)25/161語句覆蓋

語句覆蓋是指選擇足夠的測試用例，使得運行這些測試用例時，被測程序的每個可執(zhí)行語句都至少執(zhí)行一次欲使每個語句都執(zhí)行一次，只需執(zhí)行路徑L1（sabcde）即可。

L1=(y=2)and

(z=0)or

(y>1)and(z=0)and(x>y)測試用例如下：測試數據預期結果x=4,y=2,z=0x=3seacbdtffta:(y>1)and(z=0)c:(y=2)or(x>1)26/161判定覆蓋

判定覆蓋（也稱分支覆蓋）是指選擇足夠的測試用例，使得運行這些測試用例時，被測程序的每個判定的所有可能結果都至少執(zhí)行一次（即判定的每個分支至少經過一次）

27/161欲使每個分支都執(zhí)行一次，只需執(zhí)行路徑L3（sacde，a為“f”且c為“t”）和L4（sabce，a為“t”且c為“f”）即可。或者，執(zhí)行路徑L1（sabcde，a為“t”且c為“t”）和L2（sace，a為“f”且c為“f”）.seacbdtffta:(y>1)and(z=0)c:(y=2)or(x>1)28/161L3（sacde，a為“f”且c為“t”）：(y≤1)and(y=2)or

(y≤1)and(x>1)

or

(z≠0)and(y=2)

or(z≠0)and(x>1)L4（sabce，a為“t”且c為“f”）：(y>1)and(z=0)and(y≠2)and

(x≤y)seacbdtffta:(y>1)and(z=0)c:(y=2)or(x>1)測試數據預期結果路徑acx=1,y=2,z=1x=2sacdeftx=3,y=3,z=0x=1sabcetf29/161

判定覆蓋將每個判定的所有可能結果都至少執(zhí)行一次，所以，程序中的所有語句也必定都至少執(zhí)行一次。因此，滿足判定覆蓋標準的測試用例也一定滿足語句覆蓋標準。

30/161條件覆蓋

條件覆蓋是指選擇足夠的測試用例，使得運行這些測試用例時，被測程序的每個判定中的每個條件的所有可能結果都至少出現一次

31/161判定a中各種條件的所有可能結果：y>1，y≤1，z=0，z≠0。判定c中各種條件的所有可能結果：y=2，y≠2，x>1（或x>y），x≤1

（或x≤y）。seacbdtffta:(y>1)and(z=0)c:(y=2)or(x>1)測試數據預期結果路徑覆蓋的條件x=1,y=2,z=0x=1.5sabcdey>1，z=0，y=2，x≤yx=2,y=1,z=1x=3sacdey≤1，z≠0，y≠2

，x>132/161

條件覆蓋通常比判定覆蓋強，但有時雖然每個條件的所有可能結果都出現過，但判定表達式的某些可能結果并未出現。上面的二個測試用例滿足了條件覆蓋標準，但判定c為“假”的結果并未出現。33/161判定/條件覆蓋

判定/條件覆蓋是指選擇足夠的測試用例，使得運行這些測試用例時，被測程序的每個判定的所有可能結果都至少執(zhí)行一次，并且，每個判定中的每個條件的所有可能結果都至少出現一次

顯然，滿足判定/條件覆蓋標準的測試用例一定也滿足判定覆蓋、條件覆蓋、語句覆蓋標準。

34/161seacbdtffta:(y>1)and(z=0)c:(y=2)or(x>1)測試數據預期結果路徑ac覆蓋的條件x=4,y=2,z=0x=3sabcdetty>1，z=0，y=2，x>yx=1,y=1,z=1x=1saceffy≤1，z≠0，y≠2

，x≤135/161條件組合覆蓋

條件組合覆蓋是指選擇足夠的測試用例，使得運行這些測試用例時，被測程序的每個判定中條件結果的所有可能組合都至少出現一次

顯然，滿足條件組合覆蓋標準的測試用例一定也滿足判定覆蓋、條件覆蓋、判定/條件覆蓋、語句覆蓋標準。

36/161判定a中條件結果的所有可能組合：①y>1，z=0;②y>1，z≠0;③y≤1，z=0;④y≤1，z≠0判定c中條件結果的所有可能組合：⑤

y=2，x>1;⑥y=2，x≤1;⑦y≠2，x>1;⑧y≠2，x≤1seacbdtffta:(y>1)and(z=0)c:(y=2)or(x>1)37/161測試數據預期結果路徑ac覆蓋的條件x=4,y=2,z=0x=3sabcdett①y>1，z=0⑤y=2，x>yx=1,y=2,z=1x=2sacdeft②y>1，z≠0⑥y=2，x≤1x=2,y=1,z=0x=3sacdeft③y≤1，z=0⑦y≠2，x>1x=1,y=1,z=1x=1saceff④y≤1，z≠0⑧y≠2，x≤1seacbdtffta:(y>1)and(z=0)c:(y=2)or(x>1)38/161

條件組合覆蓋是上述五種覆蓋標準中最強的一種，然而，條件組合覆蓋仍不能保證程序中所有可能的路徑都被覆蓋。本例中，滿足條件組合覆蓋標準的測試用例就沒有經過sabce路徑。39/161路徑覆蓋

路徑覆蓋是指選擇足夠的測試用例，使得運行這些測試用例時，被測程序的每條可能執(zhí)行到的路徑都至少經過一次（如果程序中包含環(huán)路，則要求每條環(huán)路至少經過一次）

40/161本例中所有可能執(zhí)行的路徑有：L1(sabcde

，a為“t”且c為“t”)=(y=2)and(z=0)

or

(y>1)and(z=0)and(x>y)L2(sace，a為“f”且c為“f”)=(y≤1)and(y≠2)and(x≤1)

or

(z≠0)and(y≠2)and(x≤1)L3(sacde，a為“f”且c為“t”)=(y≤1)and(y=2)or

(y≤1)and(x>1)

or

(z≠0)and(y=2)

or(z≠0)and(x>1)L4(sabce，a為“t”且c為“f”)=(y>1)and(z=0)and(y≠2)and(x≤y)seacbdtffta:(y>1)and(z=0)c:(y=2)or(x>1)41/161seacbdtffta:(y>1)and(z=0)c:(y=2)or(x>1)測試數據預期結果路徑acx=4,y=2,z=0x=3sabcdettx=3,y=3,z=0x=1sabcetfx=2,y=1,z=0x=3sacdeftx=1,y=1,z=1x=1saceff42/161

路徑覆蓋實際上考慮了程序中各種判定結果的所有可能組合，但它未必能覆蓋判定中條件結果的各種可能情況。因此，它是一種比較強的覆蓋標準，但不能替代條件覆蓋和條件組合覆蓋標準。43/16144/161邏輯表達式錯誤敏感的測試邏輯覆蓋測試依賴于程序中的邏輯條件，這些邏輯條件由邏輯表達式組成。對于一個含有n個邏輯變量，或n個關系表達式的邏輯表達式，通常需要2n個測試用例來覆蓋其所有可能的條件組合。當n較大時，我們可以選擇對發(fā)現邏輯表達式錯誤比較敏感的組合條件進行測試，以較少的測試用例來發(fā)現邏輯表達式中的絕大多數錯誤。45/161Tai提出的分支與關系運算符（branchandrelationaloperator，BRO）測試技術能用較少的測試用例發(fā)現條件中分支與關系運算符的大多數錯誤。采用BRO方法的前提條件：條件中的每個布爾變量和關系運算符至多出現一次，并且無公共變量。BRO方法引入條件約束的概念，含有n個簡單條件Ci的復合條件C的約束D表示為（D1，D2，…Dn），Di（0<i

n）表示在Ci的輸出（outcome）上的約束，它一般是某種符號。46/161對布爾表達式，約束為t或f（真、假）；對關系表達式，約束為、、=。符合條件C的一次執(zhí)行覆蓋條件約束D是指，C中出現的每個簡單條件Ci在這次執(zhí)行中都滿足D中對應的約束Di。下面分三種情況討論：若條件為C1：B1&B2

其中B1、B2為布爾變量，C1的約束具有形式（D1，D2），D1和D2為t或f。則C1可能的三種約束為{（t，t）,（f，t），（t，f）}。對其中的每一組設計一組測試用例。而（f，f）對條件C1是不敏感的。47/161若條件為C2：B1&（E3=E4）其中B1為布爾表達式，E3和E4為算術表達式。C2的約束形式為（D1，D2），D1為t或f；當E3=E4時D2為=；當E3

E4時D2為

或

。則C2可能的約束集合為{（t，=）,（f，=），（t，

），（t，

）}。48/161若條件為C3：（E1

E2）

&（E3=E4）其中E1、E2、E3、E4均為算術表達式。則C2可能的約束集合為{（

，=）,（=，=），（

，=），（

，

），（

，

）}。49/161基本路徑測試在實際問題中，一個不太復雜的程序，特別是包含循環(huán)的程序，其路徑數可能非常大。因此測試常常難以做到覆蓋程序中的所有路徑，為此，我們希望把測試的程序路徑數壓縮到一定的范圍內?；韭窂綔y試是TomMcCabe提出的一種白盒測試技術，這種方法首先根據程序或設計圖畫出控制流圖，并計算其區(qū)域數，然后確定一組獨立的程序執(zhí)行路徑（稱為基本路徑），最后為每一條基本路徑設計一個測試用例。50/161程序的控制流圖（也稱程序圖）流圖由結點和邊組成，分別用圓和箭頭表示。設計圖中一個連續(xù)的處理框（對應于程序中的順序語句）序列和一個判定框（對應于程序中的條件控制語句）映射成流圖中的一個結點，設計圖中的箭頭（對應于程序中的控制轉向）映射成流圖中的一條邊。對于設計圖中多個箭頭的交匯點可以映射成流圖中的一個結點（空結點）。51/161上述映射的前提是設計圖的判定中不包含復合條件。如果設計圖的判定中包含了復合條件，那么必須先將其轉換成等價的簡單條件設計圖。123456c）對應的流圖a）含復合條件的設計圖a

borc

dx=1x=2tfy=0b）只含簡單條件的設計圖ttffx=1x=1a

bc

dx=2

123456y=052/161我們把流圖中由結點和邊組成的閉合部分稱為一個區(qū)域（region），在計算區(qū)域數時，圖的外部部分也作為一個區(qū)域。例如，右圖所示的流圖的區(qū)域數為3。獨立路徑是指程序中至少引進一個新的處理語句序列或一個新條件的任一路徑，在流圖中，獨立路徑至少包含一條在定義該路徑之前未曾用到過的邊。在基本路徑測試時，獨立路徑的數目就是流圖的區(qū)域數。12345653/161例如，對一個PDL程序進行基本路徑測試，該程序的功能是：最多輸入N個值（以-999為輸入結束標志），計算位于給定范圍內的那些值（稱為有效輸入值）的平均值，以及輸入值的個數和有效值的個數。54/161value[i]

minimumvalue[i]

=maximumtotal.valid加1sum=sum+value[i]value[i]

-999total.input

ntotal.valid

0average=-999i加1total.valid加1賦初值average=sum/total.valid10111213987123456tffttttfff55/161其區(qū)域數為6，我們選取獨立路徑如下：路徑1：1-2-10-11-13路徑2：1-2-10-12-13路徑3：1-2-3-10-11-13路徑4：1-2-3-4-5-8-9-2-10-12-13路徑5：1-2-3-4-5-6-8-9-2-10-12-13路徑6：1-2-3-4-5-6-7-8-9-2-10-11-13為每一條獨立路徑設計測試用例。假設：n=5；minimum=0；maximum=100。56/161路徑1：1-2-10-11-13測試數據：value=[90，-999，0，0，0]預期結果：Average=90，total.input=1，total.valid=1路徑2：1-2-10-12-13測試數據：value=[-999，0，0，0，0]預期結果：Average=-999，total.input=0，total.valid=0路徑3：1-2-3-10-11-13測試數據：value=[-1，90，70，-1，80]預期結果：Average=80，total.input=5，total.valid=357/161路徑4：1-2-3-4-5-8-9-2-10-12-13測試數據：value=[-1，-2，-3，-4，-999]預期結果：Average=-999，total.input=4，total.valid=0路徑5：1-2-3-4-5-6-8-9-2-10-12-13測試數據：value=[120，110，101，-999，0]預期結果：Average=-999，total.input=3，total.valid=0路徑6：1-2-3-4-5-6-7-8-9-2-10-11-13測試數據：value=[95，90，70，65，-999]預期結果：Average=80，total.input=4，total.valid=458/161值得注意的是，某些獨立路徑（如例中的路徑1和路徑3）不能以獨立的方式進行測試，此時，這些路徑必須在其他的獨立路徑測試中被覆蓋。59/161數據流測試數據流測試是根據程序中變量的定義（賦值）和引用位置來選擇測試用例假定s為語句的標號（每個語句有唯一的標號），x為變量名。定義：

DEF（s）={x|語句s中含有對x的定義}USE（s）={x|語句s中含有對x的引用}

當s為分支或循環(huán)語句時，DEF（s）=

設變量x在語句s中被定義，如果存在一條從語句s到語句s’

的路徑，并且在這條路徑上不存在對x的其它定義，則稱變量x在s處定義在s’處仍有效。60/161定義：定義-引用鏈DU

變量x的定義-引用鏈為[x，s，s’]

其中s,s’為語句標號，

x∈DEF（s）∩USE（s’）

且s處定義的x在s’處仍有效數據流測試就是設計測試用例使得每個DU鏈至少被覆蓋一次數據流測試適用于嵌套IF和多重循環(huán)程序的測試61/161循環(huán)測試循環(huán)分為4種不同類型：簡單循環(huán)、嵌套循環(huán)、串接循環(huán)和非結構循環(huán)。

(1)簡單循環(huán)按照下列規(guī)則設計測試用例：①零次循環(huán)：從循環(huán)入口到出口

②一次循環(huán)：檢查循環(huán)初始值

③二次循環(huán)：檢查多次循環(huán)

④m次循環(huán)：檢查多次循環(huán)

⑤最大次數循環(huán)

⑥比最大次數多一次的循環(huán)⑦比最大次數少一次的循環(huán)62/16163/161

按照下列規(guī)則設計測試用例：

①先測試最內層循環(huán)：所有外層的循環(huán)變量置為最小值，最內層按簡單循環(huán)測試；②由里向外，測試上一層循環(huán)：測試時此層以外的所有外層循環(huán)的循環(huán)變量取最小值，此層以內的所有嵌套內層循環(huán)的循環(huán)變量取“典型”值，該層按簡單循環(huán)測試；③重復上一條規(guī)則，直到所有各層循環(huán)測試完畢；④對全部各層循環(huán)同時取最小循環(huán)次數，或者同時取最大循環(huán)次數(2)嵌套循環(huán)64/161(3)串接循環(huán)

如果串接的各個循環(huán)互相獨立，則可以分別用簡單循環(huán)的方法進行測試；但如果第一個循環(huán)的循環(huán)變量與第二個循環(huán)控制相關，則兩個循環(huán)不獨立，此時，把第一個循環(huán)看作外循環(huán)，第二個循環(huán)看作內循環(huán)，然后用測試嵌套循環(huán)的辦法來處理。(4)非結構循環(huán)

這一類循環(huán)應該先將其結構化，然后再測試。65/161內容摘要軟件測試基礎白盒測試黑盒測試測試策略面向對象測試測試完成標準調試66/161黑盒測試黑盒測試是依據軟件的需求規(guī)約，檢查程序的功能是否符合需求規(guī)約的要求。主要的黑盒測試方法有：等價類劃分邊界值分析比較測試錯誤猜測因果圖67/161等價類劃分由于不能窮舉所有可能的輸入數據來進行測試，所以只能選擇少量有代表性的輸入數據，來揭露盡可能多的程序錯誤等價類劃分方法將所有可能的輸入數據劃分成若干個等價類，然后在每個等價類中選取一個代表性的數據作為測試用例等價類是指輸入域的某個子集，該子集中的每個輸入數據對揭露軟件中的錯誤都是等效的，測試等價類的某個代表值就等價于對這一類其他值的測試。也就是說，如果該子集中的某個輸入數據能檢測出某個錯誤，那么該子集中的其他輸入數據也能檢測出同樣的錯誤；反之，如果該子集中的某個輸入數據不能檢測出錯誤，那么該子集中的其他輸入數據也不能檢測出錯誤。68/161等價類劃分方法把輸入數據分為有效輸入數據和無效輸入數據有效輸入數據指符合規(guī)格說明要求的合理的輸入數據，主要用來檢驗程序是否實現了規(guī)格說明中的功能無效輸入數據指不符合規(guī)格說明要求的不合理或非法的輸入數據，主要用來檢驗程序是否做了規(guī)格說明以外的事在確定輸入數據等價類時，常常還要分析輸出數據的等價類，以便根據輸出數據等價類導出輸入數據等價類。69/161等價類劃分設計測試用例的步驟確定等價類

根據軟件的規(guī)格說明，對每一個輸入條件（通常是規(guī)格說明中的一句話或一個短語）確定若干個有效等價類和若干個無效等價類。

可使用如下表格輸入條件有效等價類無效等價類70/161確定等價類的規(guī)則：

(1)如果輸入條件規(guī)定了取值范圍，則可以確定一個有效等價類（輸入值在此范圍內）和兩個無效等價類（輸入值小于最小值及大于最大值）例如，規(guī)定輸入的考試成績在0..100之間，則有效等價類是“0

成績100”，無效等價類是“成績0”和“成績100”。71/161(2)如果輸入條件規(guī)定了值的個數，則可以確定一個有效等價類（輸入值的個數等于規(guī)定的個數）和兩個無效等價類（輸入值的個數小于規(guī)定的個數和大于規(guī)定的個數）例如，規(guī)定輸入構成三角形的3條邊，則有效等價類是“輸入邊數=3”，無效等價類是“輸入邊數

3”和“輸入邊數

3”。72/161(3)如果輸入條件規(guī)定了輸入值的集合（即離散值），而且程序對不同的輸入值做不同的處理，那么每個允許的值都確定為一個有效等價類，另外還有一個無效等價類（任意一個不允許的值）。例如，規(guī)定輸入的考試成績?yōu)閮?yōu)、良、中、及格、不及格，則可確定5個有效等價類和一個無效等價類。73/161(4)如果輸入條件規(guī)定了輸入值必須遵循的規(guī)則，那么可確定一個有效等價類（符合此規(guī)則）和若干個無效等價類（從各個不同的角度違反此規(guī)則）。例如，在Pascal語言中對變量標識符規(guī)定為“以字母開頭的……串”。那么有效等價類是“以字母開頭的串”，而無效等價類有“以數字開頭的串”、“以標點符號開頭的串”…等。74/161(5)如果輸入條件規(guī)定輸入數據是整型，那么可以確定三個有效等價類（正整數、零、負整數）和一個無效等價類（非整數）。(6)如果輸入條件規(guī)定處理的對象是表格，那么可以確定一個有效等價類（表有一項或多項）和一個無效等價類（空表）。以上只是列舉了一些規(guī)則，實際情況往往是千變萬化的，在遇到具體問題時，可參照上述規(guī)則的思想來劃分等價類。75/161設計測試用例

在確定了等價類之后，建立等價類表，列出所有劃分出的等價類。并為每個有效等價類和無效等價類編號。輸入條件有效等價類無效等價類76/161利用等價類設計測試用例的步驟：

(1)

設計一個新的測試用例，使其盡可能多地覆蓋尚未被覆蓋的有效等價類，重復這一步，直到所有的有效等價類都被覆蓋為止；

(2)

為每個無效等價類設計一個新的測試用例。77/161

用等價類劃分法設計測試用例的實例：

某編譯程序的規(guī)格說明中關于標識符的規(guī)定如下： 標識符是由字母開頭，后跟字母或數字的任意組合構成；標識符的字符數為1∽8個；標識符必須先說明后使用；一個說明語句中至少有一個標識符；保留字不能用作變量標識符。78/161用等價類劃分方法，建立輸入等價類表:輸入條件有效等價類無效等價類第一個字符字母⑴數字⑵非字母數字字符⑶后跟的字符字母⑷數字⑸非字母數字字符⑹保留字⑺字符數1~8個⑻0個⑼

8個⑽標識符的使用先說明后使用⑾未說明已使用⑿標識符個數

1個⒀0個⒁79/161下面選取9個測試用例，它們覆蓋了所有的等價類。輸入數據預期結果覆蓋的等價類VARP3t2：REAL；BEGINP3t2：=3．1；……END；正確標識符⑴，⑷，⑸，⑻，⑾，⒀VAR3P：REAL；報錯：不正確標識符⑵VAR！X：REAL；報錯：不正確標識符⑶VART#：CHAR；報錯：不正確標識符⑹80/161輸入數據預期結果覆蓋的等價類VARGOTO：INTEGER；報錯：保留字作標識符⑺VARX，：REAL；報錯：標識符長度為0⑼VART12345678：REAL；報錯：標識符字符超長⑽VARPAR：REAL；BEGIN……PAP：=3．14

……END；報錯：未說明已使用⑿VAR：REAL；報錯：標識符個數為0⒁81/161邊界值分析邊界值分析也是一種黑盒測試方法，是對等價類劃分方法的補充。人們從長期的測試工作經驗得知，大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上，而不是在輸入范圍的內部。因此針對各種邊界情況設計測試用例，其揭露程序中錯誤的可能性就更大。

82/161這里所說的邊界是指，相對于輸入等價類和輸出等價類而言，直接在其邊界上、或稍高于其邊界值、或稍低于其邊界值的一些特定情況。使用等價類分析方法設計測試用例時，原則上，等價類中的任一輸入數據都可作為該等價類的代表用作測試用例。而邊值分析則是專門挑選那些位于邊界附近的值（即正好等于、或剛剛大于、或剛剛小于邊界的值）作為測試用例。83/161邊界值分析方法選擇測試用例的規(guī)則如下：1．如果輸入條件規(guī)定了值的范圍，則選擇剛剛達到這個范圍的邊界的值以及剛剛超出這個范圍的邊界的值作為測試輸入數據。例如，規(guī)定輸入的考試成績在0～100之間，則取0，100，－1，101作為測試輸入數據。2．如果輸入條件規(guī)定了值的個數，則分別選擇最大個數、最小個數、比最大個數多1、比最小個數少1的數據作為測試輸入數據。例如，規(guī)定一個運動員的參賽項目至少1項，最多3項，那么，可選擇參賽項目分別是1項、3項、0項、4項的測試輸入數據。84/1613．對每個輸出條件使用第1條。例如，輸出的金額值大于等于0且小于104

，則選擇使得輸出金額分別為0、9999、－1、10000的輸入數據作為測試數據。4．對每個輸出條件使用第2條。例如，規(guī)定輸出的一張發(fā)票上，至少有1行內容，至多有5行內容，則選擇使得輸出發(fā)票分別有1行、5行、0行、6行內容的輸入數據作為測試數據。5．如果程序的輸入或輸出是個有序集合，例如，順序文件、表格，則應把注意力集中在有序集的第1個元素和最后一個元素上。85/1616．如果程序中定義的內部數據結構有預定義的邊界，例如，數組的上界和下界、棧的大小，則應選擇使得正好達到該數據結構邊界以及剛好超出該數據結構邊界的輸入數據作為測試數據。例如，程序中數組A的下界是10，上界是20，則可選擇使得A的下標為10、20、9、21的輸入數據作為測試數據。7．發(fā)揮你的智慧，找出其他可能的邊界條件。86/161由于邊值分析方法所設計的測試用例更有可能發(fā)現程序中的錯誤，因此經常把邊值分析方法與其它設計測試用例方法結合起來使用。87/161比較測試（backtoback）在現實中，有些軟件有很高的可靠性要求，特別是那些可能危及人的生命安全的軟件系統(tǒng)，如航空航天控制軟件、核電廠控制軟件等，其軟件可靠性絕對重要。此時，需要冗余的硬件和軟件來減少錯誤發(fā)生的可能性。通常，可由二支軟件開發(fā)隊伍，根據相同的需求規(guī)格說明分別開發(fā)二個軟件版本，然后，用相同的測試用例對二個版本的軟件分別進行測試，比較二個版本軟件的測試結果，如果測試結果相同，則可認為二個版本的軟件都是正確的，如果測試結果不同，則要分析各個版本，以發(fā)現錯誤的所在。這種測試稱為比較測試或稱為背靠背測試（back―to―backtesting）。大多數情況下，可用自動化工具來進行比較測試。88/161值得注意的是，比較測試并不能保證軟件沒有錯誤，如果規(guī)格說明本身有錯，那么所有的版本都可能反映這種錯誤。另外，如果各個版本產生相同的但都不正確的結果，那么比較測試也無法發(fā)現這種錯誤。89/161錯誤推測法錯誤猜測是一種憑直覺和經驗推測某些可能存在的錯誤，從而針對這些可能存在的錯誤設計測試用例的方法。這種方法沒有機械的執(zhí)行步驟，主要依靠直覺和經驗。錯誤猜測法的基本思想是：列舉出程序中所有可能的錯誤和容易發(fā)生錯誤的特殊情況，然后根據這些猜測設計測試用例。90/161例如，測試一個排序子程序，可考慮如下情況：輸入表為空；輸入表只有一個元素；輸入表的所有元素都相同；輸入表已排序。又如，測試二分法檢索子程序，可考慮如下情況：表中只有一個元素；表長為2n；表長為2n-1；表長為2n+191/161因果圖在等價類劃分方法和邊界值方法中未考慮輸入條件的各種組合，當輸入條件比較多時，輸入條件組合的數目會相當大因果圖方法是一種幫助人們系統(tǒng)地選擇一組高效測試用例的方法，它既考慮了輸入條件的組合關系，又考慮了輸出條件對輸入條件的依賴關系，即因果關系，其測試用例發(fā)現錯誤的效率比較高。92/161因果圖方法的特點是：考慮輸入條件的組合關系；考慮輸出條件對輸入條件的依賴關系，即因果關系；測試用例發(fā)現錯誤的效率高；能檢查出功能說明中的某些不一致或遺漏。93/161用因果圖設計測試用例的步驟：

(1)

分割功能說明書將輸入條件分成若干組，然后分別對每個組使用因果圖，這樣可減少輸入條件組合的數目。如測試編譯程序時，可以將每個語句作為一組。94/161(2)

識別“原因”和“結果”，并加以編號

“原因”是指輸入條件或輸入條件的等價類；“結果”是指輸出條件或系統(tǒng)變換。如，更新主文件就是一種系統(tǒng)變換。每個原因和結果都對應于因果圖中的一個結點，當原因或結果成立（或出現）時，相應的結點的值為1，否則為0。95/161

(3)

根據功能說明中規(guī)定的原因與結果之間的關系畫出因果圖因果圖的基本符號如下：ba恒等ba～非

abcd或abcd

與96/161圖中左邊的結點表示原因，右邊的結點表示結果原因和結果之間的關系有：恒等：若a=1，則b=1；若a=0，則b=0非：若a=1，則b=0；若a=0，則b=1或：若a=1或b=1或c=1，則d=1；否則d=0與：若a=b=c=1，則d=1；否則d=0畫因果圖時原因在左，結果在右，由上向下排列，并根據功能說明中規(guī)定的原因和結果之間的關系，用上述符號連接起來。必要時還可以引入一些中間結點。97/161

(4)

根據功能說明在因果圖中加上約束條件因果圖的約束條件如下圖所示：要求RbabaM屏蔽互斥abcE包含abcI唯一abcO98/161圖中互斥、包含、唯一、要求是對原因的約束，屏蔽是對結果的約束互斥：表示a、b、c中至多只有一個為1，即不同時為1包含：表示a、b、c中至少有一個為1，即不同時為0唯一：表示a、b、c中有且僅有一個1要求：表示若a=1，則要求b必須為1，即不可出現a=1且b=0屏蔽：表示若a=1，則b必須為0，即不可出現a=1且b=199/161

(5)

根據因果圖畫出判定表列出滿足約束條件的所有原因組合，寫出每種原因組合下的結果（如有的話）原因

允許的原因組合中間

結點

各種原因組合下中間結點的值結

果

各種原因組合下的結果值(6)為判定表的每一列設計一個測試用例100/161

例如，有一個處理單價為5角錢的飲料自動售貨機軟件，其規(guī)格說明如下：飲料自動售貨機允許投入5角或1元的硬幣，用戶可通過“橙汁”和“啤酒”按鈕選擇飲料，售貨機還裝有一個表示“零錢找完”的指示燈，當售貨機中有零錢找時指示燈暗，當售貨機中無零錢找時指示燈亮。當用戶投入5角硬幣并押下“橙汁”或“啤酒”按鈕后，售貨機送出“橙汁”或“啤酒”

。當用戶投入1元硬幣并押下“橙汁”或“啤酒”按鈕后，如果售貨機有零錢找，則送出相應的飲料，并退還5角硬幣；如果售貨機沒有零錢找，則飲料不送出，并且退還1元硬幣。101/161分析規(guī)格說明，列出原因和結果

規(guī)格說明中的紅色部分是輸入條件（原因），藍色部分是輸出條件（結果）。由于“售貨機有零錢找”是在投入1元硬幣時判斷是否能找零錢的依據，所以也可把它看作是一個輸入條件，即原因。與之對應的結果是售貨機指示燈亮（或暗）。

原因結果（1）售貨機有零錢找 （21）售貨機“零錢找完”燈亮（2）投入1元硬幣 （22）退還1元硬幣（3）投入5角硬幣 （23）退還5角硬幣（4）押下“橙汁”按鈕 （24）送出“橙汁”飲料（5）押下“啤酒”按鈕 （25）送出“啤酒”飲料102/161(2)畫出因果圖。所有原因結點列在左邊，所有結果結點列在右邊。其中中間結點的含義如下：（11）投入1元硬幣且押下飲料按鈕（12）押下“橙汁”或“啤酒”按鈕（13）應找5角硬幣且售貨機有零錢找（14）錢已付清103/161(3)

由于原因2與3，4與5不能同時發(fā)生，分別加上約束條件E。(4)根據因果圖畫出判定表(5)根據判定表設計測試用例104/161105/161內容摘要軟件測試基礎白盒測試黑盒測試測試策略面向對象測試測試完成標準調試106/161測試策略一種測試策略就是將測試分為單元測試、集成測試、確認測試和系統(tǒng)測試。單元測試是針對程序中的模塊或構件，主要揭露編碼階段產生的錯誤。集成測試針對集成的軟件系統(tǒng)，主要揭露設計階段產生的錯誤。確認測試是根據軟件需求規(guī)約對集成的軟件進行確認，主要揭露不符合需求規(guī)約的錯誤。對于基于計算機系統(tǒng)中的軟件，還需將它集成到基于計算機系統(tǒng)中，并進行系統(tǒng)測試，以揭露不符合系統(tǒng)工程中對軟件要求的錯誤。107/161V模型：描述軟件開發(fā)各階段與測試策略之間的對應關系。系統(tǒng)工程需求分析設計編碼系統(tǒng)測試確認測試集成測試單元測試108/161TomGilb指出實現一個成功的軟件測試策略必須涉及如下問題：在著手開始測試之前的較長時間，就要以量化的形式確定產品的需求。顯式地陳述測試目標。了解軟件的用戶并為每一類用戶建立剖面（profile）圖建立一個強調“快速循環(huán)（rapidcycle）測試”的測試計劃。構造“健壯”的軟件，它被設計成可測試自身。使用有效的正式技術評審作為測試之前的過濾器。使用正式技術評審來評估測試策略和測試用例本身。為測試過程建立一種持續(xù)改進的方法。109/161單元測試(UnitTesting)單元測試又稱模塊測試，它著重對軟件設計的最小單元（軟件構件或模塊）進行驗證單元測試根據設計描述，對重要的控制路徑進行測試，以發(fā)現構件或模塊內部的錯誤單元測試通常采用白盒測試，并且多個構件或模塊可以并行進行測試這里將構件或模塊統(tǒng)一稱為模塊110/1611.單元測試的內容模塊接口：確保模塊的輸入/輸出參數信息是正確的。這些信息包括參數的個數、次序、類型等。局部數據結構：確保臨時存儲的數據在算法執(zhí)行的整個過程中都能維持其完整性。如不合適的類型說明、不同數據類型的比較或賦值、文件打開和關閉的遺漏、超越數據結構的邊界等。邊界條件：確保程序單元在極限或嚴格的情況下仍能正確地執(zhí)行。111/161所有獨立路徑：確保模塊中的所有語句都至少執(zhí)行一次。程序執(zhí)行的路徑實際上體現了計算的過程，計算中常見的錯誤有：不正確的操作優(yōu)先級、不同類型數據間的操作、不正確的初始化、不精確的精度、不正確的循環(huán)中止、不適當地修改循環(huán)變量、發(fā)散的迭代等。所有錯誤處理路徑：單元測試應該對所有的錯誤處理路徑進行測試。錯誤處理部分潛在的錯誤有：報錯信息沒有提供足夠的信息來幫助確定錯誤的性質及其發(fā)生的位置、報錯信息與真正的錯誤不一致、錯誤條件在錯誤處理之前就已引起系統(tǒng)異常、異常條件處理不正確等。112/1612.單元測試過程單元測試通常與編碼工作結合起來進行。模塊本身不是一個獨立的程序，在測試模塊時，必須為每個被測模塊開發(fā)一個驅動(driver)程序和若干個樁(stub)模塊。驅動程序被測模塊樁模塊樁模塊113/161驅動模塊接收測試數據，調用被測模塊，把測試數據傳送給被測模塊，被測模塊執(zhí)行后，驅動模塊接收被測模塊的返回數據，并打印相關結果。驅動程序的程序結構如下： 數據說明； 初始化； 輸入測試數據； 調用被測模塊； 輸出測試結果；停止114/161樁模塊的功能是替代被被測模塊調用的模塊，它接受被測模塊的調用，驗證入口信息，把控制連同模擬結果返回給被測模塊。樁模塊的程序結構如下： 數據說明； 初始化； 輸出提示信息（表示進入了哪個樁模塊）； 驗證調用參數； 打印驗證結果； 將模擬結果送回被測程序；返回115/161集成測試（IntegratedTesting）集成測試也稱組裝測試、聯合測試經單元測試后，每個模塊都能獨立工作，但把它們放在一起往往不能正常工作。116/161

主要問題在于：數據可能在通過接口時丟失；一個模塊可能對另一個模塊產生產生非故意的、有害的影響（即副作用）；當子功能被組合起來時，可能不能達到期望的主功能；單個模塊可以接受的不精確性（如誤差），連接起來后可能會擴大到無法接受的程度；全局數據結構可能會存在問題。117/161

集成的方式有兩種：非增量式集成：使用“一步到位”的方法來構造程序。先將所有經過單元測試的模塊組合在一起，然后對整個程序（作為一個整體）進行測試。這種測試在發(fā)現錯誤時，很難為錯誤定位。改正錯誤時容易引入新的錯誤，新舊錯誤混在一起，更難定位。增量式集成：根據程序結構圖，按某種次序挑選一個（或一組）尚未測試過的模塊，把它集成到已測試好的模塊中一起進行測試，每次增加一個（或一組）模塊，直至所有模塊全部集成到程序中。在增量集成測試過程中發(fā)現的錯誤，往往與新加入的模塊有關。118/161

增量式集成又可分為自頂向下集成和自底向上集成。自頂向下集成：從主控模塊（主程序）開始，然后按照程序結構圖的控制層次，將直接或間接從屬于主控模塊的模塊按深度優(yōu)先或廣度優(yōu)先的方式逐個集成到整個結構中，并對其進行測試。自頂向下集成在測試一個模塊時，它的上層模塊（已測試過）可用作它的驅動模塊。119/161深度優(yōu)先測試次序：

M1、M2、M5、M8、M6、M3、M7、M4廣度優(yōu)先測試次序：

M1、M2、M3、M4、M5、M6、M7、M8M2M3M4M7M1M6M5M8120/161

自頂向下集成的步驟：（1）主控模塊（主程序）被直接用作驅動程序，所有直接從屬于主控模塊的模塊用樁模塊替換，然后對主控模塊進行測試；（2）根據集成的實現方式（深度優(yōu)先或廣度優(yōu)先），下層的樁模塊一次一個地替換成真正的模塊，從屬于該模塊的模塊用樁模塊替換，然后對其進行測試；（3）用回歸測試來保證沒有引入新的錯誤；（4）重復第（2）和第（3）步，直至所有模塊都被集成。121/161

自頂向下集成的優(yōu)點：不需要驅動模塊；能盡早對程序的主要控制和決策機制進行檢驗，能較早發(fā)現整體性的錯誤；深度優(yōu)先的自頂向下集成能較早對某些完整的程序功能進行驗證。

自頂向下集成的缺點：測試時低層模塊用樁模塊替代，不能反映真實情況；重要數據不能及時回送到上層模塊。122/161

自底向上集成：從程序結構的最底層模塊（即原子模塊）開始，然后按照程序結構圖的控制層次將上層模塊集成到整個結構中，并對其進行測試。自底向上集成在測試一個模塊時，它的下層模塊（已測試過）可用作它的樁模塊。123/161

自底向上集成的步驟：（1）將低層模塊組合成能實現軟件特定功能的簇；（2）為每個簇編寫驅動程序，并對簇進行測試；（3）移走驅動程序，用簇的直接上層模塊替換驅動程序，然后沿著程序結構的層次向上組合新的簇；（4）凡對新的簇測試后，都要進行回歸測試，以保證沒有引入新的錯誤；（5）重復第（2）步至第（4）步，直至所有的模塊都被集成。124/161McMaMb簇1簇2簇3D1D3D2驅動模塊簇4簇5125/161

自底向上集成的優(yōu)點：不需要樁模塊，所以容易組織測試；將整個程序結構分解成若干個簇，對同一層次的簇可并行進行測試，可提高效率。

自底向上集成的缺點：整體性的錯誤發(fā)現得較晚。126/161

策略的選擇自頂向下集成測試與自底向上集成測試各有優(yōu)缺點，其中一種策略的優(yōu)點差不多就是另一種策略的缺點。將這兩種策略組合起來可能是一種最好的折衷，這種折衷的策略是：在程序結構的高層使用自頂下向策略，而在低層則使用自底向上策略，這種測試策略也稱為三明治測試（sandwichtesting）。集成測試時應特別關注關鍵模塊（criticalmodule）的測試。關鍵模塊是指具有下列一個或多個特征的模塊：1）與多個軟件需求有關；2）含有高層控制（位于程序結構的高層）；3）本身是復雜的或是容易出錯的；4）含有確定的性能需求。關鍵模塊應盡早測試，回歸測試時也應集中在關鍵模塊的功能上。127/161回歸測試（RegressionTesting）在集成測試過程中，每當增加一個（或一組）新模塊時，原先已集成的軟件就發(fā)生了改變。新的數據流路徑被建立，新的I/O操作可能出現，還可能激活新的控制邏輯，這些改變可能使原本正常的功能產生錯誤。當測試時發(fā)現錯誤后，需修改程序；或者在軟件維護時也需修改程序。這些對程序的修改也可能使原本正常的功能產生錯誤?；貧w測試就是對已經進行過的測試的子集的重新執(zhí)行，以確保對程序的改變和修改，沒有傳播非故意的副作用。128/161回歸測試集（已經過測試的子集）包括三種不同類型的測試用例：能測試軟件所有功能的代表性測試用例專門針對可能會被修改影響的軟件功能的附加測試注重于修改過的軟件模塊的測試129/161確認測試（ValidationTesting）確認測試標準確認測試以軟件需求規(guī)約為依據，以發(fā)現軟件與需求不一致的錯誤。主要檢查軟件是否實現了規(guī)約規(guī)定的全部功能要求，文檔資料是否完整、正確、合理，其他的需求，如可移植性、可維護性、兼容性、錯誤恢復能力等是否滿足。130/161

確認測試的結果可分為兩類：滿足需求規(guī)約要求的功能或性能特性，用戶可以接受。發(fā)現與需求規(guī)約有偏差，此時需列出問題清單。

131/161軟件配置評審軟件配置評審也稱軟件審計（audit），其目的是保證軟件配置的所有成分都齊全，各方面的質量都符合要求，具有維護階段必需的細節(jié)，而且已經編排好分類目錄。軟件配置主要包括計算機程序（源代碼和可執(zhí)行程序），針對開發(fā)者和用戶的各類文檔，包含在程序內部或程序外部的數據。132/161α測試和β測試如果軟件是為一個客戶開發(fā)的，那么，最后由客戶進行驗收測試（acceptancetest），以使客戶確認該軟件是他所需要的。如果軟件是給許多客戶使用的（如市場上銷售的各種軟件），那么讓每個客戶做驗收測試是不現實的。大多數軟件廠商都使用一種稱為α測試和β測試的過程，來發(fā)現那些似乎只有最終用戶才能發(fā)現的錯誤。133/161α測試是由一個用戶在開發(fā)者的場所進行的，軟件在開發(fā)者對用戶的“指導下”進行測試。經α測試后的軟件稱為β版軟件。β測試是由軟件的最終用戶在一個或多個用戶場所進行的，與α測試不同，開發(fā)者通常不在測試現場，因此，β測試是軟件在一個開發(fā)者不能控制的環(huán)境中的“活的”應用，用戶記錄所有在β測試中遇到的（真正的或想象的）問題，并定期把這些問題報告給開發(fā)者，在接到β測試的問題報告后，開發(fā)者對軟件進行最后的修改，然后著手準備向所有的用戶發(fā)布最終的軟件產品。134/161系統(tǒng)測試（SystemTesting）系統(tǒng)測試是對整個基于計算機的系統(tǒng)進行的一系列測試。系統(tǒng)測試的種類很多，每種測試都有不同的目的，它們從不同的角度測試計算機系統(tǒng)是否被正常地集成，并完成相應的功能。常用的系統(tǒng)測試包括：恢復測試（recoverytesting）安全測試（securitytesting）壓力測試（stresstesting）性能測試（performancetesting）135/161恢復測試（recoverytesting）恢復測試是通過各種手段，強制軟件發(fā)生故障，然后來驗證系統(tǒng)能否在指定的時間間隔內恢復正常，包括修正錯誤并重新啟動系統(tǒng)。如果恢復是由系統(tǒng)自身來完成的，那么，需驗證重新初始化、檢查點機制、數據恢復和重啟動等的正確性。如果恢復需要人工干預，那么要估算平均修復時間MTTR（meantimetorepair）是否在用戶可以接受的范圍內。136/161安全測試（securitytesting）安全測試用來驗證集成在系統(tǒng)中的保護機制能否實際保護系統(tǒng)不受非法侵入。在安全測試過程中，測試者扮演一個試圖攻擊系統(tǒng)的角色，采用各種方式攻擊系統(tǒng)。例如，截取或碼譯密碼；借助特殊軟件攻擊系統(tǒng)；“制服”系統(tǒng)，使他人無法訪問；故意導致系統(tǒng)失效，企圖在系統(tǒng)恢復之機侵入系統(tǒng)；通過瀏覽非保密數據，從中找出進入系統(tǒng)的鑰匙等等。一般來說，只要有足夠的時間和資源，好的完全測試一定能最終侵入系統(tǒng)。系統(tǒng)設計者的任務是把系統(tǒng)設計成：攻破系統(tǒng)所付出的代價大于攻破系統(tǒng)后得到信息的價值。137/161壓力測試（stresstesting）壓力測試也稱強度測試，它是在一種需要非正常數量、頻率或容量的方式下執(zhí)行系統(tǒng)，其目的是檢查系統(tǒng)對非正常情況的承受程度。例如：當系統(tǒng)的中斷頻率是每秒1或2個時，執(zhí)行每秒10個中斷的測試用例將輸入數據的數量提高一個數量級來測試輸入功能如何響應執(zhí)行需要最大內存或其它資源的測試用例執(zhí)行可能導致大量磁盤駐留數據的測試用例138/161性能測試（performancetesting）性能測試用來測試軟件在集成的系統(tǒng)中的運行性能。它對實時系統(tǒng)和嵌入式系統(tǒng)尤為重要。性能測試可以發(fā)生在測試過程的所有步驟中單元測試時，主要測試一個獨立模塊的性能，如算法的執(zhí)行速度。軟件集成后，進行軟件整體的性能測試。計算機系統(tǒng)集成后，進行整個計算機系統(tǒng)的性能測試。性能測試常常需要與壓力測試結合起來進行，而且常常需要一些硬件和軟件測試設備，以監(jiān)測系統(tǒng)的運行情況。139/161內容摘要軟件測試基礎白盒測試黑盒測試測試策略面向對象測試測試完成標準調試140/161面向對象測試面向對象軟件的測試目標仍然是用最少時間和工作量來發(fā)現盡可能多的錯誤但面向對象軟件的性質改變了測試的策略和測試戰(zhàn)術。面向對象軟件的測試也給軟件工程師帶來新的挑戰(zhàn)。141/161面向對象語境對測試的影響繼承、封裝、多態(tài)性、基于消息的通信等概念都是面向對象軟件的重要特征，它們對面向對象測試有很大的影響。單元適用于面向對象測試的兩種單元定義單元是可以編譯和執(zhí)行的最小軟件部件單元是決不會指派給多個設計人員開發(fā)的軟件部件類是面向對象軟件中的單元142/161封裝由于屬性和操作被封裝在類中，因此測試時很難獲得對象的某些具體信息（除非提供內置操作來報告這些信息），從而給測試帶來困難。繼承測試了父類的操作后，并不表示其子類就不必對繼承的操作進行測試。多態(tài)性在測試時，應覆蓋反映多態(tài)的所有實現方法。基于消息的通信面向對象軟件是通過消息通信來實現類之間的協作，它們沒有明顯的層次控制結構，因此，傳統(tǒng)的自頂向