1 什么是接口测试

1.1 接口测试简介

点击查看博文 https://www.cnblogs.com/fnng/p/4790294.html
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

1.2 Api/接口测试的目的和意义

API（Application Programming Interface）自动化测试是软件测试中最基本的一种类型。API就像建造大楼的砖块，程序开发人员通过运用一定规则将"砖块"放在一起来构造程序，从本质上来说，API测试是用来验证组成软件的那些单个方法的正确性，而不是测试整个系统本身。

API测试又称为接口测试，接口测试是功能测试的一种。它主要借助于单元测试技术，通过模拟上层应用或者系统上层调用接口的应用场景，是对系统接口功能进行测试的一种手段。在进行接口测试的过程中，测试工程师并不需要了解被测试系统的所有代码，而主要通过分析接口定义以及模拟接口调用的业务应用场景来进行测试用例的设计，从而达到对被测试系统功能进行测试的目的。接口测试的重点是要检查数据的交换、传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

接口测试一般应用于多系统间交互开发，或者拥有多个子系统的应用系统开发的测试。接口测试适用于为其他系统提供服务的底层框架系统和中心服务系统，主要测试这些系统对外部提供的接口，验证其正确性和稳定性。接口测试同样适用于一个上层系统中的服务层接口，越往上层，其测试的难度越大。

接口测试实施在多系统多平台的构架下，有着极为高效的成本收益比。接口测试天生为高复杂性的平台带来高效的缺陷检测和质量监督能力。平台越复杂，系统越庞大，接口测试的效果越明显。

1.2.1 接口测试的目的

接口测试是测试接口，尤其是那些与系统相关联的外部接口。接口测试的核心战略在于：以保证系统的正确和稳定为核心，以持续集成为手段，提高测试效率，提升用户体验，降低产品研发成本。
　　■ 核心：保证系统的稳定
　　质量管理的目标是保证系统的正确和稳定，接口测试作为软件质量管理的一部分也保证系统正确和稳定，更准确地说是保证系统服务端的正确和稳定。一个系统的服务端越接近底层，对系统的影响就越大，甚至有可能牵一发而动全身，服务端的一个缺陷可能会引起客户端的几个甚至十几个缺陷，更可怕的是服务端的缺陷有可能引起系统的崩溃，这对整个系统来说，损失将是不可估量的，因此服务端接口的质量将直接影响到系统的正确和稳定。
　　■ 目的：提高测试效率，提升用户体验，降低产品研发成本
　　接口测试要为代码的编写保驾护航，增强开发人员和测试人员的自信，让隐含的Bug提前暴露出来，让开发人员在第一时间修复Bug，让功能测试人员和性能测试人员在测试的时候更加顺手，最大限度得减少底层Bug的出现数量，让产品研发的流程更加顺畅，要缩短产品的研发周期，最后在产品上线以后，要让用户用得更加便捷，要让用户感觉产品服务零缺陷。

1.2.2 接口测试的意义

接口测试是单元测试的一个子集，但又不等同于单元测试。从测试的角度来看，接口测试的价值在于其测试投入比单元测试少，而且技术难度也比单元测试小。一般来说，接口测试的粒度要比单元测试更粗，它主要是基于子系统或者子模块的接口层面的测试。因此，接口测试需要测试的接口或者函数的数量会远远小于单元测试，与此同时，接口定义的稳定性会远远高于类级别的函数。所以，接口测试用例代码的改动量也远远小于单元测试，代码维护成本会比单元测试少很多，因而测试的投入量会小很多。从另外一个层面来看，借助于接口测试，可以保证子系统或子模块在各种应用场景下接口调用的正确性，那么子系统或子模块的产品质量也可以得到充分的保证。因此，接口测试是一种适度的白盒测试技术，准确说它是一种灰盒测试，投入产出是非常理想的。

总的来说，接口测试是保证高复杂性系统质量的内在要求和低成本的经济利益的驱动作用下的最佳解决方案。主要体现在下面的三个方面：

• 首先，接口测试节省了测试成本，根据数据模型推算，底层的一个Bug能够引发上层8个左右Bug，而且底层的Bug很容易引起全网的死机。相反接口测试能够提供系统复杂度上升情况下的低成本高效率的解决方案。
• 其次，接口测试不同于传统开发的单元测试，接口测试是站在用户的角度对系统接口进行全面高效持续的检测。
• 最后，接口测试是自动化并且持续集成的，这也是为什么接口测试能够低成本高收益的根源。

1.3 接口测试相关术语

