序言

文章內容如下：測試分類 + 測試用例設計原則 + 測試報告的格式 + 測試框架概況

• 1. 軟體測試按專案流程分類

  • 一般來說，測試分為5個階段：單元測試 + 整合測試 + 確認測試 + 系統測試 + 驗收測試。在測試過程中如果有需要還要進行迴歸測試

    • [1] 單元測試：單元就是最小的被測功能模組，模組測試
    • [2] 整合測試：模組組裝成完整的軟體系統，排除介面錯誤等
    • [3] 確認測試：軟體的功能和效能是否如使用者所合理期待的那樣
    • [4] 系統測試：將已確認的軟體、硬體、網路等結合起來進行組裝和確認測試
    • [5] 驗收測試：由使用者或者獨立的測試人員根據測試計劃和結果進行測試和驗收

  • 單元測試

    的測試物件，目的，測試依據，測試方法
    • 測試物件：模組內部的程式，可能是一個C語言的函式或過程，C++的一個類等
    • 目的：消除模組的邏輯和功能缺陷
    • 測試依據：模組的詳細設計（比如模組設計文件）
    • 測試方法：白盒測試

  • 整合測試的測試物件，目的，測試依據，測試方法

    • 測試物件：模組間的組裝和呼叫關係
    • 目的：找出模組呼叫和模組介面方面的問題
    • 測試依據：概要設計（如模組間的通訊要求等）
    • 測試方法：灰盒測試

  • 系統測試的測試物件，目的，測試依據，測試方法

    • 測試物件：整個系統
    • 目的：找出系統與需求不符合的地方
    • 測試依據：需求規格說明書
    • 測試方法：黑盒測試

  • 驗收測試的分類

    • [1] 非正式驗收測試
      
      • α測試：內測
        。由使用者、測試人員、開發人員共同參與的內部測試
      • β測試：內測後的公測。即完全交給終端使用者測試
    • [2] 正式驗收測試

• 2. 按測試工作對程式碼的可見程度分類

  上面講的單元測試、整合測試、確認測試、系統測試和驗收測試，是從專案開發流程來進行劃分的，如果從測試工作對程式碼的可見程度來劃分，可將軟體測試劃分為：

  • [1] 黑盒測試

    • 黑盒測試，指的是把被測的軟體看作是一個黑盒子，我們不去關心盒子裡面的結構是什麼樣子的，只關心軟體的輸入資料和輸出結果

    • 黑盒測試也稱為功能測試、資料驅動測試、或基於規格說明書的測試，是一種從使用者觀點出發的測試

    • 主要檢測的錯誤型別有：

      • 不正確或遺漏的功能 + 介面介面錯誤
        (能否正確輸入正確輸出) + 效能錯誤(效能能否滿足要求) + 資料結構或外部資料訪問錯誤 + 初始化或終止條件錯誤

    • 常用的黑盒測試方法：

      • 等價類劃分法 + 邊界值分析法 + 因果圖法 + 場景法 + 正交實驗設計法 + 判定表驅動分析法 + 錯誤推測法 + 功能圖分析法。

  • [2] 白盒測試

    • 白盒測試，指的是把盒子蓋子開啟，去研究裡面的原始碼和程式結果。按照程式內部的結構測試程式，通過測試來檢測產品內部動作是否按照設計規格說明書的規定正常進行，檢驗程式中的每條通路是否都能按預定要求正確工作

    • 白盒測試也稱為結構測試、透明盒測試、邏輯驅動測試或基於程式碼的測試

    • 白盒測試需要遵循的原則：

      • (1) 保證一個模組中的所有獨立路徑至少被測試一次；
      • (2) 所有邏輯值均需要測試真（true）和假（false）兩種情況；
      • (3) 檢查程式的內部資料結構，保證其結構的有效性；
      • (4) 在上下邊界及可操作範圍內執行所有迴圈。

    • 白盒測試的主要方法有：

      • 靜態測試&動態測試 + 單元測試 + 程式碼檢查 + 同行評審 + 技術評審

      • 靜態測試和動態測試：靜態測試是不用執行程式的測試，包括程式碼檢查、靜態結構分析、程式碼質量度量、文件測試等等，它可以由人工進行，充分發揮人的邏輯思維優勢，也可以藉助軟體工具（Fxcop）自動進行。動態測試則需要執行程式碼，也是我們用的最多的一種測試，通過執行程式找到問題，包括功能確認與介面測試、覆蓋率分析、效能分析、記憶體分析等。

  • [3] 灰盒測試

    • 灰盒測試更像是白盒測試和黑盒測試的混合測試。更多時候測試做的就是灰盒測試，既有白盒測試也有黑盒測試

    • 灰盒測試關注輸出對於輸入的正確性，同時也關注內部表現，但這種關注不象白盒那樣詳細、完整，只是通過一些表徵性的現象、事件、標誌來判斷內部的執行狀態。有時候輸出是正確的，但內部其實已經錯誤了，這種情況非常多，如果每次都通過白盒測試來操作，效率會很低，因此需要採取灰盒的方法。

