Jmeter一种用法

3.2 整体方案展示

直接上图：

整体方案介绍

主要分为四大块：全局参数配置、测试结果展示、通用模块库、用例模块。

全局参数配置主要用来配置和管理全局类的测试数据、配置等。

测试结果展示主要利用一些监听器元件展示测试执行结果。

通用模块库是比较重要的一个模块，用于将用例编写中可通用的模块提取出来，放置在通用模块库统一管理。

用例模块是最核心的一个模块，用来统一管理维护所有测试用例。

3.3 全局参数配置设计思路详细介绍

模块整体展示

全局参数配置模块主要利用配置元件，配置管理全局的测试数据、运行参数、数据库配置，以及其他测试中需要的全局类的配置。

我在这项目中配置了如下几类：

使用“用户自定义变量”元件配置管理全局测试数据；

使用“用户自定义变量”元件配置与脚本运行相关的全局参数；

使用“DNS Cache Manager”元件配置测试用的 DNS 服务地址；

使用“计数器”元件配置一个计数变量，用于某些用例的使用；

使用“JDBC Connection Configuration”元件配置管理测试数据库连接。

这一模块大家根据自己项目情况自由定制，基本都是通过一些配置元件来管理一些公共数据。特别需要提醒，原则上这一模块放置的是一些通用的测试数据，不要把某些个别用例用的数据放到这里进行配置管理。

如果你需要维护的全局数据较多，也可采用“CSV 数据文件设置”元件，通过 CSV 数据文件来管理。

下面我拿目前正在做的项目作为样例给大家展示一下我主要进行了哪些配置。

测试数据全局配置

这个项目我一共配置了两套测试数据：一套用于测试环境，一套用于生产环境。切换环境测试时，只需要置灰其中一个配置元件即可。

我维护的功能测试数据主要是一些：IP 访问地址、接口地址前缀、不同角色的用户、用于测试的团队等。

大家可以注意其中有个参数 “file_url”，这用来配置 CSV 文件路径，该 CSV 文件中配置管理一些通用的大批量测试数据（目前配的是一些账号密码数据）。

运行参数配置

运行参数配置主要配置一些与线程组运行相关的参数，后续接口自动化脚本转为性能测试脚本，只需对用例略作修改，然后配置一下运行参数即可完成性能脚本编写，有没有感觉到非常方便。

其中变量 “desk_warn” 和“check_list”用于对一些用例可能写自动化断言实现成本太高，于是在这里设置了一些公共提示信息，在测试执行时，提醒进行手工辅助检查。

DNS 配置

在实际测试中经常会遇到切 DNS 或配置 host 的情况，在这里通过“DNS Cache Manager”元件配置需要设置的 DNS 和 host，这样脚本运行就不会受本机 DNS 配置的影响；

经实际验证，用该 DNS 配置元件时，后面用例中取样器配置的“客户端实现”最好选择“HttpClient4”。

数据库请求配置

测试中连接数据库是必须的一项需求，后续用例中的断言和数据准备会经常用到；

我这里分别配置了测试库和生产库的数据库配置，但生产环境的库只有查询权限，避免因为线上自动化验证影响到线上数据；

大家可能有疑问，为什么会直接在线上环境测试，因为我这个项目比较特殊，没有预发布环境，但上线又需要进行线上环境快速回归验证，于是该脚本也用于线上环境验证测试，当然在数据上已经做好隔离，不会影响线上其他用户。

3.4 通用模块库设计思路详细介绍

模块整体展示

该模块主要用来归集汇总后面用例模块需要调用的公共模块，包括数据准备相关、接口正反例通用模块等；

该模块还设有“历史常用组件/模块设计参考”，下面主要归集以前项目曾经设计的比较好的模块，以备后面项目参考使用，对于加快脚本编写是很有帮助的。

还是拿我目前正在做的项目做个展示讲解。

使用元件介绍

使用“测试片段”元件作为该模块的顶级层级，因“测试片段”元件是不会被执行的，所有在这里用测试片段作为顶级层级非常合适，我们的目的就是对一些公共模块进行归集；

使用“简单控制器”元件作为通用模块库的第二层级，用来对通用模块做分类使用，方便维护；当前你也可以用其他控制器（如事务控制器），但感觉还是“简单控制器”非常合适，毕竟只是一个简单的分组；

第三层级使用“事务控制器”元件作为我们归类汇总的通用模块的最顶层，因为事务控制有一个参数选项“Generate Parent Sample”，可以把控制器下的子集细节隐藏起来，方便测试报告的展示，这一个参数建议要勾选。

通用模块举例展示

1. 通过查询数据库抽取删除状态的用户。

2. 进行平台管理员用户登录，获取平台管理员 token。

这个通用模块就通过 “模块控制器” 元件，引用了“数据准备【单/多接口组合】相关”分组下的“数据准备 [ 接口 ]：【获取验证码 code】利用验证码接口获取响应头中的 verification-code 值，输出 {OUT_verification-code}”模块。通过这个可以看到我的设计理念——即使是通用模块库里的模块也可以相互调用。这样做的目的就是尽可能地减少维护副本，能通用的就直接通过模块控制器去调用，这样能极大地降低后期用例维护成本。

