什麼是用例測試、技術和示例?
什麼是測試中的用例
它是使用者使用軟體應用程式的特定用途的簡短描述。基本上,它是根據使用者操作制定的。它廣泛用於在驗收級別開發測試用例。
什麼是用例
用例是參與者在與系統互動以實現目標時採取的一系列操作的列表。此處,參與者可以是任何人,無論是人類使用者還是任何其他外部系統。基本上,這是一種技術,有助於識別涵蓋整個系統的測試用例,按事務逐個地從頭到尾。
在用例中,將有一組操作供使用者完成。
取款
餘額查詢
餘額轉賬
與軟體相關的操作
誰使用“用例”文件
在此,我們提供了使用者與系統互動以實現目標的不同方式的完整概述。更好的文件可以幫助以更簡單的方式識別軟體系統的需求。
軟體開發人員、軟體測試人員和利益相關者都可以使用它。
文件的用途:
開發人員使用這些文件來實現和設計程式碼。
測試人員使用它們來建立測試用例。
業務利益相關者使用該文件來理解軟體需求。
用例的型別:
用例有兩種型別:
晴天用例:這是最可能發生的主要情況,一切順利。晴天用例的優先順序高於其他用例。完成用例後,我們將其提供給專案團隊進行審查,並確保我們涵蓋了所有必需的用例。
雨天用例:雨天用例可以定義為邊緣情況的列表。此類用例的優先順序在“晴天用例”之後。我們可以藉助利益相關者和產品經理來強調這些情況。
用例中的元素:
用例中各種型別的元素如下所示:
參與者:參與用例操作的使用者。
前提條件:用例開始前需要滿足的條件。
基本流程:基本流程是系統中的正常工作流程。基本上,它是參與者在實現其目標時執行的事務流程。當參與者與系統互動時,不會出現任何錯誤,參與者將獲得他期望的預期輸出。
備選流程:除了正常工作流程外,系統還可以具有“備選工作流程”。這是使用者與系統進行的非常不常見的互動。
異常流程:異常是指阻止使用者實現某種目標的流程。
後置條件:用例完成後需要檢查的條件。
注意事項
參與者在用例中常犯的錯誤是,要麼包含有關特定情況的過多細節,要麼根本沒有足夠的細節。
這些是文字模型,如果需要,我們可以新增或不新增視覺化圖表。
確定適用的前提條件。
按正確的順序編寫流程步驟。
指定流程的質量要求。
如何編寫用例
當我們試圖編寫用例時,首先應該出現的問題是“客戶的主要用途是什麼?”
我們必須為此獲得模板。
它必須富有成效、簡單而強大。如果存在小錯誤,則強大的用例可以打動觀眾。
我們應該對其進行編號。
我們應該按步驟順序編寫流程。
為場景命名,命名必須符合目的。
這是一個迭代過程,這意味著當你第一次編寫它們時,它們不會完美無缺。
識別系統中的參與者。
讓我們考慮第一個參與者。我們可以有多個參與者具有相同的行為。
例如,在線上購物中,買家/賣家都可以“建立帳戶”。買家和賣家都可以搜尋商品。因此,這些是重複的行為,需要消除。除了使用重複的用例外,我們還必須有更通用的用例來避免重複。
我們必須確定適用的前提條件。
用例示例
考慮這樣一種情況:一個人嘗試透過線上購物方式購買商品,為此,使用者將首先登入系統。使用者可以開始執行搜尋操作,選擇搜尋結果中顯示的一個或多個專案,然後將其新增到購物車或購買。
完成所有這些後,使用者將購買或結賬。因此,這是一個使用者為完成系統以完成任務而執行的邏輯連線步驟序列的示例。
或者
在開發用例時,通常會開發測試用例表。使用者應完成幾個步驟:
插入卡
驗證卡並索要 PIN 碼
輸入 PIN 碼
驗證 PIN 碼,以及
允許訪問帳戶
在此之後,表中還將有一系列擴充套件。例如,如果系統確定某些內容不正確。
擴充套件可以是:
顯示卡無效並拒絕的訊息,和/或
顯示 PIN 碼無效的訊息,並僅要求重試幾次
用例指定主體可以與一個或多個參與者協作執行的某種行為的型別。
用例和測試用例之間的區別:
用例無法實現,這意味著它只是設計的。另一方面,測試用例是設計的,之後我們實現了它們。
用例是從業務需求規範 (BRS) 中獲得的,而測試用例是從用例中匯出的。
用例是客戶需求的圖形表示,而測試用例並非僅以表示形式存在,而是記錄在 Excel 表格中。
用例是一個文件,它始終描述應用程式的事件流。另一方面,測試用例是一個文件,它始終包含應用程式特定功能的操作、事件和預期輸出。
用例依賴於軟體需求。另一方面,測試用例取決於用例。
用例收集需求,另一方面,測試用例將分析這些需求。
在用例中,不會驗證結果。另一方面,測試用例的結果將被驗證,這意味著測試用例檢查用例中顯示的結果是否正常執行。
資料結構
網路
關係資料庫管理系統 (RDBMS)
作業系統
Java
iOS
HTML
CSS
Android
Python
C語言程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP