第三章 Webdriver Java API簡介(下)

------Web自動化測試之Webdriver+TestNG--從零到熟練（系列）

3.5  Xpath定位方法深刻探討

相比cssSelector，xpath是我比較經常使用的一種定位元素的方式，由於它很方便，缺點是，消耗系統性能。若是Xpath使用的比較好，幾乎能夠定位到任何頁面元素，並且受頁面變化影響較小。

（1）經常使用的Xpath定位方法及其特色

• Ø 使用絕對路徑定位元素。

例如：driver.findElement(By.xpath("/html/body/div/form/input"))。

特色：這個路徑是從網頁起始標籤開始一直到要定位的元素的路徑，若是要定位的元素在頁面最下面，則這個Xpath路徑會很是長。若是在要定位的元素與頁面開始之間的元素有任何增減，元素定位就會失敗。

• Ø 使用相對路徑定位元素。

例如：driver. findElement(By.xpath ("//input") ) 返回查找到的第一個符合條件的元素。

特色：相對路徑通常只會包含與被定位元素最近的幾層元素有關，相對路徑寫的好的話，頁面變更影響最小，並且定位準確。

• Ø 使用索引定位元素，索引的初始值爲1，注意與數組等區分開。

例如：driver. findElement(By.xpath ("//input[2]") )返回查找到的第二個符合條件的元素。

特色：若是一個頁面中有多個類似的元素，或是一個層下面有多個一樣的元素的時候，須要用索引的方法來定位，不然沒法區分。

• Ø 結合屬性值來定位元素。

　　例如：driver. findElement(By.xpath ("//input[@id='username']"));

driver. findElement(By.xpath ("//img[@alt='flowr']"));

特色：屬性定位也是比較經常使用的方法，若是元素中沒有常見的id,name,class等直接有方法可調用的屬性，也能夠查找元素中是否有其餘能惟一標識元素的屬性，若是有，就能夠用此方法定位。

• Ø 使用邏輯運算符，結合屬性值定位元素,and與or。

例如：driver.findElement(By.xpath("//input[@id='username' and @name='userID']"));

特色：多個屬性值聯合定位，更能準肯定位到元素。而且若是多個相同標籤的元素，若是其包含的屬性值有不一樣的，也能夠用這個方法區分開來。

• Ø 使用屬性名來定位元素。

例如：driver. findElement(By.xpath ("//input[@button]"))

特色：此方法能夠區分同一種標籤，含有不一樣屬性名的元素。定位相對簡單一些兒，但也一樣存在着沒法區分同種標籤含有同種屬性名的多個元素，這個時候要配合索引定位才行。

• Ø 相似於cssSlector，使用部分屬性值匹配元素.

例如：

（a）starts-with()   

driver. findElement(By.xpath ("//input[stars-with(@id,'user')]"))

（b）ends-with()       

driver. findElement(By.xpath ("//input[ends-with(@id,'name')]"))

（c）contains()       

例如：driver. findElement(By.xpath ("//input[contains(@id,"ernam")]"))

   特色：此方法更加靈活，能夠定位屬性值不太規律，或是部分變更，中間有空格的狀況。注：若是屬性值中間包含空格，Webdriver定位的時候容易出錯，時而能定位到時而定位不到，因此應該避免用含用空格的屬性值定位。能夠採用此方法，進行部分屬性值定位。

• Ø 使用任意屬性值匹配元素。

例如：driver. findElement(By.xpath ("//input[@*='username']"))

特色：此方法至關於模糊查詢，只要欲定位的標籤，如input中任何屬性值等於‘username’,就能匹配成功。缺點，可能會匹配含有這個屬性值的其餘元素，因此咱們在定位的時候要查看一下這個元素值在頁面中是否惟一。

（2）運用Xpath定位元素的思路

當咱們在作自動化測試的時候，欲對一個頁面元素定位，經過上面咱們講到的選擇定位方法篩選後，決定用Xpath定位了，此時咱們應該怎麼寫Xpath呢？請按如下步驟來分析：

（a）先看一個這個元素是否有明顯的，惟一的屬性值。若是有，咱們就用相對路徑加屬性值定位，這是最簡單準確的定位方法。如://input[@alog-alias=’search’]。

（b）若是要定位的元素，不符合上面的特症，元素屬性要麼是動態的，要麼就是不能區分這個元素的，還有就是屬性值中間有空格的狀況，都沒法定位。因此今後元素開始，向他的上一層查找。

