測試方法的分類

靜態測試

核心分類依據：根據是否執行程序分為靜態測試和動態測試

靜態測試方法

執行特征：不運行被測程序，通過人工檢查或工具分析進行測試

測試對象：主要針對文檔（包括需求文檔、設計文檔等）和源代碼

實施方式：

基礎檢查：文檔中的錯別字、病句、標點符號錯誤、格式不一致等問題

深度驗證：對照文檔執行操作，驗證文檔描述的準確性和完整性

代碼審查：檢查源代碼中的語法錯誤（如if語句后誤加分號）和邏輯問題

類比說明：類似靜態網站概念，不涉及用戶交互修改，僅做內容展示

含義: 評審(review)和審查(inspection)是團隊測試的通用概念，指對特定類型的檢查對象進行的活動。
過程: 評審組對選擇的評審對象進行審查和討論，如需求規約說明書、系統設計、程序代碼等。
目的: 在評審過程中發現評審對象的錯誤、缺省、不精確處，以及維護的不完善和接口的錯誤描述等；查找與需求、指南、標準或規定的不符之處。評審的目的不在于直接解決問題，而在于發現問題、記錄問題并總結經驗教訓。

動態測試

動態測試方法

核心特征：必須運行程序，通過輸入輸出驗證程序行為
包含類型：分為黑盒測試和白盒測試兩大類
對比說明：類似動態網站概念，強調用戶交互和內容修改能力

黑盒測試

別稱：功能測試、數據驅動測試、基于規格說明書測試

核心思想：將程序視為不透明的"黑盒"，只關注輸入輸出關系

形象比喻：如同給雞退毛的過程，只關心投入帶毛雞和產出無毛雞的結果，不關心內部處理機制

測試原則

用戶視角：從最終用戶角度出發驗證系統功能

依據文檔：以軟件規格說明書為主要測試依據

數據關系：重點驗證輸入輸出數據間的正確對應關系

局限性：

無法檢測程序內部結構問題

難以發現規格說明書本身的缺陷

測試數據的選擇具有局限性

主要技術：大綱法、場景法、等價類劃分、邊界值分析、決策表、錯誤推測法等

應用特點：這些方法均不涉及程序內部邏輯，僅基于外部規格設計測試用例

非功能測試

    * 測試目標：驗證"系統工作得怎么樣"而非"做什么"* 測試類型：+ 質量特性：可用性、可靠性、穩定性、健壯性、可恢復性+ 維護特性：可維護性、易用性+ 環境適應：可移植性/兼容性測試、配置測試+ 輔助要素：文檔測試、國際化/本地化測試

白盒測試

白盒測試：也稱結構測試、邏輯驅動測試、基于程序本身的測試，需要完全了解程序的結構和處理過程，按照程序內部邏輯測試程序，檢驗程序中每條通路是否按照預定要求工作。

目的：測試程序的邏輯結構，如分支、循環等是否正確。

白盒測試與黑盒測試的對比

黑盒測試：不關注程序內部結構，只關注輸入與輸出是否符合預期。

白盒測試：深入程序內部結構，檢查每條邏輯路徑是否按預定要求工作。

黑盒測試與白盒測試的區別

黑盒測試:

關注點：功能的測試，主要從用戶的角度出發進行測試。

優點：能從用戶的角度出發，關注輸入和輸出，測試數據結果是否正確。

缺點：無法測試程序的內部邏輯和結構。

白盒測試:

關注點：程序結構的測試，即對程序內部的特定部位進行覆蓋測試。

優點：能關注到程序的內部邏輯和結構。

缺點：無法檢查程序的外部特性，以及未實現規格說明的程序內部欠缺部分。

灰盒測試:

結合了黑盒測試和白盒測試的方法。

在測試網站時，灰盒測試可以大量使用。例如，在前臺輸入數據時可以使用黑盒測試，如果容易獲得后臺的源代碼，則也可以做一些白盒測試。

測試方法的應用

在實際工作過程中，可能會用到黑盒測試、白盒測試或兩者的混合使用。

