軟件測試：考點總結

引言 ⭐⭐

軟件

軟件是計算機系統中與硬件相互依存的另一部分。包括程序、數據及其文檔的完整集合。

• 程序：按實現設計的功能和性能要求執行的指令序列。
• 數據：使程序能正常操縱信息的數據結構。
• 文檔：與程序開發、維護和使用有關的圖文材料。

軟件的分類（按系統功能劃分）：

• 系統軟件：Unix、Windows
• 支撐軟件：數據庫，驅動，文件系統
• 應用軟件

測試

用任何一種可能採取的方法進行的直接實際實驗。

• 驗證特性
• 查找錯誤

軟件測試

通過一些經濟有效的方法，發現軟件中存在的缺陷，從而保證軟件質量。

軟件調試/排錯（Debug）

• 利用測試結果和測試提供的信息進行全面的分析。
• 找到錯誤的根源和出現錯誤的原因。
• 糾正已發現的問題。
  • 弄清了出錯原因和錯誤根源，立即修正。
  • 不確定出錯原因，作出推測，再次進行測試。

軟件缺陷

即指程序中存在的錯誤，也指可能出現在軟件設計過程中，甚至需求分析、規格說明或其他的文檔中的種種錯誤。

---

軟件測試概述 ⭐⭐

軟件測試的概念 ⭐

• 定義1：1983年IEEE(國際電子電氣工程師協會)提出的軟件工程標準術語中給軟件測試下的定義是：“使用人工或自動手段來運行或測定某個系統的過程，其目的在於檢驗它是否滿足規定的需求或是弄清預期結果與實際結果之間的差別”。
• 定義2：軟件測試是根據軟件開發各階段的規格說明和程序的內部結構而精心設計一批測試用例，並利用這些測試用例去執行程序，以發現軟件故障的過程。該定義強調尋找故障是測試的目的。
• 定義3：軟件測試是一種軟件質量保證活動，其動機是通過一些經濟有效的方法，發現軟件中存在的缺陷，從而保證軟件質量。

軟件測試過程 ⭐

1. 單元測試
   • 目的：檢測程序模塊中有無故障存在。
   • 對象：軟件設計的最小單位，與程序設計和編程實現關係密切。
2. 集成測試
   • 目的：發現與接口有關的模塊之間的問題。
   • 方法：非增式集成測試法和增式集成測試法。
3. 確認測試
   • 目的：對軟件產品進行評估以確定其是否滿足軟件需求的過程。
4. 系統測試
   • 目的：針對系統中各個組成部分進行的綜合性檢驗，證明系統的性能。
   • 對測試人員的要求：
     • 系統開發人員不能進行系統測試。
     • 系統開發組織不能負責系統測試。
5. 驗收測試
   • 目的：向用戶表明所開發的軟件系統能夠像用戶所預定的那樣工作。

軟件測試與軟件開發的關係 ⭐

軟件開發過程

• 第一階段 計劃：確定軟件開發的總目標。
• 第二階段 需求分析：對開發的軟件進行詳細的定義。
• 第三階段 設計：軟件工程的技術核心。
  • 概要設計：把已確定的各項需求轉換成相應的體系結構，在結構中每一組成部分都是功能明確的模塊。每個模塊都能體現相應的需求。
  • 詳細設計：對每個模塊要完成的工作進行具體的描述，包括確定使用的數據結構等。
• 第四階段 程序編寫：把軟件設計轉換成計算機可以接受的程序。
• 第五階段 測試：測試開發的軟件是否符合規格說明的要求，它是保證軟件質量的重要手段。
• 第六階段 運行和/維護：已交付給用戶的軟件投入正式使用以後便進入運行維護階段。

軟件測試在軟件開發各階段中的作用

• 項目規劃階段：負責整個測試階段的規劃。
• 需求分析階段：確定測試需求分析，制定系統測試計劃。測試需求分析是指產品生存週期中測試所需的資源、配置、各階段評審通過的標準等。
• 概要設計和詳細設計階段：制定集成測試計劃和單元測試計劃。
• 編碼階段：開發相應的測試代碼或測試腳本。
• 測試階段：實施測試，並提交相應的測試報告。

軟件測試應貫穿於軟件定義與開發的整個期間：

軟件開發經過制定計劃、需求分析、設計階段之後，才能進入編寫程序階段。但是，表現在程序中的故障，並不一定是編碼所引起的，很可能是詳細設計、概要設計階段，甚至是需求分析階段的問題引起的。即使針對源程序進行測試，所發現故障的根源也可能在開發前期的各個階段。解決問題、排除故障也必須追溯到前期的工作。因此，軟件測試應貫穿於軟件定義與開發的整個期間。

在確認軟件需求並通過評審後，概要設計和制定測試計劃可以並行工作，當系統模塊劃分好後，對各模塊的詳細設計、編碼、單元測試等也可以並行工作。其測試與軟件開發並行工作的流程如下圖：

軟件測試過程模型

V 模型

V 模型非常明確地表明瞭測試的不同級別，清晰地展示了軟件測試與開發之間的關係。

W 模型

W 模型形象地說明了軟件測試與開發的並行關係，體現了測試貫穿於整個開發過程的思想。從 W 模型很容易看出測試的對象不僅僅是程序，需求和設計階段形成的文檔同樣是軟件測試的對象。

W 模型也有侷限性。在 W 模型中，開發、測試活動都保持着一種前後關係，只有上一階段結束，纔可以正式開始下一階段的工作，因此無法支持迭代軟件開發模型。

H 模型

在 H 模型中，軟件測試的活動過程完全獨立，形成了一個完全獨立的流程，貫穿於整個產品的週期，與其他流程併發進行。

某個測試點準備就緒後就可以從測試準備階段進行到測試執行階段，軟件測試可以根據被測產品的不同分層進行。

X 模型

X 模型是對 V 模型和 W 模型的改進。X 模型提出針對單獨的程序片段進行相互分離的編碼和測試，通過頻繁的交接，最終集成爲可執行的程序。

軟件測試環境的搭建

測試環境是指用來運行軟件的環境。

測試環境 = 硬件+軟件+網絡+數據準備+測試工具

• 硬件環境
  主要是指PC機、筆記本電腦、服務器、各種PDA終端等。
• 軟件環境
  主要是軟件運行的操作系統。還有Java虛擬機，MySQL等。
• 網絡環境
  主要指的是C/S結構還是B/S結構。
• 數據準備
  主要指的是測試數據的準備。測試數據應考慮數據量和真實性，即儘可能獲得大量的真實的數據，包括正確和錯誤的數據。當無法取得真實數據時應儘可能模擬出大量的數據。
• 測試工具
  靜態測試工具、動態測試工具、黑盒測試工具、白盒測試工具、測試執行評估工具、測試管理工具等。

搭建軟件測試環境還應注意：

