接口测试探索基础

接口基础知识理解：

接口一般来说有两种：程序接口和协议接口

程序接口：程序内部的接口、倾向于方法间的调通信方式

协议接口：系统对外的接口、其他应用通过授权或认证后获取数据的方式

常见的的接口：

1、webService接口：是走soap协议通过http传输，请求报文和返回报文都是xml格式的，我们在测试的时候都用通过工具才能进行调用，测试。可以使用的工具有SoapUI、jmeter、loadrunner等；

2、http api接口：是走http协议，通过路径来区分调用的方法，请求报文都是key-value形式的，返回报文一般都是json串，有get和post等方法，这也是最常用的两种请求方式。可以使用的工具有postman、jmeter、loadrunner等；

1、接口分类

1.1系统与系统之间的接口

系统间的接口调用既可以是公司内部系统也可以和不同公司不同系统之间调用的接口

公司内部的接口更多使用场景：实现公司内部业务

不同公司不同系统使用场景：微信、微博、支付宝等第三方登录

1.2下层服务对上层服务的接口

应用层：

1、系统所提供的的UI层功能，CRM系统（http://crm.be.test.mi.com/new/）

2、BS架构的应用：浏览器页面地址访问所提供的功能、如登录、下单等

Service层：服务器上数据出的处理服务，提供数据出口、入口供应用层调用

DB层：数据库，用来存储数据，系统交互的全部的数据都会存储记录到数据中

1.3系统内部，服务与服务之间的调用

服务间的调用、一般是指程序间的调用

举例说明：查询用户订单信息

1、首先完成用户信息的查询、获取用户的ID唯一值

2、通过用户ID唯一值查询用户关联的订单信息

以上案例中完成用户订单查询过程中调用了用户信息查询的服务，都是系统内部之间的服务

其本质在代码层面：就是函数之间的调用、提供输入参数返回结果值

2、接口协议

接口协议类型大家在百度上都可以查询到很多接口协议的相关知识

简单来讲接口的通常分为两类：webservice接口和http api接口

2.1 webservice接口

webService接口是走soap协议通过http传输，请求报文和返回报文都是xml格式的，我们在测试的时候都用通过工具才能进行调用，测试。

2.2 http api接口

http api接口是走http协议，通过路径来区分调用的方法，请求报文都是key-value形式的，返回报文一般都是json串，有get和post等方法，这也是最常用的两种请求方式。

2.3 不同软件之间对接常用的接口协议

1) OPC协议

OPC（Object Linking and Embedding(OLE) for Process Control）是微软公司的对象连接和嵌入技术在过程控制方面的应用。该标准中定义了在基于PC的客户机之间进行自动化数据实时交换的方法。

2) ODBC

开放数据库连接（Open Database Connectivity，ODBC）是为解决异构数据库间的数据共享而产生的，现已成为WOSA(The Windows Open System Architecture(Windows开放系统体系结构))的主要部分和基于Windows环境的一种数据库访问接口标准ODBC 为异构数据库访问提供统一接口。

3) WebService协议

是一个平台独立的，低耦合的，自包含的、基于可编程的web的应用程序，Web Service技术，能使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件，就可相互交换数据或集成。

4) Http Restful协议

是一种网络应用程序的设计风格和开发方式，适用于移动互联网厂商作为业务使能接口的场景，实现第三方OTT调用移动网络资源的功能，动作类型为新增、变更、删除所调用资源。

3、http和https的区别

文字解释上理解，HTTP（HyperText Transfer Protocol：超文本传输协议）、HTTPS（Hypertext Transfer Protocol Secure：超文本传输安全协议）最大的区别就是：安全，具体体现：HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包。

HTTP 与 HTTPS 区别比较如下

