基于Jmeter的接口自动化测试方法和装置

技术领域

本公开涉及计算机技术的领域，具体地，涉及一种基于Jmeter的接口自动化测试方法和装置、计算设备、计算机可读存储介质以及计算机程序产品。

背景技术

Jmeter是一种基于 Java 开发的压力测试工具，用于对软件做压力测试。Jmeter可以用来进行接口自动化测试，通过其自身的组件可以进行测试脚本的编制，例如：“HTTPCookie管理器”、“HTTP请求默认值”、“HTTP消息头管理器”、“数据库配置”、“查看结果树”、“聚合报告”、“线程组”、“HTTP请求”、“断言”等内容。

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

发明内容

有鉴于此，本公开提供了一种基于Jmeter的接口自动化测试方法和装置、计算设备、计算机可读存储介质以及计算机程序产品，以缓解、减轻、甚至消除上述问题。

根据本公开的一个方面，提供了一种基于Jmeter的接口自动化测试方法，其特征在于，所述方法包括：针对Jmeter的测试计划执行以下配置步骤：添加用户定义变量、HTTP请求默认值、HTTP信息头管理器、查看结果树、以及聚合报告；在所述测试计划中为待测试的项目添加相应的线程组，所添加的线程组与所述测试计划唯一对应；在所述线程组下配置多个条件控制器，所述多个条件控制器用于确定待测试的项目所在的环境；以及在所述多个条件控制器中的每个条件控制器下添加Beanshell取样器，以配置用于测试的数据值；然后增加具体的接口测试任务，根据经配置的所述测试计划，生成Jmeter测试脚本并且基于所述Jmeter测试脚本进行接口测试，以获取测试结果。

根据本公开的一些实施例，所述配置步骤还包括：为所述待测试的项目对应的各个代码模块建立相应的循环控制器，以在逻辑上隔离各个代码模块。

根据本公开的一些实施例，所述接口测试为单接口测试或业务流程测试，并且所述循环控制器的名称根据待测试的接口对应的前后台位置以及模块功能被确定。

根据本公开的一些实施例，所述接口测试为业务流程测试，并且所述配置步骤还包括：在所述循环控制器下建立事务控制器，以确定所述事务控制器下所有HTTP请求的整体性能指标。

根据本公开的一些实施例，所述待测试的项目对应的HTTP请求的名称根据以下被确定：所述待测试的项目所在的环境、接口测试用例的编号、以及接口的名称。

根据本公开的一些实施例，所述接口测试为针对增删查改类的单接口测试，并且通过以下步骤进行接口测试：增加目标测试数据；查询所增加的目标测试数据；根据JSON提取器获取目标测试数据的ID，对目标测试数据进行修改以得到经修改的测试数据；根据目标测试数据的ID，删除经修改的测试数据。

根据本公开的一些实施例，所述配置步骤还包括：在查看结果控件中增加断言期望值；并且其中，所述基于所述Jmeter测试脚本进行接口测试包括：基于所述Jmeter测试脚本对多个接口进行验证，以生成相应的多个断言结果；根据所述多个断言结果中相应的断言期望值，确定空断言在所述多个断言结果中的第一占比；以及至少根据所述第一占比，确定断言的健康度。

根据本公开的一些实施例，所述方法还包括：对所述测试结果进行规范化处理，以得到接口测试报告，所述接口测试报告包括第一路径、第二路径、以及第三路径，其中所述第一路径用来存放数据处理有关表格；所述第二路径用来存放测试脚本有关文件，所述测试脚本有关文件包括jmx文件、jtl文件、以及log文件；并且所述第三路径用来存放HTMLReport形式的测试结果。

根据本公开的一些实施例，所述基于所述Jmeter测试脚本进行接口测试，以获取测试结果，包括：将所述Jmeter测试脚本提交到代码仓库；利用持续集成工具设置自动化测试任务，从所述代码仓库下载所述Jmeter测试脚本并利用相应的构建工具进行构建，以生成Jmeter测试报告；以及将预设内容反馈给管理员，所述预设内容包括以下中的至少一项：测试接口的个数，失败个数、成功率，平均响应时间、以及接口的URL。

