接口测试概念---毫无意义的感觉

目录
接口测试 2

1. 什么是接口 2
   1.1接口都有哪些类型 2
   1.2接口的本质及其工作原理是什么？ 2
2. 接口测试 3
   2.1 什么是接口测试 3
   2.2 为什么要做接口测试 3
   2.3 接口测试须知前提 3
   2.4 接口测试的重点 5
   2.5 接口功能测试策略 5
   2.6 接口文档 6
   2.7 接口用例设计 6
   2.8 接口测试工具 9

接口测试

1.什么是接口
接口一般来讲分为两种：
a）程序内部的接口：方法与方法、模块与模块之间的交互，程序内部跑出的接口，如登录发帖，发帖就必须要登录，如果不登录就不能发帖，发帖和登录这两个模块之间就要有交互，就会抛出一个接口，进行内部系统调用。
b）系统对外的接口：对别人的网站或者服务器上获取资源或信息，对方不会提供数据库共享，只能提供一个写好的方法来获取数据，如购物网站和第三方支付之间，购物网站支付时可选择第三方支付方法，单第三方不会提供自己的数据库给购物网站，只会提供一个接口，供购物网站进行调用。
1.1接口都有哪些类型
接口一般分为两种:1.程序内部的接口 2.系统对外的接口
系统对外的接口：比如你要从别的网站或服务器上获取资源或信息，别人肯定不会把数据库共享给你，他只能提供一个他们写好的方法来获取数据，你引用他提供的接口就能使用他写好的方法，从而达到数据共享的目的
程序内部的接口：方法和方法之间，模块与莫夸之间的调用。程序内部跑出接口，比如公司的系统，得先登录才可以进行报销等操作，那么这两个模块之间就得有交互，他就会跑出一个接口，供内部系统进行调用。
接口的分类：1.webservice接口 2，http api接口
a)webService接口：走soap协议通过http传输，请求报文和返回都是xml格式，测试时需要通过工具才能进行调用、测试。少数公司使用，如医院等。。
b)http api接口：走http协议，通过路径来区分调用的方法，请求和报文都是key-value形式的，返回的报文一般都是json串，有get和post等方法。目前来说是最常用的
1.2接口的本质及其工作原理是什么？
接口可以简单的理解为URL，工作原理就是URL通过get或post请求向服务器发送一些东西，然后会得到一些相应的返回值，本质就是数据的传输与接收。
2.接口测试
2.1 什么是接口测试
接口测试就是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间一级内部各个子系统之间的交互点。测试的重点是要检查数据的交互，传递和控制管理过程，以及系统间的相互逻辑依赖关系。（理解：请求我们想要传输的数据，看服务器返回的值是不是我们想要的或者是预期的）
2.2 为什么要做接口测试
1.更早的发现问题
随着敏捷测试的盛行，我们都知道测试工作要更早的介入到项目开发周期中，因为越早的发现BUG,修复的成本越低
然而功能测试一般都要等到系统测试提供的可测试的UI界面后才能进行，单元测试又要求较高的专业性和人力成本，所以选择接口测试来更早的介入测试。
接口测试可以下功能界面未开发出来之前对系统的接口进行测试，从未更早的发现并以更低的成本修复问题
2.缩短产品周期
接口测试应该更早的介入，可以更早的发现并解决BUG，从而使得留到后期功能测试阶段的BUG数量减少，最终缩短整个项目的上线时间，有助于实现敏捷测试。
3.发现更底层的问题
系统中的有些BUG如果想通过UI层功能测试会比较困难，或者构造测试和测试条件非常复杂。而通过接口测试可以更简单，更全面的覆盖到底层的代码逻辑，从而发现一些隐藏的BUG。
尤其是一些异常的、极端的情况。可以用接口测试很容易的验证。
2.3 接口测试须知前提
1.GET和POST请求：
如果是get请求的话，直接进在浏览器中输入就可以了，只要在浏览器中能够直接请求到的，都是get请求。如果是post的请求，就得借助于工具来使用。
a:get使用URL或cookie传参，而post将数据放在body中。
b:get的url会有长度的限制，而post的数据则可以非常大。
c:post比get安全，因为数据在地址栏上不可见
d:一般get请求用来获取数据，post请求用来发送数据。
2.http状态码
每发出一个http请求后，都会有一个响应，http本身就会有一个状态码，来标识这个请求是否成功，常见的状态码有几下几种：
a:200 表示请求成功，服务器返回数据正确
b:400 400代表客户端发送的请求附近有语法错误；401代表访问的页面没有授权；403表示没有权限访问这个页面；404代表请求失败，服务器未找到该资源
c:500 5开头的代表服务器有异常；500代表服务器产生内部错误；504代表服务器超时，没返回结果；505代表服务器不支持，或者拒绝支持在请求中使用的 HTTP 版本。
补充：
:标签属性enctype。