（c）當遇到了一個符合條件的元素時，對其寫Xpath，而後在Selenium IDE中驗證是否能定位到該元素。如：//div[@type=’good’],在Selenium IDE中驗證能定位到這個div。

（d）而後從這個元素開始，一級級往下寫，真到要定位的元素爲止。若是你比較確定寫的是正確的，能夠寫完後再驗證，若是不願定，就寫一層，用Selenium IDE驗證一下，以確保安全。如：//div[@type=’good’]/div/input

（e）當Selenium IDE定位成功後，再放到測試用例中去調試運行。雖然Selenium IDE能定位到的代碼也能定位到，不過還有由於延遲，操做順序等會影響代碼定位的因素存在。

3.6 元素定位不到的緣由及解決辦法

在咱們編寫自動化測試用例的過程當中，常常會遇到元素定位不到的現象，有的時候咱們用Selenium IDE檢查的時候也能在Firebug中看到，但是運行代碼的時候，老是提示元素找不到。通過我以往和經驗和你們在網上的討論，我總結了如下幾種狀況：

（1）定位屬性值是動態變化的狀況

現象：在咱們定位元素的時候，發現有id, name或其餘的屬性存在，因而就用相應的定位方法去定位。但是運行的時候提示定位不到，而後咱們再去查看元素的時候，發現屬性值和咱們寫代碼的時候不同了。

緣由：一般產生這種狀況的緣由就是你使用的屬性值是動態變化的，主要表現有屬性值是一串數據，或是字符加一串數據等狀況。頁面加載一次變化一次，每次都不相同。

解決辦法：咱們應儘可能避免用這樣的屬性值去定位，而採用這個元素下的其餘固定不變的屬性值。或是向上層查找，採用Xpath定位。

（2）Iframe中的元素定位出錯的狀況

現象：咱們在定位元素的時候，查看網頁源碼，發現有iframe存在。但是咱們沒有作特殊處理，而是直接用通用的定位方法，name ,id,  xpath或者CSS來定位。用Selenium IDE驗證能查找到元素，但是運行測試用例的時候，老是元素找不到。

緣由：在咱們運行測試腳本的時候，代碼獲取的是頁面的句柄，而iframe在句柄中是當成一個元素來處理的。腳本是沒有辦法本身去iframe中去定位元素的，因此當搜索完頁面時，發現找不到要定位的元素，就當錯誤處理。

解決辦法：當須要定位iframe中的元素的時候，先將句柄切換到iframe中（driver.switchTo().frame("framename");），而後再去定位，就能定位到要測試的元素。

（3）不一樣頁面或iframe切換時元素定位狀況

現象：當咱們在編寫測試用例的時候，會遇到打開一個新頁面，或是切換到一個新的iframe中，而後再去定位元素進行操做。可是咱們的定位方法寫的沒有問題，並且在Selenium IDE中也驗證經過，但是代碼運行的時候仍是會提示找不到元素。

緣由：其實這個和定位iframe中元素的狀況是同樣的，在打開一個頁面或是切換到一個iframe的時候，driver獲取的是當前頁面或是iframe的句柄。當你的操做切換到新的頁面或是iframe的時候，若是代碼不去作相應的切換，查找元素的時候還會在原來的句柄下查找，固然會出現查找不到的狀況。

解決辦法：當操做切換頁面或是iframe的時候，咱們的測試腳本也要作相應的切換，選擇新打開的頁面或是切換到新的iframe下。而後再去定位的時候，就會在新頁面或是iframe下定位了。

（4）Xpath編寫出錯的狀況

現象：若是咱們對一個元素編寫了對應的Xpath，而後在沒有經過Selenium IDE進行驗證的狀況吧，就去編寫代碼執行測試用例。會出現查找不到元素的狀況，或是頁面發生了變化，致使Xpath路徑有了變化，也會查找不到元素。

緣由：主要的問題就是Xpath編寫出錯了，或是頁面有改動。無論是增長了新的模塊或是隱藏的div，都會影響Xpath路徑的。

解決辦法：將代碼中的Xpath拷出來，放到Selenium IDE中進行驗證。若是出錯了，就作相應的修改。這個也是代碼維護中當遇到的問題，被測試對象變化，致使測試用例的修改。

（5）操做速度過快，被定位的元素沒有加載出來的狀況

現象：在測試用例運行過程當中，會出現被定位的元素有的時候能定位的到，有的時候卻定位不到的現象。而咱們去頁面上驗證咱們的定位方法的時候，沒有一點兒問題，顯示不是定位方法寫錯了。