根据本公开的一些实施例，所述待测试的项目所在的环境包括以下中的任一种：开发环境、测试环境、预发布环境、以及生产环境。

根据本公开的另一个方面，提供了一种基于Jmeter的接口自动化测试装置，其特征在于，所述装置包括：测试脚本配置模块，其被配置为添加用户定义变量、HTTP请求默认值、HTTP信息头管理器、查看结果树、以及聚合报告；在所述测试计划中为待测试的项目添加相应的线程组，所添加的线程组与所述测试计划唯一对应；在所述线程组下配置多个条件控制器，所述多个条件控制器用于确定待测试的项目所在的环境；以及在所述多个条件控制器中的每个条件控制器下添加Beanshell取样器，以配置用于测试的数据值；测试结果生成模块，其被配置为增加具体的接口测试任务，根据经配置的所述测试计划，生成Jmeter测试脚本并且基于所述Jmeter测试脚本进行接口测试，以获取测试结果。

根据本公开的又一个方面，提供了一种计算设备，其特征在于，所述计算设备包括：存储器，其被配置成存储计算机可执行指令；处理器，其被配置成当所述计算机可执行指令被处理器执行时执行根据本公开的前述方面提供的任一方法。

根据本公开的又一个方面，提供了一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机可执行指令，当所述计算机可执行指令被执行时，执行根据本公开的前述方面提供的任一方法。

根据本公开的又一个方面，提供了一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机可执行指令，当所述计算机可执行指令被处理器执行时，执行根据本公开的前述方面提供的任一方法。

根据本公开提供的基于Jmeter的接口自动化测试方法，可以针对Jmeter的测试计划执行以下配置步骤：添加用户定义变量、HTTP请求默认值、HTTP信息头管理器、查看结果树、以及聚合报告；在所述测试计划中为待测试的项目添加相应的线程组，所添加的线程组与所述测试计划唯一对应，从而可以在逻辑上隔离不同的项目；在所述线程组下配置多个条件控制器，所述多个条件控制器用于确定待测试的项目所在的环境，从而有助于区分不同的环境（例如，开发环境、测试环境、预发布环境、以及生产环境等），进而有助于利用一套脚本来支持多种不同的环境；以及在所述多个条件控制器中的每个条件控制器下添加Beanshell取样器，以配置用于测试的数据值；然后增加具体的接口测试任务，根据经配置的所述测试计划，生成Jmeter测试脚本并且基于所述Jmeter测试脚本进行接口测试，以获取测试结果。

根据在下文中所描述的实施例，本公开的这些和其他方面将是清楚明白的，并且将参考在下文中所描述的实施例而被阐明。

附图说明

在下面结合附图对于示例性实施例的描述中，本公开的技术方案的更多细节、特征和优点被公开，在附图中：

图1示意性示出了根据本公开的一些实施例的一种基于Jmeter的接口自动化测试方法的示例流程图；

图2示意性示出了根据本公开的另一些实施例的一种基于Jmeter的接口自动化测试方法的示例流程图；

图3示意性示出了根据本公开的又一些实施例的一种基于Jmeter的接口自动化测试方法的示例流程图；

图4示意性示出了图3中的基于Jmeter的接口自动化测试方法的示例原理图；

图5示意性示出了根据本公开的一些实施例的基于Jmeter的接口自动化测试装置的示例框图；

图6图示了示例系统，其包括代表可以实现本文描述的各种技术的一个或多个系统和/或设备的示例计算设备。

具体实施方式

下面将参照附图更详细地描述本公开的若干个实施例以便使得本领域技术人员能够实现本公开的技术方案。本公开的技术方案可以体现为许多不同的形式和目的，并且不应局限于本文所阐述的实施例。提供这些实施例是为了使得本公开的技术方案清楚完整，但所描述的实施例并不限定本公开的保护范围。

