測試用例與測試場景——有什麼區別?


測試用例包含什麼?

測試用例是一組標準,測試人員使用它來驗證軟體應用程式是否滿足客戶的需求。

測試用例設計包括前提條件、用例名稱、輸入條件和預期結果。測試用例是從測試場景中派生出來的基本活動。

它是一個全面的文件,包含所有可能的輸入(正向和負向)以及測試執行過程的導航說明。編寫測試用例是一次性工作,將來可以重複用於迴歸測試。

測試用例包含關於測試方法、過程、前提條件和預期結果的詳細資訊。這些在測試階段用於檢視軟體程式是否能夠執行其建立的目的。

透過將缺陷與測試用例ID關聯,測試用例幫助測試人員進行缺陷報告。詳細的測試用例文件使測試團隊受益,因為如果開發人員遺漏了什麼,則可以在執行這些萬無一失的測試用例時檢測到。

為了構建測試用例,我們需要需求來提取輸入,以及測試場景來確保我們不會忽略任何測試功能。然後,為了確保一致性,我們應該有一個測試用例模板,或者每個測試工程師都以相同的方式生成測試文件。

每當開發人員忙於編寫程式碼時,我們通常都會編寫測試用例。

何時編寫測試用例?

當我們擁有以下資訊時,我們將編寫測試用例:

當客戶提供業務需求時,開發人員開始工作並估計產品需要3.5個月才能完成。

同時,測試小組將開始開發測試用例。

完成後,它會將其傳送給測試主管進行評估。

一旦開發人員完成構建,產品就會移交給測試團隊。

因為測試是一致的,並且不依賴於人的情緒,而是依賴於測試工程師的質量,所以測試工程師在測試產品文件時從不檢視需求。

什麼是測試場景,它是如何工作的?

任何可以測試的功能都定義為測試場景。它是一組測試場景,幫助測試團隊確定專案的正面和負面特性。

測試場景提供了需要測試內容的高階概述。

用線性語句來說,測試場景是一個完整的列表,其中包含涵蓋軟體程式端到端功能的測試用例。場景被定義為線性語句。測試場景是對可測試需求的高階分類。這些標準根據模組的功能進行分類,並從用例中派生。

由於場景中有很多測試用例,因此有一個徹底的測試過程。測試人員必須在完成測試場景之前評估每個場景的測試用例。

測試人員必須在測試場景中設身處地為使用者著想,因為他們是從使用者的角度測試軟體應用程式。該過程中最重要的方面是場景準備,這需要徵求客戶、利益相關者或開發人員的建議或幫助。

測試場景:如何編寫

  • 作為測試人員,請按照以下步驟編寫測試場景:

  • 檢查軟體的需求文件,例如BRS(業務需求規格說明)、SRS(系統需求規格說明)和FRS(功能需求規格說明)。

  • 針對每個需求,確定所有技術因素和目標。

  • 查詢使用者與軟體互動的所有可能方式。

  • 確定系統可能被濫用的所有可能場景,以及可能是駭客的使用者。

  • 閱讀需求文件並完成計劃分析後,列出可能的測試用例來檢查程式的每個功能。

  • 一旦確定了所有可用的測試場景,就建立一個可追溯性矩陣,以檢視每個需求是否都有匹配的測試場景。

  • 專案主管審查所有可能性。然後由專案的其他利益相關者進行審查。

測試場景的特性

  • 測試場景是一行文字,指導測試人員完成測試過程。

  • 使用測試場景可以降低產品的複雜性和重複性。

  • 測試場景是指您詳細地討論和思考測試,但將它們寫成線性語句。

  • 這是一系列串在一起的過程。

  • 當測試人員沒有足夠的時間來開發測試用例並且團隊同意一個全面的線性場景時,測試場景變得更加重要。

  • 測試場景是一個節省時間的有用練習。

  • 它易於維護,因為新增和修改測試用例很簡單且獨立。

練習測試場景

一個電子商務應用程式的一些測試用例可能是:

  • 場景1——檢查搜尋功能

  • 場景2——檢查支付功能

  • 場景3——檢查登入功能

