軟件測試基礎(chǔ)課件

第二章軟件測試基礎(chǔ)1第二章軟件測試基礎(chǔ)1[本章要點]

軟件測試基礎(chǔ)知識；白盒測試和黑盒測試的定義；常見的白盒和黑盒測試設(shè)計技術(shù)；白盒測試與黑盒測試的區(qū)別；測試計劃和測試報告的編制；測試用例的定義和編制方法。2[本章要點]2[本章目標]理解并掌握白盒測試和黑盒測試，以及二者的優(yōu)缺點和各自的應(yīng)用范圍；能夠熟練使用幾種常見測試用例設(shè)計技術(shù)；了解測試計劃和測試文檔的作用，以及應(yīng)該包含的內(nèi)容和制定方法；了解測試報告的基本內(nèi)容，以及測試用例的基本內(nèi)容和編制方法。3[本章目標]3經(jīng)過改進的程序圖定義：節(jié)點要么是整個語句，要么是語句的一部分，邊表示控制流（從節(jié)點i到節(jié)點j有一條邊，當且僅當對應(yīng)節(jié)點j的語句或語句的一部分，可以立即在節(jié)點i對應(yīng)的語句或語句的一部分之后執(zhí)行）。程序的有向圖公式化能夠非常準確地描述程序的測試方面的問題?；窘Y(jié)構(gòu)化程序設(shè)計的構(gòu)造，例如：串行、選擇和循環(huán)等可以用如圖2-1所示的有向圖表示。4經(jīng)過改進的程序圖定義：節(jié)點要么是整個語句，圖2-1結(jié)構(gòu)化程序設(shè)計構(gòu)造的有向圖5圖2-1結(jié)構(gòu)化程序設(shè)計構(gòu)造的有向圖52.2白盒測試白盒測試是一種可視的測試軟件的方法，即它把測試對象看作一個透明的盒子，測試人員要了解程序結(jié)構(gòu)和處理過程，按照程序內(nèi)部邏輯測試程序，檢查程序中的每條通路是否按照預(yù)定要求正確工作。白盒測試的過程如圖2-7所示：圖2-7白盒測試過程示意圖62.2白盒測試圖2-7白盒測試過程示意圖6那么，在對被測軟件進行白盒測試時，主要對程序進行哪些方面的檢查呢？有如下幾點：（１）保證一個模塊中的所有獨立執(zhí)行路徑至少測試一次；（２）對所有邏輯判定取值“true”和“false”的兩種情況都至少測試一次；（３）在循環(huán)邊界和運行界限內(nèi)執(zhí)行循環(huán)體；（４）測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性。在軟件測試領(lǐng)域，有六種基本的測試類型：單元測試，集成測試，功能測試/系統(tǒng)測試，可接受性測試，回歸測試和Beta測試。白盒測試可以用在其中的三種測試類型中：1、單元測試7那么，在對被測軟件進行白盒測試時，主要對程2、集成測試3、回歸測試

2.2.1白盒測試與調(diào)試的異同

白盒測試和調(diào)試有哪些不同點呢？1、從承擔的任務(wù)來看，白盒測試同其他類型測試一樣，它的任務(wù)是發(fā)現(xiàn)所開發(fā)的項目中的缺陷；但是，調(diào)試不屬于測試，其任務(wù)是糾正軟件中的缺陷。2、從最終的結(jié)果來看，白盒測試有預(yù)知的結(jié)果，不可預(yù)知的只是程序是否通過測試，并且成功測試的結(jié)果是發(fā)現(xiàn)錯誤的癥狀，從而引起調(diào)試的進行；而調(diào)試的結(jié)果是消除項目中的錯誤。

82、集成測試83、從執(zhí)行的過程來看，測試是一個發(fā)現(xiàn)錯誤、改正錯誤、重新測試的過程；而調(diào)試是一個推理過程。4、從準備工作來看，測試從已知的條件開始，使用預(yù)先定義的程序；調(diào)試一般是以不可知的內(nèi)部條件開始，做統(tǒng)一性調(diào)試。5、從執(zhí)行的計劃性來看，測試是有計劃的并要進行測試設(shè)計；而調(diào)試則不受時間約束。6、從執(zhí)行的人員來看，測試經(jīng)常是由獨立的測試組在不了解軟件設(shè)計的條件下完成的，而調(diào)試必須由程序員來完成。

93、從執(zhí)行的過程來看，測試是一個發(fā)現(xiàn)錯誤、

7、從所使用的工具來看，大多數(shù)白盒測試的執(zhí)行和設(shè)計可有工具支持，而調(diào)試程序員能利用的工具主要是調(diào)試器。2.2.2白盒測試的用例設(shè)計白盒測試用例設(shè)計技術(shù)就是研究如何用最少的測試用例最大限度地發(fā)現(xiàn)軟件中的錯誤，目前主要有基本路徑測試、等價類劃分/邊界值分析測試、覆蓋測試、循環(huán)測試、數(shù)據(jù)流測試、程序插樁測試、變異測試等等方法。下面主要對幾種常見的方法加以介紹：一、基本路徑測試二、等價類劃分/邊界值分析（Equivalencepartitioning/boundaryvalueanalysis）107、從所使用的工具來看，大多數(shù)白盒測試的

三、控制流/覆蓋測試（Control-flow/CoverageTesting）⑴方法覆蓋方法覆蓋可用于衡量測試用例所覆蓋的方法的百分比。⑵語句覆蓋（StatementCoverage）語句覆蓋是一種衡量測試所覆蓋的程序語句百分比的措施。通過測試應(yīng)該達到100%程序語句覆蓋的目標，可以標識圈數(shù)，然后執(zhí)行最少的一組測試用例就可以達到語句覆蓋的目標。⑶判斷/分支覆蓋判斷/分支覆蓋是為了衡量在測試過程中覆蓋了多少個程序中的布爾表達式。11三、控制流/覆蓋測試（Control-flo圖2-11各種循環(huán)圖四、循環(huán)測試是一種白盒測試技術(shù)，注重于循環(huán)構(gòu)造的有效性。n循環(huán)結(jié)構(gòu)測試用例的設(shè)計循環(huán)可以劃分為以下幾種模式，如圖2-11：12圖2-11各種循環(huán)圖四、循環(huán)測試是一種白盒測可以使用如下方法設(shè)計循環(huán)測試用例：

一、簡單循環(huán)：

二、嵌套循環(huán)：

三、串接循環(huán)：

四、無結(jié)構(gòu)循環(huán)：五、數(shù)據(jù)流測試：六、程序插裝：程序插裝（ProgramInstrumentation）是指在程序中設(shè)置斷點或打印語句，在執(zhí)行過程中了解程序的一些動態(tài)特性。

13可以使用如下方法設(shè)計循環(huán)測試用例：13七、變異測試變異測試（MutationTesting）的提出始于70年代末期，是一種錯誤驅(qū)動測試，即針對某類特定程序錯誤而進行的測試，也是一種比較成熟的排錯性測試方法（排錯性測試方法的基本思想是通過檢驗測試數(shù)據(jù)集的排錯能力來判斷軟件測試的充分性）。

