随着开发模式的迭代更新，前后端分离已不是新的概念，现在大部分的项目都采用这种开发模式；当我们拿到待测试需求时，可能后端已开发完成，但前端还未完成，我们需要进行接口验证，那如何进行接口测试？就这个话题，进行一个探讨，我们先去做接口测试，从结果上来分析到底需不需要做接口测试，测试哪些内容等等。开始之前，先虚拟一个产品需求：

需求描述：

假设我们要做一个全新的后台项目，商品CMS管理平台（这里抛去复杂逻辑，因为需求无限拓展下去，势必大家对需求认知产生分歧，从而对测试内容产生分歧）。第一期的功能，商家用户可以在平台上进行商品的创建，编辑，删除，查询，上下架等操作；运营用户可以审核商家的商品；我们来简单描述其中一个功能点内容：用户点击添加按钮，跳转到商品创建页面，用户需填写商品名称、商品价格、商品描述，类目信息，商品图片，商品库存等信息，以上字段皆必填，且每个字段的限制内容xxx；商品创建完成后，提交到运营进行审核，运营可根据实际情况审批提交的商品；需求文档同时提供了商品的创建页面，商品编辑页面，商品列表页，等页面样式稿设计。

计划和目标：

在动手之前，设定计划和目标，支撑保证质量的过程

计划：

1、需求分析； 

2、接口测试用例设计；

3、测试用例评审；

4、测试准备；

5、测试执行。

目标：接口质量达成

需求分析：

需求分析是所有执行过程中，最难的一个环节，因为有很多漏测都是因为我们事先没有想到，或者没有分析到；在后续过程中，出现和发现的问题（包括测试计划、上线回归方案制订）多多少少都是因为需求分析不全面所导致；当然，新手同学，因为各方面原因肯定做不到全面，不要想着一口气吃个胖子；回过头来说，如果做得好，在需求评审时，可以提出需求的不足，这样把问题扼杀在需求阶段，测试时必然会轻松；当然你也会发现，有些产品的文档漏洞百出，如果遇到这样的文档，把控质量更是难上加难。

1.功能点划分

根据需求文档，和产品同学的语言描述，需求核心是解决什么问题？

商品CMS管理后台，为商家，运营提供商品管理功能

我们接着做功能点的详细划分：

我们从角色，角色行为（可以理解为谁，谁做了什么事）对功能做个划分；其实准确的应该叫对象，对象行为，至于为什么要从这个角度入手，因为我们需要符合开发的思维习惯，确切地说是抽象业务的思维，找到所抽象的对象，以及对象的属性和行为，这些东西就是我们测试用例的具体验证点。

功能点的划分也让我们得到了另一块重要的内容：显式需求可度量指标！我们在定制计划和目标时，接口的目标是：接口质量达成。那我们就需要质量度量指标，也就是这里的7个功能点，作为分母，便于日后度量，当然仅仅从需求文档中获得的这些明确的度量指标是不够的，质量的把控还需要另外一个关键指标：隐式需求指标。

接口质量=显式需求质量+隐式需求质量

简单地做个解释，显示需求，这个很好理解，就是需求文档中已明确说明的功能点；隐式需求：为了达成某些功能，借助工具或者其功能实现这些功能，这些隐藏但是又客观存在的需求，就是隐式需求。用当前需求举例子：登录和权限。开始我们说过，需求是全新的，肯定会涉及到登录后台的问题，如果在大公司里，会有一套统一的登录系统，这个时候，我们对于不同的登录实现，会采取不同的测试手段。回过头来再看需求文档中，却发现没有对这两块内容做解释，当然有的产品同学会详细介绍权限这一块的内容，不管怎样，这些隐式需求都不会出现在需求文档中（下文中我会对权限做一个详细的需求分析，和测试设计）。于是我们有了明确的需求和隐藏的需求这两个概念。

需求分析过程中，一个重要步骤，就是寻找隐式需求，这个过程是最难的，对于新手及其不友好，因为有些隐式需求完全在我们认知之外，但是需求不给我们学习的时间，等我们了解了隐式需求，知道该怎么测试了，这时需求可能已经上线了，但我们可能都没有去覆盖；

先抛不讲，这时如果让你去挖掘这个隐式需求，你会从哪些方面考虑？可以把自己想到的隐式需求做个记录，看看和我下面的内容是否一致，或者写下你的思路。

1.1隐式需求挖掘

思路吗？这个很简单，前面我们已经说了隐式需求的定义：“为了达成某些功能，借助工具或者其功能实现这些功能，这些隐藏但是又客观存在的需求，就是隐式需求”。我们当然要从显式需求上挖掘，看看达成这些功能点，需要什么工具，或者其他什么协助？

