Jmeter接口测试

1. 接口测试是什么
   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. 怎么作接口测试
   
   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数据驱动定义：一、从数据文件中读取测试数据，驱动测试过程的一种测试方法。二、数据驱动能够理解为更高级的参数化。特色：一、测试数据与测试代码分离。二、数据控制过程。好处：一、减小测试代码量。二、下降脚本开发和维护的成本。三、便于用例的修改和维护（不用修改代码）。