14七、變異測試14邏輯覆蓋語句覆蓋判定覆蓋條件覆蓋判定－條件覆蓋條件組合覆蓋路徑覆蓋邏輯覆蓋是以程序內(nèi)部的邏輯結(jié)構(gòu)為基礎(chǔ)的設(shè)計測試用例的技術(shù)。它屬白盒測試。15邏輯覆蓋語句覆蓋判定－條件覆蓋邏輯覆蓋是以程序內(nèi)部的邏輯⑴語句覆蓋(Statementcoverage):每個語句至少執(zhí)行一次。例：問題：若AND錯寫為OR，或X>1錯寫為X<1,則錯誤無法由上例測出。入口A>1ANDB=0TA=2ORX>1TX=X/AX=X+1返回FFTestcase:A=2,B=0,X=4.16⑴語句覆蓋(Statementcoverage):每個語⑵判定覆蓋(Branchcoverage)：在⑴的基礎(chǔ)上，每個判定的每個分支至少執(zhí)行一次。Testcases:①A=3,B=0,X=3②A=2,B=1,X=1問題：若X>1錯寫為X<1,仍然無法被測出。入口A>1ANDB=0TA=2ORX>1TX=X/AX=X+1返回FF17⑵判定覆蓋(Branchcoverage)：在⑴的基礎(chǔ)上，⑶條件覆蓋(Conditioncoverage)：在⑴的基礎(chǔ)上，使每個判定表達式的每個條件都取到各種可能的結(jié)果。Testcases:①A=2,B=0,X=4（滿足A>1,B=0;A=2,X>1)②A=1,B=1,X=1(滿足A1,B0;A2,X1）問：條件覆蓋？判定覆蓋答:不一定。反例:①A=2,B=0,X=1②A=1,B=1,X=2

⑷判定/條件覆蓋：即判定覆蓋

條件覆蓋入口A>1ANDB=0TA=2ORX>1TX=X/AX=X+1返回FF18⑶條件覆蓋(Conditioncoverage)：在⑴的⑸條件組合覆蓋：每個判定表達式中條件的各種可能組合都至少出現(xiàn)一次。入口A>1ANDB=0TA=2ORX>1TX=X/AX=X+1返回FF全部可能的條件組合為：①A>1,B=0②A>1,B0③A1,B=0④A1,B0⑤A=2,X>1⑥A=2,X

1⑦A

2,X>1⑧A

2,X

1Testcases:①A=2,B=0,X=4(TT)②A=2.B=1,X=1(FT)③A=1,B=0,X=2(FT)④A=1,B=1,X=1(FF)問題：沒有測試到（TF）的情形19⑸條件組合覆蓋：每個判定表達式中條件的各種可能組合都至少出考察controlflowgraph的角度，還可考慮下述覆蓋：⑹點覆蓋⑺邊覆蓋=語句覆蓋⑻路徑覆蓋(Pathcoverage):

每條可能的路徑都至少執(zhí)行一次，若圖中有環(huán)，則每個環(huán)至少經(jīng)過一次。=判定覆蓋Testcases:①A=1,B=1,X=1②A=1,B=1,X=2③A=3,B=0,X=1④A=2,B=0,X=4⑼路徑覆蓋條件組合覆蓋20考察controlflowgraph的角度，還可考慮下循環(huán)測試路徑選擇循環(huán)分為4種不同類型：簡單循環(huán)、連鎖循環(huán)、嵌套循環(huán)和非結(jié)構(gòu)循環(huán)。

(1)簡單循環(huán)①零次循環(huán)：從循環(huán)入口到出口

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

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

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

⑤最大次數(shù)循環(huán)、比最大次數(shù)多一次、少一次的循環(huán)。

21循環(huán)測試路徑選擇循環(huán)分為4種不同類型：簡單循環(huán)、連鎖循環(huán)、嵌例：求最小值k=i;

for(j=i+1;j<=n;j++)

if(A[j]<A[k])thenk=j;

22例：求最小值k=i;22ace23ace23測試用例選擇24測試用例選擇24

(2)

嵌套循環(huán)

①對最內(nèi)層循環(huán)做簡單循環(huán)的全部測試。所有其它層的循環(huán)變量置為最小值；

②逐步外推，對其外面一層循環(huán)進行測試。測試時保持所有外層循環(huán)的循環(huán)變量取最小值，所有其它嵌套內(nèi)層循環(huán)的循環(huán)變量取“典型”值。。

③反復(fù)進行，直到所有各層循環(huán)測試完畢。

25

(2)嵌套循環(huán)

①對最內(nèi)層循環(huán)做簡單循環(huán)的全部測試2626 ④對全部各層循環(huán)同時取最小循環(huán)次數(shù)，或者同時取最大循環(huán)次數(shù)(3)

連鎖循環(huán)

如果各個循環(huán)互相獨立，則可以用與簡單循環(huán)相同的方法進行測試。但如果幾個循環(huán)不是互相獨立的，則需要使用測試嵌套循環(huán)的辦法來處理。(4)非結(jié)構(gòu)循環(huán)

這一類循環(huán)應(yīng)該使用結(jié)構(gòu)化程序設(shè)計方法重新設(shè)計測試用例。

27 ④對全部各層循環(huán)同時取最小循環(huán)次27基本路徑測試基本路徑測試方法把覆蓋的路徑數(shù)壓縮到一定限度內(nèi)，程序中的循環(huán)體最多只執(zhí)行一次。它是在程序控制流圖的基礎(chǔ)上，分析控制構(gòu)造的環(huán)路復(fù)雜性，導(dǎo)出基本可執(zhí)行路徑集合，設(shè)計測試用例的方法。設(shè)計出的測試用例要保證在測試中，程序的每一個可執(zhí)行語句至少要執(zhí)行一次。28基本路徑測試基本路徑測試方法把覆蓋的路徑數(shù)壓縮到一定限度內(nèi)，1.程序的控制流圖符號○為控制流圖的一個結(jié)點，表示一個或多個無分支的PDL語句或源程序語句。箭頭為邊，表示控制流的方向。291.程序的控制流圖符號○為控制流圖的一個結(jié)點，表示一個或多在選擇或多分支結(jié)構(gòu)中，分支的匯聚處應(yīng)有一個匯聚結(jié)點。邊和結(jié)點圈定的區(qū)域叫做區(qū)域，當對區(qū)域計數(shù)時，圖形外的區(qū)域也應(yīng)記為一個區(qū)域。如果判斷中的條件表達式是由一個或多個邏輯運算符(OR,AND,NAND,NOR)

連接的復(fù)合條件表達式，則需要改為一系列只有單個條件的嵌套的判斷。30在選擇或多分支結(jié)構(gòu)中，分支的匯聚處應(yīng)有一個匯聚結(jié)點。3031313232計算環(huán)路復(fù)雜性的方法：

-V(G)=簡單判定節(jié)點數(shù)+1V(G)=E-N+2(E是邊數(shù)，N是定點數(shù)）V(G)=封閉區(qū)域數(shù)+1V(G)=41234567833計算環(huán)路復(fù)雜性的方法：1234567833根據(jù)環(huán)路復(fù)雜性產(chǎn)生基本路徑集Path1:1-2-3-8Path2:1-2-3-8-1-2-3Path3:1-2-4-5-7-8Path4:1-2-4-6-7-8準備測試用例覆蓋所有基本路徑34根據(jù)環(huán)路復(fù)雜性產(chǎn)生基本路徑集34基本路徑測試法步驟基本路徑測試法適用于模塊的詳細設(shè)計及源程序，其主要步驟如下。①以詳細設(shè)計或源代碼作為基礎(chǔ)，導(dǎo)出程序的控制流圖。②計算得到的控制流圖G的環(huán)路復(fù)雜性V（G）。③確定線性無關(guān)的路徑的基本集。④生成測試用例，確保基本路徑集中每條路徑的執(zhí)行。35基本路徑測試法步驟35例如，在圖示的控制流圖中，一組獨立的路徑是

path1：1-11

path2：1-2-3-4-5-10-1-11

path3：1-2-3-6-8-9-10-1-11

path4：1-2-3-6-7-9-10-1-11路徑path1，path2，path3，path4組成了控制流圖的一個基本路徑集。36例如，在圖示的控制流圖中，一組獨立的路徑是

path1：12.程序環(huán)路復(fù)雜性程序的環(huán)路復(fù)雜性給出了程序基本路徑集中的獨立路徑條數(shù)，這是確保程序中每個可執(zhí)行語句至少執(zhí)行一次所必需的測試用例數(shù)目的上界。從控制流圖來看，一條獨立路徑是至少包含有一條在其它獨立路徑中從未有過的邊的路徑。372.程序環(huán)路復(fù)雜性程序的環(huán)路復(fù)雜性給出了程序基本路徑集中的3.導(dǎo)出測試用例導(dǎo)出測試用例，確?；韭窂郊械拿恳粭l路徑的執(zhí)行。根據(jù)判斷結(jié)點給出的條件，選擇適當?shù)臄?shù)據(jù)以保證某一條路徑可以被測試到—用邏輯覆蓋方法。383.導(dǎo)出測試用例導(dǎo)出測試用例，確保基本路徑集中的每一條路徑每個測試用例執(zhí)行之后，與預(yù)期結(jié)果進行比較。如果所有測試用例都執(zhí)行完畢，則可以確信程序中所有的可執(zhí)行語句至少被執(zhí)行了一次。必須注意，一些獨立的路徑(如例中的路徑1)，往往不是完全孤立的，有時它是程序正常的控制流的一部分，這時，這些路徑的測試可以是另一條路徑測試的一部分。