除非另有定义，本文中使用的所有术语（包括技术术语和科学术语）具有与本公开所属领域的普通技术人员所通常理解的相同含义。将进一步理解的是，诸如那些在通常使用的字典中定义的之类的术语应当被解释为具有与其在相关领域和/或本说明书上下文中的含义相一致的含义，并且将不在理想化或过于正式的意义上进行解释，除非本文中明确地如此定义。

图1示意性示出了根据本公开的一些实施例的一种基于Jmeter的接口自动化测试方法（为简洁起见，下文简称为接口测试方法100）的示例流程图。

示例性地，针对Jmeter的测试计划执行配置步骤110，具体地，配置步骤110包括步骤111-114。其中，在步骤111，添加用户定义变量、HTTP请求默认值、HTTP信息头管理器、查看结果树、以及聚合报告等组件。需要说明的是，根据实际应用场景的需要，还可以添加其他组件，例如csv数据文件设置、数据库连接配置等组件；在步骤112，在所述测试计划中为待测试的项目添加相应的线程组，所添加的线程组与所述测试计划唯一对应；在步骤113，在所述线程组下配置多个条件控制器，所述多个条件控制器用于确定待测试的项目所在的环境；在步骤114，在所述多个条件控制器中的每个条件控制器下添加Beanshell取样器，以配置用于测试的数据值。接下来，在步骤120，增加具体的接口测试任务，根据经配置的所述测试计划，生成Jmeter测试脚本并且基于所述Jmeter测试脚本进行接口测试，以获取测试结果，另外，还可以对测试所用的脚本、初始化数据、配置信息以测试生成的结果进行版本化管理，以方便后续的应用（例如，进行回归测试）。

示例性地，用户定义变量指示env 对应的是开发环境、测试环境、预发布环境、还是生产环境。线程组下面设置多个条件控制器（If Controller）。条件控制器用于控制Jmeter执行脚本流程，只有在某个条件为真时才能运行采样器。在本公开中，条件控制器的数量可以通过环境的类型数量来确定，例如，当待测试的项目所在的环境包括开发环境、测试环境、预发布环境和生产环境这四种环境时，条件控制器的数量可以是四个以区分这四种不同的环境。可以在用户定义变量里面设置name和value值，例如，可以将name为“env”，然后在条件控制器中设置“${env}”的值。例如：多个条件控制器中分别需要指明"${env}"=="开发环境"、"${env}"=="测试环境"、"${env}"=="预发布环境"、以及"${env}"=="生产环境"。其中，“${env}”用于描述不同的环境。若用户定义变量中的value值和条件控制器中的值一致，则采用此环境。

所述多个条件控制器中的每个条件控制器下所添加的Beanshell取样器用于对变量进行定义，包括请求协议、请求地址、请求端口、随机值等。定义这些变量可以方便HTTP请求进行参数引用，进而有助于使得一套代码（脚本）可以复用不同的环境，因为只需要在所述多个条件控制器里面的Beanshell取样器里定义一次，就可以多次复用。采用“Beanshell取样器”定义变量操作更加灵活，有代码编写功能，扩展性比“用户定义变量”更强。

通过接口测试方法100，可以通过在测试计划中为待测试的项目添加相应的线程组来在逻辑上隔离不同的项目，并且通过线程组下配置多个条件控制器（这些条件控制器用于确定待测试的项目所在的环境）来区分待测试的项目所在的不同的环境（例如，开发环境、测试环境、预发布环境、以及生产环境等），从而可以利用一套脚本来支持多种不同的环境，进而有助于实现接口自动化测试并得到相应的测试结果。

在一些实施例中，配置步骤110还包括：为所述待测试的项目对应的各个代码模块建立相应的循环控制器（Loop Controller），以在逻辑上隔离各个代码模块。循环控制器用于控制相应的代码模块循环执行多次（循环次数可以根据实际需要来设定）。通过利用循环控制器在逻辑上隔离各个代码模块，可以更加高效地进行接口测试（例如，单接口测试或业务流程测试）。示例性地，

