前言

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

前车之鉴

小编先介绍一下自身在测试过程中遇到的接口测试问题。这类问题历历在目，任何一个问题上线都会造成线上事故，用“幸亏我意识到了”形容非常恰当。

教训一：线上资讯信息流图集频道返回非图片信息。

原因：客户端发送图集请求时，携带的Content-Type与服务端接口定义的不一致，因此服务端返回异常。

教训二：刷新资讯信息流，获取线上数据时出现浏览器闪退。

原因：客户端发送资讯请求时，读取数据库参数失败，导致空指针异常，浏览器闪退。

教训三：浏览器地址栏下方不显示热词信息。

原因：服务端返回的是否显示热词信息的开关双方定义为0或者1；但是服务端返回却是True或者False，导致客户端不兼容，不显示热词信息。

类似这样的事件举不胜数，如何才能避免类似的问题再次出现呢，那么就要求我们的检查点不能遗漏，既要用例case命中率高，也要最大限度的覆盖检查点。

言归正传

做接口测试之前，先了解接口测试的目的，通常目的是通过需求承载的(这里就不介绍了)，然后就是了解接口文档，将接口文档中信息筛选出来，梳理出检查点，滴水不漏。

通常情况下，在测试接口时，均会有接口文档作为辅助，以接口文档规定的细节作为验收标准，但是也有特殊情况(没有接口文档)，此时可以向开发或者配合方询问以下细节，确保在没有辅助材料的情况下不遗漏测试点。

a)     数据请求域名以及接口b)     数据请求的协议c)      数据请求的类型d)     数据请求的Content-Type类型e)     数据请求参数f)      数据请求的拼接内容g)     数据请求的时机h)     云端返回数据信息i)       返回的数据信息存储路径j)       返回的数据信息存储方式k)     更新/替换本地存储的数据时机l)       清除存储数据的时机

通用的用例结构

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

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

字段名	类型	必填	示例	说明
A	string	必填	aswedz	鉴权字符串
B	string	可选填	12asdwdf	秘钥
C	object	必填		应用信息
D	object array	必填		图片信息

C字段信息如下：

字段名	类型	必填	示例	说明
appName	string	可选填		app应用名
pkgName	string	可选填		app应用包名信息

用例结构参考如下：

给大家准备的干货

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

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

加餐

本篇文章只是讲述请求层面的用例设计方法，特此概括一下：

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

总结

关于数据返回的用例设计方法以及接口测试方法，小编接下来会分两次给大家讲述，欢迎大家批评指正~

搜狗测试微信号：Qa_xiaoming

搜狗测试QQ粉丝群：459645679