緣由：這種狀況多半是由於測試用例執行到代碼的時候，被定位元素沒有加載出來形成的。網速緣由，執行代碼的機器緣由，都會形成加載比程序執行的慢的狀況。

解決辦法：在咱們定位元素以前，評估一下頁面的加載狀況，若是有加載慢的地方，須要添加必定等待時間self.sleep(5000),等上幾秒後再去定位操做。

（6）定位頁面嵌入式元素的狀況

現象：在頁面中會有一些兒嵌入式元素，如object,播放器等。這個時候，咱們對其操做的時候，是沒法定位到上面的元素的。

緣由：嵌入式元素對webdriver來講是一個元素，無論裏面包含多少元素，都沒法操做。對於object對象，網上有說要對相應的Flash從新編譯，添加相應的代碼或是控件才能定位。但這樣同樣又不安全了，因此嵌入式對象一直是自動化測試的盲區。

解決辦法：嵌入式對象若是是簡單的單擊操做，但是用模擬鼠標單擊相應的區域，就能完成操做。若是是輸入操做，咱們能夠先模擬點擊輸入區，而後模擬鍵盤進行輸入。除此以外，好像也沒有什麼好的辦法。

（7）firefox安全性報錯的狀況

現象：firefox安全性強，不容許跨域調用出現報錯，錯誤描述：uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMNSHTMLDocument.execCommand]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location:

緣由：這是由於firefox安全性強，不容許跨域調用。

解決辦法：Firefox 要取消XMLHttpRequest的跨域限制的話，

第一是從 about:config 裏設置 signed.applets.codebase_principal_support = true； （地址欄輸入about:config 便可進行firefox設置）。

第二就是在open的代碼函數前加入相似以下的代碼：

try { netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");

}

catch (e)

 {

alert("Permission UniversalBrowserRead denied.");

 }

對錯誤進行處理。

3.7 檢查點的設置

   自動化測試不像手工測試，在執行測試用例的過程當中，咱們能夠隨時看到結果，而後能判斷正確與否。而自動化測試對應的就是檢查點，若是不設置檢查點，只有測 試步驟的自動化測試是沒有任何做用的。由於執行步驟執行完了，結果不是咱們想要的時候，測試用例也是正確的。因此檢查點纔是自動化測試執行成功或是失敗的 檢驗標準，而檢查點的設置是發現Bug的關鍵。

3.7.1 經常使用的檢測點設置方法

   咱們經過了一系列的操做後，就須要檢查測試執行的結果，經常使用的就是Assert相關的函數。下面咱們談一下最經常使用的兩種方法：

（1）手工設置檢測點

在咱們測試用例執行完成以後，對測試結果進行檢測。咱們仍是個例子來講明一下：

例子：在衆籌網上喜歡一個項目，在進行了一系列的喜歡操做後，咱們要檢測操做是否成功。

• 進入到「喜歡的項目」列表頁，檢查是否有剛剛喜歡的項目。
• 咱們能夠直觀地看到有喜歡的項目，但是怎麼用程序判斷呢？如圖3.7.1所示：

 

圖3.7.1 檢查喜歡的項目

Ø  咱們要先定位項目名稱「Girls Summit組合首張EP衆籌」對應的Xpath：「//div[@class='m-location']/table/tbody/tr[2]/td/div/div/p/a」，而後獲取這個元素對應的Text。

Ø  將獲取到的Text與「Girls Summit組合首張EP衆籌」字符串進行assertEquals(),若是相同，則說明喜歡成功。不然，喜歡操做失敗。

Ø  一樣方法驗證一下日期是否是今天，若是不是，多是先前喜歡的操做，測試用例仍然失敗。

（2）Selenium IDE設置檢測點

咱們也能夠用Selenium IDE錄製測試用例，在操做完成後，須要添加檢測點，此時只要利用Selenium IDE提供的「Show all Available Commands」菜單選擇合適的檢測點便可。

例如：一樣是上面的那個喜歡項目操做的例子，咱們的設置步驟以下：

• 進入到「喜歡的項目」列表頁，檢查是否有剛剛喜歡的項目。
• 如圖3.7.2所示，右擊項目名稱，選擇「Show all Available Commands」菜單，而後在打開的子菜單中選擇合適的Assert菜單。

 

圖3.7.2 selenium IDE設置檢測點

• 而後Selenium IDE中就會出現相應的assert命令，如圖3.7.3所示：

 

圖3.7.3 Selenium IDE記錄Assert操做

