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拼接在一起的。

同时，在这我为大家准备了一份软件测试视频教程（含面试、接口、自动化、性能测试等），就在下方，需要的可以直接去观看。