1、前言
今天，我们来聊聊，用RobotFramework如何编写接口用例及如何对用例断言。
2、开始前的准备
在写接口用例前，除了前面几节介绍的接口框架环境准备、接口用例规范的制定、项目分层这几点外，在真正开始写用 例之前，还有一环节是必须的，就是拿到接口的开发文档，可以理解就是一份接口的契约文件。
接口开发文档获取一般来讲，直接找对应接口开发的人员拿就可以了，这种方式虽然最简单直接，但在这里笔者并不推荐，正确提倡的做法，在每次接口提测时，需要由开发人员提供提测单且在提测单中，注明详细的提测要求，注意事项以及接口文档地址等，整个流程可以用gitlab完美串连起来，既想要的内容有了，而且流程也规范了。
注：以前笔者的公司接口开发文档以md格式编写，在gitlab上以版本管理的形式进行集中式管理。
3、接口编写套路
1、分析接口文档
本文用上述截图的接口为例：【获取热门作品列表 get /mfx/play/cdn/opus/getHeatValueOpusList】
由上图可知，该接口如下信息：
接口作用：获取某app首页热门作品列表
接口类型：Get
接口入参：2个，page（第几页）、pageSize（一页有多少个）
接口响应：为Json串，详细自行查看。
2、设计接口用例
按照之前介绍的《RobotFrameWork接口设计规范》中可知，常规接口在设计用例时，至少需包括三类，常规值用例、异常值用例、接口数据校验用例：
3、写接口用例
3.1 准备数据（接口入参）
3.2 构造请求
构造请求应该来说是整个接口用例流程中的最难的点，因为公司为了防止第三方随意刷接口或者破坏接口，都会根据产品后端特性，对请求设置各类加密方法，一般来讲，需要知道产品私钥key及加密流程和方法。
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、字段数据校验常规的做法是把所需的字段的值先取回来，再对每个字段的值加断言比较，那么如果返回的响应体，字段比较多，比如有几十个返回的字段，那这个工作也是非常耗时的。这里推荐的做法是可以写一个公共数据递归校验方法，比如：
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理