在一些实施例中，所述接口测试为单接口测试或业务流程测试，并且所述循环控制器的名称根据待测试的接口对应的前后台位置以及模块功能被确定。示例性地，针对单接口测试，所述循环控制器的名称可以是：“前台-功能模块”，例如：“前台-学生注册”、“后台-学校管理”；针对业务流程测试，所述循环控制器的名称可以是：${env}-接口测试用例编号-“业务流程中文名”，例如：“测试环境-云上XX工作室测试用例01-收藏夹”。需要说明的是，在名称中需要指明测试接口前后台的哪个模块。另外，每个业务流程测试可以对应一个测试用例编号。

在一些实施例中，所述接口测试为业务流程测试，并且所述配置步骤还包括：在所述循环控制器下建立事务控制器（Transaction Controller），以确定所述事务控制器下所有HTTP请求的整体性能指标（例如，90%的请求耗时没有超过的时间、请求错误率、最大响应时间、TPS值）。事务中会包含一个或多个请求，当含有多个请求时，想看一个事务的测试结果（例如，所有请求的总时间、总的吞吐量等），可以通过事务控制器进行操作。

在一些实施例中，所述待测试的项目对应的HTTP请求的名称根据以下被确定：所述待测试的项目所在的环境、接口测试用例的编号、以及接口的名称。在相关技术中，由于没有对HTTP请求的命令规范进行明确的定义，导致测试结果展现无法区分是哪个测试环境的结果，如果接口测试失败也无法准确定位代码模块的具体位置。通过本公开的以上针对HTTP请求的名称的命名方法可以解决这些问题。示例性地，所述待测试的项目对应的HTTP请求的名称可以是：${env}-接口测试用例编号-“单接口的中文名”，例如：“开发环境-云上XX工作室02-后台-业务管理-热门活动-编辑”，通过这种命名方法，可以通过观察HTMLReport查看什么环境下的具体哪些测试用例执行不成功。

在一些实施例中，所述接口测试为针对增删查改类的单接口测试，并且通过以下步骤进行接口测试：增加目标测试数据；查询所增加的目标测试数据；根据JSON提取器获取目标测试数据的ID，对目标测试数据进行修改以得到经修改的测试数据；根据目标测试数据的ID，删除经修改的测试数据。通过这种针对增删查改类的单接口测试提出的规范化技术方案，可以保证在这种增删查改类的单接口测试中无需连接相应的数据库，既简化了配置又不会造成脏数据。

图2示意性示出了根据本公开的另一些实施例的一种基于Jmeter的接口自动化测试方法（为简洁起见，下文简称为接口测试方法200）的示例流程图。其中，在针对Jmeter的测试计划执行的配置步骤210中，步骤211-214分别与上文关于图1描述的步骤111-114一致。另外，配置步骤210还包括步骤215：在查看结果控件中增加断言期望值，从而不论断言成功或者失败都显示断言的期望值（当前的查看结果控件当中的FailureMessage只显示断言失败情况的断言期望值，应该也显示测试成功情况下的断言期望值）。示例性地，可以配置查看结果控件，即在查看结果控件的中增加一项来指示断言期望值，例如可以将该项命名为“Assertion expectation”，从而可以根据接口ID唯一绑定、对应的接口期望值进行集中展示，便于接口测试人员直观查看空断言的情况，也便于方便进行断言编写正确与否的集中核对。示例性地，可以针对每一个HTTP请求对所使用的环境和测试编号进行标记，例如，标记为“ ${env}-接口测试用例编号-‘业务流程中文名’”。进而可以根据断言结果中的标签（label）和断言期望值一一对应，从而实现集中核对断言期望值的情况。步骤220用于进行接口测试，其包括步骤221-224。

具体地，在步骤221，增加具体的接口测试任务，根据经配置的所述测试计划，生成Jmeter测试脚本。进而在步骤222，基于所述Jmeter测试脚本对多个接口进行验证，以生成相应的多个断言结果。

在步骤223，根据所述多个断言结果中相应的断言期望值，确定空断言在所述多个断言结果中的第一占比。示例性地，当断言期望值为空时，可以确定相应的断言为空断言，通过所述多个断言结果中相应的断言期望值，可以确定空断言的数量，进而确定空断言在所述多个断言结果中的占比作为所述第一占比。

