扫盲内容：

1.什么是接口？

2.接口都有哪些类型？

3.接口的本质是什么？

4.什么是接口测试？

5.问什么要做接口测试？

6.怎样做接口测试？

7.接口测测试点是什么？

8.接口测试都要掌握哪些知识？

9.其他相关知识？

1.什么是接口？

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

2.接口都有哪些类型？

接口一般分为两种：1.程序内部的接口 2.系统对外的接口

系统对外的接口：比如你要从别的网站或服务器上获取资源或信息，别人肯定不会把数据库共享给你，他只能给你提供一个他们写好的方法来获取数据，你引用他提供的接口就能使用他写好的方法，从而达到数据共享的目的。

程序内部的接口：方法与方法之间，模块与模块之间的交互，程序内部抛出的接口，比如bbs系统，有登录模块、发帖模块等等，那你要发帖就必须先登录，那么这两个模块就得有交互，它就会抛出一个接口，供内部系统进行调用。

接口的分类：1.webservice接口 2.http api接口

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

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

json是一种通用的数据类型，所有的语言都认识它。（json的本质是字符串，他与其他语言无关，只是可以经过稍稍加工可以转换成其他语言的数据类型，比如可以转换成Python中的字典，key-value的形式，可以转换成JavaScript中的原生对象，可以转换成java中的类对象等。）

3.接口的本质及其工作原理是什么？

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

4.什么是接口测试？

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

　　　　　　　　　　　　　　–百度百科

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

5.问什么要做接口测试？

   1.越底层发现bug，它的修复成本是越低的。

   2.前端随便变，接口测好了，后端不用变，前后端是两拨人开发的。

   3.检查系统的安全性、稳定性，前端传参不可信，比如京东购物，前端价格不可能传入-1元，但是通过接口可以传入-1元。

　4.如今的系统复杂度不断上升，传统的测试方法成本急剧增加且测试效率大幅下降，接口测试可以提供这种情况下的解决方案。

　5. 接口测试相对容易实现自动化持续集成，且相对UI自动化也比较稳定，可以减少人工回归测试人力成本与时间，缩短测试周期，支持后端快速发版需求。接口持续集成是为什么能低成本高收益的根源。

　6.   现在很多系统前后端架构是分离的，从安全层面来说：

     　　 (1)、只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前面实在太容易）， 需要后端同样进行控制，在这种情况下就需要从接口层面进行验证。

     　　 (2)、前后端传输、日志打印等信息是否加密传输也是需要验证的，特别是涉及到用户的隐私信息，如身份证，银行卡等。

6.怎样做接口测试？

–由于我们项目前后端调用主要是基于http协议的接口，所以测试接口时主要是通过工具或代码模拟http请求的发送与接收。工具有很多如：postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。

–也可以用 接口自动化来实现，就是用代码实现，框架和UI自动化差不多，发送请求用断言来判断。

7.接口测测试点是什么？

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

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

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

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

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

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

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

    问题1.1、后端接口都测试什么？

　　–回答这个问题，我们可以从接口测试活动内容的角度下手，看一下面这张图，基本反应了当前我们项目后端接口测试的主要内容：



问题2、后端接口测试一遍 ，前端也测试一遍，是不是重复测试了？

　　–回答这个问题，我们可以直接对比接口测试和app端测试活动的内容，如下图为app测试时需要覆盖或考虑内容：



 　　从上面这两张图对比可以看出，两个测试活动中相同的部分有功能测试、边界分析测试和性能测试，其它部分由于各自特性或关注点不同需要进行特殊的测试，在此不做讨论。接下来我们针对以上三部分相同的内容再进行分析：

1、基本功能测试：

　　由于是针对基本业务功能进行测试，所以这部分是两种测试重合度最高的一块，开发同学通常所指的也主要是这部分的内容。

2、边界分析测试：

　　在基本功能测试的基础上考虑输入输出的边界条件，这部分内容也会有重复的部分（比如业务规则的边界）。但是，前端的输入输出很多时候都是提供固守的值让用户选择（如下拉框），在这种情况下测试的边界范围就非常有限，但接口测试就不存在这方面的限制，相对来说接口可以覆盖的范围更广，同样的，接口出现问题的概率也更高。

 3、性能测试：