混合使用時，兩者的界限有時很難完全分開，在做測試時可能黑白盒測試會混合使用。

評審的分類

文檔審查

簡單文檔審查: 主要檢查文檔中的錯別字、病句、標點符號錯誤以及排版錯誤，類似于校對工作。
復雜文檔審查: 需要核對文檔中的說法是否與用戶要求一致，是否與開發的理解一致，確保文檔內容的準確性和一致性。

代碼審查和代碼走查

代碼審查的含義、過程和目的

代碼審查定義: 一種同級評審，通過檢查文檔以檢測缺陷，如不符合開發標準，不符合上層的文檔等。這是最正式的評審技術，基于文檔化的過程。

最正式的評審活動: 由專門培訓的主持人（非作者）領導。
同行檢查: 定義了不同的角色，引入了度量。
正式過程: 根據入口、出口規則的檢查列表和規則定義，會議前需要準備，出具審查報告和發現問題列表。

靜態分析方法

核心特征：分析軟件產品（如需求或代碼）而不執行這些工作產品，強調"分析"而非測試
靜態特性：無需運行程序代碼，因此稱為"靜態"分析
與動態測試區別：不同于代碼審查和代碼走查，更依賴理論和技術手段

靜態分析的分類

主要方向：
- 符合編程原則和標準（如編碼規則）
- 控制流分析（結合程序執行路徑）
- 復雜度分析（評估代碼復雜程度）

數據流分析

檢測內容：

未聲明變量使用：如直接寫而未聲明int a

未初始化變量使用：如聲明int a后直接print a

冗余變量聲明：聲明變量后從未使用（如int a但后續未引用）

嚴格性說明：

Java/C等語言嚴格要求變量先聲明后使用

int a是聲明，int a=3是定義

變量聲明后必須使用，否則視為缺陷

控制流分析

控制流圖

- 基本構成：* 圖形特性：帶開始和結束節點的有向圖（可用橢圓表示）* 節點表示：程序指令/語句（順序語句序列可合并為一個節點）* 邊表示：語句執行路徑（用箭頭表示控制流向）
- 繪制原則：* 分支語句（if/switch）必須單獨節點* 循環語句（while）單獨節點* switch中的case不單獨分節點* 開始/結束節點可省略
- 應用要點：* 根據需求或算法圖繪制（非程序代碼）* 邊需要命名（如a→b→c表示執行路徑）* 典型結構示例：

復雜度分析

圈復雜度

定義：復雜度分析給出一組能描述程序代碼復雜度特征的度量，主要用于評估程序的復雜程度。

白盒測試方法

單元測試用例的設計方法

主要方法: 以白盒測試方法為主，適當結合黑盒測試方法

執行順序: 一般采用"先黑后白"的測試策略

黑盒方法: 包括大綱法、場景法、邊界值法、等價類劃分、決策表、錯誤猜測等方法

白盒測試方法

1.邏輯覆蓋法

測試對象: 主要測試程序中的順序語句、分支語句(if/switch)、循環語句(while)以及條件表達式(>,<,>=,<=,and,or等)

覆蓋類型:
- 語句覆蓋
- 判定覆蓋
- 條件覆蓋
- 判定條件覆蓋
- 條件組合覆蓋

2.路徑覆蓋法

測試原理: 對程序中的所有執行路徑進行測試
示例說明: 假設程序從a點到b點，可能經過c、d、e等節點，則測試路徑包括：
- a→c→b
- a→d→b
- a→e→b
- 若存在交叉路徑(如c→d)，則增加a→d→c→b等更多路徑

白盒測試方法的步驟

獲得需求、獲得/畫出程序流程圖/算法圖

- 流程圖符號:* 圓角矩形: 表示開始和結束* 平行四邊形: 表示輸入/輸出* 菱形: 表示判斷/條件* 程序輸入三個變量a、b、c* 判斷條件1:a>0a>0a>0且b>0b>0b>0+ 滿足則執行c=c/ac=c/ac=c/a+ 然后判斷條件2:a>1a>1a>1或c>1c>1c>1- 滿足則執行c=c+1c=c+1c=c+1* 最終執行c=b+cc=b+cc=b+c并輸出結果