在步骤224，至少根据所述第一占比，确定断言的健康度。示例性地，可以根据所述第一占比，确定非空断言在所述多个断言结果中的第二占比，并且将所述第二占比作为所述健康度。示例性地，用N来表示空断言的总数，则所述第一占比为N/T，其中T表示所述多个断言结果的总数，在这种情况下，所述第二占比等于1-N/T=(T-N)/T，从而可以将(T-N)/T作为所述健康度。所述健康度的值越高，说明空断言的总数越小，断言结果越可靠（健康）。

作为另一示例，可以根据所述第一占比和空断言的权重，确定断言的健康度，其中，所述空断言的权重至少根据所述空断言对应的接口测试的类型被确定。所述空断言对应的接口测试的类型可以包括单接口测试和业务流程测试。空断言的权重可以是0到1之间的任意数。示例性地，用w

需要说明的是，在本公开中，可以根据所述空断言对应的接口测试的类型来确定空断言的权重，或者可以结合所述空断言对应的接口测试的类型和业务流程的重要性来确定空断言的权重。例如，为重要性更高的业务流程对应的空断言赋予更高的权重。

通过接口测试方法200，可以通过统计空断言的占比来更加准确地衡量断言的健康度，另外，在接口测试方法200中，还可以对测试脚本的断言进行权重的划分，从而进一步细化对断言的健康度的评估。

在一些实施例中，接口测试方法100还包括：对所述测试结果进行规范化处理，以得到接口测试报告，所述接口测试报告包括第一路径、第二路径、以及第三路径，其中所述第一路径用来存放数据处理有关表格；所述第二路径用来存放测试脚本有关文件，所述测试脚本有关文件包括jmx文件（例如，测试框架脚本文件）、jtl文件（可以通过该文件生成html形式的测试报告）、以及log文件（即日志文件）；并且所述第三路径用来存放HTMLReport形式的测试结果，用于通过浏览器查看测试结果。示例性地，所述第一路径、所述第二路径、以及所述第三路径可以是文件夹的形式。

图3示意性示出了根据本公开的又一些实施例的一种基于Jmeter的接口自动化测试方法（为简洁起见，下文简称为接口测试方法300）的示例流程图。其中，在针对Jmeter的测试计划执行的配置步骤310中，步骤311-314分别与上文关于图1描述的步骤111-114一致。步骤320用于进行接口测试，其包括步骤321-324。

具体地，在步骤321，增加具体的接口测试任务，根据经配置的所述测试计划，生成Jmeter测试脚本；在步骤322，将所述Jmeter测试脚本提交到代码仓库。示例性地，所述代码仓库可以是GitLab仓库，在这种情况下，Jmeter测试脚本被上传至GitLab。GitLab是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的Web服务。除了GitLab仓库之外，也可以使用其他能够保管源码的仓库（包括但不限于本地存储库、GitHub、Bitbucket等）；在步骤323，利用持续集成工具（例如，Jenkins、Tekton等）设置自动化测试任务，从所述代码仓库下载所述Jmeter测试脚本并利用相应的构建工具（例如，Ant）进行构建，以生成Jmeter测试报告；在步骤324，将预设内容反馈给管理员，所述预设内容包括以下中的至少一项：测试接口的个数、失败个数、成功率、平均响应时间、以及接口的URL。下面结合图4来进一步说明图3中的接口测试方法300的原理图。

如图4所示，Jmeter服务器410可以将所生成的Jmeter测试脚本提交到代码仓库420，以便设置了相应的自动化测试任务的Jenkins服务器430从代码仓库420下载所述Jmeter测试脚本并利用相应的构建工具进行构建，从而生成Jmeter测试报告。最后，可以由Jenkins服务器430将预设内容反馈给管理员440，所述预设内容包括以下中的至少一项：测试接口的个数、失败个数、成功率、平均响应时间、以及接口的URL。

图5示意性示出了根据本公开的一些实施例的基于Jmeter的接口自动化测试装置（为简洁起见，下文简称为接口自动化测试装置500）的示例框图。如图5所示，接口自动化测试装置500包括测试脚本配置模块510和测试结果生成模块520。