• 儘量模擬用戶的真實使用環境；
• 測試環境中儘量不要安裝其它與被測軟件無關的軟件，但最好安裝殺毒軟件，以確保系統中沒有病毒；
• 測試環境應與開發環境獨立。

總之，搭建的軟件測試環境應與軟件生產運行環境一致，但還要從軟件開發環境中獨立出來。

軟件測試工具

• 測試管理工具：幫助完成測試計劃，跟蹤測試運行結果。
  • 白盒測試工具：單元測試，集成測試。（靜態測試工具，動態測試工具）
  • 黑盒測試工具：集成測試，系統測試。（功能測試工具，系統測試工具）
  • 專用測試工具：其他測試。
• 測試輔助工具：
  • 測試設計和開發工具：選擇並生成測試用例。
  • 測試執行和評估工具：執行測試用例並對結果進行評估。

軟件測試的原則 ⭐

1. 儘早地和不斷地進行軟件測試：缺陷存在放大趨勢。問題發現越早，解決問題的代價就越小，這是軟件開發過程中的黃金法則。
2. 不可能完全的測試：
   • 不可能測試程序對所有可能輸入的響應。
   • 不可能測試到程序每一條可能的執行路徑。
   • 無法找出所有的設計錯誤。
   • 不能採用邏輯來證明程序的正確性。
3. 增量測試，由小到大：單元測試 → 集成測試 → 系統測試。
4. 避免測試自己的程序。
5. 注意錯誤集中的現象。
6. 確認BUG的有效性：有時候測試人員提交的BUG並不是真正的BUG。一般由A測試人員發現的BUG，一定要由另外一個B測試人員來進行確認。
7. 合理安排測試計劃：嚴謹、準確。

---

軟件缺陷 ⭐⭐

軟件缺陷概述 ⭐

軟件缺陷的定義

按照缺陷的來源，軟件缺陷分爲文檔缺陷、代碼缺陷、測試缺陷、過程缺陷。

• 文檔缺陷
  • 文檔在靜態檢查過程中發現的缺陷，通過測試需求分析、文檔審查對被分析或被審查的文檔發現的缺陷。
• 代碼缺陷
  • 對代碼進行同行評審、審計或代碼走查過程中發現的缺陷。
• 測試缺陷
  • 由測試執行活動發現的被測對象的缺陷。（被測對象一般是指可運行的代碼、系統，不包括靜態測試發現的問題）
  • 測試活動：內部測試、連接測試、系統集成測試、用戶驗收測試。
• 過程缺陷
  • 通過過程審計、過程分析、管理評審、質量評估、質量審覈等活動發現的關於過程的缺陷和問題。過程缺陷的發現者一般是質量經理、測試經理、管理人員等。

軟件缺陷的種類

1. 輸入/輸出缺陷
   • 輸入：不接受正確輸入、接受不正確輸入、描述有錯或遺漏、參數有錯或遺漏；
   • 輸出：格式有錯、結果有錯、在錯誤的時間產生正確的結果、不一致或遺漏結果、不合邏輯的結果、拼寫/語法錯誤、修飾詞錯誤。
2. 邏輯缺陷
   • 遺漏情況、重複情況、極端條件出錯、解釋有錯、遺漏條件、外部條件有錯、錯誤變量的測試、不正確的循環迭代、錯誤的操作符。
3. 計算缺陷
   • 不正確的算法、遺漏計算、不正確的操作數、不正確的操作、括號錯誤、精度不夠、錯誤的內置函數。
4. 接口缺陷
   • 不正確的中斷處理、I/O時序有錯、調用了錯誤的過程、調用了不存在的過程、參數不匹配、不兼容的類型、過量的包含。
5. 數據缺陷
   • 不正確的初始化、不正確的存儲/訪問、錯誤的標誌/索引值、不正確的打包/拆包、使用了錯誤的變量、錯誤的數據引用、縮放數據範圍或單位錯誤、不正確的數據維數、不正確的下標、不正確的類型、不正確的數據範圍、傳感器數據超出限制、出現1次斷開、不一致數據。

軟件缺陷的產生

• 疏忽造成的錯誤（Carelessness Defect，CD）
• 不理解造成的錯誤（Misapprehend Defect，MD）
• 二義性造成的錯誤（Ambiguity Defect，AD）
• 遺漏造成的錯誤（Skip Defect，SD）

軟件缺陷數目估計

1. 散播模型

$\LARGE \frac{N}{N+M}=\frac{n}{n+m}$

$\LARGE N=\frac{n}{m}*M$

$N：固有缺陷$

$M：人工植入的缺陷$

2. 靜態模型
3. 覆蓋率預測模型
   1. 錯誤與時間曲線
   2. 錯誤與覆蓋率曲線
   3. 覆蓋率與時間曲線

軟件缺陷管理

缺陷管理的目標

• 確保每個被發現的缺陷都能夠被解決。
  • 這裏解決的意思不一定是被修正，也可能是其他處理方式(例如，在下一個版本中修正或不修正)。
• 收集缺陷數據並根據缺陷趨勢曲線識別測試過程的階段。
• 收集缺陷數據並在其上進行數據分析，作爲組織的過程財富。
  • 找出預防和修復它們的方法，以及預防引入新的缺陷。

缺陷報告

缺陷報告的用途

• 記錄缺陷
• 缺陷分類
• 缺陷跟蹤

缺陷報告的特點

• 書面的：供日後對修改後的程序j進行測試時使用。
• 已編號的：依據唯一的編號跟蹤問題報告。
• 簡單的：一份報告應只描述一個問題。
• 可重現的：一定要強調 Bug 的可重現性。
• 不做判斷的：對程序員的評價要三思而後行，本着合作的精神，做出合理的判斷。

軟件缺陷管理流程 ⭐

缺陷的生命週期 ⭐

• 評估(Review)是缺陷處理的核心。由項目經理或者委員會組決定缺陷如何處理。
• 缺陷一旦被發現並且記錄下來 就處於開放(Open)狀態。
• 經過評估，決定是否解決，由誰來解決。
• 找到解決方案的軟件缺陷 (Resolved)，必須經過評估和測試驗證，才能最終關閉 (Closed)。

基本流程 ⭐

• 關鍵狀態：
  • 未經確認（Unconfirmed）
    • 直接來自最終用戶或系統外部。
  • 活躍（Active/Open）
    • 新的缺陷。
    • 直接來自內部（開發或測試）團隊。
    • 曾經關閉的缺陷，被重新激活。
  • 已分配（Assigned）
    • 經過評估，分配給相關開發人員處理。
    • 開發人員自己發現的缺陷。
    • 未通過測試的解決方案，需要進一步研究。
  • 已解決（Resolved）
    • 經過評估確認的解決方案。
  • 已驗證（Verified）
    • 測試通過，但是需要後續處理 - 歸檔，完善測試覆蓋，原因分析。
    • 測試不通過，重新分配給開發人員。
  • 關閉（Close）
    • 處理完畢。
