前情：

《【接口测试实战(零)】接口测试简介》

《【接口测试实战(一)】搭建接口测试环境》

《【接口测试实战(二)】根据接口文档使用postman测试》

相关文档：

《【自动化测试】接口测试基础》

《【自动化测试】接口测试的具体内容和流程》

1）接口测试发现的典型问题

接口测试经常遇到的bug和问题，如下：

• 传入参数处理不当，导致程序crash
• 类型溢出，导致数据读出和写入不一致
• 因对象权限未进行校验，可以访问其他用户敏感信息
• 状态处理不当，导致逻辑出现错乱
• 逻辑校验不完善，可利用漏洞获取非正当利益等

2）接口测试用例设计

一个接口通常是有输入输出的，输入就是我们常见的入参，输出有时有，有时没有。调用相关接口，接口会执行相关处理逻辑。

接口测试的用例设计，主要从输入和接口处理两方面考虑：

1. 针对输入，可按照参数类型进行设计。
2. 针对接口处理，可按照逻辑进行用例设计。
3. 针对输出，可根据结果进行分析设计。

2.1 针对输入设计

对于接口来说，输入就是入参。

常见参数类型有:

• 数值型(int、long、float、double等）
• 字符串类型
• 数组或链表
• 结构体：结构体(struct)是一些元素的结合，元素实际也是数值型，字符串型，数组或链表。

2.1.1 数值型

如果参数规定了值的范围，则需要考虑等价类取值范围内、取值范围外，取值的边界，如有需要，可能会遍历取值范围内的各个值。

• 常见问题和风险：

  • 特殊值处理不当导致程序异常退出
  • 类型边界溢出
  • 取值范围外值未返回正确的错误信息等

• 设计举例：

  检查权限的接口：TaskChecker.checkTask(int taskID)，taskID的取值范围是1-35，那么设计时考虑：
  • 1-35范围内和范围外的值
  • 1-35的边界：0、1、2、34、35、36
  • 类型的特殊值：-1、0、非数字、特殊字符
  • 数据类型的边界值：int的最小值最大值
  • 因为1-35代码的权限ID不同，可能需要遍历1-35的每个值

2.1.2 字符串型

字符串型的参数，主要考虑字符串的长度和内容。

• 常见问题和风险：

  • 传入非特定类型导致程序异常退出
  • 超长字符未进行处理，导致存储、显示等异常
  • 其他用户可见设置的敏感字

• 设计举例：

  接口转换设置闹钟的接口DateUtil.getDayOfDDHH(String ddhh)，用例可以考虑：
  • 长度为4位，比4位少，比4位多
  • 边界值：String的最大长度
  • 特殊值：空字符
  • 字符串内容可考虑类型：数字，非数字
  • 特殊字符
  • 如果是输入用户输入且其他用户可见的内容，则还需要考虑敏感字是否被正常过滤

2.1.3 数组或链表类型

• 常见问题和风险：

  • 0个item时程序异常退出
  • 重复的item处理时未去重导致结果异常等

• 设计举例：

  批量提交任务的接口submitTask(int[] taskID)，参数用例设计考虑：
  • 正常取值：1-5个权限，范围外：6个权限
  • 元素边界值：1-35的边界值，请求允许最大最小值
  • 特殊值：0个
  • 合法ID和不合法的
  • 重复的ID等

2.2 针对逻辑设计

接口需要进行一些逻辑处理的，那么按逻辑设计用例可以从以下几个角度分析。

2.2.1 约束条件分析

约束条件的测试在功能测试中经常遇到，在接口测试中更为重要。

• 它的意义在于：

  • 用户进行操作时，在该操作的前端可能已经进行了约束条件的限制，故用户无法直接触发请求该接口。
  • 但是实际上，在其他情况下，例如UI有bug或者通过技术手段直接调用接口，那么接口是否针对这些条件进行了限制就尤为重要。
    
    

• 常见的约束条件：

  • 数值限制：分数限制、金币限制、等级限制、时间限制等等。（例如：兑换Q币活动要求积分>50才可参与。）
  • 状态限制：登录状态等。（例如：同步用户信息需要先登录账号。）
  • 关系限制：绑定的关系，好友关系等。（例如：帮家人防骗功能只能查询绑定家人的来电信息。）
  • 权限限制：管理员等。
    
    

• 常见的问题和风险：

  • 约束条件判断不足，导致用户可通过特殊手段获取利益

• 设计举例：

  要兑换5Q币需要200积分，但是由于积分不足，所以兑换按钮是灰色无法点击的状态。
  • 正常用户是无法操作的，但是兑换其实是调后台的一个接口，如果绕过页面按钮的限制，直接调用后台接口兑换呢？是否可以兑换？
  • 预期当然是不能兑换的。因此积分这个数值限制就需要针对接口进行测试，并且非常重要。

2.2.2 操作对象分析

操作通常是针对对象的，对象分析主要是针对合法和不合法对象进行操作。

• 常见的问题和风险：

  • 用户可访问非权限内的其他用户信息、敏感信息，从而利用这些信息谋取利益

• 设计举例：

  用户绑定电话号码，电话号码就是操作对象，而这个电话号码的话费、流量也是对象：
  • 用户A查询电话P1话费
  • 用户A查询电话P1流量
  • 用户A查询电话P2话费
  • 用户A查询电话P2流量
• 后台的逻辑处理，如果一个电话已经被绑定过，从后台的角度是可以查询到该电话的话费和流量的。
• 但是在用户侧，应该是A绑定了的电话，才能让A查询到该电话的话费。故类似对象的测试也必不可少。

2.2.3 状态转换分析

被测逻辑可以抽象成状态机，各个状态之间根据功能逻辑从一个状态切换到另一个状态。如果我们打乱了这个次序，从一个状态切换到另一个不在它下一状态集中的状态，那么逻辑将会打乱，就会出现逻辑问题。

• 常见的问题和风险：

  • 可通过特殊手段达到原本不能的状态，从而谋取利益

从某状态改变到新的状态，依赖于转换接口。而对于某转换接口，其输入状态是确定的，比如Fun23这个函数只能把状态2转换为状态3，而不能把状态1转换为状态3。那么测试点就可以是：

• 状态为状态2，调用接口Fun23（），状态切换到状态3；
• 状态为1,3等，调用接口Fun23（），状态不能切换。
  
  

设计举例：

在做任务的时候，任务有三种状态：未领取，已领取未提交，已完成三种状态。那么可以这样设计：

• 正常的状态切换：
  • 未领取状态，领取任务后变为已领取未提交状态；
  • 已领取满足任务条件提交后，变成已完成状态；
  • 完成后可以再次领取任务。
• 非正常的状态切换：
  • 未领取任务满足任务条件直接提交任务；
  • 已领取时再次领取任务等等。

2.2.4 时序分析

在一些复杂的活动中，一个活动是由一系列动作按照指定顺序进行的，这些动作形成一个动作流，只有按照这个顺序依次执行，才能得到预期结果。

• 在正常的流程里，这些动作是根据程序调用依次进行的，并不会打乱。

• 在接口测试时，需要考虑如果不按照时序执行，是否会出现问题。

• 常见的问题和风险：

  • 非顺序执行后，数据出现异常，可能还会出现程序其他异常
  • 通过打乱顺序获取利益

• 设计举例：

  客户端数据同步是由客户端触发进行的，期间的同步用户无法干预。功能测试的时候可见的就是是否能正常进行同步，而进一步分析，同步流程实际涉及了一组动作：
  • 从时序图可以看出，后台有3个接口：登陆获取用户ID，上报本地数据，上报本地冲突。
  • 三个接口需要依次调用执行，才能完成同步。
  • 那么在接口测试就可以考虑打乱上述接口的执行顺序去执行，会有怎样的结果，是否会出现异常。
    • 例如：获取用户ID后不上报本地数据而直接上报本地冲突。

2.3 针对输出设计

针对输出设计其实是针对接口返回的结果进行分析。

2.3.1 针对输出结果

接口处理正确的结果可能只有一个，但是错误异常返回结果有很多情况很多值。如果知道返回结果有很多种，就可以针对不同结果设计用例。覆盖返回码也是用例设计的一种思路。

• 常见的问题和风险：

  • 错误前端处理不足，导致前端异常
  • 错误提示处理不当，导致用户看到晦涩的错误码
  • 错误提示不当，导致用户不知道哪里出了问题，如何解决

• 设计举例：

  提交积分任务的时候我们通常能想到的是返回正确和错误。
  • 错误可能想到：无效任务，无效登录态，但是不一定能否完全覆盖所有错误码。
  • 而接口返回定义的返回码可以设计更多用例。

2.3.2 接口超时

接口正常情况下是有返回的，但如果接口不返回呢？也就是说接口超时后的处理也是测试需要考虑的部分。

• 常见的问题和风险：

  • 如果超时处理不当，可能未进行超时处理，导致整个流程阻塞
  • 如果超时处理不当，可能超时后又收到接口返回，导致逻辑出现错乱

2.4 其他测试设计

2.4.1 已废弃接口测试

已废弃协议，是指之前有定义，但是因为需求变更或其他原因，目前版本不用。这些接口虽然不再使用，但有可能代码并没有及时删除。如果利用技术手段调用这些接口，可能获取额外利益。

• 常见的问题和风险：

  • 如果利用技术手段调用这些接口，可能获取额外利益。

因此新版本在考虑兼容旧版本的同时，还应做好相关废弃接口的检查，避免用户获得额外利益。

• 设计举例：

  任务之前有个清理任务，在一个版本需求里将清理任务替换为下载任务。
  • 在新版本客户端已不再调用完成清理任务的接口；
  • 但是如果该接口未关闭，用户就可以继续请求submitTask(int taskID)接口完成清理任务获得积分。

2.4.2 接口设计合理性分析

接口定义是否合理可以从以下几个方面分析：

• 接口字段是否冗余
• 接口是否冗余
• 接口是否返回了调用方期望得到的信息
• 接口定义是否可满足所有调用需求
• 接口定义调用是否方便

3）接口功能测试用例模板

接口测试的步骤中最重要的是向接口发送预设请求，结果则要关注响应信息及后续处理。

所以接口功能测试用例编排可以考虑下列两种形式：

1、用例名称、用例编号、接口地址、请求方式、前置条件、步骤（描述、请求头、请求参数、状态码）、预期结果和实际结果。

2、用例编号、标题、模块、优先级、描述、前置条件、请求类型、请求参数、步骤、结果。

• 要特别注意的是，实际工作场景中我们可能还会对接口之间的串联和混合场景进行测试。就是上一个接口返回的数据有可能作为后边的接口的参数传入后边的接口。

4）测试报告模板

测试报告是指把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。

• 测试报告是测试阶段最后的文档产出物。
• 优秀的测试经理或测试人员应该具备良好的文档编写能力。
• 接口测试报告很多时候会和接口性能测试报告一起。

单独报告的话，可以考虑以下内容：

4.1 系统接口概况

简要描述与测试项目相关的一些背景资料，如被测系统简介，项目上线计划等。

对于系统接口的定义和设计做出介绍。

• 比如系统一共有多少个接口？
• 采用哪种协议？
• 都涉及到哪些发送方法？
• 采用怎样的请求格式？
• 使用怎样的返回标准？
  
  

可用表格说明。

4.2 测试目的与范围

描述本次接口测试的目的、范围与目标，内容应与本次接口测试的《接口测试实施方案》中的对应内容保持一致。

• 测试目的：本次测试的目的在于确保系统接口功能和逻辑处理已验证，符合《接口定义说明书》的定义和要求，满足系统需要。
• 测试对象范围（测试用例设计）：简要介绍测试用例的设计方法。例如：等价类划分、边界值、因果图，以及用这类方法(3-4句)。
• 测试指标范围：被测接口接收请求和返回报文、被测接口返回状态、被测接口对应业务逻辑处理、涉及数据沉淀的处理、复杂场景下多接口串联交互

4.3 测试工具及资源

简要介绍测试中采用的方法(和工具)。

4.4 测试记录及结果分析

4.5 测试问题及结果分析

结合测试中发现的问题对于整体测试结果进行分析，做出判断：

• 接口业务功能错误类缺陷情况
• 接口异常处理类缺陷情况
• 接口处理数据沉淀缺陷类情况
• 接口安全性缺陷情况
• 混合接口业务功能错误类缺陷情况
• 混合接口业务数据传递类缺陷情况

4.6 测试结论

给出本次性能测试的测试总结论，一般以测试结果与测试目标的比较结果作为测试结论。

• 测试执行是否充分（可以增加对安全性、可靠性、可维护性和功能性描述）。
• 对测试风险的控制措施和成效。
• 测试目标是否完成。
• 测试是否通过。
• 是否可以进入下一阶段项目目标。

【部分内容参考自】

• 接口测试用例设计（详细干货）：https://blog.csdn.net/u011001084/article/details/79102967
• 接口测试用例和接口测试模板：https://www.cnblogs.com/jingdenghuakai/p/10815008.html

持续更新…
标记

1. 接口测试概述

1.1 生活中的接口和软件程序的接口

生活中的接口
比如（插座，插头）、网线和USB的转接等。

软件程序的接口

软件接口就是指程序中具体负责在不同模块之间传输或接受数据的并做处理的类或者函数。（而不是指传输的数据！！）
比如腾讯发布一个qq登录的接口（一个函数），别人拿到这个函数放到自己的网站代码里面运行，就可以通过这个函数把用户输入的账号密码传给腾讯服务器，服务器校验成功后就能让用户第三方登录QQ了。
软件中什么是接口？软件接口的具体定义

1.2 接口测试的定义

接口的定义

• API（Application Program Interface）接口属于一种系统或程序的调用接口；
• GUI（Graphic User Interface）接口属于一种图形界面的操作软件的系统；

尤其是API，有些公司会制定自己的系统接口标准，当需要执行系统整合、自定义和程序应用等操作时，公司所有成员都可以通过该接口标准调用源代码，该接口标准被称为开放式API。

接口测试

• 接口测试是测试系统内部各个组件间接口，以及系统和外部系统之间的交互点；
• 测试的主要内容：1.检查数据的交换，2.传递和控制管理过程，3.系统间的相互逻辑依赖关系；

接口测试是集成测试中非常常用的手段。

1.3 接口测试的范围和适用场景

接口测试的范围

接口测试的使用场景

1）一般应用于系统间交互开发；
2）适用于为其他系统提供服务的底层框架系统和中心服务系统；
3）适用于上一层系统中的服务层接口；
4）总之，平台越复杂，系统越庞大，接口测试的效果就越明显。

关于接口测试

• 与界面功能测试相比：
  • 接口测试没有具体的页面；
  • 它是通过接口规范文档上的调用地址、请求参数、拼接请求信息；
  • 然后发送请求，检查返回结果；
  • 只需要测入参和出参就行。
• 进行接口测试的好处：
  • 可以发现很多在页面上操作发现不了的bug；
  • 检查系统的异常处理能力；
  • 检查系统的安全性、稳定性；
  • 前端随便变、接口测好了，后端不用变。

2. 接口测试必备条件

2.1 接口测试的必要条件

1）接口说明
2）调用url（统一资源定位器）
3）请求方法（比如get/post等）
4）请求参数、参数类型、请求参数说明
5）返回参数说明

2.2 标准和规范的接口文档

• V2EX API 整理
• 百度翻译通用翻译API
• 京东联盟开放平台
• 支付宝支付API
• 腾讯开放平台
• …

2.3 如何获取接口信息

• 标准的接口文档
• 询问开发人员
• 测试人员自己抓包获取数据和信息

3. 接口测试必备的知识

3.1 常见的接口传输协议和标准

常见的传输协议：

• http(超文本传输协议)/https(超文本传输安全协议)：是tcp/ip四层架构中应用层的协议；
• ftp(文件传输协议)

数据的传输标准：

• jdbc(java与数据库的连接标准)

3.2 常见的接口测试工具

• Chrome
• Firefox
• Postman
• JMeter
• Fiddler（抓包工具，如果没有标准的接口文档，测试人员自己抓包获取数据和信息）

3.3 常见的接口数据组织形式

• HTML（超文本标记语言）
• JSON（轻量级的数据交换格式）
• String
• XML（可扩展标记语言）：常用于传输和存储数据

3.4 接口测试流程

1. 接口需求分析；
2. 测试计划编写；
3. 测试用例设计；
4. 测试脚本开发；
5. 测试执行；
6. 发布测试结果。

4. 接口测试用例设计

4.1 用例设计方法

1）等价类划分、边界值分析（用于选取测试数据）
2）因果图法、判定表驱动法
3）正交试验法
4）场景法
5）功能图法
6）错误猜测法（类似探索性测试法）
…

4.2 接口测试用例模板

eg:

5. HTTP协议

网络体系结构：TCP/IP（传输控制协议/网际协议）、OSI/RM（开放式通信系统互联参考模型）

TCP/IP结构四层（应用领域广泛）：网络接口层，网络层，传输层，应用层。
OSI/RM结构七层：物理层，数据链路层，网络层，传输层，会话层，表示层，应用层。

5.1 HTTP协议基础

5.1.1 HTTP和HTTPS协议定义

HTTP定义：
HTTP（Hyper Text Transfer Protocol，超文本传输协议）是从万维网（WWW(3W)：World Wide Web）服务器传输超文本到本地浏览器的传送协议，HTTP是一个基于TCP/IP通信协议来传递数据的（eg：HTML文件，图片文件，查询结果等）。

HTTPS定义：
HTTPS（Hyper Text Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单说就是HTTP的安全版，HTTPS在HTTP的基础上加入了SSL，SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。

5.1.2 HTTP协议的工作原理

HTTP工作环境：
HTTP工作与客户端/服务器（C/S）架构上;
1）浏览器作为HTTP客户端通过URL向HTTP服务器（即WEB服务器，常用的WEB服务器：Apache服务器、IIS（Internet Information Services）服务器，nginx服务器等）发送请求。
2）Web服务器根据接收到的请求后，向客户端发送响应信息。

5.1.3 HTTP协议特性

HTTP的特点：
1）无连接的（即请求和响应的双方可以不同时在线）
2）媒体独立的（传输过程中的数据和通信协议没有关系，即只要客户端和服务端能够识别数据，就能够进行传输，协议只是起到了媒介的作用）
3）无状态的：只要请求，就重新响应，不管之前响应了多少数据。（即频繁的刷新反而会带给浏览器负担）

5.1.4 与HTTPS协议的关系

HTTP和HTTPS的区别：
1）HTTP是SSL加密的，HTTP不加密：HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费，HTTPS是具有安全性的SSL加密传输协议，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输，身份认证的网络协议，比HTTP协议安全；
2）端口不同：HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443;

5.2 HTTP请求及其结构

5.2.1 HTTP请求的组成

HTTP协议的客户端发送一个HTTP请求到服务器的请求消息包括以下格式：1.请求行（request line）、2.请求头（header）、3.空行、4.请求数据四个部分组成。下
下图给出了请求报文的一般格式：

5.2.2 HTTP请求方法|URL

根据HTTP标准，HTTP请求可以使用多种请求方法：
1）HTTP1.0定义了三种请求方法：GET，POST和HEAD方法
2）HTTP1.1新增了五种请求方法：OPTIONS，PUT，DELETE，TRACE和CONNECT方法。

所以现在HTTP协议请求方法一共有8种：

5.2.3 HTTP请求头（Request Headers）

请求头：用来说明服务器要使用的附加信息，比较重要的信息有Cookie、Referer、User-Agent等，部分常见的请求体字段如下：

• Referer：包含一个URL，用户从该URL代表的页面除法访问当前请求的页面；
• User-Agent：浏览器类型，如果Servlet返回的内容与浏览器的类型有关则该值非常有用；
• Content-Length：表示请求消息正文的长度；
• Cookie：是最重要的请求头信息之一；
• Form：请求发送者的email地址，由一些特殊的web客户程序使用，浏览器不会使用到它；
• Host：初始URL中的主机和窗口；
• Accept-Language：浏览器希望的语言，当服务器能够提供一种以上的语言版本要用到；
• Authorization：授权信息，通常出现在对服务器发送的WWW-Authenticate头的应答中；
• Content-Type：表示后面的文档属于什么MIME类型（媒体类型（通常称为 Multipurpose Internet Mail Extensions 或 MIME 类型 ）是一种标准，用来表示文档、文件或字节流的性质和格式），Servlet默认为text/plain，但通常需要显示地指定为text/html，由于经常要设置Content-Type，因此HttpServletResponse提供了一个专门的方法setContentType；

5.2.4 HTTP请求体（Request Body）

请求体：一般用于POST请求中，主要是向浏览器提交数据类型，而对于GET请求Request Body为空。

5.3 HTTP响应及其结构

5.3.1 HTTP响应的组成

HTTP响应由服务器返回，也由四个部分组成，分别是：1.状态行、2.消息报头、3.空行、4.响应正文
具体格式如下：

5.3.2 HTTP响应头及其结构

查看Cookie

5.3.3 HTTP响应状态码

当浏览器接受并显示网页前，此网页所在的服务器会返回包含HTTP状态码（HTTP Status Code）的信息头（server header）用以响应浏览器的请求。


HTTP响应状态分类：

HTTP状态码

5.4 查看客户端和服务端的数据交换

浏览器作为媒介，会将客户端和服务端进行数据沟通的所有情况完完整整的记录下来，从页面开始请求到请求完毕，Network会记录下来所有的数据交换内容，客户端和服务器端进行了哪些数据交换，它都会以实体的方式一一列出。

目录

一、接口相关概念

1.1 接口概念与分类

1.2 接口测试

1.2.1 接口测试原理

1.2.2 接口测试特点

1.2.3 接口测试实现方式

二、HTTP协议

2.1 HTTP协议介绍

2.1.1 HTTP协议概念

2.1.2 HTTP特点

2.2 URL

2.3 HTTP请求

2.4 HTTP响应

三、接口风格：传统接口风格、Restful接口风格

3.1 传统接口风格

3.2 RESTful接口风格

四、接口测试流程

4.1接口测试流程

4.2 接口文档解析

4.2.1 接口文档是什么

4.2.2 接口文档内容

五、接口用例设计

5.1 接口测试测试点

 5.2 接口用例设计

一、接口相关概念

1.1 接口概念与分类

接口：系统与系统之间，组件与组件之间实现数据交互、传递的通道

接口类型：硬件接口和软件接口

1.2 接口测试

1.2.1 接口测试原理

接口测试原理：模拟客户端向服务器发送请求，服务器接收请求后进行相应的业务处理，并向客户端返回相应数据，检查相应数据是否符合预期。

接口测试：对系统或者组件之间的接口进行测试，校验传递数据正确性和逻辑依赖关系的正确性。

接口测试目标：服务器

自动化接口测试：借助工具或者是代码模拟客户端向服务器发送请求，借助断言自动判断预期结果和实际结果是否一致。

1.2.2 接口测试特点

1）更早介入测试

2）能发现页面发现不了的bug

3）性价比高（例如底层一个支付功能异常，会影响页面中所有和支付相关的测试点）

4）比单元测试更贴近用户角度

1.2.3 接口测试实现方式

工具或代码：

                     工具：postman、jmeter、fiddler等；

                     代码：python+UnitTest框架+Request框架。

二、HTTP协议

2.1 HTTP协议介绍

2.1.1 HTTP协议概念

HTTP协议：Hyper Text Transfor Protocol超文本传输协议，是一个基于请求与响应模式的、应用层协议，也是互联网上应用最为广泛的一种网络协议；

协议即规则，要求通信双方必须遵守。协议主要包含以下两种：

2.1.2 HTTP特点

1）支持客户端和服务器模式

2）简单快速

3）灵活：请求方式多样性

4）无连接

5）无状态：是否登陆成功无法体现

2.2 URL

 URL格式：（Uniform Resource Locator）统一资源定位符，是互联网上标准资源的地址。HTTP使用URL来建立连接和传输数据 。

URL语法格式（组成)   https://baike.baidu.com/item/%E5%88%98%E4%BA%A6%E8%8F%B2/136156?fr=aladdin，

    协议：http。规定数据的传输格式

    域名：ip，在网络环境中找到主机      ----用：//与协议分开

    端口：port，（经常省略）在网络主机上表示一个进程（应用程序）  ----用：与域名分隔开

