不少新手剛剛掌握了寫指令碼的能力，一上來就拿著功能測試用例一條一條的轉化成自動化用例。在編寫的過程中，會發現諸多問題，例如，指令碼中重複程式碼很多，一個指令碼的執行結果影響到另一個指令碼的執行，有些功能用例很難轉化成自動化用例等。

下面談談幾條指導建議：
站在使用者角度設計自動化
在功能測試的時候我們一般會遵循這個原因，但是自動化測試往往可以實現更強大的功能，所以，我們在設計指令碼的時候很容易違背這個原則。例如，你要獲得的資料是使用者不可見的，你要判斷用例是否成功的資訊也是使用者不可見的，或者你要模擬的是使用者永遠不可能做的操作等。
設計簡單傻瓜的用例
自動化指令碼本來是很傻瓜的。記得有同學問我，百度輸入有個自動聯想功能，就是在使用者輸入的過程中自動配置熱門搜尋的關鍵詞，例如，使用者輸入“自”，會自動聯想“自我評價”，“自行車”等。用繼續輸入“自動”，會自動聯想“自動化”，“自動關機”，“自動檔”等。他想定位自動聯想下拉列表的某個關鍵詞，這個關鍵詞是百度根據使用者搜尋熱度的變化而變化的。
再如有同學問我，下拉列表功能，我想指令碼執行時隨機選擇某一個選項，那麼如何如何去判斷隨機的結果呢？換句話說，你都不知道你做了什麼，怎麼去判斷做的結果對不對？
所以，我們在設計用例時儘量考慮簡單傻瓜的用例，操作步驟簡單，預期結果容易判斷等。
循序漸進，從簡單開始

對於新需要自動化的專案來說，自動化測試的實施是循序漸進的，不要一上來就設計幾百條用例，而是逐步的將功能用例轉成自動化用例，在轉的過程中需要不斷的調整測試結構。然後，再增加穩定的測試用例。然後，再調整測試結構。隨著功能的增加你的自動化測試框架也在逐漸穩定，基礎測試用例也在增加。一上來就幾百條用例，需求的稍微變化，用例就可能大調整，那麼你很可能每天疲憊於用例的維護。
所以，在開始自動化的時候，你可以只對登入功能寫個十來條的自動化用例。從而，漸漸的考慮將更多功能自動化起來。
半自動化對於測試人員是個不錯的開始，這樣你可以將更多的精力花在安全測試，探索性測試，甚至是用例體驗上等。不要覺得全職自動化就是多麼高大上的職位。