39每個測試用例執(zhí)行之后，與預(yù)期結(jié)果進行比較。如果所有測試用例都最后，歸納一下白盒測試中各種測試方法的應(yīng)用策略。在白盒測試中，可以使用各種測試方法的綜合策略如下。（1）在測試中，應(yīng)盡量先使用工具進行靜態(tài)結(jié)構(gòu)分析。（2）測試中可采取先靜態(tài)后動態(tài)的組合方式：先進行靜態(tài)結(jié)構(gòu)分析、代碼檢查，再進行覆蓋率測試。40最后，歸納一下白盒測試中各種測試方法的應(yīng)用策略。（3）利用靜態(tài)分析的結(jié)果作為導(dǎo)引，通過代碼檢查和動態(tài)測試的方式對靜態(tài)發(fā)現(xiàn)結(jié)果進行進一步的確認，使測試工作更為有效。（4）覆蓋率測試是白盒測試的重點，一般可使用基本路徑測試法達到語句覆蓋標準；對于軟件的重點模塊，應(yīng)使用多種覆蓋率標準衡量代碼的覆蓋率。41（3）利用靜態(tài)分析的結(jié)果作為導(dǎo)引，通過代碼檢查和動態(tài)（5）在不同的測試節(jié)點，測試的側(cè)重點不同：在單元測試階段，以代碼檢查、邏輯覆蓋為主；在集成測試階段，需要增加靜態(tài)結(jié)構(gòu)分析等；在系統(tǒng)測試階段，應(yīng)根據(jù)黑盒測試的結(jié)果，采取相應(yīng)的白盒測試。42（5）在不同的測試節(jié)點，測試的側(cè)重點不同：在單元測試階段，白盒測試總結(jié)：

“白盒”法全面了解程序內(nèi)部邏輯結(jié)構(gòu)、對所有邏輯路徑進行測試?！鞍缀小狈ㄊ歉F舉路徑測試。在使用這一方案時，測試者必須檢查程序的內(nèi)部結(jié)構(gòu)，從檢查程序的邏輯著手，得出測試數(shù)據(jù)。貫穿程序的獨立路徑數(shù)是天文數(shù)字。但即使每條路徑都測試了仍然可能有錯誤。第一、窮舉路徑測試決不能查出程序違反了設(shè)計規(guī)范，即程序本身是個錯誤的程序；第二、窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三、窮舉路徑測試可能發(fā)現(xiàn)不了一些與數(shù)據(jù)相關(guān)的錯誤。43白盒測試總結(jié)： “白盒”法全面了解程序內(nèi)部邏輯結(jié)構(gòu)、對所有邏黑盒測試也稱作功能測試和行為測試，主要是根據(jù)功能需求來測試程序是否按照預(yù)期工作。

黑盒測試的目的是盡量發(fā)現(xiàn)代碼所表現(xiàn)的外部行為的錯誤，主要有以下幾類：⑴功能不正確或不完整；⑵接口錯誤；⑶接口所使用的數(shù)據(jù)結(jié)構(gòu)錯誤；⑷行為或性能錯誤；⑸初始化和終止錯誤。黑盒測試的示意圖如圖2-14所示。從圖2-14中，我們可以看出黑盒測試只考慮程序的輸入和輸出，無須考慮程序的內(nèi)部代碼。2.3黑盒測試44黑盒測試也稱作功能測試和行為測試，主要是根據(jù)

圖2-14黑盒測試示意圖45圖2-14黑盒測試示意圖452.3.1黑盒測試和白盒測試的異同本書歸納出以下幾點：執(zhí)行測試人員不同黑盒測試通常由用戶以及非開發(fā)人員來進行；而白盒測試通常要有了解軟件內(nèi)部結(jié)構(gòu)的開發(fā)人員來做。測試覆蓋目標不同如果我們用一個盒子來代替整個軟件系統(tǒng)，那么黑盒測試可以看成是一種系統(tǒng)測試。而對盒子內(nèi)部的多個單元的測試就可以稱作為白盒測試。另外一種區(qū)別就是，二者的覆蓋目標不同。黑盒測試的目標是覆蓋所有的用戶需求；而白盒測試的目標是覆蓋所有的代碼。462.3.1黑盒測試和白盒測試的異同463、測試動機不同有效的安全測試有時也需要詳細了解代碼以及系統(tǒng)結(jié)構(gòu)，此時把這些技術(shù)稱作白盒測試。另外一種風(fēng)險測試的目標可能就只是測試軟件是否能夠為用戶提供預(yù)期輸出?？捎眯詼y試就是如此，所以被稱作黑盒測試。

4、測試方法不同一個最普通的區(qū)別就是行為測試設(shè)計是基于功能需求來定義測試，而結(jié)構(gòu)測試則是基于代碼本身來定義測試的。這就是兩種設(shè)計測試的方法。因為行為測試是基于外部功能定義的，所以稱作黑盒測試；結(jié)構(gòu)測試則是基于代碼內(nèi)部結(jié)構(gòu)來定義的，所以稱作白盒測試。473、測試動機不同475、評估測試方法不同一些技術(shù)是使用代碼工具來跟蹤軟件內(nèi)部的工作過程，因此稱為白盒測試技術(shù)。與之相比，黑盒測試技術(shù)只是簡單的觀察程序的正常輸出。

2.3.2黑盒測試的用例設(shè)計常用的黑盒測試用例設(shè)計方法主要有以下幾種：功能圖分析方法，等價類劃分方法，邊界值分析方法，錯誤推測方法，因果圖方法，判定表驅(qū)動分析方法，正交實驗設(shè)計方法和功能圖分析方法等。下面對上述方法分別作以簡要介紹。485、評估測試方法不同48一、基于用戶需求的測試黑盒測試用例就是基于用戶需求的，也是從研究客戶需求工作開始的。二、對等區(qū)間劃分

對等區(qū)間劃分是一種黑盒測試方法，該方法也稱為等價類劃分，是一種設(shè)計測試用例的非常形式化的方法。三、邊界值分析法邊界值分析方法是對等價類劃分方法的補充。長期的測試工作經(jīng)驗告訴我們,大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內(nèi)部。49一、基于用戶需求的測試49四、狀態(tài)轉(zhuǎn)換測試狀態(tài)轉(zhuǎn)換測試適用于軟件被設(shè)計成一個狀態(tài)機或?qū)崿F(xiàn)了一種被建模成一種狀態(tài)機的情況?？梢栽O(shè)計測試用例測試狀態(tài)間轉(zhuǎn)換，測試用例創(chuàng)建引起轉(zhuǎn)換的事件?？梢栽O(shè)計負面測試的測試用例用于測試狀態(tài)與事件的非法組合。五、分支測試在分支測試中，測試用例用于測試單元的控制流分支或決策點。通常用于實現(xiàn)決策覆蓋（DecisionCoverage）的測試目標。六、錯誤推測法錯誤推測法就是根據(jù)經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤，借助邊界值分析等方法有針對性的設(shè)計測試用例的方法。50四、狀態(tài)轉(zhuǎn)換測試50七、因果圖方法因果圖方法適合于檢查程序輸入條件的各種組合情況。使用該方法首先要理解軟件所表示的對象及其關(guān)系，然后，定義一組保證“所有對象與其他對象都具有所期望的關(guān)系”的測試序列。

