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