敏捷自動化測試(2)——像用戶使用軟件一樣享受自動化測試(3)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　自動化測試中最關鍵的兩部分是“腳本”和“斷言”。至此，自動化測試腳本的編寫、維護以及執行已經可以跟上敏捷開發的步伐了。本系列的下一篇文章會就“如何讓斷言不再成為自動化測試的負擔”這個話題來分享一些實踐經驗，敬請關注!

原文轉自：http://www.infoq.com/cn/articles/Agile-test-automation-2