• 3. 按使用的測試方法分類

  • [1] 手工測試

    • 由人去執行測試用例，觀察返回結果是否符合預期

  • [2] 自動化測試

    • 把人為驅動的測試行為轉換為機器執行。

    • 自動化測試又可分為：功能自動化測試 + 效能自動化測試

    • (1) 功能自動化測試：一般所說的自動化測試就是指功能自動化測試。用一段程式來測試軟體功能，重複執行進行重複測試，如果軟體發生小部分改動，只需要改動小部分測試程式碼，就可繼續對軟體進行功能測試

    • (2) 效能自動化測試：現在的效能測試工作都是通過效能測試工具輔助完成的。測試工具可以模擬成千上萬的使用者向系統傳送請求，用來驗證系統的處理能力。

• 4. 效能測試的分類

  • [1] 效能測試
  • [2] 負載測試：在一定的工作負荷下，系統的負荷及響應時間
  • [3] 容量測試：系統在其極限值狀態下沒有出現任何軟體故障或還能保持主要功能正常執行
  • [4] 壓力測試：確定系統瓶頸的測試
  • [5] 強度測試：對異常情況的抵抗能力

  壓力和強度測試通常與效能測試結合進行。

  針對一個網站進行測試，模擬10到50個使用者就是在進行常規效能測試，使用者增加到1000乃至上萬就變成了壓力/負載測試。如果同時對系統進行大量的資料查詢操作，就包含了強度測試。

• 5. 設計測試用例最重要的原則

  • 準確性：準確對應需求來設計測試用例

  • 完整性：完整覆蓋應有的功能需求

  • 可重複性：測試用例應該是可重複的，排除測試情形的特殊性

  • 獨立性：一個測試用例最好能獨立執行，不依賴於其他測試用例的輸出結果

  除了上述原則，還有其他一些原則比如：

  • 經濟性：測試沒有冗餘步驟
  • 可追蹤：測試用例應該追溯到具體需求
  • 自我清理：測試結束後，恢復到原有乾淨的狀態，不應該對原有系統造成影響
  • 結構化和可測試性：測試用例應該是結構化。一般可以根據一個橫向維度，對測試用例進行功能模組的劃分；同時縱向維度上可以根據測試類別對測試用例進行縱向結構的劃分。測試同時應該是可測試性的。對於無法執行的測試用例是沒有意義的。
  • 規範性：包含測試用例的說明-命名、環境、步驟、結果等必要說明
  • 簡潔性：儘量簡潔，精悍，執行時間不要過長，粒度不要太大（大型系統不太適用）
  • 有效性：測試用例是否符合商業用例

• 6. 測試報告包括哪些內容

  測試報告的通常閱讀者：開發人員、測試經理、產品經理、專案負責人
  不同人員有不同的閱讀需求：

  開發人員往往希望能從報告中瞭解缺陷的情況
  測試經理還關心用例的執行情況及覆蓋率
  專案責任人則最關心還有多少問題、此次版本是否測試通過

  測試報告有：功能測試報告，效能測試報告，相容性測試報告等

  功能測試報告根據內容的側重點，分為版本測試報告和總結測試報告

  • [1] 版本測試報告的主要內容

    • 測試簡介：測試目的，測試消耗的資源
    • 測試環境：軟硬體環境，系統拓撲圖等
    • 測試方法
    • 測試用例：用例分析，用例執行情況
    • 測試過程：缺陷統計，問題摘要
    • 測試結果：資源佔用，測試結論(詳細資料支援)
    • 備註：用例執行記錄，資源監控記錄等

  • [2] 總結測試報告的主要內容

    • 測試簡介：條目同上
    • 測試環境：條目同上
    • 測試過程：各版本測試狀況，各版本bug統計
    • 測試分析：缺陷分析，遺留問題
    • 測試小結：資源佔用，風險分析等

