接口测试是什么？如何做好接口测试？

文章目录

1.什么是接口？

2.接口都有哪些类型？

3.什么是接口测试？

4.为什么要做接口测试？

5.怎样做接口测试？

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

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

8.其他相关知识？

1.什么是接口？

形象来讲：我们天天用的手机，需要充电，那么我们需要给给手机插上充电器，如果充电器的接口型号对不上，那么就不能进行充电，我们调用接口也是一样，必须要根据接口设计文档来，不能自己随心所欲去调用。

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

2.接口都有哪些类型？

软件中的接口：就是对外提供了一种服务

本地接口：我们提供的basepage、 DBUtil、selenium、 htmltestrunner、pymysql中封装了很多方法，方便调用，那这些方法也可以算接口，只是是本地接口，不能通过网络访问而已

网络接口：软件提供了一种服务，但是这个服务部署好之后，可以通过网络远程调用、socket接口、webservice接口、http接口（这个是目前接口测试最主要的一种协议）

3.什么是接口测试？

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

简单来说就是调用接口，然后输入参数的各种情况，检查对应的输出是否符合预期

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

1.测试场景更完善，测试一些通过页面不能构造的场景，银行app转账金额不能是0，但是通过接口可以构造转账0元的场景。

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

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

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

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

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

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

6.接口自动化测试可以尽早发现系统服务端存在的问题，尽早修复，缩短测试周期。

5.怎样做接口测试？

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

–也可以用接口自动化来实现，就是用代码实现，框架主要也就是接口对象模型，这种模型抽取出接口后，可以最大程度的提升接口的复用性，提高用例的可维护性。

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

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

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

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

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

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

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

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

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

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

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

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

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

1、基本功能测试：

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

2、边界分析测试：

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

3、性能测试：

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

综论：

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

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

4、接口测试持续集成：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.其他相关知识？

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状态码：

表示http响应状态的三位数字，不同数据有不同的含义，常见状态码含义如下

200 OK //客户端请求成功，系统正常处理了这次请求 400 Bad Request //客户端请求有语法错误，不能被服务器所理解 #很多时候我们构造的请求数据格式错了 403 Forbidden //服务器收到请求，但是拒绝提供服务 404 Not Found //请求资源不存在，eg：输入了错误的URL 或者服务没有部署好 500 Internal Server Error //服务器发生不可预期的错误一般看到这种错误提单

502 Bad GateWay //网关错误，说明网络不通，或者服务器没有开启

其实响应码可以代表任何意义，只要双方沟通清楚就行，上面只是说行业标准这样，大家都按照这个要求去做的

http协议如何识别这次请求来自谁？

对于服务端来说，任何一次请求都是全新的开始，也就是说每次请求都是独立的，那我认证了获取服务端授权之后，后面的请求，服务端怎么知道我是谁的呢？

主流的思路如下

第一次请求时，我带上用户名和密码，然后服务端校验传递的用户名密码正确之后，返回一个唯一的字符串，俗称token，后面请求带上这个token，服务端就知道这个请求是来自谁啦。

这样做的好处是什么？不需要每次都传用户名和密码，用户名和密码暴露的风险就小很多，系统会更加安全

那么这个token可以放在请求哪些位置呢？请求头、cookie、传递的数据中都是可以的，只要能够携带数据都可以用，但是绝大多数请求都是放在cookie中

cookie的简单理解

由服务端发送出来以存储在网络浏览器（当然如果是接口测试，我们就要想办法自己保存，浏览器有自己的cookie管理器）上，下一次请求浏览器会自动根据接口调用匹配对应cookie

COOKIE主要有哪些字段呢：

1、name COOKIE的名字

2、value COOKIE对应的值

3、domain 域名就是说这个COOKIE对应哪一个域名有效

4、path 路径， COOKIE对应的哪一个路径才会有效

5、expires/Max-Age 字段为此cookie超时时间。若设置其值为一个时间，那么当到达此时间后，此cookie失效。不设置的话默认值是Session，意思是cookie会和session一起失效。当浏览器关闭(不是浏览器标签页，而是整个浏览器) 后，此cookie失效。

举一个例子，访问禅道服务器返回的内容中的COOKIE值

Set-Cookie: id=123456789; expires=Tue, 26-Otc-2020 08:16:28 GMT; domain = 119.29.100.135 path=/pro/

cookie匹配的时候 1、域名(IP)必须一致， 2、cookie必须有效， 3、路径必须在指定的路径之内（和指定路径相同或者在指定路径的子路径）

1、http://119.29.100.138/pro/

2、http://119.29.100.135/pro/

3、http://119.29.100.135/pro/test/

4、http://119.29.100.135/pro11/

5、http://119.29.100.135/test/pro/

2、3访问的时候会带上对应的COOKIE id =123456789

1、不会带上因为域名不对

4、不会带上因为路径不对

5、不会带上，端口号后面不是/pro/开始