6.3 軟件測試技術

6.3.1軟件測試技術相關概念

軟件測試的定義

•在某種指定的條件下對系統或組件操作，觀察或記錄結果，對系統或組件的某些方面進行評估的過程。

•分析軟件各項目以檢測現有的結果和應有結果之間的差異，並評估軟件各項目的特征的過程。

軟件缺陷

• 軟件未實現產品說明書要求的功能。
• 軟件出現了產品說明書指明不能出現的錯誤。
• 軟件實現了產品說明書未提到的功能。
• 軟件未實現產品說明書雖未明確提及但應該實現的目標。
• 軟件難以理解、不易使用、運行緩慢或者——從測試員的角度看——最終用戶會認為不好。
• 驗證（Verification）
  • 保證軟件特定開發階段的輸出已經正確完整地實現了規格說明
• 確認（Validation）
  • 對於每個測試級別，都要檢查開發活動的輸出是否滿足具體的需求或與這些特定級別相關的需求

軟件質量保證

創建、執行改進過程並防止缺陷的標准和方法

質量與可靠性

• 功能性（functionality）
• 可移植性（portability）
• 效率（efficiency）
• 可靠性（reliability）
• 可維護性（maintainability）
• 可用性（usability）

軟件調試

• 目標是定位與修復缺陷

軟件測試

找出軟件缺陷，並確保修復

軟件測試的目標

• 測試用例（test case）：是測試輸入、執行條件、以及預期結果的集合，是為特定的目的開發的，例如執行特定的程序路徑或驗證與指定的需求相符合。
• 主題。設計者、類型、測試名稱、狀態、描述、優先級、comment、步驟名、步驟描述、預期結果、評審人、評審備注、評審時間等……

軟件測試的基本原則

1. 窮盡測試是不可能的
2. 測試無法顯示潛伏的軟件缺陷
3. 測試活動應盡早進行
4. 軟件缺陷具有群聚性
5. 注意“殺蟲劑”現象
6. 盡量由獨立的測試團隊進行測試

評估准則

主要測試方法

白盒測試

白盒測試

• 把測試對象看做一個透明盒子，允許利用程序內部邏輯結構及有關信息，進行測試。

• 通過在不同點檢查程序的狀態，確定實際的狀態是否與預期的狀態一致。

• 又稱為結構測試或邏輯驅動測試。

檢查范圍

• •對程序模塊的所有獨立的執行路徑至少測試一次；

• 對所有的邏輯判定，取“真”與取“假”的兩種情況都至少測試一次；

• 在循環的邊界和運行界限內執行循環體；

• 測試內部數據結構的有效性等。

完全測試的困難性

對一個具有多重選擇和循環嵌套的程序，不同的路徑數目可能是天文數字

例如：

執行路徑數：520條
設：每一條路徑測試需要1毫秒，如果一年工作365 × 24小時。需用時：3170年。

邏輯覆蓋

以程序內部的邏輯結構為基礎設計測試用例的技術。

1. 語句覆蓋
2. 分支覆蓋
3. 條件覆蓋
4. 條件組合覆蓋

分支覆蓋

分支覆蓋：就是設計若干個測試用例，運行被測程序，使得程序中每個判斷的取真分支和取假分支至少經歷一次。分支覆蓋又稱為判定覆蓋。

條件覆蓋

條件覆蓋：設計若干個測試用例，運行被測程序，使得程序中每個判斷的每個條件的可能取值至少執行一次。

條件組合覆蓋

條件組合覆蓋：設計足夠的測試用例，運行被測程序，使得每個判斷的所有可能的條件取值組合至少執行一次。

控制流圖覆蓋測試：是將代碼轉變為控制流圖（CFG），基於其進行測試的技術。

程序的控制圖

• 結點：符號○ ，表示一個或多個無分支的PDL語句或源程序語句。
• 邊：箭頭，表示控制流的方向。
• 匯聚節點：在選擇或多分支結構中，分支的匯聚處應有一個匯聚結點。
• 區域：邊和結點圈定的區域。對區域計數時，圖形外的區域也應記為一個區域，即每次至少有兩個區域。

單條件嵌套

單條件嵌套：如果判斷中的條件表達式是由一個或多個邏輯運算符 (OR,  AND, NAND,  NOR)  連接的復合條件表達式，則需要改為一系列只有單個條件的嵌套的判斷。

節點覆蓋

對圖中的每個節點，至少要有一條測試路徑訪問該節點

