自動化測試之控制元件點選

UI自動化測試，首要考慮的是我們所選用的測試工具或框架對測試程式的支援如何。而這個支援，則主要是通過對控制元件的識別和操作來體現的；但是，不管一個測試工具或者框架對測試程式的支援程式如何，它執行測試程式時最終都是以螢幕的絕對座標來定位執行的，儘管我們平時都能聽到很多人在說，儘量避免用座標。
　　儘量避免用座標和最終通過座標來識別，這個看起來有點衝突，但是卻又不會衝突，是不是有點類似太極的感覺了。
　　座標，通常分為兩類：絕對座標和相對座標。
　　1. 通常我們所說的座標都是基於螢幕左上角的絕對座標。測試工具和我們人的操作最終也都是通過這個座標來進行測試程式操作的，只不過有的我們知道，有的我們不知道，僅此而已。
　　通俗的講：我們人手動來點選螢幕的時候，只是在點選的位置傳送一個螢幕點選事件，這個螢幕點選事件通過windows庫定位到當前活動的窗體，再對這個窗體的一個具體位置傳遞點選事件，從而獲得響應。這個過程，在我們的感官和需求中，我們只需要直接對活動窗體的進行操作的結果，至於定位，who care？
　　自動化測試本質上就是來模擬人的行為的操作，所以實現過程大致類似。它首先通過我們在程式碼中編寫的id、text、index、class等來定位到我們要操作的控制元件，然後再讀取這個控制元件的x、y屬性來傳送點選事件。但是，在使用層面，我們只看到了通過id來點選，至於其他獲取座標這些，leave them alone。
　　2. 說到相對座標，這個就稍微有點複雜。目前已知的相對方式有相對左上、左下、右上、右下、中上、中下、居中；並且根據是否隨著父視窗變化而變化，又可分類為：不擴充套件、同步擴充套件(和父視窗一起放大/縮小)、按比例擴充套件(父視窗擴大3倍，該物件也擴大3倍)。
　　舉個例子來說，螢幕上有一個記事本視窗“記事本.txt”，它的座標絕對座標是400,600，這個記事本的開始選單欄，它的座標是450,700。如果假設記事本視窗的座標為，那麼這個開始選單欄就可以描述為：相對於視窗"記事本.txt"的座標為50,100，絕對座標就可以表示為；再假設選單欄中的編輯按鈕絕對座標為500,700，那麼它就可以描述為：相對於選單欄的座標為50,0，絕對座標就可以表示為。這樣的話，這個視窗上的所有座標就都可以用一個座標來維護了，如果視窗位置發生變化，我們也只需要修改一個最上層父視窗的座標就可以動態適配所有按鈕的座標了。
　　上面就是相對的解釋。其實說白了，所謂相對座標，就是一種優化的座標計算方式，可以讓我們用盡量少的改動去適應更多的變化。
　　至於它的相對方式和擴充套件方式，則就只是其中的一些計算方式，在這裡就不一一舉例了。
　　那麼，瞭解了上面的這些，我們可以做些什麼呢？
　　平時在開展自動化測試時，總是會遇到一些不能識別的自定義控制元件，尤其是app型別程式。那麼這時候我們就可以通過上面的座標適配來完善解決一下。
　　下面，我來簡單說一個基於座標的控制元件識別的簡單實現思路：
　　1. 實現思想：通過虛擬截圖的方式來提供一個快速定位虛擬控制元件的座標系，並對齊賦予一些額外的識別引數；嵌入到其他測試工具中直接使用。
　　2. 首先，通過呼叫windows api或者其他截圖程式，對測試程式的全視窗截一個半透明的截圖（可以按比例縮放）；
　　然後，獲取測試程式的座標，並監控這個截圖上的拖拽事件來計算控制元件的座標系，並寫入xml檔案；
　　其次，將這個xml檔案匯入到測試工具的物件庫中進行使用。這裡需要注意，有的測試工具不支援外部自定義物件，所以需要做一些轉換。
　　3. 程式碼：以後再傳吧。這塊東西最好做成視覺化的，比較易於操作

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/11323760/viewspace-1062771/，如需轉載，請註明出處，否則將追究法律責任。