不得不說--自動化測試元素定位與用例設計

關于自動化測試，經常被問到元素的定位 與 如何設計用例。 很多時間我也幫不了你解決實際的問題，隻能從個人腳本談談如何看待這些問題。

不得不說之元素定位

　　雖然，本章寫了十幾篇文章來講元素的定位與操作，對于碰到的一些常見功能，如何通過技巧來定位它們，但是在實際的自動化腳本開發中，不管是新手還是具有一定經驗的老手，我們面臨最多的問題仍然是元素的定位問題。

　　有時間元素定位非常簡單，例如，我們隻要知道這個元素有的id和name 就可以輕松的來定位到它；有時間元素的定位卻非常的令人非常頭疼，盡管我們用盡了是以辦法，仍然無法定位到它。在這裡筆者也沒萬能的方法來幫你解決這些實際問題。

      評估自動化可行性

　　對于不同的web項目，所用到的前端技術也不同，有些項目會用到ext（一個強在的js類庫），有些會用到ajax（一種建立互動式網頁應用的網頁開發技術），這些技術的應用無疑對于前端開發人員可以快速的生成所需要的頁面，但對于ui自動化測試人員來說，增加了定位頁面元素的難度。

　　是以，在進行項目實作ui自動化評估的時候，頁面元素的定位難度也是一個評估标準，如果處處都是很難定位的元素，那麼無疑會增加腳本的開發與維護的成本，得不償失。這個時候我可以考慮将更新多的精力放在單元或接口層的自動化上。

      提高技術能力

　　對于自動化測試人員來說，如果熟悉前端技術也會大在降低你定位難度，熟練使用xpath和css技術會使你的定位變得容易很多，如果精通javascript、jquery 等技術，那麼使你的定位之路變得更加随心所欲。

    規範前端開發

　　在我們嘗試實施的web項目中，大多數在設計初期，前端并沒考慮到需要ui層的自動化，是以，有些前端開發人員以實作功能為目的，前端頁面的代碼相當不規範。這個也是自動化測試定位難的重要原因。如果開發人員在設計代碼的時候規範的為元素加上id 和name屬性的話，那我們的定們将會變得容易很多。

　　很多測試人員在對項目進行學習和實施自動化測試的過程總是覺得困難重重，就是因為這些普遍的客觀原因所造成的。一方面，我們要努力學好技術，克服這些困難。另一方面，我們要清楚的認識到，自動化技術的應用與實踐不是一個人的戰鬥。一定要得到整個團隊的配合與支援。

　　當然，站在公司的立場，不能帶來收益的事情是很難得到支援的，這個就需要讀者去綜合評估目前的産品真的适合引入自動化麼？或者目前的階段真的迫切需要自動化麼？

不得不說之用例設計

　　自動化測試用例如何設計，對于新手來說也是比較難了解的問題。

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

　　站在使用者角度設計自動化

　　在功能測試的時候我們一般會遵循這個原因，但是自動化測試往往可以實作更強大的功能，是以，我們在設計腳本的時候很容易違背這個原則。例如，你要獲得的資料是使用者不可見的，你要判斷用例是否成功的資訊也是使用者不可見的，或者你要模拟的是使用者永遠不可能做的操作等。

　　設計簡單傻瓜的用例

　　自動化腳本本來是很傻瓜的。記得有同學問我，百度輸入

有個自動聯想功能，就是在使用者輸入的過程中自動配置熱門搜尋的關鍵詞，例如，使用者輸入“自”，會自動聯想“自我評價”，“自行車”等。用繼續輸入“自

動”，會自動聯想“自動化”，“自動關機”，“自動檔”等。他想定位自動聯想下拉清單的某個關鍵詞，這個關鍵詞是百度根據使用者搜尋熱度的變化而變化的。

　　再比例有同學問我，下拉清單功能，我想腳本執行時随機選擇某一個選項，那麼如何如何去判斷随機的結果呢？換句話說，你都不知道你做了什麼，怎麼去判斷做的結果對不對？

　　是以，我們在設計用例時盡量考慮簡單傻瓜的用例，操作步驟簡單，預期結果容易判斷等。

　　從簡單開始

　　對于新需要自動化的項目來說，自動化測試的實施是循序

漸進的，不要一上來就設計幾百條用例，而是逐漸的将功能用例轉成自動化用例，在轉的過程中需要不斷的調整測試結構。然後，再增加穩定的測試用例。然後，再

調整測試結構。随着功能的增加你的自動化測試架構也在逐漸穩定，基礎測試用例也在增加。一上來就幾百條用例，需求的稍微變化，用例就可能大調整，那麼你很

可能每天疲憊于用例的維護。

　　是以，在開始自動化的時候，你可以隻對登入功能寫個十來條的自動化用例。進而，漸漸的考慮将更多功能自動化起來。

　　半自動化對于測試人員是個不錯的開始，這樣你可以将更多的精力花在安全測試，探索性測試，甚至是用例體驗上等。不要覺得全職自動化就是多麼高大上的職位。