本文章使用王者荣耀游戏接口、企业微信接口的展示结合理论知识，讲解什么是接口测试、接口测试理论、疑问收录与扩展相关知识点的知识学院，快来一起看看吧~
接口测试基础理论
接口测试：接口测试是测试系统组件间接口的一种测试，主要用于测试系统与外部其他系统之间的接口，以及系统内部各个子模块之间的接口。–百度百科 接口原理：模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做判断并将最终结果返回至客户端，客户端再次接收返回结果并应答的过程。 检查重点：测试的重点是检查接口参数传递、接口功能实现、输出结果的正确性，以及对各类异常情况容错处理的完整性与合理性。 接口类型：内部接口及外部接口，内部接口为程序开发的接口，方法之间或模块之间的调用，外部接口为外部接入调用接口，例如王者荣耀的微信登录、支付宝的支付功能等，均是外部接口。 接口分类：webservice接口及httpapi接口，webService接口使用soap协议传输，通过http进行传输，是HTTPPOST专用版本之遵循一种特殊的xml消息格式，httpapi接口使用http协议，通过路径来区分调用的方法，通过key-value请求，返回报文通常为json。 接口本质：接口的本质上是一个公开的函数类，进行数据传输的发送与接收，可以理解成一条通道，在发送get或post请求方式时，实际上就是从通道进行发送、在由服务器从通道返回数据。 测试范围：接口功能、接口性能、接口稳定性以及接口安全性等。
为什么要进行接口测试
稳固代码底层：在初期阶段的开发时，业务层面无法检测到底层内容，代码底层不稳固牢靠，故此需要对底层内容进行接口测试，否则底层代码错误可能会引发更多外部系统或调用模块的错误。 低成本高效益：初期开发且资源未设计完成时，提前介入测试工作提前暴露问题，符合质量前移理念，能够明显有效的控制测试成本，且接口可进行自动化持续集成，故此会有更高的长期收益体现。 测试范围更广：接口测试大部分是从用户的角度而言对系统接口进行全方面的检查测试，无论是软件项目还是游戏项目，接口测试均会覆盖到部分业务逻辑，故此在进行接口测试时也同样能够辅助业务测试。 提高接口安全：上述提到了接口安全的测试范围，在接口安全方面考虑，客户端进行的限制条件容易避开绕过，同样需要测试服务端的限制，涉及到部分隐私数据时还需要验证接口的加密传输，例如用户密码、身份证、银行卡信息等。 保障系统稳固：进行接口测试能够保障系统间的数据传输以及容错，从而提高系统层面的稳定性。
总结： 接口测试的优点：提高整体测试效率，降低研发测试的成本，综合性提升产品质量、降低后续维护资源。
如何开展接口测试
接口开展方式
业务层面：
常用接口测试工具：Postman、Jmeter、SoupUI等。 接口测试工具原理：通过接口测试工具模拟请求与数据接收，实现数据传输。
代码层面：
接口自动化测试：通过代码实现，发送请求通过代码断言判断接口正确性。
ps：会在后续自动化的文章教学接口自动化框架搭建、持续集成等内容。
接口测试流程
在真实的项目工作中，接口测试的流程大致分为以下几个步骤：
公司有接口测试需求或测试人员收到接口测试任务时开始正式介入接口测试的流程阶段。 由开发人员提供接口文档，测试人员拿到接口文档后先行熟悉需求文档，了解各个接口的功能以及相关信息。 当测试人员熟悉需求文档完成后，开始介入测试用例的编写，与业务测试相同，需要考虑到正常、异常的请求参数、还需要考虑到对应的响应报文数据的正确性。 最后可以通过接口测试工具进行用例执行，可以选用Postman、Jmeter等，举例：Jmeter可以先建立线程组、添加http请求，写好相关的请求地址、端口、请求参数，并设置好参数化，添加断言，最后添加结果树再运行，Postman与Jmeter原理是一样的，只是操作方式不同，这里不过多阐述，有兴趣的朋友可以网上查找下相关的工具使用说明与资料。 当运行完成后，检查接口是否通过，如果接口测试不通过，第一步先检查请求方式、参数等信息是否有错误，如果无错误的情况下，检查下网络环境，如果都没有问题，可能是接口本身存在问题，先以自己的认知进行判断是前端还是后端问题，判断完成后提单给开发并附上相关日志信息直至全部确认完成。值得一提的是，在业务的接口测试过程中更多的会关注失败的接口，在接口自动化的过程中也同样需要关注测试通过的接口，以用于质量提升、报告输出等方面。
接口测试需求
一份接口需求文档，核心要素主要包括以下内容： 文档封面：封面为xx公司接口需求文档，有公司名称及公司logo并注明为保密文件、需求文档的版本号、文档创建日期等。 修订记录：通常为表格形式，其中至少包括修订的版本及日期、修订说明、修订人、审核时间以及审核人等。 接口说明：接口访问地址格式、接口地址举例、返回结果说明等。 接口信息：模块名称、子模块、业务描述、接口名称、请求方法、请求格式、响应格式、请求参数、结果说明、返回示例等。
简单介绍接口信息中对应信息所产出的内容：
模块名称：登录、支付等子模块名：微信登录、QQ登录、手机号登录业务描述：简洁概括接口的功能接口名称：/login/wechat，/payment/personal请求方法：GET/POST等请求格式：application/x-www-form-urlencoded响应格式：application/json请求参数：手机号、登录密码结果说明：参数内容、变量名、类型，返回状态码等返回示例：返回成功的举例，下方4接口演示中有片体现 ps：并非所有的接口文档都很规范，绝大多数的需求文档中不会有如此详细的信息说明，具体情况大家依据公司接口文档为准即可。
接口演示
笔者在这里进行一些接口的演示，帮助大家了解接口、熟悉接口需求和说明~
王者荣耀接口展示如下：
英雄列表：
请求方式：GET
输入参数：无
输出参数：
| [] | list | 英雄列表 |
| ename | int | 英雄id |
| cname | str | 中文名称 |
| title | str | 皮肤名称 |
| pay_type | int | 支付类型 |
| new_type | int | 新类型() |
| hero_type | int | 英雄主类型（坦克、法师） |
| hero_type2 | int | 第二类型（辅助、坦克） |
| skin_name | str | 准备属性表述 |
返回结果： 企业微信接口展示如下：
文件上传接口：
素材上传得到media_id，该media_id仅三天内有效media_id只能是对应上传文件的机器人可以使用
请求方式：POST接口地址：https://qyapweixiqq.com/cgi-bin/webhook/upload_media?key=KEY&type=TYPE使用multipart/form-data
POST上传文件，文件标识名为”media”
参数说明：
| key | 是 | 调用接口凭证, 机器人webhookurl中的key参数 |
| type | 是 | 固定传file |
POST的请求包中，form-data中媒体文件标识，应包含有filename、filelength、content-type等信息
filename标识文件展示的名称。比如，使用该media_id发消息时，展示的文件名由该字段控制
请求示例：POSThttps://qyapweixiqq.com/cgi-bin/webhook/upload_media?key=693a91f6-7xxx-4bc4-97a0-0ec2sifa5aaa&type=fileHTTP/1Content-Type:multipart/form-data;boundary=-------------------------acebdf13572468Content-Length:220---------------------------acebdf13572468Content-Disposition:form-data;name=“media”;filename=“wewortxt”;filelength=6Content-Type:application/octet-streammytext---------------------------acebdf13572468–
返回数据：{“errcode”:44001,“errmsg”:“emptymediadata,hint:[1638347756075722279950035],fromip:18113153,moreinfoathttps://opeworweixiqq.com/devtool/query?e=44001”}
接口测试用例设计
用例设计格式：
用例序号：项目名称_模块名称_序号接口模块：对应的接口模块，例如英雄列表、召唤师技能，企业微信的登录模块、语音模块等请求方式：通常请求方式为GET、POST接口地址：通常有固定的地址格式便于接口自动化测试接口参数输入：部分接口不需要接口参数的输入，部分存在接口输入，如果有，填写即可
用例设计重点及关注点：
发送给服务器的请求数据是否正确；服务器返回给客户端的数据是否与需求一致，符合预期；查看数据库中接口是否实现对应功能；接口的响应时间是否符合需求文档要求
接口用例设计考虑的范围：
业务功能：功能是否实现业务规则：定义的描述是否符合预期请求参数：参数的长短、大小、格式等异常场景：传参异常、操作异常、服务异常等数据传输：数据传输结果的正确性接口性能：接口性能的正确，例如并发等接口安全：如支付类、充值接口的数据篡改等 ps：在以上范围内还需要考虑接口的用例覆盖率及代码覆盖率，至少符合预期
后端接口测试内容
所谓的接口测试，后端接口都测试什么内容？下面的片会给你一定的帮助：
知识学院
扩展知识收录解答
GET与POST的区别
GET请求用来获取数据资源，POST请求用来创建、发送数据资源。 GET无请求主体，POST有请求主体。 GET有幂等性，PSOT非幂等。 GET可以进行缓存，POST一般不缓存。 GET可存放历史记录和书签，POST不可存放。 POST相对GET更加安全 GET请求有长度限制、POST几乎无限制。
补充说明： GET请求：请求的数据会附加在URL后，以“?”分割URL以及传输的数据，多个参数会使用“&”进行连接，URL采用的是ASCLL编码格式，而非Unicode的编码格式，所有的非ASCLL编码的字符都需要在编码后进行传输。 POST请求：POST请求会把请求的数据放在HTTP的Body数据中，形式分为两种，一种是参数名与参数值，一种是键值对，普遍的JSON是通用型的格式。 HTTP没有对传输的数据大小进行限制，也没有对URL的长度进行限制，而我们所说的GET请求的长度限制实际上是特定的浏览器和服务器对URL进行的长度限制，限制为2083Byte。POST并非通过URL传值，理论上就不会受到大小限制，但理论终究是理论，实际上服务器还是会对POST所提交的数据进行大小限制，例如IISApache等，它们均有独特的配置规则。 POST方式比GET的安全性高的原因主要是因为GET能够在地址栏直接看到请求的数据，采用GET传输可能会受到CSRF跨站请求伪造攻击。而POST的请求方式需要通过破解、拦截方式才能够获取到数据，例如常见的抓包工具获取，从而使用POST请求方式相对于使用GET请求方式安全度更高
HTTP状态码详解
HTTP状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型。响应分为五类：信息响应(100–19，成功响应(200–29，重定向(300–39，客户端错误(400–49和服务器错误(500–59-↓文本表格摘自菜鸟教程：
| 1** | 信息，服务器收到请求，需要请求者继续执行操作 |
| 2** | 成功，操作被成功接收并处理 |
| 3** | 重定向，需要进一步的操作以完成请求 |
| 4** | 客户端错误，请求包含语法错误或无法完成请求 |
| 5** | 服务器错误，服务器在处理请求的过程中发生了错误 |
| 100 | Continue | 继续。客户端应继续其请求 |
| 101 | Switching Protocols | 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议 |
| 200 | OK | 请求成功。一般用于GET与POST请求 |
| 201 | Created | 已创建。成功请求并创建了新的资源 |
| 202 | Accepted | 已接受。已经接受请求，但未处理完成 |
| 203 | Non-Authoritative Information | 非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本 |
| 204 | No Content | 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档 |
| 205 | Reset Content | 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域 |
| 206 | Partial Content | 部分内容。服务器成功处理了部分GET请求 |
| 300 | Multiple Choices | 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择 |
| 301 | Moved Permanently | 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替 |
| 302 | Found | 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI |
| 303 | See Other | 查看其它地址。与301类似。使用GET和POST请求查看 |
| 304 | Not Modified | 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 |
| 305 | Use Proxy | 使用代理。所请求的资源必须通过代理访问 |
| 306 | Unused | 已经被废弃的HTTP状态码 |
| 307 | Temporary Redirect | 临时重定向。与302类似。使用GET请求重定向 |
| 400 | Bad Request | 客户端请求的语法错误，服务器无法理解 |
| 401 | Unauthorized | 请求要求用户的身份认证 |
| 402 | Payment Required | 保留，将来使用 |
| 403 | Forbidden | 服务器理解请求客户端的请求，但是拒绝执行此请求 |
| 404 | Not Found | 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置'您所请求的资源无法找到'的个性页面 |
| 405 | Method Not Allowed | 客户端请求中的方法被禁止 |
| 406 | Not Acceptable | 服务器无法根据客户端请求的内容特性完成请求 |
| 407 | Proxy Authentication Required | 请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权 |
| 408 | Request Time-out | 服务器等待客户端发送的请求时间过长，超时 |
| 409 | Conflict | 服务器完成客户端的 PUT 请求时可能返回此代码，服务器处理请求时发生了冲突 |
| 410 | Gone | 客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置 |
| 411 | Length Required | 服务器无法处理客户端发送的不带Content-Length的请求信息 |
| 412 | Precondition Failed | 继续。客户端应继续其请求 |
| 413 | Request Entity Too Large | 由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息 |
| 414 | Request-URI Too Large | 请求的URI过长（URI通常为网址），服务器无法处理 |
| 415 | Unsupported Media Type | 服务器无法处理请求附带的媒体格式 |
| 416 | Requested range not satisfiable | 客户端请求的范围无效 |
| 417 | Expectation Failed | 服务器无法满足Expect的请求头信息 |
| 500 | Internal Server Error | 服务器内部错误，无法完成请求 |
| 501 | Not Implemented | 服务器不支持请求的功能，无法完成请求 |
| 502 | Bad Gateway | 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应 |
| 503 | Service Unavailable | 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 |
| 504 | Gateway Time-out | 充当网关或代理的服务器，未及时从远端服务器获取请求 |
| 505 | HTTP Version not supported | 服务器不支持请求的HTTP协议的版本，无法完成处理 |
ps：最常见的HTTP状态码为200、300、40500、502等
HTTP是一种无状态的协议，服务器本身没有记忆功能，无法记住客户端之前是否有发送过请求，因此客户端每次发送的请求都是独立的。 缺点：比如当客户端必须要登录才能进行的操作，客户端频繁发送敏感信息，会产生严重的安全隐患。
session会话机制： 原理：当用户登录时，发送用户名和密码之后，服务端会给客户端生成一个sessionid，标明这是属于哪一个用户，然后在sessionid中存储该用户的数据。服务端通过cookie的形式把sessionid返回给客户端。每次客户端请求该服务时，会自动带上sessionid这个cookie。服务器接收到后查询有没有存储sessionid的信息
session特点：
存储在服务端，占用服务器非常多的存储资源，导致服务器压力增大 响应速度慢 CSRF跨站伪造请求攻击 Cookie无法跨越，涉及到多个服务的跨域操作，有很大的局限性，拓展性不强
解决方法：配置redis集群 当单点数据库挂掉时，可以使用其他数据库中的数据。集群要做好数据同步，保证每个节点得到数据一致性，也要做好负载均衡，尽量不让节点因为负载挂掉。就算其中有节点挂掉了，也不影响服务执行。唯一的缺点是维护成本巨大。
token安全令牌机制：
原理：服务器并不存储用户数据，而是直接通过编码或者加密方式把用户数据作为令牌直接返回给客户端，传递的方式由服务端自己设置。每次客户端携带这个令牌，证明自己的身份，从而得到自己的状态和数据 本质：用户信息通过编码转化成另一种形态得到Token，再通过Token解码得到用户数据，未加签名的token会很容易被伪造
解决办法： 签名：token是由服务端签发生成的，只有服务器才知道签名，从而保证信息不会被伪造
token特点： 不需要存储在服务端，服务器可以节省大量的存储资源，加快了响应速度 传递的方式也是由双方协定，不管是否跨域，都可以正常传递 只消耗CPU资源计算资源 token通常而言不能立即失效，部分需要立即失效：有些大厂采用配置redis集群，回到session
cookie和sessiontoken的联系： session可以通过Cookie实现，也可以不通过 token也可以通过Cookie实现，也可以不通过 Cookie+session一般都搭配做认证，Cookie是放在浏览器中的，session是保存在服务端的数据库中的 由于Cookie一般是和域名绑定的，一般很少和token搭配
疑问收录解答
后端接口与前端均测试了一遍，是否重复测试了？
答：有重复的内容，也有不重复的内容，重复的内容主要体现在：
业务功能：业务功能重合率是最高的，在日常的接口测试中，业务功能上的检查也是占主要的部分，至于为何要测的原因就是一开始提到的要稳固底层。 边界值测试：通常我们在进行接口测试时会进行传参，而传参和客户端正常的逻辑现象表现不同，例如购买王者荣耀游戏的每日免费礼包，礼包每日限购1个且免费购买，当你购买后礼包的次数为0并置灰且不可购买，但在接口测试时传参不受到前端的判断限制，可以自由输入，那么输入10个，输入100个就很可能会出现绕过前端逻辑的情况。在正常的客户端购买会受到代码逻辑限制，这里是其中的区别，在业务功能的检查是无法做到的 性能测试：对于手机软件而言，更多的关注一些APP的性能、CPU、内存等情况，对于手机游戏同样也会关注一些CPU、内存、再此之上会关注渲染、DC、包体大小、FPS、内存泄露等等，无论是游戏测试还是软件测试的接口，都会关注接口响应、服务器数据处理响应、接口并发等场景，关注点也会不同。
没有前端界面已经测试后端接口了，完成前端后还需要再次测试吗？
答：需要，无论是软件测试还是游戏测试，功能测试才是最核心的检查，测试后端的接口为了稳固底层代码、降低成本，提前介入测试，并不意味着不需要进行功能测试，在1中也提及到了，有重复的内容也有不重复的内容，接口测试不能够完全取代功能测试，故此我们在进行了后端接口测试后，仍然需要对功能进行检查。
公司里没有接口需求文档，又收到了测试任务，如何处理？
答：通常而言在一些公司里没有接口需求文档是不会要求进行接口测试的，如果所处的公司收到了接口测试任务，但又没有接口需求文档时，可以通过抓包的方式抓取接口，还可以自动生成接口文档，当然笔者是不建议这样做的，但现实终究是残酷的鸭~
接口测试在执行测试中属于什么测试阶段？
答：集成测试阶段
什么样的接口是个好接口？
答：功能准确无误，响应速度快，支持多用户并发操作，安全性较高
文章为作者独立观点，不代表股票自动交易程序化数据接口观点
股民评论