协议约定post提交的数据必须放在消息主体（entity-body）中，但协议并没有规定数据必须使用什么编码方式（不是指字符编码），由开发者自行决定。服务器通常是根据请求头（headers）中的Content-Type字段来获知请求中的消息主体是用何种方式编码，再对主体进行解析。因此post提交数据方案，包括了Content-Type 和消息主体编码方式两部分。主要有四种方式：application/x-www-from-urlencoded、multpart/from-data、raw(raw的编码方式主要application/json、text/xml等)。
a:application/x-www-from-urlencoded:这是最常见的post提交方式。原生的from表单，如果不设置enctype属性，最终就是以application/x-www-from-urlencoded方式提交数据。
b:multipart/from-data：一种新增的编码类型，以提高二进制文件的传输效率。这种方式一般用来上传文件，各大服务端语言对它也是有良好的支持。当在该表单输入内容进行提交的时候就会产生一个post请求，其中的Content-Type参数值就会被设置为multipart/from-data。
上面提到的这两种post数据的方式，都是浏览器原生支持的，而且现阶段标准汇总原生表单也只支持这两种方式（通过元素的enctype属性指定，默认为application/x-www-from-urlencoded。其实enctype还支持text/plain，不过用的非常少）。
c:raw的编码方式主要是appliction/json、text/xml等。
d:application/json:由于json规范的流行，除了低版本IE之外各大浏览器都原生支持json.stringify,服务端语言也有处理json的函数，使用json不会遇上什么麻烦。同时json可以支持比普通的键值对更加复杂的数据，因此越来越多的人开始使用这种方式进行数据传输。
e:XML：XML-RPC，一种使用http作为传输协议，XML作为编码方式的远程调用规范。
2.4 接口测试的重点
1：检查接口返回的数据是否与预期结果一致。
2：检查接口的容错性，假如传递数据的类型错误时是否可以处理。
3：接口参数的边界值。例如，传递的参数足够大或为负数是，接口是否可以正常处理。
4：接口的性能，http请求接口大多与后端执行的sql语句性能，算法等比较相关。
5：接口的安全性，外部调用的接口尤为重要。
2.5 接口功能测试策略
1.接口测试范围
根据服务器的测试需求，接口范围主要分为：1.新增接口的测试；2.新增业务功能接口测试；3.整个服务器的接口测试。所需测试接口依次增多，在测试时间足够的条件下，当然需要对所有接口进行测试用例的设计，但如果测试较短的情况下，则应首先根据用户的典型操作对测试接口进行优先级划分，对调用频繁接口需要优先进行测试。
2.6 接口文档
接口文档中包含了对接口url，参数以及输出内容的说明，测试人员参照接口文档编写接口测试用例。接口文档内容需详细，以此保证测试用例的完整度，覆盖率。
1：接口名称。标识各个接口的简单说明，如登录接口，获取项目详情接口等；
2：接口url。接口的调用地址，在测试环境下前面的域名可能不一样，不过接口名称不会变。
3：调用方式。接口的调用方式：post/get方式，决定了如何调用接口及传递参数。
4：参数。接口需要传递的参数，参数需要增加些说明：
a:参数类型说明：参数值要说明一下，支支持字母，数据，特殊字符或是字母数据混搭；
b:参数长度说明：参数接收最大多少个的字符串，或是最大是多少的数值等；
c:参数取值范围：像枚举型的参数u，只接收什么范围内的数据，如1-5等；
d:参数的配合说明：有些参数需要配合起作用
e:参数是必需的还是非必须的
5：返回值。接口的返回值说明需要包含正确何错误的情况，正确的情况下有哪些数据，错误的情况下有什么提示
**接口文档缺失
针对目前接口文档信息不全或是没有接口文档得情况:
1:完全没有接口文档。这个情况是最麻烦得，我们要找开发人员来商量，补一个接口文档。如果实在来不及那就给一个调用接口得实例。实例中会有接口地址，参数等信息，我们去测试环境中调用一下，就能看到返回结果得情况。
2：接口文档信息不全。信息不全这个最常见，像参数缺少说明，说明不具体（那里是必填参数，哪里是非必填参数或者没有取值范围等）。此时就需要测试人员去做些尝试，或者去问开发人员。
3：文档不是最新得。接口得后续工作中被修改或是优化过，我们按接口文档上的说明去调用，返回何预期得不一样。通知开发更新文档，然后用最新得文档再去修改测试用例。
2.7 接口用例设计
接口测试用例的设计方法其实和功能测试用例的设计方法是类似的，因为接口是需要满足需求的，而接口测试所依赖的也是需求说明书。但是，因为接口测试毕竟是通过代码去测试代码。所以，为了保证覆盖率，可能会使用单元测试的方法。
1.通用接口用例设计
a:通过性校验：首先肯定要保证这个接口功能是好的，也就是正常的通过性测试，按照接口文档上的参数，正常传入，是否可以返回正确的结果；
b:参数组合：因为参数有必传和非必传，参数的类型和长度，以及传递时可能业务上的一些下限值，所以在设计用例是，要排列组合这些情况，保证所有情况窦娥能覆盖到。例：现在有一个操作商品的接口，有个字段type,传1的时候代表修改商品，商品id、商品名称、价格有一个是必传的，type传2的时候是删除商品，商品id是必传的。这种情况下，就需要测试组合参数了。例：type传1的时候，只传商品名称能不能修改成功，id、名称、价格都穿的时候能不能修改成功。
c:接口安全;
c1:绕过验证，比如提交订单时，在传递商品价格参数时，修改商品价格，就要看后端有没有验证了。又或者支付时，抓个包将订单金额一改，如果能以我修改后的金额支付，那么这个接口就有问题了。
c2：绕过身份验证，系统用户与普通用户，抓取普通用户请求数据，修改用户标识，能不能赋予系统用户的权限。
c3：参数是否加密，比如说登录接口，用户名和密码是否加密。如果不加密，别人拦截你的请求，就能获取到你的信息。加密规则是否容易破解
c4:密码安全规则，密码的负责程度校验（MD5）
d:异常验证：所谓异常校验，也就是我不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。比如输入异常（边界值，非法长度，特殊字段类型），操作异常（特殊业务流程，非法删除数据），依赖服务异常（访问丢包，访问超时）。
e：根据业务逻辑设计用例。
2.设计思路
A:优先级–针对所有的接口
a1:暴露在外面的接口，因为通常该接口会给第三方调用；
a2:供系统内部调用的黑心功能接口；
a3：供系统内部调用费核心功能接口。
B：优先级–针对单个接口
b1:正向用例优先测试，逆向用例次之；
b2:是否满足前提条件 > 是否携带默认参值参数 > 参数是否必填 > 参数之间是否存在关联 > 参数数据类型限制 > 参数数据类型自身的数据范围限制
3.设计用例具体分析：
通常设计接口用例需要考虑以下几个方面：
a:是否满足前提条件
有些接口需要满足前提条件，才可以成功获取数据。常见的如：登录Login。
逆向用例：
针对是否满足前提条件（假设为n个条件），设计0~n条用例
b:是否携带默认值参数
正向用例：
带默认值的参数都不填写、不传参，必填参数都填写正确且存在的“常规”值。其他不填写，设计一条用例；
c:业务规则、功能需求
根据实际需求情况，结合接口参数说明。设计n条正向和逆向用例。
d:参数是否必填
针对每个必填参数，都设计1条参数值为空的逆向用例。
e:参数之间是否存在关联
有些参数批次之间存在相互制约的关系
逆向用例：
根据实际情况，可能需要设计0~n条用例；
f:参数数据类型限制
逆向用例：
针对每个参数都设计1条参数值类型不符的逆向用例；
g:参数数据类型自身的数据范围值限制
正向用例：
针对所有的参数，设计一条每个参数的参数值在数据范围内为最大值的正向用例
逆向用例：
针对每个参数(假设n个)，设计n条每个参数的参数值都超出数据范围最大值的逆向用例。
针对每个参数(假设n个),设计n条每个参数的参数值都小于数据范围最小值的逆向用例。
覆盖范围：
主流程测试用例：正常的主流程功能校验；
分之流测试用例：正常的分支流功能校验；
异常流测试用例：异常容错校验。

2.8 接口测试工具
Fiddler：
Fiddler是一种抓包工具。他说一个http协议调试代理工具，它能够记录互联网之间得http协议通信，可以设置断点，查看所有“进出”得数据（cookie，html，js，css等文件）。
Jmeter：
Jmeter是一款纯java开发得免费开源工具，主要用来做性能测试，但也可以做接口测试，配合后置处理器与断言，可以满足大部分接口测试场景，Jmeter提供了BeanShell编程能力，可以写出比较灵活得测试脚本。相比较postman，postman自动话断言不够强大。