不会代码的时候，如何使用 jmeter 完成接口测试

Posted 2022-11-23 酔清风

1.接口测试简介

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

2.接口测试流程

接口测试的流程和功能测试流程类似，依据的对象是需求说明书和接口需求，接口测试流程如下：

3.接口测试范围

1)     业务功能（包括正常、异常场景是否实现）
2)     业务规则（覆盖度是否全面）
3)     参数验证（边界、业务规则是否达到要求）
4)     异常场景（重复提交、并发提交、事务中断、多机环境、大数据量测试）
5)     性能测试（响应时间、吞吐量、并发数、资源要求）
6)     安全测试（权限验证、SQL 注入等）

4.接口测试重点

1. 检查接口的功能：检查接口的功能有没有实现，也就是请求会不会成功，如果不成功会不会返回错误代号（或错误信息）
2. 检查接口返回的数据：检查接口返回的数据、数据格式、数据类型是否与预期一致（正向且传递的参数正常）；
3. 检查接口的容错性：接口是否可以正常处理（假如传递的参数足够大或者为负、空值时）
4. 检查接口的性能：http 请求接口大多与后端执行的 SQL 语句性能、算法等比较相关。
5. 检查接口的安全性：外部调用的接口尤为重要

5.接口测试需求分析

1. 首先根据接口设计的技术架构方案，了解清楚被测接口对应的公共入参、入参、出参及返回数据的 Json 结构规范，根据测试场景进行测试。
2. 理解接口参数，熟悉接口参数的输入要求、输入值范围、必填项等；
3. 理解接口输出，熟悉返回 json 的结构构成、返回值类别、返回值范围、返回 data 的不同类型等。
4. 理解接口的逻辑、接口的业务关联，熟悉技术方案中的接口相互关联、依赖的关系，接口与接口之间的数据传递等。
5. 寻找测试点，根据输入 (参数名、取值范围)、输出 (参数名、返回值范围)、关联关系，进行测试点分析；

6.接口测试用例设计

接口测试的主要测试对象是接口，但是随着系统复杂度越来越高，接口越来越多，完全覆盖所有接口是很难的一件事情，并且实际过程中任意内部接口的变动都可能导致我们的测试用例的不可用。

接口用例设计优先级

优先级-->针对所有接口
暴露在外面的接口，因为通常该接口会给第三方调用；
供系统内部调用的核心功能接口；
供系统内部调用非核心功能接口；
优先级-->针对单个接口
正向用例优先测试，逆向（异常）用例次之 (通常情况，非绝对)；
是否满足前提条件 > 是否携带默认参值参数 > 参数是否必填 > 参数之间是否存在关联 > 参数数据类型限制 > 参数数据类型自身的数据范围值限制

接口用例设计方法

测试用例编写注意事项

是否满足前提条件	有些接口需要满足前置条件，才可成功获取数据。常见的，需要登陆 Token。逆向用例：针对是否满足前置条件 (假设为 n 个条件)，设计 0~n 条用例
是否携带默认值参数	正向用例：带默认值的参数都不填写、不传参，必填参数都填写正确且存在的 “常规” 值，其它不填写，设计 1 条用例；
业务规则、功能需求	这里根据实际情况，结合接口参数说明，可能需要设计 n 条正向用例和逆向用例
参数是否必填	逆向用例：针对每个必填参数，都设计 1 条参数值为空的逆向用例
参数之间是否存在关联	有些参数彼此之间存在相互制约的关系,逆向用例：根据实际情况，可能需要设计 0~n 条用例
参数数据类型限制	逆向用例：针对每个参数都设计 1 条参数值类型不符的逆向用例
参数数据类型自身的数据范围值限制	正向用例：针对所有参数，设计 1 条每个参数的参数值在数据范围内为最大值的正向用例,逆向用例：针对每个参数 (假设 n 个)，设计 n 条每个参数的参数值都超出数据范围最大值的逆向用例,针对每个参数 (假设 n 个)，设计 n 条每个参数的参数值都小于数据范围最小值的逆向用例

进行测试执行编写时，有如下的原则：

1.不同的接口参数覆盖不同的业务场景；
2.在后台构造合适的数据来满足接口的测试用例；
3.根据接口的返回值，断言其是否返回期望结果，并查看数据库验证；
4.测试用例涉及多个步骤的，应对涉及的步骤都验证
5.删除测试过程中产生的结果，确保每个用例执行前都是一个清洁的环境