• 實際情況不必經過每一個狀態。

---

黑盒測試 ⭐⭐⭐⭐

黑盒測試的基本概念 ⭐

• 黑盒測試：不考慮內部實現，依據輸入輸出設計實驗。
• 白盒測試：依據內部的實現邏輯設計測試。
• 灰盒測試：在實際工作中，需要結合黑盒測試和白盒測試。

測試用例：爲實施測試而向被測試系統提供的輸入數據、操作或各種環境設置以及期望結果的一個特定的集合。

黑盒測試是從一種從軟件外部對軟件實施的測試，也稱功能測試或基於規格說明的測試。其基本觀點是：任何程序都可以看作是從輸入定義域到輸出值域的映射，這種觀點將被測程序看作一個打不開的黑盒，黑盒裏面的內容(實現)是完全不知道的，只知道軟件要做什麼。

黑盒測試是從用戶觀點出發的測試，其目的是儘可能發現軟件的外部行爲錯誤。

黑盒測試的兩個顯著優點：

• 黑盒測試與軟件具體實現無關，所以如果軟件實現發生了變化，測試用例仍然可以使用。
• 設計黑盒測試用例可以和軟件實現同時進行，因此可以壓縮項目總的開發時間。

等價類劃分法 ⭐

完全不考慮程序的內部結構，只根據程序規格說明書對輸入範圍進行劃分，把所有可能的輸入數據，即程序輸入域劃分爲若干個互不相交的子集，稱爲等價類，然後從每個等價類中選取少數具有代表性的數據構成測試用例，然後進行測試。

等價類劃分法的原理

所謂等價類是指輸入域的某個互不相交的子集合，所有等價類的並便是整個輸入域。

1. 劃分等價類

   • 有效等價類：檢驗程序是否實現了規格預先規定的功能和性能。
   • 無效等價類：檢查軟件功能和性能的實現是否有不符合規格說明要求的地方。

2. 常用的等價類劃分原則

   • 按區間劃分；
   • 按數值劃分；
   • 按數值集合劃分；
   • 按限制條件或規則劃分；
   • 細分等價類。
   • 同樣，可按輸出條件，將輸出域劃分成若干等價類。
   • 列出所有劃分出的等價類表。（| 輸入條件 | 有效等價類 | 無效等價類 |）

3. 等價類劃分測試用例

   • 確定輸入需求及輸入項。
   • 爲每個等價類規定一個唯一的編號。
   • 設計一個新的測試用例，儘可能多地覆蓋尚未被覆蓋的有效等價類，直到測試用例覆蓋了所有的有效等價類（包括輸出域）。
   • 設計一個新的測試用例，使其覆蓋並且只覆蓋一個還沒有被覆蓋的無效等價類，直到測試用例覆蓋了所有的無效等價類。

4. 等價類測試的兩個問題

• 規格說明往往沒有定義無效測試用例的期望輸出應該是什麼樣的。因此，測試人員需要花費大量時間來定義這些測試用例的期望輸出。
• 強類型語言沒有必要考慮無效輸入。

等價類劃分法的測試運用

示例一：三角形問題

示例二：保險公司保費計算程序

邊界值分析法 ⭐

大量的軟件測試實踐表明，故障往往出現在定義域或值域的邊界上，而不是在其內部。

爲檢測邊界附近的處理專門設計測試用例，通常都會取得很好的測試效果。

邊界值分析法的原理

1. 邊界條件

• 邊界是一些特殊情況。
  • 程序在處理大量中間數值時都是正確的，但是在邊界處可能出現錯誤。邊界條件就是軟件計劃的操作界限所在的邊緣條件。
• 一些可能與邊界有關的數據類型有：數值、速度、字符、地址。位置、尺寸、數量等。

邊界值和等價類密切相關，從等價類中選取測試數據時應該關注邊界值。

在等價類劃分基礎上進行邊界值分析測試的基本思想是：選取正好等於、剛剛大於或剛剛小於等價類邊界的值作爲測試數據，而不是選取等價類中的典型值或任意值作爲測試數據。

2. 邊界值分析測試

邊界值分析利用輸入變量的最小值（min），稍大於最小值（min+），域內任意值（nom），稍小於最大值（max-），最大值（max）來設計測試用例。

對於一個n變量的程序，邊界值分析測試會產生4n+1個測試用例。

3. 健壯性邊界值測試

健壯性測試是邊界值分析的一種擴展。考慮一個略超過最大值（max+）以及一個略小於最小值（min-）的取值，看看超過極限值時系統會出現什麼情況。

對於一個n變量的程序，健壯性邊界值測試會產生6n+1個測試用例。

健壯性測試最有意義的部分不是輸入，而是預期的輸出，觀察例外情況如何處理。（是否會失控或出現可怕的情形）

對於強類型語言，健壯性測試可能比較困難。

4. 邊界值分析法的侷限性

• 基於函數輸入定義域的測試方法，是所有測試方法中最基本的。
• 這類測試方法都有一種假設，即輸入變量是真正獨立的。
• 如果不能保證這種假設，則這類方法不能產生令人滿意的測試用例。

邊界值分析法的測試運用

示例一：三角形問題

邊界值分析測試：4*3+1=13

示例二：加法器

測試用例不全，少了10個：4*2+7*2+1=23

因果圖法 ⭐

等價類劃分法和邊界值分析法都是着重考慮輸入條件，如果程序輸入之間沒有什麼聯繫，採用等價類劃分和邊界值分析是一種比較有效的方法。

如果輸入之間有關係，例如，約束關係、組合關係，這種關係用等價類劃分的邊界值分析是很難描述的，因此必須考慮使用一種適合於描述對於多種條件的組合，產生多個相應動作的測試方法。

因果圖法的原理

1. 因果圖

2. 約束

在實際問題中，輸入狀態之間可能存在某些依賴關係，稱之爲約束。

• 輸入條件的約束：
  • 異或（Exclusive，E）；
  • 或（Inclusive，I）；
  • 唯一（One and Only，O）；
  • 需要（Require，R）；
• 輸出條件的約束：
  • 強制（Mask，M）。

3. 因果圖法測試用例的設計步驟

• 確定軟件規格中的原因和結果。
• 確定原因和結果之間的邏輯關係，根據這些關係畫出因果圖。
• 確定因果圖中的各個約束，在因果圖上用一些記號表明約束或限制條件。
• 把因果圖轉換爲決策表。
• 根據決策表設計測試用例。

因果圖法的測試運用

決策表法 ⭐

在所有的黑盒測試方法中，基於決策表的測試是最嚴格的，最具有邏輯性的測試方法。

決策表法的原理

1. 決策表

決策表是把作爲條件的所有輸入的各種組合值以及對應輸出值都羅列出來而形成的表格。

