軟件測度中的失控的UI自動(dòng)化
一提到自動(dòng)化測試，大多數人就會(huì )以為是用硬編碼(hardcode)的事件和數據來(lái)編寫(xiě)腳本，模擬用戶(hù)和軟件之間可能的交互動(dòng)作，來(lái)完成一個(gè)預定義的、機器人執行的任務(wù)�？赡芫褪且驗檫@個(gè)原因， 商業(yè)分析師(Business Analysts)或者黑盒測試者得到了太多的工具來(lái)幫助他們錄制和回放（或者列出相關(guān)步驟的關(guān)鍵字）一些人為設想的用戶(hù)可能會(huì )做的操作步驟。確實(shí)……看著(zhù)窗口開(kāi)關(guān)、鼠標魔術(shù)般的在桌面上移動(dòng)是很酷的一件事。但是，對于任何聰明的的人來(lái)說(shuō)， 這種視覺(jué)上的驚奇往往只能持續……哦……大約1.7秒……之后就變得麻木無(wú)聊了！不幸的是： 自動(dòng)化常常是很短命的， 它需要大量的維護開(kāi)銷(xiāo)，并且是造成那些失敗或談不上成功的自動(dòng)化工程的主要原因。
總的來(lái)說(shuō)我并不是很熱衷于圖形界面的自動(dòng)化測試，這里有很多原因，但是最重要的原因是因為它被濫用了，有一些測試其實(shí)找一個(gè)人能夠執行得更快更好。不過(guò)我也理解在某些場(chǎng)合下圖形界面自動(dòng)化測試的確能夠提供它的價(jià)值。我并不反對圖形界面自動(dòng)化測試，但是絕不主張只是因為能夠自動(dòng)化就用自動(dòng)化測試，或者只是因為我們有的那些荒誕的想法：認為所有的東西都應該自動(dòng)化。
就拿有一次我和一個(gè)測試人員的談話(huà)來(lái)舉例吧。他的經(jīng)理希望他去維護一個(gè)舊的測試用例，這個(gè)用例是用來(lái)檢測一個(gè)操作后箭頭的顏色是否正確。如果操作成功，箭頭的顏色是綠色，否則就是紅色�，F在，可以看出我們能很容易通過(guò)檢測HRESULT值來(lái)自動(dòng)化一個(gè)新的測試，這個(gè)測試可以由一個(gè)用戶(hù)在合理的時(shí)間內執行完。這部分的代碼基本不會(huì )被修改，并且沒(méi)有什么依賴(lài)性。但是這個(gè)主管堅持要運行這個(gè)用戶(hù)界面測試，盡管圖像比較是眾所周知存在問(wèn)題的。（許多圖像比較方法都出了名的有問(wèn)題，產(chǎn)生很多錯誤的判斷，這并不奇怪.）
測試人員說(shuō)這位經(jīng)理認為這個(gè)自動(dòng)化用例減少測試人員手工操作的重復勞動(dòng)從而節約時(shí)間。真的么？這個(gè)測試人員需要每周花幾個(gè)小時(shí)來(lái)努力尋找出現錯誤的地方，調整自動(dòng)化測試使它在每天的版本上“正確執行”，而只是為了讓他的主管高興。所以，盡管這個(gè)功能會(huì )被上百個(gè)試用每日構建(Daily Build)的人、另外上百個(gè)公司內用到內部發(fā)行版本的人和上千個(gè)使用Beta版本的客戶(hù)所重復使用，這個(gè)主管還是認為不停的調整測試能節約一些測試人員的時(shí)間。
還有一個(gè)例子， 一個(gè)測試員詢(xún)問(wèn)如何自動(dòng)化一個(gè)測試用例來(lái)判斷PowerPoint演示中的幻燈片順序在不同的.ppt文件拷貝中是否相同。當然，這個(gè)問(wèn)題引來(lái)了一大堆的回復，比如建議他創(chuàng )建每個(gè)幻燈片的圖像庫，然后用圖像比較工具來(lái)判斷變化。我的回答有點(diǎn)不同。首先，這里有幾種方法來(lái)編程檢測文件的變化，一旦檢測到二進(jìn)制屬性的變化，我們可以簡(jiǎn)單地在幻燈片排序視圖中打開(kāi)PowerPoint演示文件，用幾秒鐘（取決于幻燈片的數目）直接比較它和原文件的幻燈片順序。這是比自動(dòng)化測試慢一點(diǎn)，但是我真的懷疑它會(huì )更有效率，尤其是長(cháng)期來(lái)看。我也很好奇在他的項目（不是PowerPoint本身）中這個(gè)“測試”究竟實(shí)際會(huì )被執行幾次，是否值得開(kāi)發(fā)一個(gè)這樣的測試所花的小時(shí)數/天數和后期維護的噩夢(mèng)。
這只是濫用UI自動(dòng)化測試的兩個(gè)例子，它們顯示了下面幾個(gè)重要的觀(guān)點(diǎn):
- 并不是所有的UI自動(dòng)化測試都節省時(shí)間!
那些因為常常給出錯誤結果而需要不斷調整的UI自動(dòng)化測試，浪費了一個(gè)測試人員大量的時(shí)間在維護上。
- 有時(shí)候人工測試是比計算機算法更有效率的辦法!
確實(shí)，任何計算機能做的事情都能在某種程度上被自動(dòng)化，但是有些測試用人工來(lái)做會(huì )更加明智和簡(jiǎn)單。
- 別依賴(lài)自動(dòng)化來(lái)模擬你的用戶(hù)！
測試自動(dòng)化并不能有效的模擬一個(gè)用戶(hù)。確實(shí)，在我們內部的測試框架中有很多種方法來(lái)減慢模擬的鍵盤(pán)操作（真正的鍵并沒(méi)有在鍵盤(pán)上被按下），或者模擬在一個(gè)控件或鼠標上的多次重復點(diǎn)擊，和其它試圖模擬不同用戶(hù)行為的技巧。然而，自動(dòng)化測試在檢測行為問(wèn)題上通常很弱， 例如可用性、易用性或用戶(hù)實(shí)用性的測試。在這種情況下，應該依賴(lài)于內部或外部的用戶(hù)。他們是真正測試和體驗你的產(chǎn)品的人。
- 深入內部！
我覺(jué)得很多測試人員過(guò)多的依賴(lài)于UI自動(dòng)化是因為他們覺(jué)得這樣能夠模擬用戶(hù)行為（雖然大部分的事情，例如填充一個(gè)文本框，是通過(guò)Windows API來(lái)模擬的），或者可能因為他們不知道怎么深入研究UI背后的實(shí)現。不管是哪種情況，考慮一下這個(gè)測試的確切的目的是什么。如果檢查一個(gè)返回值或者調用一個(gè)API來(lái)改變設置會(huì )更簡(jiǎn)單，那么就深入下去，停止在UI上浪費時(shí)間了。（這只會(huì )是把測試復雜化，浪費寶貴的機器運轉，減少了多種版本間的重用，還常常導致長(cháng)期的維護代價(jià)）。
- 不斷修改代碼會(huì )導致測試不穩定！
我看到很多次測試人員設計了一個(gè)UI自動(dòng)化測試，然后這里改一點(diǎn)，那里改一點(diǎn)來(lái)使它運行。這些修改常常導致測試不容易暴漏問(wèn)題，甚至有可能隱藏其它問(wèn)題。有些修改也和同步問(wèn)題相關(guān)（同步自動(dòng)化測試和被測的系統），人為地減慢了自動(dòng)化過(guò)程（常常通過(guò)停止或‘睡眠’測試程序一段時(shí)間來(lái)實(shí)現）。另外一些修改可能硬編碼了一些參數，導致測試在另外一個(gè)環(huán)境下失敗或者不可移植。
- 停止嘗試自動(dòng)化所有測試！
就象我前面說(shuō)的，我們能夠自動(dòng)化一些東西并不意味著(zhù)我們就應該自動(dòng)化所有的東西！我們需要理做出理智的決定：哪些測試要被自動(dòng)化，并且哪種方法是最好的自動(dòng)化方式。
測試者很容易陷入到UI自動(dòng)化測試中。我寫(xiě)自動(dòng)化測試用例只是為了解放我的時(shí)間，從而可以有更多時(shí)間來(lái)設計和開(kāi)發(fā)更多更好的測試，一旦實(shí)現了自動(dòng)化，我就不需要坐在電腦前執行多余重復的測試，不需要不停地修改代碼來(lái)使它運行。稱(chēng)職的測試人員應該理解自動(dòng)化測試技術(shù)的適用范圍，從而得心應手的使用這項技術(shù)。但無(wú)論它有多棒，這僅僅是眾多測試技術(shù)之一。最能幫助進(jìn)行有效測試的依舊是開(kāi)動(dòng)大腦！
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
