原創|使用教程|編輯:鄭恭琳|2020-06-09 14:10:21.347|閱讀 168 次
概述:在過去的幾年中,UI測試的活動有所增加。新的令人興奮的工具已進入市場,帶來了各種創新方法,使傳統上相當復雜的過程變得簡單。 過去,我們只有大型解決方案,例如IBM Rational Suite或Mercury/HP/MicroFocus QTP/UFT。現在,我們看到許多人從“傳統”測試自動化工具轉向諸如Selenium之類的開源替代方案,或由mabl,Selenic或Functionize之類的新型創新AI驅動的解決方案或框架。這種轉變引起了很多炒作,但它也植根于解決常見的抱怨和挑戰,如果您采用的是新工具,則需要確保解決。
# 界面/圖表報表/文檔/IDE等千款熱門軟控件火熱銷售中 >>
相關鏈接:
在過去的幾年中,UI測試的活動有所增加。新的令人興奮的工具已進入市場,帶來了各種創新方法,使傳統上相當復雜的過程變得簡單。
過去,我們只有大型解決方案,例如IBM Rational Suite或Mercury/HP/MicroFocus QTP/UFT。現在,我們看到許多人從“傳統”測試自動化工具轉向諸如Selenium之類的開源替代方案,或由mabl,Selenic或Functionize之類的新型創新AI驅動的解決方案或框架。這種轉變引起了很多炒作,但它也植根于解決常見的抱怨和挑戰,如果您采用的是新工具,則需要確保解決。
但是,當然,這不只是挑選“最佳人選”并前往城鎮而已。無論您是決定自己構建框架,擁有最終控制權,還是決定進入擁有高級功能(如自我修復或并行執行)的專有框架,任何解決方案中都應具備七個重要因素考慮。
聽起來像是個問題,對不對?不是。對于希望自動進行Web UI測試但又不想被鎖定在供應商平臺中的組織,Selenium已迅速成為事實上的標準。
作為一個社區,Selenium開放源代碼項目將商業供應商和開放源代碼純粹主義者聚集在一起,使之成為我們行業中最強大的框架之一——并且正在被大量使用。
根據我們的研究,超過64%的用戶正在使用Selenium進行UI測試自動化。你是?
這是必須考慮的因素。您在使用Selenium嗎?如果不是這樣,那么現在正是考慮未來的好時機,以及您希望未來的測試計劃有多靈活。現在市場上的許多解決方案都具有類似Selenium的功能或基于Selenium的,專注于導入/導出純Selenium測試的價值。但是它們不能在純Selenium上運行,也不能執行純Selenium,因此您必須在其技術的限制內工作。
頁面對象模型是一種UI測試設計范例,用戶可以在其中定義與它們所在的頁面相關聯的UI元素。如果您還不熟悉,這是。為了主動解決可維護性問題,您希望UI測試利用此頁面對象模型范式,因為由于元素位置被定義在一個位置,然后在整個測試套件中加以利用,使得維護腳本更加容易。
頁面對象方法功能強大,因為它有助于解決應用程序更改時的可維護性問題。在頁面對象模型中,頁面上的元素是在一個位置定義的,因此,如果您確定某個特定的Web元素已經移動,則不必遍歷整個腳本來更新每個單獨的定位器。頁面對象模型使您可以為頁面上的元素提供單一的事實來源,從而使所有這些工作更加自動化。
執行UI測試時發生的大多數維護問題源于由于應用程序UI更改而中斷的測試用例。因此,在設計UI測試時要做的最重要的事情之一就是建立一種方法來為每個元素定位器創建可靠性和穩定性。
一些新的UI測試工具正在采用獨特的創新方法,使用各種不同的術語,即“智能定位器”或“魔術綁定”。無論如何,在為單個元素定義多個定位器或采用最佳定位器定義策略方面,您有很多潛力可以從所有這些創新中受益。
自我修復聽起來像是在做夢,在這種情況下,我們的自動化測試會自動識別故障發生的位置,然后自行解決問題。瘋狂的是,這實際上在許多流行的UI測試工具中都是現實的。通過利用智能定位器,這些UI測試工具可以在運行時嘗試不同的定位器或在UI中自動識別按鈕的方式。
現在,我已經下定決心,在任何UI測試解決方案中,我都將其視為嚴格的必要條件,因為最終我們將嘗試減少測試流失和總體測試周期。如果您已經創建了數千個UI測試并且每天晚上運行它們,那么您就不希望其中的一半中斷,因為有人將按鈕從“添加”更改為“購物車”,然后又添加到了“購物籃”。
在您的軟件開發組織中,您可能已經在某種類型的IDE(即Eclipse,IntelliJ)中編寫代碼,并且可能正在使用Jenkins之類的構建系統來構建該代碼。這些框架將在您的整個組織中建立,它們都是經過實踐檢驗的框架,因此對于將UI測試解決方案集成到已構建的框架中而言,這顯然是有益的。
許多UI測試工具都是各自獨立的工具,因此可能確實很棒,因為這意味著它們專注于構建可解決所有這些挑戰并最終控制生成的測試腳本的解決方案。但是供應商鎖定(我將在后面再討論)是危險的,并且我們已經看到組織正因為這個原因而放棄大型解決方案。由于開發人員和測試人員比以往任何時候都更加精通技術,因此他們希望訪問其測試腳本。因此,當您查看UI測試工具時,可以看到您的測試腳本是否可以移植,不僅可以與必須集成到DevOps管道中的其他腳本一起使用,還可以真正地集成到現有框架中。
用戶體驗在B2C Web應用程序中尤其重要,在該應用程序中,令人困惑的UI或不可靠的客戶體驗會迅速影響收入,并且組織意識到確保體驗的無縫性至關重要。隨著每天涌現出新項目并且測試要求如此之高,尤其是在轉向敏捷時,能夠使自己擺脫困境可能意味著準時發布和錯過窗口之間的區別。您的UI測試工具將幫助您驗證關鍵的客戶體驗-但是,如果您嘗試做某事并且無法弄清楚,讓供應商的支持團隊為您提供暢通無阻的選擇是您可以做出的選擇,隨時隨地都有。
有一些開放框架可以很容易地集成到您現有的框架中,但是如果沒有強大的支持,當在關鍵版本發布之前出現問題并且沒有人負責時,會發生什么?Selenium是一個很好的例子-盡管它功能強大,并且擁有出色的社區支持,但是當出現問題時,沒有人可以打電話。
正如我之前所說,在過去幾年中,有20多種新的UI測試工具進入了市場。接下來的五個代表什么?毫無疑問,我們現在所做的一切都會改變,尤其是從UI測試的角度來看。必然會出現一些令人興奮的新事物,因此現在考慮我們如何促進遷移過程非常重要。這樣做的關鍵是確保您引入的任何解決方案都不會將您鎖定在專有框架中。
由于Selenium可以在任何管道中輕松執行并以代碼形式實現,因此它具有很高的靈活性。一些新的解決方案已考慮到這一點,并使用導入/導出機制來允許您切入和退出其工具,但是導入和導出需要驗證其是否有效。這并不像您想的那么容易。在我看來,如果供應商對其功能有信心,則應提供此功能。當您查看UI測試工具時,您可以問:“我是否被其框架所束縛?”
如果您正在查看UI測試工具并希望獲得方便的指南,請查看每個人都在談論的十大新UI測試工具,并在考慮應該在軟件交付過程中采用哪些工具時開始提出這些問題。
本站文章除注明轉載外,均為本站原創或翻譯。歡迎任何形式的轉載,但請務必注明出處、不得修改原文相關鏈接,如果存在內容上的異議請郵件反饋至chenjj@fc6vip.cn