它能夠將複雜的問題按照各種可能的情況全部列舉出來，簡明並避免遺漏。因此，利用決策表能夠設計出完整的測試用例集合。

決策表通常由條件樁、條件項、動作樁和動作項四部分組成。動作項和條件項緊密相關，指出在條件項的各組取值情況下應該採取的動作。

規則是指：任何一個條件組合的特定取值及其相應要執行的操作。

• 決策表的組成：

2. 決策表的構造

   1. 列出所有的條件樁和動作樁；
   2. 確定規則的個數；
   3. 填入條件項；
   4. 填入動作項，得到初始決策表；
   5. 簡化決策表，合併相似規則。

3. 決策表的化簡

對於n個條件的決策表，相應有$2^n$個規則(每個條件分別取真、假值)，當n較大時，決策表很繁瑣。實際使用決策表時，常常先將它簡化。

決策表的簡化是以合併相似規則爲目標。即若表中有兩條以上規則具有相同的動作，並且在條件項之間存在極爲相似的關係，便可以合併。

決策表法的測試運用

狀態圖法

1. 畫出狀態圖

   1. 列出被測系統的輸入事件；
   2. 對空閒狀態（程序剛啓動時的狀態）加所有可能的輸入，判斷產生哪些新狀態；
   3. 對上一步產生的每個新狀態分別加所有可能的輸入。

2. 編寫測試用例

   1. 每種狀態至少訪問一次；
   2. 測試看起來最普遍的狀態轉換；
   3. 測試狀態之間最不常用的分支；
   4. 測試所有錯誤狀態及其返回值；
   5. 利用工具自動執行狀態轉換測試。

其他黑盒測試方法

• 特殊值測試
• 故障猜測法

黑盒測試方法的比較與選擇 ⭐

• 等價類分析測試中，通過等價類劃分來減少測試用例的絕對數量。
• 邊界值分析方法則通過分析輸入變量的邊界值域設計測試用例。
• 因果圖測試方法考慮到輸入條件和輸出結果間的依賴關係和制約關係。
• 決策表方法全面的列出可能輸入組合，並通過制約關係和合並的方法來減少測試用例。
• 狀態圖法側重於過程間的轉換動作及轉換狀態。

測試工作量

1. 測試用例數量（邊界值分析>等價類劃分>決策表）
   • 邊界值分析：不考慮數據或邏輯依賴關係，機械地根據各邊界生成測試用例。但會生成大量測試用例，機器執行時間長。
   • 等價類劃分：則關注數據依賴關係和函數本身，考慮如何劃分等價類，隨後也是機械地生成測試用例。
   • 決策表技術：最精細，既要考慮數據，又要考慮邏輯依賴關係。但生成的測試用例少，機器執行時間短。
2. 設計測試用例的工作量（邊界值分析<等價類劃分<決策表）
   • 決策表：測試用例生成所需的工作最大。但生成的測試用例少，機器執行時間短。
   • 邊界值分析：測試方法使用簡單，但會生成大量測試用例，機器執行時間長。

測試方法研究的目的就是在開發測試用例工作量和測試執行工作量之間做一個令人滿意的折中。

測試有效性

解釋測試有效性是很困難的。我們能夠做的，只是根據不同類型的故障，選擇最有可能發現這種缺陷的測試方法。

• 如果變量引用的是物理量，可採用邊界值分析測試和等價類測試。
• 如果變量是獨立的，可採用邊界值分析測試和等價類測試。
• 如果變量不是獨立的，可採用決策表測試。
• 如果可保證是單缺陷假設，可採用邊界值分析和健壯性測試。
• 如果程序包含大量例外處理，可採用健壯性測試和決策表測試。
• 如果變量引用的是邏輯量，可採用等價類測試和決策表測試。

黑盒測試工具

• QTP
• Selenium

黑盒測試練習題

---

白盒測試 ⭐⭐⭐⭐⭐

白盒測試概述 ⭐

白盒測試的特性

• 又稱透明盒測試、結構測試、邏輯驅動測試或基於程序的測試。
• 是測試被測單元內部如何工作的一種測試方法。
• 允許測試人員根據程序內部邏輯結構及有關信息來設計和選擇測試用例，對程序的邏輯結構進行測試。
• 可覆蓋全部代碼、分支、路徑和條件等。

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

白盒測試和黑盒測試都是軟件測試的一個方面，白盒測試與黑盒測試的區別如下：

白盒測試	黑盒測試
需要源代碼	不需要源代碼，需要可執行文件
無法檢驗程序的外部特性，無法測試遺漏的需求	從用戶的角度出發進行測試
關心程序內部結構、邏輯以及代碼的可維護性	關心程序的外在功能和非功能表現
編碼、集成測試階段進行	確認測試、系統測試階段進行

白盒測試的策略

1. 桌前檢查（Desk Check）：程序員檢查自己的程序；檢查變量、常量、風格等，補充桌前檢查文檔。
2. 同行評審（Peer Review）：召開程序審查會，程序員逐句講解程序的邏輯，其他成員提問，展開討論。
3. 代碼走查（Walk Through）：走查小組集體扮演計算機的角色，讓測試用例沿程序的邏輯運行一遍，記錄軌跡，供分析討論。
4. 靜態分析（Static Analyse）：結構分析、質量度量、模式匹配。
5. 單元測試（Unit Testing）：邏輯覆蓋、功能驗證、輔助插裝(插樁instrumentation)、程序變異。

邏輯驅動覆蓋測試 ⭐

特性

• 針對程序的內部邏輯結構設計測試用例；
• 通過運行測試用例達到邏輯覆蓋目的；
• 是最傳統最經典的白盒測試技術；
• 要求測試人員對程序邏輯結構非常清楚。

基本概念

函數的控制流圖：通常一個程序控制流圖可表示爲（N，E，entry，exit）：

• N：節點的集合，反映程序中的語句；
• E：有向邊的集合，反映程序中語句間的控制流關係；
• entry：程序的固定的唯一入口節點；
• exit：程序唯一的退出節點。

控制流圖即是具有單一的，固定的入口節點和出口節點的有向圖。

控制流覆蓋準則（重點）

• 覆蓋準則
  • 評價白盒測試中測試用例的好壞。
  • 測試結束的量化指標。
• 語句覆蓋準則
  • 語句覆蓋就是設計若干個測試用例，運行被測試程序，使得每一條可執行語句至少執行一次。
• 分支覆蓋準則
  • 設計若干個測試用例，運行所測程序，使程序中每個判斷的取真分支和取假分支至少執行一次。