具体地，测试脚本配置模块510可以被配置为：添加用户定义变量、HTTP请求默认值、HTTP信息头管理器、查看结果树、以及聚合报告；在所述测试计划中为待测试的项目添加相应的线程组，所添加的线程组与所述测试计划唯一对应；在所述线程组下配置多个条件控制器，所述多个条件控制器用于确定待测试的项目所在的环境；以及在所述多个条件控制器中的每个条件控制器下添加Beanshell取样器，以配置用于测试的数据值；测试结果生成模块520可以被配置为：增加具体的接口测试任务，根据经配置的所述测试计划，生成Jmeter测试脚本并且基于所述Jmeter测试脚本进行接口测试，以获取测试结果，另外，还可以对测试所用的脚本、初始化数据、配置信息以测试生成的结果进行版本化管理。

应理解，接口自动化测试装置500可以以软件、硬件或软硬件相结合的方式实现，以支持C/S模式和B/S模式中的任一种。接口自动化测试装置500中的多个不同模块均可以在同一软件或硬件结构中实现，或者一个模块可以由多个不同的软件或硬件结构实现。

此外，接口自动化测试装置500可以用于实施前文所描述的接口测试方法100，其相关细节均已经在前文中详细描述，为简洁起见，在此不再重复。接口自动化测试装置500可以具有与关于前述接口测试方法100描述的相同的特征和优势。

图6图示了示例系统，其包括代表可以实现本文描述的各种技术的一个或多个系统和/或设备的示例计算设备600。计算设备600可以是例如服务提供商的服务器、与服务器相关联的设备、片上系统、和/或任何其他合适的计算设备或计算系统。上述接口自动化测试装置500中的任意一种或多种装置可以采取计算设备600的形式。替换地，接口自动化测试装置500可以以应用616的形式被实现为计算机程序。

如图6所示的示例计算设备600包括彼此通信耦合的处理系统611、一个或多个计算机可读介质612以及一个或多个I/O接口613。尽管未示出，但是计算设备600还可以包括系统总线或其他数据和命令传送系统，其将各种组件彼此耦合。系统总线可以包括不同总线结构的任何一个或组合，所述总线结构诸如存储器总线或存储器控制器、外围总线、通用串行总线、和/或利用各种总线架构中的任何一种的处理器或局部总线。还构思了各种其他示例，诸如控制和数据线。

处理系统611代表使用硬件执行一个或多个操作的功能。因此，处理系统611被图示为包括可被配置为处理器、功能块等的硬件元件614。这可以包括在硬件中实现为专用集成电路或使用一个或多个半导体形成的其他逻辑器件。硬件元件614不受其形成的材料或其中采用的处理机构的限制。例如，处理器可以由（多个）半导体和/或晶体管（例如，电子集成电路（IC））组成。在这样的上下文中，处理器可执行指令可以是电子可执行指令。

计算机可读介质612被图示为包括存储器/存储装置615。存储器/存储装置615表示与一个或多个计算机可读介质相关联的存储器/存储容量。存储器/存储装置615可以包括易失性介质（诸如随机存取存储器（RAM））和/或非易失性介质（诸如只读存储器（ROM）、闪存、光盘、磁盘等）。存储器/存储装置615可以包括固定介质（例如，RAM、ROM、固定硬盘驱动器等）以及可移动介质（例如，闪存、可移动硬盘驱动器、光盘等）。计算机可读介质612可以以下面进一步描述的各种其他方式进行配置。

一个或多个I/O接口613代表允许用户使用各种输入设备向计算设备600输入命令和信息并且可选地还允许使用各种输出设备将信息呈现给用户和/或其他组件或设备的功能。输入设备的示例包括键盘、光标控制设备（例如，鼠标）、麦克风（例如，用于语音输入）、扫描仪、触摸功能（例如，被配置为检测物理触摸的容性或其他传感器）、相机（例如，可以采用可见或不可见的波长（诸如红外频率）将不涉及触摸的运动检测为手势）等等。输出设备的示例包括显示设备（例如，显示器或投影仪）、扬声器、打印机、网卡、触觉响应设备等。因此，计算设备600可以以下面进一步描述的各种方式进行配置以支持用户交互。

