關鍵字驅動的過去和未來

　　鑒于這個系列寫的內容是希望幫助“大多數2-3年工作經驗、急切盼望提升自身能力的 tester找到捅破‘測試自動化’窗戶紙的辦法”，所以木有高深內容，高手們請直接飄過，呵呵。

　　1.“關鍵字驅動”的由來

　　說到“關鍵字驅動”和“測試自動化”，就不能不提到 Mosley Daniel 的《軟件測試自動化》一書，這本書03年引入國內，04年市面上開始有賣，書中有兩個相信能吸引到很多 tester 的話題：

　　(1)腳本應該錄制還是編寫?——想知道答案的自己下載電子書看吧：)

　　(2)“數據驅動”和“關鍵字驅動”。

　　彼時的我，剛剛經歷了一次不成功的自動化實踐，雖然 Rational Robot 提供了類似UI庫管理，數據池管理之類的強大功能，但是痛苦依然。對測試自動化理解的不夠深入，不知道該如何應對RAD模式下UI和業務快速調整，以及對 C/S下非標準控件的識別等問題，導致了無法快速維護腳本、replay 次數不夠，回放通過率不夠，最后的結果是ROI無法滿足要求，自動化項目宣告結束。

　　帶著很多疑問的我原本想從那本書中找到些答案，遺憾的是那時功力實在太差，居然沒有看懂，唯一留下印象的就是作者在80年代就開始探索自動化回歸的技術，并且在90年代已經嘗試了“數據驅動”和“關鍵字驅動”的技術，想來當時 Robot framework 之類的都還沒有出現，所以我相信“關鍵字驅動”的技術源自這書的作者和他的朋友們。

　　2. 從“數據驅動”到“關鍵字驅動”

　　所謂的數據驅動，原本沒有什么特別的，無非就是把hard code 在腳本中的數據參數化出來，之所以算是Robot、WinRunner甚至QTP時代測試工具的賣點，其實主要是因為那個年代大多數system tester 不懂開發，總需要有個功能來幫助自己完成參數抽取、數據維護、自動替換之類的功能。

　　而關鍵字驅動，則進一步在技術上把 tester 分成了完全不懂技術的和懂點技術的，前者只能根據格式填寫一下 excel 表格，后者對工具/框架內置的所謂關鍵字庫進行增補或二次開發。

　　找些例子來看看吧。

　　(1)簡單的數據驅動。

　　如下面代碼，定義了一個class并實例化了幾個對象，用來存放不同的用戶登錄信息;而在負責完成登錄操作的 do_login_as() 方法中，把 send_keys 原來向表單中填充的數據參數化，根據每次調用 do_login_as() 方法時傳入的不同對象來實現用不同帳號登錄的效果——雖然我對以“登錄”為樣例介紹自動化測試腳本深惡痛絕，不過這里為了表述簡單，還是用了。(下面的代碼只是一個示例，不是直接用來運行的。)

　　其實數據驅動本來也沒有什么技術含量，寫過代碼的誰還不知道什么是變量啊?不過在早期的商業工具中，的確把這個作為了一個賣點，畢竟10年前的測試工具設計思路也與現在不同。早期的工具始終都假設”系統測試工程師不懂開發“，所以他們在開發測試腳本時需要借助類似錄制回放+編輯調試的模式;另外，對于數據驅動所需要的測試數據，最好也是通過工具內置的data pool 管理，通過表格編輯，甚至讀取 csv、excel 文件之類的。如果我們依照這個思路去實現自己的測試框架，那肯定是商業工具很有價值，畢竟自己實現data pool管理、外部數據文件讀取之類的功能，代碼量也不小，要處理好那些數據格式和內容校驗之類的，貌似跟我們所需要完成的自動化也沒啥太大關系。

　　可問題在于，為什么一定要有data pool+外部數據文件來實現”數據驅動“呢?

　　(2)傳統的“關鍵字驅動”

　　還是先用個例子來看看傳統的“關鍵字驅動”長什么樣子。

　　上面是一個 Selenium 0.x 時代Core模式下(什么是selenium的core模式和RC模式請自行google，不過話說現在已經全民webdriver時代了，不知道也就不知道吧)的例子(QTP的實現效果也類似)，簡單說就是第一行是 test case name，下面3列開始進入正題，第一列表示你想干啥，第二列是被操作對象是誰，第三列是你對它干了啥。06年剛剛開始嘗試web測試自動化的時候，我們一度認為這是一個比之前的測試工具要智能的多的東東，不過在嘗試了很長一段時間之后，還是發現了這種模式下的問題，又逐漸轉回了編寫腳本的方式。

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