• 謂詞覆蓋準則
  • 原子謂詞覆蓋準則
    • 設計足夠多的測試用例，運行所測程序，使程序中每個複合謂詞所包含的每一個原子謂詞都至少獲得一次“真”值和一次“假”值。
  • 分支——謂詞覆蓋準則
    • 設計足夠多的測試用例，運行所測程序，使程序中不僅每個複合謂詞所包含的每一個原子謂詞都至少獲得一次“真”值和一次“假”值，而且每個複合謂詞本身也至少獲得一次“真”值和一次“假”值。
  • 複合謂詞覆蓋準則
    • 設計足夠多的測試用例，運行所測程序，使程序中每個謂詞中條件的各種可能都至少出現一次。
• 路徑覆蓋準則
  • 設計足夠多的測試用例，覆蓋被測試對象中的所有可能路徑。
• 各種覆蓋準則間的關係（重點）
  • 箭頭表示包含關係。
  • 原子謂詞覆蓋不包含語句覆蓋或分支覆蓋。

控制流覆蓋準則：應用舉例

代碼審查 ⭐

• 代碼審查（Code Review）是軟件靜態測試中常用的軟件測試方法之一，更容易發現架構以及時序相關等較難發現的問題。
• 幫助團隊成員統一編程風格，提高編程技能等。
• 代碼審查被公認爲是一個提高代碼質量的有效手段。

代碼審查的意義

代碼審查包含對錯誤代碼的檢查，和不好的編碼風格代碼的檢查。

• 可靠性
• 可讀性/維護性
• 移植性

代碼審查的內容

• 可追溯性
• 邏輯
• 數據
• 接口
• 文檔
• 註釋
• 異常處理
• 內存
• 其它

代碼審查的過程

• 代碼審查策劃階段
• 代碼審查實施階段
  • 代碼講解
  • 靜態分析
  • 規則檢查
  • 正式代碼檢查
  • 更改確認
• 代碼審查總結階段

代碼走查 ⭐

代碼走查（Code Walkthrough􏰅􏰵􏰌􏰀􏰴􏰗􏰾􏰶）是軟件靜態測試方法之一，是通過對代碼的閱讀，檢查發現程序代碼中的問題。

具體方法

由測試人員組成小組，準備一批有代表性的測試用例，集體扮演計算機的角色，沿程序的邏輯，逐步運行測試用例，查找被測軟件缺陷。

代碼走查的意義

• 經驗表明，代碼走查通常能夠有效地查找出**30%~70%**的邏輯設計和編碼錯誤。
• 一旦發現錯誤，通常就能在代碼中對其進行精確定位，降低了調試的成本。
• 代碼走查過程通常可以發現成批的錯誤，這樣錯誤就可以一同得到修正。

代碼走查的過程

• 準備階段
• 生成實例
• 執行走查
• 形成報告

程序變異測試

對於給定程序 P，假定程序中存在一個錯誤 e 使 P 變成 P’。理論上，如果 P 是正確的，那麼 P’ 肯定是錯誤的。對測試數據 C，運行 C，如果對於每個 C，P 都是正確的，P’ 都是錯誤的，這說明 P 的正確性較高。如果對某個 Ci，P 是錯誤的，而 P’ 是正確的，這就說明 P 存在錯誤，而錯誤就是 e。這裏 P’ 稱爲 P 的變異因子。

變異測試的關鍵是如何產生變異因子。常用的方法是通過對原來的被測程序作用變異算子來產生變異因子。

一個變異算子是一個程序轉換規則，它把一種語法結構改變成另一種語法結構，保證轉換後的程序的語法正確，但不保證語義的一致。

• 表達式a < b 換成 a > b、a=b、a!=b。
• 把變量設成某常量C。
• 把常量C1換成C2。

程序強變異測試：缺點是需要大量的計算機資源來完成測試充分性分析。對於一箇中等規模的軟件，所需的存儲空間也是巨大的，運行大量的變異因子也導致了時間上巨大的開銷。
程序弱變異測試：主要差別是弱變異強調的是變動程序的組成部分。

白盒測試工具

• Emma
• C++test
• JUnit
• Testbed

單元測試工具CTS

白盒靜態測試

代碼檢查

• 規則類
• 疑問類
• 故障類

靜態結構分析

• 控制流分析
• 數據流分析
• 調用關係分析

代碼質量度量

• 採用度量統計的方法分析程序的某些質量因素。
• 質量模型的建立：
  • 規則（Metrics）：量化的行爲規範
  • 分類標準（Criteria）：由一系列質量規則組成
  • 質量因素（Factor）：根據各分類標準取值組合權重來計算
• 規則Kiviat圖
• 分類標準Kiviat圖

---

基於缺陷模式的軟件測試 ⭐⭐⭐

基於缺陷模式的軟件測試概述 ⭐

缺陷模式

• 程序中經常發生的錯誤或缺陷所呈現的語法及語義特徵。
• 通常由具有領域程序設計經驗的程序員或者測試人員總結出來。
• 不同的編程語言，往往對應於不同的缺陷模式集。

基於缺陷模式的軟件測試技術特點

• 針對性強。
  • 如果說某種模式的缺陷是經常發生的，並且在被測軟件中是存在的，則面向缺陷的測試可以檢測出此類缺陷。
• 往往能發現其他測試技術難以發現的故障。
• 工具自動化程度高以及測試效率高。
• 缺陷定位準確。

缺陷模式及實例 ⭐

以缺陷產生後果的嚴重性高低爲評判標準，從程序的源代碼形式着眼，對缺陷模式進行分類：

• 故障模式
• 安全漏洞模式
• 疑問代碼模式（Book：缺陷模式）
• 規則模式

故障模式

一經產生，會導致系統異常或出錯。

1. 存儲泄露的故障模式（Memory Leak Fault，MLF）
   • 遺漏故障：申請的內存沒有被釋放。
   • 不匹配故障：申請函數和釋放函數不匹配。
   • 不相等的釋放錯誤：釋放的空間和申請的空間大小不一樣。
2. 數組越界故障模式（Out of Bounds Array Access Fault，OBAF）
3. 使用未初始化變量故障模式（Uninitialized Variable Fault，UVF)
4. 空指針使用故障（NULL Pointer Dereference Fault，NPDF）
5. 非法計算類故障（Illegal Computing Fault，ILCF）
6. 死循環結構模式（Dead Loop Fault，DLF）
7. 資源泄露故障（Resource Leak Fault，RLF）
   • 當一個資源被打開後，如果並不是在所有的可執行路徑上對其進行了顯式的釋放操作，則是一個資源泄露故障。
8. 併發故障模式

安全漏洞模式

此類缺陷會給系統留下安全隱患，爲攻擊該系統開了綠燈。

1. 緩衝區溢出（buffer overflow）漏洞模式
   • 主要類型：
     • 數據拷貝造成的緩衝區溢出。
     • 格式化字符串造成的緩衝區溢出。
2. 未驗證輸入（Tainted Data）
   • 程序從外部獲取數據時，這些數據可能含有欺騙性或者是不想要的垃圾數據，如果在使用這些數據前不進行合法性檢查則將威脅到程序的安全。
   • 主要類型：
     • 使用的數據來自外部的全局變量。
     • 使用的數據來自輸入函數。