主要區別

  • 測試用例是一組用於檢查特定特性或功能的動作,而測試場景是任何可以評估的功能。

  • 測試場景源自測試工件,例如BRS和SRS,而測試用例源自測試場景。

  • 測試用例有助於徹底測試應用程式,而測試場景有助於以更敏捷的方式測試端到端功能。

  • 測試用例更關注測試什麼和如何測試,而測試場景更關注測試什麼。

  • 低階活動是測試用例,而高階活動是測試場景。

  • 測試用例需要更多資源和時間來執行,而測試場景需要更少的資源和時間。

  • 測試用例包括測試過程、資料和預期結果,而測試場景包含要評估的端到端功能。

測試用例示例

對於測試場景“檢查登入功能”,將會有測試用例。

  • 輸入有效的電子郵件地址和密碼時,觀察系統的反應。

  • 輸入錯誤的電子郵件地址和有效的密碼時,觀察系統的行為。

  • 輸入有效的電子郵件地址和錯誤的密碼時,觀察系統的行為。

  • 輸入錯誤的電子郵件地址和密碼時,檢查系統的反應。

  • 電子郵件地址和密碼留空並按下“登入”按鈕時,檢查系統的行為。

  • 確保“忘記密碼”功能正常工作。

  • 輸入有效的或無效的電話號碼和密碼時,觀察系統的行為。

  • 選擇“保持登入狀態”時,觀察系統的行為。

我們為什麼要編寫測試用例?

以下是一些開發測試用例的令人信服的原因:

  • 測試用例有助於驗證是否符合相關標準、指南和客戶需求。

  • 幫助您驗證客戶的期望和需求。

  • 控制、邏輯和資料流覆蓋率均已提高。

  • 您可以嘗試真實的終端使用者場景。

  • 暴露缺陷或錯誤

  • 為測試執行開發測試用例後,測試工程師的工作將更有條理且更簡單。

編寫測試場景的目的是什麼?

以下是一些開發測試場景的令人信服的原因:

  • 編寫測試場景的主要目標是確保驗證軟體應用程式的整體功能。

  • 它還有助於確保業務流程和流程符合功能需求。

  • 為了確保對被測應用程式進行充分測試,業務分析師、開發人員和客戶等多個利益相關者可以批准測試場景。它確保程式在最常見的情況下正常執行。

  • 它們有助於確定測試工作量,並因此為客戶建立提案或組織員工。

  • 它們有助於識別最重要的端到端事務或軟體程式的實際使用情況。

  • 一旦這些測試場景最終確定,就可以輕鬆地從中生成測試用例。

測試用例和測試場景有什麼區別?

測試用例和測試場景之間存在重要區別。

測試場景測試用例
測試場景是一個高級別文件,它定義了從頭到尾要測試的功能。為了評估應用程式的所有功能,測試用例包含指定的測試步驟、資料和預期結果。
它強調“測試什麼”而不是“如何測試”。它完全強調“測試什麼”和“如何測試”。
單行語句就是一個測試用例。因此,在測試過程中始終存在歧義的風險。測試用例中描述了步驟、先決條件、預期結果等等。因此,此過程中沒有誤解的空間。
使用BRS、SRS和其他測試工件來建立測試場景。大多數測試用例都源自測試場景。單個測試場景可能會提供多個測試用例。
它有助於快速測試端到端功能。它有助於徹底測試應用程式。
測試場景中使用的是高階操作。測試用例是低階操作。
建立和測試場景所需的時間和成本明顯更少。測試用例的文件編制和執行需要更多資源。

測試用例示例

  • 測試用例應該清晰易懂。

  • 建立測試用例時要考慮到終端使用者。

  • 應避免測試用例的重複。

  • 必須確保編寫測試用例以確保滿足規範文件中指定的軟體需求。

  • 建立測試用例時,切勿對軟體應用程式的功能和特性進行假設。

  • 測試用例必須易於區分。

測試場景示例

  • 大多數測試用例都是單行語句,指定了應該測試的內容。

  • 場景描述應簡潔明瞭,易於理解。

  • 應對指定的標準進行徹底檢查。

  • 在開始測試過程之前,收集必要的工具和資源。

更新於:2021年12月2日

6K+ 次瀏覽

開啟您的職業生涯

完成課程獲得認證

開始
廣告
© . All rights reserved.