軟件測試中失控的UI自動化

第第頁軟件測試中失控的UI自動化軟件測試中失控的UI自動化

發(fā)表于：2023-05-26來源：：點擊數：標簽：自動化軟件測試失控

軟件測試中失控的UI自動化一提到自動化測試，大多數人就會以為是用硬編碼(hardcode)的事件和數據來編寫腳本，模擬用戶和軟件之間可能的交互動作，來完成一個預定義的、機器人執(zhí)行的任務?？赡芫褪且驗檫@個原因，商業(yè)分析師(BusinessAnalysts)或者黑盒

軟件測試中失控的UI自動化

一提到自動化測試，大多數人就會以為是用硬編碼(hardcode)的事件和數據來編寫腳本，模擬用戶和軟件之間可能的交互動作，來完成一個預定義的、機器人執(zhí)行的任務?？赡芫褪且驗檫@個原因，商業(yè)分析師(BusinessAnalysts)或者黑盒測試者得到了太多的工具來幫助他們錄制和回放（或者列出相關步驟的關鍵字）一些人為設想的用戶可能會做的操作步驟。確實……看著窗口開關、鼠標魔術般的在桌面上移動是很酷的一件事。但是，對于任何聰明的的人來說，這種視覺上的驚奇往往只能持續(xù)……哦……大約1.7秒……之后就變得麻木無聊了！不幸的是：自動化常常是很短命的，它需要大量的維護開銷，并且是造成那些失敗或談不上成功的自動化工程的主要原因。

總的來說我并不是很熱衷于圖形界面的自動化測試，這里有很多原因，但是最重要的原因是因為它被濫用了，有一些測試其實找一個人能夠執(zhí)行得更快更好。不過我也理解在某些場合下圖形界面自動化測試的確能夠提供它的價值。我并不反對圖形界面自動化測試，但是絕不主張只是因為能夠自動化就用自動化測試，或者只是因為我們有的那些荒誕的想法：認為所有的東西都應該自動化。

就拿有一次我和一個測試人員的談話來舉例吧。他的經理希望他去維護一個舊的測試用例，這個用例是用來檢測一個操作后箭頭的顏色是否正確。如果操作成功，箭頭的顏色是綠色，否則就是紅色?，F在，可以看出我們能很容易通過檢測HRESULT值來自動化一個新的測試，這個測試可以由一個用戶在合理的時間內執(zhí)行完。這部分的代碼基本不會被修改，并且沒有什么依賴性。但是這個主管堅持要運行這個用戶界面測試，盡管圖像比較是眾所周知存在問題的。（許多圖像比較方法都出了名的有問題，產生很多錯誤的判斷，這并不奇怪.）

測試人員說這位經理認為這個自動化用例減少測試人員手工操作的重復勞動從而節(jié)約時間。真的么？這個測試人員需要每周花幾個小時來努力尋找出現錯誤的地方，調整自動化測試使它在每天的版本上“正確執(zhí)行”，而只是為了讓他的主管高興。所以，盡管這個功能會被上百個試用每日構建(DailyBuild)的人、另外上百個公司內用到內部發(fā)行版本的人和上千個使用Beta版本的客戶所重復使用，這個主管還是認為不停的調整測試能節(jié)約一些測試人員的時間。

還有一個例子，一個測試員詢問如何自動化一個測試用例來判斷PowerPoint演示中的幻燈片順序在不同的.ppt文件拷貝中是否相同。當然，這個問題引來了一大堆的回復，比如建議他創(chuàng)建每個幻燈片的圖像庫，然后用圖像比較工具來判斷變化。我的回答有點不同。首先，這里有幾種方法來編程檢測文件的變化，一旦檢測到二進制屬性的變化，我們可以簡單地在幻燈片排序視圖中打開PowerPoint演示文件，用幾秒鐘（取決于幻燈片的數目）直接比較它和原文件的幻燈片順序。這是比自動化測試慢一點，但是我真的懷疑它會更有效率，尤其是長期來看。我也很好奇在他的項目（不是PowerPoint本身）中這個“測試”究竟實際會被執(zhí)行幾次，是否值得開發(fā)一個這樣的測試所花的小時數/天數和后期維護的噩夢。

這只是濫用UI自動化測試的兩個例子，它們顯示了下面幾個重要的觀點:

并不是所有的UI自動化測試都節(jié)省時間!那些因為常常給出錯誤結果而需要不斷調整的UI自動化測試，浪費了一個測試人員大量的時間在維護上。

有時候人工測試是比計算機算法更有效率的辦法!確實，任何計算機能做的事情都能在某種程度上被自動化，但是有些測試用人工來做會更加明智和簡單。

別依賴自動化來模擬你的用戶！測試自動化并不能有效的模擬一個用戶。確實，在我們內部的測試框架中有很多種方法來減慢模擬的鍵盤操作（真正的鍵并沒有在鍵盤上被按下），或者模擬在一個控件或鼠標上的多次重復點擊，和其它試圖模擬不同用戶行為的技巧。然而，自動化測試在檢測行為問題上通常很弱，例如可用性、易用性或用戶實用性的測試。在這種情況下，應該依賴于內部或外部的用戶。他們是真正測試和體驗你的產品的人。

深入內部！我覺得很多測試人員過多的依賴于UI自動化是因為他們覺得這樣能夠模擬用戶行為（雖然大部分的事情，例如填充一個文本框，是通過WindowsAPI來模擬的），或者可能因為他們不知道怎么深入研究UI背后的實現。不管是哪種情況，考慮一下這個測試的確切的目的是什么。如果檢查一個返回值或者調用一個API來改變設置會更簡單，那么就深入下去，停止在UI上浪費時間了。（這只會是把測試復雜化，浪費寶貴的機器運轉，減少了多種版本間的重用，還常常導致長期的維護代價）。

不斷修改代碼會導致測試不穩(wěn)定！我看到很多次測試人員設計了一個UI自動化測試，然后這里改一點，那里改一點來使它運行。這些修改常常導致測試不容易暴漏問題，甚至有可能隱藏其它問題。有些修改也和同步問題相關（同步自動化測試和被測的系統(tǒng)），人為地減慢了自動化過程（常常通過停止或‘睡眠’測試程序一段時間來實現）。另外一些修改可能硬編碼了一些參數，導致測試在另外一個環(huán)境下失敗或者不可移植。

停止嘗試自動化所有測試！就象我前面說的，我們能夠自動化一些東西并不意味著我們就應該自動化所有的東西！我們需要理做出理智的決定：哪些測試要被自動化，并且哪種方法是最好的自動化方式。

測試者很容易陷入到UI自動化測試中。我寫自動化測試用例只是為了解放我的時間，從而可以有更多時間來設計和開發(fā)更多更好的測試，一旦實現