HTTP基础:接口测试,http接口测试

接口

1、接口又称API(Application Programming Interface,应用程序编程接口)：是一些预先定义的函数，为方便应用程序或开发人员在无需访问其源码，或理解其内部工作机制的情况下就能访问对应函数功能的入口

    ⑴接口是后端设计的一套供给第三方使用的方法(第三方指前端/后端)

    ⑵两个不同的系统或者一个系统中两个不同的功能，它们之间相互连接的部分称为接口

2、软件项目中，接口是系统与系统之间，模块与模块之间或者服务与服务之间相互调用的入口

    ⑴从开发者角度，接口是分工协作的产物，不同开发者实现自己的功能之后，封装成接口，供其他开发者调用

    ⑵其他开发者只要按规定格式发送一些必要参数，就能使用该功能

3、接口通过网络协议来调用，我们最常用的协议是HTTP协议(不同系统之间)

4、在定义一个接口时，会写好接口路径和接口方法名的映射，然后前端通过接口路径来调用方法(不同系统之间)

    ⑴举个例子：一个获取商品列表的接口，接口路径是：/api/getMerchantList，接口方法名是：getMerchantList

    ⑵前端通过请求/api/getMerchantList来调用getMerchantList方法，接着后端会做相关逻辑处理，比如查询数据库，最后返回商品数据

5、简单概括为以下3点：

    ⑴程序代码（函数方法）

    ⑵屏蔽实现细节

    ⑶可以被访问/调用来获取信息或实现某些功能(提供访问地址，定义了访问规则)

接口自述(通俗的来说)

1、首先我有一些功能（功能函数）

2、你不用关心我怎么实现的（屏蔽细节）

3、我会给你一个我的地址（接口地址）

4、你按照地址找到我，按照我规定的格式（请求类型）告诉我所需要的信息（参数）就行

5、我会给你个反馈（相应信息）

接口分类  

1、依据所遵循的协议不同，常见的接口可以分为以下3类：

    ⑴HTTP接口：它是基于超文本传输协议(HTTP)开发的接口

    ⑵Web Service接口：它是系统对外的接口。比如你要从别的网站或者服务器上获取资源，别人不会把数据库共享给你，他们会提供一个写好的方法，让你来获取数据

    ⑶RESTful接口：简称REST，其描述了一个架构样式的网络系统，核心是面向资源。REST专门针对网络应用设计和开发方式，降低开发的复杂性，提高系统的可伸缩性

2、按照使用场景也可以简单的划分为：

    ⑴系统与系统之间的调用，比如银行会提供接口供电子商务网站调用，或者说，支付宝会提供接口给淘宝调用(对外接口)

    ⑵模块与模块之间的调用，比如注册用户时，会先调用用户查询的服务，查看该用户是否已经注册(内部接口)

注：

1、基于浏览器/服务器模式(B/S)的软件系统接口大多数为HTTP接口  

2、一般情况下模块与模块之间的接口都是由开发完成的(单元测试等)

    ⑴接口调用方式为：方法名(函数)、参数

3、测试人员测试的基本上都是系统对外接口

    ⑴因此这里介绍系统对外接口的测试流程

接口组成

1、一个完整的对外接口一般由以下部分组成：

    ⑴请求地址：也就是URL地址

    ⑵请求方法：GET、POST等

    ⑶请求header：部分接口需要header信息(有些可能不需要)

    ⑷请求参数：发送请求时需要传递的数据(参数)，如parmas、body

        ①参数类型：比如JOSN、表单等

        ②请求参数说明：参数描述、参数类型(字符串、整形等)

接口测试

1、接口测试是项目测试的一部分，正如其名，主要测试系统对外部系统提供的接口，验证其正确性和稳定性

2、一般来说接口测试按测试对象分为两种类型：

    ⑴模块接口测试：模块接口测试其实就是单元测试的基础，适用于分别开发一些功能模块

    ⑵外部接口测试：就是测试客户端(第三方用户)与服务端之间的接口

3、接口测试是一种完整的测试体系，也分为接口功能测试、接口性能测试、接口稳定性测试、接口安全性测试

为什么要做接口测试

1、接口测试能使测试团队更早、更深入地介入项目：初期就能发现系统深层次的问题，降低问题修复的时间成本

2、接口是各种系统功能的基础：接口测试介于单元测试与系统测试之间(单元测试一般由开发完成，不要相信开发)

