UI Automation從項目準備到框架成熟，差不多用去了6個月的時間。這段時間給我了很大的發揮空間和難得的實現自己想法的機會。
昨天發現了當時寫的筆記，覺得可以記錄出來，以後會有用。
1. 對需求進行測試。舉個例子: 項目起初只考慮在一臺機器上運行測試用例，當幾乎所有的單機測試用例都完成的時候，發現需要把多機器聯合操作(run on multipy machines for inter-operation)的測試用例加進來。可是程序設計的時候都是從單機運行用例的角度考慮的，沒有留出可以運行多機情況的想法空間。如果當初就考慮好了多機運行是怎麼走的，那麼起初在設計單機運行的時候做出彈性的框架來兼容多機模式。爲什麼需要對需求進行測試？我覺得是因爲我們經常在項目中期和後期發現需求中包括邏輯不一致的問題，更能發現我們普通人容易犯的一個錯誤是:用另外一個或多個缺陷/錯誤來掩蓋或是互相掩蓋現有缺陷，換句話說叫一錯再錯，錯到我們不認爲錯爲止。
2. 在團隊開發裏，在項目伊始，對所有隊員描述一個大家共同努力的目標。這樣做的好處是在開始的時候就做對的事情，讓每個人都清楚和統一目標，否則有的人會因爲覺得自己的角色可能不重要，所以不用太用心，給全組士氣造成影響。另外一個好處是避免以後再廢話。
3.講述所有人（不同角色的人）所應具備的素質。人就是這樣，如果開始的時候就做對的事情，有了警鳴鐘，事情進展的會順利些。雖然這些事情看似多此一舉，但不得不考慮人的本性就是如此。
4.經常的去思考如何把技術和產品做到最大限度的優秀。這樣會產生一些靈感或想法，來改進現有的東西。
5.使用統一的接口。
6.對領導，要想得到項目的具體實施，需要去爭取他們的肯定和共識。
7.要驗證的場景很多，找出、設計出不同的場景。比如：COM驗證郵件是否發出，郵件文本驗證, 不同控件的特有的點擊事件，用同一套代碼對不同版本產品的驗證等等。
8.UI自動化的技術。UI Automation 離不開像Mita, KAF ,Maui這樣的對UIA技術框架又封裝了一層的框架，準確的應該叫類庫。
他們都有各自的特點:
1):Maui是最貼近UIA core的一層了，KAF,MITA 都是在maui的基礎上建立起來的，這麼說可能不準確，但他們都應用了maui的東西。 2):MITA:要比maui好用，它的架構本身就是應用裝飾模式，並且對windows application 支持的還算不錯，包括WPF,所以使用MITA做UI自動化簡單，宜用，比起UIA框架提供的元素好用多了。
3).KAF:它的內部都引用了Maui和MITA, 可能是考慮到Maui雖低層，但不支持WPF;MITA雖支持wpf,但對外部不公開com. 我覺得KAF就是爲瀏覽器的UI自動化而生。它對瀏覽器的支持超過前兩者。
目前UI自動化的技術還存在很大的缺陷，有三點：
一是在UI element查找時，不支持正則表達式；
二是產品的UI技術總是不斷變化，從win32,到wpf,再到Rebun, 這就造成了對同一個界面元素的唯一標識的不一致性。對自動化開發限制和挑戰很大，針對於特定系統，特定版本的軟件，要有兼容的解決方案才能克服。問題的根源是在產品設計時，開發者就沒考慮UI automation自動化這事，windows OS也很難讓所有在windows上運行的程序都有唯一而且統一的標識。
三是不支持二級查找。目前都是從UI tree的根節點開始查找，而不能直接從所有的二級或三級節點查找ui element.
9.要想提高開發速度，可以通過良好的成熟的架構設計，工具和管理。
10.使用好日誌。記錄信息時，需要記錄好log lelver, when, where, How. 對troubleshooting很有幫助