计算设备600还包括应用616。应用616可以例如是接口自动化测试装置500的软件实例，并且与计算设备600中的其他元件相组合地实现本文描述的技术。

本文可以在软件硬件元件或程序模块的一般上下文中描述各种技术。一般地，这些模块包括执行特定任务或实现特定抽象数据类型的例程、程序、元素、组件、数据结构等。本文所使用的术语“模块”，“功能”和“组件”一般表示软件、固件、硬件或其组合。本文描述的技术的特征是与平台无关的，意味着这些技术可以在具有各种处理器的各种计算平台上实现。

所描述的模块和技术的实现可以存储在某种形式的计算机可读介质上或者跨某种形式的计算机可读介质传输。计算机可读介质可以包括可由计算设备600访问的各种介质。作为示例而非限制，计算机可读介质可以包括“计算机可读存储介质”和“计算机可读信号介质”。

与单纯的信号传输、载波或信号本身相反，“计算机可读存储介质”是指能够持久存储信息的介质和/或设备，和/或有形的存储装置。因此，计算机可读存储介质是指非信号承载介质。计算机可读存储介质包括诸如易失性和非易失性、可移动和不可移动介质和/或以适用于存储信息（诸如计算机可读指令、数据结构、程序模块、逻辑元件/电路或其他数据）的方法或技术实现的存储设备之类的硬件。计算机可读存储介质的示例可以包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字通用盘（DVD）或其他光学存储装置、硬盘、盒式磁带、磁带，磁盘存储装置或其他磁存储设备，或其他存储设备、有形介质或适于存储期望信息并可以由计算机访问的制品。

“计算机可读信号介质”是指被配置为诸如经由网络将指令发送到计算设备600的硬件的信号承载介质。信号介质典型地可以将计算机可读指令、数据结构、程序模块或其他数据体现在诸如载波、数据信号或其他传输机制的调制数据信号中。信号介质还包括任何信息传递介质。术语“调制数据信号”是指这样的信号，该信号的特征中的一个或多个被设置或改变，从而将信息编码到该信号中。作为示例而非限制，通信介质包括诸如有线网络或直接连线的有线介质以及诸如声、RF、红外和其他无线介质的无线介质。

如前所述，硬件元件614和计算机可读介质612代表以硬件形式实现的指令、模块、可编程器件逻辑和/或固定器件逻辑，其在一些实施例中可以用于实现本文描述的技术的至少一些方面。硬件元件可以包括集成电路或片上系统、专用集成电路（ASIC）、现场可编程门阵列（FPGA）、复杂可编程逻辑器件（CPLD）以及硅中的其他实现或其他硬件设备的组件。在这种上下文中，硬件元件可以作为执行由硬件元件所体现的指令、模块和/或逻辑所定义的程序任务的处理设备，以及用于存储用于执行的指令的硬件设备，例如，先前描述的计算机可读存储介质。

前述的组合也可以用于实现本文所述的各种技术和模块。因此，可以将软件、硬件或程序模块和其他程序模块实现为在某种形式的计算机可读存储介质上和/或由一个或多个硬件元件614体现的一个或多个指令和/或逻辑。计算设备600可以被配置为实现与软件和/或硬件模块相对应的特定指令和/或功能。因此，例如通过使用处理系统的计算机可读存储介质和/或硬件元件614，可以至少部分地以硬件来实现将模块实现为可由计算设备600作为软件执行的模块。指令和/或功能可以由一个或多个制品（例如，一个或多个计算设备600和/或处理系统611）可执行/可操作以实现本文所述的技术、模块和示例。

