接口测试的基本概念

什么是接口
接口测试主要用于外部系统与系统之间以及内部各个子系统之间的交互点，定义特定的交互点，然后通过这些交互点来，通过一些特殊的规则也就是协议，来进行数据之间的交互。

接口的本质及其工作原理
接口可以简单的理解是URL，工作原理就会说URL通过get或者post请求像服务器发送一些东西，然后得到一些相应的返回值，本质就是数据的传输与接收。

什么是接口测试
接口测试是测试系统组件间接口的一种测试。
接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。
测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

简答的说就是通过URL像服务器或者其他模块等，传输我们想传输的数据，然后看看他们返回的是不是我们预期想要的。

接口可以分下面几种 ：

第一种是函数级别的，测试需要对接口的各个参数进行测试，如：Int MathAdd（int a，int b）。
第二种是对象级别的，开发在使用API接口时，先引入包名，在使用之前声明一个对象，之后可以使用对象提供的方法，而测试时，需要测试的是API的功能及对数据输入的正确性。
第二种和第一种的差别是，我们只需关注提供给用户使用的接口就可以了，不用关心接口调用其他函数情况，相对于第一种来说，测试的粒度要大一些，范围小一些。
第三种是http协议的接口，App客户端和后端服务连接，一般采用的都是http协议，客户端通过get和post的方法从后端服务获取数据。第三种相对于第二种来说，粒度更大，我们关注的接口更少，但是这些接口都是核心功能。
为什么做接口测试
越底层发现bug，它的修复成本是越低的。
前端随便变，接口测好了，后端不用变，前后端是两拨人开发的。
检查系统的安全性、稳定性，前端传参不可信，比如京东购物，前端价格不可能传入-1元，但是通过接口可以传入-1元。
如今的系统复杂度不断上升，传统的测试方法成本急剧增加且测试效率大幅下降，接口测试可以提供这种情况下的解决方案。
接口测试相对容易实现自动化持续集成，且相对UI自动化也比较稳定，可以减少人工回归测试人力成本与时间，缩短测试周期，支持后端快速发版需求。接口持续集成是为什么能低成本高收益的根源。
现在很多系统前后端架构是分离的，从安全层面来说：
1、只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前面实在太容易）， 需要后端同样进行控制，在这种情况下就需要从接口层面进行验证。
2、前后端传输、日志打印等信息是否加密传输也是需要验证的，特别是涉及到用户的隐私信息，如身份证，银行卡等。
接口测试工具
Wireshark
Postman
SoapUI

接口测试测试点
目的：测试接口的正确性和稳定性；

原理：模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做处理并向客户端返回应答，客户端接收应答的过程；

重点：检查数据的交换，传递和控制管理过程，还包括处理的次数；

核心：持续集成是接口测试的核心；

优点：为高复杂性的平台带来高效的缺陷监测和质量监督能力，平台越复杂，系统越庞大，接口测试的效果越明显（提高测试效率，提升用户体验，降低研发成本）；

用例设计重点：通常情况下主要测试最外层的两类接口:数据进入系统接口（调用外部系统的参数为本系统使用）和数据流出系统接口（验证系统处理后的数据是否正常）；

PS：设计用例时还需要注意外部接口提供给使用这些接口的外部用户什么功能，外部用户真正需要什么功能；

测试的策略
评审测试接口文档（需求文档）
根据接口文档编写测试用例（用例编写完全可以按照以往规则来编写，例如等价类划分，边界值等设计方法）
执行测试，查看不同的参数请求，接口的返回的数据是否达到预期
web接口测试
服务器接口测试：
是测试浏览器与服务器的接口。
用户输入的数据是输入到的前端页面上，怎样把这些数据传递的后台的呢？
通过http协议的get与post请求来实现前后端的数据传递。

外部接口测试：
典型：第三方登录，比如你做的新系统免于新用户重新注册的麻烦会提供第三方登录，那用户在登录的时候调用的就是第三方登录的接口，由第三方验证用户名和密码并且返回给当前系统。

web接口测试要点：