繪制控制流圖

例題:畫控制流圖

選擇覆蓋方法設計測試用例

語句覆蓋法

1.目標

最低標準：屬于C0標準（Coverage的縮寫），是測試理論中最基礎的要求
核心要求：程序中的每個可執行語句至少被執行一次，對應控制流程中的每個圓圈節點
執行次數：允許語句多次執行，但要求最少執行一次
死代碼檢測：若存在永遠無法執行的語句，則表明程序存在缺陷（死代碼）
示例說明：對于條件分支結構，需要設計至少兩條用例分別覆蓋不同路徑，如：

2.度量

計算公式：覆蓋率 = 被執行語句數 / 所有可能語句數 × 100%
路徑覆蓋：除語句外還需考慮路徑覆蓋率，如分支結構中不同路徑的執行情況
理想目標：要求語句覆蓋率必須達到100%，路徑覆蓋率根據測試需求而定
重復執行：應盡量減少用例的重復執行，在保證覆蓋率前提下優化用例數量
實際應用：單元測試中常用，功能測試中較少使用該標準

語句覆蓋法設計用例

1.語句覆蓋要求: 在設計用例時，需要確保程序中的每一個語句都被執行至少一次。

2.語句覆蓋路的走法

走法示例: 輸入a, b, c，如果a>0且b>0，則執行c=c/a；如果a>1或c>1，則執行c=c+1；最后執行c=b+c，并輸出a, b, c。需要設計用例使得這些語句都被執行。

設計用例

用例設計: 根據語句覆蓋的要求，設計用例a=2, b=1, c=6。

用例解釋: 這個用例可以確保所有語句都被執行。首先，a>0且b>0，所以執行c=c/a，c變為3；然后，a>1，所以執行c=c+1，c變為4；最后執行c=b+c，c變為5，并輸出a, b, c的值為2, 1, 5。

用例有效性: 這個用例滿足了語句覆蓋的要求，因為所有語句都被執行了。

4.語句覆蓋率: 通過設計用例并執行程序，可以計算出語句覆蓋率。在本例中，通過用例a=2, b=1, c=6，所有語句都被執行，所以語句覆蓋率為100%。

5.路徑覆蓋率: 路徑覆蓋率是指程序中所有可能的執行路徑被測試的比例。在本例中，存在四條可能的執行路徑，但語句覆蓋法只測試了其中一條，所以路徑覆蓋率為25%。

提高路徑覆蓋率: 為了提高路徑覆蓋率，需要設計更多的用例來覆蓋其他可能的執行路徑。這通常需要使用更復雜的測試方法，如條件覆蓋、路徑覆蓋等。

分支覆蓋標準

分支覆蓋（判定覆蓋）定義

定義: 分支覆蓋（判定覆蓋）是指程序中的每個判定的真分支和假分支至少各執行一次。

判定: 即大條件，如if、where語句中的條件表達式。

題目給出了一個包含多個判定條件的程序片段，要求設計測試用例以滿足分支覆蓋標準。

解題思路:
- 首先識別程序中的判定條件，即a>0且b>0和a>1或c>1。
- 然后設計測試用例，使得每個判定的真分支和假分支至少各執行一次。
- 可以通過選擇不同的路徑來實現，例如：
  - 用例1：a<0, b<0, c<0，此時兩個判定條件均為假。
  - 用例2：a=2, b=1, c=6，此時兩個判定條件均為真。

分支覆蓋的定義

分支覆蓋: 也叫判定覆蓋，是軟件測試中的一種覆蓋準則，要求設計測試用例，使得程序的每一個分支（或判定）至少被執行一次。
語句覆蓋率: 在這個例子中，語句覆蓋率是百分之百，但分支覆蓋率可能不同。

分支覆蓋的計算

