自动化-Httprunner脚本编写流程梳理


自动化-Httprunner脚本编写流程梳理

此前一段时间一直忙着公司的紧急需求,自动化编写进度拉下一大半,这个季度的OKR有点不妙.抓紧把自动化进度拉出来,发现还有三十几个功能点没有编写,其中一个是业务很复杂的模块.

1个多月没写脚本的我遇到这个模块,一瞬间竟然又一种老虎吃猪,无从下手的感觉.但经过仔细分析,发现了脚本编写的难点并且找到了还不错的解决办法,这边文章总结了我解决问题的流程,主要用流程图梳理思路

测试框架: Httprunner 3.x + Request

script_write_flow

业务分析

分析业务需求及测试难点,确定测试策略

业务流

难点分析

待测试模块主要提供的功能是数据分析,处于产品业务的最末端,依赖第三方服务

  1. 前置条件较多,需要准备较多前置模块数据
  2. 在进行分析时,存在消息队列,分析所需时间未知
  3. 具有增量数据同步功能.后续新增的数据隔日会自动分析到当前项目
  4. 增量项目会一直产生费用,需要定期进行项目删除

测试策略

  1. 前置条件分层编写脚本, 最后一个初始化脚本调用这些方法生成所有所需数据,写入到环境变量
  2. 断言历史数据结果,断言新增数据状态
  3. 初始化脚本中写入项目模块造数据方法,用于新增内容
  4. 初始化脚本新增删除功能,只保留固定数量项目

脚本运行过程

脚本实际上发挥了pytest框架中中setup方法和teardown方法的作用,只是删除脚本方法放在了第二次运行,有利于后续追踪异常结果

不足之处

脚本过于依赖历史数据,如果环境环境中初始化的保留的历史数据被删除, 仍会报错,但第二天会回复正常 , 没有想到解法, 暂时在脚本中加入确认环境信息提醒

前置条件

前置条件主要通过request来实现接口请求,最后将请求数据写入到环境数据汇总

  1. API请求方法: 单接口方法,实现对某一接口的请求,返回json数据
  2. script: 多个Api测试方法组成, 完成模块内某一个业务操作,返回关键参数
  3. script_init : 多个script请求,最终返回所需的环境变量数据

script_structure

Hrun用例编写

环境数据准备好了,脚本编写就容易多了.按照之前思路将用例大致分为2类

  1. Post接口: 使用前置模块数据进行编写
  2. Put,Get,Del接口: 使用历史数据进行测试

使用环境变量数据进行接口编写

环境确认

用例编写完成之后就要跑到不懂的环境试跑了,这里主要有2个目的

  1. 初始化历史数据 -> 避免代码提交合并之后第一天出现报错
  2. 验证代码健壮性 - > 不同环境,不同情况(删除某一模块历史数据)下用例运行是否报错

Author: Feny Lau
Reprint policy: All articles in this blog are used except for special statements CC BY 4.0 reprint policy. If reproduced, please indicate source Feny Lau !
  TOC