敏捷自動化測試(4)

　　想要有效的改善這些問題，就必須讓自動化測試變得“敏捷”起來!

　　像用戶使用軟件一樣享受自動化測試

　　近幾年，Web技術發展勢頭迅猛，瀏覽器市場群雄爭霸、各種UI 組件庫也如雨后春筍?，F在互聯網上已經很少有僅支持一種瀏覽器，并且不基于任何可復用的UI組件庫進行開發的應用了。開發人員基于各種優秀的UI組件庫(如，JQuery、Dojo、ExtJS)可以很容易的開發出功能強大、展現絢麗、兼容各種瀏覽器的頁面(如下圖)：

　　UI組件庫的廣泛采用在提高開發效率的同時，也極大的提升了用戶體驗?；赨I組件庫之所以能快速開發出功能強大的頁面，是因為UI組件庫可以自動生成海量、結構類似的HTML源碼(如下圖)：

　　開發人員是幸福的，因為這一切對于他來說完全透明。于是只剩下自動化測試人員獨自面對這樣“恐怖”的頁面源碼。

　　如前文“我們的測試為什么不夠敏捷”中所言，業界常見測試工具的腳本本質上還是針對頁面源碼的，因此原本就舉步維艱的自動化測試在開發使用UI組件庫之后變得雪上加霜：

　　1、頁面DOM結構非常復雜

　　導致所錄制/編寫腳本的復雜度變的更大、可讀性變得更差。

　　2、UI框架的升級很可能會導致DOM結構的變化

　　因此即使開發人員沒對代碼做任何改動，測試腳本也會因為UI框架的升級變得無法回放。

　　3、控件ID是自動生成的，甚至在每次刷新頁面后都會變化

　　大部分自動化測試工具在“錄制”腳本時，都會優先使用ID定位策略，自動生成的ID會導致這種關鍵的控件定位策略變得無效。

　　4、UI框架在各種瀏覽器下自動生成頁面源碼可能不完全相同

　　為了在不同瀏覽器下“看起來一樣”，實際的DOM結構有時也可能是不同的，因此所錄制腳本的瀏覽器兼容性會比較差。

　　技術的發展是為了讓生活變得越來越輕松。從用戶的角度來看確實如此：Web應用的功能覆蓋范圍越來越廣、操作越來越方便、界面越來越美觀。

　　為什么自動化測試人員沒有感覺工作變得輕松呢?

　　要回答這個問題，首先要分析“用戶使用軟件”與“自動化測試軟件”之間的一些重要差異：

　　1)用戶使用軟件時只關注界面上能“看”到的，而不用總是“查看頁面源碼”;

　　2)用戶會更關注整體業務的正確性、穩定性，而不僅僅是每個孤立頁面功能的正確性;

　　3)用戶對頁面樣式、響應時間、瀏覽器兼容性要求越來越高; 如果我們能像用戶使用軟件一樣進行自動化測試，測試就會變得更敏捷：

　　4)根據界面快速編寫測試腳本：敏捷應對需求的變化;

　　5)降低對技術實現(UI框架、頁面樣式/布局)的依賴：敏捷應對設計/開發的變化;

　　6)測試腳本可以穩定支持各種瀏覽器：敏捷應對環境的變化;

　　(一)根據界面快速編寫測試腳本的實現思路

　　還是以前文“我們的測試為什么不夠敏捷”中用到的“用戶增加”界面為例:

　　如果你是作為用戶在使用上述功能時，心里一定也會默念下面內容吧：

　　“賬號”輸入***、“密碼”輸入***、“姓名”輸入***、“性別”選擇***、“生日”輸入***、“國籍”選擇***，點擊“保存”按鈕。

　　這就可以理解為“根據界面編寫的測試腳本”。

　　我們在使用Web應用時，心里常常默念的還包括：“展開/收攏/選中”樹(Tree)的某個節點、數據表格(Grid)的下一頁/上一頁、選中數據表格(Grid)的某一行、點擊/關閉某個Tab頁，等等。

　　很多人在與筆者交流的過程中都會問“為什么還要手工編寫腳本，怎么不提供腳本錄制工具呢?”

　　因此在這里想澄清一下大家對“編寫”腳本的誤解，與傳統自動化測試工具相比，“此腳本”非“彼腳本”。

　　傳統的測試腳本是給特定測試工具執行時使用的，對人類而言可讀性極差，更別談手工編寫了，因此“錄制/回放”工具往往都是必備組件。即便如此，此類“錄制/回放”工具的實際使用效果，也是不盡如人意的。

原文轉自：http://www.uml.org.cn/Test/201307154.asp