關鍵字驅動的過去和未來(2)

　　對比上面的第一個腳本，可以看出關鍵字驅動進一步屏蔽了底層的實現細節，例如，你只需要clickAndWait那個btnG，而不需要知道btnG到底是個啥，以及它在哪里，你只需要填寫表格。等你把一個個 test case 變成了一個個表格，把一個個step變成了一行行表格中的內容，基本上你的自動化測試就搞完了。——真的是這樣嗎?

　　現在回想一下，關鍵字驅動之所以會出現，可能初衷還是為了降低自動化實施的門檻——因為tester都不太懂開發嘛，所以開發能力強的人把框架實現出來，原來那些只會寫excel的 system tester填寫表格就可以了。也許現在還有很多公司會傾向于這個方案，美其名曰“分工協作，人盡其能”。不過關于這個問題，暫時先不展開討論，先看看這種傳統的關鍵字驅動模式會遇到什么問題。

　　首先，頁面對象的識別問題。這是任何一種基于UI實現回歸測試自動化的框架都會遇到的問題。在C/S時代，就已經出現了很多定制化UI組件難以被工具識別的問題，可好歹總逃不出windows的手心。到了web時代，前端實現技術百花齊放，而前端代碼的編寫也更是一個開發人員一個習慣，如果缺少統一的編碼規范，對于那些沒有使用id或者name之類屬性的頁面對象，傳統的關鍵字驅動框架就沒有例子中看起來那么美好了。當然，有人說xpath可以解決一切問題。嗯，xpath是很強，但是一個沒有開發經驗的tester 想掌握它其實也不會比學會一點基本的編碼技術容易多少;另外，xpath并不是萬能的，在實際中還是有些它處理不了的情況。下面再給個例子(如果 tester看不懂這個例子，估計學會xpath也有點困難)：

　　上面這個圖中是一個表格，id列(第一列)和需求名稱列(第二列)下顯示的內容，都是可以點擊的超鏈接，最后的“操作”一列中的一個個小圖標也各自指向一個鏈接(分別是“變更”、“評審”、“編輯”、“建用例”)，通過查看第一行記錄的html代碼，我們發現：

　　1.假如想要編輯一條記錄，沒有可利用的id或name屬性，唯一可用的是link;

　　2.link指向的url中包含了這條記錄的ID信息，因為這里是第一行記錄的代碼，所以都是341，而后面的每一行記錄的代碼都是各自的ID。

　　上面這個例子是企業應用中常見的場景，關鍵問題在于數據記錄ID 是一個不可控因素，而數據記錄的title/name之類的是可控的，為了提高test case的可維護性和相互獨立，我們肯定不會依賴ID去模擬頁面操作，而是根據title/name之類取回ID信息，再拼裝回所需要操作的鏈接。這種情況下，xpath恐怕也搞不定了。(如果這里再涉及到要在幾個iframe之間跳來跳去，恐怕寫腳本的人就要崩潰了。)

　　當然，有人會說關鍵字驅動框架一般也可以定義function來實現類似的操作啊。唉，都到了編寫自定義function的地步了，干嘛還非要糾纏在關鍵字驅動上啊。

　　第二，腳本的可維護性問題。如一開始的例子，傳統的關鍵字驅動是一種純“面向過程”的腳本組織方式(就像C/pascal)，表格中填寫的是一個操作序列。如果多個test case 都涉及到某個頁面，基本上就會在多個case中都看到類似 clickAndWait btnG這樣的內容，而一旦頁面中btnG改名叫buttonG了，或者 clickAndWait btnG與verifyTextPresent 之間增加了一個 clickAndWait XXX的step，那基本上每個case都需要修改。

　　嗯，問題來了，當你的腳本數量從1增長到100、1000的時候，當UI的變動無法避免的時候，當你發現100個case回歸執行只有90個通過，執行失敗的10個需要逐個檢查錯誤日志和查看截圖，再挨個修改的時候，當下次回歸測試又發生這種問題的時候——基本上這就是一個死循環了。如果解決不了根本問題，前期投資可以舍棄了，別糾結了。

　　當然，有人說關鍵字驅動已經進化了，可以跟最新的webdriver結合起來，提升關鍵字的封裝層次，解決這個可維護性的問題。好吧，這個問題等下再詳細說。

　　第三，腳本的可擴展性問題。在大規模實施自動化的過程中，腳本一般都會簡單的是一行行的browser.find_elmenet_by_id(xxxx).click() 這樣的模式，根據各種條件來判斷執行的分支，進行各種異常處理，第三方類庫/包的調用，主機環境的訪問，諸如此類，這些對于所有的3GL/4GL來說其實都很容易實現，但對于傳統的關鍵字驅動來說，嗯，也可以實現，大概是下面這個樣子【摘自robot framework(此robot非rational robot)】：

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