如何设计接口测试用例？接口测试实战案例分享

本文关于如何设计接口测试用例？接口测试实战案例分享。

一、用例设计1

1、接口测试概念

接口测试：测试系统间接口的一种测试，测试的对象主要是接口，主要是测试外部系统与所测系统之间以及内部系统之间的交互点

2、接口测试方法

a、可以通过开发脚本代码进行测试

b、可以通过开源免费的接口调用调试工具测试，如：Postman等。

c、可以通过App手动测试，结合抓包工具分析，如：Fillder/Charles等

3、接口测试范围

接口范围包括：

一、被测项目中同层之间的接口（如DAO层、Service层），一个接口调用了其他的接口。

二、外部系统与系统之间的交互点（如一个App调用了第三方支付宝的API）

三、各个子系统之间的交互点（如App客户端调用了服务端的Http接口）

被测接口范围：

通常接口会很多，接口测试范围的筛选，参考测试人力资源、项目特点、接口重要性与优先级来进行。其中第一种属内部接口，构造测试稍复杂需开发配合实施，通常优先覆盖第二、三种接口

接口测试的重点测试范围：

优先测试覆盖核心业务，复杂业务的接口

4、如何设计接口测试用例

接口测试出发点是被测接口逻辑存在错误，参考这个为出发点，更容易发现问题

设计接口测试用例，我们可简单的考虑两个基本要素，即：入参、出参，正确/错误的入参，逻辑判断后，接口是否做出正确的处理，返回正确的出参

接口测试用例有3类（逻辑测试，异常测试，路径测试）：

1）逻辑测试：主要是根据开发提供的接口文档来设计测试用例，接口文档包含的要素（前提条件，输入参数，参数类型，业务逻辑，返回输出描述等），此类主要测试在正常输入的情况下，是否能得出正确的输出结果。主要使用的用例设计方法是等价类划分，边界值等

2）异常测试：接口逻辑的测试中主要测试接口正常逻辑，即对外提供的接口服务是基本可用的，但仅逻辑测试不能保证数据的安全及程序接口在异常情况下的逻辑处理的正确性

(a) 空值,null;

(b) 参数属性(如：未赋值的参数)

(c) 异常业务参数(如：构造不满足业务异常业务参数)

(d) 参数个数、参数类型错误(如：接口文档中定义必填参数2个int,输入参数仅1个,类型非int)

3）路径测试：当被测接口的实现方法中，判断逻辑复杂分支多，且判断中又调用了其他的接口，此时必须要进行路径覆盖测试

5、接口测试关注点

6、接口自动化测试工具

1）Java(HttpClient) + Junit/TestNG;

2）Jmeter

3）SoapUI

4）Python requests/urllib 库;

......

二、用例设计2

1、优先级--针对所有接口

1.暴露在外面的接口，因为通常该接口会给第三方调用

2.供系统内部调用的核心功能接口

3.供系统内部调用非核心功能接口

2、优先级--针对单个接口

1.正向用例优先测试,逆向用例次之(通常情况，非绝对)

2.是否满足前提条件 > 是否携带默认参值参数 > 参数是否必填 > 参数之间是否存在关联 > 参数数据类型限制 > 参数数据类型自身的数据范围值限制

3、设计分析

通常，设计接口测试用例需要考虑以下几个方面：

1.是否满足前提条件

有些接口需要满足前置条件，才可成功获取数据。常见的，需要登陆Token；

逆向用例：针对是否满足前置条件(假设为n个条件)，设计0~n条用例

2.是否携带默认值参数

正向用例：带默认值的参数都不填写、不传参，必填参数都填写正确且存在的“常规”值，其它不填写，设计1条用例

3.业务规则、功能需求

这里根据实际情况，结合接口参数说明，可能需要设计n条正向用例和逆向用例

4.参数是否必填

逆向用例：针对每个必填参数，都设计1条参数值为空的逆向用例