HTTP 明文传输，数据都是未加密的，安全性较差，HTTPS（SSL+HTTP）数据传输过程是加密的，安全性较好。
使用 HTTPS 协议需要到 CA（Certificate Authority，数字证书认证机构）申请证书，一般免费证书较少，因而需要一定费用。证书颁发机构如：Symantec、Comodo、GoDaddy 和 GlobalSign 等。
HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 ssl 握手需要的 9 个包，所以一共是 12 个包。
http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议，所以，要比较 HTTPS 比 HTTP 要更耗费服务器资源。

4、POST和GET的区别

4.1 http请求方法

HTTP 请求可以使用多种请求方法。

HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD 方法。

HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

解释说明

GET：get方法一般用于获取服务器资源

POST：post方法一般用于传输实体主体

PUT：put方法一般用于传输文件

DELETE：delete方法用于删除文件

HEAD：head方法用于获取报文首部，不返回报文主体

OPTIONS：options方法用于询问请求URI资源支持的方法

PATCH：是对 PUT 方法的补充，用来对已知资源进行局部更新

TRACE：回显服务器收到的请求，主要用于测试或诊断

CONNECT：HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器

4.2 http请求响应状态码

下面是常见的 HTTP 状态码：

200 - 请求成功
301 - 资源（网页等）被永久转移到其它URL
404 - 请求的资源（网页等）不存在
500 - 内部服务器错误

100状态码，我们很少见到，需要了解的见下面链接

具体的响应信息解读，大家参靠：https://www.runoob.com/http/http-status-codes.html

4.3 POST和GET区别

GET和POST是http协议最常见的两种方法，这几点答案其实有几点并不准确，但是比较常规的区别

请求缓存：GET 会被缓存，而post不会
收藏书签：GET可以，而POST不能
保留浏览器历史记录：GET可以，而POST不能
用处：get常用于取回数据，post用于提交数据
安全性：post比get安全
请求参数：querystring 是url的一部分get、post都可以带上。 get的querystring（仅支持urlencode编码），post的参数是放在body（支持多种编码）
请求参数长度限制：get请求长度最多1024kb（受浏览器内核限制），post对请求数据没有限制

4.4 介绍下post和get经常产生的误区

get用来取数据、post用来传输数据：两种方式都支持数据的获取和传输，出于传输速度和安全加以分类使用
参数长度限制：参数长度的限制是浏览器及服务对get请求类型的限制，在协议层面没有明确限制get请求参数的长度，业界的1024的长度也是出于对IE浏览器的最大限制，火狐和谷歌浏览器各自长度限制也是不一致的
安全性：这里的安全是相对性，并不是真正意义上的安全，通过get提交的数据都将显示到url上，页面会被浏览器缓存，其他人查看历史记录会看到提交的数据，而post不会。另外get提交数据还可能会造成CSRF（跨站请求伪造）攻击

5、为什么进行接口测试

5.1 更早的发现问题

更早的发现问题的两种方式：单元测试、接口测试

单元测试：更多的依赖倾向于研发进行代码检查、自测，测试同学参与度相对较低

接口测试：在接口未与功能界面开始联调前、对系统的接口进行测试，更多验证入参、出参之间的逻辑判断接口的功能是否符合预期，对研发人员的单元测试也是一种补充。

接口测试在代码review前介入、帮助研发同学验证、确认业务逻辑。

更早的发现问题、避免系统测试阶段问题回溯，一方面问题定位困难、另一方面需要多方进行确认问题定位、代价会增大。

5.2 缩短产品研发周期

研发侧：更早的发现接口的逻辑、实现结果的错误，减少系统测试环节的问题定位困难

业务侧：对需求的确认、研发实现方案（接口文档）的检查

测试侧：在了解业务的前提下，熟悉接口层面数据流转，进而熟悉数据库底层数据的流转逻辑

接口测试的过程中及早的发现bug、服务层面的bug越少在系统测试事功能层面的问题越少。

5.3 发现更底层的问题

接口测试时，我们面对的是服务抛出的接口，通过入参、出参进行数据组合、接口结果输出的预期判断，从而得出接口功能的结论是否符合预期

