1.不是所有的手工用例都要轉化為自動化測試用例。2.考慮到指令碼考法的成本，不要選擇流程太複雜的用例。如果有必要考慮把流程拆分成多個用例來實現指令碼。
3.選擇的用例最好可以構建場景。例如，乙個功能模組，分多個測試用例，多個用例使用同乙個場景。
4.選擇的用例可以帶有目的性。例如：這部分用例做冒煙測試，那部分用例做回歸測試。
5.選取的用例可以是你認為重複執行，很繁瑣的部分。例如，字典驗證，提示資訊驗證這類，這部分適用於回歸測試。
6.選取的用例可以是主體流程，這部分適用於冒煙測試。
7.自動化測試也可以用來做配置檢查，資料庫檢查，這些可能超越了手工用例，但也算用例擴充套件的一部分，專案負責人可以有選擇地增加。
8.平時在手工測試時，如果需要構造一些複雜的資料或重複一些簡單的機械式動作，則告訴自動化指令碼，讓它來幫你，或許你的效率會因此而得到提高。
在編寫自動化測試用例過程中應該遵守以下幾點原則：1.乙個用例為乙個完整的場景，從使用者登入系統到最終關閉瀏覽器。
2.乙個用例只驗證乙個功能點，不要試圖在使用者登入系統後把所有的功能都驗證一遍。
3.盡量少的編寫逆向邏輯用例。一方面因為逆向邏輯的用例很多（例如，手機號輸錯有幾十種情況）；另一方面自動化指令碼本身比較脆弱，對於複雜的逆向邏輯用例實現麻煩容易出錯。
4.用例與用例之間盡量避免產生依賴。
5.一條用例完成測試之後需要對測試場景進行還原，以免影響其他用例的執行。-- 資料清理
執行自動化指令碼 ，在測試系統裡產生的資料
– 資料庫清除 - 表的關聯/資料關聯/ --調介面刪除 – 運維定期清理
介面自動化用例設計的原則
不要為了做自動化測試而做自動化，做的首要目標是問題出現時，能第一時間發現?自動化中的 覆蓋率統計可以作為參考，但不能一開始就為了提高覆蓋率，陷入 case 設計之中。注意 好的介面自動化 case 設計，依賴於 case 設計者的功能理解程度 手工測試的功力 功能覆蓋點，在用例設計上面要遵循以下幾點...
自動化用例設計
用例設計部分，無論是手工測試還是自動化測試，都必須要的環節，也是非常重要的環節。在做自動化的時候，用例需要考慮前置後置 步驟和對比，每乙個部分都要有提供非常明確的測試資料，要考慮資料的重複使用是否會影響指令碼的執行結果。1.不是所有的手工用例都要轉成自動化測試用例 2.考慮到指令碼開發的成本，不要選...
自動化用例設計
自動化用例主要用來冒煙測試和回歸測試 冒煙測試，即為主要功能的用例執行 回歸測試，即為全部或者部分用例的執行 自動化測試得誤區 不編寫自動化測試用例，直接編寫自動化指令碼 直接拿手工測試用例來編寫自動化測試指令碼 自動化用例選型注意事項 1，不是所有的手工測試用例都要轉化為自動化測試用例 2，考慮指...