在各种实施方式中，计算设备600可以采用各种不同的配置。例如，计算设备600可以被实现为包括个人计算机、台式计算机、多屏幕计算机、膝上型计算机、上网本等的计算机类设备。计算设备600还可以被实现为包括诸如移动电话、便携式音乐播放器、便携式游戏设备、平板计算机、多屏幕计算机等移动设备的移动装置类设备。计算设备600还可以实现为电视类设备，其包括具有或连接到休闲观看环境中的一般地较大屏幕的设备。这些设备包括电视、机顶盒、游戏机等。

本文描述的技术可以由计算设备600的这些各种配置来支持，并且不限于本文所描述的技术的具体示例。功能还可以通过使用分布式系统、诸如通过如下所述的平台622而在“云”620上全部或部分地实现。

云620包括和/或代表用于资源624的平台622。平台622抽象云620的硬件（例如，服务器）和软件资源的底层功能。资源624可以包括在远离计算设备600的服务器上执行计算机处理时可以使用的应用和/或数据。资源624还可以包括通过因特网和/或通过诸如蜂窝或Wi-Fi网络的订户网络提供的服务。

平台622可以抽象资源和功能以将计算设备600与其他计算设备连接。平台622还可以用于抽象资源的分级以提供遇到的对于经由平台622实现的资源624的需求的相应水平的分级。因此，在互连设备实施例中，本文描述的功能的实现可以分布在整个系统600内。例如，功能可以部分地在计算设备600上以及通过抽象云620的功能的平台622来实现。

应当理解，为清楚起见，参考不同的功能单元对本公开的实施例进行了描述。然而，将明显的是，在不偏离本公开的情况下，每个功能单元的功能性可以被实施在单个单元中、实施在多个单元中或作为其他功能单元的一部分被实施。例如，被说明成由单个单元执行的功能性可以由多个不同的单元来执行。因此，对特定功能单元的参考仅被视为对用于提供所描述的功能性的适当单元的参考，而不是表明严格的逻辑或物理结构或组织。因此，本公开可以被实施在单个单元中，或者可以在物理上和功能上被分布在不同的单元和电路之间。

将理解的是，尽管第一、第二、第三等术语在本文中可以用来描述各种设备、元件、部件或部分，但是这些设备、元件、部件或部分不应当由这些术语限制。这些术语仅用来将一个设备、元件、部件或部分与另一个设备、元件、部件或部分相区分。

尽管已经结合一些实施例描述了本公开，但是其不旨在被限于在本文中所阐述的特定形式。相反，本公开的范围仅由所附权利要求来限制。附加地，尽管单独的特征可以被包括在不同的权利要求中，但是这些可以可能地被有利地组合，并且包括在不同权利要求中不暗示特征的组合不是可行的和/或有利的。特征在权利要求中的次序不暗示特征必须以其工作的任何特定次序。此外，在权利要求中，词“包括”不排除其他元件，并且术语“一”或“一个”不排除多个。权利要求中的附图标记仅作为明确的例子被提供，不应该被解释为以任何方式限制权利要求的范围。

应当理解，为清楚起见，参考不同的功能单元对本公开的实施例进行了描述。然而，将明显的是，在不偏离本公开的情况下，每个功能单元的功能性可以被实施在单个单元中、实施在多个单元中或作为其他功能单元的一部分被实施。例如，被说明成由单个单元执行的功能性可以由多个不同的单元来执行。因此，对特定功能单元的参考仅被视为对用于提供所描述的功能性的适当单元的参考，而不是表明严格的逻辑或物理结构或组织。因此，本公开可以被实施在单个单元中，或者可以在物理上和功能上被分布在不同的单元和电路之间。

本公开提供了一种计算机可读存储介质，其上存储有计算机可读指令，计算机可读指令在被执行时实现上述的基于Jmeter的接口自动化测试方法。

本公开提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算设备执行上述各种可选实现方式中提供的基于Jmeter的接口自动化测试方法。

通过研究附图、公开内容和所附的权利要求书，本领域技术人员在实践所要求保护的主题时，能够理解和实现对于所公开的实施例的变型。在权利要求书中，词语“包括”不排除其他元件或步骤，并且“一”或“一个”不排除多个。在相互不同的从属权利要求中记载某些措施的纯粹事实并不指示这些措施的组合不能被有利地使用。