壹個好的測試用例應該在被執行步驟的表達式中盡可能地從數據中分離出來。例如，有壹個ATM取款功能，可能有以下幾種情況:
1)使用正確的密碼登錄
2)不正確的密碼登錄
3)密碼連續三次輸入錯誤，卡被鎖定。
4)提取不到余額
5)盡量提取比余額多的錢。
6)盡量取出與余額相等的錢(考慮手續費)
6)取款金額大於當前限額。
7)取款金額大於當日限額。
8)取款次數大於限額次數。
等等
無論妳用什麽用例設計方法論作為指導，作為這個簡單的例子，有經驗的人應該能看出這裏的很多步驟都是可以復用的，可以總結如下(這裏只列出操作步驟，省略系統交互中的反饋結果):
1)插卡->；答:輸入密碼-& gt；b:按“確定”鍵-& gt；重復A-B
2)答:選擇取款功能-& gt；b:填寫取款金額-& gt；點擊“確認取款”按鈕-& gt；提取現金-& gt；重復A-D
所以我們只需要寫兩套比較完整的步驟，用參數表示密碼和取款金額。這樣是不是輕松很多？
2.基礎測試數據的單獨準備。
第壹個例子中的輸入數據比較簡單，但是我們還需要考慮壹個問題:我們在測試中輸入什麽樣的具體數據？什麽是“正確的密碼”？什麽是「錢大於余額」？
正確
在大型應用系統中，數據與準備過程的關系會非常復雜，甚至會有其他外部系統導入、傳輸或計算的數據。更好的做法是提前準備這些測試數據。
在每次定期測試前導入系統。壹個典型的例子，假設要求妳單獨測試幾個復雜的財務報表，使用其他模塊和外部系統逐個創建數據，這樣會錯。
這通常是費時費力的。這時候基礎數據的準備就顯得尤為重要，這樣才能保證測試工作的高效和測試結果的準確。
如果可能的話，最好提前準備好復雜的基礎測試數據，類似於這裏的簡單例子。
有效銀行卡，賬號1234567890，密碼66666，內有人民幣1000元，以此類推。提前準備好這些內容(妳可以使用自動化工具來準備，或者指導
將現有數據寫入您單獨的測試數據準備文檔，而不是在所有使用它的情況下描述它。
3.測試用例的前置條件和後置條件
除...之外
除了第二點提到的數據，在測試用例層面，妳必須滿足壹些條件，才能開始執行。比如在初始設置條件下準備壹個IE。
安裝了舊版本軟件的瀏覽器和XP系統。這些可重用的訪問條件不能被認為是壹個特定的用例步驟，而是壹個設置。
部分或先決條件。
對於後置條件或後置-
條件下，我們經常用它來做壹些處理或回收。比如上面的取款例子，如果我們要用同壹個賬號重復測試，取完所有的錢余額為零。
，您可以通過壹些步驟或數據庫腳本來重置帳戶余額。類似地，您將瀏覽器設置為禁用壹個用例的Cookie。執行完用例後，需要回到默認設置嗎？
然後呢。
把這些步驟集中組織成壹個相對獨立的操作單元，妳只需要在具體的用例中引用，這樣會方便對用例的理解，在很多地方可以重用。
對了，對於壹些類似於軟件運行環境的條件，比如安裝配置測試中三個操作系統三個瀏覽器的組合，我們可以放在測試集的層面，不需要寫多個用例，在測試計劃和執行的管理系統中，僅僅表示為測試集的壹個環境參數。
4.常見業務操作(知識庫)
對於壹個大規模的應用，比如壹個銀行系統，開發和測試工作是壹個長期持續的過程，這樣的系統非常適合引入自動化測試。業務邏輯復雜，測試技術要求高。它經常使用不同廠商的工具和各種腳本語言(如Shell、Python等。)，並且有許多可用的遺留腳本。
這些完成壹些預定業務操作的腳本單元可以直接借用。為了在公司和產品層面管理這些可重用的資源，壹個很好的辦法就是用編號來標記，比如KB_PRJ01_Module02_XXX，集中管理，以便在以後的用例中調用。
上升
比如銀行業務測試，我們需要模擬與銀聯的接口，讓測試賬戶進行外匯支付，獲取響應信息，保存結果。這可能是壹個復雜的底層處理流程，不適合普通員工。
需要，也沒有權力掌握。這時候把它們打包成Shell腳本或者小工具，做好使用，統壹歸檔。在以後的項目測試中，調用它們就行了。諸如
這可以大大提高對具有相關接口的模塊進行自動測試的效率。
根據前期工作中的壹些常見問題，就如何編寫測試用例(不僅限於自動化測試)做如下補充:
推薦
不推薦
把例子的內容描述清楚，強調怎麽操作，驗證什麽，然後期待結果是什麽。
復制設計文件中的要求和內容；描述為:在什麽條件下，邏輯會是怎樣的？這對測試用例的讀者和執行者來說是不可操作的。
預期結果要具體，比如:系統響應是什麽；結果號是多少；用戶被帶到哪個頁面；顯示哪些成功信息；這條記錄在後臺或者數據庫的修改結果是什麽？
描述:“驗證系統返回正確的結果”；”頁面元素顯示與規格壹致”；“操作成功”等抽象語句。
業務邏輯強的應用軟件，可以以業務流程為主線組織用例。
以頁面的形式組織用例。
用例以模塊、功能、測試類型、基本業務流和備選業務流的樹形結構的形式分層組織。使用用例管理工具。
Word格式的扁平化組織結構不利於管理和閱讀。
使用壹個屬性字段來建立用例與文檔章節之間的映射，比如Spec。
無法對應需求，很難計算未來的用例覆蓋率和測試執行覆蓋率。
具體業務的每個模塊、功能和壹組測試用例都是獨立的，沒有耦合。
用例之間存在依賴關系，這是無法實現的:選擇30%的用例進行回歸測試。
在時間和成本允許的情況下，盡量讓用例粒度“壹個不同的操作，得到不同的結果，就寫壹個單獨的用例”。
用例中的操作步驟甚至預期結果中仍然存在條件分支。
對於復雜的業務操作流程，如“壹次順序表單簽署流程”、“壹次完整授信流程”等，單獨增加壹些貫穿整個業務流程的大型測試用例。
對於長時間的業務操作，只有分散的詳細用例。
用例被優先排序，以便於在回歸測試中選擇核心業務或用戶密集型用例。
用例沒有優先級和重要性的定義。