　　这个比较容易区分，虽然都需要做性能测试，但关注点确大不相同。App端性能主要关注与手机相关的特性，如手机cpu、内存、流量、fps等。而接口性能主要关注接口响应时间、并发、服务端资源的使用情况等。两种测试时的策略和方法都有很大区别，所以这部分内容是需要分开单独进行测试的，理论上来说这也是不同的部分。

 

综论：

      1、接口测试和app测试的活动有部分重复的内容，主要集中在业务功能测试方面。除此之外，针对各自特性的测试都不一样，需要分别进行有针对性的测试，才能确保整个产品的质量。

　　2、接口测试可以关注于服务器逻辑验证，而UI测试可以关注于页面展示逻辑及界面前端与服务器集成验证

3、接口测试持续集成：

      对接口测试而言，持续集成自动化是核心内容，通过持自动化的手段我们才能做到低成本高收益。目前我们已经实现了接口自动化，主要应用于回归阶段，后续还需要加强自动化的程度，包括但不限于下面的内容：

　　a) 流程方面：在回归阶段加强接口异常场景的覆盖度，并逐步向系统测试，冒烟测试阶段延伸，最终达到全流程自动化。

　　b) 结果展示：更加丰富的结果展示、趋势分析，质量统计和分析等

　　c) 问题定位：报错信息、日志更精准，方便问题复现与定位。

　　d) 结果校验：加强自动化校验能力，如数据库信息校验。

　　e) 代码覆盖率：不断尝试由目前的黑盒向白盒下探，提高代码覆盖率。

　　f) 性能需求：完善性能测试体系，通过自动化的手段监控接口性能指标是否正常。

 

4、接口测试质量评估标准：

　　a) 业务功能覆盖是否完整

　　b) 业务规则覆盖是否完整

　　c) 参数验证是否达到要求（边界、业务规则）

　　d) 接口异常场景覆盖是否完整

　　e) 接口覆盖率是否达到要求

　　f)  代码覆盖率是否达到要求

　　g) 性能指标是否满足要求

　　h) 安全指标是否满足要求

8.接口测试都要掌握哪些知识？

①了解系统及内部各个组件之间的业务逻辑交互；

②了解接口的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；

文档维护：文档在维护的时候，如有修改一定要写上修改日期，修改人，对大的修改要有版本号变更；

9.其他相关知识？

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中

什么是接口？
1、什么是接口？

　 接口一般来讲分为两种：
(1)程序内部的接口：方法与方法、模块与模块之间的交互，程序内部抛出的接口，如登录发帖，发帖就必须要登录，如果不登录不能发帖，发帖和登录这两个模块之间就要有交互，就会抛出一个接口，进行内部系统调用。
(2)系统对外的接口：从别人的网站或服务器上获取资源或信息，对方不会提供数据库共享，只能提供一个写好的方法来获取数据，如购物网站和第三方支付之间，购物网站支付时可选择第三方支付方法，但第三方不会提供自己的数据库给购物网站，只会提供一个接口，供购物网站进行调用。
2、接口的分类？
接口分类一般分为两种：
(1)webService接口：走soap协议通过http传输，请求报文和返回报文都是xml格式的。测试时需要通过工具才能进行调用、测试。少数公司还在使用这种接口，如医院等行业。
(2)http api接口：走http协议，通过路径来区分调用的方法，请求和报文都是key-value形式的，返回报文一般都是json串，有get和post等方法。目前来讲，是最常用的。
3、接口返回数据
接口返回的数据一般都是json串，json是一种通用的数据类型，格式为key-value。
4、前端、后端区别？

前端：客户端。通俗来讲，一般情况下，web端或app端能看见的地方以及一些简单的校验，都属于前端。
（ps：网站上显示的后台管理不属于后端哦）
后端：服务器端。web端或app端的系统逻辑、如购物时扣除余额，微博发到哪里等都是由后端实现的。

什么是接口测试

本来想写篇接口测试的基础文章，但看到这个，就偷个懒用Google翻译搬过来，想看原文的点这里http://www.softwaretestingmagazine.com/knowledge/api-testing-definition/，之后博主再整理更新更多关于接口测试以及用Python搭建框架的一些内容吧。


  
什么是API？
  
  
现代计算机系统通常使用“分层架构方法”来设计：
  
  

  
  