3、接口的变更概率远远小于用户界面的变更概率

    ⑴接口测试自动化维护成本比UI自动化维护成本更低，接口测试相对于更容易实现自动化测试持续集成

    ⑵减少回归测试的人力和时间成本，缩短测试周期(持续集成是接口测试的灵魂)

4、可以发现很多在页面上操作发现不了的bug

    ⑴可能只是在前端做了校验，后端可能没做校验，可通过工具绕过前端校验发送请求到后端

接口测试的原理

1、测试人员借助工具模拟客户端向服务器端发送请求报文，服务器端接收请求报文后，对相应的报文做出处理并向客户端返回应答，工具模拟客户端接收应答，然后测试人员检查应答是否正确

2、比如服务端http接口测试，常用的工具有jmeter、postman、httpclient等

接口测试的范围

关于接口测试的范围，主要从以下两个方面进行介绍：

1、是否所有的接口都需要测试

    ⑴随着系统复杂度越来越高，接口越来越多，想要完全覆盖所有的接口是一件非常困难的事

    ⑵通常情况下，主要测试最外层的两类接口：数据进入系统的接口(调用外部系统的参数为本系统使用)和数据流出系统的接口(验证系统处理后的数据是否正确)

2、被测试接口需要测试哪些方面

    ⑴测试人员需要关注被测试接口的功能是否实现，性能是否达标，安全性是否满足。重点关注数据的交换、传递、处理次数以及控制管理过程

注：

1、上面说的测试范围是对于整个项目而言的。实际中的测试范围还是根据需求文档上来的。需求文档上说要测试什么就测试什么

接口测试流程

1、接口测试也是属于功能测试，所以跟以往的功    能测试流程并没有太大区别，测试流程依旧是：

    ⑴需求文档评审：需求人员编写需求文档后组织需求评审

    ⑵详细设计文档评审：开发人员根据提供的需求文档编写对应的功能详细设计文档并组织评审

    ⑶编写测试计划：测试人员根据需求、是情况等编写测试计划文档

    ⑷编写测试用例：测试人员根据需求文档、详细设计文档编写测试用例并组织评审

    ⑸搭建测试环境：功能提测之后，测试人员根据项目、功能搭建对应的测试环境

    ⑹执行冒烟测试用例：测试人员进行冒烟测试，保证功能主流程是通畅的

    ⑺执行用例：测试人员编写测试用例

    ⑻缺陷管理：测试人员、开发管理BUG

    ⑼测试报告：测试人员编写测试报告

需求文档评审

1、需求人员讲解需求：需要实现哪些功能

2、参与人员对需求提出问题等

详细设计文档评审

1、开发人员根据需求文档编写的功能设计文档，主要包括以下方面：

    ⑴功能主要实现方式

    ⑵功能(接口)详细说明

2、这里的详细设计文档其实就是API文档了：API文档是接口测试中最重要的一个文档

    ⑴如果没有接口文档，可能测试都无法展开

    ⑵接口文档最好详细到接口涉及的每一处

3、一个接口文档主要包含以下部分：

    ⑴接口说明：接口实现什么功能，如何实现(功能逻辑)

    ⑵接口地址：接口URL

    ⑶请求方法：GET、POST等

    ⑷请求header：部分接口需要header信息(有些可能不需要)

    ⑸请求参数：发送请求时需要传递的数据(参数)，如parmas、body

        ①参数类型：比如查询字符串参数、JOSN、表单等

        ②请求参数说明：参数描述、参数类型(字符串、整形等)、参数是否可选等

    ⑹返回数据说明

        ①返回数据格式

        ②需要返回哪些字段

        ③返回字段的说明：类型等

        ④返回字段的数据源：对应哪张表中的哪个字段

4、接口文档越详细越好，感觉特别是接口说明、请求参数、返回数据等一定要清楚

    ⑴比如一个查询接口：查询了哪些表、哪些字段、查询逻辑、返回字段与数据库字段的对应关系等

    ⑵比如一个新增、更新接口：新增到哪张表、新增、更新逻辑、传入参数与数据库字段的对应关系等

    ⑶查询逻辑：比如多表查询时根据哪些字段关联等

    ⑷新增、更新逻辑：比如传入的参数是直接入库还是根据参数在其他表中查询后，将查询结果入库等

