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 附加说明

由于目前该系列文章在笔者的公众号中连载，为了避免存在打广告的嫌疑，本文只是取自原文中部分内容、且文章中存在的跳转链接皆已全部取消