3. 删除应用接口测试时用到的三种通用模块。

1) 我在后续设计用例时，主要会调用三类通用模块：

正确入参，检查返回成功；

错误入参，检查返回失败，出现预期失败信息；

错误入参，检查返回失败，出现预期失败的错误码。

2）为什么会出现检查失败错误码的用例呢，因为有的接口错误入参后不会有错误信息返回，只是返回一个错误码，所以需要设计通过错误码是否返回预期值判断用例是否执行成功。

3）对于接口的响应码判断时，如果返回不是 200，但我们又需要让用例在报告中显示执行成功，这时我们就需要写一段脚本，处理一下取样器的成功状态，参加上面第二张截图。

3.5 用例模块设计思路详细介绍

模块整体展示

用例模块主要包含：测试片段元件做的分隔符、线程组元件做的用例组、事务控制器做的用例 ABCD 分类、事务控制器做的测试用例。

测试片段做的分隔符只是为了对多组具有共同特点的用例组做个划分，方便在脚本量比较大时的易维护性。

用线程组元件划分用例组，我一般是将测试一个接口的所有用例放到一组中管理。为什么要用线程组呢，因为线程组具有隔绝性，不同线程组内创建的变量是不能在另外一个线程组使用的，正好满足用例组这个概念，隔绝不同用例组之间的影响。

对于线程组内的用例，我又划分为四类，主要是为了用例管理维护上的方便：

【A】可自动化执行的用例

【B】手工执行的用例

【C】正在维护的用例

【D】备用参考、回收等

用例层级我用事务控制器来对应管理，并且勾选参数“Generate Parent Sample”，这样在测试报告中可只展示该事务控制器的用例标题，不展示内部的执行步骤，方便报告的展示。

细心的同学，可能注意到我的用例内容一般只有两部分：用户参数和模块控制器，这样维护用例很方便，当然前提你要先维护好通用模块。

下面还是拿我目前正在做的项目做个展示讲解。

把执行用例需要的测试数据做成通用模块供所有用例调用。

是否启用集合点

这个模块主要用于后期的性能测试中，需要集合点的场景，只需修改一下上面全局运行参数中的 flag=1，就可使集合点生效，有没有感觉非常方便。

获取线程组的名称

这个见名知意，就是为了获取当前线程组的名称，在后面的用例标题中，可以看到对线程组变量 xc 的使用，主要是为了最后生成的报告好看。

用例可以有多种设计样式，在这里展示几种我目前常用的。

1) 最简单样式

2) 体现 TDD 思想的用例样式

3) 随机数据多次测试样式

每个用例最后面跟“附加：自增用例编号（No+1）”

目的就是为了给变量 ${No} 加 1 操作，这样用例标题中的序号会自动 +1，报告展示好看。

3.6 测试结果展示模块设计思路详细介绍

模块整体展示

主要用到四个元件：用表格查看结果、查看结果树、查看聚合报告、断言结果。

通过“用表格查看结果”可以清晰方便看到测试执行结果，其中列“Label”展示测试用例描述，列“Status”展示用例执行结果，通过的是绿色标记，未通过的是红色标记。

其他元件根据需要选择使用即可。

当然利用 Jmeter 本身的元器件展示的报告还不够完美，比如缺少测试结果的汇总统计等，这些都可以通过一些第三方的报告生成工具生成更友好的测试报告。

3.7 总结

这套模板一旦建立使用起来，对实际工作帮助不小，特别是模块化思想的应用，即使接口有变动，也能最大化减轻修改成本。

当然目前这套脚本架构设计还有需要继续改进的地方，我目前正在对一些元件进行二次开发，以求进一步增强这套架构的易用性，以及降低测试用例维护成本。

4. 补充：接口用例设计思路分享

文章最后，补充一下我在实际接口测试中用到的用例设计思路，不一定完美，但希望可以对刚入门接口测试的小白用户有所启发。

接口测试用例设计角度

接口用例设计一般可以考虑四个角度：功能角度、性能角度、安全角度、健壮性角度，在这里我重点跟大家分享一下功能角度主要考虑哪些方面，其他角度暂不展开。

我一般在设计用例时把测试点分为 5 个角度：基础检查、正常多角度、异常多角度、必录项检查、边界值检查。细心的同学看我上面分享的截图中，用例标题中都会包含这几个设计角度关键字。

当然实际中要根据具体接口情况，不一定非要覆盖这 5 个角度。

如果你的时间很紧张，建议按下面这个优先级去设计实现用例：基础检查 -> 正常多角度 -> 异常多角度 -> 必录项检查 -> 边界值检查。

常用断言方式

我目前主要用到这五类断言方法来核对检查用例是否执行成功。特别说明一下，“数据库匹配核对”是按照接口入参的逻辑写好 SQL 脚本，通过查询数据库获取查询结果，然后再和接口返回的数据做对比来达到检查用例是否执行成功的目的。

我比较推荐利用相关接口来辅助验证，这样检查成本比较低一些，也比较可

转载自https://gitbook.cn/books/5beff0033671112a292fbe88/index.html