我们先抽象这里面的核心对象：商品！商品的属性：商品名称、商品价格、商品描述、类目信息、商品图片、商品库存、商品状态；商品的行为：添加、编辑、删除、上下架、审核、查询，虽然查询不严格属于商品的行为，但是还是把它放到商品行为中，方便归类。从商品的行为汇集到接口层面，我们可以分析出本次需求对前端会提供这样几个接口：

然后我们脱离需求本身，从提供接口的工具了解一些隐式需求：服务端通过spring框架帮我们提供了以上几个接口，那程序员在提供这些接口时，都做了哪些工作？

1）定义统一返回体，我们都知道，多个不同的接口传入正确参数时，返回的结构体是一致的，正确的是同一个code，错误的有很多不同的code定义，比如：

2）定义统一异常拦截，因为spring框架，对httpstatus定义的异常返回，对我们来说理解比较困难，程序员需要把这些异常，定义成统一的返回内容，供测试或者其他同学方便阅读，比如：

统一处理成：

3）登录，所有的接口必须登录过后才能正常请求；那么登录在接口中到底是什么？是不是只有在前端页面上才可以登录？只测试接口，该怎么登录呢？其实这里我们需要了解登录的原理，接口是如何处理登录的？简单地解释一下：登录的过程，其实是用户使用账号密码，去请求登录接口，登录接口会在返回头中放置一个用户身份唯一标识，然后下次请求，在请求头中加入这个唯一标识即可，服务端在接受http请求时，会通过拦截器处理request header 中的信息，来判断当前请求是否登录。好了知道这些信息后，我们需要在测试执行前准备测试数据，当前登录要配合权限一起使用，我们接着向下探讨。

4）权限处理，后台系统是怎么判断，当前登录的用户是管理员，还是商家，还是运营人员？这里的实现原理和登录有些类似，服务端在获取当前用户后，会查询权限表中，当前用户是什么权限，判断他是否可以继续下面的接口操作。

登录和权限非常重要，会引出我们的测试数据准备，在测试用例评审过之后，我们需要准备测试数据，特别是商家用户、运营用户、和管理员用户（需求中没有提及该角色，可以先忽略）都需要提前准备测试账号；另一方面就是知道了有拦截器的概念，我们不需要每个接口都去测试是否做了登录逻辑判断，因为拦截器可以指定拦截想要拦截的接口，这使得我们的测试更加准确。

5）统一日志处理

看到日志这里你或许会产生疑问，怎么日志也需要测试么？这个也是需要的，回顾我们发生线上问题的时候，会发现排查线上问题的第一手段就是日志，假如我们的日志，打得不标准，或者关键信息没有打出来，势必会影响线上问题的修复效率才生影响，关于日志这方面的测试，可以算是程序可排查性，可恢复性的测试；

好了，我们暂时从工具方面（和开发沟通）得到这些隐式需求，当然不止这些，那至于为什么我们要把这些需求作为隐式需求，也是有原因的，前面说过由于项目是首个项目，后台前端都是全新的，如果你不在这个时候把控这些质量，如果在后续的过程中，再去修改，就会发现，改动的成本非常的大，可能回归的范围也非常的巨大，所以针对每个需求所处的阶段、特性，我们都会去做采取不同的手段去执行需求分析；由于篇幅原因，我们就不再举例子说明了。

2.接口测试用例设计

有了以上显式需求和隐式需求，我们开始设计测试用例，描述用例的话术根据每个人的习惯编写即可，把核心的验证内容描述清楚，评审时，大家能看懂就可以。先来看显式需求测试用例（由于编写软件问题，有些场景只是简单描述了一下，为了能在一个屏幕内截屏展示下，如果你是新手测试同学，还是描述清楚较好）：

说下思路：我这里习惯把每一个功能点，按照正常和异常进行分类，先保证正常流程，然后会根据这条正常的用例，设计多条异常的用例。但是无论怎么分类，只要最后面的验证点一致即可。

关于查询的用例，我在这里补充一下，除了分页查询，列表查询外，还有一个单体查询，就是查询单个商品，只要我们传入正确的id，返回整个商品对象，对象内属性无缺失即可。异常场景可以传入一个不存在的id，看下返回是否报错。