这意味着系统的核心功能包含在“业务逻辑”层中，作为一系列离散但连接的业务组件。它们负责从各种用户界面（UI）获取信息，在数据库层上执行计算和事务，然后将结果呈现回用户界面。
  
  
然而，除了经由UI层与人进行通信之外，计算机系统必须能够彼此直接通信。例如，您的移动乘车共享应用程序将需要与地图服务，交通和天气服务以及提供乘车的驾驶员使用的其他专门应用程序进行通信。在这个现代和相互关联的世界中，我们认为所有这些不同的系统可以无缝地相互通信，但在现实中，如果没有API是不可能的。
  
  
API定义
  
  
在其核心，应用程序编程接口（API）是作为两个单独的软件之间的保证合同的正式规范。 API提供程序定义了它期望的一组操作，数据格式和协议。API的消费者（称为客户端）将使用那些规则，客户端将永远不必担心API本身的内部，只要它遵循规则。
  
  

  
  
API的重要性在于，它们允许不同的组织创建与其他应用程序和服务讨论的软件应用程序，而不必在相关应用程序或服务的内部更改时不断更新其应用程序。只要API本身保持稳定，实现就可以改变。 这是API的一个重要特性：它们由不改变的部分组成 - 指定操作，数据格式和行为的“接口或合同” - 以及可根据需要更改的实现。
  
  
处理API更改
  
  
那么当您想要更改API并公开新功能时会发生什么？ 你基本上有两个选择：
  
  
更改现有API以反映更新的版本。 但是，这被称为“破坏兼容性”，意味着API的所有客户端都需要更新。 有时这是必要的，但如果可能，应该避免。这对于广泛使用并且具有许多依赖于它的应用的应用尤其如此。 
  
创建一个新的API版本并保留旧的API。 这是推荐的选项。如果可能，您可以创建一个新的API来公开新的功能，但保留现有客户端的旧API。 您可能需要添加翻译图层，以确保旧API的行为与以前完全相同。
  

  
  
API测试
  
  
因此，现在我们已经确立了什么是API，以及为什么API对于现代互连的，全局分布式应用程序和服务至关重要，因此了解为什么API测试是关键的，这一点很重要。
  
  
API测试包括直接测试应用程序编程接口（API）以及作为集成测试的一部分，以确定它们是否满足对功能，可靠性，性能和安全性的期望。由于API缺少GUI，因此在消息层执行API测试。API测试对于自动化测试至关重要，因为API现在是应用程序逻辑的主要接口，因为GUI测试很难通过Agile软件开发和DevOps常用的短暂发布周期和频繁更改来维护。
  
  

  
  
当您发布新版本的系统（例如更改某些业务组件或内部数据结构）时，您需要具有快速，易于运行的API回归测试集，以验证这些内部更改是否会破坏API接口。这是为了确保依赖于API的客户端应用程序将继续像以前一样运行。
  
  
我可以测试什么样的API？
  
  
多年来，API已经从简单的代码库演化而来，应用程序可以在同一台计算机上运行代码，远程API可用于允许一台计算机上的代码调用其他地方的代码。
  
  
下面是以大致时间顺序存在的更常见的API技术的快速列表： 
  
  
TCP / IP套接字 
  
远程过程调用（RPC） 
  
公共对象请求代理体系结构（CORBA） 
  
Java远程方法调用（RMI）和企业Java Bean（EJB） 
  
Microsoft分布式组件对象模型（DCOM） - 也称为ActiveX 
  
Web服务（SOAP然后REST）
  
当查看API测试工具时，了解您将使用哪些API技术以及如何最好地测试它们是非常重要的。现在大多数API将会是Web服务类型（REST或SOAP），但你可能会遇到其他技术，如Java EJB或Microsoft DCOM /ActiveX DLL。
  
  
Web服务测试
  
  
Web服务是可以使用HTTP远程调用的托管代码的单位，也就是说，它可以使用HTTP请求激活。 Web服务允许您通过网络公开现有代码的功能。一旦它暴露在网络上，其他应用程序可以使用您的程序的功能。
  
  
有两大类的Web服务： 
  
  
简单对象访问协议（SOAP） 
  