编写测试计划

1、接口测试计划与功能测试计划的目标一致，都是为了确认需求、确定测试环境以及测试方法，为设计测试用例做准备，初步制定接口测试进度方案

2、一般来说，接口测试计划包含概述、测试资源、测试功能以及重点，测试策略、测试风险、测试标准等

编写测试用例

1、接口测试用例的设计方法其实和功能测试用例的设计方法是类似的，因为接口是需要满足需求的

    ⑴根据需求文档、接口文档等项目相关文档编写并评审接口测试用例

2、接口测试思路如下图

    ⑴设计测试用例还是需要熟悉业务、功能逻辑，然后根据两者结合来设计、提取测试点

搭建测试环境

1、根据项目实际需要来搭建测试环境

2、现在我们项目主要使用的是Linux系统，服务器包类型是war包和jar包

    ⑴war包：需要放到Tomcat中启动

    ⑵jar包：包内置了Tomcat，因此可以直接驱动

    ⑶因此就需要对需要用到的Linux命令熟悉了

执行用例

1、执行用例前还需要准备测试数据

    ⑴这个的话主要还是根据实际用例场景来准备测试数据

    ⑵我们接口都是操作数据库的，因此查询类接口都是直接使用SQL在数据库中插入测试数据

    ⑶也可以使用相应的增加数据接口来向数据库中插入对应数据

2、执行接口测试用例的话，我们手工执行用例的话使用的是Postman

    ⑴这个工具还是挺简单的，熟悉熟悉就会用例

3、自动化执行测试用例，我们使用的是Python+RF

4、测试过程中可能会使用到mock方法：mock测试就是在测试过程中，对于某些不容易构造或者不容易获取的对象，用一个虚拟的对象来创建以便测试的测试方法

接口测试质量评估标准

1、接口覆盖率是否达到要求

2、业务规则覆盖是否完整

3、参数验证是否达到要求(边界、业务规则)

4、接口异常场景覆盖是否完整

5、代码覆盖率是否达到要求

6、性能指标是否满足要求

7、安全指标是否满足要求

接口自动化

1、目前项目中我负责的业务有报文(XML、JSON报文)解析入库、HTTP接口。这两部分业务的自动化都使用的是Python+RF的方式

    ⑴手工测试完成之后，将对应的手工测试用例转为自动化测试用例    

    ⑵RF框架其实还是挺简单的，其业务层还是使用Python编写的：通过Python代码将业务逻辑实现(类、函数)

        ①在RF层将Python函数封装成对应关键字，然后通过关键字来组装测试用例

        ②用例流程基本上就是手工测试步骤了

2、其目的主要还是用于回归：在新功能提测之后都要跑一边以前版本的自动化用例(保证以前的功能是正确的)

报文解析自动化流程

HTTP接口自动化流程

注：

1、整个自动化流程中还有其他的一些需要注意：

    ⑴数据库的连接：RF中虽然提供了数据库连接的关键字，但是我们使用的连接方法、查询方法等都是自己写的

        ①RF中其实也提供了requests对应的关键字，但是感觉不好用，因此发送请求的方法也是自己封装的

    ⑵数据的处理：

        ①比如查询数据、请求参数的合并、替换等

            ㈠请求参数中有两个字段，但是入库时是将两个字段合并后入库的

            ㈡请求参数中传递的是事件代码，但是实际入库的是经代码查询的描述信息

        ②一定需要将数据处理好，这样在对比时才不会出现问题

2、数据对比：主要使用的是集合的对称差属性来进行对比的

    ⑴一般情况下都是将查询结果、请求参数等整理成一个字典{}或者是嵌套了字典的列表[{},{}...]，然后使用集合对称差属性来进行对比

    ⑵在对比时首先需要保证两个对比数据中键名得是一样的：键名都不一样对比结果肯定不一样

    ⑶如果是两个字典{}数据对比的话，就简单的多：直接将字典转为集合，然后使用集合的对称属性来比较

    ⑷如果是两个嵌套了字典的列表[{},{}...]数据对比的话，就会麻烦得多：

        ①首先从两个数据源中获取出需要对比的两个字典：这里使用的是数据库主键及其值(如ID)来获取两个需要对比的字典，毕竟主键:值是不可能重复的，这样就确定了两个数据源中的唯一字典

        ②然后对比获取到的两个字典

        ③然后循环获取下一组需要对比的字典，直到对比完全部字典数据，然后返回最终对比结果