51七、因果圖方法51等價類劃分等價類劃分是一種典型的黑盒測試方法，使用這一方法時，完全不考慮程序的內(nèi)部結(jié)構(gòu)，只依據(jù)程序的規(guī)格說明來設(shè)計測試用例。等價類劃分方法把所有可能的輸入數(shù)據(jù)，即程序的輸入域劃分成若干部分，然后從每一部分中選取少數(shù)有代表性的數(shù)據(jù)做為測試用例。52等價類劃分等價類劃分是一種典型的黑盒測試方法，使用這一方法時使用這一方法設(shè)計測試用例要經(jīng)歷劃分等價類（列出等價類表）和選取測試用例兩步。劃分等價類

等價類是指某個輸入域的子集合。在該子集合中，各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的。測試某等價類的代表值就等價于對這一類其它值的測試。

53使用這一方法設(shè)計測試用例要經(jīng)歷劃分等價類（列出等價類表）和選等價類的劃分有兩種不同的情況：

①有效等價類：是指對于程序的規(guī)格說明來說，是合理的，有意義的輸入數(shù)據(jù)構(gòu)成的集合。 ②無效等價類：是指對于程序的規(guī)格說明來說，是不合理的，無意義的輸入數(shù)據(jù)構(gòu)成的集合。在設(shè)計測試用例時，要同時考慮有效等價類和無效等價類的設(shè)計。54等價類的劃分有兩種不同的情況：

①有效等價類：是指對于程序劃分等價類等價類的原則。

(1)如果輸入條件規(guī)定了取值范圍，或值的個數(shù)，則可以確立一個有效等價類和兩個無效等價類。例如，在程序的規(guī)格說明中，對輸入條件有一句話：

“……項數(shù)可以從1到999……”

則有效等價類是“1≤項數(shù)≤999”兩個無效等價類是“項數(shù)＜1”或“項數(shù)＞999”。在數(shù)軸上表示成:55劃分等價類等價類的原則。

(1)如果輸入條件規(guī)定了取值范圍 (2)如果輸入條件規(guī)定了輸入值的集合，或者是規(guī)定了“必須如何”的條件，這時可確立一個有效等價類和一個無效等價類。例如，在Pascal語言中對變量標識符規(guī)定為“以字母打頭的……串”。那么所有以字母打頭的構(gòu)成有效等價類，而不在此集合內(nèi)（不以字母打頭）的歸于無效等價類。(3)如果輸入條件是一個布爾量，則可以確定一個有效等價類和一個無效等價類。

56 (2)如果輸入條件規(guī)定了輸入值的集合，或者是規(guī)定了“必須(4)如果規(guī)定了輸入數(shù)據(jù)的一組值，而且程序要對每個輸入值分別進行處理。這時可為每一個輸入值確立一個有效等價類，此外針對這組值確立一個無效等價類，它是所有不允許的輸入值的集合。例如，在教師上崗方案中規(guī)定對教授、副教授、講師和助教分別計算分數(shù)，做相應(yīng)的處理。因此可以確定4個有效等價類為教授、副教授、講師和助教，一個無效等價類，它是所有不符合以上身分的人員的輸入值的集合。

(5)如果規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則，則可以確立一個有效等價類（符合規(guī)則）和若干個無效等價類（從不同角度違反規(guī)則）。57(4)如果規(guī)定了輸入數(shù)據(jù)的一組值，而且程序要對每個輸入值分邊界值分析(BoundaryValueAnalysis)邊界值分析也是一種黑盒測試方法，是對等價類劃分方法的補充。人們從長期的測試工作經(jīng)驗得知，大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上，而不是在輸入范圍的內(nèi)部。因此針對各種邊界情況設(shè)計測試用例，可以查出更多的錯誤。邊界值分析是一種補充等價劃分的測試用例設(shè)計技術(shù)，它不是選擇等價類的任意元素，而是選擇等價類邊界的測試用例。注意：①程序最容易在邊界發(fā)生錯誤； ②通常與等價劃分結(jié)合進行。58邊界值分析(BoundaryValueAnalysis)邊界值設(shè)計原則應(yīng)遵循以下幾條原則：

1.如果輸入條件規(guī)定了值的范圍，則應(yīng)取剛達到這個范圍的邊界的值，以及剛剛超越這個范圍邊界的值作為測試輸入數(shù)據(jù)。

2.如果輸入條件規(guī)定了值的個數(shù)，則用最大個數(shù)、最小個數(shù)、比最小個數(shù)少一、比最大個數(shù)多一的數(shù)作為測試數(shù)據(jù)。3.根據(jù)規(guī)格說明的每個輸出條件，使用前面的原則1。59邊界值設(shè)計原則應(yīng)遵循以下幾條原則：594.根據(jù)規(guī)格說明的每個輸出條件，應(yīng)用前面的原則2。5.如果程序的規(guī)格說明給出的輸入域或輸出域是有序集合，則應(yīng)選取集合的第一個元素和最后一個元素作為測試用例。6.如果程序中使用了一個內(nèi)部數(shù)據(jù)結(jié)構(gòu)，則應(yīng)當選擇這個內(nèi)部數(shù)據(jù)結(jié)構(gòu)的邊界上的值作為測試用例。7.分析規(guī)格說明，找出其他可能的邊界條件。604.根據(jù)規(guī)格說明的每個輸出條件，應(yīng)用前面的原則2。60

(1)邊界值分析不是從某等價類中隨便挑一個作為代表，而是使這個等價類的每個邊界都要作為測試條件。

(2)邊界值分析不僅考慮輸入條件，還要考慮輸出空間產(chǎn)生的測試情況被測試子域測試內(nèi)點測試外點邊界值分析法與等價類劃分法區(qū)別61(1)邊界值分析不是從某等價類中隨便挑一個作為代表，而是使設(shè)計測試用例原則：

(1)如輸入條件代表以a和b為邊界的范圍，測試用例應(yīng)包含a、b、略大于a和略小于b的值。

(2)如輸入條件代表一組值，測試用例應(yīng)當執(zhí)行其中的最大值和最小值，還應(yīng)測試略大于最大值和略小于最小值的值。邊界值分析法(續(xù))62設(shè)計測試用例原則：邊界值分析法(續(xù))62錯誤推測法可以靠經(jīng)驗和直覺推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的例子。這就是錯誤推測法（如常見的錯誤）。錯誤推測法的基本想法是：列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況，根據(jù)它們選擇測試用例。思路：①列出可能有的錯誤；②列出容易發(fā)生錯誤的特殊情況。以此為基礎(chǔ)設(shè)計測試方案。根據(jù)：直覺、經(jīng)驗;工具：常見錯誤清單、判定表63錯誤推測法可以靠經(jīng)驗和直覺推測程序中可能存在的各種錯誤，從而錯誤推測法例1[例1]對一個排序程序，可以列出以下幾種特別需要檢查的情況：1)輸入表為空。2)輸入表中只有一行。3)輸入表中所有的行都具有相同的值。4)輸入表已經(jīng)是排序的。64錯誤推測法例1[例1]對一個排序程序，可以列出以下幾種因果圖如果在測試時必須考慮輸入條件的各種組合，可使用一種適合于描述對于多種條件的組合，相應(yīng)產(chǎn)生多個動作的形式來設(shè)計測試用例，這就需要利用因果圖。

因果圖方法最終生成的就是判定表。它適合于檢查程序輸入條件的各種組合情況。65因果圖如果在測試時必須考慮輸入條件的各種組合，可使用一種用因果圖生成測試用例的基本步驟

(1)分析軟件規(guī)格說明描述中，哪些是原因(即輸入條件或輸入條件的等價類)，哪些是結(jié)果(即輸出條件)，并給每個原因和結(jié)果賦予一個標識符。

(2)分析軟件規(guī)格說明描述中的語義，找出原因與結(jié)果之間，原因與原因之間對應(yīng)的是什么關(guān)系?根據(jù)這些關(guān)系，畫出因果圖。

66用因果圖生成測試用例的基本步驟

(1)分析軟件規(guī)格說明描述 (3)由于語法或環(huán)境限制，有些原因與原因之間，原因與結(jié)果之間的組合情況不可能出現(xiàn)。為表明這些特殊情況，在因果圖上用一些記號標明約束或限制條件。