表示状态转移（REST）
  
测试SOAP Web服务
  
  
SOAP Web服务使用Web服务定义语言（WDSL）并使用HTTP POST请求进行通信。它们本质上是将RPC对象调用序列化为XML，然后可以将其传递到Web服务。 传递到SOAP Web服务的XML需要与WSDL中指定的格式匹配。
  
  
SOAP Web服务是完全自我描述的，因此大多数客户端不直接使用SOAP XML语言，而是使用客户端代理生成器创建Web服务（例如Java，.NET对象）的客户端对象表示。 Web服务消费者与SOAP Web服务的这些特定于语言的表示进行交互。
  
  
但是，当您测试SOAP服务以及具有用于查看提供服务和调用测试操作的漂亮界面时，您需要始终有一种方法来验证以XML发送的原始SOAP请求和响应数据包：
  
  

  
  
此特定功能将真正的SOAP解决方案与仅仅是SOAP客户端库区分开来。前者可帮助您测试服务并了解故障，而后者只是使用不同编程语言更轻松地进行SOAP Web服务调用的一种方法。
  
  
在SOAP Web服务测试工具中应该需要以下功能：
  
  
能够下载远程Web服务描述语言（WSDL）文件并可视化检查其所有功能和数据结构。
  
应该有一种方法通过获取函数并填充所需的参数，然后查看从API返回的响应，以图形方式创建SOAP请求。它应该处理两个简单的值（称为基元，如整数，日期，字符串）和更复杂的结构化对象（例如一个新的用户对象）
  
应该有一种方法来查看发送请求和检索到的响应的原始SOAP XML结构。 理想情况下，应该有一种方法来查看XML数据格式，以便更容易理解交互。
  
如果可能，该工具应支持不同版本的SOAP（1.0,1.1,1.2），并且还处理特定于供应商的扩展，例如Microsoft Windows Communication Foundation（WCP）和ASP.NET Web Services（ASMX）。 
  
测试REST Web服务
  
  
RESTful Web API（也称为RESTful Web服务）是使用HTTP和REST原则实现的Web API。与基于SOAP的Web服务不同，RESTful Web API没有“官方”标准。 这是因为REST是一种架构风格，不像SOAP是一种协议。
  
  

  
  
通常，REST Web服务将其操作展示为对应于特定URL的一系列唯一“资源”。每个标准HTTP方法（POST，GET，PUT和DELETE）然后映射到每个资源上的四个基本CRUD（创建，读取，更新和删除）操作。REST Web服务可以使用不同的数据序列化方法（XML，JSON，RSS等）。
  
  
用于REST Web服务的格式传统上是XML。 这部分是因为它在SOAP Web服务中被广泛使用，因此是熟悉的，但是当带宽不是限制因素时，它是自描述的，其中字段和数据清楚地描述：
  
  
在基于Web浏览器的API中使用的通用格式是JSON，因为它返回数据作为JavaScript对象符号（JSON）对象，可以直接在Web浏览器中使用，因为它与JavaScript用于存储数组和对象的格式匹配。它也是一种非常紧凑的格式，使其成为有限带宽的移动网络上的通信的理想选择。
  
  
在选择用于执行REST Web服务测试的工具时，应查找：
  
  
能够原型化和预览HTTP请求，能够指定HTTP标头，正文，方法和标准HTTP凭据。
  
以各种格式（包括JSON和XML）查看请求和响应正文的能力。 最好的工具提供自动格式化程序，使数据更易于输入和查看。
  
记录您的操作并生成可以自动执行回归和API测试的编程测试脚本的能力。如果可能的话，工具应该提供一种方法来将请求和响应转换为软件“对象”，使得处理数据更容易。
  
如果可能，应该有一种方法来参数化REST请求，以便您可以创建通用REST测试函数，可以以不同的方式在测试脚本中使用，而不必每次都重写。
  