注：端口的网络知识：1-1024给计算机用

1024以上，65535以下给用户使用

    资源路径：标识网络资源（文件、图片、音频、变量..)   ---用：/与端口分隔

    查询参数：  传递给资源路径对应的数据。 ---用？与资源路径分隔，查询参数内部用&分隔多个k，v键值对。

2.3 HTTP请求

HTTP请求：客户端（app、浏览器），发送请求给服务器时，使用的协议，规定发送给服务器的语法格式

请求行：http请求第一行，请求方法 (空格)  URL  (空格)  协议版本

常见请求行中四大请求方法：

          POST请求：向指定的资源提交数据进行处理请求，数据包含在请求体中，POST请求会导致资源的添加，已有资源的修改（登录模块使用）

          GET请求：请求指定的页面信息，并返回实体主体。（通常用来接收数据，查询数据）

          PUT请求：从客户端向服务器传送的数据取代指定的文档内容。（修改）

          DELETE请求：请求删除服务器中的指定页面。

请求头：k ：v  键值对

•    User-Agent：描述请求发送端的浏览器类型。

•   Content-Type：描述请求体的数据类型。

空行：标志请求头结束

请求体：请求发送时携带的数据。

• post 和 put 有请求体，数据类型 Content-Type 的值来确定，支持多种数据类型（图片、表单、Json、html和xml）。

