摘 要

Jmeter 作为一款著名的软件测试工具，在 DevOps 模式下有着广泛的应用。若不对 Jmeter 接口自动化测试框架形成技术标准，不方便审核脚本，也不利于回归测试。缺乏断言健康度度量会导致无法判断接口测试的正确性。

文章重点介绍了现有技术方案以及存在的问题、提出一种基于 Jmeter 的接口自动化测试方法，提供了一种标准的脚本框架和断言健康度度量方案。有效解决目前存在的问题，具有很好的实践价值。

关键词  Jmeter 、接口自动化测试、断言健康度、线程组

一、技术背景

Jmeter 作为一款著名的软件测试工具，在 DevOps 模式下有着广泛的应用。笔者曾对多家外部技术公司进行技术管理的过程中发现，若不对 Jmeter 接口自动化测试框架形成技术标准，不方便审核脚本，也不利于回归测试；缺乏断言健康度度量会导致无法判断接口测试的正确性，因为有些人不写断言，测试依然是通过的。Jmeter 可用来进行接口自动化测试，通过其自身的组件编制测试脚本。如：“HTTP Cookie 管理器”、“HTTP 请求默认值”、 “HTTP 消息头管理器”、“数据库配置”、“查看结果树”、“聚合报告”、“线程组”、“HTTP 请求”、“断言”等内容。

在相关技术中，可以通过添加线程组配置其并发数量、循环次数、线程启动时间参数等来模拟普通用户发送请求对服务器接口进行压力测试，然后通过配置 csv 数据文件进行参数化设置，使其更准确无误的测试接口，接下来通过编写 Beanshell 脚本或者导入辅助性 jar 包，最后添加设置监听器以及断言来判断请求相应的结果是否是预期结果，从而完成接口的自动化测试。然而，现有方案的脚本无法区分不同的环境（例如，开发环境、测试环境、预发布环境、以及生产环境等），从而无法利用一套脚本来支持多种不同的环境。

二、现有技术方案和存在的问题

专利申请：一种基于 Jmeter 的接口自动化测试方法

本发明公开了一种基于 Jmeter 的接口自动化测试方法中，利用 Jmeter 工具，通过添加线程组配置其并发数量、循环次数、线程启动时间参数等来模拟普通用户发送请求对服务器接口进行压力测试，然后通过配置 csv 数据文件进行参数化设置，使其更准确无误的测试接口，接下来通过编写 beanshell 脚本或者导入辅助性 jar 包，最后再添加设置监听器以及断言来判断请求相应的结果是否是预期结果，从而完成接口的自动化测试。本发明的方法可解决目前人工在测试时配置请求数据的时候容易填写错误，且查找和修改错误的工作量比较大以及测试请求不能并发、测试数据不能变化的问题。

专利申请：一种基于 Jmeter 的自动化性能测试方法及系统

本发明提供了一种基于 Jmeter 的自动化性能测试方法及系统，所述方法采用在 Jmeter 测试工具中设置并发量、端口号、IP 地址及循环数，运行 Jmeter 得到测试结果，同时编写统计结果脚本，分析 Jmeter 测试结果，获得最终的性能测试结果；同时本发明还通过编写 Shell 脚本将并发量、端口号、IP 地址、循环数及 Jmeter 测试结果和保存目录进行参数化，来实现多个接口，多组并发，多个不同 IP 地址或端口的测试；本发明无需多次输入执行命令，无需多次重写脚本，无需将测试结果拷贝到安装了 Jmeter  GUI 的电脑中，可节约大量时间，提升工作效率，提升工作准确率。

现有技术方案存在的问题：