Microsoft DCOM / ActiveX测试
  
  
Microsoft的组件对象模型（COM）也称为ActiveX，是用于单独设计的软件组件（源）之间的通信的标准。任何具有COM接口的对象都可以创建并远程使用：
  
  
var doc = new ActiveXObject("Word.Application"); 
doc.Documents.Open(wordFileName);
  
  
使用此方法，可以通过测试工具来本地测试任何作为COM或.NET可访问动态链接库（DLL）打包的API，这些测试工具支持测试以下不同类型的DLL API：
  
  
托管DLL - 使用.NET Framework编写，该工具应提供特殊的访问类来测试这些API。 
  
未管理的DLL - 使用本机Intel x86代码编写，该工具应提供一个特殊的DynamicWrapper，使它更容易访问这些API
  

什么是接口？

业内常说的接口一般指两种：
API：应用程序编程接口，程序间的接口
	
GUI：图形用户界面，人与程序的接口
软件接口测试中的接口特指API接口
	
接口测试又称API测试
接口实例：系统与系统间的接口调用，作用：实现了两个或多个独立系统或模块间的通信和数据交换能力。

常见的Web接口类型

REST接口——通过HTTP的get和post方式得到数据，返回报文json格式
	
SOAP接口——通过soap协议得到数据，相比Httpservice能处理更加复杂的数据类型，请求报文和返回报文xml格式
Http接口的组成

eg：http://127.0.0.1:80/user.php?act=register

请求协议：http://
	
IP：127.0.0.1
	
端口号：80
	
接口地址：user.php
	
接口参数：act
	
参数值：register
SOAP接口

SOAP实际上就是HTTP+XML
	
无论哪种语言开发的平台，只要是网页开发都可以通过http协议来进行通信，并且返回的数据想要通用的话，可以使用XML格式来编写
面试题：什么是RESTful？

RESTful是REST的全程。
	
提供了一组客户端和服务器交互的规则。
当用“GET”方式时，只用来获取数据，成功了返回http状态码200。
	
当用“POST”方式时，只用来创建数据，成功了返回http状态码201
	
当用“PUT”方式时，只用来修改更新数据，成功了返回http状态码203
	
当用“DELETE”方式时，只用来删除数据，成功了返回http状态码204
    ps：GET(SELECT)：从服务器取出资源（一项或多项）。

           POST(CREATE)：在服务器新建一个资源。

           PUT（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）。

           PATCH（UPDATE）：在服务器更新资源（客户端提供改变的属性）。

           DELETE（DELETE）：从服务器删除资源。

为什么要做接口测试？

尽早进行系统集成测试，暴露BUG
	
解决系统测试复杂度
	
屏蔽UI层的不稳定性
	
检查系统安全性，稳定性
	
接口经过测试稳定了，前端页面随便改，减少BUG的产生
接口测试的原理

原理：模拟客户端向服务器发送请求报文，服务器接受请求报文后对相应的报文做处理并向客户端返回应答，客户端再接受应答的一个过程。
	
接口测试是黑盒测试。作为黑盒测试，基本的测试思路是通过输入和输出判断被测系统或者对象的逻辑。
接口测试关注点

关注在系统架构的业务逻辑层，不注重UI操作或者用户感观
	
检查数据的交换，传递和控制管理过程
	
注重系统间的相互逻辑关系调用
接口测试的范围

按测试类型分：功能、性能、安全性

按数据的输入输出分：

1、进入系统的接口（调用外部系统的参数为本系统使用）

2、数据流出系统接口（验证系统处理后的数据是否正常）

接口测试和UI测试的异同点

UI的操作实际上就是用另一种方式调用接口，那么接口有多少种参数组合就要求UI用例要构造多少种操作进行调用
	
UI操作所需要的数据可以用接口来生成
	
接口测试可以保证数据和逻辑的准确性，UI测试需要考虑交互和界面展示的逻辑正确性
	
UI测试需要重视接口调用不成功或者接口异常情况下UI的呈现方式和用户体验
	
UI中可能会有一些状态的缓存信息（这样就不需要每次频繁调用接口去获取了），比如鉴权信息等，需要重点关注这些缓存的更新策略
接口测试的三种形式

手动测试：辅助工具、Fiddler、Postman、HttpWath。。。

自动化测试：自己开发的工具、SoapUI、RobotFramework。。。

性能测试：自己开发的工具、Jmeter、LoadRunner。。。

如何开展接口测试

找开发或者开发主管索要接口说明文档（API文档）。作用：是开发测试脚本的依据
	