• 7. 對測試框架的瞭解

四種常用的測試框架：資料驅動測試框架 + 測試指令碼模組化框架 + 測試庫架構框架 + 關鍵字驅動測試框架

• [1] 資料驅動測試框架：

  • 所有測試框架中最簡單的一種。

  • 資料驅動測試是測試從資料檔案（資料池，ODBC源，cvs檔案，Excel檔案，DAO物件等）中讀取輸入和輸出數值並載入到捕獲的或手工編碼的指令碼中變數裡的一種框架。將測試資料從測試指令碼中分離出來。

  • 優點：

    • 至少測試資料可以單獨維護了
    • 可以快速增加相似測試，測試者增加新的測試不必掌握測試工具語言

  • 缺點：

    • 維護成本非常高。任何測試程式的變更所導致的工作量是所有測試框架中最多的

• [2] 測試指令碼模組化框架

  • 測試指令碼模組化框架應用了抽象或封裝的原則。

  • 測試指令碼模組化框架需要建立能夠代表測試下應用程式（application-under-test）的模組，零件（section）和函式的小的、獨立的指令碼。然後用一種分級的方式將這些小指令碼組成更大的測試，實現一個特定的測試用例。

  • (1) 測試資料由測試工程師負責

  • (2) 測試指令碼由自動化工程師負責維護，必須懂業務邏輯

  • 優點：

    • 控制元件和業務邏輯一旦發生變化，要進行修改和維護的是底層的測試指令碼（比無任何抽象封裝的自動化測試程式稍好一些）

  • 缺點：

    • 控制元件識別和業務邏輯本身屬於不同的領域，沒有很好進行抽象封裝
    • 幾乎所有大的變更引起的工作量都由自動化測試開發工程師完成

• [3] 測試庫架構框架

  • 測試庫構架框架和測試指令碼模組化框架非常相似，有著同樣的優勢，但是它把測試下的應用程式分成過程和函式，而不是指令碼。

  • 這種框架要求建立代表測試下應用程式模組，零件和函式的庫檔案（SQABasic libraries, APIs, DLLs等等）。然後這些庫檔案被測試用例指令碼直接呼叫。

  • (1) 測試資料由測試工程師負責
  • (2) 測試指令碼由自動化工程師負責，必須懂業務邏輯

  • (3) 測試庫由自動化工程師負責，無須懂業務，負責控制元件的維護

  • 優點：

    • 完成了控制元件識別操作和業務邏輯的抽象分離
    • 被測試系統無論是哪層發生變化，只需要相應的人員進行變更維護即可
  • 缺點：
    
    • 變更引起的工作量還是附加在自動化測試開發工程師身上

• [4] 關鍵字驅動測試框架/表格驅動測試

  • 關鍵字驅動和表格驅動測試是一種獨立於應用程式的自動化框架，它們是可以互相替換的術語。這種框架要求開發於用來執行的自動化工具，驅動測試下應用程式和資料的測試指令碼程式碼相獨立的資料表和關鍵字。關鍵字驅動測試看上去非常象手工測試。在關鍵字測試裡，應用程式的功能特性被寫在表格和每個測試的詳細指引裡了。

  • 控制元件和業務邏輯以關鍵字的形式在EXCEL裡面進行呼叫，普通的測試工程師不需要了解框架和工具的知識就能維護好控制元件和業務邏輯

  • 優點：

    • 極大的減少了自動化開發工程師維護量，畢竟在測試團隊中，自動化開發工程師佔的比較少
    • 普通測試工程師，可以很好的維護自身負責的模組中涉及的測試case和測試資料
  • 缺點：
    
    • 框架的抽象程度比較高，對自動化測試工程師的開發能力比較高

除了上述四種測試框架，可能還有混合的測試自動化框架

• [5] 混合的測試自動化框架
  
  • 最常見的已實現的框架是上述技術的組合，抽取它們的優點，剔除其弱點。這種混合的測試自動化框架是發展時間較長且應用專案最多的框架

2017.09.26