第二章軟件測試基礎1第二章軟件測試基礎1[本章要點]

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

2.2.1白盒測試與調試的異同

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

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

93、從執行的過程來看，測試是一個發現錯誤、

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

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

一、簡單循環：

二、嵌套循環：

三、串接循環：

四、無結構循環：五、數據流測試：六、程序插裝：程序插裝（ProgramInstrumentation）是指在程序中設置斷點或打印語句，在執行過程中了解程序的一些動態特性。

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

14七、變異測試14邏輯覆蓋語句覆蓋判定覆蓋條件覆蓋判定－條件覆蓋條件組合覆蓋路徑覆蓋邏輯覆蓋是以程序內部的邏輯結構為基礎的設計測試用例的技術。它屬白盒測試。15邏輯覆蓋語句覆蓋判定－條件覆蓋邏輯覆蓋是以程序內部的邏輯⑴語句覆蓋(Statementcoverage):每個語句至少執行一次。例：問題：若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)：在⑴的基礎上，每個判定的每個分支至少執行一次。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)：在⑴的基礎上，⑶條件覆蓋(Conditioncoverage)：在⑴的基礎上，使每個判定表達式的每個條件都取到各種可能的結果。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)：在⑴的⑸條件組合覆蓋：每個判定表達式中條件的各種可能組合都至少出現一次。入口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,X1⑦A2,X>1⑧A2,X1Testcases:①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):

每條可能的路徑都至少執行一次，若圖中有環，則每個環至少經過一次。=判定覆蓋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的角度，還可考慮下循環測試路徑選擇循環分為4種不同類型：簡單循環、連鎖循環、嵌套循環和非結構循環。

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

②一次循環：檢查循環初始值

③二次循環：檢查多次循環

④m次循環：檢查在多次循環

⑤最大次數循環、比最大次數多一次、少一次的循環。

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

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

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

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

(2)

嵌套循環

①對最內層循環做簡單循環的全部測試。所有其它層的循環變量置為最小值；

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

③反復進行，直到所有各層循環測試完畢。

25

(2)嵌套循環

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

連鎖循環

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

這一類循環應該使用結構化程序設計方法重新設計測試用例。

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

連接的復合條件表達式，則需要改為一系列只有單個條件的嵌套的判斷。30在選擇或多分支結構中，分支的匯聚處應有一個匯聚結點。3031313232計算環路復雜性的方法：

