測試用例是否應該包含所有的細節?

　　測試用例寫的太細化了，則適應不了系統的變更需求;寫的太粗糙，則可操作性不強，太隨意。，如果文檔中的對操作步驟描述的過于具體，像下面這樣：

　　01.在“用戶名”項中輸入“user”;

　　02.在“密碼”項中輸入“password”;

　　03.點擊“確定”按鈕。

　　這樣的描述方式表面看起來可操作性似乎是增強了，任何人拿到這個文檔都可以充當測試人員，檢查一下這個功能是否存在缺陷。但是我們不要忘記，在開發過程中，變更的存在是必然的。一旦需求、設計或者應用程序中的某些細節發生了變化，比如“用戶名”變成了“操作員”，“密碼”變成了“口令”，“確定”變成了 “登錄”，或者輸入項所接受的數據類型發生了變化，那么同這部分內容相關的所有的測試用例都需要修改。否則，我們憑什么可以保證這些描述不同的測試用例說的是同一樣東西?如果我們只有這么一個測試用例，也許一切都不是問題，但是對于一個業務復雜、功能完整的系統，如果按照這樣的方法描述測試用例，最終要么產生大量的測試用例文檔，要么產生過長的單個文檔。無論是那一種，如果發生了類似于上面說的變化，維護文檔都將變成一次地獄式的體驗。這也是為什么在網絡上頻頻出現的這個問題，而且每次出現都會受到測試同行們的關注的原因。

　　那么這個問題應該任何解決呢?測試用例是不是把所有的流程寫出來就可以了呢?如何在減少測試用例文檔中包含過多瑣碎的細節的同時保證測試用例的可操作性呢?又有什么方法可以提高我們維護測試用例文檔的效率呢?筆者的建議是：關注“測試思想”而不是關注操作步驟。要理解這個問題，首先要弄明白測試用例的作用。就像用例一樣，測試用例并不是用來描述具體的實現的，而是著重描述處理問題的思路——對于一項明確的測試內容進行測試的思路。作為測試用例的設計人員，如何理解基本流和備選流?如何深入分析并找到所有需要覆蓋的路徑和需要檢查的特性?我們在測試用例中應該用容易理解的自然語言清晰的來描述我們將要如何進行測試，而不是簡單的把在應用程序上如何操作的煩瑣的步驟記錄下來。把測試用例設計當成填寫具體操作步驟的表格是人們對測試用例最大的誤解。傳統的測試用例文檔編寫有兩種方式。一種是填寫操作步驟列表：將在軟件上進行的操作步驟一步一步詳細的記錄下來，包括所有被操作的項目和相應的值。另一種是填寫測試矩陣：將被操作項作為矩陣中的一個字段，而矩陣中的一條條記錄，則是這些字段的值。網絡上對于這兩種方式孰優孰劣的爭論，將大家錯誤的引導向了兩個極端：要么采用A，要么采用B。而大家卻忽視了一點，對于工作方法的爭論，本質上同工具的爭論并不是一回事(例如曾經的VC、BCB之掙)。如果不同的方法各有優勢，我們完全可以通過變通的方法，把優勢的部分組合在一起來使用。操作步驟列表的優勢在于對基本流和備選流進行分析后，它可以清晰的描述您的測試思路。而測試矩陣則更適合于用來存放測試數據，特別是那些需要人工賦予一個確定的值的特性。下面，我們來看一個例子，當然，這個例子同樣是杜撰的。?需求名稱：用戶登錄安全驗證需求描述：用戶登錄安全驗證是為了保證所有登錄到系統中的用戶，都是由系統管理員預先在系統中設定的。使用系統中不存在的用戶名，或者用戶名輸入正確，但密碼輸入錯誤情況，都無法登錄到系統中。當用戶使用了不存在的用戶名或錯誤的密碼時，系統應分別給出適當的提示。如果用戶連續三次無法使用正確的用戶名和密碼登錄到系統，則系統應給出適當的提示，并退出當前程序。如果用戶使用正確的用戶名和密碼登錄到系統，則退出界面，轉到系統主界面。對于用戶登錄界面和程序主界面，請參考相應的UI設計文檔。

　　測試需求：

　　01.　檢查能否使用正確的用戶名和密碼登錄到系統;

　　02.　檢查能否使用錯誤的用戶名或密碼登錄到系統;

　　03.　檢查使用錯誤的用戶名和密碼登錄失敗超過三次，是否會自動退出當前程序。

　　測試用例：

原文轉自：http://www.uml.org.cn/Test/200906186.asp