何時應進行自動化測試?
發表于:2009-06-18來源:作者:點擊數:
標簽:自動化
假設你的工作是要寫一組測試來檢測用戶是否輸入了正確的電話號碼,那么你就需要檢查是否是輸入了有效地阿拉伯數字而非其它字符等等。如果你清楚其中的代碼(據我了解很少人會這樣)你可以設計一個規劃列表將校驗電話號碼的代碼使用高亮顯示做出標記。通常稱
假設你的工作是要寫一組測試來檢測用戶是否輸入了正確的電話號碼,那么你就需要檢查是否是輸入了有效地阿拉伯數字而非其它字符等等。如果你清楚其中的代碼(據我了解很少人會這樣)你可以設計一個規劃列表將校驗電話號碼的代碼使用高亮顯示做出標記。通常稱它為 the code under test。這部分代碼可以更加完善你的測試任務。
在大多數時候,你不可能有機會直接運用the code under test。例如:你不可能直接得到確認電話號碼的那部分代碼,因為它通常會是一個用戶的一部分屬性,就需要通過用戶接口來測試,將與其關聯的那部分代碼組織起來,使這部分轉變到內部程序的數據,并會按照常規將這部分數據表現出來。當然,你也不能直接對表現出來的數據進行檢測,因為轉變會通過其他的代碼來將其轉變成在用戶界面可見的最后的數據(就像非法的數據會轉換成錯誤信息)。我稱這些代碼為intervening code——介于測試本身和code under test之間的代碼。
Changes to the intervening code(對介入其間的代碼進行變化)
介入其間的代碼是導致測試死亡的主要因素。而且用戶圖形界面接口較上文提到的那個接口和一些硬件驅動接口相比更是這個樣子。例如:假設用戶接口要求你輸入電話號碼,但是現在變化為要求提供一個電話按鍵區的視覺表現。這時你要使用鼠標敲擊號碼模擬使用真實的電話。(這是個非常愚蠢的主意,但是這怪異的事情已經發生了。)盡管接口傳給了code under test一個正確的值,但是用戶界面的變化很可能破壞一次
自動化測試,是因為很可能使用者再沒有地方輸入電話號碼了。
就像另外的一個例子,一個輸入的錯誤用戶界面會用其它的方法來告訴用戶。它可能會刷新主窗體使其顯示紅色同時發出特殊的聲音來代替彈出的提示信息來告知你不能完成這次操作。但是,如果你的測試是通過測試是不是彈出提示信息來判定的,那么將視這種正常的運行為一個
bug。很顯然這個測試就沒有效果了。
"Off the shelf "
測試自動化工具能做避免測試死亡的有限制的工作。例如:大多數的GUI自動化
測試工具都可以忽視文本框大小、位置和顏色的改變。從而把握像上面兩段所提到的那些大的改變,但是需要事先定制。這需要在你的工程中有一些人去創建test libraries。這樣就要求你,一個
測試人員,在編寫好測試的特殊術語,盡可能多的忽略用戶接口的細節。例如,你的自動化測試可能包含這樣一行定制的信息:try 217-555-1212 try是test library程序,它的作用是將電話號碼翻譯成接口可以知道的術語。如果用戶界面接受在輸入框中輸入字符,try會在其中輸入電話號碼。如果需要通過顯示在屏幕上的特定圖形區域鍵入電話號碼時,try也會做到。
test library 可以有效地將那些不相關信息過濾掉。這樣我們就可以詳細的準確的測試那些與功能相關的數據。在輸入上,增加這些附加信息是intervening code所必須的。在輸出上,它們將intervening code中的信息全部壓縮到一個很重要的模塊中,其中的信息實際上可以當作是Code Under Test的一個延伸。這種過濾可以用左圖來描述:
多數用戶界面的變化不會需要對測試做更改,而只需要對test library做相應的修改。應為test Code要比library Code多的多,所以只修改library Code的代價會很低。
但是,盡管我們有更好的補償性的代碼也不可能將測試從所有的變化中隔離出來。它僅僅是盡可能的去預期所有的事情。所以其中有很多可能性,將來很可能出現一些問題破壞你的測試。你必須問自己這樣一個問題:
在變化中Intervening Code會把測試保護到什么程度?
你需要估計intervening Code的改變對測試造成影響的可能性。要保證用戶界面永遠的不會改變是一件不可能的事情,這就使你需要不停的改變自動化測試的腳本以保證測試可以自動的執行。(我不會相信界面凍結后永遠不會變化,除非manager答應如果以后每做一個新的修改將會給我100美元)
如果變化是可能的,你一定會被詢問對你的test Library保護你的測試不受其影響正常執行有多大的信心。如果說test Library不能保護測試,那么起碼它可以很容易的做出改動以適應變化。如果花費一個半小時的時間可以拯救300個測試,那么所做的一切是值得的。但是,小心:很多人往往低估了維護test Library的困難,特別是在變化后需要手工的對測試test Library進行反復的修改。不應該馬上就放棄,拋棄所有的測試類和test Library,從頭開始,因為很可能只需要簡單的修改就可以完成需要的測試。
如果你沒有test Library——如果你正在使用自動化GUI測試工具來捕獲和重放模式——你不要期待會有任何保護。一次對界面的修改會讓你的大部分的測試“死亡”。往往不會有足夠的時間來允許我們完成對發生變化的測試進行修改,我們不得不在少的花費和短的生命生存期之間做出選擇。
原文轉自:http://www.kjueaiud.com