-V(G)=簡單判定節點數+1V(G)=E-N+2(E是邊數，N是定點數）V(G)=封閉區域數+1V(G)=41234567833計算環路復雜性的方法：1234567833根據環路復雜性產生基本路徑集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根據環路復雜性產生基本路徑集34基本路徑測試法步驟基本路徑測試法適用于模塊的詳細設計及源程序，其主要步驟如下。①以詳細設計或源代碼作為基礎，導出程序的控制流圖。②計算得到的控制流圖G的環路復雜性V（G）。③確定線性無關的路徑的基本集。④生成測試用例，確保基本路徑集中每條路徑的執行。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.程序環路復雜性程序的環路復雜性給出了程序基本路徑集中的獨立路徑條數，這是確保程序中每個可執行語句至少執行一次所必需的測試用例數目的上界。從控制流圖來看，一條獨立路徑是至少包含有一條在其它獨立路徑中從未有過的邊的路徑。372.程序環路復雜性程序的環路復雜性給出了程序基本路徑集中的3.導出測試用例導出測試用例，確保基本路徑集中的每一條路徑的執行。根據判斷結點給出的條件，選擇適當的數據以保證某一條路徑可以被測試到—用邏輯覆蓋方法。383.導出測試用例導出測試用例，確保基本路徑集中的每一條路徑每個測試用例執行之后，與預期結果進行比較。如果所有測試用例都執行完畢，則可以確信程序中所有的可執行語句至少被執行了一次。必須注意，一些獨立的路徑(如例中的路徑1)，往往不是完全孤立的，有時它是程序正常的控制流的一部分，這時，這些路徑的測試可以是另一條路徑測試的一部分。

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

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

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

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

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

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

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

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

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

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

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

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

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

“……項數可以從1到999……”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

通常在因果圖中用Ci表示原因，用Ei表示結果，各結點表示狀態，可取值“0”或“1”。“0”表示某狀態不出現，“1”表示某狀態出現。主要的原因和結果之間的關系有:68在因果圖中出現的基本符號

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

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

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

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

21、不移動棋子；

22、移動棋子；

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

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

總之，建議測試人員在進行測試的過程中，可以考慮先使用黑盒測試，然后統計相應的覆蓋率，再設計適當的白盒測試用例作為補充以保證測試的完整性。762.4白盒測試和黑盒測試的比較76

2.4.1白盒測試的優缺點

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

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

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

80%

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

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

缺乏可重復性測試—項目缺少回歸測試。·

缺乏可見性測試—沒有收集衡量結果的指標，唯一的標準就是發布代碼的期限。·

反作用的構建過程—只對項目的緊急程度構建響應，沒有預測其他構建人的需要。·

沒有對測試環境或測試數據進行控制。·

代碼發布后，沒有進行單元或集成測試。·

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

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

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

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

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

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

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

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

1、開發人員自己的本地環境

2、全部集成到一個普遍的開發環境中。

3、項目要構建一個測試環境，以進行系統測試的工作。

4、基于需求驗證和發布日期（關鍵的衡量指標），把代碼移動到質量保證（QA）的環境中。

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

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

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

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

—最終所形成的測試策略

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

實施

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

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

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

圖2-20

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

1．與開發者意見不一致

2．缺乏測試工具

3．培訓不夠104制定測試計劃時面對的問題1044．管理部門缺乏對測試工作的理解和支持5．缺乏用戶的參與6．測試時間不足7．過分依賴測試人員8．測試人員處于進退兩難的狀態9．不得不說“不”1054．管理部門缺乏對測試工作的理解和支持105制定測試計劃制定測試計劃時，由于各軟件公司的背景不同，測試計劃文檔也略有差異。實踐表明，制定測試計劃時，使用正規化文檔通常比較好。為了使用方便，在這里給出IEEE軟件測試計劃文檔模板。106制定測試計劃106107107根據IEEE829－1998軟件測試文檔編制標準的建議，測試計劃包含了16個大綱要項，簡要說明如下。1．測試計劃標識符一個測試計劃標識符是一個由公司生成的惟一值，它用于標識測試計劃的版本、等級，以及與該測試計劃相關的軟件版本。108根據IEEE829－1998軟件測試文檔編制標準的2．介紹在測試計劃的介紹部分主要是測試軟件基本情況的介紹和測試范圍的概括性描述。1092．介紹1093．測試項測試項部分主要是綱領性描述在測試范圍內對哪些具體內容進行測試，確定一個包含所有測試項在內的一覽表。具體要點如下。功能的測試設計的測試整體測試1103．測試項110IEEE標準中指出，可以參考下面的文檔來完成測試項：需求規格說明用戶指南操作指南安裝指南與測試項相關的事件報告111IEEE標準中指出，可以參考下面的文檔來完成測試項：1114．需要測試的功能測試計劃中這一部分列出了待測的功能。5．方法（策略）這部分內容是測試計劃的核心所在，所以有些軟件公司更愿意將其標記為“策略”，而不是“方法”。1124．需要測試的功能112測試策略描述測試小組用于測試整體和每個階段的方法。要描述如何公正、客觀地開展測試，要考慮模塊、功能、整體、系統、版本、壓力、性能、配置和安裝等各個因素的影響，要盡可能地考慮到細節，越詳細越好，并制作測試記錄文檔的模板，為即將開始的測試做準備。測試記錄具體說明如下。113測試策略描述測試小組用于測試整體和每個階段的方法公正性聲明測試用例特殊考慮經驗判斷設想114公正性聲明1146．不需要測試的功能測試計劃中這一部分列出了不需要測試的功能。7．測試項通過/失敗的標準測試計劃中這一部分給出了“測試項”中描述的每一個測試項通過/失敗的標準。正如每個測試用例都需要一個預期的結果一樣，每個測試項同樣都需要一個預期的結果。1156．不需要測試的功能115下面是通過/失敗的標準的一些例子：通過測試用例所占的百分比；缺陷的數量、嚴重程度和分布情況；測試用例覆蓋；用戶測試的成功結論；文檔的完整性；性能標準。116下面是通過/失敗的標準的一些例子：1168．測試中斷和恢復的規定測試計劃中這一部分給出了測試中斷和恢復的標準。常用的測試中斷標準如下：關鍵路徑上的未完成任務大量的缺陷嚴重的缺陷不完整的測試環境資源短缺1178．測試中斷和恢復的規定1179．測試完成所提交的材料測試完成所提交的材料包含了測試工作開發設計的所有文檔、工具等。例如，測試計劃、測試設計規格說明、測試用例、測試日志、測試數據、自定義工具、測試缺陷報告和測試總結報告等。1189．測試完成所提交的材料11810．測試任務測試計劃中這一部分給出了測試工作所需完成的一系列任務。在這里還列舉了所有任務之間的依賴關系和可能需要的特殊技能。11910．測試任務11911．環境需求環境需求是確定實現測試策略必備條件的過程。例如：人員——人數、經驗和專長。他們是全職、兼職、業余還是學生？設備——計算機、測試硬件、打印機、測試工具等。12011．環境需求120辦公室和實驗室空間——在哪里？空間有多大？怎樣排列？軟件——字處理程序、數據庫程序和自定義工具等。其他資源——軟盤、電話、參考書、培訓資料等。121辦公室和實驗室空間——在哪里？空間有多大？怎樣排列？112．測試人員的工作職責測試人員的工作職責是明確指出了測試任務和測試人員的工作責任。有時測試需要定義的任務類型不容易分清，不像程序員所編寫的程序那樣明確。復雜的任務可能有多個執行者，或者由多人共同負責。12212．測試人員的工作職責12213．人員安排與培訓需求前面討論的測試人員的工作職責是指哪類人員（管理、測試和程序員等）負責哪些任務。人員安排與培訓需求是指明確測試人員具體負責軟件測試的哪些部分、哪些可測試性能，以及他們需要掌握的技能等。實際責任表會更加詳細，確保軟件的每一部分都有人進行測試。每一個測試員都會清楚地知道自己應該負責什么，而且有足夠的信息開始設計測試用例。12313．人員安排與培訓需求123培訓需求通常包括學習如何使用某個工具、測試方法、缺陷跟蹤系統、配置管理，或者與被測試系統相關的業務基礎知識。培訓需求各個測試項目會各不相同，它取決于具體項目的情況。124培訓需求通常包括學習如何使用某個工具、測試方法、14．進度表測試進度是圍繞著包含在項目計劃中的主要事件（如文檔、模塊的交付日期，接口的可用性等）來構造的。作為測試計劃的一部分，完成測試進度計劃安排，可以為項目管理員提供信息，以便更好地安排整個項目的進度。12514．進度表125表4給出了一個例子。126表4給出了一個例子。126進度安排會使測試過程容易管理。通常，項目管理員或者測試管理員最終負責進度安排，而測試人員參與安排自己的具體任務。127進度安排會使測試過程容易管理。通常，項目管理員或15．潛在的問題和風險軟件測試人員要明確地指出計劃過程中的風險，并與測試管理員和項目管理員交換意見。這些風險應該在測試計劃中明確指出，在進度中予以考慮。有些風險是真正存在的，而有些最終證實是無所謂的，重要的是盡早明確指出，以免在項目晚期發現時感到驚慌。12815．潛在的問題和風險128一般而言，大多數測試小組都會發現自己的資源有限，不可能窮盡測試軟件所有方面。如果能勾畫出風險的輪廓，將有助于測試人員排定待測試項的優先順序，并且有助于集中精力去關注那些極有可能發生失效的領域。下面是一些潛在的問題和風險的例子：129一般而言，大多數測試小組都會發現自己的資源有限，不現實的交付日期與其他系統的接口處理巨額現金的特征極其復雜的軟件有過缺陷歷史的模塊發生過許多或者復雜變更的模塊安全性、性能和可靠性問題難于變更或測試的特征130不現實的交付日期13016．審批審批人應該是有權宣布已經為轉入下一個階段做好準備的某個人或某幾個人。測試計劃審批部分一個重要的部件是簽名頁。審批人除了在適當的位置簽署自己的名字和日期外，還應該簽署表明他們是否建議通過評審的意見。13116．審批1313、確定完成每項任務以及整個測試生命周期所需的時間。4、為測試工作建立詳細的時間進度計劃和里程碑表。5、評估時間進度風險并準備緩解風險計劃。四、準備并復查測試計劃文檔。1、測試計劃格式2、測試計劃復查

1323、確定完成每項任務以及整個測試生命周期所需的時

2.6.2測試報告測試報告是測試階段最后的文檔產出物，優秀的測試經理應該具備良好的文檔編寫能力，一份詳細的測試報告包含足夠的信息，包括產品質量和測試過程的評價，測試報告基于測試中的數據采集以及對最終測試結果的分析。2.6.3測試用例的編制本節我們首先討論幾個和測試用例相關的幾個問題，然后探討如何編制一個有效的測試用例。一、為什么做測試用例主要原因有如下幾點：①完全測試是不可能的；②輸入量太大；③輸出結果太多；④軟件實現途徑太多；⑤軟件說明書沒有客觀標準。從不同角度看，軟件缺陷的標準不同。1332.6.2測試報告133二、什么是測試用例比較通常的說法是：為達到最佳的測試效果或高效的揭露隱藏的錯誤而精心設計的少量測試數據，稱之為測試用例。三、使用測試用例的好處①在開始實施測試之前設計好測試用例，可以避免盲目測試并提高測試效率。②測試用例的使用令軟件測試的實施重點突出、目的明確。③在軟件版本更新后只需修正少部分的測試用例便可展開測試工作，降低工作強度、縮短項目周期。④功能模塊的通用化和復用化使軟件易于開發，而134二、什么是測試用例134用于功能模塊測試的測試用例的通用化和復用化則會使軟件測試易于開展，并隨著測試用例的不斷精化其效率也不斷攀升。四、測試用例在軟件測試中的作用①指導測試的實施②規劃測試數據的準備③評估測試結果的度量基準④分析缺陷的標準 ⑤編寫測試腳本的"設計規格說明書"五、測試用例文檔的編制首先，在編寫測試用例之前需要準備以下幾個編寫的依據：135用于功能模塊測試的測試用例的通用化和復用化則會使軟件需求說明以及相關文檔；相關的設計說明（概要設計，詳細設計等）；與開發組交流對需求理解的記錄（可以是開發人員的一個解釋）；已經基本成型的UI（可以有針對性地補充一些用例）。

其次，編寫測試用例文檔應有文檔模板，須符合內部的規范要求。最后一點就是，測試用例文檔應該由簡介和測試用例兩部分組成。那么，下面從測試用例的設置、設計、評審、修改以及管理等幾方面來詳細討論測試用例文檔的編制問題：136需求說明以及相關文檔；136

1、測試用例的設置2、測試用例的設計測試用例可以分為基本事件、備選事件和異常事件。軟件測試常用的設計測試用例的基本方法有：等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、邏輯覆蓋法等。視軟件的不同性質采用不同的方法。如何靈活運用各種基本方法來設計完整的測試用例，并最終實現暴露隱藏的缺陷，則要憑測試設計人員的豐富經驗和精心設計。3、測試用例的評審

1371、測試用例的設置137

4、測試用例的修改更新5、測試用例的管理測試管理軟件的主要功能有三個：①能將測試用例文檔的關鍵內容；②可供測試實施時及時輸入測試情況；③最終實現自動生成測試結果文檔。1384、測試用例的修改更新138本章小結在功能性測試中，我們通常使用離散數學，而涉及到結構性測試的領域，我們則會用到關于圖論的知識。使用這兩方面的知識，有助于我們更精確的描述軟件測試，減少對測試過程的誤解。白盒測試與黑盒測試則是軟件測試工作中設計測試用例的兩個主要的方法。在實際測試過程中，如果黑盒測試是足夠充分的，那么白盒測試就沒有必要，但是“足夠充分”只是一種理想狀態，例如：真的是所有功能點都測試了嗎？程序的功能點是人為的定義，常常是不全面的；139本章小結139各個輸入數據之間，有些組合可能會產生問題，怎樣保證這些組合都經過了測試？難于衡量測試的完整性是黑盒測試的主要缺陷，而白盒測試恰恰具有易于衡量測試完整性的優點，兩者之間具有極好的互補性。

白盒測試主要是針對程序的邏輯結構設計測試用例，用邏輯覆蓋率來衡量測試的完整性。邏輯單位主要有：語句、分支、條件、條件值、條件值組合、路徑。語句覆蓋就是覆蓋所有的語句，其他類推。另外還有一種判定條件覆蓋，其實是分支覆蓋與條件覆蓋的組合，在此不作討論。跟條件有關的覆蓋就有三種：140各個輸入數據之間，有些組合可能會產生問題，怎樣保證條件覆蓋是指覆蓋所有的條件表達，即所有的條件表達式都計算了，不考慮計算結果；條