1、现有方案的脚本无法区分不同的测试环境。例如开发环境、测试环境、预发布环境等，不支持一套脚本支持多种不同的测试环境。2、现有方案的脚本没有对 HTTP 请求的命令规范进行明确的定义。没有明确的规范会导致测试结果展现无法区分是哪个测试环境的结果，如果接口测试失败也无法准确定位代码模块的具体位置。3、没有提出对代码的子模块建立循环控制器。4、没有提出用线程组来隔离不同的项目、没有提出针对业务流程采用事务控制器。5、没有针对增删查改类单接口测试提供规范化技术方案。6、缺乏针对断言的健康性度量。目前的 Jmeter 测试生成结果是断言的成功率和失败率进行统计。例如：如果不写断言，接口测试的结果依然是成功的。当前的接口测试生成结果“Requests Summary”很明显不能准确衡量断言的健康度。由于接口测试有单接口和业务流程测试，不同的接口重要程度是不同的，应该可以针对不同的断言设定不同的权重。

三、一种基于 Jmeter 的接口自动化测试方法                                     

本文提出一种基于 Jmeter 的接口自动化测试方法，解决现有技术方案存在的问题。

Jmeter 脚本的预处理文件需要包含：“HTTP Cookie 管理器”、“HTTP 请求默认值”、“HTTP 消息头管理器”、“数据库配置（正式环境）”、“数据库配置（测试环境）”、“查看结果树”、“聚合报告”等预配置文件。此外，根据情况也可以添加“用户定义变量”、“CVS 格式数据文件设置”等。 说明：这些组件如果有用不到的地方请选择“禁用”。比如“数据库配置”如果不用，就需要禁用，否则会导致后续测试出错。其中“查看结果树”、“聚合报告”显示的是测试结果情况。“HTTP 请求默认值”中填写协议、IP 地址、端口号和内容编码是为了避免在 HTTP 请求中重复填写这些内容。如图 1 所示提供了一种基于 Jmeter 的接口自动化测试脚本框架。该方法能够支持：1、一套脚本支持多种不同的测试环境。2、制定 HTTP 请求的命名规范，方便观察测试结果。3、对代码的子模块建立循环控制器。4、用线程组隔离不同的项目、针对业务流程采用事务控制器。5、针对增删查改类单接口制定标准方案。6、对 Jmeter 断言进行健康度度量。

图 1 基于 Jmeter 的接口自动化测试脚本框架

（1）一套脚本支持多种不同的测试环境

线程组下面需要有 N 个“如果（if）控制器”。通过 BeanShell Sampler 配置 N 个环境的初始化值。例如：分别为“开发环境变量”、“测试环境变量”、“生产环境变量”。其中测试计划的用户定义变量必须指明 env 对应的是开发环境、测试环境还是生产环境。 三个“如果（if）控制器”中分别需要指明"${env}"=="开发环境"、"${env}"=="测试环境"、"${env}"=="生产环境"。“如果（if）控制器”下面需要有个 beanshell 取样器，对变量进行定义，包括请求协议、请求地址、请求端口等。定义变量方便 HTTP 请求进行参数引用。说明：这样做是为了一套代码可以复用不同的环境，只需要在三个如果（if）控制器里面的 beanshell 取样器里定义一次，就可以多次复用。采用“beanshell 取样器”定义变量操作更加灵活，有代码编写功能，扩展性比“用户定义变量”更强。

（2）制定 HTTP 请求的命名规范，方便观察测试结果

测试计划命名规范：需要为“测试计划-系统名称”。如：“测试计划-资产管理系统”。循环控制器的命名规范：1）单接口测试。需要为：“前台-功能模块”。如：“前台-学生注册”、“后台-学校管理”。 2）业务流程测试。需要为：${env}-接口测试用例编号-“业务流程中文名”。如：“测试环境-资产管理系统测试用例 01-收藏夹”。说明：需要指明测试接口前后台的哪个模块。每个业务流程测试对应一个测试用例编号。对单接口测试，每个 HTTP 请求对应一个测试用例编号。如：“热门活动”模块对应增删查改四个 HTTP 请求，则对应四个接口测试用例。一个订单支付流程对应一个接口测试用例。HTTP 请求的命名规范：HTTP 请求的命名需要明确是开发环境、测试环境还是生产环境，以及对应的测试用例编号和中文名称。需要为：${env}-接口测试用例编号-“单接口的中文名”。如：“开发环境-资产管理系统 02-后台-业务管理-热门活动-编辑”。说明：这样可以通过观察 HTML Report 查看什么环境下的具体哪些测试用例执行不成功。