3. 競爭條件（Race Condition）
   • 如果程序中有兩種不同的I/O調用同一文件進行操作，而且這兩種調用是通過絕對路徑或相對路徑引用文件的，那麼就容易出現Race Condition問題。在兩種操作進行的間隙，黑客可能改變文件系統，那麼將會導致對兩個不同的文件操作而不是同一文件進行操作。
   • 發生在用戶擁有不同的權限運行的程序中（例如：setuid程序、數據庫和服務器程序等）。
4. 風險操作（Risky Operation）
   • 不恰當地使用了某些標準庫函數（例如：rand（）生成的口令很容易被猜測到）。

疑問代碼模式（缺陷模式）

PPT：此類問題未必會造成系統的錯誤，可能是誤操作造成的，或者是由工程師不熟悉開發程序造成的，起到提示作用。

Book：此類缺陷是不應該發生的，它未必會造成系統的錯誤，但可能會隱含某些故障。

1. 性能缺陷（低性能模式）：此類缺陷會降低系統的性能，導致軟件運行效率低下，可以採用更高效的代碼來完成同樣的功能。
   • 低效函數/代碼
   • 多餘函數
   • Java中的顯式垃圾回收
   • 冗餘代碼
   • 頭文件中定義的靜態變量
   • 不必要的文件包含
   • 字符串低效操作
   • 更簡單的運算符替代
2. 爭議代碼：讓人費解的代碼。

規則模式

1. 聲明定義
2. 版面書寫
3. 分支控制
4. 指針使用
5. 運算處理

---

集成測試 ⭐

集成測試概述

集成測試的概念 ⭐

• 集成（Integration）：把多個單元組合起來形成更大的單元。
• 集成測試（Integration Testing）：在假設各個軟件單元已經通過了單元測試的前提下，檢查各個軟件單元接口之間的協同工作（參數、全局數據結構、文件、數據庫）是否正確。
  • 通常採用黑盒測試用例設計方法、灰盒測試方法。

集成測試主要關注的問題

• 模塊間的參數傳遞是否正確？（參數個數、類型、次序）
• 一個模塊的功能是否會對另一個模塊的功能產生錯誤的影響？（資源內容及操作）
• 全局數據結構是否有問題，會不會被異常修改？（使用一致性）
• 集成後各個模塊的累積誤差是否會擴大，是否達到不可接受的程度？（精度缺失、邏輯錯誤）
• 模塊組合起來的功能是否滿足要求？（需求覆蓋）

模塊分析

集成測試的第一步，也是最重要的工作之一。

一般將模塊劃分爲3個等級：高危模塊、一般模塊和低危模塊，高危模塊應該優先測試。

模塊的劃分常常遵循下列幾個原則：

• 本次測試希望測試哪個模塊。
• 把與該模塊最緊密的模塊聚集在一起。
• 再考慮劃分後的外圍模塊，並分析外圍模塊和被集成模塊之間的信息流是否容易模擬和控制。

集成測試與系統測試的區別 ⭐

測試對象	集成	系統
測試時間	開發過程	開發完成
測試方法	黑白結合	黑盒
測試內容	接口（各模塊之間的接口，以及集成後的功能）	需求（整個系統的功能）
測試目的	接口錯誤	需求不一致
測試角度	開發者	用戶

集成測試與開發的關係

軟件開發的 V 模型：

• 需求分析->概要設計->詳細設計->編碼
• 系統測試<-集成測試<-單元測試<-編碼

集成測試與軟件開發過程中的概要設計階段相對應，軟件概要設計中關於整個系統的體系結構是集成測試用例輸入的基礎。

集成測試的層次與原則

集成測試的層次

• 傳統軟件按集成粒度不同：
  • 模塊內集成測試
  • 模塊間集成測試
  • 子系統內集成測試
  • 子系統間集成測試
• 面向對象的應用系統按集成粒度不同：
  • 類內集成測試
  • 類間集成測試

集成測試的原則

• 所有公共接口必須被測試到
• 關鍵模塊必須進行充分測試
• 集成測試應當按一定層次進行

集成測試策略 ⭐

輔助模塊

• 驅動模塊（Driver）：用以模擬待測模塊的上級模塊；
• 樁模塊（Stub）：用以模擬待測模塊工作過程中所調用的模塊。

非漸增式集成

首先對每個子模塊進行測試（單元測試），然後將所有模塊全部集成起來一次性進行集成測試。

該方法只適用於規模較小的應用系統，在大、中型系統中一般不推薦使用這種方法。

漸增式集成

把下一個要測試的模塊同已經測試好的模塊結合起來進行測試，然後再把下一個待測試的模塊結合起來進行測試。

可以同時完成單元測試和集成測試。

• 容易定位和改正錯誤；
• 對接口可以進行更徹底的測試；
• 可以使用系統化的測試方法。

目前在進行集成測試時普遍採用漸增式集成方法。

• 自頂向下集成
• 自底向上集成
• 三明治集成

自頂向下集成

從主控制模塊開始，沿着程序的控制層次向下移動，逐漸把各個模塊結合起來。

使用深度優先的策略，或者使用寬度優先的策略。

1. 對主控制模塊進行測試，測試時用樁模塊代替所有直接附屬於主控制模塊的模塊。
2. 根據選定的結合策略（深度優先或寬度優先），每次用一個實際模塊替換一個樁模塊（新結合進來的模塊往往又需要新的樁模塊）。
3. 爲了保證加入的模塊沒有引入新的錯誤，可能需要進行迴歸測試（即，全部或部分地重複以前做過的測試）。

優點：

1. 可以及早發現主控模塊的問題並解決。
2. 如果選擇深度優先的結合方法，可以在早期驗證一個完整的功能，增強開發人員和用戶雙方的信心。

缺點：用樁模塊代替了低層次的實際模塊，沒有重要的數據自下往上流。

自底向上集成

從“原子”模塊（即最底層的模塊）開始組裝和測試。

不需要樁模塊。

1. 把底層模塊組合成實現某個特定的軟件子功能的族。
2. 寫一個驅動程序（用於測試的控制程序），協調測試數據的輸入和輸出。
3. 對由模塊組成的子功能族進行測試。
4. 去掉驅動程序，沿軟件結構自下向上移動，把子功能族組合起來形成更大的子功能組。

三明治集成

• 混合增量測試策略，綜合了自頂向下和自底向上兩種集成方法的優點。
• 樁模塊和驅動模塊的開發工作都比較小。
• 代價：一定程序上增加了定位缺陷的難度。

1. 確定以哪一層爲界來進行集成，如 B 模塊。
2. 對模塊 B 及其所在層下面的各層使用自底向上的集成策略。
3. 對模塊 B 所在層上面的層次使用自頂向下的集成策略。
4. 對模塊 B 所在層各模塊同相應的下層集成。
5. 對系統進行整體測試。