(4)把因果圖轉(zhuǎn)換成判定表。

(5)把判定表的每一列拿出來作為依據(jù)，設(shè)計測試用例。

67 (3)由于語法或環(huán)境限制，有些原因與原因之間，原因與結(jié)果在因果圖中出現(xiàn)的基本符號

通常在因果圖中用Ci表示原因，用Ei表示結(jié)果，各結(jié)點表示狀態(tài)，可取值“0”或“1”?！?”表示某狀態(tài)不出現(xiàn)，“1”表示某狀態(tài)出現(xiàn)。主要的原因和結(jié)果之間的關(guān)系有:68在因果圖中出現(xiàn)的基本符號

通常在因果圖中用Ci表示原因，用E表示約束條件的符號

為了表示原因與原因之間，結(jié)果與結(jié)果之間可能存在的約束條件，在因果圖中可以附加一些表示約束條件的符號。69表示約束條件的符號

為了表示原因與原因之間，結(jié)果與結(jié)果之間可一、分析中國象棋中走馬的實際情況（下面未注明的均指的是對馬的說明）

1、如果落點在棋盤外，則不移動棋子；2、如果落點與起點不構(gòu)成日字型，則不移動棋子；3、如果落點處有自己方棋子，則不移動棋子；4、如果在落點方向的鄰近交叉點有棋子（絆馬腿），則不移動棋子；5、如果不屬于1-4條，且落點處無棋子，則移動棋子；6、如果不屬于1-4條，且落點處為對方棋子(非老將)，則移動棋子并除去對方棋子；7、如果不屬于1-4條，且落點處為對方老將，則移動棋子，并提示戰(zhàn)勝對方，游戲結(jié)束。70一、分析中國象棋中走馬的實際情況（下面未注明的均指的是對馬的二、根據(jù)分析明確原因和結(jié)果原因：落點在棋盤上；落點與起點構(gòu)成日字；落點處為自己方棋子；落點方向的鄰近交叉點無棋子；落點處無棋子；落點處為對方棋子（非老將）；落點處為對方老將。71二、根據(jù)分析明確原因和結(jié)果71結(jié)果：

21、不移動棋子；

22、移動棋子；

23、移動棋子，并除去對方棋子；

24、移動棋子，并提示戰(zhàn)勝對方，結(jié)束游戲。添加中間節(jié)點11，目的是作為導(dǎo)出結(jié)果的進一步原因，簡化因果圖導(dǎo)出的判定表72結(jié)果：72考慮結(jié)果不能同時發(fā)生，所以對其施加唯一約束O。原因5、6、7不能同時發(fā)生，所以對其施加異約束E.73考慮結(jié)果不能同時發(fā)生，所以對其施加唯一約束O。原因5、6、7三、根據(jù)因果圖建立判定表：(分為兩表)12345678910111213141516原因10101010101010101200110011001100113000011110000111140000000011111111結(jié)果110000000100000000211111111011111111用例74三、根據(jù)因果圖建立判定表：(分為兩表)23456789101123456789`0111213141516原因110101010101010101500110011001100116000011110000111170000000011111111結(jié)果220010000230000100240000001用例注：1、以上判定表中由于表格大小限制沒有列出最后所選的測試用例；2、第2表中部分列被合并表示不可能發(fā)生的現(xiàn)象；3、通過中間節(jié)點將用例的判定表簡化為兩個小表。減少工作量。75123456789`0111213141516原因110102.4白盒測試和黑盒測試的比較1、白盒測試只關(guān)注軟件產(chǎn)品的測試，不能夠確保產(chǎn)品已經(jīng)實現(xiàn)了規(guī)格說明中的所有功能。黑盒測試則只關(guān)注規(guī)格說明中的功能測試，不能夠保證已經(jīng)實現(xiàn)的各個部分都被測試到。2、與黑盒測試相比，白盒測試的成本要高一些。3、黑盒測試故意不考慮控制結(jié)構(gòu)，而只注意信息域。白盒測試只考慮測試軟件產(chǎn)品，它不保證完整的需求規(guī)格是否被滿足。黑盒測試是一種確認技術(shù)，回答“我們在構(gòu)造一個正確的系統(tǒng)嗎？白盒測試是一種驗證技術(shù)，回答“我們在正確地構(gòu)造一個系統(tǒng)嗎？”

總之，建議測試人員在進行測試的過程中，可以考慮先使用黑盒測試，然后統(tǒng)計相應(yīng)的覆蓋率，再設(shè)計適當?shù)陌缀袦y試用例作為補充以保證測試的完整性。762.4白盒測試和黑盒測試的比較76

2.4.1白盒測試的優(yōu)缺點

1）優(yōu)點可構(gòu)成測試數(shù)據(jù)對特定程序部分測試，可以檢測代碼中的每條分支和路徑；揭示隱藏在代碼中的錯誤；對代碼的測試比較徹底；有較多工具支持；有一定的充分性度量手段。

2）缺點工作量大,成本高。通常只用于單元測試，有應(yīng)用局限；無法檢測代碼中遺漏的路徑和數(shù)據(jù)敏感性錯誤；不能驗證規(guī)格說明的正確性；無法對規(guī)格說明中未實現(xiàn)的部分進行測試；不易生成測試數(shù)據(jù)(通常)。772.4.1白盒測試的優(yōu)缺點772.4.2黑盒測試的優(yōu)缺點優(yōu)點對于較大的代碼單元來說，效率高；測試人員不需要了解實現(xiàn)的細節(jié)，包括具體的編程語言；測試員和程序員可以由不同的人員來擔任；從用戶的角度進行測試，容易被理解和接受；有助于暴露任何規(guī)格不一致或有歧義的問題；測試用例的設(shè)計可以在規(guī)格說明完成之后馬上進行；容易入手生成測試數(shù)據(jù)；適用于各階段測試。782.4.2黑盒測試的優(yōu)缺點78缺點 實際上，只有一小部分可能的輸入被測試到，某些代碼得不到測試；如果沒有清晰、簡潔的規(guī)格說明，難以設(shè)計測試用例；如果測試人員不知道開發(fā)人員已經(jīng)執(zhí)行過該測試用例，會存在不必要的重復(fù)測試；會有很多程序路徑?jīng)]有被測試到；不能直接針對可能隱蔽了許多問題的特定程序段進行測試，；如果規(guī)格說明有誤，則無法發(fā)現(xiàn)；不易進行充分性測試。79缺點 792.4.3灰盒測試灰盒測試介于白盒測試和黑盒測試之間，是現(xiàn)代測試的一種理念。就是指，在白盒測試中交叉使用黑盒測試的方法；在黑盒測試中交叉使用白盒測試的方法。2.5測試方法的選擇一、單元測試測試方法：白盒測試參考規(guī)范：詳細設(shè)計說明和代碼結(jié)構(gòu)二、集成測試測試方法：黑盒和白盒測試參考規(guī)范：詳細設(shè)計說明和概要設(shè)計說明802.4.3灰盒測試80實用策略:

黑盒設(shè)計白盒補充①在任何情況下都應(yīng)該使用邊界值分析的方法；②必要時用等價劃分法補充；③必要時再用錯誤推測法補充；④對照程序邏輯，檢查測試方案?？筛鶕?jù)對程序可靠性的要求采用不同的邏輯覆蓋標準，必要時補充一些測試方案。注:即使用上述綜合策略設(shè)計測試方案，仍不能保證發(fā)現(xiàn)一切錯誤。例如Lucent公司經(jīng)過包括逐行檢查源代碼在內(nèi)的多方面測試之后，其軟件能達標運行的成功率為:

80%

81實用策略:黑盒設(shè)計白盒補充81為什么需要一個測試策略

測試策略應(yīng)該使測試過程中的交流變得更為容易，而它會影響到整個項目組。通過制定測試策略來指導(dǎo)我們的工作，項目組所碰到的具體問題：·

缺乏可重復(fù)性測試—項目缺少回歸測試?！?/p>

