敏捷自動化測試(6)

　　3、采用統一的UI框架開發復雜控件

　　對于復雜控件，比如Tree、Grid，如果不基于統一的UI框架實現，開發、測試工作量都會很大。

　　4、對于需要設置ID的控件，一定要設置唯一、并且有業務意義的ID

　　當然對于一般不需要設置ID的控件(如，div)或者控件ID由UI框架自動生成的情況除外。

　　5、對于Form中最常見的label+input組合，盡量讓label和input有邏輯對應關系

　　推薦為label設置for屬性，屬性值等于input的id，這樣對最終用戶也比較友好：雙擊label的時候，鼠標焦點能定位到對應的input中。

　　6、頁面設計時考慮用戶體驗，往往用戶使用方便的時候，自動化測試也會方便

　　比如，一個頁面上不要有多個同名的按鈕、通過點擊上下微調按鈕(箭頭)改變輸入域值的控件也支持直接輸入值、日期選擇控件支持用戶直接輸入、下拉列表控件支持輸入過濾，等等

　　對以上幾點最佳實踐有如下補充說明：

　　1、這些最佳實踐不僅能提高Web UI的可測試性，也非常有助于提升用戶體驗;

　　2、這些最佳實踐如果能滿足更好，即使不能全部滿足，也可以開展自動化測試;

　　按照本文給出的方案，前文“我們的測試為什么不夠敏捷”中用到的“用戶管理(增加、刪除)”功能的自動化測試腳本就可以改造為如下樣式(示意代碼)：

<event id="[button]新增" name="click"/>
<event id="[input]帳號" name="setValue" value="${account}"/>
<event id="[input]密碼" name="setValue" value="1"/>
<event id="[input]姓名" name="setValue" value="${accountName}"/>
<event id="[input]性別" name="select" value="女"/>
<event id="[input]生日" name="setDate" value="1980-01-01"/>
<event id="[input ]國籍" name="select" value="中國"/>
<event id="[button]保存" name="click"/>
<event id="[gridRow]${account}" name="assertExist"/>
<event id="[gridRow]${account}" name="check"/>
<event id="[button]刪除" name="click"/>
<event id="[ gridRow]${ account }" name="assertNotExist"/>

　　以上測試腳本完全基于界面上“可見”的內容進行編寫，大家應該不需要看下面的解讀，也能明白腳本的意思：

　　1)第1、8、11行表示點擊“新增”、“保存”、“刪除”按鈕;

　　2)第2~7行表示為輸入域賦值，賦值方式有輸入文本、輸入日期、選擇下拉選項;

　　3)第10行表示選中表格中的指定行，即，選中指定行前面的Radio按鈕;

　　4)第9、12行表示斷言表格中指定的行“存在”或“不存在”;

　　5)${ account }表示使用外部的變量account;

　　讓斷言不再成為自動化測試的負擔

　　在本系列的第一篇文章“我們的測試為什么不夠敏捷”中，根據實例總結出敏捷自動化測試的兩大阻礙：“腳本維護困難”、“斷言條件繁瑣”。本文針對在不失自動化測試有效性的前提下如何降低斷言成本來分享一些實踐經驗。

　　目前業界常見的自動化測試工具在斷言方面大多都是采用“指哪兒打哪兒”的細粒度模式，即，在自動化測試過程中只能對設置為斷言條件的字段(頁面元素)進行斷言。而且這些測試工具即使提供錄制腳本的功能，但對于斷言往往還需要測試人員手工補充插入。

　　除了補充、維護斷言條件的工作量大之外，這種斷言模式還存在一些明顯的不足，下面結合一個實際的例子(如下圖)進行分析：

　　無法感知未設為斷言對象的字段上發生的錯誤

　　以上圖為例，如果在“增加用戶”的測試腳本之后只對列表中的“用戶姓名是否存在” 進行斷言，那么就可能遺漏“入職日期沒有提交成功”的錯誤。而且由于頁面的信息量往往很大，我們是不可能對所有字段都設置為斷言條件的。

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