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