缺乏可見性測試—沒有收集衡量結(jié)果的指標，唯一的標準就是發(fā)布代碼的期限?！?/p>

反作用的構(gòu)建過程—只對項目的緊急程度構(gòu)建響應(yīng)，沒有預(yù)測其他構(gòu)建人的需要?！?/p>

沒有對測試環(huán)境或測試數(shù)據(jù)進行控制。·

代碼發(fā)布后，沒有進行單元或集成測試?！?/p>

沒有簡單的自動化過程，沒有測試過程。82為什么需要一個測試策略測試策略應(yīng)該使測試過程中的交流變軟件測試策略軟件測試策略描述軟件測試活動的總體方法和目標。為了檢驗開發(fā)的軟件能否符合規(guī)格說明書的要求，測試活動可以采用各種不同的策略。這些策略的區(qū)別在于它們表明了不同的出發(fā)點、不同的思路以及采用不同的手段和方法。具體地說，包括要使用的測試技術(shù)和工具；測試完成標準；影響資源分配的特殊考慮等。83軟件測試策略軟件測試策略描述軟件測試活動的總體方通常，制定軟件測試策略要考慮如下的內(nèi)容。（1）要使用的測試方法。（2）確定質(zhì)量風(fēng)險。（3）測試完成和測試成功所采用的評價標準。（4）有關(guān)資源要求或涉及進度的特殊考慮。（5）測試類型、評估標準以及測試方法。（6）確定資源。84通常，制定軟件測試策略要考慮如下的內(nèi)容。84

在制定測試策略時，你需要和項目中的關(guān)鍵人物一起，將關(guān)注點放在你們所面對的問題上，制定一個長期的解決方案，可以在整個項目周期內(nèi)實施。除了上面列出的那些問題之外，我們的項目解決方案還要滿足測試策略的基本需求：在開發(fā)周期內(nèi)，幫助項目組盡可能早的找到最嚴重的bugs。想盡早地發(fā)現(xiàn)最嚴重的缺陷，需要把項目的測試部分和開發(fā)部分聯(lián)合在一起，包括不同的測試階段、測試類型、項目環(huán)境，以及如何在環(huán)境、角色、職責(zé)之間升級代碼，還有普遍使用的工具。85在制定測試策略時，你需要和項目中的關(guān)鍵人物一起，將關(guān)注點寫字板上的計劃

第1步：基本策略輪廓第2步：目前的安排第3步：突如其來的改進第4步：組織計劃

第5步：確定要使用的工具

86寫字板上的計劃第1步：基本策略輪廓86寫字板上的計劃實現(xiàn)過程準備:

清晰地定義簡化的概念是簡單性的保證。把想法和內(nèi)容寫到寫字板上，它可以幫助人們共享意見和觀點。這時候，寫字板往往是最好的媒介。人們使用寫字板時，會畫一些漂亮的圖和流程圖，而這些圖形符號每個人都能理解。人員：項目經(jīng)理、開發(fā)主管、架構(gòu)師、DBA（數(shù)據(jù)庫管理員），以及其他一些關(guān)鍵人物。測試策略應(yīng)該覆蓋整個項目的生命周期，讓每個人都能按照它的方式工作。87寫字板上的計劃實現(xiàn)過程準備:87第1步：基本策略輪廓—輪廓

首先，把每個你想要捕獲、制定的測試方面寫到寫字板上，分成列的形式。把測試階段（包含了項目所執(zhí)行的測試類型）、不同的代碼環(huán)境、衡量指標各分成了一列，其中的衡量指標決定何時在不同的環(huán)境之間移動代碼。列出項目組當前并存執(zhí)行的每個測試階段；在測試階段的下面，列出要執(zhí)行的測試類型。尋找測試類型的過程，會幫助你清晰地定義測試階段。同時，可以把每個階段所代表的含義和產(chǎn)生的內(nèi)容分成一組。這里沒有所謂的“正確”定義；唯一重要的就是大家都認可你所使用的定義。你也可能需要定義測試的類型，但更重要的是確保每個人都能夠理解如何區(qū)分不同的測試類型。要使大家能夠自由地討論測試策略，一個清晰的框架需要清晰的定義。88第1步：基本策略輪廓—輪廓首先，把每個你想要捕獲、制定的測第2步：目前的安排—測試的當前狀態(tài)

列出不同的項目環(huán)境，以及當前所使用的衡量指標。后者決定了何時在環(huán)境之間移動構(gòu)建。在實際情況中，項目組會執(zhí)行系統(tǒng)測試和一些回歸測試，以及為少量用戶提供的專門的接受測試。而缺少單元測試和集成測試的一致性，以及通常在代碼提交給用戶之后所要進行的代碼復(fù)查工作。系統(tǒng)測試中，利用一些功能測試和生命周期測試，將大部分的需求做了驗證。而在前面的迭代中，項目組執(zhí)行了一個或兩個臨時的潛在測試，所以已經(jīng)包含了那些測試。所有的回歸測試，在時間允許的情況下，從前面的一次發(fā)布開始，是手工地基于測試用例的測試。89第2步：目前的安排—測試的當前狀態(tài)列出不同的項目環(huán)境，以具有5個項目環(huán)境。

1、開發(fā)人員自己的本地環(huán)境

2、全部集成到一個普遍的開發(fā)環(huán)境中。

3、項目要構(gòu)建一個測試環(huán)境，以進行系統(tǒng)測試的工作。

4、基于需求驗證和發(fā)布日期（關(guān)鍵的衡量指標），把代碼移動到質(zhì)量保證（QA）的環(huán)境中。

5、用戶根據(jù)發(fā)布的版本對大多數(shù)的期望功能進行復(fù)查，然后在一系列的結(jié)束標志（另一個關(guān)鍵的衡量指標）出現(xiàn)后，代碼即可移動到產(chǎn)品中。在衡量指標的那一列中，我們對每個環(huán)境中的需求驗證級別進行了討論，確定了那些能準確地反映當前過程的數(shù)字。90具有5個項目環(huán)境。90第3步：突如其來的改進

—添加的測試類型和衡量指標

所有的人都同意了寫字板上有關(guān)衡量指標的內(nèi)容，就可以制定項目測試希望達到的目標。討論一些有關(guān)實踐和工具的內(nèi)容，后者可以幫助提高效率，并與當前的資源（人力和財力）水平相符合。同時，由于很可能不能再擴大測試組的規(guī)模了，這樣會設(shè)法讓開發(fā)人員為測試提供幫助，而談?wù)摰年P(guān)注點也隨之開始圍繞在此問題上。也可以把關(guān)注點放在我們所經(jīng)歷的那些關(guān)鍵問題上。（即前面所羅列的那些問題嗎？）91第3步：突如其來的改進