（3）对代码的子模块建立循环控制器，对业务流程建立事务控制器。

采用循环控制器去定义模块不仅做到了代码模块之间的逻辑隔离，也便于进行多次回归测试。若写到一起容易引起逻辑混乱，比如针对登录模块进行压力测试，如果和其他 HTTP 请求写到了一起，还需要手工禁用掉其余所有的 HTTP 请求。

（4）用线程组隔离不同的项目、提出针对业务流程采用事务控制器

 用线程组隔离不同的项目可以做到不同项目的逻辑隔离。一套脚本可以跑多种不同的项目。一个业务流程对应一个事务控制器。如果对业务流程进行性能测试，需要在循环控制器下面建立“事务控制器”，这样做是为了统计“事务控制器”下面所有的 HTTP 请求整体性能指标。

（5）提供增删查改类单接口测试规范化技术方案

首先测试数据增加接口，然后进行查询，根据 JSON 提取器获取增加后的数据 ID，然后进行修改，最后根据增加的数据 ID 进行删除，从而保证增删查改类接口自动化测试，不用连接数据库，不造成脏数据。

（6）提出针对 Jmeter 断言进行健康度度量方案

图 2 所示提供了一种断言健康性度量方案。首先配置断言结果，在断言结果的 failermessage 中增加“断言期望值”功能，这样就可以根据接口 ID 唯一绑定对应的接口期望值进行集中展示，直观查看空断言的情况，也方便进行断言编写正确与否的集中核对。针对每一个 HTTP 请求标志好所用的环境和测试编号，例如： ${env}-接口测试用例编号-“业务流程中文名”，其中 ${env}用于描述不同的环境。如：“测试环境-资产管理系统测试用例 01-收藏夹”，然后根据断言结果中的 label 和断言期望值一一对应，从而实现集中核对断言期望的情况。由于接口测试有单接口和业务流程测试，不同的接口重要程度是不同的，可以针对不同的断言设定不同的权重。用 N 来表示空断言的总数，则所述第一占比为 N/T，其中 T 表示所述多个断言结果的总数，在这种情况下，所述第二占比等于 1-N/T=(T-N)/T，从而可以将(T-N)/T 作为所述健康度。所述健康度的值越高，说明空断言的总数越小，断言结果越可靠（健康）。设置一个断言的权重值为 M，则 0<M<=100%。测试脚本的断言有权重之分，不同的权重对应不同的断言的重要性，可以更加灵活的对断言进行度量。所述空断言对应的接口测试的类型可以包括单接口测试和业务流程测试。空断言的权重可以是 0 到 1 之间的任意数。示例性地，用 wi 来表示第 i 个空断言的权重，则断言的健康度可以表示如下： 。可以根据所述空断言对应的接口测试的类型来确定空断言的权重，或者可以结合所述空断言对应的接口测试的类型和业务流程的重要性来确定空断言的权重。例如，为重要性更高的业务流程对应的空断言赋予更高的权重。

图 2 断言健康性度量

四、实践效果和改进措施

对 8 个系统实施 Jmeter 接口自动化测试效果如表格 1 所示。实践表明上述 Jmeter 接口自动化测试方法可以帮助外部公司技术人员提高编写脚本的效率，也有助于实施回归测试。同时也方便判断出空断言。

表格 1

改进措施：

（1）该技术可以结合 Meterphere 等持续测试平台，实现在线管理用例、在线编辑脚本和调试脚本，在线压测和在线分析报告等。

（2）将断言权重作为接口自动化测试脚本评价的指标项需要进一步实践。

五、总结

自动化测试的本质是通过提升测试效率，进一步提升软件产品的交付效率。本文介绍了现有技术方案和存在的问题，提出了一种基于 Jmeter 的接口自动化测试方法，提供了标准的脚本框架和断言健康度度量方案。该方法可以指导接口自动化测试人员将脚本编写标准化，有利于回归测试，可以帮助脚本审核人员发现空断言等情况，具有很好的实践价值。