熟悉业务，设计测试用例，准备测试数据
	
根据接口说明文档开发接口测试脚本，执行脚本
API文档
	
测试文档接口说明，参数，返回值，是否齐全
	
熟悉业务
	
设计测试用例，准备测试数据
	
开发接口测试脚本
	
执行脚本，调入数据
	
提交BUG
	
写报告
一份好的接口说明文档是什么样的？

在项目中，一份完整的接口文档应该包含以下的内容：

接口说明
	
请求方式（get\post）
	
请求地址
	
请求参数、参数类型、请求参数说明
	
返回参数说明
	
返回示例


HTTP协议——Http请求

请求：Request，由客户端发送给服务器端
	
请求分类：GET和POST请求（有什么区别？）
GET请求主要是数据的获取
	
POST请求主要是数据的提交
HTTP协议——Http响应

响应：Response，由服务器端返回给客户端
	
响应包含正常的响应和异常的响应。
	
HTTP协议通过响应的状态码来进行定义：1xx，2xx，3xx（正常），4xx，5xx（异常）
接口功能测试点

接口文档规范性
	
接口可用性
	
接口实现功能验证
	
输入输出参数个数及命名
	
输入参数的必填项
	
输入参数的合法性
	
输出参数内容的正确性
	
接口传递参数的安全性
——接口可用性

主要测试接口是否可用、接口是否存在、接口的协议类型
	
测试用例中应包括：
依据接口文档中给定的接口地址和协议方法能够访问到该接口。
	
使用错误的协议方法无法按照接口地址进行访问。
	
使用正确的协议方法无法按照错误的接口地址进行访问。
——输入输出参数个数及命名

主要测试接口包含的输入输出参数的个数以及各个参数的命名是否正确。
	
测试用例中应包括：
依据接口文档检查输入参数的个数以及命名是否和文档一致。
	
依据接口文档检查输出参数的个数以及命名是否和文档一致（注意检查输出的正常参数和异常参数）。
	
输入错误的参数名，接口会报错，并有错误信息返回。
——输出参数内容的正确性

主要对输出参数的内容是否和后台真实数据一致进行检查。
	
测试用例中应包括：
考虑多种输入参数的组合情况，依次测试在这些组合情况下接口返回的数据的各字段内容是否正确，要具体检查每个字段的内容。一般通过与后台数据库数据比较来进行检查。
	
考虑多种输入参数的组合情况，依次测试在这些组合情况下接口返回的数据中涉及输入参数的项，是否和最初输入的值一致。
——接口实现功能验证

主要对接口操作的具体功能是否正常运转进行检查。
	
测试用例中应包括：
输入正确的参数，检查接口对应的要实现的后台功能是否正确运转。例如：对一个启动接口发送启动的命令，接口对应的后台系统能够正确启动并返回正确的参数。
	
输入错误的参数，检查接口对应的要实现的后台功能是否没有运转。
——接口文档规范性

主要对开发提供的接口文档是否规范准确进行检查。
	
测试用例中应包括：
接口文档中对于输入输出参数都有准确的命名，不存在模糊的情况。
	
接口文档对于每一个参数都有明确的类型说明，是否可选还是必输，是否有默认值。
	
接口文档对于每一个输入参数都有明确好基本的录入条件，比如长度最长多少、只能为数字还是字母、不能含有特殊字符等。
	
针对一个接口如果有多种类型的输出参数组合且参数的命名或者个数有不同，这种情况，要在接口文档中罗列清晰，并明确指出出现这种类型的输出参数的条件。
——接口传递参数的安全性

接口传递参数的加密显示
	
防止SQL注入攻击
——SQL注入的原理

定义：利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力。
	
用于没有对用户的输入数据进行必要的合法性判断，导致了攻击者可用提交一段数据库查询代码，根据程序返回的结果，获得一些他想要得到的数据。
	
举例：
	
在用户名输入框中输入：’or 1=1 #，密码随便输入，这时候的合成后的SQL查询语句为：
	
select * from users where username = '' or 1=1 #' and password = md5('')
	
等价于：select * from users where username = '' or 1=1
接口测试用例怎么写

三个步骤：

初始化测试数据
	
调用接口，传入输入数据
	
对输出断言