—添加的測試進行自由討論，商定問題，并得到了一些結(jié)論：利用單元測試和集成測試，可以盡早地發(fā)現(xiàn)更多的問題，并準備好自動化測試的初始級別，同時，它們提供了一些衡量指標，這些指標讓我們可以更好的跟蹤開發(fā)過程。這樣，可以做出決定—-何時移動代碼。系統(tǒng)測試中，以每次發(fā)布用戶基線為結(jié)束，用戶基線會增長，同時他們也會逐漸地要求一些更為精確的性能測試。不能再依賴于需求驗證，不能再繼續(xù)將其作為主要的測試類型了。因為不能忽略安全性測試、可用性測試、配置測試和數(shù)據(jù)完整性測試，以及上百種其他類型的測試。進行一些基于session-based的探索性測試，而最初是以成對的方式執(zhí)行該測試的，直到我們更為適應(yīng)這種類型測試的過程，同時，也發(fā)展了我們快速學(xué)習(xí)和解決問題的能力。一旦我們適應(yīng)了探索性測試的工作，那么我們可以開始執(zhí)行更多的sessions。需要建立一個正規(guī)的且自動化的煙霧測試，它適用于所有的環(huán)境，它和自動化回歸測試的腳本集一起被用來測試那些高風(fēng)險的功能，以及高容量的事務(wù)處理。92進行自由討論，商定問題，并得到了一些結(jié)論：92用戶的接受測試（UAT）遠遠達不到它應(yīng)有的效果。因此，要制定更為詳細的UAT測試計劃，將其與測試腳本和培訓(xùn)材料一起提供給用戶，以幫助他們快速地提高。然而，這并不意味著能夠全權(quán)負責(zé)UAT的工作，提供更多的指南、資源和培訓(xùn)來幫助用戶進行接受測試，目的只是希望UAT執(zhí)行的更為順利。商定代碼何時可以在環(huán)境之間移動的衡量指標。無論是單元測試，還是集成測試，90%的測試通過率對代碼而言已經(jīng)足夠了，甚至可以從中了解到一些還會出現(xiàn)的bug。決定要執(zhí)行嚴格的代碼復(fù)查，以保證在早期（更可取的是在寫完或接近完成代碼時）就發(fā)現(xiàn)問題，而不是在代碼發(fā)布之后。在創(chuàng)建煙霧測試之后，代碼必須100%的通過這些測試，這樣才能前進入下一個級別。系統(tǒng)測試中，無論如何都不能讓任何嚴重或高級別的缺陷遺留到下一個過程中，但是也存在這樣的一些缺陷，是能容忍的，可以和用戶進行交流，以此來確定他們的期望：問題現(xiàn)在就被修復(fù)，還是放在后面解決。我們使用了代碼覆蓋的測試工具，根據(jù)它添加了一些相關(guān)的衡量指標，同時根據(jù)工具的缺陷趨勢分析，來幫助我們衡量系統(tǒng)測試工作的效果。93用戶的接受測試（UAT）遠遠達不到它應(yīng)有的效果。因此，要制定第4步：組織計劃—職責(zé)、環(huán)境詢問了會議中每一個人，一起檢查所達成的（寫在寫字板上）共識。下一步，劃分職責(zé)和活動的實際區(qū)域范圍。在寫字板上做了相應(yīng)的標注。在寫字板上做了相應(yīng)的標注，如用藍色方括號和箭頭。反映出項目中所包含的工作小組。項目可能包含了更多的工作小組—多個開發(fā)或測試組，甚至有獨立的行政或QA組。寫字板上的藍色箭頭表示要執(zhí)行的測試類型與環(huán)境的關(guān)聯(lián)關(guān)系。雖然還不算完美，但這些內(nèi)容為我們提供了一個測試提綱，使我們知道了大多數(shù)測試工作的分布情況。94第4步：組織計劃—職責(zé)、環(huán)境詢問了會議中每一個人，一起檢第5步：確定要使用的工具

—最終所形成的測試策略

測試中實際所使用的工具，把這些工具添加到的測試策略里。確定了主要的測試工具，當然，補充其他一些有幫助的工具。比如單元測試，可選用JUnit，開發(fā)人員知道該如何使用它。靜態(tài)分析，我們選用Jlint。其他的工具，選用Rational的產(chǎn)品：使用ClearCase進行資源和測試資產(chǎn)的控制；使用ClearQuest跟蹤問題；Purify、Quantify和PureCoverage被用來進行運行期分析；需求管理（rm）工具使用RequisitePro；自動化測試使用Robot和TestManager。95第5步：確定要使用的工具

實施

把測試策略作為一個可接受的解決方案，可以制定一個實施計劃。在計劃中，回答下面的問題：包含了各新測試類型的迭代過程是什么？（劃分測試類型對應(yīng)的每個迭代過程。）我們?nèi)绾螌χ皼]有做過測試的小組進行測試培訓(xùn)？（事關(guān)測試資源的利用和分配。）我們何時開始安裝、配置新的測試工具，并進行相關(guān)的培訓(xùn)？（測試工具的使用問題，會影響測試的實際進度。）由誰來負責(zé)每個測試階段的管理工作？（指定一個測試負責(zé)人。）我們?nèi)绾斡媱澾@份測試策略的修訂和更新工作？（需要控制測試策略的版本變更。）我們?nèi)绾魏饬窟@份測試策略的有效性？（對該測試策略的效果進行評估，評估的標準是什么？）由誰來負責(zé)該測試策略的維護工作？（我們應(yīng)該有自己的配置管理員來維護這些測試資產(chǎn)。）96實施把測試策略作為一個可接受的解決方進一步思考進一步思考，會遇到其他一些實施方面的問題，這些和項目背景有關(guān)。但只要能確保下面的一些情況就可以了：擁有所需的資源（人、硬件和軟件）；有時間和能力給項目組內(nèi)的人做相關(guān)的培訓(xùn)；你是個越干越起勁的人。項目的測試策略還沒有具體地實施。我們發(fā)現(xiàn)了一些變更，比之前面的更具效力。我們已經(jīng)完成了測試策略，但每次的迭代過程，依然要關(guān)注具體的新工具和新技術(shù)，或者關(guān)注與人員的培訓(xùn)，以使其具有更高的效率。這里討論的測試策略很簡單，它具有的格式也使我們可以容易地修改和更新，不僅靈活，而且很有幫助性。97進一步思考進一步思考，會遇到其他一些實施方面的問題，這些和項優(yōu)秀測試策略與測試用例的重要意義觀點：對于公司測試部最重要的人是設(shè)計優(yōu)秀測試策略和設(shè)計優(yōu)秀測試方案的測試工程師。自動化測試腳本開發(fā)工程師和測試工具開發(fā)者對于測試部很重要，但是其影響也是低于前者的。

自動化測試開發(fā)和測試工具開發(fā)都是可以外包出去的。而測試策略設(shè)計和測試方案設(shè)計才是測試部最重要的人才隊伍。

98優(yōu)秀測試策略與測試用例的重要意義觀點：對于公司測試部最重要的2.6測試計劃與測試文檔最常見的測試文檔包括測試計劃，測試規(guī)范，測試用例和測試時發(fā)現(xiàn)缺陷后要寫的‘缺陷報告’等。那么，測試計劃和測試文檔在測試過程中能夠發(fā)揮什么樣的作用呢？1、測試文檔有助于測試任務(wù)的完成。2、使用測試文檔可以更好的協(xié)調(diào)測試任務(wù)與測試過程。3、測試文檔為測試項目的組織、規(guī)劃與管理提供了一個架構(gòu)。992.6測試計劃與測試文檔992.6.1測試計劃的制定為了給讀者一個宏觀的認識，首先請看測試計劃活動圖，如圖2-20所示。在制定測試計劃過程中，核心活動就是：一、確定測試策略通常，可以采用以下幾個方法來制定測試策略：1、確定測試的范圍2、確定測試的方法3、確定測試標準和質(zhì)量檢查點4、確定自動化測試策略二、確定測試系統(tǒng)（硬件和軟件）1、測試架構(gòu)測試架構(gòu)指的就是測試用例的組織結(jié)構(gòu)。1002.6.1測試計劃的制定為了給讀者一個宏觀的認識，首先請

圖2-20

測試計劃活動101圖1012、測試工具3、測試環(huán)境測試環(huán)境的組成包括物理測試設(shè)施，產(chǎn)品運行的操作系統(tǒng)、產(chǎn)品運行的計算平臺等。4、測試配置情況需要排列配置的優(yōu)先級，然后決定哪些配置需要全面測試，哪些可以進行部分測試。三、預(yù)估測試工作量（資源和時間進度計劃）對項目進行預(yù)估有5個準備步驟：1、確定要完成的任務(wù)。2、確定每項任務(wù)所需的工作量和整個測試生命周期的工作量。1022、測試工具102制定測試計劃的原則制定測試計劃是軟件測試中最有挑戰(zhàn)性的一個工作。以下原則將有助于制定測試計劃工作。1．制定測試計劃應(yīng)盡早開始2．保持測試計劃的靈活性3．保持測試計劃簡潔和易讀4．盡量爭取多渠道評審測試計劃5．計算測試計劃的投入103制定測試計劃的原則103制定測試計劃時面對的問題制定測試計劃時，測試人員可能面對以下問題，必須認真對待，并妥善予以處理。

1．與開發(fā)者意見不一致

2．缺乏測試工具