• get 和 delete 没有请求体

2.4 HTTP响应

HTTP响应：服务器端针对客户端发送的 http请求，回发响应数据，规定回发给客户端的数据组织格式。

响应行：协议版本 (空格) 状态码 (空格) 状态消息​​​​​​                       

响应头：语法格式：k:v键值对

• Content-Type: 描述 响应体中数据类型

空行：表示响应头结束

响应体：基本不会为空。（请求成功：回发数据，失败：回发错误信息）

              数据类型受 Content-Type值影响。

2.5 状态码（Status Code）

三、接口风格：传统接口风格、Restful接口风格

3.1 传统接口风格

特点总结：传统接口

    1.请求方法只使用GET和POST
    2.URL不唯一，同一个操作可以对应不同的URL
    3.状态码的使用比较单一，常用200

3.2 RESTful接口风格

总结：

1.每个URL代表一种资源
2.客户端和服务器之间，传递这种资源的某种表现层
表现层：数据不同表现形式（如图片、文字表现同一个数据对象）
3.通过4个http动词（GET/post、delete、put）对服务器资源进行操作，实现“表现层状态转化”；

四、接口测试流程

4.1接口测试流程

1.需求分析
         主要依据需求文档

2.接口文档解析
        一般由开发人员编写接口文档（API）文档

