使用Fitnesse進行介面自動化測試
阿新 • • 發佈：2019-02-12
隨著雲端計算以及SOA以及敏捷軟體開發的熱火朝天，對於測試工程師的要求也漸漸增加。目前很多公司特別是網際網路公司都已經開展介面測試這樣的工作，隨著web架構的日趨複雜，介面的種類也多種多樣，有http,webservice,hessian,dao,message以及簡單的api介面，那麼如何設計或者選擇一款測試框架來完成對這些介面的測試成為了一個很大的挑戰。本文將簡單介紹一款由java開發的開源測試框架Fitnesse在介面測試方面的使用，並且列舉一些簡單的demo來進行演示和說明。
FitNesse是一個輕量級的開源框架，能夠幫助開發和測試團隊方便的定義介面驗收測試（Acceptance Tests）。Fitnesse支援多語言軟體產品的測試，包括（java,c,c++,python,php）等等。具體使用可參考：http://www.fitnesse.org/.FitNesse.UserGuide，因為關於Fitnesse工具的介紹不是本文的主要意圖。在Fitnesse框架中，總共包括三個部分，Wiki，Test system，Fixtures。其中Wiki部分將展現具體的Test case以及Test suite甚至是Test Requirement，Test system包括兩部分Slim，Fit，也就是Fitnesse的執行引擎，Fixtures也就是真正的測試程式碼。Fitnesse具體架構圖如下所示：
從上圖大家可以看到，在Wiki pages上描述的是關於業務邏輯的測試用例，Fitnesse將會根據你所選擇的Test System(slim或者fit)來解析Wiki pages所傳送過來的Test cases, 假如我們選擇了slim作為我們的test system，那麼slim runners將會把網路傳輸過來的Wiki 指令碼轉換為一系列的指令，然後slim executer將會解析並執行這些指令來呼叫我們所編寫的測試程式碼也就是Fixtures code，fixtures可以是java語言測試程式碼，C語言測試程式碼或者其他語言編寫的測試程式碼，測試程式碼將會呼叫被測物件來執行測試用例。同理當你選擇fit作為Test runner的話過程也是一樣，只是fit在解析wiki指令碼的時候與slim不一樣，fit會將wiki page作為html頁面，然後通過解析html頁面來呼叫後臺的測試程式碼來執行測試用例，相對於slim效能上較差。另外在使用fit的時候設計測試程式碼也必須繼承fit的類來進行編寫，相對slim測試程式碼編寫相對受限。因此我推薦大家使用slim，因為slim會更加的輕量和高效，在過去的兩年時間裡面我們團隊一直使用slim作為test runner，並且在slim的基礎做了很多二次開發和改進，相對來說比較穩定。
我們可以使用Fitnesse做單元測試，整合測試，介面測試等相關測試。本文重點介紹Fitnesse在介面整合測試方面的使用，廢話少說，下面上主菜，在下面的例子中，將利用Fitnesse slim 做TestRunner，進行Java環境下的介面測試。
Http介面測試
可以利用第三方工具httpClient.jar編寫http介面客戶端傳送Request.在此我們做一個簡單的http介面測試，如對infoq登入介面進行測試。
首先編寫測試程式碼如下：
1. 傳送Post請求：
(1) 設定請求引數
該方法有兩個引數第一個引數為Map型別表示請求表單引數，第二個引數用來表示表單引數的個數，其中parameters為NameValuePair陣列，並設為全域性變數。
(2) 傳送請求
該方法引數為請求URL，postResponse為服務端返回值。
(3) 檢驗返回值
當然這裡的postResponse可能要根據業務需求的檢查點來做一些具體的解析，在本用例中不做詳細的解析。
接下去用Fitnesse來設計測試用例並執行測試：
(1) 設定表格環境變數，指定使用slim作為Testsystem，並且定義classpath，便於fitnesse能夠驅動測試程式碼執行用例。
(2) 定義測試資料，如提交的表單資料使用者名稱和密碼，我們是用來測試infoq的登入功能。
(3) 定義預期輸出值，在登入infoq成功之後，伺服器返回引數中會返回”ok”字串，該測試用例就是用來描述是否登入成功的scenario。
點選Test按鈕執行該case結果如下所示：
該用例有一個檢查點，也就是呼叫checkPostResponse方法的時候輸入預期值ok，該方法檢查返回字串的時候找到該字串，因此測試用例通過，測試用例pass,因此執行結果為綠色。
只需要更改引數就可以設計其他測試用例，組成infoq登入功能的測試集。
該節主要介紹fitnesse對http介面型別的測試。
Webservice介面自動化測試
目前大多數網際網路公司都採用SOA架構，因此對於webservice介面型別的測試顯得更加重要。通常測試工程師可能會藉助SoapUI等工具進行web service的測試，不可否認SoapUI在進行單一webservice介面測試中具有非常好的效果，但是在介面組合測試，以及在測試結果需要進行資料庫校驗的情況下就顯得不是那麼的自動化，總是需要人工干預，這在一定程度上導致測試效率偏低，因此我們在這裡介紹如何使用Fitnesse這塊開源產品實現介面測試自動化。
首先我們簡單的搭建了一個WebService demo.
該webservice介面總共包括4個方法，我們要測試一下addUserToTheWorld和getUserFromTheWorld這兩個方法組成的一個Scenario。
首先，設計測試程式碼，思路和http介面測試一樣，設計webservice client端傳送請求，利用spring和cxf設計webservice client端，當然也可以通過cxf或者axis自帶客戶端生成工具產生客戶端程式碼，但是還是建議自己動手寫客戶端，這樣可以使程式碼簡單清晰。
Spring context配置如下：
客戶端測試程式碼如下所示：
我們再來看在Fitnesse中如何設計case描述上述程式碼：
測試用例描述如下所示：
上圖中的用例描述為呼叫testAddUserToTheWorld方法將使用者加入資料庫，然後呼叫testGetUserFromTheWorld從資料庫中取出相關資料，這樣就作為一個組合場景呼叫了webservice的addUserToTheWorld和getUserFromTheWorld這兩個方法，當然還可以設計更多的場景來測試，如果用soupUI的話起碼得做兩次操作，如果有資料庫檢查的需要的話可能需要3次操作，不便於做自動化。接下去我們看一下該用例執行結果。
執行結果如上圖所示測試執行通過。我們再來看一下用例失敗的場景：
我們將預期輸出結果的Age的值改為了27，測試用例執行失敗，與實際結果不符合。
Database校驗測試
我們再來討論一下資料庫校驗測試，開源社群已經有很多相關的資料庫測試工具如Dbunit等等，以及Fitnesse/Fit測試引擎的DBFit都是很優秀的工具，筆者根據DBFit的功能設計了Fitnesse/slim測試引擎的DBSlim,來方便對資料庫測試的操作。
DBSlim目前有增刪改查的功能，支援對oracle、mysql、sqlserver的操作，原始碼已上傳google.code開源，具體在Fitnesse中的使用場景如下所示：
使用dbslim首先要設定相關環境變數，由於是使用maven做程式碼的管理，因此使用的時候需要配置好如上圖的dependency。上圖中有三個Wiki table，第一個table表示所引用的包名，第二個表格是用來連線資料庫，我們使用的mysql所以就呼叫ConnectToMysql方法，依次配置好資料庫url和埠號，資料庫名稱，使用者名稱和密碼。第三個表格是對fitnesse的query表格做了一些改進，用來做資料庫的查詢工作，Query:Query是Query表格的書寫方法，第一個Query表示是查詢表格的關鍵字，第二個Query是指呼叫Dbslim中的Query類，後面的引數為要查詢的sql。表格的第二行表示要查詢的欄位和sql中查詢欄位一一對應，第三行表示期望值，由此組成了一個數據庫查詢操作的場景。關於Fitnesse中表格的使用方法同樣可以參考Fitnesse官方的User guide。我們看一下執行結果：
本文再此只介紹查詢操作，其他操作不再一一介紹。
總結
本文主要介紹Fitnesse在介面測試以及整合測試中的使用，從上面的Demo中可以看出，使用Fitnesse做介面測試，有以下幾點好處：
1. 測試程式碼編寫簡單，風格自由。
2. 測試程式碼和業務邏輯分離，fitnesse上面只負責業務story的編寫，測試程式碼和業務用例方便維護。
3. 測試程式碼冗餘度大大降低，同一段測試程式碼可以組成多個業務場景使用。
4. Fitnesse是完全有Java開發的測試框架，跨平臺並且便於與其他測試框架的合併，筆者曾經做過Fitnesse與TestNG，Junit以及Selenium的整合。
5. Fitnesse執行方式多種多樣，便於後期的持續整合和持續交付，以及敏捷測試，筆者以完成Fitnesse測試報告的解析並且配合Hudson做持續構建。
6. 更重要的是Fitnesse可以用於敏捷測試，這個也是Fitnesse的作者，Uncle Bob的初衷。
目前存在很多開源測試框架，但是如何選擇並且設計需要根據公司的業務需求來決定，比如說網際網路公司就比較適合使用Fitnesse這樣的測試框架來構建自動化測試框架，使得測試設計、執行以及
管理都顯得相對簡單和清晰，並且對於測試框架的選擇最重要的就是要考慮其擴充套件性，這個便於後期與其他工具和框架的整合，否則我們在後期的工作當中將會遇到想象不到的困難。
FitNesse是一個輕量級的開源框架，能夠幫助開發和測試團隊方便的定義介面驗收測試（Acceptance Tests）。Fitnesse支援多語言軟體產品的測試，包括（java,c,c++,python,php）等等。具體使用可參考：http://www.fitnesse.org/.FitNesse.UserGuide，因為關於Fitnesse工具的介紹不是本文的主要意圖。在Fitnesse框架中，總共包括三個部分，Wiki，Test system，Fixtures。其中Wiki部分將展現具體的Test case以及Test suite甚至是Test Requirement，Test system包括兩部分Slim，Fit，也就是Fitnesse的執行引擎，Fixtures也就是真正的測試程式碼。Fitnesse具體架構圖如下所示：
從上圖大家可以看到，在Wiki pages上描述的是關於業務邏輯的測試用例，Fitnesse將會根據你所選擇的Test System(slim或者fit)來解析Wiki pages所傳送過來的Test cases, 假如我們選擇了slim作為我們的test system，那麼slim runners將會把網路傳輸過來的Wiki 指令碼轉換為一系列的指令，然後slim executer將會解析並執行這些指令來呼叫我們所編寫的測試程式碼也就是Fixtures code，fixtures可以是java語言測試程式碼，C語言測試程式碼或者其他語言編寫的測試程式碼，測試程式碼將會呼叫被測物件來執行測試用例。同理當你選擇fit作為Test runner的話過程也是一樣，只是fit在解析wiki指令碼的時候與slim不一樣，fit會將wiki page作為html頁面，然後通過解析html頁面來呼叫後臺的測試程式碼來執行測試用例，相對於slim效能上較差。另外在使用fit的時候設計測試程式碼也必須繼承fit的類來進行編寫，相對slim測試程式碼編寫相對受限。因此我推薦大家使用slim，因為slim會更加的輕量和高效，在過去的兩年時間裡面我們團隊一直使用slim作為test runner，並且在slim的基礎做了很多二次開發和改進，相對來說比較穩定。
我們可以使用Fitnesse做單元測試，整合測試，介面測試等相關測試。本文重點介紹Fitnesse在介面整合測試方面的使用，廢話少說，下面上主菜，在下面的例子中，將利用Fitnesse slim 做TestRunner，進行Java環境下的介面測試。
Http介面測試
可以利用第三方工具httpClient.jar編寫http介面客戶端傳送Request.在此我們做一個簡單的http介面測試，如對infoq登入介面進行測試。
首先編寫測試程式碼如下：
1. 傳送Post請求：
(1) 設定請求引數
該方法有兩個引數第一個引數為Map型別表示請求表單引數，第二個引數用來表示表單引數的個數，其中parameters為NameValuePair陣列，並設為全域性變數。
(2) 傳送請求
該方法引數為請求URL，postResponse為服務端返回值。
(3) 檢驗返回值
當然這裡的postResponse可能要根據業務需求的檢查點來做一些具體的解析，在本用例中不做詳細的解析。
接下去用Fitnesse來設計測試用例並執行測試：
(1) 設定表格環境變數，指定使用slim作為Testsystem，並且定義classpath，便於fitnesse能夠驅動測試程式碼執行用例。
(2) 定義測試資料，如提交的表單資料使用者名稱和密碼，我們是用來測試infoq的登入功能。
(3) 定義預期輸出值，在登入infoq成功之後，伺服器返回引數中會返回”ok”字串，該測試用例就是用來描述是否登入成功的scenario。
點選Test按鈕執行該case結果如下所示：
該用例有一個檢查點，也就是呼叫checkPostResponse方法的時候輸入預期值ok，該方法檢查返回字串的時候找到該字串，因此測試用例通過，測試用例pass,因此執行結果為綠色。
只需要更改引數就可以設計其他測試用例，組成infoq登入功能的測試集。
該節主要介紹fitnesse對http介面型別的測試。
Webservice介面自動化測試
目前大多數網際網路公司都採用SOA架構，因此對於webservice介面型別的測試顯得更加重要。通常測試工程師可能會藉助SoapUI等工具進行web service的測試，不可否認SoapUI在進行單一webservice介面測試中具有非常好的效果，但是在介面組合測試，以及在測試結果需要進行資料庫校驗的情況下就顯得不是那麼的自動化，總是需要人工干預，這在一定程度上導致測試效率偏低，因此我們在這裡介紹如何使用Fitnesse這塊開源產品實現介面測試自動化。
首先我們簡單的搭建了一個WebService demo.
該webservice介面總共包括4個方法，我們要測試一下addUserToTheWorld和getUserFromTheWorld這兩個方法組成的一個Scenario。
首先，設計測試程式碼，思路和http介面測試一樣，設計webservice client端傳送請求，利用spring和cxf設計webservice client端，當然也可以通過cxf或者axis自帶客戶端生成工具產生客戶端程式碼，但是還是建議自己動手寫客戶端，這樣可以使程式碼簡單清晰。
Spring context配置如下：
客戶端測試程式碼如下所示：
我們再來看在Fitnesse中如何設計case描述上述程式碼：
測試用例描述如下所示：
上圖中的用例描述為呼叫testAddUserToTheWorld方法將使用者加入資料庫，然後呼叫testGetUserFromTheWorld從資料庫中取出相關資料，這樣就作為一個組合場景呼叫了webservice的addUserToTheWorld和getUserFromTheWorld這兩個方法，當然還可以設計更多的場景來測試，如果用soupUI的話起碼得做兩次操作，如果有資料庫檢查的需要的話可能需要3次操作，不便於做自動化。接下去我們看一下該用例執行結果。
執行結果如上圖所示測試執行通過。我們再來看一下用例失敗的場景：
我們將預期輸出結果的Age的值改為了27，測試用例執行失敗，與實際結果不符合。
Database校驗測試
我們再來討論一下資料庫校驗測試，開源社群已經有很多相關的資料庫測試工具如Dbunit等等，以及Fitnesse/Fit測試引擎的DBFit都是很優秀的工具，筆者根據DBFit的功能設計了Fitnesse/slim測試引擎的DBSlim,來方便對資料庫測試的操作。
DBSlim目前有增刪改查的功能，支援對oracle、mysql、sqlserver的操作，原始碼已上傳google.code開源，具體在Fitnesse中的使用場景如下所示：
使用dbslim首先要設定相關環境變數，由於是使用maven做程式碼的管理，因此使用的時候需要配置好如上圖的dependency。上圖中有三個Wiki table，第一個table表示所引用的包名，第二個表格是用來連線資料庫，我們使用的mysql所以就呼叫ConnectToMysql方法，依次配置好資料庫url和埠號，資料庫名稱，使用者名稱和密碼。第三個表格是對fitnesse的query表格做了一些改進，用來做資料庫的查詢工作，Query:Query是Query表格的書寫方法，第一個Query表示是查詢表格的關鍵字，第二個Query是指呼叫Dbslim中的Query類，後面的引數為要查詢的sql。表格的第二行表示要查詢的欄位和sql中查詢欄位一一對應，第三行表示期望值，由此組成了一個數據庫查詢操作的場景。關於Fitnesse中表格的使用方法同樣可以參考Fitnesse官方的User guide。我們看一下執行結果：
本文再此只介紹查詢操作，其他操作不再一一介紹。
總結
本文主要介紹Fitnesse在介面測試以及整合測試中的使用，從上面的Demo中可以看出，使用Fitnesse做介面測試，有以下幾點好處：
1. 測試程式碼編寫簡單，風格自由。
2. 測試程式碼和業務邏輯分離，fitnesse上面只負責業務story的編寫，測試程式碼和業務用例方便維護。
3. 測試程式碼冗餘度大大降低，同一段測試程式碼可以組成多個業務場景使用。
4. Fitnesse是完全有Java開發的測試框架，跨平臺並且便於與其他測試框架的合併，筆者曾經做過Fitnesse與TestNG，Junit以及Selenium的整合。
5. Fitnesse執行方式多種多樣，便於後期的持續整合和持續交付，以及敏捷測試，筆者以完成Fitnesse測試報告的解析並且配合Hudson做持續構建。
6. 更重要的是Fitnesse可以用於敏捷測試，這個也是Fitnesse的作者，Uncle Bob的初衷。
目前存在很多開源測試框架，但是如何選擇並且設計需要根據公司的業務需求來決定，比如說網際網路公司就比較適合使用Fitnesse這樣的測試框架來構建自動化測試框架，使得測試設計、執行以及
管理都顯得相對簡單和清晰，並且對於測試框架的選擇最重要的就是要考慮其擴充套件性，這個便於後期與其他工具和框架的整合，否則我們在後期的工作當中將會遇到想象不到的困難。