3．培訓(xùn)不夠104制定測試計劃時面對的問題1044．管理部門缺乏對測試工作的理解和支持5．缺乏用戶的參與6．測試時間不足7．過分依賴測試人員8．測試人員處于進退兩難的狀態(tài)9．不得不說“不”1054．管理部門缺乏對測試工作的理解和支持105制定測試計劃制定測試計劃時，由于各軟件公司的背景不同，測試計劃文檔也略有差異。實踐表明，制定測試計劃時，使用正規(guī)化文檔通常比較好。為了使用方便，在這里給出IEEE軟件測試計劃文檔模板。106制定測試計劃106107107根據(jù)IEEE829－1998軟件測試文檔編制標準的建議，測試計劃包含了16個大綱要項，簡要說明如下。1．測試計劃標識符一個測試計劃標識符是一個由公司生成的惟一值，它用于標識測試計劃的版本、等級，以及與該測試計劃相關(guān)的軟件版本。108根據(jù)IEEE829－1998軟件測試文檔編制標準的2．介紹在測試計劃的介紹部分主要是測試軟件基本情況的介紹和測試范圍的概括性描述。1092．介紹1093．測試項測試項部分主要是綱領(lǐng)性描述在測試范圍內(nèi)對哪些具體內(nèi)容進行測試，確定一個包含所有測試項在內(nèi)的一覽表。具體要點如下。

功能的測試

設(shè)計的測試

整體測試1103．測試項110IEEE標準中指出，可以參考下面的文檔來完成測試項：

需求規(guī)格說明

用戶指南

操作指南

安裝指南

與測試項相關(guān)的事件報告111IEEE標準中指出，可以參考下面的文檔來完成測試項：1114．需要測試的功能測試計劃中這一部分列出了待測的功能。5．方法（策略）這部分內(nèi)容是測試計劃的核心所在，所以有些軟件公司更愿意將其標記為“策略”，而不是“方法”。1124．需要測試的功能112測試策略描述測試小組用于測試整體和每個階段的方法。要描述如何公正、客觀地開展測試，要考慮模塊、功能、整體、系統(tǒng)、版本、壓力、性能、配置和安裝等各個因素的影響，要盡可能地考慮到細節(jié)，越詳細越好，并制作測試記錄文檔的模板，為即將開始的測試做準備。測試記錄具體說明如下。113測試策略描述測試小組用于測試整體和每個階段的方法

公正性聲明

測試用例

特殊考慮

經(jīng)驗判斷

設(shè)想114公正性聲明1146．不需要測試的功能測試計劃中這一部分列出了不需要測試的功能。7．測試項通過/失敗的標準測試計劃中這一部分給出了“測試項”中描述的每一個測試項通過/失敗的標準。正如每個測試用例都需要一個預(yù)期的結(jié)果一樣，每個測試項同樣都需要一個預(yù)期的結(jié)果。1156．不需要測試的功能115下面是通過/失敗的標準的一些例子：

通過測試用例所占的百分比；

缺陷的數(shù)量、嚴重程度和分布情況；

測試用例覆蓋；

用戶測試的成功結(jié)論；

文檔的完整性；

性能標準。116下面是通過/失敗的標準的一些例子：1168．測試中斷和恢復(fù)的規(guī)定測試計劃中這一部分給出了測試中斷和恢復(fù)的標準。常用的測試中斷標準如下：

關(guān)鍵路徑上的未完成任務(wù)

大量的缺陷

嚴重的缺陷

不完整的測試環(huán)境

資源短缺1178．測試中斷和恢復(fù)的規(guī)定1179．測試完成所提交的材料測試完成所提交的材料包含了測試工作開發(fā)設(shè)計的所有文檔、工具等。例如，測試計劃、測試設(shè)計規(guī)格說明、測試用例、測試日志、測試數(shù)據(jù)、自定義工具、測試缺陷報告和測試總結(jié)報告等。1189．測試完成所提交的材料11810．測試任務(wù)測試計劃中這一部分給出了測試工作所需完成的一系列任務(wù)。在這里還列舉了所有任務(wù)之間的依賴關(guān)系和可能需要的特殊技能。11910．測試任務(wù)11911．環(huán)境需求環(huán)境需求是確定實現(xiàn)測試策略必備條件的過程。例如：

人員——人數(shù)、經(jīng)驗和專長。他們是全職、兼職、業(yè)余還是學(xué)生？

設(shè)備——計算機、測試硬件、打印機、測試工具等。12011．環(huán)境需求120

辦公室和實驗室空間——在哪里？空間有多大？怎樣排列？

軟件——字處理程序、數(shù)據(jù)庫程序和自定義工具等。

其他資源——軟盤、電話、參考書、培訓(xùn)資料等。121辦公室和實驗室空間——在哪里？空間有多大？怎樣排列？112．測試人員的工作職責(zé)測試人員的工作職責(zé)是明確指出了測試任務(wù)和測試人員的工作責(zé)任。有時測試需要定義的任務(wù)類型不容易分清，不像程序員所編寫的程序那樣明確。復(fù)雜的任務(wù)可能有多個執(zhí)行者，或者由多人共同負責(zé)。12212．測試人員的工作職責(zé)12213．人員安排與培訓(xùn)需求前面討論的測試人員的工作職責(zé)是指哪類人員（管理、測試和程序員等）負責(zé)哪些任務(wù)。人員安排與培訓(xùn)需求是指明確測試人員具體負責(zé)軟件測試的哪些部分、哪些可測試性能，以及他們需要掌握的技能等。實際責(zé)任表會更加詳細，確保軟件的每一部分都有人進行測試。每一個測試員都會清楚地知道自己應(yīng)該負責(zé)什么，而且有足夠的信息開始設(shè)計測試用例。12313．人員安排與培訓(xùn)需求123培訓(xùn)需求通常包括學(xué)習(xí)如何使用某個工具、測試方法、缺陷跟蹤系統(tǒng)、配置管理，或者與被測試系統(tǒng)相關(guān)的業(yè)務(wù)基礎(chǔ)知識。培訓(xùn)需求各個測試項目會各不相同，它取決于具體項目的情況。124培訓(xùn)需求通常包括學(xué)習(xí)如何使用某個工具、測試方法、14．進度表測試進度是圍繞著包含在項目計劃中的主要事件（如文檔、模塊的交付日期，接口的可用性等）來構(gòu)造的。作為測試計劃的一部分，完成測試進度計劃安排，可以為項目管理員提供信息，以便更好地安排整個項目的進度。12514．進度表125表4給出了一個例子。126表4給出了一個例子。126進度安排會使測試過程容易管理。通常，項目管理員或者測試管理員最終負責(zé)進度安排，而測試人員參與安排自己的具體任務(wù)。127進度安排會使測試過程容易管理。通常，項目管理員或15．潛在的問題和風(fēng)險軟件測試人員要明確地指出計劃過程中的風(fēng)險，并與測試管理員和項目管理員交換意見。這些風(fēng)險應(yīng)該在測試計劃中明確指出，在進度中予以考慮。有些風(fēng)險是真正存在的，而有些最終證實是無所謂的，重要的是盡早明確指出，以免在項目晚期發(fā)現(xiàn)時感到驚慌。12815．潛在的問題和風(fēng)險128一般而言，大多數(shù)測試小組都會發(fā)現(xiàn)自己的資源有限，不可能窮盡測試軟件所有方面。如果能勾畫出風(fēng)險的輪廓，將有助于測試人員排定待測試項的優(yōu)先順序，并且有助于集中精力去關(guān)注那些極有可能發(fā)生失效的領(lǐng)域。下面是一些潛在的問題和風(fēng)險的例子：129一般而言，大多數(shù)測試小組都會發(fā)現(xiàn)自己的資源有限，

不現(xiàn)實的交付日期

與其他系統(tǒng)的接口

處理巨額現(xiàn)金的特征

極其復(fù)雜的軟件

有過缺陷歷史的模塊

發(fā)生過許多或者復(fù)雜變更的模塊

安全性、性能和可靠性問題

難于變更或測試的特征