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