如何利用F#庫canopy進行UI測試

這篇文章將為大家詳細講解有關如何利用F#庫canopy進行UI測試，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

InfoQ：你能否為我們介紹一下canopy？

Chris Holt：canopy是基于Selenium之上，以F#實現(xiàn)的一層功能，它的目標是使UI測試的行為符合使用者的預期。Selenium雖然表現(xiàn)很出色，但有時會顯得過于刻板。在canopy中，所有行為不再會因為無法點擊某個元素而立即報錯，而是不斷地嘗試點擊某個元素，直至一段合理的時間后仍無法點擊才會報錯。這將幫助你創(chuàng)建更可靠的測試，而不是往往只在第一次嘗試時成功的測試。

InfoQ：canopy如何簡化通過Selenium進行UI測試的過程？

CH：canopy內置了重試功能，包括元素的獲取以及用戶在屏幕上的行為，也包括驗證功能。此外，canopy還可以通過實用的錯誤信息幫助用戶修復一些常見的問題，例如某個選擇器的拼寫錯誤。它還支持以多種方式選擇元素，并且易于對這些功能進行擴展。

舉例來說，如果用戶的屏幕上有一個顯示“Save”文字的按鈕，那么只需要在代碼中寫為click "Save"，就可以實現(xiàn)單擊的目的。而在常規(guī)的Selenium代碼中，用戶必須在ByText、ById、ByCSS、ByXPath等方法中進行選擇。如果要擴展這一功能，只需為用戶網(wǎng)頁的慣用方式添加對應的finder實現(xiàn)，例如在表單數(shù)據(jù)中的placeholder值，或是為了表示元數(shù)據(jù)而人為定義的data-*標簽。

canopy還提供了一套簡明的API，讓用戶更方便地閱讀與編寫測試。它還能夠克服html中的各種區(qū)別。比方說，每種輸入類型在html中都有著不同的表現(xiàn)方式，因此通過原始的Selenium操作他們的方式也是不同的。而在canopy中，操作方式都是相同的。舉例來說：

// Assign a value to a textbox or dropdown
"#state" << "New York"

InfoQ：canopy是否支持與外部自動化服務的集成，例如Browserstack？

CH：是的，只要是Selenium支持的功能，canopy也同樣支持。為了支持Browserstack，用戶需要使用RemoteWebdriver。由于canopy本身內置了大量的重試功能，因此交互的次數(shù)將有所增加。不過，因為用戶不必經(jīng)常調用Sleep，因此這種增加的交互是可以接受的。canopy還提供了大量可選的優(yōu)化方式，如果你打算具體地表述選擇器的類型，而不是讓canopy分析你的選擇器類型，就可以應用這些優(yōu)化。

InfoQ：在頁面中選擇元素有沒有推薦的做法？比方說，通過id選擇元素是否會為測試帶來更好的可維護性與健壯性？

CH：在UI自動化中所用到的多數(shù)“技巧”都與選擇元素相關。至于是應該使用整潔的選擇器，還是必須要在標簽中加入class或id等屬性，這兩者之間需要找到一個平衡點。我認為，CSS與JQuery選擇器的語法是最優(yōu)秀的，用戶可以在80-90%的場景中使用這種方式。而在其余10%-20%的場景中可以使用XPath。在進行準確的文字匹配或是找到某個元素的父元素時需要用到XPath。而通過值或內部文字進行查找也是非常方便的做法，假如上文所述的click "Save"這個示例，它的內部實現(xiàn)就用到了XPath。

經(jīng)過一段時間的實踐之后，用戶就可以熟練地掌握創(chuàng)建選擇器的方法了，工建議用戶通過實踐進行學習，而不是通過某種工具去生成選擇器。這種方式更準確，并且當頁面結構發(fā)生變化而影響了用戶的測試時，它也更容易進行修正。一旦用戶對于選擇器有了一定的心得體會之后，用戶就會懂得如何讓html代碼更易于維護，從而簡化了選擇器的創(chuàng)建。

選擇器的編寫可以通過某些方式讓人更易于理解，例如#header .links這個選擇器就表示在頁面的header這個div中所有的links元素。而在自動生成的XPath中，它或許會變成html/body/div/div/div[2]/ul/li/a這種形式，這對于理解它的意義毫無幫助。而且如果一旦在這條選擇鏈中多加了或是刪除了某個div，就會使選擇器無法工作。通過CSS方式編寫的選擇器“永遠”都是有效的，除非有人改動了header這個id，或者刪除/改變了links這個class。

InfoQ：用戶是否可以自定義錯誤報告？比方說，我們是否能夠在測試失敗時自動截屏呢？

CH：canopy目前內置了3種reporter實現(xiàn)，即ConsoleReporter、TeamCityReporter和HtmlReporter。如果用戶需要新增一個自定義的功能，只需簡單地實現(xiàn)IReporter這個接口就行了。

InfoQ：有哪些方法能夠擴展canopy的功能？

1）通過實現(xiàn)IReporter接口，自定義測試結果的輸出。

2) 在canopy所使用的finder集合中添加新的通用finder實現(xiàn)，以幫助用戶找到頁面元素。

3) 為用戶常用的action添加新的函數(shù)。由于F#會運行某個函數(shù)最新定義的版本，因此用戶還能夠“重寫”現(xiàn)有的函數(shù)，以滿足自身的需求。

比方說，用戶可以實現(xiàn)自定義的“click”功能，只需創(chuàng)建一個模塊，例如“canopyExtensions”，并在“打開canopy”操作后“打開”這一模塊，將所有擴展方法與重寫的方法定義在其中。這樣一來，所有測試都會調用由用戶所定義的功能，而無需改動任何現(xiàn)有的功能。

這個示例表現(xiàn)的是某人希望能夠在多選框中實現(xiàn)對元素的Ctrl+Click操作。由于canopy本身不具備這一特性，因此作者編寫了一段擴展方法。

4) canopy并沒有隱藏任何Selenium中的特性，或是對其進行抽象化。它只是使用了IWebDriver與IWebElement接口。用戶在Stack      
overflow網(wǎng)站上看到的各種問題與回復對canopy都是100%有效的。用戶所要做的唯一一件事就是將代碼轉換為F#。

InfoQ：在持續(xù)集成（CI）服務器上運行canopy測試需要經(jīng)過哪些步驟？

CH：測試的運行方式是執(zhí)行由構建過程所生成的控制臺應用。測試結果支持不同的輸出格式。支持TeamCity的配置過程只需一行代碼：

reporter <- new TeamCityReporter() :> IReporter

 

我個人會選擇使用一些簡單的任務來實現(xiàn)整個構建過程，因此我在TeamCity中創(chuàng)建的任務都是很簡單的，例如從源代碼控制系統(tǒng)中獲取最新代碼，隨后通過一個命令行語句啟動我的任務，并完成其余工作。

在Jenkins環(huán)境中，我會選用HtmlReporter，通過一個Jenkins的插件生成html文檔，并保存到整個任務的結果中。這同樣也可以通過簡短的幾行代碼完成設置工作。

關于“如何利用F#庫canopy進行UI測試”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。