測試用例級別：level1 基本：
1、該類用例設計系統基本功能，1級用例的數量應受到控制、
2、劃分依據：該用例執行的失敗會導致多出重要功能無法執行的，如：表單維護中的增加功能、最平常的業務使用等。可以認為是發生概率較高的而經常這樣使用的一些功能用例。
3、該級別的測試用例在每一輪版本測試中都必須執行
level2 重要：
1、2級測試用例實際系統的重要功能。2級用例數量較多。
2、劃分依據：主要包括一些功能互動相關、個種應用場景、使用頻率較高的正常功能測試用例
3、在非回歸的系統測試版本中基本上都需要進行驗證，以保證系統所有的重要功能都能夠正常實現。在測試過程中可以根據版本當前的具體情況進行安排是夠進行測試。
level3 一般：
1、3級測試用例設計系統的一半功能，3級用例數量也較多。
2、劃分依據：使用頻率較低於2級用例。例如：數值或陣列的便捷情況、特殊字元、字串超長、與外部件互動訊息失敗、訊息超時、事物完整性測試、可靠性測試等等。
3、在非回歸的系統測試版本中不一定都進行驗證，而且在系統測試的中後期並不一定需要每個版本都進行測試
level4 生僻：如果沒有可以不適用該級別
1、該級別用例一半非常少。
2、劃分依據：該用例對應較生僻的預置條件和資料設定。雖然某些測試用例發現過較嚴重的錯誤，但是那些用例的處罰條件非常特殊，仍然應該被植入4級用例中。如介面規範化的測試也可歸入4級用例。在實際使用中使用頻率非常低、對使用者可有可無的功能。
3、在版本測試中有某些正常原因（包括：環境、人力、時間等）經過測試經理同意可以不進行測試。
軟體的缺陷等級應如何劃分：
a類——致命錯誤，包括以下各種錯誤：
1．由於程式所引起的宕機，非法退出
2．死迴圈
3．資料庫發生死鎖
4．因錯誤操作導致的程式中斷
5．功能錯誤
6．與資料庫連線錯誤
7．資料通訊錯誤
b類——嚴重錯誤，包括以下各種錯誤：
1．程式錯誤
2．程式介面錯誤
3．資料庫的表、業務規則、預設值未加完整性等約束條件
c類——一般錯誤，包括以下各種錯誤：
1．操作介面錯誤（包括資料視窗內列名定義、含義是否一致）
2．列印內容、格式錯誤
3．簡單的輸入限制未放在前台進行控制
4．刪除操作未給出提示
5．資料庫表中有過多的空欄位
d類——提示錯誤，包括以下各種錯誤：
1．介面不規範
2． 輔助說明描述不清楚
3． 輸入輸出不規範
4． 長操作未給使用者提示
5． 提示視窗文字未採用行業術語
6． 可輸入區域和唯讀區域沒有明顯的區分標誌
用例的十大缺陷
用例怎麼理解呢？其原始英文是usecase，直譯過來就成了用例。這也是乙個比較貼切的叫法了，從字面的直接理解就是使用的例子。另一種比較流行的定義是用例就是與使用者 actor 互動的，並且給使用者提供可觀測的有意義的結果的一系列活動的集合 用例模型怎麼理解呢?用例模型是系統既定功能及系統環境的模型，...
業務用例和系統用例
拋開前一篇文章談的總體思路，我們今天來談一下需求分析工作實質性的做些什麼。在這裡，我們，將主要關注於分析層面，也即 uml中的用例模型和邏輯模型。在這裡要申明的是邏輯模型並不能完全算需求分析階段的工作，因為它包含了設計模型的概念，但是我又把它歸納了一塊到需求分析階段，原因在於邏輯模型中存在了業務物件...
業務用例和系統用例
業務用例與系統用例具有同樣的特徵，因此編寫和評審用例的方法對兩者都適用。在業務用例中說明的東西，也會在系統用例中說明。這形成了系統用例和使用者用例之間的合作。但這樣帶來了兩個壞訊息。第乙個壞訊息 編寫者和讀者經常把二者弄混，可能把系統行為放入業務用例中，也可能把業務操作歸於系統用例。如果能夠商量著去...