一般在工作中記錄測試用例狀態用到三種狀態：通過(pass)，失敗(fail)和排隊等待中(in queue)。但是我傾向與更準確地表示乙個一般測試用例的生命週期，儘管你的測試的週期會有變化。這裡列出了我所使用的乙個測試用例生命週期：
排隊(in queue)：測試用例已經指定給某個測試人，不準備在這乙個測試階段執行。
進行中(ip)：該測試正在進行，並且會持續一段時間。(如果乙個測試所需要的時間少於一天，我就不會講乙個測試標為進行中，因為我每天會跟蹤測試用例的狀態)
阻塞(block)：一些因素會導致測試不能進行到底，例如某個功能欠缺或者測試環境的某個部分欠缺。我通常會在測試用例總結工作表的意見欄記錄下阻塞的狀態。你可以把阻塞理解為：我希望執行測試，但是目前還不能執行測試。
跳過(skip)：你決定在當前測試階段跳過某個測試，可能是因為它的優先權相對較低。(同樣地，我會在測試用例總結工作表的意見欄記錄下我跳過這個測試的原因。)你可以把跳過理解為：我現在可以執行這個測試，但是我不想執行它。
通過(pass)：測試執行結束，測試人得到了預料中的測試結果狀態和測試行為。
失敗(fail)：在很多情況下，測試人得到預料之外的測試結果，狀態或行為，這些結果與測試目標相差甚遠。這就引發了關於系統質量的疑問。乙個或多個測試錯誤需要記錄下來。
警告(warn)：在很多情況下，測試人得到預料之外的測試結果，狀態或行為，但是這些結果與測試目標差別不是很大(我通常會在測試包總結工作表的通過一欄記為警告，而不是另加一欄)。另一種想法是，警告意味著當前的錯誤是無關緊要的，或者對正在測試的特徵是沒有意義的。系統報出了更多的錯。我處理這個問題的乙個標準是只和延期的或不是一定要改的錯誤相關的測試可以標記為警告，而不是失敗。
關閉(close)：乙個測試在第乙個迴圈種被標為失敗或警告，第二個測試發布中將第乙個測試迴圈出現的錯誤修改了。重新執行了整個測試用例後，沒有錯誤出現。將這類測試標記為關閉而不是通過，使得你可以跟蹤測試在某乙個測試發布中失敗的實事(同標記為警告的測試一樣，我在測試包總結工作表中將標記為關閉的測試也納入成功的範疇)。
手動標記用例狀態 軟體測試用例狀態有哪些 百度經驗
排隊 in queue 測試用例已經指定給某個測試人，不準備在這乙個測試階段執行。進行中 ip 該測試正在進行，並且會持續一段時間。如果乙個測試所需要的時間少於一天，我就不會講乙個測試標為進行中，因為我每天會跟蹤測試用例的狀態 阻塞 block 一些因素會導致測試不能進行到底，例如某個功能欠缺或者測...
業務用例和系統用例
拋開前一篇文章談的總體思路，我們今天來談一下需求分析工作實質性的做些什麼。在這裡，我們，將主要關注於分析層面，也即 uml中的用例模型和邏輯模型。在這裡要申明的是邏輯模型並不能完全算需求分析階段的工作，因為它包含了設計模型的概念，但是我又把它歸納了一塊到需求分析階段，原因在於邏輯模型中存在了業務物件...
業務用例和系統用例
業務用例與系統用例具有同樣的特徵，因此編寫和評審用例的方法對兩者都適用。在業務用例中說明的東西，也會在系統用例中說明。這形成了系統用例和使用者用例之間的合作。但這樣帶來了兩個壞訊息。第乙個壞訊息 編寫者和讀者經常把二者弄混，可能把系統行為放入業務用例中，也可能把業務操作歸於系統用例。如果能夠商量著去...