5.参数之间是否存在关联

有些参数彼此之间存在相互制约的关系；

逆向用例：根据实际情况，可能需要设计0~n条用例

6.参数数据类型限制

逆向用例：针对每个参数都设计1条参数值类型不符的逆向用例

7.参数数据类型自身的数据范围值限制

正向用例：针对所有参数，设计1条每个参数的参数值在数据范围内为最大值的正向用例

逆向用例：针对每个参数(假设n个)，设计n条每个参数的参数值都超出数据范围最大值的逆向用例；针对每个参数(假设n个)，设计n条每个参数的参数值都小于数据范围最小值的逆向用例

全网最详细的接口测试实战案例

一、接口测试的误区

前段时间，有个朋友跳槽去了一家公司做服务端的测试开发工程师，月薪涨了50%

我第一时间向他送去了诚挚的祝福，同时询问了他去到新公司的工作情况。

他和我说，他目前主要负责一个电商平台的接口测试工作以及开始着手去搭建一个接口自动化测试平台。

因为该同事以前是做移动端的测试的，从来没有听说过，他有做接口测试的经验。于是我出于好奇，就问了一下：他目前是如何去进行接口测试的。

他对这个问题可能没有做出充足的准备，也有可能他因为之前没有接口测试的相关经验，他给到我的回答，其实和网上随便搜出来的答案差不多：

通过 Postman / Jmeter / 代码调用 等测试工具，来模拟网络请求，

1. 校验接口传参是否合理（少传 / 漏传 / 多传 / 边界值 / 参数类型校验等等）。

2. 测试响应结果是否会返回约定的数据格式，有没有字段没有下发或下发不正确。

3. 验证接口是否有安全性问题，是否鉴权。

利用 Postman 进行接口测试

对于这个回答，我并不感到意外，网上大多数的回复也都是这么说的。

但是对于一个纯服务端的测试而言，仅仅是调调参数，真的就能完成接口测试了么？

NO，这只是接口测试的冰山一角，接口测试远没有你想象中的那么简单！

那么，接口测试主要需要测试哪些方面呢？

按照惯例，先上老（nao）图：

接下来，臻叔将用一次深度的接口测试实战，来分享一下，臻叔是如何去做接口测试的。

二、接口测试的实战步骤

接下来我们以电商平台的搜索接口来做案例，一步步给大家讲解接口测试的步骤。

第一步：梳理上下游调用链

1）为什么要梳理上下游调用链？

目前互联网产品的后端服务，基本上都是分布式部署的，一个接口可能会调用其他接口，也有可能被其他接口调用，接口与接口之间，具有千丝万缕的依赖关系。

如果我们的把自己负责的接口纯粹地当成黑盒去测试，不可谓知己；

如果我们只熟悉自己的接口，不清楚与其他接口的依赖关系，不可谓知彼；

所谓知己知彼，方能百战不殆。

所以，梳理上下游调用链是首先要做的工作。

我们在测试的时候，很可能只会片面的去关注搜索网关开放给前端调用的接口，

但只要把整个调用链路和流程图画出来，我们会发现其实搜索网关依赖好多的服务。

比如：

搜索网关需要调用价签系统，去获取商品促销价格；

搜索网关需要调用推荐系统，去获取搜索场景下的推荐的商品；

搜索网关需要去调用商品系统，去获取实时的商品信息；

搜索网关需要去调用搜索服务，去ES召回商品、获取搜索排序信息等等。

前端在搜索框搜索一个关键词，对搜索网关发起一个HTTP请求，背后其实经过了很多道工序去处理这个请求。

如果只是单独的调调参数，就希望把接口测试做好，显然是不可能的。（开发自己都能调（tiao）接口参数，还要测试做什么？）

接口背后的业务逻辑是否正确处理、后端依赖的服务是否健壮、接口性能是否达标。

2）怎么梳理上下游调用链？

