6.3 軟體測試技術
6.3.1軟體測試技術相關概念
軟體測試的定義
•在某種指定的條件下對系統或元件操作，觀察或記錄結果，對系統或元件的某些方面進行評估的過程。
•分析軟體各專案以檢測現有的結果和應有結果之間的差異，並評估軟體各專案的特徵的過程。
軟體缺陷
- 軟體未實現產品說明書要求的功能。
- 軟體出現了產品說明書指明不能出現的錯誤。
- 軟體實現了產品說明書未提到的功能。
- 軟體未實現產品說明書雖未明確提及但應該實現的目標。
- 軟體難以理解、不易使用、執行緩慢或者——從測試員的角度看——終端使用者會認為不好。
- 驗證（Verification）
- 保證軟體特定開發階段的輸出已經正確完整地實現了規格說明
- 確認（Validation）
- 對於每個測試級別，都要檢查開發活動的輸出是否滿足具體的需求或與這些特定級別相關的需求
軟體質量保證
建立、執行改進過程並防止缺陷的標準和方法
質量與可靠性
- 功能性（functionality）
- 可移植性（portability）
- 效率（efficiency）
- 可靠性（reliability）
- 可維護性（maintainability）
- 可用性（usability）
軟體除錯
- 目標是定位與修復缺陷
軟體測試
找出軟體缺陷，並確保修復
軟體測試的目標
- 測試用例（test case）：是測試輸入、執行條件、以及預期結果的集合，是為特定的目的開發的，例如執行特定的程式路徑或驗證與指定的需求相符合。
- 主題。設計者、型別、測試名稱、狀態、描述、優先順序、comment、步驟名、步驟描述、預期結果、評審人、評審備註、評審時間等……
軟體測試的基本原則
- 窮盡測試是不可能的
- 測試無法顯示潛伏的軟體缺陷
- 測試活動應儘早進行
- 軟體缺陷具有群聚性
- 注意“殺蟲劑”現象
- 儘量由獨立的測試團隊進行測試
評估準則
主要測試方法
白盒測試
白盒測試
-
把測試物件看做一個透明盒子，允許利用程式內部邏輯結構及有關資訊，進行測試。
-
通過在不同點檢查程式的狀態，確定實際的狀態是否與預期的狀態一致。
-
又稱為結構測試或邏輯驅動測試。
檢查範圍
-
•對程式模組的所有獨立的執行路徑至少測試一次；
-
對所有的邏輯判定，取“真”與取“假”的兩種情況都至少測試一次；
-
在迴圈的邊界和執行界限內執行迴圈體；
-
測試內部資料結構的有效性等。
完全測試的困難性
對一個具有多重選擇和迴圈巢狀的程式，不同的路徑數目可能是天文數字
例如：
執行路徑數：520條
設：每一條路徑測試需要1毫秒，如果一年工作365 × 24小時。需用時：3170年。
邏輯覆蓋
以程式內部的邏輯結構為基礎設計測試用例的技術。
- 語句覆蓋
- 分支覆蓋
- 條件覆蓋
- 條件組合覆蓋
分支覆蓋
分支覆蓋：就是設計若干個測試用例，執行被測程式，使得程式中每個判斷的取真分支和取假分支至少經歷一次。分支覆蓋又稱為判定覆蓋。
條件覆蓋
條件覆蓋：設計若干個測試用例，執行被測程式，使得程式中每個判斷的每個條件的可能取值至少執行一次。
條件組合覆蓋
條件組合覆蓋：設計足夠的測試用例，執行被測程式，使得每個判斷的所有可能的條件取值組合至少執行一次。
控制流圖覆蓋測試：是將程式碼轉變為控制流圖（CFG），基於其進行測試的技術。
程式的控制圖
- 結點：符號○ ，表示一個或多個無分支的PDL語句或源程式語句。
- 邊：箭頭，表示控制流的方向。
- 匯聚節點：在選擇或多分支結構中，分支的匯聚處應有一個匯聚結點。
- 區域：邊和結點圈定的區域。對區域計數時，圖形外的區域也應記為一個區域，即每次至少有兩個區域。
單條件巢狀
單條件巢狀：如果判斷中的條件表示式是由一個或多個邏輯運算子 (OR, AND, NAND, NOR) 連線的複合條件表示式，則需要改為一系列只有單個條件的巢狀的判斷。
節點覆蓋
對圖中的每個節點，至少要有一條測試路徑訪問該節點
顯然，節點覆蓋=語句覆蓋
邊覆蓋
對圖中每一個可到達的長度小於(無邊圖)等於1 的路徑，中至少存在一條測試路徑覆蓋。
顯然，邊覆蓋包含節點覆蓋，且邊覆蓋也可以實現分支覆蓋。
路徑覆蓋
路徑覆蓋測試：就是設計足夠的測試用例，覆蓋程式中所有可能的路徑
基本路徑覆蓋
基本路徑測試：將覆蓋的路徑數壓縮到一定限度內，程式中的迴圈體最多隻執行一次。
例
黑盒測試
-
測試物件看做一個黑盒子，測試人員完全不考慮程式內部的邏輯結構和內部特性
-
只依據程式的需求規格說明書，檢查程式的功能是否符合它的功能說明
-
又叫做功能測試或資料驅動測試。
基本思想
•把所有可能的輸入資料，即程式的輸入域劃分成若干部分，然後從每一部分中選取少數有代表性的資料做為測試用例。
檢查範圍
是否有不正確或遺漏了的功能?
在介面上，輸入能否正確地接受? 能否輸出正確的結果?是否有資料結構錯誤或外部資訊訪問錯誤?效能上是否能夠滿足要求?是否有初始化或終止性錯誤?
測試步驟
•劃分等價類
•選取測試用例
完全測試的困難性
如果考慮所有的可能性，黑盒測試同樣可能是天文數字
等價類劃分
•等價類：某個輸入域的子集合。在該子集合中，各個輸入資料對於揭露程式中的錯誤都是等效的。
•有效等價類：對於程式的規格說明來說，是合理的，有意義的輸入資料構成的集合。
•無效等價類：對於程式的規格說明來說，是不合理的，無意義的輸入資料構成的集合。
兩個有無有效的等價類這兩條需要同時考慮。
劃分步驟
1： 如果輸入條件規定了取值範圍
2：如果輸入條件規定了輸入值的集合，或者規定了“必須如何”
3：如果輸入條件是一個布林量
4：如果規定了輸入資料的一組值，而且要對每個輸入值分別進行處理。
原則5：如果規定了輸入資料必須遵守的規則
例
在某一PASCAL語言版本中規定：“識別符號是由字母開頭，後跟字母或數字的任意組合構成。有效字元數為不超過8個。”
並且規定：“識別符號必須先說明，再使用。” “在同一說明語句中，識別符號至少必須有一個。”
邊界值分析
方法HOW
確定邊界情況
選取正好等於，剛剛大於，或剛剛小於邊界的值做為測試資料做為測試資料。
邊界指標BY
相當於輸入、輸出等價類而言，稍高、低於其邊界值的一些特定情況
含義WHAT
黑盒測試方法
對等價類劃分方法的補充
原因WHY
大量的錯誤是發生在輸入或輸出範圍邊界上
邊界測試可以查出更多的錯誤
例
狀態測試
狀態測試
在黑盒測試階段，通過對狀態的測試間接地加以驗證功能
軟體狀態
軟體當前所處的條件或者模式。
除了極少數簡單程式外，均需選擇重要的內容進行測試。
建立狀態轉換圖
建立狀態轉換圖 ——> 根據狀態轉換圖設計測試用例
- 找出從一種狀態轉入另一種狀態所需的輸入和條件。
- 標識出軟體可能進入的每一種獨立狀態。
- 找出進入或退出某種狀態時的設定條件及輸出結果。
根據狀態轉換圖設計測試用例原則
- 每種狀態至少訪問一次
- 測試看起來是最常見和最普遍的狀態轉換
- 測試狀態之間最不常用的分支
- 測試所有錯誤狀態及其返回值
- 測試狀態的隨機轉換
例
(1)列出所有輸入事件
(2)從啟動開始，第一輪狀態分析
(3)從啟動開始，第二輪狀態圖分析，加入所有可能的輸入
靜態分析方法
不執行程式，通過檢查和閱讀等手段來發現錯誤並評估程式碼質量的測試技術
作用
- 程式碼標準、質量監控提高可靠性
- 儘早通過原始碼檢查發現缺陷
- 程式碼稽核定位易產生錯誤的模組
通用評審過程
- 計劃
- 概述
- 準備
- 評審會議
- 返工
- 追蹤
靜態分析的主要內容
需求+設計+程式碼
靜態分析型別
-
同事審查
適用於初次審查，要求最低的正式方法，也稱為夥伴審查
-
走查
開發組內部進行
-
審查
以會議形式，由開發組、測試組和相關人員聯合進行。