httprunner使用总结

背景

在准备做接口自动化的过程中，了解到httprunner是一种简洁、不会代码的人也可以快速上手的框架。维护人员只需要编写并维护json或yaml文件，即可实现自动化测试。

在结合httprunnerV2.X中文使用文档，应用于自己的项目中，还是遇到了一些问题，所以结合项目经验以及源码分析，来总结框架的使用方法，以及遇到问题的解决办法。

环境

本次接口自动化采用的是：python3.7+httprunner2.0.1

项目文件结构

利用项目脚手架直接创建测试用例分层结构：hrun --startproject demo，其中demo为项目名称。 

Httprunner的核心命令

• hrun：httprunner的缩写，功能与httprunner完全相同

• locusts：基于Locust实现性能

• har2case：辅助工具，可将har格式（HTTP Archive）转换为YAML或者JSON格式。

在我们实际项目的应用中，更多的应用hrun指令。目前没有做性能测试，所以没有用到locusts。用例选择yaml文件格式，为自己书写，没有使用转换工具。

• hrun主要用到的指令如下：

-V：获取当前项目使用的httprunner版本

--startproject：生成项目结构

--log-level：日志信息,默认info,调试时可指定debug,hrun ss.yml --log-level debug

--dot-env-path：指定.env文件路径,在本次项目中,用于加载host来区分环境

--report-template：指定测试报告模板路径

--report-dir：指定生成报告的路径

--html-report-name（测试一下，看是否能改名儿）

--validate：校验json用例格式

--prettify：规范json用例格式

• httprunner的运行方式：

1、一种是基于命令行模式：

hrun XXX.yml --dot-env-path env/staging.env --log-level debug

2、另一种是作为软件包集成到自己的项目中，通过类名.方法调用，这种方式也是支持参数化的。

from httprunner.api import HttpRunner  

runner = HttpRunner(failfast=False)

 runner.run("XX.yml")

首先类初始化常用的参数：__init__(self, failfast=False,save_tests=False,report_template=None, report_dir=None,log_level="INFO", log_file=None)

failfast:设置为 True 时，测试在首次遇到错误或失败时会停止运行；默认值为 False

report_template：报告模板

report_dir：生成报告位置

log_level：日志等级

log_file：生成日志文件位置

其次方法可传入的参数：run(path_or_tests, dot_env_path=None, mapping=None):

path_or_tests：用例所在文件夹或者用例的路径

dot_env_path：环境变量的路径，默认为当前工作目录的.env文件

mapping：变量映射，可用于对传入测试用例中的变量进行覆盖替换

备注：

文档中写，支持文件夹和文件路径的混合情况(list/set)存在bug，会提示“ stat: path should be string, bytes, os.PathLike or integer, not list”

原因：传入list或set时，在api->run_path->load_tests中没有将list处理，造成调用genericpath->exists在判断路径时候，系统抛异常了.

httprunner运行时的工作流

问题：基于httprunner2.0.1版本

1、有些接口的入参需要时间戳，并且这个时间戳是存在有效期的

问题：我们把时间戳写在了case层，当用例数过多的时候，把变量加载完再去运行，就会造成可能执行的时候，时间戳已经失效了

解决：将具有时效性的入参，写在api层，这样每次运行时，会取到当前时间戳

2、variables变量覆盖问题

问题：文档中描述“若某变量在 config 和某 test 中都定义了，则该 test 中使用自己定义的变量值”，在目前系统中是有bug的

原因：在parse里边进行变量替换时，写反了替换变量

3、extract提取参数问题

问题：web系统中，如增加客户资料信息接口，接口返回值并没有返回客户id，但是为了做连贯性用例，我们比较希望获取这个值

不建议的解决办法：修改接口的返回值，通过sql获取刚刚添加的资料的id，并塞入接口返回值然后通过extract关键字进行抽取

4、小技巧

问题：目前api仅用于接口定义，在case层完善用例，但是入参很多的时候，针对某个入参，其他参数无所谓的时候，造成case定义的变量冗余

解决：可在api层的variables字段里边，将所有的入参给个默认值，在api里边通过$引用变量，然后外边case调用的时候，根据覆盖的原则，想改变哪个入参，就填写哪个入参。

5、用例分层后，suite层是不支持直接调用api的

分析：根据源码可知，_parse_testsuite方法在解析testsuite的时候，并没有解析test字段，如图：

6、当接口定义中，入参的key如果遇到yes、no字段，一定要记着加引号，否则程序load时候，会当做boolean类型处理，处理为True、False

7、times重复执行指定次数问题

问题：目前times只能应用在api上，即只能重复执行测试步骤。在testcase层的config中和testsuite的config中都不能使用times关键字，去实现多次执行测试用例。以下是按照用例分层后，可调用到的。

解决办法：因为httprunner对外提供调用，所以我们可以自己写个python方法，重复调用。对于我们项目需要频繁造数比较有帮助

8、suite层不能使用validate字段

---

以上为工具使用上遇到的问题以及基于我们项目本身的小技巧~

本文转载自Qtest

---

往期精彩回顾

2019年度精选文章

基于Appium的UI自动化测试

全国新型肺炎实时动态

---

360技术公众号

技术干货|一手资讯|精彩活动

扫码关注我们