1、看项目wiki、产品文档和开发文档。

2、看开发写的代码，阅读代码，当然是首选：JetBrains全家桶啦（Java用IDEA；Python用Pycharm）

3、梳理出上下游调用关系后，手绘一份系统流程图，如果还有不明确的地方，可以找PM、开发沟通确认。

第二步：编写接口测试用例

接口测试用例和平常的测试用例差不多，没有太多的要求限制。因为测试工作中很多时候不是专门测接口的，所以这个步骤不一定要做。

但是你心里要清楚你要测的点，如果你是第一次做接口测试，臻叔还是建议自己去写一份接口测试用例，并且好好归档。

如果说要做接口自动化，接口测试用例也是很有帮助的。

这里给出一个接口测试用例的案例：

第三步：测试接口文档&调试接口

接口文档在软件项目开发过程中非常重要，接口文档是连接前端开发和后端开发的一座桥梁。

在项目开发之初，前端开发和后端开发会共同去约定一套接口规范，然后由后端开发去编写接口文档，然后前后端就可以按照约定去进行协同开发。

接口文档的管理和编辑有多种方式：

有的团队习惯用wiki或者在线文档去编写接口文档；

有的团队喜欢用专业的接口文档工具，比如：Swagger、Yapi等去生成接口文档。

我们公司习惯于用丝袜哥（swagger）去维护接口文档。

swagger 对多种编程语言/框架 都提供了良好的接入方案。就拿Java来说，只需要引入相应的jar包，在接口上添加相应的api文档注解，就可以自动生成网页版的接口文档。

并且还可以通过接口文档去对接口进行调试，大大提高了开发效率。

但不管是以何种方式去管理和维护接口文档，接口文档都是必须要有的。

测试接口文档可以参考以下测试点：

确保开发必须提供接口文档。如果开发没有写接口文档的习惯，应push开发去写接口文档。

检查接口文档的格式内容等是否完备，包括：URL、请求方法、Header、入参、返回值、示例Demo等。

检查接口设计是否符合公司规范。包括接口命名、接口格式、字段命名、字段类型、响应状态码、接口容错、字段是否冗余、接口是否鉴权、是否做版本区分等等。

当后端开发完成接口的开发工作时，我们就可以提前开始对接口进行初步测试了。

步骤如下：

把后端代码部署到测试环境上。

通过postman或swagger去对接口文档提到的接口进行测试。

第四步：前端接口测试&Mock数据（接口层面的测试）

前面的步骤只是利用测试工具去发起网络请求，来模拟接口调用。

但在真实的场景下，搜索网关的接口实际上是提供给 APP/WEB/小程序 进行调用的。

我们同样也需要关注前端调用过程是否是正常的。（需要等待前端开发完毕，才能介入测试）

可以利用Charles来对前端发送的请求进行抓包，

验证前端调用接口的传参是否正确；

验证后端的接口响应是否符合预期；

前端拿到数据之后，交互和UI展示是否正确。

当有些数据有多种状态，并且数据比较难以构造时，我们可以通过Mock数据去进行测试。

常见的Mock数据的方式有：

用 Fiddler 或者 Charles 去篡改请求和响应。

如果是PHP或者Python等动态语言，可以直接在后端代码里面去更改条件。

数据库中去修改数据。

用专业的Mock工具去构造数据，如：EasyMock、TestableMock、Mockjs等。

比较快速的方式，当然是直接用Charles去模拟。

如果说只是改少量的响应数据，比如说：改变一个标签下发的文案，看看前端的展示。这种情形就非常适合用 Charles 去模拟数据。

但是 Charles 模拟也有一个弊病，那就是假如遇到接口下发的数据结构比较复杂，涉及到多个字段的变更，用 Charles 去 Mock 数据就比较麻烦。

第五步：后端接口测试&业务逻辑覆盖（看日志、看代码）

看日志