HTTP（Hypertext Transport Protocol--超文本传输协议）：是一种通信协议，详细规定了浏览器和万维网服务器之间互相通信的规则，通过因特网传送万维网文档的数据传送协议。
JMS（Java Message Service--Java消息服务）：应用程序接口是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。
REST（Representational State Transfer--表述性状态转移）：是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。
SOAP（Simple Object Access Protocol--简单对象访问协议），或面向服务交换架构协议）：是一种轻量级的、简单的、基于XML 的协议，它被设计成在Web上交换结构化的和固化的信息。SOAP 可以和现存的许多因特网协议和格式结合使用，包括超文本传输协议（HTTP）、简单邮件传输协议（SMTP）、多用途网际邮件扩充协议（MIME）。它还支持从消息系统到远程过程调用（RPC）等大量的应用程序。
TEST：测试中描述用户执行的步骤，它模拟了真实用户使用应用程序的行为。
UDDI（Universal Description Discovery and Integration--统一描述、发现和集成协议）：UDDI是一个用来发布和搜索WEB服务的协议，应用程序可借由此协议在设计或运行时找到目标WEB服务。
Web services：Web Service是基于网络的、分布式的模块化组件，它执行特定的任务，遵守具体的技术规范，这些规范使得Web Service能与其他兼容的组件进行互操作。Web Services 主要利用 HTTP 和 SOAP 协议使商业数据在 Web 上传输，SOAP通过 HTTP 调用商业对象执行远程功能调用，Web 用户能够使用 SOAP 和 HTTP通过 Web 调用的方法来调用远程对象。
XML：（Extensible Markup Language--可扩展标记语言）：用于标记电子文件使其具有结构性的标记语言，可以用来标记数据、定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言。XML是标准通用标记语言（SGML）的子集，非常适合Web传输。XML提供统一的方法来描述和交换独立于应用程序或供应商的结构化数据。
XSD（XML Schema Definition）：XML Schema 是DTD的替代品。XML Schema语言也就是XML Schema Definition（XSD）。XML Schema描述了XML文档的结构。可以用一个指定的XML Schema来验证某个XML文档，以检查该XML文档是否符合其要求。文档设计者可以通过XML Schema指定一个XML文档所允许的结构和内容，并可据此检查一个XML文档是否是有效的。XML Schema本身是一个XML文档，它符合XML语法结构。可以用通用的XML解析器解析它。
WSDL（web service description language--web服务描述语言）：它是基于XML的用于描述 Web Services以及如何访问Web Services的语言。它是一个XML文档。用于说明一组SOAP消息以及如何交换这些消息。
JSON：JSON(JavaScript Object Notation, JS 对象标记) 是一种轻量级的数据交换格式。它基于 ECMAScript (w3c制定的js规范)的一个子集，采用完全独立于编程语言的文本格式来存储和表示数据。简洁和清晰的层次结构使得 JSON 成为理想的数据交换语言。 易于人阅读和编写，同时也易于机器解析和生成，并有效地提升网络传输效率。

1.4 接口测试流程

1、 通过抓包工具或者开发人员提供接口的出入参数和请求地址
2、 了解被测接口业务，分析接口中可变的参数字段含义
3、 编写接口测试用例
4、 利用接口测试工具根据测试用例对接口进行测试
5、 完成测试报告，整理保存测试脚本以便下次继续使用

2 测试工具下载

百度云：http://pan.baidu.com/s/1slDOJ2t
包含jmeter/soapui/postman/chrome/Fiddler等

3 接口测试工具教程

3.1 Soapui、Jmeter、postman工具比较

参考 https://blog.csdn.net/huilan_same/article/details/75413482

3.2 工具使用教程

在本机上安装JDK环境，安装教程：
https://jingyan.baidu.com/article/48b558e35008cb7f38c09a3e.html
jdk软件同样在上面的测试工具中
安装完成jdk之后
解压apache-tomcat-7.0.54.rar到任意目录，进入到apache-tomcat-7.0.54的bin目录，双击startup.bat 脚本启动，如图所示，启动完成。

打开 浏览器输入：http://localhost:8080/MockService/rest/GBQ_ChargeInfo
如下显示即为正常:

备注：本次模拟的4个接口你可以在测试工具下载中的 接口测试.txt 文件中找到出入参和请求地址。

3.2.2 使用Postman进行接口测试

3.2.2.1 安装Postman到chrome浏览器

解压Postman_v4.1.3.zip到任意目录，打开chrome浏览器，在地址栏输入：chrome://extensions/ 并回车
将开发者模式打上勾，点击 ，打开文件窗口选择刚才解压的Postman_v4.1.3文件夹

安装完成：

点击 启动 即可打开Postman插件

3.2.2.2 简单的HTTP测试

下拉框选择Post

在地址栏输入：http://localhost:8080/MockService/rest/GBQ_ChargeInfo
按照图示顺序进行操作，然后点击 按钮

图示表示已成功发送请求，并且得到可该接口的返回内容。

3.2.2.3 创建测试用例集

点击Collections

点击添加新的Collections

创建好的Collections

点击新创建的Collection可查看详细信息：

