自動化測試用例如何設計，對于新手來說也是比較難理解的問題。
不少新手剛剛掌握了寫腳本的能力，一上來就拿著
功能測試用例一條一條的轉化成自動化用例。在寫的過程中，會發現諸多問題，例如，腳本中重復代碼很多，一個腳本的執行結果影響到另一個腳本的執行，有些功能用例很難轉化成自動化用例等。
站在用戶角度設計自動化
在功能測試的時候我們一般會遵循這個原因，但是自動化測試往往可以實現更強大的功能，所以，我們在設計腳本的時候很容易違背這個原則。例如，你要獲得的數據是用戶不可見的，你要判斷用例是否成功的信息也是用戶不可見的，或者你要模擬的是用戶永遠不可能做的操作等。
設計簡單傻瓜的用例
自動化腳本本來是很傻瓜的。記得有同學問我，
百度輸入有個自動聯想功能，就是在用戶輸入的過程中自動配置熱門搜索的關鍵詞，例如，用戶輸入“自”，會自動聯想“自我評價”，“自行車”等。用繼續輸入“自動”，會自動聯想“自動化”，“自動關機”，“自動檔”等。他想定位自動聯想下拉列表的某個關鍵詞，這個關鍵詞是百度根據用戶搜索熱度的變化而變化的。
再比例有同學問我，下拉列表功能，我想腳本執行時隨機選擇某一個選項，那么如何如何去判斷隨機的結果呢？換句話說，你都不知道你做了什么，怎么去判斷做的結果對不對？
所以，我們在設計用例時盡量考慮簡單傻瓜的用例，操作步驟簡單，預期結果容易判斷等。
從簡單開始
對于新需要自動化的項目來說，自動化測試的實施是循序漸進的，不要一上來就設計幾百條用例，而是逐步的將功能用例轉成自動化用例，在轉的過程中需要不斷的調整測試結構。然后，再增加穩定的
測試用例。然后，再調整測試結構。隨著功能的增加你的自動化測試框架也在逐漸穩定，基礎測試用例也在增加。一上來就幾百條用例，需求的稍微變化，用例就可能大調整，那么你很可能每天疲憊于用例的維護。
所以，在開始自動化的時候，你可以只對登錄功能寫個十來條的自動化用例。從而，漸漸的考慮將更多功能自動化起來。
半自動化對于測試人員是個不錯的開始，這樣你可以將更多的精力花在
安全測試，探索性測試，甚至是用例體驗上等。不要覺得全職自動化就是多么高大上的職位。