示例：

1. 對模塊 E、F、G 分別進行單元測試；
2. 對模塊 A 進行測試；
3. 把模塊 E、F 同 B 模塊集成並進行測試；
4. 把模塊 C、G 集成並進行測試；
5. 對所有模塊集成並進行測試。

集成測試用例設計

1. 爲系統運行設計測試用例
   • 達到合適的功能覆蓋率和接口覆蓋率
   • 測試分析技術：
     • 等價類劃分
     • 邊界值分析
     • 基於決策表的測試
     • 正交實驗法
     • 狀態圖法
2. 爲正向集成測試設計用例
   • 測試目標：驗證集成後的模塊是否按照設計實現了預期的功能
   • 測試分析技術：
     • 輸入域測試
     • 輸出域測試
     • 等價類劃分
     • 狀態轉換測試
     • 規範導出法
3. 爲逆向集成測試設計用例
   • 測試目標：分析被測接口是否實現了需求規格沒有描述的功能，檢查規格說明中可能出現的接口遺漏等
   • 測試分析技術：
     • 錯誤猜測法
     • 基於風險的測試
     • 基於故障的測試
     • 邊界值測試
     • 特殊值測試
     • 狀態轉換測試
4. 爲滿足特殊需求設計用例
   • 測試目標：接口的安全性指標、性能指標等
   • 測試分析技術：規範導出法
5. 爲覆蓋設計用例
   • 測試分析技術
     • 功能覆蓋分析
     • 接口覆蓋分析

集成測試過程

• 計劃階段
• 設計階段
• 實施階段
• 執行階段
• 評估階段

---

系統測試 ⭐⭐⭐

開發的軟件只是實際投入使用系統的一個組成部分，還需要檢測它與系統其它部分能否協調地工作，這就是系統測試的任務。

系統測試實際上是針對系統中各個組成部分進行的綜合性檢驗，很接近人們的日常測試實踐。

性能測試 ⭐

性能測試的基本概念

性能：是一種表明軟件系統或構件對於及時性要求的符合程度的指標。是軟件產品的一種特性，可以用時間來度量。性能及時性通常用系統對請求做出響應所需要的時間來度量。

性能測試：檢驗軟件是否達到需求說明書中規定的各類性能指標，並滿足一些性能相關的約束和限制條件。

性能測試的目的：通過測試，確認軟件是否滿足產品的性能需求，同時發現系統中存在的性能瓶頸，並對系統進行優化。

性能測試包括以下幾個方面：

• 評估系統的能力
• 識別系統中的弱點
• 系統調優

性能測試方法

性能測試方法：

• 基準法
• 性能下降曲線分析法

基準法中關於性能測試的基準：

• 響應時間：對用戶來講，響應時間的長短沒有絕對的區別，合理的響應時間取決於實際的用戶需求。
• 併發用戶：系統用戶數，同時在線用戶數，同時操作用戶數（併發用戶數）。
• 吞吐量：指單位時間內系統處理的客戶請求數量。可以直接體現系統的性能。
• 性能計數器：是描述服務器或操作系統性能的一些數據指標。計數器在性能測試中發揮着監控和分析的關鍵作用。
  • e.g. Windows 系統管理器就是一個性能計數器，它提供了測試機 CPU、內存、網絡和硬盤的使用信息。

性能測試執行

1. 計劃階段
2. 測試階段
3. 分析階段

壓力測試 ⭐

壓力測試的基本概念

壓力測試（Stress Testing）是指模擬巨大的工作負荷，以查看系統在峯值使用情況下是否可以正常運行。

壓力測試是通過逐步增加系統負載來測試系統性能的變化，並最終確定在什麼負載條件下系統性能處於失效狀態，一次來獲得系統性能提供的最大服務級別的測試。

壓力測試的特點

• 壓力測試是檢查系統處於壓力情況下的能力表現。通過不斷增加系統壓力，來檢測系統在不同壓力情況下所能夠到達的工作能力和水平。壓力測試一般通過模擬方法進行。
• 壓力測試是一種極端情況下的測試，所以爲了捕獲極端狀態下的系統表現往往採用模擬方法進行。通常在系統對內存和 CPU 利用率上進行模擬，已獲得測量結果。
• 壓力測試一般用於測試系統的穩定性。
• 與性能測試的聯繫與區別：
  • 壓力測試用來保證產品發佈後系統能否滿足用戶需求，關注的重點是系統整體；
  • 性能測試可以發生在各個測試階段，即使是在單元層，一個單獨模塊的性能也可以進行評估。
  • 壓力測試是通過確定一個系統的瓶頸，來獲得系統能提供的最大服務級別的測試，是極端情況下的系統能力的表現；
  • 性能測試是檢測系統在一定負荷下的表現，是正常能力的表現。

壓力測試方法

• 重複：一遍又一遍地執行某個操作或功能。
• 併發：同時執行多個操作的行爲，即在同一時間執行多個測試線程。
• 量級增加：壓力測試可以重複執行一個操作，但是操作自身也要儘量給產品增加負擔。
• 隨機：對上述測試手段進行隨機組合，以便獲得最佳的測試效果。

壓力測試執行

• 檢查是否有足夠的磁盤空間。
• 檢查是否有足夠的內存空間。
• 創造極端的網絡負載。
• 製造系統溢出條件。

健壯性測試 ⭐

健壯性測試的基本概念

健壯性測試（Robustness Testing）：

• 主要用於測試系統抵禦錯誤的能力。
• 這裏的錯誤通常是指由於設計缺陷而帶來的系統錯誤。測試的重點爲當出現故障時，是否能夠自動恢復或忽略故障自動運行。

健壯性有兩層含義：一是高可靠性，二是從錯誤中恢復的能力。

• 可靠性體現了軟件系統的質量，需要根據符合規格說明的數據選擇測試用例，用於檢測在正常情況下系統輸出的正確性。
• 從錯誤中恢復的能力體現了軟件系統的適應性，需要在異常數據中選擇測試用例，檢測非正常情況下的系統行爲。

健壯性測試方法

評估系統的健壯性：

• 通過
• 災難性失效
• 重啓失效
• 夭折失效
• 沉寂失效
• 干擾失效

自動化實現測試內容時需要把握的原則：

• 可移植性
• 覆蓋率
• 可擴展性
• 測試結果的記錄

安全性測試 ⭐

安全性測試的基本概念

安全性測試：檢查系統對非法侵入的防範能力，其目的是爲了發現軟件系統中是否存在安全漏洞。軟件安全性是指在非正常條件下不發生安全事故的能力。

系統安全設計的準則：使非法侵入的代價超過被保護的信息的價值，從而令非法侵入者無利可圖。

安全性測試手段

