app端接口用例设计方法和测试方法（一）

前言

接口测试作为测试的重要一环，重点关注的是数据层面的输入输出，今天小编介绍一种常用的接口测试用例设计方法和测试方法，希望对大家有所帮助，由于内容较多，分三次给大家讲解，今天先介绍“请求层面的用例设计方法”。

前车之鉴

小编先介绍一下自身在测试过程中遇到的接口测试问题。这类问题历历在目，任何一个问题上线都会造成线上事故，用“幸亏我意识到了”形容非常恰当。 教训一：线上资讯信息流图集频道返回非图片信息。 原因：客户端发送图集请求时，携带的Content-Type与服务端接口定义的不一致，因此服务端返回异常。 教训二：刷新资讯信息流，获取线上数据时出现浏览器闪退。 原因：客户端发送资讯请求时，读取数据库参数失败，导致空指针异常，浏览器闪退。 教训三：浏览器地址栏下方不显示热词信息。 原因：服务端返回的是否显示热词信息的开关双方定义为0或者1；但是服务端返回却是True或者False，导致客户端不兼容，不显示热词信息。 类似这样的事件举不胜数，如何才能避免类似的问题再次出现呢，那么就要求我们的检查点不能遗漏，既要用例case命中率高，也要最大限度的覆盖检查点。

言归正传

做接口测试之前，先了解接口测试的目的，通常目的是通过需求承载的（这里就不介绍了），然后就是了解接口文档，将接口文档中信息筛选出来，梳理出检查点，滴水不漏。 通常情况下，在测试接口时，均会有接口文档作为辅助，以接口文档规定的细节作为验收标准，但是也有特殊情况（没有接口文档），此时可以向开发或者配合方询问以下细节，确保在没有辅助材料的情况下不遗漏测试点。 a) 数据请求域名以及接口 b) 数据请求的协议 c) 数据请求的类型 d) 数据请求的Content-Type类型 e) 数据请求参数 f) 数据请求的拼接内容 g) 数据请求的时机 h) 云端返回数据信息 i) 返回的数据信息存储路径 j) 返回的数据信息存储方式 k) 更新/替换本地存储的数据时机 l) 清除存储数据的时机

通用的用例结构

接口测试用例结构要符合实际请求和下发的数据结构，这样方便了解数据结构特点，快速掌握接口数据含义，熟悉接口业务。先介绍请求数据的用例结构

举个栗子：若接口文档中标明客户端请求数据格式如下：

C字段信息如下：

用例结构参考如下：

给大家准备的干货

用例结构中“数据来源”是为了接下来做请求拼接容错处理，对应接口测试检查点中的【数据请求的拼接内容】。

值得注意的是，除此之外，数据来源还有两种逻辑处理和移动设备信息。

加餐

本篇文章只是讲述请求层面的用例设计方法，特此概括一下： a) 梳理接口文档中关于获取数据的内容，方式等信息，为的是不遗漏测试点； b) 梳理获取数据参数来源，为的是评估拼接请求的容错范围； c) 代码写死的参数信息，不需要做容错；系统API获取到的参数信息，只需要考虑获取到的为空或者获取不到的情况下即可； d) 接口用例的设计结构要符合实际请求和获取到的数据结构； e) 拼接请求的参数来源于数据库/配置文件等需要做容错； f) 拼接请求的参数容错不需要考虑参数的数据类型； g) 请求拼接参数不需要做数据类型容错，因为不管存储的参数是什么类型，客户端均按照string拼接在一起的。