顯然，節點覆蓋=語句覆蓋

邊覆蓋

對圖中每一個可到達的長度小於(無邊圖)等於1 的路徑，中至少存在一條測試路徑覆蓋。

顯然，邊覆蓋包含節點覆蓋，且邊覆蓋也可以實現分支覆蓋。

路徑覆蓋

路徑覆蓋測試：就是設計足夠的測試用例，覆蓋程序中所有可能的路徑

基本路徑覆蓋

基本路徑測試：將覆蓋的路徑數壓縮到一定限度內，程序中的循環體最多只執行一次。

例

黑盒測試

• 測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性

• 只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能說明

• 又叫做功能測試或數據驅動測試。

基本思想

•把所有可能的輸入數據，即程序的輸入域划分成若干部分，然后從每一部分中選取少數有代表性的數據做為測試用例。

檢查范圍

是否有不正確或遺漏了的功能?

在接口上，輸入能否正確地接受? 能否輸出正確的結果?是否有數據結構錯誤或外部信息訪問錯誤?性能上是否能夠滿足要求?是否有初始化或終止性錯誤?　

測試步驟

•划分等價類

•選取測試用例

完全測試的困難性

如果考慮所有的可能性，黑盒測試同樣可能是天文數字

等價類划分

•等價類：某個輸入域的子集合。在該子集合中，各個輸入數據對於揭露程序中的錯誤都是等效的。

•有效等價類：對於程序的規格說明來說，是合理的，有意義的輸入數據構成的集合。

•無效等價類：對於程序的規格說明來說，是不合理的，無意義的輸入數據構成的集合。

​ 兩個有無有效的等價類這兩條需要同時考慮。

划分步驟

1： 如果輸入條件規定了取值范圍

2：如果輸入條件規定了輸入值的集合，或者規定了“必須如何”

3：如果輸入條件是一個布爾量

4：如果規定了輸入數據的一組值，而且要對每個輸入值分別進行處理。

原則5：如果規定了輸入數據必須遵守的規則

例

在某一PASCAL語言版本中規定：“標識符是由字母開頭，后跟字母或數字的任意組合構成。有效字符數為不超過8個。”
並且規定：“標識符必須先說明，再使用。” “在同一說明語句中，標識符至少必須有一個。”

邊界值分析

方法HOW

確定邊界情況

選取正好等於，剛剛大於，或剛剛小於邊界的值做為測試數據做為測試數據。

邊界指標BY

相當於輸入、輸出等價類而言，稍高、低於其邊界值的一些特定情況

含義WHAT

黑盒測試方法

對等價類划分方法的補充

原因WHY

大量的錯誤是發生在輸入或輸出范圍邊界上

邊界測試可以查出更多的錯誤

例

狀態測試

狀態測試

在黑盒測試階段，通過對狀態的測試間接地加以驗證功能

軟件狀態

軟件當前所處的條件或者模式。

除了極少數簡單程序外，均需選擇重要的內容進行測試。

建立狀態轉換圖

建立狀態轉換圖 ——> 根據狀態轉換圖設計測試用例

• 找出從一種狀態轉入另一種狀態所需的輸入和條件。
• 標識出軟件可能進入的每一種獨立狀態。
• 找出進入或退出某種狀態時的設置條件及輸出結果。

根據狀態轉換圖設計測試用例原則

• 每種狀態至少訪問一次
• 測試看起來是最常見和最普遍的狀態轉換
• 測試狀態之間最不常用的分支
• 測試所有錯誤狀態及其返回值
• 測試狀態的隨機轉換

例

(1)列出所有輸入事件

(2)從啟動開始，第一輪狀態分析

(3)從啟動開始，第二輪狀態圖分析，加入所有可能的輸入

靜態分析方法

不運行程序，通過檢查和閱讀等手段來發現錯誤並評估代碼質量的測試技術

作用

• 代碼標准、質量監控提高可靠性
• 盡早通過源代碼檢查發現缺陷
• 代碼審核定位易產生錯誤的模塊

通用評審過程

1. 計划
2. 概述
3. 准備
4. 評審會議
5. 返工
6. 追蹤

靜態分析的主要內容

​ 需求+設計+代碼

靜態分析類型

1. 同事審查

   ​ 適用於初次審查，要求最低的正式方法，也稱為伙伴審查

2. 走查

   ​ 開發組內部進行

3. 審查

   ​ 以會議形式，由開發組、測試組和相關人員聯合進行。