測試者扮演一個是試圖攻擊系統的角色：

• 嘗試通過外部的手段來獲取系統的密碼。
• 使用能夠瓦解任何防護的客戶軟件來攻擊系統。
• 把系統“制服”，使別人無法訪問。
• 有目的地引發系統錯誤，期望在系統恢復過程中侵入系統。
• 通過瀏覽非保密的數據，從中找到進入系統的鑰匙。

安全性測試層次

• 應用程序級別的安全性：對數據或業務功能的訪問。
• 系統級別的安全性：對系統的登錄或遠程訪問。

二者的關係：應用級別的安全性可確保在預期的安全性情況下，操作者只能訪問特定的功能或用例，或者只能訪問有限的數據。系統級別的安全性可確保只有具備系統訪問權限的用戶才能訪問應用程序，而且只能通過相應的入口來訪問。

安全性測試方法

• 功能驗證
• 漏洞掃描
  • 主機漏洞掃描器（Host Scanner）
  • 網絡漏洞掃描器（Network Scanner）
• 模擬攻擊
  • 冒充
  • 重演
  • 消息篡改
  • 拒絕服務
  • 內部攻擊
  • 外部攻擊
  • 陷阱
  • 木馬
• 偵聽技術

可靠性測試 ⭐

可靠性測試的基本概念

• 軟件可靠性：在規定時間、規定的運行剖面上運行規定的軟件，測試其是否能夠正常執行的能力。
• 度量指標：
  • 平均無故障時間是否超過規定時限
  • 因故障而停機的時間在一年中不應超過多少時間
• 可用軟件可靠性模型來評估這些指標的有效性。

可靠性測試的基本參數

• 故障率（λ）：總失效次數/總工作時間
• 維修率（μ）：總失效次數/總維護時間
• 平均無故障時間（MTBF）：總工作時間/總失效次數
• 平均維護時間（MTTR）：總維護時間/總失效次數
• 有效度（A）：總工作時間/(總工作時間+總維護時間)
• 殘留的缺陷數目（N0）
• 可靠性：R（t）= e ^ {-f^t_0 λ(t)dt}

恢復性測試 ⭐

主要檢查系統的容錯能力。

當系統出錯時，能否在指定時間間隔內修正錯誤並重新啓動系統。恢復測試首先要採用各種方法強迫系統失敗，然後驗證系統是否能儘快恢復。

備份測試 ⭐

備份測試是恢復性測試的一個補充，也是恢復性測試的一個部分。

備份測試的目的是驗證系統在軟件或者硬件失敗時備份數據的能力。

兼容性測試 ⭐

兼容性測試是指檢查軟件之間是否能夠正確地進行交互和共享信息。

軟件兼容性測試需要解決的問題：

• 軟件設計需求與運行平臺的兼容性。
• 軟件的行業標準或規範，以及如何達到這些標準和規範的條件。
• 被測軟件與其它平臺、其它軟件交互或共享的信息。

兼容性測試：

• 向前和向後兼容
• 不同版本之間的兼容性
• 標準和規範
• 數據共享兼容性

安裝性測試 ⭐

軟件運行的第一件事就是安裝（嵌入式軟件除外），安裝測試是軟件測試首先需要解決的問題。

安裝測試需要不僅要考慮在不同的操作系統上運行，還要考慮與現有軟件系統的配合使用問題。

可用性測試 ⭐

可用性測試（Usability Testing）：對於用戶友好型的測試，是指在設計過程中被用來改善易用性的一系列方法。

可用性測試方法：

• 一對一用戶測試
• 啓發式評估
• 焦點小組

配置測試 ⭐

配置測試（Configuration Testing）：

• 驗證系統在不同的系統配置下能否正確工作。
• 配置包括：軟件、硬件、網絡等。

配置測試的目的：促進被測軟件在儘可能多的硬件平臺上運行。有時經常會與兼容性測試或安裝測試一起進行。

文檔測試

軟件產品有可運行的程序、數據和文檔組成。文檔是軟件的一個重要組成部分。

軟件文檔的分類：

• 用戶文檔
• 開發文檔
• 管理文檔

一個好的軟件文檔能從以下3個方面提高軟件產品的整體質量：

• 提高可用性
• 提高可靠性
• 降低支持費用

文檔測試（Document Testing）：針對系統提交給用戶的文檔進行驗證，目標是驗證軟件文檔是否可以正確記錄系統的開發全過程的技術細節。通過文檔測試可以改進系統的可用性、可靠性、可維護性和安裝性。

文檔測試的內容：

• 文檔的正確性
• 文檔的完備性
• 文檔的可理解性

文檔測試方法：

• 走查：只通過閱讀文檔，不必執行程序。
• 驗證：對比文檔和程序執行結果。

GUI 測試

圖形用戶界面（Graphical User Interface，GUI）測試是功能測試的一種表現形式，不但要考慮 GUI 本身的測試，也要考慮 GUI 所表現系統功能的測試。

• 一般來說，當一個軟件產品完成 GUI 設計後，就確定了它的外觀架構和 GUI 元素，GUI 本身的測試工作就可以進行。
• 而 GUI 對應的功能完成之後，才進入功能測試階段。
• 有時可以把上述兩個階段加以合併，待功能代碼完成後一併進行。
• GUI 測試可以採用手工測試方法和自動化測試方法完成。

驗收測試

驗收測試是部署軟件之前的最後一項測試，目的是確保軟件準備就緒，並且可以讓最終用戶使用。

驗收測試的常用策略：

• 正式驗收測試
• 非正式驗收測試（內部測試人員）
• Beta 測試

迴歸測試

迴歸測試是在軟件發生變動時保證原有功能正常運作的一種測試策略和方法。

• 不需要進行全面的測試，而是根據修改的情況進行有選擇性的測試。
• 保證軟件原有功能正常運作：
  • 所做的修改達到了預期的目的。
  • 軟件的修改沒有引入新的缺陷，沒有影響原有的功能實現。

迴歸測試方法：

• 測試用例庫的維護
• 迴歸測試包的選擇
• 迴歸測試的基本過程
  1. 識別出軟件中被修改的部分。
  2. 從原基線測試用例庫 T 中排除所有不再適用的測試用例，確定對新版本依然有效的測試用例，其結果是建立一個新的基線測試用例庫 T0。
  3. 依據一定的策略從 T0 中選擇測試用例測試被修改的軟件。
  4. 生成新的用例集 T1，用於測試 T0 無法充分測試的部分。
  5. 用 T1 執行修改後的軟件。
     • 第2步和第3步測試驗證修改是否破壞了現有的功能。
     • 第4步和第5步測試驗證修改後的功能。

網站測試

• 文字測試
• 鏈接測試
• 圖形測試
• 表單測試
• 動態內容測試
• 數據庫測試
• 服務器性能和加載測試
• 安全性測試