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

　　下面是一個在 keyword 表格里面實現的 FOR 循環：

　　這是獲取時間，當然也是寫在表格里面的：

　　import 外部的庫:

　　讀取外部文件:

　　正則表達式:

　　重復執行5次 goto pre page 操作:

　　執行一個 keyword 然后期待能捕獲一個異常:

　　有人可能會說“你看，關鍵字驅動框架也可以擴展的很強大啊!”。是，在programming 的世界中，沒有什么不能做的，不過都弄到這個份兒上了，學習這一套東西跟學習一個標準的編程語言還有什么差別嗎?先不說這樣的框架越擴展越難維護，可靠性也就越差，單單這些關鍵字的用途被局限在自己的框架中，你所積累的知識和經驗無法重用到其他測試代碼的編寫中這一個理由，就應該徹底放棄這種方式了。

　　如果要說的直白一些，傳統的關鍵字驅動框架的時代在前幾年就已經開始遠去(是had been，不是have been)，我們感謝上一代tester的努力探索和實踐，但最終歷史證明這是一個不算成功的嘗試，一個框架如果不具備開放性，一切都自給自足，那么有一天這也會成為限制自己發展的最大原因。

　　(3)穿馬甲的“關鍵字驅動”

　　時代在進步，關鍵字驅動也在進步，這個領域中的代表 robot framework(此robot非rational robot) 也在進步，于是，test case 變成了下面這個樣子。

　　依舊不變的是“表格”，改變的是填寫方式——其實這背后的，是關鍵字定義終于被開放出來，tester可以自己定義keyword然后“注冊”到框架中，而那些依然沒有學會基本編程技能的tester，繼續用這些keyword重復上個時代的事情——填寫表格。

　　其實相對于最初對關鍵字驅動的定義，這個真的已經不是關鍵字驅動了，如果非說它是，那么只能說上個時代的關鍵字驅動中，test case 表格的每行都是一個頁面操作，而“新的”關鍵字驅動中，test case 的每行都已經是一個完整的業務操作，以上面的“Create Valid User” step 為例，robot framework希望的實現方式是tester通過python等4GL實現一個同名的function，這個function接受兩個參數，分別是 “fred”和“P4ssw0rd”，再把這個function注冊到robot framework中。而“Create Valid User”內部的實現，可以類似于一開始“數據驅動”中的那個例子，充分利用4GL的特性和已有的其他第三方組件(例如webdriver)，來實現各種復雜的基于UI的操作，這樣也就解決了剛剛“傳統的關鍵字驅動”所遇到的問題。

　　最后，當完成了這個function的開發并在robot framework中注冊后，做手工測試的system tester就可以很容易的把原本excel中的一個個case轉變為自動化腳本了。

　　其實這個思路有它的優點，例如：通過分工協作降低實施門檻，可以一開始就編寫符合robot所需格式的manual test case，等到keyword開完全了以后這些case就可以直接導入執行了;不再自給自足，而是保持一定的開放，并利用其他第三方組件的特性。這樣很大程度上解決了自動化項目實施遇到的人員能力問題和可維護性、可擴展性的問題。

　　另外，新的關鍵字驅動還有一個更加先進的“近親”BDD作為參照，很容易把它的一些實踐也一起融合進來。

　　一切看起來都很美好，不過問題也還是有。

　　1.表格化的test case畢竟不同于編寫代碼，調試就變成了一個問題，如果寫錯了關鍵字的一個字母，要及時發現并定位到問題就不那么容易。當然，可以再開發一個web平臺，讓編寫case的人僅能從一個list中選擇已經定義好的keyword，不過這個成本恐怕就不是一般研發團隊能承受的了。

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