7.接口测试用例模板

8.接口数据准备

9.接口测试工具

接口测试工具选择

1. 接口工具：Postman/Jmeter/SouapUI/python，单个接口测试时使用 Postman，多个接口测试时可以使用 Jmeter，或者使用 python 脚本；
2. Jmeter：可以测试各种类型的接口，不支持的也可以通过网上或自己编写的插件进行扩展。
3. postman：功能上更简单，组织方式也更轻量级，它主要针对的就是单个的 HTTP 请求。 接口测试工具根据对比

   

   抓包工具 个人比较喜欢 Charles,但是也可以使用 fiddler 或者其他的抓包工具

jmeter 使用 dome

10.接口测试原则

（1）    基础配置，如域名、环境配置等，单出文件配置，方便不同环境测试、脚本维护
（2）    明确接口实现什么样的功能，实际需要什么样的功能，是否一致
（3）    接口测试数据太多，用该数据驱动模式更有层次，且易于维护
（4）    要在众多测试用例中选出冒烟测试用例及可用于性能测试的用例
（5）    先单接口测试，在多接口业务测试
（6）    测试完成以后，需要清洗脏数据
 

11.接口测试执行实例

11.1 使用 Jmeter 测试接口实例

接口测试环境准备

1. Jdk1.8 或以上：Java Downloads | Oracle
2. Jmeter 下载址址：Apache JMeter - Download Apache JMeter
3. 插件的下载安装地址：JMeter Plugins :: JMeter-Plugins.org

12. 如何快速生产脚本生成

• 既然使用到了 jmeter 团队又是多人的情况下，那么 jmeter 脚本的生产力是一个很大的问题，再加上团队不是每个人对 jmeter 的熟悉程度都是不一样的，所以脚本的编写和快速生产就是个问题，针对这个个人建议脚本的生产建议从以下几个方面考虑
• 使用 jemter 原生的录制器
• 手写 jmeter 脚本，但是需要对 jmeter 相对熟悉，
• 使用 fiddles 抓包工具导出生产
• 针对 web 页面个人推荐 BlazeMeter 的谷歌插件

针对以上五种生产 jmeter 脚本快速生产的方案，都可以很好的辅助编写 jmeter 的脚本，在这里很多同学肯定会问为什么不使用 metersphere，这个项目本身很优秀了，但是由于公司的原因，所以最后放弃，很多同学肯定想，录制生成，直接回访就完事，我只能说太简单，这样你的脚本使用一次基本就报废， 会造成脚本的重复编写费时费力，这个时候，需要测试强硬一点了大家采用统一的录制控制方式去录制，同意脚本编写的方案，毕竟在怎么录制都是不行的，所以最好的实践方式就是采用录制为主，修改为辅的解决方式，去编写复用率高的脚本

13.团队协作落地

相信 jmeter 很多测试小伙伴都很熟悉，肯定也都熟悉他有一个最大通病，就是 case 太多的时候，一点都不方便管理， 其实这个问题，我也遇见了，因为现在的团队不只是我一个人单打独斗，我还有队友，所以对 jmx 脚本的管理，我在团队里面采用的时 git 管理我们的脚本，我们在团队内部和开发约束，测试环境的时候，所有的部署都走 test 的一个代码分支，这样做的好处，就是为了减轻 jmx 脚本的复杂性，同时也避免了在发布生产环境的时候，将脚本发布到生产环境，因为最初的初中使用 jmeter 做接口测试的情况下，就是因为团队开发的同学不写单元测试，测试同学会 Java 的只有一两个，服务又多，公司的迭代速度又快，开发提测的功能一直没有很好的健壮性，所以，我在想能不能在开发部署成功的时候或者定时轮询执行一下每个服务的接口，以达到提测的质量。在团队实践中也遇到了一些问题如下：

• token 的时效性原因，导致脚本老是执行失败
• 数据的唯一性，例如我每次亲求的时间都是不一样的等
• 数据库的连接数老是超标，因为团队存在多个项目组，他们之间又是使用相同的数据库，只是不同表
• Jenkins 的并发限制，因为大家都是使用同一个 Jenkins，不可能你一个老是占用 Jenkins 的执行