接口自动化测试持续集成的要点

进行项目测试时，接口会增加、减少或变更，测试用例也会相应更新，因此需要借助工具(如GitHub等)来维护测试用例进行持续集成，通过自动化测试实时监控项目接口运行情况。对接口测试而言，持续集成是核心内容，通过自动化的手段才能做到低成本、高收益。接口自动化测试持续集成主要包括以下内容：

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

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

3、问题定位：报错信息、日志更加精确，方便问题的复现和定位

4、结果校验：加强自动化校验能力，如数据库信息校验

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

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

前言：

　　本文主要针对http接口进行测试，使用Jmeter工具实现。

　　Jmter工具设计之初是用于做性能测试的，它在实现对各种接口的调用方面已经做的比较成熟，因此，本次直接使用Jmeter工具来完成对Http接口的测试。

一、开发接口测试案例的整体方案：

• 第一步：我们要分析出测试需求，并拿到开发提供的接口说明文档；

• 第二步：从接口说明文档中整理出接口测试案例，里面要包括详细的入参和出参数据以及明确的格式和检查点。

• 第三步：和开发一起对接口测试案例进行评审。

• 第四步：结合开发库，准备接口测试案例中的入参数据和出参数据，并整理成csv格式的文件。

• 第五步：结合接口测试案例文档和csv格式的数据文档，做接口测试案例的自动化案例开发。

二、接口自动化适用场景：

 目前设计的自动化接口测试案例有两个运行场景：

　　1. 测试前置、开发自测：一个新的自动化接口测试案例开发完成后，直接发给接口对应的开发，安排在开发本地环境执行，一旦开发确认完成接口开发，就开始执行接口测试案例，基本上可以实时拿到测试结果，方便开发快速做出判断。【开发本地运行的方式就是打开JMeter工具，导入JMX文件，开始执行可。】

　　2. 回归测试：开发本地测试通过后，或整个需求手工测试通过后，把自动化的接口测试案例做分类整理，挑选出需要纳入到回归测试中的案例，在持续集成环境重新准备测试数据，并把案例纳入到持续集成的job中来，这些用于回归的接口测试案例需要配置到持续集成平台自动运行。

三、接口测试环境准备

• 　Jdk1.6或以上：Java Downloads | Oracle

• 　Jmeter，下载址址：Apache JMeter - Download Apache JMeter

• 　插件的下载安装地址：JMeter Plugins :: JMeter-Plugins.org

四、创建工程：

　　1、打开Jmeter：下载好Jmeter后，双击bin目录下的jmeter.bat文件：

　　2、添加线程组：在“测试计划”上点击鼠标右键-->添加-->threads(Users)-->线程组，添加测试场景设置组件，接口测试中一般设置为1个“线程数”，根据测试数据的个数设定“循环次数”。

　　3、添加“HTTP Cookie管理器”：

　　4、添加“Http请求默认值”组件，当被测系统有唯一的访问域名和端口时，这个组件很好用：

　　5、在“HTTP 请求默认值”组件配置页面，填写被测系统的域名和端口，http请求的实现包版本以及具体协议类型，线程组里的所有“HTTP Sampler”可默认使用此设置。

　　6、在“线程组”里添加“HTTP 请求”的Sampler

 　　7、在HTTP请求设置页面，录入被测接口的详细信息，包括请求路径，对应的请求方法，以及随请求一起发送的参数列表：

　　8、设置检查点：在被测接口对应的“HTTP 请求”上，添加“响应断言”

　　9、在设置页面上添加对相应结果的正则表达式存在性判断即可：

　　10、添加监听器：方便查看运行后的结果

 　　运行结果：

　　上述步骤完成了一个简单测试案例的创建，复杂测试案例均在此基础上扩展完成。使用Jmeter工具开发的接口测试案例，一个子系统建议放在同一个 “测试计划”中，流程测试可以通过“线程组”来区分，这样也便于设定不同的测试数据个数。比较独立的接口，可以统一放在一个线程组内，顺序完成测试。　　

　　流程性接口的测试：如果要测试的接口可以组成一个流程，只需要顺序添加多个“HTTP 请求”的Sampler，各请求之间可以提取需要在上下文传递的数据作为参数，以保证流程中数据的一致性。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。