请求是否正确，默认请求成功是200，如果请求错误也能返回404、500等。
检查返回数据的正确性与格式；json是一种非常创建的格式。
接口的安全性，一般web都不会暴露在网上任意被调用，需要做一些限制，比如鉴权或认证。
接口的性能，web接口同样注重性能，这直接影响用户的使用体验。
功能测试
接口的功能是否正确实现了
接口是否按照设计文档中来实现（比如username参数写为了user，那么这就不符合，因为接口文档在整个开发中都需要使用，所以接口实际的设计要与接口设计文档中保持一致）
兼容性测试：比如说今天接口进行了调整，但是前端没有进行变更，这时候需要验证新的接口是否满足旧的调用方式
错误码测试：通用的错误码与业务错误码是否能够清晰的说明调用问题，错误码是否能够尽可能的全的覆盖所有的情况
返回值测试：返回值除了内容需要是正确的，还需要类型也是正确的，保证调用方拿到这些参数能够正确的解析
参数边界值、等价类测试
json格式测试：通常我们的接口一般设计的都是传递json串，那么就需要去测试如果传递非json的情况，这时候程序会不会正确的处理，返回相应的 error code
默认值测试：很多情况一些非必填的参数会有默认值，比如说一个查询的接口，参数count为返回查询的结果数量， 默认为10，那么就应该有一条case来测试，当然前置条件是数据库里面必须要存在这样的数据超过10条。
逻辑业务
是否有依赖业务，比如查看订单，是需要用户首先登录的，所以肯定要保证登录了或有相应的cookie
业务逻辑测试：传递正确的参数，接口对数据库进行查询的操作，需要去验证数据库查询是否正确，接口对数据库进行 增删改的操作，也需要看数据库是否同步进行了这些操作
异常测试
1、参数异常：

关键字参数：将参数写为开发语言中的关键字
参数为空：比如去掉了username参数
多或少参数：多或者少参数的验证，现在还不确定如果一个接口多了参数如果没有报错是否是合理的，或者是否需要优化，因为就目前开发给予的答案是，一般不对接口多了参数的处理
错误参数：比如将username参数写为了user等看是否能返回相应的error code
2、数据异常：

关键字数据：将参数的值填为开发语言中的关键字
数据为空：将参数的额值填为空
长度不一致：因为数据库中每个字段都设置有字段长度，填写不符合的长度进行验证
错误数据：就是将参数的值任意填写，或填写不存在的数值
异常类型测试：比如count参数，这个参数的类型一定是可以转换为int类型的，这时候我们需要测试如果传的一些不可以 转换为int类型值来测试代码是否加入判断
性能测试
响应时间
吞吐量
并发用户数
占用内存，CPU等
安全性测试
敏感信息是否加密
必要参数是否后端也进行校验（现在很多系统前后端架构是分离的，从安全层面来说，只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前端太容易了）， 需要后端同样进行控制，在这种情况下就需要从接口层面进行验证）
接口是否防恶意请求（SQL注入）
cookie：就是将header中的cookie修改或删除后看是否能返回相应的error code
header：就是删除或修改header中部分参数的值，看是否能返回相应的error code
唯一识别码：删除修改唯一识别码测试
其他相关知识
get请求，post请求的区别：

GET使用URL或Cookie传参；而POST将数据放在BODY中。
GET的URL会有长度上的限制；而POST的数据则可以非常大。
POST比GET安全，因为数据在地址栏上不可见。
一般get请求用来获取数据，post请求用来发送数据。
http状态码：

200 2开头的都表示这个请求发送成功，最常见的就是200，就代表这个请求是ok的，服务器也返回了。
300 3开头的代表重定向，最常见的是302，把这个请求重定向到别的地方了。
400 400代表客户端发送的请求有语法错误，401代表访问的页面没有授权，403表示没有权限访问这个页面，404代表没有这个页面。
500 5开头的代表服务器有异常，500代表服务器内部异常，504代表服务器端超时，没返回结果。
cookie与session的区别：

cookie数据存放在客户的浏览器上，session数据放在服务器上。
cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗考虑到安全应当使用session。
session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能考虑到减轻服务器性能方面，应当使用cookie。
单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
建议：
将登陆信息等重要信息存放为session
其他信息如果需要保留，可以放在cookie中