• 轉化成相應的編碼，如python,就能夠直接拷到測試用例中使用。轉化後的編碼如：assertEqual(u"Girls Summit組合首張EP衆籌", driver.findElement(By.linkText(u"Girls Summit組合首張EP衆籌").text)

3.7.2 檢測點設置技巧

正如咱們上面所說的，好的檢測點是發現Bug的關鍵。可是並非說檢測點設置的越多越好，由於檢測點會消耗機器資源，測試用例出錯的時候增長排查難度。因此如何設置檢測點呢？一般能夠參考以下方法：

（1）根據測試用例的側重點設置檢測點

每一個測試用例都有測試的重點，好比說，咱們測試登陸的時候，登陸是否成功，就須要檢測。可是在咱們測試喜歡項目的時候，須要先登陸，這個時候登陸就不須要設置檢測點了，由於在登陸測試用例中已經測試過了。

（2）設置檢測點要全面

咱們在編寫測試用例的時候，必定要全面瞭解測試操做影響了哪些兒方面。對影響到的地方，都設置一下檢測點，防止出現遺漏的地方。

（3）設置檢測點要靈活

設置檢測點的時候，咱們一般會比較一下實際的結果和預期結果是否相同。但是有些兒時候，咱們不能簡單地進行是否相等來判斷。好比說：檢測圖片的時候，可能 會檢測圖片是否顯示；有的檢測對象在某些兒頁面會換行或是添加空格，與預期有變化，這個時候咱們能夠判斷是否包含關鍵字便可。靈活使用各類判斷函數，才能 使自動化測試用例更加健壯。

3.7.3 檢測點設置中常見的錯誤

   在測試過程當中，咱們編寫了測試用例，設置了檢測點，但是在測試用例投入使用的過程當中，咱們不得不反覆修改測試用例。由於測試用例老是通不過，維護成本很高。雖然這一部分是由於被測對象變化形成的，還有一部分緣由是檢測點設置的不對。因此常見的檢測點設置中的錯誤以下：

（1）檢測動態變化的元素

檢測點不能隨着操做而變化，好比說翻頁。咱們想要測試翻頁是否成功，就不能去檢測第二頁第一個元素是不是某個項目。由於若是項目增長的話，第二頁第一個元 素的項目可能會變化。應該先取一下第一個位置的項目名稱，而後翻頁，再判斷如今第一個位置的項目是否是和剛剛獲取的項目名稱相同，若是不一樣，就證實翻頁成 功。

（2）遺漏檢測點

在一個測試用例中，咱們要檢測全部影響到的地方。如喜歡項目操做，若是咱們只檢測個人喜歡項目列表中有沒有剛剛喜歡的項目，這是不夠的。還要檢測一下這個項目的喜歡數據是否+1，喜歡項目的入口是否變成已喜歡等相關檢測點。

（3）檢測點設置過多

既然上面講到，檢測點是檢測Bug的關鍵，咱們就在每一步操做後添加檢測點。這樣作也是多餘的，雖然增長檢測點，更加安全一點兒，可是過多的檢測點影響測試用例運行。並且測試用例若是出錯了，咱們去定位錯誤的時候，是很是困難，或是一個測試用例出錯會致使相關的測試用例沒法執行。

（4）忘記設置檢測點或是檢測點不是測試重點

新手寫自動化測試用例的時候，每每會寫了每一步的測試操做代碼，沒有添加對應的檢測點或是檢測點設置不正確。明明是登陸操做，操做完成以後卻檢測頁面顯示是否正確，這樣會無論操做成功與否，測試用例都不會報錯，使自動化測試用例失去了意義。

（5）檢測須要刷新纔有反映的元素

在測試的時候，有些兒元素在操做完成後須要刷新一下頁面才能顯示出操做的結果。手工測試的時候，通常會觸發刷新操做，但是自動化的時候，若是不刷新，就不符合預期結果。因此咱們要添加刷新頁面的代碼，而後再去檢測。

這幾種是常見的錯誤，固然也會有一些比較奇葩的檢測點設置錯誤的狀況。在此也不能一下列舉了，遇到問題，要多嘗試幾種方法，會在網上搜索解決辦法，這也是學習自動化測試必備的技能。

3.8 本章小結

本章咱們講解了Webdriver java　API的一些基本操做和頁面元素的定位方法，檢測點的設置以及常見的錯誤。經過本章的學習，咱們對頁面元素的定位及相關操做有了進一步的瞭解。在此咱們重複了python+webdriver教程中的內容，但願對沒有看過那個教程的同窗有所幫助。下章咱們開始講解，如何從須要開始一步步到自動化測試用例的編寫，運行，以調試輸出。