Selenium Web Driver自動化測試(java版)系列下半部分(37) - 關鍵字驅動自動化測試框架(2)-測試過程...

上篇我們開始用關鍵字驅動修改框架，定位了專案目錄，還修改了測試檔案，這篇我們繼續修改測試過程。和資料驅動框架版本一樣，測試過程的控制器還是TestRunner.java這個檔案，而且也分測試準備、測試中、測試收尾，相似度可以說是90%了。但鑑於關鍵字驅動讀取檔案原理的不一樣，所以唯一一點我們需要改的地方就是就是測試中這部分：

先回憶一下關鍵字驅動的特點：在測試檔案中按順序寫測試步驟，然後在程式中羅列操作，掃描檔案時根據步驟判斷該執行哪個操作：

但是，上篇文章我們已經修改了測試檔案，裡面包含了login和logout兩個generic functions，我們上一篇介紹關鍵字驅動時的條件判斷中並沒有包括generic functions，按理說我們應該把它們加進去。不過等等，現在我們只有兩個generic functions，但隨著test case越來越多未來還可能有很多很多個，問題是你真的要一個一個的加到條件判斷裡嗎？這樣的話會不會使得判斷語句變得很長很長很長？

所以，這麼做不太聰明，還得想別的辦法。既然這些新的都是generic functions，那我就把它們全標成一類操作，如果我把上圖中的switch-case語句變成if-else，那我是不是隻需要多加一個else語句就行了？指的是隻要掃描到檔案中的generic function，就執行else：

再結合我們上篇修改的檔案，是不是明白了點什麼？以登入成功的test case為例，執行過程大體畫張圖就是這樣：

圖畫得有點亂，別嚇著。其實也沒那麼亂，帶大家梳理一遍就清楚了。左邊部分是條件語句，右邊是涉及到的兩個測試檔案 - tcLogin1.xlsx和login.xlsx。執行過程如下：

第1步：程式開始執行時先掃描tcLogin1.xlsx，遇到的第一個關鍵是login，隨即執行最後一個else語句；
第2步：通過else裡的種種操作使得程式開始掃描login.xlsx，執行從Open Browser到Click Element之間的步驟；
第3步：返回tcLogin1.xlsx；
第4步：繼續執行下一個關鍵字Verify Element Text；
第5步：執行關鍵字logout，再一次執行了最後一個else語句；
第6步：再一次通過else裡的種種操作使得程式開始掃描login.xlsx，執行Click Element;
第7步：返回tcLogin1.xlsx；
第8步：執行最後一個關鍵字Verify Element Display，結束。

這樣，雖然看起來是掃描了一個測試檔案tcLogin1.xlsx，但其實是一環套一環，每次執行完generic function後都要回到原來的地方繼續。明白了這些，我們開始寫掃描檔案中的測試步驟，這步是由Test.java完成。我給這個方法起個名叫stepThrough()，把測試檔案作為引數傳進去，然後把除最後一個else之外的條件語句都寫好：

理解起來沒什麼難度，基本上就是關鍵字驅動這篇例子的翻版，我們先留著else裡面不寫。除此之外，因為測試資料有時不止一組，所以在掃描檔案的測試步驟前還需先獲取資料集，這步也放在Test.java裡，方法叫getTestData()：

有了資料來源和測試步驟掃描，測試過程才完整。為了看起來方便我們再寫一個叫executeTest()的方法把它們都放進來：

當然，page objects也不能落下。先不用管executeTest()裡面接了四個引數，分別是driver，檔名，檔案的sheet，以及module，也就是模組。前面三個好理解，為什麼最後還要有個模組呢？先跳過這個問題，一會兒就明白了。很明顯，executeTest()就是我們的測試過程，我們只需要在TestRunner.java中呼叫它就可以了：

現在還不能執行，別忘了，Test.java裡邊還有個else沒寫呢，應該寫什麼呢？再看一遍上面的執行流程，剛才說了，這個過程看起來是掃描了一個測試檔案tcLogin1.xlsx，但其實是一環套一環，每次執行完generic function後都要回到原來的地方繼續。你體會一下，不管是掃描一個測試檔案，還是它的generic functions，執行方式感覺都是一樣的，逐步遞進，按步迴歸。這點像什麼？是不是像我們之前介紹java時說的遞迴方法？所以，我們只需要在else語句中重複這個過程即可：

裡面我設定了一個module引數，指的是訪問哪個包含generic functions的檔案。現在明白當初為什麼要在測試檔案上加一列module了吧？就是要作為引數傳進這裡邊的。程式本身不難理解，把引數想成實際值帶入一下就好了。

這就是把資料驅動框架改成關鍵字驅動框架的一個例子。還是那句話，框架的設計方式成千上萬，你也可以設計自己喜歡的，只要解決問題就可以了。我個人感覺關鍵字驅動設計起來還是挺費事的，我們們現在程式簡單，只測了登入功能，但隨著其它功能的引入，很可能你會發現原來的測試檔案需要新增其它資訊，一個module已經不好使了。而且越來越複雜，一個人寫起來很困難。所以，市面上有很多現成的以關鍵字為驅動的框架我們可以直接拿來用，不少還是開源的，你一看就知道不是一個人開發的，需要一整個團隊。其中一個叫Robot Framework，很流行，我也寫了簡單的入門材料，大家有時間可以看一下。

這篇文章的原始碼是SeleniumKeywordDrivenFramework專案。