业务测试过程中，我们需要时刻关注后端日志状态。

有时候接口响应数据是正常的，但是后端日志可能正在报错，

比如：

搜索结果页返回空数组是常见现象，一般代表搜索关键词没有召回任何商品。

但是臻叔有一次测试过程中，发现同一个关键词，在同样的条件下，有时召回0个商品，有时召回多个商品。

一开始觉得很蹊跷，后来一查看后端日志，才发现召回商品的时候超时了。

看代码

推荐大家在做接口测试的时候，一定要去阅读开发的源码。

阅读源码可以对业务逻辑实现了解更加深入。

另外，有些条件，在手工测试中很难模拟出来，但是通过阅读源码，甚至单元测试，就能够轻松的模拟出来。

阅读源码还有个好处就是，对开发起到一个约束作用，因为代码是公开的，如果从代码层面发现很多Bug的话，开发的面子也过不去。

关于阅读源码，我们可以把代码拉到本地，用IDEA等工具去查看源码。

如果代码量很大怎么办？

告诉大家一个小诀窍：当开发提交代码之后，我们可以在Gitlab上看他的Commit记录，或者将他的开发分支和生产环境的分支做个diff，这样就能知道他改了哪些地方。

此外，还有2个工具推荐：

java覆盖率工具 jacoco，这里可以用来统计代码覆盖率。

感兴趣可以参考：https://github.com/jacoco/jacoco

代码静态扫描 sonar，主要是用来检测代码编写是否规范。

感兴趣可以参考：http://www.sonar.org.cn/

第六步：接口性能调优（Arthas）

这里再给大家看一个真实工作中的案例：

排查过程：

（1）先在APP上尝试复现

（2）抓包看接口返回响应时间，一次请求居然花费了3.69s

（3）通过Arthas的trace逐步去排查接口响应慢的原因：

进入Arthas命令行

trace 接口调用的方法

最后发现可能是调用价格标签的时候很慢。

后来终于找到了原因：

调用依赖的服务的某个方法在测试环境中已经不维护了，但是代码存在bug，还会继续调用，导致调用超时。

经过优化后，搜索网关响应速度从 3s 缩短到 300ms 左右。

第七步：接口异常机制（Chaosblade）

因为接口依赖的服务很多，经常需要调用其他接口。假如依赖的服务出现了异常，我们就需要考虑我们的接口是不是做了容错处理，或者是降级处理。

可以用Chaosblade去注入异常。（非必须，但有更好）

Chaosblade是阿里开源的混沌工程工具，感兴趣的可以去了解下：https://chaosblade.io/docs/

第八步：接口版本控制&diffy

一般接口都会区分版本，如果接口不是很规范，或者改了一些通用的逻辑，这个时候就需要对老版本进行一次回归测试。

最笨的方法就是拿新老版本的两个app对比测试。我们也可以用diffy这个工具来做回归测试。

diffy是推特开源的一款接口数据对比工具，这里是Github地址 ：twitter-archive/diffy

第九步：开始做接口自动化

接口自动化一般常用于进行线上巡检回归、提测冒烟测试等场景。

实现接口自动化，常见有几种方式：

（1）coding：

python+pytest+requests，臻叔公司目前采用这种方式去做。

（小而美，方便定制化）

pytest生成的测试报告

（2）postman+newman

（利用工具，效率最高，但是不太方便定制化）

感兴趣可以参考：https://www.npmjs.com/package/newman#newmanrunoptions-object--callback-function--run-eventemitter

（3）流量录制与回放

（低代码实现，但是实现成本颇高）

常用的流量录制与回放工具：gor

上述就是小编为大家整理的如何设计接口测试用例？接口测试实战案例分享。

国内(北京、上海、广州、深圳、成都、重庆、杭州、西安、武汉、苏州、郑州、南京、天津、长沙、东莞、宁波、佛山、合肥、青岛)eolink软件分析、比较及推荐。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。