Postman實戰總結
簡介
本次實戰內容主要包括如下幾點：
l 背景介紹
l Postman使用，側重于自動化實作，基礎使用不做介紹
l 可視化Newman介紹
l 框架特色
l 實戰中的坑
背景
隨著國內軟體技術的高速發展，越來越多的手工測驗逐漸被自動化所替代，如UI測驗，介面測驗，單元測驗等均可被自動化所替代，國內的大型互聯網公司早已將自動化測驗做的很成熟，大大提升了產品的交付效率和交付質量，
在it行業的大趨勢下，產品組面臨著如下四個挑戰：
1. dubbo+cloudt2.X底層的老介面亟待升級；
2. 產品基本實作雙周迭代，回歸測驗無法覆寫全部模塊，偶爾出現關聯影響考慮不周，導致泄露bug出現；
3. 測驗資源不足，出現泄露bug后，影響產品質量；
4. 陸續嘗試過使用python、doclever、eolinker、postman等做過介面測驗，效果不是太理想，
在此背景下，最終通過研究，結合產品組內對postman有使用經驗，且測驗人員自動化能力欠缺，postman封裝好，學習成本低，可快速產出自動化腳本，確立使用Postman+newman作為介面自動化測驗方案，
如果你不想再體驗一次自學時找不到資料，沒人解答問題，堅持幾天便放棄的感受的話，可以關注我一起討論，
給大家推薦一個軟體測驗技術交流群：1079636098 群友福利免費領取
Postman
Json用例
Json格式的自動化測驗用例，其實保存的是陣列，陣列元素均為物件，而一個物件則對應了一條用例，如下圖；
用例包含了用例名稱（caseName），用例描述（description），期望呼叫結果（expectation），自動化業務型別（requestType），入參（queryData），預期結果（checkData）,結果校驗欄位（checkKey）；可根據自動化框架需要，靈活設定自己的用例引數，
Postman中訪問用例資料的幾種方式，為了便于后面查看，特準備如下格式用例：
[
{
"url":"requestUrl",
"params":"params"
"body":0,
"script":{
"consoleInfo":"helloWorld"
}
}
]
1. 介面地址，只能訪問用例物件中最外層屬性，使用方式{{variableName}}
2. Params，使用方式和規則同地址
3. Body，使用方式和規則同地址
4. Pre-request-Script& Tests（下文均稱前置腳本和后置腳本），data指向用例物件，想要獲取物件的屬性，通過data.屬性名的方式獲取，如下圖：
環境變數
Postman支持環境變數，其中可設定一些不同環境的變數，如域名，登錄賬號密碼等，
環境變數也可以在腳本中使用，使用方式如下：
1． 介面地址，params和body中的使用方式同用例屬性的呼叫方式，{{variableName}}，如果出現變數沖突時，優先取用例中的屬性，比如環境變數中設定了url=www.baidu.com，用例物件最外層屬性中也有一個url=www.google.com屬性，那么優先使用www.google.com
2． 前置和后置腳本中使用環境變數會有所不同，可使用postman封裝的方法,具體使用如下：
全域變數
Postman支持設定全域變數，顧名思義，全域變數在任何環境下均可以使用，這也就限制了其只能設定一些公用的變數，介面地址，params和body中對于全域變數的使用同環境變數，這里不再贅述；前置/后置腳本中的使用方式大體與環境變數相同，只不過postman封裝的方法名有差異：
獲取全域變數：pm.globals.get(“variable_key”);
設定全域變數：pm.globals.set(“variable_key”,”variable_value”);
清慷訓境變數：pm.globals.unset(“variable_key”);
在此次自動化實戰中，博主提煉了公用方法作為全域變數，比如獲取時間戳，對比資料，處理cookie，查詢資料字典等等，下圖是獲獲取時間戳方法，getTime是方法名，右側是方法體：
全域變數中的公用方法使用不同于變數，需要特殊處理；如果想要在腳本中使用獲取時間戳方法，需要使用eval()方法參考，如同java中的import；
注意：
1. 使用eval參考方法時，方法名后面不需要增加()，而呼叫方法時需要增加()；
2. 環境變數中也可以設定方法，不過一般不這樣使用，使用方式類似于全域變數，eval(environment.functionName)；
3. 方法中可以呼叫其他方法，用法同1、2，
腳本
前置腳本在呼叫介面前執行，一般對介面引數進行前置處理，如對入參進行賦值；后置腳本在介面呼叫后執行，一般對介面回應結果進行校驗，對于環境變數、全域變數、json外部資料訪問上文中已經涉及，此處不再贅述，
這兩部分是postman支持腳本撰寫的部分，博主習慣使用JavaScript語言進行撰寫；而且postman列舉了一些常用的方法，這里就不再對其一一介紹，主要介紹幾個postman未列舉，但是在后置腳本撰寫程序中很實用的點：
1. postman.setNextRequest()：跳轉
collection中有多個介面，一條用例會涉及多個介面的呼叫，如果不加跳轉陳述句，自動化運行時會默認執行下一個介面，會使用例執行流程不易控制，如果增加跳轉陳述句后，跳轉就會靈活，結束執行流程也變得更方便；
結束當前用例執行：postman.setNextRequest(null)；
跳轉執行另一個介面：postman.setNextRequest(“介面名稱”)；
2. return：回傳
Tests腳本可看做一個方法的方法體，上圖中的return也就意味著方法回傳了，不再執行后續腳本
3. responseCode：介面呼叫狀態
一般只需要使用其中的code（介面回應碼），使用方式：responseCode.code，整個responseCode內容如下：
{
"name": "OK",
"detail": "Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request the response will contain an entity describing or containing the result of the action.",
"code": 200,
"standardName": "OK"
}
4. responseBody：回應結果
這里要注意的是，responseBody的值是字串型別的回應結果，如介面回傳應該是物件，則需要對responseBody進行轉換（JSON.parse(responseBody)）
5. request：當前呼叫介面資訊，內容如下：
6. tests[“回應斷言輸出內容”] = true：回應斷言，任何一個腳本都要有回應斷言
等號后面可使用判斷陳述句，如果是true，則斷言通過，如果是false，斷言失敗，如判斷tests[“介面呼叫成功，狀態碼為200”] = responseCode.code == 200，判斷介面是否呼叫成功，
自動化測驗
使用postman可以在本地進行單個collection進行自動化測驗，collection runner視窗即可進行執行自動化腳本，
1. environment可選擇執行環境變數；
2. Iterations設定執行用例數，如果設定用例數少于json外部檔案中的用例數，那么只執行設定的用例數；如果設定用例數多于json外部檔案中的用例數，那么執行完全部用例后，會將最后一條用例重復執行，直到執行完設定的Iterations次數為止，
3. Delay設定執行間隔時間；
4. Data可選擇外部json用例，這里注意檔案中json資料格式如果有問題會報錯，
運行結果如下：
Newman
Newman 是 Postman 推出的一個 nodejs 庫，直接來說就是 Postman 的json檔案可以在命令列執行的插件，Newman 可以方便地運行和測驗集合，并用之構造介面自動化測驗和持續集成，
Newman的安裝在這里不進行贅述，網上有很多安裝教程，
因newman需要使用bat命令運行，自動化腳本量大，且撰寫命令形式不利于管理；為了解決這個問題，特開發newman可視化頁面，可選擇環境變數和全域變數，批量選擇腳本，自動生成bat命令并執行，提高效率，降低使用難度，可視化頁面如下圖
Newman執行腳本，每套腳本會生成三種格式的報告（xml，json和html），可讀性很差，為了解決這個問題，進行了如下研究：
1. 現程序中發現json檔案大，讀取效率低；
2. 通過查詢資料，確定從newman安裝檔案中生成報告的js腳本下手（路徑：C:\Users\賬號 \AppData\Roaming\npm\node_modules\newman\lib\reporters\json），縮減json報告大小，只保留部分有用的內容
3. 生成excel格式的自動化報告
4. 郵件發送，通過nodejs腳本自動將處理后的報告，以郵件形式發送到干系人，
框架特點
按業務模塊存放
此次實戰主要針對web api，介面自動化冒煙測驗從業務維度進行拆分collection，不僅測驗單介面例外情況，也支持關聯介面之間配合測驗；
資料驅動模式
1． 自動化用例全部提取到外部json檔案；
2． 同一個collection中，不存在相同介面；
3． 任何一個介面中入參或出參，都只有一個變數保存在用例中，后續介面維護后，僅需要更新用例，腳本無需再做修改；如入參或出參需要處理，則在前置腳本中進行處理；示例見下圖，body中只傳入一個變數值；
4． 預期結果保存在用例中，同一套腳本，適用不同的業務場景，
如果你不想再體驗一次自學時找不到資料，沒人解答問題，堅持幾天便放棄的感受的話，可以關注我一起討論，
給大家推薦一個軟體測驗技術交流群：1079636098 群友福利免費領取
公用方法提煉
為了減少自動化腳本中的冗余腳本，提高腳本的撰寫效率，特提煉公用方法到全域變數中，不僅減少代碼復雜度，提高腳本撰寫效率，也能夠降低此套自動化框架的上手難度；公用方法的使用方式在postman介紹中已經描述，此處不再贅述，
多環境執行
在多套環境的基礎上，基礎資料的主鍵有所不同；面臨越來越多的自動化腳本，維護的作業量不斷加大，
為了減少這部分的作業，通過研究，確立資料字典模式：
1. 將環境下的資料字典維護到環境變數中
2. 自動化用例中需要使用基礎資料主鍵的部分，增加變數標識
3. 撰寫公用方法，用來識別變數并在資料字典中匹配并替換成匹配結果，
優勢：腳本和用例有且只有一套，適用于任何環境，進一步降低維護成本
劣勢：用例的可讀性降低，不能直觀看出資料
實戰中的坑
1. 如body中使用的變數需要是物件或陣列，則需要將物件或陣列通過JSON.stringify()轉換成字串后，賦值給變數才能成功呼叫介面；
Json外部用例格式，body引數要傳入bodyInfo屬性：
前置腳本處理：
Body中呼叫：
2. 前置或后置腳本中定義變數時，如果不寫識別符號，定義的變數可在其他介面執行時使用，但其生命周期僅限于本條用例執行完畢，
查詢1中定義變數：
查詢2中輸出test的內容：
Collection runner運行后輸出結果
3. 前置腳本中不支持介面間跳轉：postman.setNextRequest();
4. Collection可增加前置腳本，后置腳本和變數定義；前置腳本和后置腳本，沒呼叫一個介面后，均執行一次；
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/247979.html
標籤：其他