RobotFrameWork編寫接口測試及如何斷言

時間 2019-11-06

標籤 robotframework 編寫接口測試如何斷言简体版

原文原文鏈接

1. 前言

本篇是第一系列（Http接口自動化）的第五課程，若是對系列課程大綱不清楚的，能夠查看《RobotFramework系列免費課程-開課了~》。git

前面咱們介紹了，在真正實施前，需先定好多人協做過程當中約定的接口用例規範，以及開始時，接口項目如何結構化分層，那麼今天，咱們來聊聊，用RobotFramework如何編寫接口用例及如何對用例斷言。後端

2. 開始前的準備

在寫接口用例前，除了前面幾節介紹的接口框架環境準備、接口用例規範的制定、項目分層這幾點外，在真正開始寫用例以前，還有一環節是必須的，就是拿到接口的開發文檔，能夠理解就是一份接口的契約文件。微信

接口開發文檔獲取通常來說，直接找對應接口開發的人員拿就能夠了，這種方式雖然最簡單直接，但在這裏筆者並不推薦，正確提倡的作法，在每次接口提測時，須要由開發人員提供提測單且在提測單中，註明詳細的提測要求，注意事項以及接口文檔地址等，整個流程能夠用gitlab完美串連起來，既想要的內容有了，並且流程也規範了。app

注：之前筆者的公司接口開發文檔以md格式編寫，在gitlab上以版本管理的形式進行集中式管理。框架

3. 接口編寫套路

3. 一、分析接口文檔

本文用上述截圖的接口爲例：【獲取熱門做品列表 get /mfx/play/cdn/opus/getHeatValueOpusList】gitlab

由上圖可知，該接口以下信息：學習

接口做用：獲取某app首頁熱門做品列表測試

接口類型：Getui

接口入參：2個，page（第幾頁）、pageSize（一頁有多少個）加密

接口響應：爲Json串，詳細自行查看。

3.二、設計接口用例

按照以前介紹的《RobotFrameWork接口設計規範》中可知，常規接口在設計用例時，至少需包括三類，常規值用例、異常值用例、接口數據校驗用例：

3.3 、寫接口用例

數據準備（接口入參）-> 構造請求-> 響應斷言

3.3. 1 準備數據（接口入參）

看過我以前的文章就知道，這裏說的準備數據，對應的就是RobotFramework中的測試用例層（以前強調過在RF中，用例中儘可能只存放接口入參數據）

3.3.2 構造請求

構造請求應該來講是整個接口用例流程中的最難的點，由於公司爲了防止第三方隨意刷接口或者破壞接口，都會根據產品後端特性，對請求設置各種加密方法，通常來說，須要知道產品私鑰key及加密流程和方法。

3.3.3 響應斷言

拿到請求返回的響應體後，根據所需，校驗指望的數據是否存在響應體中，一般最多見的就是校驗預期的code值是否包括在響應返回數據中。

4. 接口用例如何斷言

接口用例設計好以後，如何能讓用例能發揮價值主要取決於斷言如何來寫，接口自動化用例的最終目的是經過接入研發體系的CI持續集成中，經過接口每日巡檢儘早地發現因接口變動致使的異常。那麼如何發現異常，簡單來講，就是指望接口返回的數據與接口實際返回的數據不一致。而這個過程就須要經過合理地在接口用例中使用斷言來實現。

那麼有人會問，接口斷言我加了啊？不就是校驗接口返回的code值是不是成功的嗎？我相信至少有一部分人在設計接口用例斷言時，只有且僅有校驗接口的返回code值，雖然code值的斷言是須要的，但不能僅僅只經過這一種斷言方式來作爲接口是否有異常的判斷依據。

那麼接口斷言，須要有幾種呢，從上面接口用例設計的截圖中你們也能看出，通常來講至少須要有三種：正常code斷言（正常返回的code值）、異常斷言（異常的code值和異常的msg錯誤信息）、接口關鍵數據斷言（校驗具體返回的數據字段值）

4.1 正常code斷言

4.2 異常code、msg斷言

4.3 接口數據斷言

小技巧：

一、接口數據斷言時，能夠不須要用具體的值進行比較，好比想判斷歌曲id返回，不須要拿具體的sondId的值與xxx數值進行比較，由於對於這類返回的字段來說，歌曲id都會要求是大於0的數值，因此斷言時比較返回的數據是不是大於0便可，對於返回的字符串字段而言，好比userLogo用戶頭像字段，好比返回的userLogo用戶頭像數據不爲空便可。固然若是有些特殊場景，須要用具體的數值比較，可另當別論。

二、字段數據校驗常規的作法是把所需的字段的值先取回來，再對每一個字段的值加斷言比較，那麼若是返回的響應體，字段比較多，好比有幾十個返回的字段，那這個工做也是很是耗時的。這裏推薦的作法是能夠寫一個公共數據遞歸校驗方法，好比：