3.设计测试用例

4.执行测试
         使用接口测试工具实现

5.接口缺陷管理与跟踪

6.生成测试报告

7.接口自动化持续集成（可选）

4.2 接口文档解析

4.2.1 接口文档是什么

接口文档：API文档，一般由开发人员编写的，用来描述系统所提供接口信息的文档。 大家都根据这个 接口文档进行开发，并需要一直维护和遵守。

写接口文档的目的：

1. 能够让前端开发与后台开发人员更好的配合，提高工作效率。（有一个统一参考的文件）

2. 项目迭代或者项目人员更迭时，方便后期人员查看和维护

3. 方便测试人员进行接口测试

4.2.2 接口文档内容

1.基本信息：path（资源路径）：/api/sys/login（协议和域名在“系统信息中”；

                    Method；

                   接口描述；

2.请求参数：请求头的数据类型，请求体的数据内容，实现接口使用额数据及对应类型；

3.返回数据：发送请求后的预期结果；测试就是测实际结果哦与返回数据（预期结果）是否一致；状态码；错误码描述：（码值和描述信息）

五、接口用例设计

5.1 接口测试测试点

 5.2 接口用例设计

接口测试用例设计类似于功能测试，但是接口文档中多了对接口请求数据和响应数据的描述，因此接口测试中，多了参数测试。

正向参数

        必填参数

        必填+选填参数

        全部参数

逆向参数

        数据异常：长度不符、类型、是否为空、错误数据

        参数异常：多参、少参、无参、错误参数

        业务异常