针对以上的问题，我个人是如下解决的，首先 token 校验的问题，纯在这个问题的根本原因，是因为我们每次登录都是图片验证码的登陆，但是我又不能识别，只能求助开发经理，让他在测试环境给我们测试写了一个万能验证码，再拿这个这个验证码去刷新 token 和或获取对应的 op（op 参数是内部特有的验证）
数据的唯一性，这个当时头疼了好久，最后只能去百度，最后发限 jmeter 还有很强大的功能，就是函数助手，里面有各种函数，例如获取时间戳，随机数，生成 uuid 等，直接开箱即用
熟悉 mysql 的小伙伴都知道 MySQL 的默认最大连接数是 200 数据库连接池老是超标，最后查看了 mysql 日志发限连接数占用最大的是开发的代码里面写了很多多表联查的大 SQL，尤其是公司大数据那帮人的 sql 一个 SQL 语句执行半个小时，，，，因为去年 mtsc 深圳站的时候，听了唯品会的同学分享接触到了，sql 扫描检查，当时在 sonar 扫描代码的时候，加入了 sql 的扫描，和开发老大商量，去除了项目中大部分的长 sql 语句，最后去请教了运维的同学和公司 dba 的大佬，当时运维同学有点不配合的，最后买了一包好烟，在加各种舔，最终终于同意扩大数据库的连接数，最终勉强解决了这个问题
jenkins 并发机制的问题，这个是 jenkisn 本身就存在的瓶颈，当时给公司运维提了个需求，让他多起几个 jenlkins 的的节点，测试专门使用一个节点

14.接口测试结果报告

由于使用了 jmeter 为了测试的时候，可以实时查看，个人建议使用 influxdb+cadvisor+grafana 搭建一套配合 jmeter 的报告可视化的监控系统

搭建步骤如下

创建容器挂载目录

mkdir -p /dockerdata/influxdb
mkdir -p /dockerdata/grafana

安装 influxdb 数据库

docker run -d \\
   -p 8083:8083 \\
   -p 8086:8086 \\
   --expose 8090 \\
   --expose 8099 \\
   --name influxsrv \\
   -v $PWD:/var/lib/influxdb \\
   influxdb;

安装 cadvisor 容器监控

 docker run \\
--volume=/:/rootfs:ro \\
--volume=/var/run:/var/run:rw \\
--volume=/sys:/sys:ro \\
--volume=/var/lib/docker/:/var/lib/docker:ro \\
-p 8081:8080 \\
--detach=true --link influxsrv:influxsrv \\
--name=cadvisor \\
google/cadvisor:latest \\
-storage_driver=influxdb \\
-storage_driver_db=cadvisor \\
-storage_driver_host=influxsrv:8086;

安装 grafana

docker run \\
-d \\
-p 3000:3000 \\
-e INFLUXDB_HOST=localhost \\
-e INFLUXDB_PORT=8086 \\
-e INFLUXDB_NAME=cadvisor  \\
-e INFLUXDB_USER=root \\
-e INFLUXDB_PASS=root  \\
--link influxsrv:influxsrv \\
-v $PWD:/var/lib/grafana \\
--name grafana \\
grafana/grafana;

最终结果如下

需要注意的点

• 既然使用 influxdb 存储 jmeter 的数据，那么就不得不提 jmeter 的 Backend Listener 后端控制器，的配置，这个超简单，但是我没有使用默认的，因为默认的只能查看 压测的 tps 这些，再加上脚本的每个场景接口我加入事务控制器，所以我采集的是事务控制器，一个事务代表一个接口或者代表多个接口
• 启动了 influxdb 之后需要进入容器创建对应的数据库，要不数据没办法存储
• 为了方便在 grafana 上面看到了每个接口的请求参数和返回值，这个是因为之前公司每个项目已经接入普罗米修斯的监控，在配置普罗米修斯监控的时候，我们加入了自定义监控，所以这款我直接使用普罗米修斯原有的配置的面板
• 还有因为插件的原因当时遇见了 influxdb 里面没办法失败 “/” 所以控制器的命令 “/” 可以使用下划线代替

13.接口测试中常见问题

接口测试经常遇到如下的 bug 和问题：
（1）传入参数处理不当，导致程序 crash;
（2）类型溢出，导致数据读出和写入不一致；
（3）因对象权限为进行校验，可以访问其他用户敏感信息；
（4）状态处理不当，导致逻辑出现错乱；
（5）逻辑校验不完善，可利用漏洞获取非正当利益等；

