1. 前言
本篇是第一系列（Http接口自動化）的第五課程，如果對系列課程大綱不清楚的，可以查看《RobotFramework系列免費課程-開課了~》。
前面我們介紹了，在真正實施前，需先定好多人協作過程中約定的接口用例規范，以及開始時，接口項目如何結構化分層，那么今天，我們來聊聊，用RobotFramework如何編寫接口用例及如何對用例斷言。
2. 開始前的准備
在寫接口用例前，除了前面幾節介紹的接口框架環境准備、接口用例規范的制定、項目分層這幾點外，在真正開始寫用 例之前，還有一環節是必須的，就是拿到接口的開發文檔，可以理解就是一份接口的契約文件。
接口開發文檔獲取一般來講，直接找對應接口開發的人員拿就可以了，這種方式雖然最簡單直接，但在這里筆者並不推薦，正確提倡的做法，在每次接口提測時，需要由開發人員提供提測單且在提測單中，注明詳細的提測要求，注意事項以及接口文檔地址等，整個流程可以用gitlab完美串連起來，既想要的內容有了，而且流程也規范了。
注：以前筆者的公司接口開發文檔以md格式編寫，在gitlab上以版本管理的形式進行集中式管理。
3. 接口編寫套路
3. 1、分析接口文檔
本文用上述截圖的接口為例：【獲取熱門作品列表 get /mfx/play/cdn/opus/getHeatValueOpusList】
由上圖可知，該接口如下信息：
接口作用：獲取某app首頁熱門作品列表
接口類型：Get
接口入參：2個，page（第幾頁）、pageSize（一頁有多少個）
接口響應：為Json串，詳細自行查看。
3.2、設計接口用例
按照之前介紹的《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 接口數據斷言
小技巧：
1、接口數據斷言時，可以不需要用具體的值進行比較，比如想判斷歌曲id返回，不需要拿具體的sondId的值與xxx數值進行比較，因為對於這類返回的字段來講，歌曲id都會要求是大於0的數值，所以斷言時比較返回的數據是否是大於0即可，對於返回的字符串字段而言，比如userLogo用戶頭像字段，比如返回的userLogo用戶頭像數據不為空即可。當然如果有些特殊場景，需要用具體的數值比較，可另當別論。
2、字段數據校驗常規的做法是把所需的字段的值先取回來，再對每個字段的值加斷言比較，那么如果返回的響應體，字段比較多，比如有幾十個返回的字段，那這個工作也是非常耗時的。這里推薦的做法是可以寫一個公共數據遞歸校驗方法，比如：
5. 教程目錄大綱（已更新）
RobotFrameWork環境搭建（基於HTTP協議的接口自動化）
6. 下節預告
《RobotFrameWork測試數據管理》
詳見可：閱讀原文
如想更深入學習RF接口設計內容或有疑問可給筆者留言
或加筆者微信號: jinjian_762357658