使用EOLINKER做介面測試最佳路徑（上）
本文內容：
-
測試指令碼管理：講述如何在 EOLINKER 上設計測試專案目錄結構。
-
編寫測試指令碼：講述如何在 EOLINKER 上編寫介面測試指令碼。
-
測試指令碼執行及報告：講述如何在 EOLINKER 上執行介面測試指令碼，及如何檢視和下載測試報告。
- 測試專案人員協作：講述如何在 EOLINKER 上進行多人的測試專案協作。
1.測試指令碼管理
在EOLINKER上設計測試專案目錄結構來管理測試指令碼；
先來看下EOLINKER的測試指令碼管理分級：
專案管理 > 測試專案管理 > 測試專案模組管理（支援子模組和子子模組管理） > 測試用例集 > 單個測試用例
測試指令碼管理分級
專案管理
如果現在你只有一個專案叫"小魚遊遊Web"，包含web版/app版/公眾號H5版/小程式版，你可以通過【新建自動化測試】（如下圖中標記1）來建立每個版本的測試專案；
如果現在你有多個專案，如"小魚遊遊Web"，"小魚遊遊APP"，同時每個專案包含web版/app版/公眾號H5版/小程式版，你可以先通過【新建分組】（如下圖中標記2），為"小魚遊遊Web"，"小魚遊遊APP"分別建立各自的專案目錄，然後進入各個專案目錄中，通過【新建自動化測試】（如下圖中標記1）來建立每個版本的測試專案；
另外，如果專案已經結案，可以通過專案列表的[歸檔]操作按鈕，專案就會移至【已歸檔專案】（如下圖中標記3）列表中，這裡的歸檔和未歸檔沒有本質上的區別，只是放在不同的資料夾而已。
專案管理頁面
通過前面操作，各位已經有了測試專案，大家可以進入專案來一看究竟。
1.如果需要了解測試專案當前的協作人員數/ 專案動態/ 測試用例個數等資訊的話，請開啟 概況頁面；
2.如果要建立並管理 測試專案模組，測試用例集以及單個測試用例，您可以先去 場景用例 頁面檢視，回頭將為您詳細講解；
3.如果想指定一批測試用例指令碼在你設定的時間自動跑，並把測試結果傳送到你指定的郵箱，定時進行檢視。這個功能需要大家開通企業版本才能進行使用；而如果你已經擁有企業版本，那你可以開啟 定時任務 頁面先看看裡面長什麼樣，後面會和大家進行詳細講解；
4.如果希望自定義一些公共呼叫的變數或引數，如 http 請求的預設值（host url，請求頭部，body 引數），來 公共資源管理 頁面。
5.如果想對測試指令碼進行限權管理，比如只讀/讀寫等，去 協作人員管理 頁面設定；
6.最後，如果你想在匯入 API 文件時，只看小魚遊遊 Web 專案的 API 文件時，你可以進行 自動化測試管理 裡面的【可引用的API專案】中進行設定；
測試專案管理
測試專案模組管理/測試用例集
回顧前面說的：“如果你要建立並管理 測試專案模組，測試用例集以及單個測試用例，先去[場景用例]頁面打個照面，稍後再詳細給你叨叨。”
點[場景測試]，進入測試專案模組/測試用例集頁面；
通過【新建分組】（如下圖中標記1）建立專案模組目錄（通常模組劃分2種：按業務和按介面，你可以在設計單介面測試指令碼時，按介面，在設計場景測試指令碼時，按業務），你可以通過模組目錄後面的選單按鈕，建立子分組和子子分組，即子模組和子子模組。
建立好模組目錄後，我們需要在各個模組目錄下面建立對應用例集，通過【新建用例】（如下圖中標記2）建立各自的用例集。
測試專案模組/測試用例集頁面
EOLINER 的用例集有2種類型：
1.普通型別-UI 模式（預設型別）：如果你偏愛介面，那你可以選擇這種模式，你只需要填空就能完成介面測試指令碼；
2.高階型別-程式碼模式：如果你鐘意擼程式碼，如果你又會 Javascript ，這個模式會更加適合你；
新建用例集彈窗
單個測試用例
到此，專案結構已完成，下面就可以開始編寫測試指令碼了。
在測試用例集列表，點選一個普通型別-UI模式用例集，進入單個測試用例 - 普通型別[UI模式]頁面，通過【+已有介面】（如下圖中標記1）從API文件匯入介面基本資訊（url/請求方法/請求協議/ 傳參/返回資訊），這樣方便我們設計指令碼時，只要改動傳參和新增校驗資訊，即完成一個用例指令碼編寫，具體怎麼做，去下一小節吧；當然如果開發的沒有在EOLINKER的API研發管理模組中編寫API文件，那你可以通過【+空白介面】（如下圖中標記2）來編寫測試指令碼。
單個測試用例頁面 - 普通型別[UI模式]
如果你點選是一個高階型別-程式碼模式用例集，你將進入單個測試用例 - 高階型別[程式碼模式]頁面，介面如下，
單個測試用例頁面 - 高階型別[程式碼模式]
2.編寫測試指令碼
上面小節已提到，編寫介面測試指令碼有2種方式：
-
通過【+已有介面】按鈕，從API文件列表匯入已有的介面文件（如下圖 - API文件列表頁面），然後基於介面文件基本資訊，並新增用例名稱和校驗資訊（斷言），完善介面測試指令碼。（推薦）
- 通過【+空白介面】按鈕，填寫空白介面文件，然後新增用例名稱和校驗資訊（斷言），完成介面測試指令碼。
截圖進入路徑：API研發與自動化測試 -> API研發管理 -> 小魚遊遊Web（Web開發專案）-> API文件
API文件列表頁面
如果你現在是在EOLINKER上編寫專案的第一條測試用例指令碼，你可以根據下面的步驟去編寫測試指令碼：
-
建立測試環境並匯入到用例集
-
建立前置用例（如登入或註冊）
- 建立後置用例（如退出登入）
說明：步驟2-3放在步驟5後面再做，也是可以的。
-
匯入API文件（或新增空白介面）
a. 在匯入的API文件中，編輯測試用例描述（在EOLINKER上叫介面名稱）
b. 在匯入的API文件中，編輯請求資訊
c. 在匯入的API文件中，編輯預期返回資訊（這裡是填寫返回頭部和返回引數，如果這部分開發已經填寫，可以跳過這一步）
d. 在匯入的API文件中，新增返回頭部校驗
e. 在匯入的API文件中，新增返回結果校驗
f. 在匯入的API文件中，新增高階設定
- 點儲存，完成測試指令碼編寫。
說明：後面新增新的用例，基本就是重複4-5的操作，還是挺便捷的嘛!
1.建立測試環境並匯入到用例集
在測試環境中，我們可以自定義公共URL（介面所在的主機名）自定義全域性變數、自定義新增公共請求引數、自定義新增公共請求頭部標籤、自定義新增公共鑑權方式。
建立測試環境並匯入到用例集操作步驟如下gif動態圖：
建立測試環境並匯入到用例集
GIF 動態圖說明：
第一個頁面為測試專案列表頁面。
第二個頁面為測試專案的公共資源管理-測試環境頁面，在這裡建立測試環境。
第三個頁面為測試專案的場景用例頁面，在這裡匯入剛才建立測試環境。
2.建立前置用例（如登入或註冊）
前置用例，即測試用例的前置條件，登入或資料初始化，目前還不支援遠端連線並操作資料庫，不過我們可以通過呼叫介面方式，達到資料初始化的目的。
這裡假設在 API 文件列表中，已經新增 登入的介面文件，這裡我通過【+已有介面】按鈕從 API 文件列表中 匯入登入介面 來建立前置用例，步驟如下 GIF 動態圖：
GIF動態圖說明：
-
第一個頁面為測試專案的場景用例頁面，在這裡，點【前置用例】，進入前置用例集列表頁面，然後點【新建前置用例】，建立一個名為 登入的用例集，點這個新建的用例集進入前置用例編輯頁面。
-
第二個頁面為前置用例編輯頁面，（注：在新建用例或匯入API前，先清除掉編輯視窗中的示例程式碼），在這裡，
a. 點【+已有介面】按鈕，此時會進入 API文件列表選擇頁面，勾選登入介面，點【確定】按鈕，完成API匯入。
b. 編輯匯入的API文件，因為這裡的登入介面有3個必填傳參，所以我定義3個變數，變數的值，需要自己去構造，每個公司的登入引數都不一樣，有的是時間戳+隨機字串+金鑰，有的是md5等等，這一部分eolinker都有封裝好的md5和sha方法，可直接呼叫，你也可以自己通過 在通用函式構造自定義的函式，如下圖為通用函式編輯頁面，我覺得這塊比jmeter好用太多，jmeter那邊你需要用java寫個jar包，然後在jmeter的測試計劃中匯入，然後呼叫的時候，還要寫beanshell指令碼，真的太麻煩了。
另外，還寫了個斷言，用於測試前置用例是否正確，其中"result_api_1.response"是獲取介面返回資訊，這個資訊是string型別，所以後面用JSON.parse()，將其轉化為json物件，用於後面response.statusCode獲取返回資訊中的statusCode欄位的值。
c. 編輯完API文件，即寫好前置用例，可以點測試按鈕，看是否登陸成功，我這裡測試結果是測試失敗，是因為我的3個傳參我給的是空的。
d. 點【儲存】，然後點【返回列表】返回到前置用例集列表頁面。
- 第三個頁面為前置用例集列表頁面。
3.建立後置用例（如退出登入）
後置用例，即為後期處理，返回引數加工、資源清除或資料清除。
後置用例和前置用例的建立步驟一樣，這裡就不再上gif動態圖。
4.匯入API文件並完成測試指令碼編寫
這裡不用多說，直接上gif動態圖，圖看不明白的，可以看下面的動態圖說明（TT，圖錄的好辛苦，要求加雞腿...）。
GIF動態圖說明：
-
第一個頁面為測試專案的場景用例頁面，在這裡，點之前建立好的 測試專案模組目錄【通用介面】，進入用例集列表頁面，然後點【新建用例】，建立一個名為 獲取公司列表的用例集，點這個新建的用例集進入用例編輯頁面。
-
第二個頁面為單例列表頁面，在這裡，
a. 點【+已有介面】，此時會進入 API文件列表選擇頁面，勾選登入介面，點【確定】按鈕，完成API匯入。
b. 點剛匯入的API文件後面的【編輯】操作按鈕進入用例編輯頁面。
-
第三個頁面為用例編輯頁面，
a. 編輯介面名稱，即用例名稱。
b. 訪問此介面時不用傳參，所以請求資訊這裡為空。
c. 預期返回引數，一般是開發在API文件填好的，所以這裡為空。
d. 沒有可校驗的返回頭部，所以返回頭部校驗這裡為空。
e. 返回結果校驗，這裡我用的是JSON檢驗方式，這裡有個【同步返回引數】按鈕，XML檢驗方式也有，如果開發已經寫好預期返回引數，點此按鈕後，所有的返回引數都會自動匯入到校驗欄位列表中。
f. 高階設定，我勾選了 【該用例校驗為失敗時,依然執行下一個用例】，如果沒勾選的話，此用例測試失敗時，後面的用例就不會被執行；其中【當某一校驗規則判斷為失敗時，依然判斷其餘規則】是預設勾選，表示如果校驗欄位列表中某個欄位校驗失敗，仍校驗其他還沒校驗的欄位；超時限制，預設5000ms，即5秒，表示 測試超時將會自動判斷為測試失敗。
點【儲存】，返回到單例列表頁面，即完成用例編寫。
- 第四個頁面為單例列表頁面，在這裡點【+前置用例】按鈕，在彈窗中選擇要新增的用例，因為成功呼叫這個 [獲取公司列表]通用介面需要登入的，這裡就需要新增 登入前置用例。
注：高階型別-程式碼模式的用例編寫方法和前面的建立前置用例的方法是一樣，這裡就不再詳細說明，如果你非常想我寫一篇關於 高階型別-程式碼模式的用例編寫的話，請留言，讓領導給我加雞腿!（對，我就是這麼沒出息，我就是要雞腿... ）
到此，測試用例編寫的正確方式，也就介紹完了，接下來我們可以執行前面寫的測試用例了，並且檢視測試報告。
本文總結
本文主要是引導大家怎麼用 EOLINKER 設計介面測試專案架構，其中包含如何專案目錄結構，如何編寫介面測試指令碼，如何執行測試指令碼和如何獲取測試報告，以及如何進行多人的協作。其中後兩部分的內容，我們在下篇文章介紹！