15.接口自动化适用场景及持续集成

接口自动化框架：Jmeter+maven+Jenkins+git

• Jmeter 作为执行者的角色，每次负责执行具体的接口/性能测试脚本，并得到结果，生成报表。
• Maven 和 Git 是作为管理者角色，前者主要负责项目的依赖管理，而后者主要负责项目的代码管理。
• Jenkins 作为调度者，主要根据我们设置的 build 触发条件和事件调用 jmeter 进行测试 ## maven 集成 jmeter 插件

<dependency>
    <groupId>org.apache.jmeter</groupId>
    <artifactId>ApacheJMeter_components</artifactId>
    <version>5.4.1</version>
</dependency>

jmeter 镜像的制作

因为在上面我们说了我们使用了自己的 Backend Listener 插件，由于网络原因，所以在运行 docker 容器的时候，我们需要将 jmeter 容器使用-v 参数挂在到本地
在加上网络的原因，我们只能自己制作镜像了，制作镜像的 dockerfile 如下

FROM java:8
ENV http_proxy ""
ENV https_proxy ""

RUN mkdir /jmeterdocker
RUN mkdir -p /jmeterdocker/test
RUN mkdir -p /jmeterdocker/test/input/jmx
RUN mkdir -p /jmeterdocker/test/input/testdata
RUN mkdir -p /jmeterdocker/test/report/html
RUN mkdir -p /jmeterdocker/test/report/jtl
RUN mkdir -p /jmeterdocker/test/report/outputdata
RUN chmod -R 777 /jmeterdocker

RUN cd /jmeterdocker

ENV JMETER_VERSION=5.4.1
ENV JMETER_HOME=/jmeterdocker/apache-jmeter-$JMETER_VERSION
ENV JMETER_PATH=$JMETER_HOME/bin:$PATH

RUN wget https://archive.apache.org/dist/jmeter/binaries/apache-jmeter-$JMETER_VERSION.tgz
RUN tar -zxvf apache-jmeter-$JMETER_VERSION.tgz
RUN rm apache-jmeter-$JMETER_VERSION.tgz

需要注意的点
因为使用了 docker 启动运行容器，那么在运行完成之后，需要在对应的 shell 脚本中接入如下命令在每次运行构建之前删除对应的容器

docker rm - f [容器name]

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

测试前置、开发自测

• 一个新的自动化接口测试案例开发完成后，直接发给接口对应的开发，安排在开发本地环境执行，一旦开发确认完成接口开发，就开始执行接口测试案例，基本上可以实时拿到测试结果，方便开发快速做出判断。【开发本地运行的方式就是打开 JMeter 工具，导入 JMX 文件，开始执行可。】
• 回归测试：开发本地测试通过后，或整个需求手工测试通过后，把自动化的接口测试案例做分类整理，挑选出需要纳入到回归测试中的案例，在持续集成环境重新准备测试数据，并把案例纳入到持续集成的 job 中来，这些用于回归的接口测试案例需要配置到持续集成平台自动运行。对接口测试而言，持续集成自动化是核心内容，通过自动化的手段才能有效降低成本，提高接口测试的价值。如果使用 LR、JMeter、SoapUI 工具做自动化测试，工具本身支持命令行模式运行，可以接合 Jenkins 等自动化平台，实现项目版本更新后的自动化回归测试

关于持续自动化回归测试的建议：

• 接口脚本开发时要注意参数的取值的可用性，不因为时间或数据状态的变化引起脚本不能正常运行，降低脚本维护成本.
• 接口回归功能的覆盖度控制，需要根据脚本的实际功能和重要性判断自动化回归覆盖度，回归内容越多脚本维护成本越高，一般应用接口不建议全功能覆盖（毕竟接口有变化会做详细测试，如果没修改其它变更可能对其产生的影响一般不会影响其逻辑判断）
• 接口脚本需要一定的自动化校验能力，除请求 http 状态的判断外，还需要对核心内容的正常性做判断（判断内容可与数据库内容匹配等方式，不建议用写死的内容）。
• 持续性能测试，还需要做好相关的监控、性能指标的分析自动化，减少人工操作。

福利（关注公众号领取）