实质上：接口测试就是调用某一个服务方法、或者是某些方法的集合，经过代码逻辑运算处理返回一个数据结果，对数据结果的准确性进行校验。

通过接口测试可以简单构造出多种场景（UI层面构造苦难）、覆盖更多的底层代码、从而发现一些隐藏的bug；避免UI层面无法触发服务层面的一些异常处理逻辑。

接口专项测试可以检查系统的安全性、稳定性。

5.4 行业发展趋势

1、前后端分离

随着行业发展、传统的一体化程序逐步被服务化的程序取代，前后端分离已是当前比较流行的行业解决方案，那么对我们的软件从业者来说，研发人员更加的专注单项领域即前端、中台、后台；概括起来就是APP应用、服务管理后台、服务软件程序；对于测试从业者而言也有相应的划分：功能测试、服务测试、接口测试、性能测试、安全测试、测试开发等。

测试工作者的实际情况呢？

研发侧可以隔离开发进行，但是对于测试而言功能测试、接口测试、服务测试、甚至是测开都是关联角色，是不可能分割的。那么对于我们测试从业者就提出了更高的要求、在技术上也有了更广泛的涉及。

2、微服务化

概念：微服务架构风格是一类将单一应用程序作为由众多小型服务构成之套件加以开发的方式，其中各项服务都拥有自己的进程并利用轻量化机制（通常为HTTP源API）实现通信。这些服务围绕业务功能建立而成，且凭借自动化部署机制实现独立部署。

微服务化的结果：程序出现大量的服务间的接口调用、不同服务间的接口调用

在微服务化的软件环境中对于我们测试人员的要求：掌握接口测试技巧

5.5 接口测试的必要性总结:

1.可以发现很多在页面上操作发现不了的 bug

2.检查系统的异常处理能力

3.检查系统的安全性、稳定性

4.前端随便变，接口测好了，后端不用变 5.可以测试并发情况，一个账号，同时(大于 2 个请求)对最后一个商品下单，或不同账号，对最后一个商品下单 6.可以修改请求参数，突破前端页面输入限制(如金额)

6、系统测试前：接口测试

接口测试我总结了几句：两看、三查、四要、五关、六验

6.1 两看

一看：业务文档、产品设计熟悉了解业务功能、逻辑，实现功能场景

二看：技术文档、接口文档，了解研发实现方式、数据存储逻辑，通过入参、出参构造测试场景

6.3 三查

一查：是否是新接口开发：查看新业务、新逻辑

二查：是否是旧接口改造：查看原有业务逻辑是否有影响、新业务是否满足

三查：是否是废弃旧接口：明确接口使用范围、查看废弃后是否产生影响

6.3 四要

一要：接口地址、路由要确认

二要：接口类型要确认，post、get、put、head等

三要：接口参数合理性、返回结果对象的内容要开始测试前确认

四要：要通过思维导图或者其他方式梳理接口参数、设计场景验证case

6.4 五关

一关注：功能性关注（功能性方面，其实就是用我们常用的黑盒测试方法去进行测试，例如：等价类、边界值、正交实验…主要是为了确保这个接口能实现基本的功能）

二关注：安全性（用户鉴权、用户认证、接口加密、登录状态依赖cookie/token）

三关注：性能、接口性能在测试过程中根据用户场景进行设计，多数验证大数据量高并发访问

四关注：接口容错性，输入异常(例如非法数据)，关注异常处理是否生效且正确处理，并通过接口的结果进行数据返回提示

五关注：服务异常处理结果（三方服务异常、接口逻辑处理是否具备容错性：如用户系统异常、订单系统异常等，多数情况下前端要进行处理交互保障、后端一般不做处理）

6.5 六验

一验证：接口参数是否必传，结合业务进行确认、后期开展功能测试需要结合检查验证

二验证：参数边界，根据参数设计边界值验证服务是否有功能限制

