在本系列的第一篇文章“我們的測試為什么不夠敏捷”中,根據實例總結出敏捷自動化的兩大阻礙:“腳本維護困難”、“斷言條件繁瑣”。本文針對如何降低腳本維護難度分享一些實踐經驗。
近幾年,Web技術發展勢頭迅猛,瀏覽器市場群雄爭霸、各種UI組件庫也如雨后春筍?,F在互聯網上已經很少有僅支持一種瀏覽器,并且不基于任何可復用的UI組件庫進行開發的應用了。開發人員基于各種優秀的UI組件庫(如,JQuery、Dojo、ExtJS)可以很容易的開發出功能強大、展現絢麗、兼容各種瀏覽器的頁面(如下圖):
UI組件庫的廣泛采用在提高開發效率的同時,也極大的提升了用戶體驗?;赨I組件庫之所以能快速開發出功能強大的頁面,是因為UI組件庫可以自動生成海量、結構類似的HTML源碼(如下圖):
開發人員是幸福的,因為這一切對于他來說完全透明。于是只剩下自動化測試人員獨自面對這樣“恐怖”的頁面源碼。
相關廠商內容
一路走來技術人的創業故事
未來物聯網中智能硬件的角色
人工智能的技術版圖
GMTC全球移動技術大會,6折優惠,最后一周!
不要寫死!天貓App的動態化配置中心實踐
相關贊助商
ArchSummit深圳2016將于7月15-16在華僑城洲際大酒店舉行,現價8折搶購,團購報名更多優惠!
如前文“我們的測試為什么不夠敏捷”中所言,業界常見測試工具的腳本本質上還是針對頁面源碼的,因此原本就舉步維艱的自動化測試在開發使用UI組件庫之后變得雪上加霜:
頁面DOM結構非常復雜
導致所錄制/編寫腳本的復雜度變的更大、可讀性變得更差。
UI框架的升級很可能會導致DOM結構的變化
因此即使開發人員沒對代碼做任何改動,測試腳本也會因為UI框架的升級變得無法回放。
控件ID是自動生成的,甚至在每次刷新頁面后都會變化
大部分自動化測試工具在“錄制”腳本時,都會優先使用ID定位策略,自動生成的ID會導致這種關鍵的控件定位策略變得無效。
UI框架在各種瀏覽器下自動生成頁面源碼可能不完全相同
為了在不同瀏覽器下“看起來一樣”,實際的DOM結構有時也可能是不同的,因此所錄制腳本的瀏覽器兼容性會比較差。
技術的發展是為了讓生活變得越來越輕松。從用戶的角度來看確實如此:Web應用的功能覆蓋范圍越來越廣、操作越來越方便、界面越來越美觀。
為什么自動化測試人員沒有感覺工作變得輕松呢?
要回答這個問題,首先要分析“用戶使用軟件”與“自動化測試軟件”之間的一些重要差異:
用戶使用軟件時只關注界面上能“看”到的,而不用總是“查看頁面源碼”;
用戶會更關注整體業務的正確性、穩定性,而不僅僅是每個孤立頁面功能的正確性;
用戶對頁面樣式、響應時間、瀏覽器兼容性要求越來越高; 如果我們能像用戶使用軟件一樣進行自動化測試,測試就會變得更敏捷:
根據界面快速編寫測試腳本:敏捷應對需求的變化;
降低對技術實現(UI框架、頁面樣式/布局)的依賴:敏捷應對設計/開發的變化;
測試腳本可以穩定支持各種瀏覽器:敏捷應對環境的變化;
(一)根據界面快速編寫測試腳本的實現思路
還是以前文“我們的測試為什么不夠敏捷”中用到的“用戶增加”界面為例:
如果你是作為用戶在使用上述功能時,心里一定也會默念下面內容吧:
原文轉自:http://www.infoq.com/cn/articles/Agile-test-automation-2