可通过点击 在Collection中添加文件夹，文件夹Folder可以与请求Request同级并存

点击 将刚才测试的接口信息保存到新建的Collection中

按照之前的步骤将其他两个Http接口（QryDataFlow 和UserOrdInfoQry）也加入到该Collection中

关闭工具，在下次打开时这些接口信息会依然存在

3.2.2.4 接口返回验证

在实际测试过程中，我们可以通过手动查看接口的返回并分析来验证接口是否正常，如果要测试的接口多达几十个并且需要每隔几天全量测试一次，这样使用手动验证返回的方式显然太繁琐和麻烦。

我们可以使用js代码给每个接口带上预设的返回验证规则，这样在实际测试过程中，只需要关注那些验证不通过的接口，从而大大减少一些重复的手工操作。

首先打开任意一个接口，点击 tests

在tests的右侧Postman给我们预先设置一些常用的代码片段，通过揣测字面意思我们大概能知晓其中的含义

例如：
验证响应时间是否少于200ms
验证返回状态码是否为200
验证返回消息头Content-Type

点击代码片段则会在左侧窗口生成对应的js代码

我们可以手动更改一些值，或者填写新的验证规则

如上图，我们修改了一处验证并新增了一个验证

tests["Response is OK"] = responseBody.has("\"RETURN_CODE\":\"0\"")

此处验证了在返回的报文中是否包含字符串"RETURNCODE":"0"

点击发送请求，我们可以看到我们添加的4条验证均通过

更多的验证规则说明和技巧请参考
http://blog.csdn.net/willcaty/article/details/65631811

按照以上步骤我们给剩下的两个接口同样增验证规则，测试通过之后点击 保存

注意：请观察不同接口的返回内容是否不一样。

3.2.2.5 运行测试用例集

在Collection详情页面点击

点击

查看右侧测试结果，测试验证均为Pass

3.2.3 使用SoapUI进行接口测试

3.2.3.1 安装SoapUI

双击SoapUI-x32-5.2.1.exe进行安装即可。

3.2.3.2 简单的HTTP测试

打开SoapUI，新建一个项目实例如下：

选择此项目右键，新建一个用例组

选中测试组名称右键新建测试用例

创建测试步骤：

注：此处选择HTTP Test Request，接口有哪些类型可自己百度，或者不清楚所测接口是什么类型可与开发确认

如图填写相关信息直接点击OK

选择MediaType为application/json，同时在下方编辑框输入入参报文

如果请求的URL地址中有大写字母，则需要进行以下操作：

在左侧菜单栏下面打开HTTP TestRequest Properties，将有大小写字母的请求地址填入到Endpoint一栏即可。

点击发送请求，查看接口返回内容是否正常

3.2.3.3 创建测试组TestSuite

在SoapUI中一个完整的测试用例组织结构如下：

对应的说明如下：

3.2.3.4 返回验证

你可以根据以下操作完成一个简单的返回验证，如果需要更加复杂的验证操作请自行百度 SoapUI和Groovy。
参考：http://blog.csdn.net/tz0705010216/article/details/39204431

主要对返回报文结果进行一些验证，在右侧栏中，SoapUI为我们预置了几种快捷验证：
我们选择Contains


在 Content 中填入内容，此处是表示返回的结果报文里应该包含的字段。
点击确定，然后点击左上角执行按钮 ，执行结束之后我们可以看到
，表示此处的断言通过。

3.2.3.5 运行测试用例集

双击创建测试集

点击 执行用例集

查看运行结果

3.2.4 使用Jmeter进行接口测试

3.2.4.1 安装Jmeter

将 下载的apache-jmeter-2.13.rar解压到任意目录中，进入apache-jmeter-2.13\bin目录，双击打开 打开jmeter工具

3.2.4.2 简单的HTTP测试

右键点击 如图所示新建一个线程组

如图所示新建一个HTTP请求

注意 方法请选择 POST， 下方选择 BodyData 并输入入参报文

右键添加一个监听器-查看结果树

完成之后的结果如下：

点击上方工具栏中的执行按钮

会提示你保存测试脚本，点 是 选择保存

查看 响应数据 是否正确：

3.2.4.3 返回验证

右键 添加一个 断言 -> 响应断言

点击 运行并在 查看是否测试正常

尝试将响应断言中的值修改为其他值，再次运行，查看会出现什么情况？

3.2.4.4 运行测试集

在 线程组 中继续添加另外两个接口并为每一个请求做一个正确的响应断言

点击上方 运行 按钮

3.2.5 导入脚本文件

3.2.5.1 脚本文件

Jmeter/soapUI/postman 相关脚本文件位于 scripts 文件中

Postman导入文件:

Jmeter脚本文件:

SoapUI脚本文件:

3.2.5.2 导入方式

Postman

Jmeter

SoapUI