三验证：数据类型，入参有类型要求、传入非法类型的参数是否有限制给出明确的提示

四验证：非法输入，数据类型一致、但是其值不符合要求（例如前端通过下拉框选择填写的数据、通过接口传参时出入不在其范围内的数据，前端进行数据长度的限制、但是通过接口传入超出长度的内容）

五验证：返回状态，根据不同的入参会返回不同的结果，具体的返回code码在进行软件开发阶段会明确在接口文档中、前端研发会根据返回结果做出交互、接口测试会根据入参预期结果进行测试验证

六验证：返回内容，异常容错结果返回是否符合预期，正常code码状态返回数据是否符合逻辑预期的验证

7、系统测试：接口测试

7.1 获取接口方式

1、查看公司接口文档，明确具体的入参和出参

如果接口文档不存在或者不全面：

1、web端可以通过Chrome或者其他浏览器查看接口、也可以通过抓包工具查看

2、Client客户端软件，通过抓包工具查看

3、APP手机端应用，多数通过抓包工具、对于有些应用会禁止抓包、所以需要研发配合打包可抓包的应用

4、服务间的接口：通过日志文件、查看服务间的接口数据入参、出参的数据

通过以上方式确认接口传递的参数是否符合要求和预期。

注意：web端对于部分PHP网页，会出现无法获取接口的页面，需要特别关注页面的业务逻辑测试

7.2 接口返回数据校验

1、页面传参和实际的接口上传数据一致性校验

2、接口返回的结果和页面展示的数据是否一致，接口数据逻辑计算结果和页面展示内容是否一致

3、对于增、删、改动作的功能对应数据变化，结合数据库数据一致性原则开展验证

6.6 接口测试怎么测、具体做法

通过性验证:首先肯定要保证这个接口功能是好使的，也就是正常的通过性测试，按照接口文档上的参数，正常传入，是否可以返回正确的结果。
参数组合:现在有一个操作商品的接口，有个字段 type，传 1 的时候代表修改商品，商品 id、商品名称、价格有一个是必传的，type 传 2 的时候是删除商品，商品 id 是必传的，这样的，就要测参数组合了，type 传 1 的时候，只传商品名称能不能修改成功，id、名称、价格都传的时候能不能修改成功。
接口安全:

1、绕过验证，比如说购买了一个商品，它的价格是 300 元，那我在提交订单时候，我把这个商品的价格改成 3 元，后端有没有做验证，更狠点，我把钱改成-3，是不是我的余额还要增加?

2、绕过身份授权，比如说修改商品信息接口，那必须得是卖家才能修改，那我传一个普通用户，能不能修改成功，我传一个其他的卖家能不能修改成功

3、参数是否加密，比如说我登陆的接口，用户名和密码是不是加密，如果不加密的话，别人拦截到你的请求，就能获取到你的信息了，加密规则是否容易破解。

4、密码安全规则，密码的复杂程度校验

异常验证:

所谓异常验证，也就是我不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。比如说必填的参数不填，输入整数类型的，传入字符串类型，长度是 10 的，传 11，总之就是你说怎么来，我就不怎么来，其实也就这三种，必传非必传、参数类型、入参长度。

性能测试

接口并发情况，如上面提到的:一个账号，同时(大于 2 个请求)对最后一个商品下单，或不同账号，对最后一个商品下单接口响应时间，响应时间太长了，肯定需要优化，一般都是毫秒级别

8、接口测试案例

测试接口文档

接口：127.0.0.1:8080/

路由地址	test/mypath/
参数	类型	必填项	查询模式	说明
param1	int	是	精确查询	1：有效，2、无效
param2	String	否	模糊查询	订单名称，长度20位、纯数字
param3	ArrayList	是	列表数据精确查询	列表要求内容传递String
param4	String	否	精确查询	不传参数使用默认值：80
param5	String	是	精确查询	要求数据标识：xiaomi2022****** 长度要求：16位