自動化測試用例如何設計，對於新手來說也是比較難理解的問題。
不少新手剛剛掌握了寫指令碼的能力，一上來就拿著功能測試用例一條一條的轉化成自動化用例。在寫的過程中，會發現諸多問題，例如，指令碼中重複**很多，乙個指令碼的執行結果影響到另乙個指令碼的執行，有些功能用例很難轉化成自動化用例等。
站在使用者角度設計自動化
在功能測試的時候我們一般會遵循這個原因，但是自動化測試往往可以實現更強大的功能，所以，我們在設計指令碼的時候很容易違背這個原則。例如，你要獲得的資料是使用者不可見的，你要判斷用例是否成功的資訊也是使用者不可見的，或者你要模擬的是使用者永遠不可能做的操作等。
設計簡單傻瓜的用例
再比例有同學問我，下拉列表功能，我想指令碼執行時隨機選擇某乙個選項，那麼如何如何去判斷隨機的結果呢？換句話說，你都不知道你做了什麼，怎麼去判斷做的結果對不對？
所以，我們在設計用例時盡量考慮簡單傻瓜的用例，操作步驟簡單，預期結果容易判斷等。
從簡單開始
對於新需要自動化的專案來說，自動化測試的實施是循序漸進的，不要一上來就設計幾百條用例，而是逐步的將功能用例轉成自動化用例，在轉的過程中需要不斷的調整測試結構。然後，再增加穩定的測試用例。然後，再調整測試結構。隨著功能的增加你的自動化測試框架也在逐漸穩定，基礎測試用例也在增加。一上來就幾百條用例，需求的稍微變化，用例就可能大調整，那麼你很可能每天疲憊於用例的維護。
所以，在開始自動化的時候，你可以只對登入功能寫個十來條的自動化用例。從而，漸漸的考慮將更多功能自動化起來。
半自動化對於測試人員是個不錯的開始，這樣你可以將更多的精力花在安全測試，探索性測試，甚至是用例體驗上等。不要覺得全職自動化就是多麼高大上的職位。
原文**51testing軟體測試網
關於基礎，不得不說
最近遇到好多問題，都與基本概念相關。忍不住，就想多說幾句。研究生面試，我出了乙個問題，乙個100khz的方波訊號，幅度大約是幾伏的數量級，想測量其有效值，用什麼儀器，怎麼測？多數學生一臉茫然，搞的我不好意思，慚愧題目是不是太難了。我急了，問學生，乙個1.5v的電池，其電壓有效值是多少？學生問我，直流...
不得不說的「跳槽」
現實中不難發現 越是高階人才，適合的機會就越少 的現象。身處金字塔中上層的人員，無論是職位還是薪水，起點都很高，這客觀上造成適合的職位機會少，職業路徑轉換成本過高等問題。我個人認為，it技術高層人士，如果要跳槽，務必要注意三宜和三忌。忌 病急亂投醫 宜 方法得當 公升遷至較高職位的人，大多都多年不找...
ios icon 不得不說的故事
圖示是ios程式包所必需的組成部分。如果你沒有提供程式所需的各種尺寸的圖示,程式上傳發布時可能會無法通過驗證。ios程式為兼顧不同的應用場景，定義了多個不同規格的圖示，並以不同的命名區分 圖示名稱 大小圓角 用途必需 icon.png 57 x 57 10px 用於程式商店和在iphone ipod...