軟體測試 - 測試用例



軟體測試是藉助許多工件進行的,例如測試計劃、策略、場景和測試用例。它不僅用於檢測錯誤,還用於驗證軟體是否按預期工作。為了實現這一點,遵循特定的模板來驗證每個功能。這被稱為測試用例。

什麼是測試用例?

測試用例是在測試中遵循的標準格式,用於檢查軟體是否符合要求。它包含需要驗證的一組條件,以驗證軟體上的實際結果是否與預期結果相匹配。

測試用例的各個部分列在下面 -

  • 功能名稱 - 指向要驗證的功能。
  • 測試用例識別符號 - 指向分配給每個測試用例的唯一 ID。
  • 測試人員姓名 - 將執行測試的測試人員的姓名。
  • 測試場景名稱 - 將轉換為測試用例的場景的名稱。
  • 測試用例描述 - 將在測試用例中驗證的需求或標準。
  • 測試步驟 - 在軟體上執行的操作以驗證測試條件。
  • 前提條件 - 在開始執行測試步驟之前需要滿足的先決條件。
  • 測試優先順序 - 為測試用例分配的測試優先順序,以確定需要執行的順序。
  • 測試資料 - 完成測試所需的輸入和資料。
  • 預期結果 - 根據需求的預期結果。
  • 測試設定 - 執行測試前需要設定的設定和引數。
  • 實際結果 - 軟體產生的實際結果。
  • 環境 - 執行測試的環境配置,包括作業系統、配置、安全等。
  • 測試狀態 - 測試的狀態應反映為透過、失敗、未執行和阻塞。
  • 評論 - 新增到每個測試用例的註釋。

測試用例和測試場景的區別

測試用例和測試場景之間存在多個差異 -

序號 測試用例 測試場景
1 它包含有關要測試的內容、需要執行的測試步驟、實際結果和預期結果等的全部詳細資訊。 它是一個高級別文件,涵蓋所有功能以及所有功能的使用者故事。
2 它的建立是為了讓測試人員和開發人員能夠協同工作。 它指導測試團隊執行的任務。
3 它根據測試場景文件建立,並在迴歸或重新測試階段再次重用。 它是直接根據需求建立的,但每當需求發生更改或新增時都需要更新。

我們什麼時候編寫測試用例?

即使在軟體開發開始之前,當需求準備就緒時,也會編寫測試用例。當軟體的開發也已完成時,測試人員會完成測試用例的設計。

它也可以在完成軟體開發後(在生產部署之前)或根據需要實施新功能後立即建立。

測試用例的建立是在整個軟體開發過程中持續進行的,以便一旦某個模組或其一部分準備就緒,就可以立即並行測試。

為什麼要編寫測試用例?

編寫測試用例的原因如下 -

  • 檢查軟體是否符合要求。
  • 檢查軟體是否在指定條件下工作。
  • 它有助於限制軟體更新和其他需求。
  • 它確保所有需求以及所有可能的場景和用例都得到涵蓋和記錄,從而提高測試覆蓋率。
  • 它有助於實現測試執行的均勻性。精心設計的測試用例允許任何測試人員開始驗證軟體。
  • 一個好的測試用例需要最少的維護工作。

測試用例的基本格式是什麼?

元件 目的
測試用例 ID 它指向分配給每個測試用例的唯一 ID。
測試用例描述 測試用例設計的簡要說明。
前提條件 開始執行測試步驟前需要滿足的先決條件。
測試步驟 詳細描述測試步驟。
測試資料 完成測試所需的輸入和資料。
預期結果 根據需求的預期結果。
後置條件 測試用例成功執行後需要滿足的條件。
實際結果 軟體產生的實際結果。
測試狀態 將實際結果與預期結果進行比較後的測試狀態。
專案名稱 專案的名稱。
模組名稱 模組的名稱。
參考資料 參考資料的存放位置。
建立者 設計測試用例的測試人員姓名。
建立日期 建立測試用例的日期。
評審日期 測試用例被評審的日期。
執行者 執行測試用例的測試人員姓名。
執行日期 測試用例被執行的日期。
備註 針對測試用例新增的備註。

下圖顯示了一個測試用例的格式。

Software Testing Test Cases

設計測試用例的最佳實踐

