接口测试必知常见问题深入理解接口测试

业务稳定为啥要测接口？

为了回归。而且接口有个好处，定位问题简单，一出问题基本都是服务端的问题，而且肯定是和这个接口相关的代码，不用花时间再去抓包->分析

对于page的接口测试，测试点如何设计？

第一页、中间页、最后一页，那么如何获取到的页数就是最后一页？让开发协助写获取最后一页的接口，测试来调用。

接口测试是否成功的校验点是？

从reponse中是否包含指定内容开始。

扩展到数据库的校验

接口测试的用例验证点？

ADD/MOD:

字段边界值，最大最小字符，为空以及格式校验

重复提交相同的参数

权限校验

业务逻辑

DEL:

删除不存在的

删除无权限删除的

删除后再添加相同的

重复删除

LST:

为空时获取

数量大时获取

分页

获取无权限获取的

接口测试的本质？

通过测试参数的排列组合验证返回值/数据库变更是否符合预期，从而确定接口相关代码是否正确。

接口测试的优点？

简单

稳定

效率

可信

时间

简单的一个接口测试的步骤？

开始编写前置条件、入参、返回参数、预期结果等测试相关的信息

运用工具去执行测试用例或者执行自己写的脚本

校验返回结果是否正确

接口测试是什么？

接口测试是功能测试不可或缺的一部分，抛开了前段的逻辑和限制对于服务器的功能进行了完整的测试，一个好的功能测试人员应该充分了解所测系统有多少个接口，接口的核心参数和响应，完成对接口代码的走读，接口有没有白名单，防刷，内部接口和外部接口等。

接口测试的作用是什么？

从接口测发起的测试弥补了界面测试的遗漏点，能将接口测试纳入功能测试的一部分，测试的完整性得到了很大的提高，界面测试起码遗漏了如下的信息：

服务器端接口参数校验

接口是否存在安全漏洞或者逻辑漏洞，实时性，防刷

接口是否存在越权的可能

接口测试注意点？

【第一步：看】

看接口的请求参数构造是否合理

看所传参数有无敏感参数需要加密传输。比如说用户userid、password等数据如果不使用https进行通信，最好使用加密的方式进行传输，这也是业界通用的标准，并且入库也需是加密的

看所测服务的代码。第一看对于传入参数的校验部分，第二是看整体逻辑处理部分。举个例子，大家在测试过程中经过会遇到如五所示，有多个必填或者选填项、输入条件特别多、每个输入条件都需要做校验。有些测试人员会对此类问题用正交的方式一项一项测试，这类效率太慢。个人认为效率最高的方式为对于接口参数的校验，以静态测试为主，review代码的过滤条件，页面控件实际输入测试为辅助。很多的输入界面，其中判空处理是必须的。开发代码中常用的一个判空函数是i。首先界面类查找是否有控件对象未使用该函数，若未使用肯定存在bug；其次即使使用这个函数也是有bug，该函数并未完全满足需求。这个函数漏掉了输入空格的情况,正确的做法是i。那么如果在全工程内，搜索isempty,对比发现bug，最后可以选择一个输入项进行测试，通过后所有输入控间判空测试均告完毕。

看接口的返回体是否返回一些不必要的敏感信息，返回格式是否合理

【第二步：改】

请求体中参数的常规修改。常规修改就是通用的边界值方法，如极大值、极小值、极长值、null、空。未对这些值做校验的后果可大可小。小的方面仅仅是服务器throw一个统一的错误提示，如网络错误等。中等一点的为前端页面会返回如六形式的内部错误，这种错误会泄露一些敏感信息。严重的后果可能就是影响现有或者后续业务，使得业务往不可控的方向进行。

与业务强相关的参数修改。

请求消息体中的字段修改。有些人习惯在cookie中传输大量的信息，也是值得关注的测试点。

接口测试的主要关注点？

业务逻辑

响应结构

数据格式

测试的原则？

基础配置，如域名，环境配置等，单独文件配置，方便不同环境测试，脚本维护

明确接口实现什么样的功能，实际需要什么样的功能。是否一致

接口测试数据太多，用数据驱动模式更有层次，且易维护

要众多用例中选出冒烟测试用例及可用于性能测试的用例

先单接口测试，在多接口测试

测试完成后，需要清理脏数据

为什么选择JMeter做为接口测试的技术方案？

基于配置实现接口测试的自动化，免代码开发丰富的断言能力支持，返回值校验，数据库比对校验比较好的支持流程控制比较完善的结果监听和Jenkins易于集成，集成后支持接口性能趋势的查看能力非标准协议或者对接方有特殊安全处理的情况可以使用JavaSample的方式处理

接口测试的流程？

类似于功能测试，需求讨论--评审需求—确定需求—产出接口定义—根据需求文档及接口定义设计测试用例—评审用例—执行测试

需求的频繁变化，做接口测试的测试人员应该如何应对？

个人觉得此在于团队开发的流程，团队之间的沟通和测试人员的警觉性。

在开发阶段，需求的变更是一件极为频繁和正常的事情，对于此点团队中的任何一个人都应该正确的心态来面对，团队需要规范的开发流程，良好的沟通方式，测试人员更需要及时跟进软件进度，和开发人员并进齐行，测试与开发需要相对独立的工作环境，总结而言为知己知彼，亦敌亦友。

接口测试的原理？

通过测试程序模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做出处理然后再把应答报文发送给客户端，客户端接收应答报文这一过程

接口测试的范围？

新增接口的测试；

新增业务功能接口测试；

整个服务器的接口测试，所需测试接口一次增多，在测试时间足够的条件下，当然需要对所有接口进行测试用例的设计，如果测试较短的情况下，则应该首先根据用户的典型操作对测试接口进行优先级划分，对调用平凡接口需要优先进行测试。

接口测试策略？

接口设计检查、接口依赖关系检查、接口输入/输出验证条件判断接口条件判断的验证：要对判断条件进行验证，则需要知道接口是根据哪些输入项来进行判断的异常数据的响应：对于密码重置接口，用户ID不存在、不合法，邮箱输入格式错误、用户邮箱信息不存在或未激活就是测试时需要考虑的异常场景，设计这类输入值，并且检查接口返回的响应码，响应码的正确才能保证客户端根据异常情况来显示相应的提示信息。数据查询接口除了像条件判断接口之外根据请求参数设计合法/不合法/正常/异常测试值之外，还需要结合数据库来对查询结果进行验证。是否根据正确的关联数据表进行查询验证查询结果是否从数据表中正确项中获取，涉及到多表联合查询时，不同表中的相同项设计不同测试数据来进行验证。修改查询结果在数据表中对应项中的数据，使其为空值或客户端相应项的范围值的最大和最小值，查看接口输出是否正确。逻辑运算接口

后端接口都测试什么？

回答这个问题，我们可以从接口测试活动内容的角度下手，看一下面这张，基本反应了当前我们项目后端接口测试的主要内容：