说下列表，这里唯一要注意的就是排序，如果需求文档有明确指出是如何排序的，我们按照文档设计用例即可，但是多数产品都会遗漏该功能点，其实这个验证点，来自“列表”的特性，不了解列表特性的人不知道也不为过。另一个就是分页，如果你是新手，可能只从接口返回字段上看，你并不知道分页，到底需要接口吐出哪些字段，这时需要结合接口文档进行比较。（可能会遇到这样的问题，我们在测试过程中，并不知道后端提供的返回参数是否能满足前端的使用要求，假如分页返回了5个字段，接口文档和实际请求接口时你也看到了5个字段，但是前端做分页时需要6个参数，这个属于正常情况）

异常的用例设计，一方面来自于异常流程场景，另一方面来自于构成这个对象的每一个属性的异常，比如“商品名称”字段，既然是String类型，就会有长短限制，空限制等等，依次对每一个属性进行异常测试，类推递增，形成基础的用例。

这里比较难设计的，是异常的有效性，你会发现就某些对象属性，有很多条异常场景，我们模糊不清，原因是我们不了解java中数据类型，哪些可以为数字类型，哪些可以为null，哪些可以为’'。所以在设计之初，会不分字段类型，比如String类型的字段，会设计异常入参传入纯数字123，这些即为无效的异常，因为这样传参，会返回Http Status400入参异常，这就是一条无效的异常用例，但是返回400也是我们的一个测试点，只不过它不属于当下这个场景，属于隐式需求的测试用例，下面我们来看隐式需求用例的设计：

每条用例最后的验证点，没有文字描述得很清楚，我这里只是为了说明思路。

直到目前为止你会发现我们每一条用例，产生的原因都是有根据的，不会像探索性测试一样，漫无目的的测试；

我们把显式需求和隐式需求的用例合并成一份用例，就可以拿去用例评审了。

我们要切记勿犯以下错误：

1）测试用例生搬硬套产品需求文档

2）明确测试点，比如不要这样去描述：商品创建接口，返回内容正确，这里的验证点需要明确知道，是哪一个字段，操作步骤是哪个入参不正确，等等。

到了这里接口测试最重要的流程已经过半了，我们需要停下来总结一下；你会发现接口层面的用例真正体现出需求文档的内容基本上很少，除了最后的验证点，我们执行步骤的分类，和需求关系很小，多数是接口的实现逻辑，了解接口的实现原理，才去这样设计的；经历过多个需求的接口测试，你会发现，在接口层面的测试，用例都大致相同，这是不是在追求效能的今天，可以对用例进行最大程度的复用，关于这点，可以关注后面的文章，我们也会对平台建设方面，对用例复用提出一种新的见解。回过头来，因为我们不是做黑盒测试，既然是接口测试，就需要测试同学具备基础能力，这样才能保证质量。

3.测试用例评审

我们拿到一份庞大的用例，可以在评审会上跟研发、产品掰扯很长时间，因为有些细节的地方还需要一一确认，比如每个属性在异常时的报错提示，需求文档是否给出，提示是否合理等等，当然这要在大的思路正确的前提下，才去纠结这些细节。另一方面别忘了我们还需要确认些重要的内容，测试同学作为小白，并不了解我们挖掘的这些隐式需求是否全面，我们还需要跟研发同学确认是否还有其他的隐式需求。我们还需要继续补充隐式需求相关的测试用例，还有就是，上面提及我们不确定对象属性的异常到底有哪些，测试设计的异常用例是否是有效异常？我们都需要和研发去沟通。

总结一下用例评审：

需求要解决的核心问题，确认后，作为最终上线验收的标准，需要跟产品同学保持一致。不要功能都开发了，但是没有解决用户的问题，本末倒置。（团队成员所做的事情方向和目标是一致的，大家以这个为最终检验标准，可上线）

显示需求的确认，把文档中明确内容，转换成测试用例，只需简单确认验证即可。注意这里不是生搬硬套产品需求文档，而是要找出“明确”的验证点。

隐式需求的确认和探讨，我们除了把自己想到的隐式需求跟研发确认外，还需要让研发帮忙补充更多的隐式需求。

细节的“拍板”，异常的提示，异常的有效性，需要达成明确的结果。

4.测试准备

对于接口测试来说，测试数据的准备，可以加快我们的测试执行，记得提前申请一下对应角色的账号。另外我们还需要一款趁手的接口测试工具，假如公司已有，我们直接使用即可。postman是非常不错的工具，简单方便快捷，推荐使用，这里我就不详细讲解工具的使用了。

5.测试执行

简单地来说接口测试就是传入一些参数，验证接口出参的正确性，这里我们用http请求举例子，在动手之前，我们使用工具帮我们完成：请求url，入参，请求头的构建，发送请求以及返回体接收工作，校验返回体中的内容，就是接口测试执行校验结果的主要内容。

作者：测试界的飘柔

原文链接：https://blog.csdn.net/m0_67695717/article/details/127271896