覆蓋率計算: 若有七個語句，其中五個語句被覆蓋，則分支覆蓋率為5/7，即約71.43%，而非100%。
單獨分析: 需要單獨看每個分支是否被覆蓋，而不能只看整體的語句覆蓋率。

分支覆蓋的覆蓋率

覆蓋率概述

總體覆蓋率: 在進行代碼測試時，總體上達到了百分之百的語句覆蓋率。

路徑覆蓋率: 提及了路徑覆蓋率的概念，并指出在特定的測試用例中，只走了兩條路徑，因此路徑覆蓋率為百分之五十。

條件覆蓋法設計測試用例

定義: 條件覆蓋（C2標準）要求使每個判定中的每個條件的可能取值至少滿足一次，即每個條件都要真（True）一次，假（False）一次。
與分支覆蓋的對比: 分支覆蓋關注大條件的正確性，而條件覆蓋能發現條件錯誤（如大于、小于、等于寫錯），但不能發現邏輯錯誤。

例題：

條件覆蓋的例子與分析

判定條件覆蓋C1+C2

同時滿足判定覆蓋和條件覆蓋的要求

判定條件覆蓋C1+C2應用案例

例題:條件掩蓋問題

用例：

測試用例輸入	原子條件	判定條件
a=2 b=1 c=4	a>0 真，b>0 真，a>1真，c>1真	判定3取真，判定6取真
a=-1 b=-2 c=-3	a>0 假，b>0 假，a>1假，c>1假	判定3取假，判定6取假

條件組合覆蓋

定義: 條件組合覆蓋，也稱為多條件覆蓋C3，要求每個判定中的所有的條件取值組合至少執行一次。

路徑覆蓋C4

覆蓋路徑

路徑覆蓋: 除了滿足條件組合覆蓋外，還需要考慮路徑的覆蓋，即程序執行的所有可能路徑都要被測試到。

示例: 在給定的判定條件下，需要確保真真、假真、假假等所有路徑都被覆蓋到，如果有遺漏的路徑（如真假），則需要補充相應的用例。

注意: 路徑覆蓋通常比條件組合覆蓋要求更高，用例數量可能會翻倍。

路徑覆蓋法

核心目標：要求測試用例覆蓋程序中所有可能的執行路徑，包括循環路徑
覆蓋標準：屬于白盒測試中的C4級覆蓋標準，比條件組合覆蓋更嚴格
執行難點：程序中的循環結構會導致路徑數量呈指數級增長，例如操場跑步的比喻（第500圈狀態無法預測）

應用案例

四路徑模型：通過a>0、b>0、a>1、c>1四個條件組合形成4條獨立路徑
用例設計：
- 全真路徑：a=2,b=1,c=6（判定3真/判定6真）
- 全假路徑：a=-1,b=-2,c=-3（判定3假/判定6假）
- 混合路徑1：a=1,b=1,c=-3（判定3真/判定6假）
- 混合路徑2：a=-1,b=2,c=3（判定3假/判定6真）
適用條件：適用于無循環或有限循環次數的程序段

路徑覆蓋優化

McCabe的基路徑方法 02:51

理論基礎：基于圈復雜度計算線性獨立路徑數（邊-節點+2）
優化原理：通過控制流圖識別基本路徑，避免無限循環測試
McCabe的控制圖

- 節點定義：A為起始節點，G為終止節點，B/C/D等為過程節點
- 循環識別：B→C→B形成循環結構，需特殊處理
- 復雜度計算：閉合環數+1=5（示例中需設計5條獨立路徑）

路徑覆蓋法設計用例

路徑示例

    * 路徑選擇原則：+ 允許部分重疊（如p1與p2在A→B→C段重疊）+ 禁止完全包含（如p2不應完全包含p1的路徑）+ 循環結構僅測試單次迭代（如p2中的B→C→B）* 典型路徑：+ p1：A→B→C→G（邊1,4,9）+ p2：A→B→C→B→C→G（邊1,4,3,4,9）+ p3：A→D→E→F→G（邊2,6,8,10）+ p4：A→D→F→G（邊2,7,10）+ p5：A→B→E→F→G（邊1,5,8,10）