設計測試用例的最佳實踐如下:

  • 測試用例不應該複雜,應該清晰易懂。
  • 每個測試用例都應該具有唯一性。
  • 只有在明確理解需求、輸入、資料並且沒有任何假設的情況下才能設計測試用例。
  • 每個測試用例都應該對映到至少一個需求,以便進行可追溯性。
  • 每個測試用例都應該用所有可能的輸入、條件和資料進行驗證。
  • 測試用例的描述、名稱等應該不言自明,但用幾句話解釋清楚。
  • 每個測試用例都應該涵蓋客戶需求。
  • 測試用例的設計不應產生相同的結果。
  • 設計測試用例時應該考慮到終端使用者的需求和視角。
  • 每個測試用例都應該有一個唯一的ID。
  • 測試用例應該有明確定義的前置條件和後置條件。
  • 測試用例的編寫應該能夠在其他地方重複使用。
  • 應該包含測試用例的精確預期結果。

測試管理工具

不同的測試管理工具如下:

  • TestRail - 這是一款測試管理工具。
  • Jira - 這是一款專案管理工具。
  • ALM/HP QC - 這是一款專案管理工具。

正式和非正式測試用例

  • 正式測試用例 - 它遵循上面討論的測試用例模板或格式。
  • 非正式測試用例 - 它不遵循任何測試用例模板或格式。

不同型別的測試用例

不同型別的測試用例如下:

  • 功能測試用例 - 它們用於驗證軟體的功能是否按預期工作。
  • 單元測試用例 - 它們由開發人員編寫,用於驗證他們開發的軟體單元是否正常工作。
  • GUI測試用例 - 它們用於驗證軟體的圖形使用者介面。
  • 整合測試用例 - 它們用於驗證軟體的不同元件在與其他元件整合後是否正常工作。
  • 效能測試用例 - 它們用於驗證軟體的響應時間和整體效能。
  • 資料庫測試用例 - 它們用於驗證後端以及所有資料是否都反映在資料庫中的正確表中。
  • 安全測試用例 - 它們用於驗證軟體的安全功能。
  • 可用性測試用例 - 它們用於驗證軟體是否可用且使用者友好。
  • 使用者驗收測試 - 它們用於驗證軟體在現實生活場景和環境中是否正常工作。

測試用例的實際示例

以下是一個功能測試用例的示例,該用例旨在驗證只有在使用者擁有最低賬戶餘額的情況下才能處理付款。

模組名稱 支付
測試用例 ID 10
建立者 張三
測試用例描述 驗證支付功能
前提條件 1. 使用者應該能夠登入。
2. 使用者的賬戶中應該有一些餘額。
環境 Windows,最新Chrome瀏覽器UAT環境
場景名稱 驗證只有在使用者擁有最低賬戶餘額的情況下才能處理付款。
測試用例 ID 測試步驟 測試資料 預期結果 實際結果 狀態 備註
10 啟動瀏覽器 使用者憑據 瀏覽器應該啟動 瀏覽器已啟動 透過 不適用
開啟URL 應用程式URL應該開啟 應用程式URL已開啟
點選餘額選項卡 餘額頁面應該開啟,並且使用者應該有一些餘額。 餘額頁面已開啟,使用者具有一定金額的餘額
點選支付選項卡 支付頁面應該開啟,並且使用者應該能夠使用餘額成功處理支付。 支付頁面已開啟,使用者使用餘額成功處理了支付。
點選登出 應用程式應該登出。 應用程式已登出

在上面的示例中,使用者首先啟動瀏覽器並在其中開啟一個應用程式。然後檢查使用者賬戶餘額,然後使用該餘額進行支付。

結論

本教程對軟體測試用例進行了全面概述。我們從描述什麼是測試用例、測試用例的基本特徵是什麼、何時編寫測試用例、為什麼編寫測試用例、測試用例和測試場景之間有什麼區別、有哪些不同的測試管理工具、正式和非正式測試用例是什麼、不同型別的測試用例是什麼以及測試用例的實際示例開始。

這使您能夠深入瞭解軟體測試用例。明智的做法是不斷練習您所學到的知識,並探索與軟體測試相關的其他知識,以加深您的理解並擴充套件您的視野。

廣告