- 接口测试是什么
1.1接口
API（Application Program Interface）接口属于操作系统的程序接口。
GUI （Graphic User Interface）接口，属于一种图形接口。
2者都是用户接口。有时候公司将API作为为公共接口，对外开放。
1.2接口测试
接口测试是测试系统组件间的一种测试
接口测试主要用于检查外部系统和系统之间以及内部各个子系统之间的交互点。
1.3接口测试目的
提供测试效率，提供用户体验度，减少研发成本
对系统接口进行全面（功能，安全，性能）高效的持续的测试；
接口测试是一个完整的系统，包括了功能测试，部分的安全测试，性能测试。
可以发现很多页面上发现不了的bug
检查系统的异常处理能力
前端随意变，接口测好了，后端不用变
1.4接口测试工具
HTTPWatch，Fildder，浏览器自带F12，BurpSuit、LoadRunner，Soapui、jmeter，postman
1.4.1客户端请求消息
请求消息包括以下格式：请求消息包括以下格式：请求行（request line）、请求头部(header)、空行和请求数据4个部分组成。如图1所示：
1.4.2服务端响应消息：
HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。如图2所示：
1.4.3请求方法
请求方法如图3所示：
以GET请求为例：
login.action?name=hyddd&password=idontknow&verifly=%E4%BD%E5%A5%BD
以？来分隔URL和数据；以&来分隔参数；如果数据是英文或数字，原样发送；如果数据是中文或其他字符，则进行BASE64编码。
1.4.4常见状态码
200 请求成功
301 资源（网页等）被永久转移到其他URL
404 请求的资源（网页等）不存在
500 内部服务器错误 - 怎么做接口测试
2.1接口用例设计
接口测试用例设计的重点，在于功能性的业务逻辑检查和参数检查。
(1). 功能：检查接口基础功能，是否完成了业务逻辑要求。此处的用例设计方法，和普通的测试用例设计方法一样。可以把接口当作一个待测模块，分析接口功能需求，利用常规用例方法设计测试用例。
等价类划分法
边界值分析法
错误推测法
因果图法
判定表驱动法
正交试验法
场景图法
(2). 数据：分析接口的输入参数，覆盖各种可能的场景。
检查接口的输入，数据格式、数据类型、数据范围等
检查接口的参数边界（传递的参数足够大或者为负、空值时）
检查接口的参数的组合，可选、必选等
检查接口的约束条件，是否符合约束条件的，是否需要设计用例
(3). 性能：接口是否造成性能瓶颈，能承受的压力范围
(4). 安全：接口是否涉及安全性
2.2什么样的脚本，是一个好的脚本
自动化脚本规范：
(1）.一个脚本是一个完整的场景，覆盖到正常异常业务场景（L0，L1，L2）。
(2).一个脚本只验证一个功能点，不要试图用户登陆系统后把所有的功能都进行验证，再退出系统。
(3).脚本之间不要产生关联性，也就是说编写的每一个脚本都是独立的，不能依赖或影响其他脚本。
(4). 如果对数据进行了修改，需要对数据进行还原。【后置步骤】
(5). 测试用例的上下文必须有一定的顺序性，要能够互相连接起来；并且前置条件要清楚。
(6). 每个测试用例粒度必须尽可能小，短小简单的测试用例易于调试。如果测试用例不得不长而复杂，则把它分成两个或更多的私有方法，并单独调用这些方法。
(7). 尽量把重复任务放入一个方法中，这样它可以被多个测试用例调用。
(8). 测试用例要有合适的验证点，符合测试用例的期待结果。验证：如文件存在，数据库的表字段，接口返回的消息。
3.jmeter基本使用
3.1安装与配置
配置Jdk1.8或以上
Jmeter下载址址：http://jmeter.apache.org/download_jmeter.cgi
Jmeter启动：解压，bin目录下运行ApacheJMeter.jar进行启动。
Jmeter 文件目录介绍
bin：可执行文件目录
Bin目录文件
jmeter.bat：windows的启动文件
jmeter.log：日志文件
jmeter.sh：linux的启动文件
jmeter.properties：系统配置文件
docs：接口文档目录
extras：扩展插件目录
lib：所用到的插件目录，里面全是jar包，JMeter 会自动在 JMETER_HOME/lib 和 ext 目录下寻找需要的类
Licenses jmeter证书目录
printable_docs用户使用手册
3.2接口测试过程
3.2.1Jmeter页面
Jmeter页面如图6所示：
3.2.1.1测试计划
新建测试计划过程如图7所示：
作用：
• 本次测试所需要的【组件】都是基于测试计划添加；
• 本次测试所有组件的设置与执行都基于测试计划；
• 组件：完成指定功能代码段的封装；
3.2.1.2线程组
Threads (Users)线程 用户
setup thread group
一种特殊类型的ThreadGroup的，可用于执行预测试操作。这些线程的行为完全像一个正常的线程组元件。不同的是，这些类型的线程执行测试前进行定期线程组的执行。
teardown thread group.
一种特殊类型的ThreadGroup的，可用于执行测试后动作。这些线程的行为完全像一个正常的线程组元件。不同的是，这些类型的线程执行测试结束后执行定期的线程组。
thread group(线程组)
这个就是我们通常添加运行的线程。可以看做一个虚拟用户组，线程组中的每个线程都可以理解为一个虚拟用户。线程组中包含的线程数量在测试执行过程中是不会发生改变的。右键点击“测试计划” -> “添加”-> “Threads(Users)” -> “线程组” 分别如图8和图9所示。
• 线程数：虚拟用户数。一个虚拟用户占用一个进程或线程。设置多少虚拟用户数在这里也就是设置多少个线程数。
• Ramp-Up Period(in seconds)准备时长：设置的虚拟用户数需要多长时间全部启动。如果线程数为10，准备时长为2，那么需要2秒钟启动10个线程，也就是每秒钟启动5个线程。
• 循环次数：每个线程发送请求的次数。如果线程数为10，循环次数为100，那么每个线程发送100次请求。总请求数为10*100=1000 。如果勾选了“永远”，那么所有线程会一直发送请求，一到选择停止运行脚本。
• Delay Thread creation until needed：直到需要时延迟线程的创建。
• 调度器：设置线程组启动的开始时间和结束时间(配置调度器时，需要勾选循环次数为永远)
• 持续时间（秒）：测试持续时间，会覆盖结束时间
• 启动延迟（秒）：测试延迟启动时间，会覆盖启动时间
3.2.1.3添加http请求
右键点击“线程组” -> “添加” -> “Sampler” -> “HTTP请求”
接口地址：http://www.baidu.com/s?ie=utf-8&wd=jmeter接口测试
图10和图11所示：
一个HTTP请求有着许多的配置参数，下面将详细介绍：
名称：本属性用于标识一个取样器，建议使用一个有意义的名称。
注释：对于测试没有任何作用，仅用户记录用户可读的注释信息。
服务器名称或IP ：HTTP请求发送的目标服务器名称或IP地址。
端口号：目标服务器的端口号，默认值为80 。
协议：向目标服务器发送HTTP请求时的协议，可以是http或者是https ，默认值为http 。
方法：发送HTTP请求的方法，可用方法包括GET、POST、HEAD、PUT、OPTIONS、TRACE、DELETE等。
Content encoding ：内容的编码方式，默认值为iso8859
路径：目标URL路径（不包括服务器地址和端口）
自动重定向：如果选中该选项，当发送HTTP请求后得到的响应是302/301时，JMeter 自动重定向到新的页面。
Use keep Alive ： 当该选项被选中时，jmeter 和目标服务器之间使用 Keep-Alive方式(又称持久连接、连接重用)进行HTTP通信，默认选中。
Use multipart/from-data for HTTP POST ：当发送HTTP POST 请求时，使用Use multipart/from-data方法发送，默认不选中。
3.2.1.4Jmeter参数化
方式一：
添加用户自定义变量
我们可以添加用户自定义变量用以Http请求参数化，右键点击“线程组” -> “添加” -> “配置元件” -> “用户定义的变量”。图12所示：
新增一个参数wd，存放搜索词"自动化测试"，如图13所示：
并在Http请求中使用该参数，格式为：${wd} ，如图14所示：
方式二："CSV 数据文件设置"
1.新建一个csv文件，保存如下数据：注意使用notepad编辑，将其转换为utf-8编码方式，否则中文在jmeter中显示乱码
2.右键点击“线程组” -> “添加” -> “配置元件” -> “CSV 数据文件设置”：如图15和图16所示：
在Http请求中使用该参数，格式为：${keyword} ，并运行可以在结果树中查看到如下结果，则表示已从csv文件中读取对应的参数。如图17所示：
3.2.1.5响应断言
右键点击“HTTP请求” -> “添加”-> “断言” -> “响应断言” ，如图18所示：
校验返回的文本中是否包含搜索词，添加参数${keyword}到要测试的模式中：如图19所示
模式匹配规则
• 包括：支持纯文本和正则，验证返回包括指定的内容
• 匹配：支持纯文本和正则，正则需全匹配（正则必须匹配全部返回，而非部分返回）
• Equals：字符串相等，纯文本匹配，验证返回结果和指定结果完全一致
• SubString：字符串包含，纯文本匹配，验证返回结果包含指定结果
• 否：结合上述条件取反，若上述断言结果为false，取否后，最终断言结果为true
3.2.1.6Json断言
Json断言是针对Json报文的断言方式，通Json Path提取出Json响应报文中的字段，再采用纯文本或者正则去验证Json Path的提取结果，Json结合了Json Path和正则表达式，有如下选项：
• Additionally assert value：文本验证，此处是完全匹配，勾选上此选项后再勾选Match as regular expression，可以触发正则匹配。
• Match as regular expression：支持正则表达式匹配
• Expect null：判定返回为null
• Invert assertion：倒置断言结果
如图20所示:
3.2.1.7正则表达式提取器
正则表达式部分配置说明
（1）引用名称：下一个请求要引用的参数名称，如填写uuid，则可用${uuid}引用它。
（2）正则表达式：
()括起来的部分就是要提取的。
.匹配任何字符串。
+：一次或多次。
?：在找到第一个匹配项后停止。
（3）模板：用$$引用起来，如果在正则表达式中有多个正则表达式（多个括号括起来的东东），则可以是$2$$3$等等，表示解析到的第几个值给title。如：$1$表示解析到的第1个值
（4）匹配数字：0代表随机取值，1代表全部取值，
（5）缺省值：如果参数没有取得到值，那默认给一个值让它取。
3.2.1.8Json提取器
详见图21所示：
3.2.1.9添加察看结果树
右键点击“线程组” -> “添加” -> “监听器” -> “察看结果树”
详见图22所示
这时，我们运行Http请求，修改响应数据格式为“HTML Source Formatted”，可以看到本次搜索返回结果页面标题为”jmeter接口测试_百度搜索。如图23所示：
4.jmeter数据驱动
定义：
1、从数据文件中读取测试数据，驱动测试过程的一种测试方法。
2、数据驱动可以理解为更高级的参数化。
特点：
1、测试数据与测试代码分离。
2、数据控制过程。
好处：
1、减少测试代码量。
2、降低脚本开发和维护的成本。
3、便于用例的修改和维护（不用修改代码）。
来源：51CTO
作者：siyecao5996
链接：https://blog.51cto.com/14647406/2463401