點擊獲取工具>>程序員
在選擇正確的工具來幫助您成功進行自動UI測試時,您須要瞭解如下內容。工具
爲何不能再忽略自動UI測試?開發工具
儘管面向代碼的自動化測試工具已經變得愈來愈廣泛,但大多數開發公司都忽略了自動化UI測試。這樣作的主要緣由是維護UI測試套件的成本,使用大多數/全部UI測試工具,實際上對應用程序UI的任何更改都會致使UI測試工具將整個應用程序標記爲已損壞。結果,現代軟件開發實踐的大部分過程都是圍繞UI與代碼的精確分離而組織的,所以能夠在不接觸UI的狀況下測試代碼。測試
現實狀況是用戶不與代碼交互:用戶與您的UI交互,從用戶的角度來看,您的UI是您的應用程序,證實代碼在故意忽略UI的狀況下有效的當前作法缺乏了重點。 與當前的實踐相反,UI測試提出一個簡單的主張:要證實您的應用程序已「準備好投入生產」,您必須證實UI可以正常工做並驅動您的應用程序執行正確的操做。編碼
一些基於工具的選項開發
隨着DevOps和對用戶驗收測試的需求增長,這一要求變得愈來愈重要。 結果是UI測試工具獲得了發展,但這也使得開發者更難、也更容易獲取正確的工具集。難點在於有更多選擇可供選擇;容易在於有更多的工具對您有意義。 例如當查看UI測試時,能夠在無代碼工具和基於代碼的工具之間進行選擇。get
無代碼工具容許測試人員經過與應用程序進行交互來建立UI測試,而該工具經過「觀察」用戶的交互和應用程序的響應來生成測試腳本。 這些工具利用「 UI即應用程序」範式,而且不須要測試人員比應用程序(及其相關的業務需求)瞭解更多。自動化
另外一方面,基於代碼的工具要求測試人員編寫腳原本經過代碼(即在頁面上查找按鈕,而後從UI元素提取數據)來操縱UI。 可是,這些工具能夠檢查「反作用」,這些反作用不必定顯示在任何用戶界面(或「能夠做爲測試的一部分進行訪問的任何用戶界面」)中,而且能夠處理各類響應,基於代碼的工具確實要求測試人員知道如何編寫代碼。io
無代碼工具使開發人員脫離了測試的關鍵路徑,並受權用戶建立對其有效的測試。 基於代碼的工具支持更深刻、更完全的探測、並處理各類響應,從而減小錯誤的數量(實際上,在應用程序正常運行時的故障報告)。社區
重要事項
不管您最終使用什麼工具,都須要將它們集成到您的流程中,而不會妨礙您交付應用程序……並在知足組織、用戶和您本身的目標的同時作到這一點。
首先:您是否須要自動化的UI測試? 值得記住的是,測試的目標是將失敗的成本從生產環境轉移到開發環境中。 若是您的團隊對當前的生產失敗水平感到滿意,而且不肯意修改開發實踐,那麼您可能不須要自動化的UI測試。 自動化的UI測試如何符合團隊的戰略目標?
第一個問題與第二個問題重疊:自動化測試如何適應團隊文化?團隊是否重視儘快向但願應對高變化率的用戶社區提供新功能,即便存在一些小故障?仍是團隊更須要高度可靠的應用程序,這些應用程序會隨着時間的推移而穩定,所以能夠知足嚴格的(也許甚至是法規)標準?
反過來,這個問題與第三個問題重疊:自動UI測試將如何適應您的流程? 答案始於用戶什麼時候何地進行驗收測試。例如若是有很長的時間用戶沒有參與開發過程,那麼利用用戶的UI測試策略可能就沒有意義。若是在團隊中若是「編碼器驅動的UI測試」是一個矛盾的話題(即只有最終用戶會說出UI是否「正確」),那麼基於編碼器的方法就沒法適應您的工做方式。
最後一個問題:您能夠利用哪些技能集和現有工具集? 例如,無代碼測試僅在您擁有一羣不只僅「使用」應用程序但有能力知道在測試中什麼是「正確」或「不正確」響應的用戶時纔有意義。 在開發人員方面,您但願查看用於交付應用程序的工具鏈 - 利用團隊在該工具鏈上的經驗並與之集成能夠爲您帶來真正的好處。 不過,有趣的是,在選擇UI測試工具時,用於構建應用程序的開發工具並非特別重要,特別是對於Web應用程序而言。
**[Telerik Test Studio]
比起單一的「 UI測試工具」,更須要一種爲知足特定需求測試而配置的套件,最終會組合一個最佳的套件來知足您的特定需求,可是從單一來源得到完整的解決方案顯然會更方便。
自動化UI測試領域的供應商既重視靈活性,又重視與其餘工具集成的支持。 例如,[Telerik Test Studio]支持無代碼測試,支持將那些無代碼測試轉換爲編碼測試,將編碼步驟與無代碼測試結合在一塊兒,並與第三方庫集成以知足特殊需求。
意味着非程序員(例如QA團隊或最終用戶)能夠建立測試,以證實系統已完成用戶但願系統執行的操做。 將這些無代碼測試與編碼測試無縫結合的能力意味着,當非程序員遇到障礙時,開發人員能夠擴展這些測試以處理「難以自動化」的場景。
建立無代碼測試的能力可是請不要忘記這一點:仍然不是關於工具的問題,而是這些工具是否支持您的目標、流程以及現有技能/工具鏈。若是您對這些內容有很好的瞭解,那麼就能夠獲取在自動UI測試中取得成功的工具。