接口测试 接口之间耦合关系比较强的话怎么组织 JMeter 脚本可以有效减少后期不断迭代带来的脚本维护工作量?

Beerus · 2019年06月01日 · 最后由 老马 回复于 2019年08月05日 · 2764 次阅读

想做接口测试,但是没有接口文档。现状是:
1.组成各个功能的多个接口之间的数据依赖比较强,比如一个功能要 30 多个接口按顺序一个个才能生成最后需要验证的结果,现在要对每个接口进行验证,到第 30 个接口了环境准备的接口就太多了,而且 30 个接口中的参数组合不要太多。(当然不是用功能测试的方法做接口测试,只是验证最后一个接口需要的测试数据需要前面很多个接口执行来生成);
2.接口的参数很多,接口参数也大多没有后端进行限制处理,那么参数组合,场景组合带来的工作量太多了;
当前没有好的方案实施。希望有类似情况且最后实施后成功为团队带来收益的经验能指点一下。

共收到 5 条回复 时间 点赞

楼主你再稍微多说一点~

高耦合不该先解耦吗?另外,建议 LZ 提供更多信息供大家讨论参考

可以尝试生成一个比较稳定的自动化脚本模板。未来的迭代都是向这个模板添加特定的需求。可以生成一批不同接口的 jmx 文件,让其成为素材,每次添加即可。当然这需要双开或者多开 Jmeter 来编辑。
建议每一个迭代都要保存好 jmx 文件,这样面对新的迭代可以参考历史文件,让工作量降低。
同时要写好每一个请求的注释,要能真正区分 sampler 的作用和特点。
Jmeter 是有一些缺点无法避免的,比如是一个本地工具无法和线上文档匹配,本身是脚本文件本地保存查找等,麻烦是必然的。需要结合其它工具来使用。

xmind 是个好东西,多、杂容易照成思维混乱

@CelebrateMeaningless https://testerhome.com/articles/17038
https://testerhome.com/articles/18485

https://testerhome.com/articles/18525

用好 jmter 的这几个概念 就可以做到 分层 分类 各层之间耦合度低

我们内部 约定了个 用 Jmter 的目录规范 主要就是 步骤 用例 和 场景

按照此约定 该去哪层写的去哪层写 核心和基线是 step 和 case 层 场景只是做调度和组装 。

步骤 step 是最原子性的
步骤层举例

Tips:1、步骤层里面互不依赖,如果模块很多可根据模块名创建文件夹来分类保存。

2、步骤层的测试计划命名为步骤,通过 Test Fragment 这样的测试片段来进行包含。(建议 Test Fragment 名称和整个步骤的 jmx 文件名称保持一致,方便查询)。

3、步骤层根据具体业务需求来切分,可以是单独一个 sampler 或者多个 sampler 组合,而且一般会使用事物控制器包含。(如果 sampler 里面的变量需要传递使用 vars.get 方法获取,里面有变量需要提取也是同步进行)。

4、为了接口测试严谨性,一般步骤层,会跟随 sampler 绑定这个接口的必填参数测试的简单控制器,方便阅读。(必填参数测试:缺失必填参数后,接口返回值是否正确)。

用例层举例

Tips:1、用例层里面只调用步骤层来进行组装,不添加任何 sampler。

2、用例层一般会使用 Parameterized Controller 插件来对步骤层进行参数传递,一般需要和步骤层绑定。如果需要再获取上级参数传递可写为变量

3、用例是独立存在的,用事物控制器进行包含,由于 JMeter 本身的特性,需要在场景层中组合的话,也只能存放为 Test Fragment 给与调用。

4、用例名称中,事物控制器,测试片段,jmx 文件名称尽量保持一致,方便查找。

场景层举例

Tips:1、场景层是由线程组通过 Include Controller 调用 Test Fragment 的测试用例来直接运行的 jmx 文件,也是最后输出的报告展示结果。

2、所有用例都需要使用的变量可以在场景层存放,比如用户账户数据,数据账户密码,APPID,AppSecret 等,如果不需要在场景层使用可以在用例层进行传值覆盖。

3、场景层中的用例没有依赖关系,可以顺序或者乱序组合,互不干扰。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册