我發現很多人，包括論壇上的網友，還有很多身邊的同事都對UI自動化充滿了一些恐懼感，從而不敢觸及它。當然也有一定的原因是覺得UI自動化沒太深的技術含量，這也是我討厭UI自動化的唯一原因。但是，一旦讓這些人去做UI自動化的話，是很難做好的，因為UI自動化需要一定的經驗，而我個人認為一年的經驗，一個正規的項目應該都能具備編寫良好UI自動化測試的能力。因此，對于后來的人，我想把UI自動化關鍵的幾條再談一談，UI自動化確實沒什么技術含量，你掌握了以下幾點也能成為一個小專家了。
1. 用高級語言編寫自動化程序，在UI的部分調用UI自動化工具。我反對純用UI自動化工具去寫自動化，因為那樣就太死板了，而且功能不強大，不靈活。我推薦學好一門高級語言，把大多數的自動化都用這門高級語言實現，只在需要UI操作的時候才調用UI工具。
2. 只在你測試的UI模塊上進行自動化的測試，其他地方避免用UI去操作，使用高級語言去實現。這樣你需要用UI的地方就進行了最小化，從而使得只有在真正需要UI的地方才自動化UI，因此測試程序會相對更穩定。
3. UI自動化最基本的操作就是發現控件和操作控件。盡量避免用text來發現控件，而使用一些固定的控件屬性來發現，比如Control ID等等。這樣的話，測試程序會更穩定，開發改變文本不會影響到你，而你也不用擔心localization的問題。
4. 操作控件分為模擬用戶操作和事件驅動。簡單的例子就是，模擬用戶操作就是鼠標真的去點一下，而事件驅動則是跳過點擊直接引發點擊的事件。我以前用過具有這種功能的工具，但是最近幾年用的工具不具備這個功能。
5. 解決好同步問題。UI自動化最不穩定的地方就是同步問題了，你不能連續點擊，而需要等待到一定的情況才能進行下一次點擊。各種情況都不太一樣，需要一些經驗進行良好的程序設計。但是，簡單來講，要做到等待的情況發生能立刻返回到程序，不能空等。
6. 減少其他UI對你自動化程序的影響，比如關閉Windows balloon，等等。一般來說是發現了有其他UI影響你的情況，就想一下workaround, 不會有什么大問題。
從我的經驗上來看，一般UI自動化有問題都能歸結于以上幾點，而一旦你解決了以上幾點的話，UI自動化就變成了一個熟練工的工作了，沒什么挑戰性。我本人的有些模塊的UI自動化基本可以達到100%的通過率，而所有模塊的自動化也能達到95%以上的通過率。不過我基本已經脫離UI自動化了，因為太沒有技術含量了，不過我還是認為如果你剛剛進入測試的工作，或者從來沒有接觸過UI自動化，或者從來都沒有做好過UI自動化的話，在這上邊工作個2，3年會有一定的收獲的。
| 控件類型 | 大分類 | 小分類 | 檢查內容 | 結果判定 |
| TextBox | 數值型 | 邊界值 | 輸入[最小值-1] | 程序應提示錯誤 |
| 輸入[最小值] | OK |
| 輸入[最大值] | OK |
| 輸入[最大值+1] | 程序應提示錯誤 |
| 位數 | 輸入[最小位數-1] | 程序應提示錯誤 |
| 輸入[最小位數] | OK |
| 輸入[最大位數] | OK |
| 輸入[最大位數+1] | 程序應提示錯誤 |
| 允許輸入小數位的控件，小數位的長度做以上同樣測試 | 同上 |
| 異常值、特殊值 | 輸入[空白(NULL)]、空格或‘“~!@#$%^&*()_+-={}[]|\:;”’<>,./?;”等可能導致系統錯誤的字符 | 程序應提示錯誤 |
| 禁止直接輸入特殊字符時，使用“粘貼”、“拷貝”功能嘗試輸入，并測試能否正常提交保存。 | 只能使用“粘貼”、“拷貝”方法輸入的特殊字符應無法保存，并應給出相應提示 |
| word 中的特殊功能，通過剪貼板拷貝到輸入框：分頁符，分節符，類似公式的上下標等 | 程序應提示錯誤 |
| 輸入[負值] | 根據設計書要求判定 |
| 輸入設計書中明確指出禁止輸入的數字 | 根據設計書要求判定 |
| 輸入[英文字母] | 程序應提示錯誤 |
| 數值輸入的長度：整型----32位 最大值 65535,最小值-65535；16位 最大值 32767，最小值-32767 | 根據設計書要求判定 |
| 帶符號的數值：帶正號的正數，帶負號的負數 | 根據設計書要求判定 |
| 小數：小數點后的位數，小數的四舍五入問題，小數點前零舍去的情況，如 .12；多個小數點的情況；0值：0.0，0.，.0 | 根據設計書要求判定 |
| 分數：如 2/3 | 根據設計書要求判定 |
| 首位為零的數值：如01＝1 | 根據設計書要求判定 |
| 科學技術法是否支持：如 1.0E2 | 根據設計書要求判定 |
| 指數是否支持 | 根據設計書要求判定 |
| 全角數字和半角數字的情況 | 根據設計書要求判定 |
| 數字與字母的混合：16進制數值，8進制數值 | 根據設計書要求判定 |
| 貨幣型輸入項：允許小數點后幾位 | 根據設計書要求判定 |
| 字符型 | 字符種類 | 輸入[全角字符] | 根據設計書要求判定 |
| 輸入[半角字符] | 根據設計書要求判定 |
| 數字字符 | 根據設計書要求判定 |
| 郵政編碼輸入項的輸入限制，如只能輸入半角數字字符或某幾個指定字符 | 根據設計書要求判定 |
| 電話號碼和傳真輸入限制，如只能輸入半角數字字符和半角括號“()”及半角減號“-”；電話或傳真只能輸入數字和減號。 | 根據設計書要求判定 |
| E-mail地址的格式檢查，如輸入字符串中必須包含“@”和半角“.”字符。 | 根據設計書要求判定 |
| 年齡的輸入限制檢查，一般<=200即可。 | 根據設計書要求判定 |
| 輸入設計書中明確指出禁止輸入的字符 | 程序應提示錯誤 |
| 輸入[空白(NULL)]或“~!@#$%^&*()_+-={}[]|\:;”’<>,./?;”等可能導致系統錯誤的字符 | 程序應提示錯誤 |
| 密碼輸入項的特殊處理 | 登錄驗證時大、小寫是否區分 | 根據設計書要求判定 |
| 登錄只能輸入半角字符 | 根據設計書要求判定 |
| 是否允許輸入特殊字符 | 根據設計書要求判定 |
| 多行文本框輸入 | 允許回車換行 | 根據設計書要求判定 |
| 保存后再顯示能夠保持輸入時的格式 | 根據設計書要求判定 |
| 僅輸入回車換行，檢查能否正確保存；若能，查看保存結果。若不能，查看是否有正確提示 | 根據設計書要求判定 |
| 僅輸入空格，檢查能否正確保存；若能，查看保存結果。若不能，查看是否有正確提示 | 根據設計書要求判定 |
| 長度檢查 | 輸入[最小字符數-1] | 程序應提示錯誤 |
| 輸入[最小字符數] | OK |
| 輸入[最大字符數] | OK |
| 輸入[最小字符數+1] | 程序應提示錯誤 |
| 文件名輸入項的測試 | 輸入不存在的文件名 | 程序應提示錯誤 |
| 輸入文件名稱超長（256個字符） | 程序應提示錯誤 |
| 輸入帶路徑的文件名和不帶路徑的文件名 | 根據設計書要求判定 |
| 手工輸入后綴名稱 | 根據設計書要求判定 |
| 對于文件大小的限制，需要采用邊界值法測試系統的處理方式是否符合需求；考慮磁盤空間不足/滿的情況 | 程序應提示錯誤 |
| 文件名的非法字符集：/\:*?"<>| | 程序應提示錯誤 |
| 不輸入文件名和輸入空格 | 程序應提示錯誤 |
| 輸入中間有空格的路徑名和文件名 | 根據設計書要求判定 |
| 輸入合法字符，但影響系統判斷文件名有效性的情況，如輸入a;b-20003.5.8 | 根據設計書要求判定 |
| 日期型 | 合法性檢查 | 日輸入[0日] | 程序應提示錯誤 |
| 日輸入[1日] | OK |
| 日輸入[32日] | 程序應提示錯誤 |
| 月輸入[1、3、5、7、8、10、12月]、日輸入[31日] | OK |
| 月輸入[4、6、9、11月]、日輸入[30日] | OK |
| 月輸入[4、6、9、11月]、日輸入[31日] | 程序應提示錯誤 |
| 輸入非閏年,月輸入[2月]、日輸入[28日] | OK |
| 輸入非閏年,月輸入[2月]、日輸入[29日] | 程序應提示錯誤 |
| (閏年)月輸入[2月]、日輸入[29日] | OK |
| (閏年)月輸入[2月]、日輸入[30日] | 程序應提示錯誤 |
| 月輸入[0月] | 程序應提示錯誤 |
| 月輸入[1月] | OK |
| 月輸入[12月] | OK |
| 月輸入[13月] | 程序應提示錯誤 |
| 異常值、特殊值 | 輸入[空白(NULL)]或“~!@#$%^&*()_+-={}[]|\:;”’<>,./?;”等可能導致系統錯誤的字符 | |
| 時間型 | 合法性檢查 | 時輸入[30時] | 允許輸入30時制的項目“OK";
不允許輸入30時制的項目程序應提示錯誤 |
| 時輸入[31時] | 程序應提示錯誤 |
| 時輸入[00時] | 程序應提示錯誤 |
| 30時制是否允許存在1點~5點 | ？？ |
| 分輸入[59分] | OK |
| 分輸入[60分] | 程序應提示錯誤 |
| 分輸入[00分] | OK |
| 秒輸入[59秒] | OK |
| 秒輸入[60秒] | 程序應提示錯誤 |
| 秒輸入[00秒] | OK |
| 異常值、特殊值 | 輸入[空白(NULL)]或“~!@#$%^&*()_+-={}[]|\:;”’<>,./?;”等可能導致系統錯誤的字符 | 程序應提示錯誤 |
| 特定值（如：只允許輸入："0","1"等） | 合法性檢查 | 分別輸入所有允許輸入的特定值 | OK |
| 輸入任意不屬于特定值范圍的字符 | 程序應提示錯誤 |
| 異常值、特殊值 | 輸入[空白(NULL)]或“~!@#$%^&*()_+-={}[]|\:;”’<>,./?;”等可能導致系統錯誤的字符 | 程序應提示錯誤 |
| ChcecBox | 復選 | 連續選擇 | 連續選擇相鄰的checkbox | OK |
| 跳躍選擇 | 跳躍選擇不連續的checkbox | OK |
| ComboBox | 單選 | | 選擇某一個列表項 | 被選中項目高亮或底色顯示 |
| 復選 | | 使用ctrl選擇多個列表項 | 根據設計書要求判定
允許多選時，所有被選中項目高亮或底色顯示；
不允許多選時，只有第一次被選中的項目高亮或底色顯示，再點擊其他項目應無反應； |
| 0, 11, 92, 23, 0, 60, 93, 11 Bitmap | 鼠標操作 | 上鍵頭 | 鼠標點擊按件的“上箭頭” | text框中數量自動+1 |
| 下鍵頭 | 鼠標點擊按件的“下箭頭” | text框中數量自動-1 |
| 鍵盤操作 | 上鍵頭 | 按下鍵盤的“上箭頭” | text框中數量自動+1 |
| 下鍵頭 | 按下鍵盤的“下箭頭” | text框中數量自動-1 |
| 箭頭控制輸入值 | 邊界值 | 輸入[最小值-1] | 程序應提示錯誤 |
| 輸入[最小值] | OK |
| 輸入[最大值] | OK |
| 輸入[最大值+1] | 程序應提示錯誤 |
| text框輸入值 | 同TextBox輸入測試
|
最近還是發現有一些文章，個人對于自動化測試報有很大的懷疑態度，本人也對相關的文章給與了駁斥。我個人和公司對自動化測試都是報有很積極的態度的。這里我想再次的寫一篇文章來闡述到底UI自動化測試可以做什么，作為一個優秀的UI自動化測試工程師應該具備有什么方面的技能，以及本人對UI自動化的一些經驗和體會。
首先還是要強調一點，API和command line程序都是非常適合用自動化來進行測試的。我想這個觀點，即使那些反對自動化測試的人也不應該否認吧？至少我覺得他們應該有這個意識。因此，對于他們反對自動化就集中在了UI自動化方面，我這里也完全站在UI自動化測試的角度來寫這篇文章，后邊就不再強調了。
再次套用朋友的一句話，＂自動化測試聽起來很神秘，學起來很簡單，用起來很麻煩＂。我想有過自動化測試經驗的人，可能大多都有這個體會吧？前邊的過程我就不提了，以后主要探討為什么用起來會麻煩和怎樣簡單化自動化測試。總而言之，想搞好自動化測試，還是需要測試人員比較高的技術水平，尤其是編程能力和解決問題，分析問題的能力。
首先，我要談談自動化測試工具和編程語言的關系。作為一個優秀的自動化測試人員，他的最基本的能力就是編程水平了。所謂編程就是至少要精通一門高級語言，比如Java，C＃等等，腳本語言不計算在內。請記住，不是熟悉，是精通。高級編程語言給我們提供很強的能力來實現一些東西。你所精通的語言能力越強，你在自動化測試可以做的事情就越多，越好。簡單來講，論程序的能力來排序是這樣的，測試工具－〉腳本語言－〉高級語言（Java，C＃）－〉 C／C＋＋－〉C＋＋／CLI。根據這個語言能力的排序，結合你自己的語言能力，你可以想想你到底具備多少自動化測試能力。我所強調的是，如果你想優秀，你至少要精通一門高級語言，這是必不可少的。如果很多人還只是用測試工具，腳本語言工作而抱怨自動化，我要強烈的建議他們好好去學習一下編程能力先了。他們的問題在于，由于編程能力的不足，使得自動化測試的很多問題沒有能力和辦法去解決。再談一下自動化測試工具，無論哪種測試工具，無論他們設計的多么強大，從編程語言來講，他們最多能夠達到腳本語言的能力。也就是說，如果你完全用測試工具來進行自動化的開發，很多問題你還是無法解決的。因此，我推薦的自動化開發方法是高級語言結合測試工具。我的自動化測試邏輯是，用測試工具只是完成UI操作，其他部分完全用高級語言來實現。我們不能否認高級語言所具有的能力，他們創造出了世界上這么多豐富多彩，這么多優秀的軟件，難道開發測試程序會有問題嗎？因此，我們的焦點就落在了測試工具的UI操作部分。
第二，關于測試工具。開發語言重要，選擇一個合適的測試工具也同樣的重要。一個靈活，強大的測試工具可以使你的自動化開發起到事半功倍的作用。結合不同的項目，不同的語言，你可能會有不同的選擇。不過，這里我想解釋的是，具有了高級語言的開發能力之后，我們期望測試工具來為我們做什么。我前邊也說過了，我們所要求自動化測試工具所做的就是UI的操作。這里邊比較重要的是三個方面，一是找到UI對象，二是操作UI對象，三是同步。如果一個工具能夠讓你找到所有的UI對象，并且能成功操作這些對象，就完全滿足我們的自動化開發需要了。如果，工具能夠提供同步的功能，就使你能夠如虎添翼，不然的話要自己去實現，會麻煩不少。到了這里，你已經具有了所有UI的操作能力（測試工具提供），并且具有了高級語言的實現能力（高級語言提供），你才有了基本的能力去做一個優秀的自動化開發。沒有這些能力的人，我嚴重懷疑能否做出好的自動化測試。
第三，怎樣自動化。我的自動化的原則是，盡量少的進行UI的操作，除非是你本身要測試的UI。道理很簡單，UI操作由于可能受各種問題的干擾，很容易失敗。通過非UI的方法去實現是更加可靠和快速的。這也是我為什么要強調對于高級語言的精通，具有高級語言的開發能力，你就能過把大量的任務從UI操作轉向了程序操作，使得你的自動化程序的可靠性大大的增強。這里還需要強調的一點能力就是系統應用的能力，比如Windows使用的能力。Windows的很多的操作是有相關的命令來實現的，不一定非得通過大家熟悉的UI。記住這個原則：除非是你要測試的UI，否則盡可能的通過高級語言來實現。我想大家對于高級語言來實現的工作應該還是有信心吧？因此，下邊我要談的內容就完全的與你要測試的界面相關了。
第四，怎樣進行UI測試。首先要盡量的減少UI操作，除非是你必須要測試的操作。比如簡潔快速的啟動你要測試的界面，用快捷鍵代替鼠標操作等等。總而言之，理想狀態下我們進行的每一次UI操作，都是我們需要測試的，其他操作盡量避免，不能避免用最可靠的方式去實現。那么我們現在的焦點就變成了，怎樣來處理我們真正要測試的UI了。UI測試的開發基本上就三個問題：發現對象，操作對象和同步。簡單解釋一下同步，同步就是有一個機制告訴你何時可以執行一個 UI操作。很多人是用sleep的方式，等待一定的時間去執行下一個操作，這是我非常反對的。我的原則是，盡量少用sleep，就算要用每次最多不要超過一秒。濫用sleep會嚴重影響測試程序的性能（具體的UI自動化過程，大家可以參考我的其他文章）。
第五，UI測試錯誤／異常的解決和Debug。通過以上的解釋，我們只是在自己需要測試的UI操作才進行UI操作，否則通過高級語言或者系統命令來實現。是不是我們的UI自動化就完美了呢？絕對不是，這只是一個基礎，還遠遠沒有達到完美。我們在自動化開發和應用的過程中，大部分的時間其實是花費在了異常／錯誤處理和Debug上面。這跟真正的程序開發非常的類似，你如果去看代碼的話，大量的是在進行返回值得檢驗和異常的處理。如果我們的程序在運行過程中出了問題怎么辦，或者如果沒有出現我們期望的結果怎么辦？一般來說有三種問題，第一是產品的問題，我們可以報bug了，第二是你測試程序的bug，你需要fix。第三是其他的問題，比如測試工具，甚至高級語言本身的問題，你需要workaround。總而言之，優秀的測試程序最終的目的是，一旦程序的運行發現了問題，就是產品的問題，就是可以報bug的。能夠達到這種境界才能算自動化測試的完美，才能算是一個真正優秀的測試人員。（當然了，正如軟件產品不可能沒有bug，你的測試程序也不可能完全沒有bug。但是，由于軟件產品是有大量的用戶來使用，而你的測試程序只是很小范圍內來使用，使得你消除影響測試過程的bug成為完全可能）
綜上所述，一個優秀的自動化測試工程師必須要具備高級語言的開發能力，自動化工具的靈活應用能力，系統命令和使用的熟練能力等這些基本功，還更要具備優秀的Debug，Fixbug的能力，和保持程序穩定性能力。換句話講，一個優秀的自動化測試工程師必定也是一個優秀的軟件開發工程師。
最后談一下我為什么要轉向C＋＋／CLI？從上邊的排序大家可以看到，C＋＋／CLI是目前Windows平臺最強大的編程語言。在我的自動化開發的過程中，我需要高級語言和系統命令都不能完成的功能。如果沒有C＋＋／CLI我就必須要通過UI來實現，從而降低我程序的可靠性。而有了C＋＋／CLI的功能，我就可以繞過UI操作了。總之，能夠繞過UI操作的能力也體現出一個自動化測試人員的能力。從這個角度講，測試人員有很多東西要學的。最后說一下，我自動化工作的要求是100％可靠，我還不能完全滿足，因為使用我程序的人是那些手工測試的人，他們的使用環境的變化有可能引起一些問題的產生，基本上還不是我程序的問題，而是測試工具，或者其他模塊的問題，我需要想辦法去workaround。不過，隨著一定時間問題的積累和解決，如果環境不變，應該可以達到100％可靠。（可是環境的變化是不會停止的，因此實際上很難達到永久的可靠，不過一段時間的可靠還是應該可以達到的，或者說我們的測試開發必須有這樣一個目標，就如同軟件開發的目標一樣）