接口测试简介
1.什么是接口
接口是内部模块对模块，是外部系统对其他服务提供的调用或连接能力的标准，类似于usb接口。 他是系统向外部提供的物理数据传输的接口，当然只是接口不能传输。 此外，还对该接口是如何传输的进行了一些设置和定义。 开发是模块之间的连接，测试中可见的接口是协议(接口功能的定义)
2.接口的种类和分类
外部接口、内部接口：上层服务是下层服务、同级服务。 常规接口分类http:get、post、delete、put
系统的对外界面：例如，如果试图从其他网站或服务器获取资源或信息，其他人一定不会与你共享数据库。 他只能给你提供他们写的方法来获取数据。 引用他提供的接口，可以使用他写的方法达到数据共享的目的。
程序内部接口：方法和方法之间、模块和模块之间的交互、程序内部抛出的接口，例如bbs系统、登录模块、帖子模块等。 投稿必须先登录。 这样，这两个模块就有交互作用，它会抛出一个接口供内部系统调用。
接口分类：1.web服务接口2.http api接口
webService接口通过soap协议以http传输，请求消息和回复消息都是xml格式，我们可以在测试时使用巴斯德调用进行测试。
http api接口是一种遵循http协议并通过路径区分调用的方法，所有请求消息都是key-value格式，返回消息一般为json串，有get和post等方法
json是一种通用的数据类型，所有语言都知道它。 (json的本质是字符串，他可以转换为Python词典，可以转换为key-value格式，可以转换为javaScript本机对象，可以转换为Java类对象等，而与其他语言无关。) ）
3.各个接口之间的区别
通常，我们测试的接口分为get接口和post接口。 get的提交方式以明文形式提交，并将提交的参数附加在url之后发送到服务器，因此不安全。 此外，get提交的参数有字符限制，可以另存为书签，但post提交方式与get完全不同，post提交的参数位于表单中，因此没有字符限制。 另外，参数在表单中，所以
4.什么是接口测试
简单来说，接口测试实际上是对接口协议的测试，该协议是为实现该接口所需功能而设计的要求。
5.为什么要进行接口测试
由于工作进度因终端(前一级、后端)而异，因此需要调用最初出现的接口和其他公司的接口(银行、支付宝、微信、qq等)的几个接口在安全级别，仅通过前端进行限制不能完全满足系统的安全要求，后端也必须进行同样的控制。 在这种情况下，必须从接口级别进行。还需要验证前后发送、日志打印等信息是否经过加密发送，特别是涉及身份证、银行卡等用户的隐私信息。
6.接口测试流程
执行需求研究、需求审查、场景设计、创建列、数据准备和测试
7.怎么进行接口测试
工具模拟客户端向服务端发送请求并接收服务返回的数据，以测试接口的功能、逻辑业务、异常和安全
功能测试：测试此接口的功能是否实现，以及此接口是否是按照接口文档开发的(例如，接口文档中规定了几个关键字) 在整个项目周期中，不仅有一个开发，还有多个开发，因此在开发过程中由于关键字不同，部分开发的功能可能会发生异常。 另外，自动化脚本也发生异常) ) )。
逻辑业务主要是指逻辑业务的依赖关系。 例如，当支付宝(Alipay )提交订单时，必须确保您已登录。 如果在不登录的情况下提交成功，这将是异常的。 可以修改请求的cookie进行测试)
异常：参数异常：关键字参数(应用其他关键字替换进行测试)、参数为空、参数数) (增加参数个数)、参数错误。 数据异常：关键字数据(填写的数据替换为其他数据语言的数据)、数据长度、数据为空、数据错误。
由于项目前后的调用主要是基于http协议的接口，因此在测试接口时主要通过工具或代码模拟发送和接收http请求。 工具包括postman、jmeter、soupUI、Java http客户端和robot framework http库。
也可以通过接口自动化来实现。 就是用代码实现。 框架与UI自动化相同，发送请求由断言决定。
8.接口测试需要用到的工具
接口测试的常用工具fiddler捕获请求，postman模拟客户端向fiddle
r抓取的请求修改并发送到服务端并接收服务器返回的数据及异常来进行验证接口。工具不是固定的，需要根据项目来进行选择。9.接口的本质及其工作原理
接口你可以简单的理解他就是URL，工作原理就会说URL通过get或者post请求像服务器发送一些东西，然后得到一些相应的返回值，本质就是数据的传输与接收。
接口测试用例设计思路
目的：测试接口的正确性和稳定性；
原理：模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做处理并向客户端返回应答，客户端接收应答的过程；
重点：检查数据的交换，传递和控制管理过程，还包括处理的次数；
核心：持续集成是接口测试的核心；
优点：为高复杂性的平台带来高效的缺陷监测和质量监督能力，平台越复杂，系统越庞大，接口测试的效果越明显（提高测试效率，提升用户体验，降低研发成本）；
用例设计重点：通常情况下主要测试最外层的两类接口:数据进入系统接口（调用外部系统的参数为本系统使用）和数据流出系统接口（验证系统处理后的数据是否正常）；
PS：设计用例时还需要注意外部接口提供给使用这些接口的外部用户什么功能，外部用户真正需要什么功能；
1 输入
输入参数主要从以下几各方面设计：
a 必填项校验
接口文档中有是否必填的说明。参考接口文档即可。
b 参数长度校验
参考接口文档即可。
c 参数值的有效性校验
如：身份证号的校验 ，设计的数据虽然符合身份证号的规则，但是并不是真实有效的身份证号；这种情况就要看身份证号的校验规则是什么样了，一般都是用的现成的身份证号校验器，但是有些是自己写的校验算法，这个本人就遇到过这种问题—校验算法写的不正确；
所以参数有效性的校验就需要结合实际业务场景，判断哪些数据是真实有效的数据，一定要确保所有真实有效的数据是可以验证通过的。
d 参数组合校验
不同的参数组合可能会存在不同的业务场景；
e 如果参数是枚举值，一定要各种枚举值都要测试，因为可能不同的枚举走的不同的业务流程；
f 参数值的默认值的校验
参考接口文档。
g 某些参数具有特定的生成规则，要单独针对生成规则设计用例，一定要保证真实有效的数据是可以验证通过的。
如身份证号中间几位 ***19860701*，本人就遇到过输入***19861001*这种值校验不正确；
2 接口逻辑
接口逻辑我用的设计方法是分支覆盖—>路径覆盖—>场景覆盖,同样也是要结合实际业务场景，根本不发生的业务场景就是无效的测试用例。
a 第一步先把业务流程图画出来；
b 依据路程图中的分支分别设计，不同分支不同的场景，这里就要把异常的场景考虑进去；如接口超时，接口异常，接口请求成功或失败，成功后怎么处理，失败后流程是否继续执行，失败后的数据怎么处理；
以打款接口为例：
打款结果有打款成功或打款失败，成功后怎么处理，需要回写打款成功状态，失败后怎么处理，也需要回写失败状态，失败后的数据可以操作退回，也可以操作重新出款等等；
c 测试逻辑设计完成后要想一想不同的业务场景怎么去测试，需要哪些人员协助，
如接口超时怎么去测试，请求重复怎么去测试，请求并发怎么去测试
3 输出
输入结果：正常输出和异常输出，常用的方法有错误推断法（列举出程序中可能存在的错误或者异常，根据他们选择测试用例）
4 以上都完成后，要结合实际的业务场景去掉冗余的用例（即实际业务场景不存在的流程或者输入数据）；
5 如果业务流程涉及到状态转换，要单独设计用户—方法：状态转换图；
6 涉及到多个不同金额或者手续费的计算，可能还会用到正交实验法去设计用例；
7 另外，用例设计中还应当包含异常流程中产生的异常数据的处理流程；—通常所说的补偿机制，这块流程能大大的减轻人工运营的工作量，当然，这需要在做系统设计的时候就需要把这部分考虑进去。
接口测试和app测试的相同和区别
1.两者区别：App端性能主要关注与手机相关的特性，如手机cpu、内存、流量、fps等。而接口性能主要关注接口响应时间、并发、服务端资源的使用情况等。两种测试时的策略和方法都有很大区别，所以这部分内容是需要分开单独进行测试的，理论上来说这也是不同的部分。
2.接口测试持续集成：
对接口测试而言，持续集成自动化是核心内容，通过持自动化的手段我们才能做到低成本高收益。目前我们已经实现了接口自动化，主要应用于回归阶段，后续还需要加强自动化的程度，包括但不限于下面的内容：
a) 流程方面：在回归阶段加强接口异常场景的覆盖度，并逐步向系统测试，冒烟测试阶段延伸，最终达到全流程自动化。
b) 结果展示：更加丰富的结果展示、趋势分析，质量统计和分析等
c) 问题定位：报错信息、日志更精准，方便问题复现与定位。
d) 结果校验：加强自动化校验能力，如数据库信息校验。
e) 代码覆盖率：不断尝试由目前的黑盒向白盒下探，提高代码覆盖率。
f) 性能需求：完善性能测试体系，通过自动化的手段监控接口性能指标是否正常。
最后ps：接口测试需要掌握的知识。
①了解系统及内部各个组件之间的业务逻辑交互；
②了解接口的I/O（input/output：输入输出）；
③了解协议的基本内容，包括：通信原理、三次握手、常用的协议类型、报文构成、数据传输方式、常见的状态码、URL构成等；
④常用的接口测试工具，比如：jmeter、loadrunner、postman、soapUI等；
⑤数据库基础操作命令（检查数据入库、提取测试数据等）；
⑥常见的字符类型，比如：char、varchar、text、int、float、datatime、string等；
如何学这些技能？
①系统间业务交互逻辑：通过需求文档、流程图、思维导图、沟通等很多渠道和方式；
②协议：推荐《图解http》这本书，内容生动，相对算是入门级的书籍，其他的还有《图解tcp、IP》等；
③接口测试工具：百度这些工具，然后你会发现，好多的教学博客、相关问题解决方案、以及一些基于工具的书籍，当然，选择合适的书很重要；
④数据库操作命令：学习网站（W3C、菜鸟教程）、教学博客，以及一些数据库相关书籍，入门级推荐：《mysql必知必会》、《oracle PL/SQL必知必会》等
⑤字符类型：还是百度，有句话这么说：内事不决问百度，外事不决问Google。。。
如何获取接口相关信息？
一般的企业，都会由开发或者对应的技术负责人员编写接口文档，里面会注明接口相关的地址、参数类型、方法、输入、输出等信息，如果没有，想办法获取。。。
接口文档八要素：
封面：封面最好是本公司规定的封面，有logo，内容标题，版本号，公司名称，文档产生日期；
修订历史：表格形式较好些，包括：版本、修订说明、修订日期、修订人、审核时间审核人等；
接口信息：接口调用方式，常用的GET/POST方式，接口地址；
功能描述：简洁清晰的描述接口功能，比如：接口获取的信息不包括哪些；
接口参数说明：每个参数都要和实际中调用的一样，包括大小写；参数的含义言简意赅的说明，格式，是string 还是int 还是long等格式；
说明部分，说明参数值是需要哪里提供，并详细说明参数怎么生成的，例如时间戳，是哪个时间段的，参数是否必填，一些参数是必须要有的，有些是可选参数等；
返回值说明：
①最好有一个模板返回值，并说明每个返回参数的意义；
②提供一个真实的调用接口，真实的返回值；
调用限制，安全方面：
加密方式，或者自己公司一个特殊的加密过程，只要双方采用一致的加密算法就可以调用接口，保证了接口调用的安全性，比如常见的md5；
文档维护：文档在维护的时候，如有修改一定要写上修改日期，修改人，对大的修改要有版本号变更；
其他相关知识？
get请求，post请求的区别：
1、GET使用URL或Cookie传参。而POST将数据放在BODY中。
2、GET的URL会有长度上的限制，则POST的数据则可以非常大。
3、POST比GET安全，因为数据在地址栏上不可见。
4、一般get请求用来获取数据，post请求用来发送数据。
其实上面这几点，只有最后一点说的是比较靠谱的，第一点post请求也可以把数据放到url里面，get请求其实也没长度限制，post请求看起来参数是隐式的，稍微安全那么一些些，但是那只是对于伶俐的画笔用户来说的，就算post请求，你通过抓包也是可以抓到参数的。（唯一区别就是这一点，上面3点区别都是不准确的）
http状态码：
1、200 2开头的都表示这个请求发送成功，最常见的就是200，就代表这个请求是ok的，服务器也返回了。
2、300 3开头的代表重定向，最常见的是302，把这个请求重定向到别的地方了。
3、400 400代表客户端发送的请求有语法错误，401代表访问的页面没有授权，403表示没有权限访问这个页面，404代表没有这个页面。
4、500 5开头的代表服务器有异常，500代表服务器内部异常，504代表服务器端超时，没返回结果。
webservice接口怎么测试：
它不需要你在拼报文了，会给一个webservice的地址，或者wsdl文件，直接在soapui导入，就可以看到这个webservice里面的所有接口，也有报文，直接填入参数调用，看返回结果就可以了。
天气预报wsdl地址：http://www.webservicex.net/globalweather.asmx?wsdl
cookie与session的区别：
1、cookie数据存放在客户的浏览器上，session数据放在服务器上。
2、cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗
考虑到安全应当使用session。
3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
考虑到减轻服务器性能方面，应当使用cookie。
4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
5、所以个人建议：
将登陆信息等重要信息存放为session
其他信息如果需要保留，可以放在cookie中