在上一篇文章中分享了 pytest 的基本用法,本文进一步介绍 pytest 的其他实用特性和进阶技巧。
pytest fixtures
pytest 中可以使用 @pytest.fixture 装饰器来装饰一个方法,被装饰方法的方法名可以作为一个参数传入到测试方法中。可以使用这种方式来完成测试之前的初始化,也可以返回数据给测试函数。
通常使用 setup 和 teardown 来进行资源的初始化。如果有这样一个场景,测试用例 1 需要依赖登录功能,测试用例 2 不需要登录功能,测试用例 3 需要登录功能。这种场景 setup,teardown 无法实现,可以使用 pytest fixture 功能,在方法前面加个 @pytest.fixture 装饰器,加了这个装饰器的方法可以以参数的形式传入到方法里面执行。
例如在登录的方法,加上 @pytest.fixture 这个装饰器后,将这个用例方法名以参数的形式传到方法里,这个方法就会先执行这个登录方法,再去执行自身的用例步骤,如果没有传入这个登录方法,就不执行登录操作,直接执行已有的步骤。
创建一个文件名为“test_fixture.py”,代码如下:
在上面的代码中,测试用例 test_case1 和 test_case3 分别增加了 login 方法名作为参数,pytest 会发现并调用 @pytest.fixture 标记的 login 功能,运行测试结果如下:
从上面的结果可以看出,test_case1 和 test_case3 运行之前执行了 login 方法,test_case2 没有执行这个方法。
fixture 里面有一个参数 scope,通过 scope 可以控制 fixture 的作用范围,根据作用范围大小划分:session> module> class> function,具体作用范围如下:
创建目录 test_scope,并在目录下创建三个文件 conftest.py,test_scope1.py 和 test_scope2.py。
conftest.py 文件定义了公共方法,pytest 会自动读取 conftest.py 定义的方法,代码如下:
创建 test_scope1.py 文件,代码如下:
创建文件“test_scope2.py”,代码如下:
打开 cmd,进入目录 test_scope/,执行如下命令:
或者
执行结果如下:
执行过程中 pytest 会自动识别当前目录的 conftest.py,不需要导入直接引用里面的方法配置。应用到整个目录下的所有调用这里面的方法中执行。conftest.py 与运行的用例要在同一个 pakage 下,并且这个包下有 init.py 文件
如果每条测试用例都需要添加 fixture 功能,则需要在每一要用例方法里面传入这个fixture的名字,这里就可以在装饰器里面添加一个参数 autouse=‘true’,它会自动应用到所有的测试方法中,只是这里没有办法返回值给测试用例。
使用方法,在方法前面加上装饰器,如下:
@pytest.fixture 里设置 autouse 参数值为 true(默认 false),每个测试函数都会自动调用这个前置函数。
创建文件名为“test_autouse.py”,代码如下:
执行上面这个测试文件,结果如下:
从上面的运行结果可以看出,在方法 myfixture() 上面添加了装饰器 @pytest.fixture(autouse=“true”),测试用例无须传入这个 fixture 的名字,它会自动在每条用例之前执行这个 fixture。
测试过程中需要大量的测试数据,如果每条测试数据都编写一条测试用例,用例数量将是非常宠大的。一般我们在测试过程中会将测试用到的数据以参数的形式传入到测试用例中,并为每条测试数据生成一个测试结果数据。
这时候可以使用 fixture 的参数化功能,在 fixture 方法加上装饰器 @pytest.fixture(params=[1,2,3]),就会传入三个数据 1、2、3,分别将这三个数据传入到用例当中。这里可以传入的数据是个列表。传入的数据需要使用一个固定的参数名 request 来接收。
创建文件名为“test_params.py”,代码如下:
运行结果如下:
从运行结果可以看出,对于 params 里面的每个值,fixture 都会去调用执行一次,使用 request.param 来接受用例参数化的数据,并且为每一个测试数据生成一个测试结果。在测试工作中使用这种参数化的方式,会减少大量的代码量,并且便于阅读与维护。
假如项目中有测试用例 1000 条,一条测试用例需要执行 1 分钟,一个测试人员需要 1000 分钟才能完成一轮回归测试。通常我们会用人力成本换取时间成本,加几个人一起执行,时间就会缩短。如果 10 人一起执行只需要 100 分钟,这就是一种并行测试,分布式的场景。
pytest-xdist 是 pytest 分布式执行插件,可以多个 CPU 或主机执行,这款插件允许用户将测试并发执行(进程级并发),插件是动态决定测试用例执行顺序的,为了保证各个测试能在各个独立线程里正确的执行,应该保证测试用例的独立性(这也符合测试用例设计的最佳实践)。
安装
多个 CPU 并行执行用例,需要在 pytest 后面添加 -n 参数,如果参数为 auto,会自动检测系统的 CPU 数目。如果参数为数字,则指定运行测试的处理器进程数。
案例
某个项目有 200 条测试用例,每条测试用例之间没有关联关系,互不影响。这 200 条测试用例需要在 1 小时之内测试完成,可以加个-n参数,使用多 CPU 并行测试。运行方法:
进入到项目目录下,执行 pytest 可以将项目目录下所有测试用例识别出来并且运行,加上 -n 参数,可以指定 4 个 CPU 并发执行。大量的测试用例并发执行提速非常明显。
测试报告通常在项目中尤为重要,报告可以体现测试人员的工作量,开发人员可以从测试报告中了解缺陷的情况,因此测试报告在测试过程中的地位至关重要,测试报告为纠正软件存在的质量问题提供依据,为软件验收和交付打下基础。测试报告根据内容的侧重点,可以分为 “版本测试报告” 和 “总结测试报告”。执行完 pytest 测试用例,可以使用 pytest-HTML 插件生成 HTML 格式的测试报告。
安装
执行方法
结合 pytest-xdist 使用
生成测试报告
如下图:
生成的测试报告最终是 HTML 格式,报告内容包括标题、运行时间、环境、汇总结果以及用例的通过个数、跳过个数、失败个数、错误个数,期望失败个数、不期望通过个数、重新运行个数、以及错误的详细展示信息。报告会生成在运行脚本的同一路径,需要指定路径添加–html=path/to/html/report.html 这个参数配置报告的路径。如果不添加 --self-contained-html 这个参数,生成报告的 CSS 文件是独立的,分享的时候容易千万数据丢失。
编写代码时,我们经常会做出一些假设,断言就是用于在代码中捕捉这些假设。断言表示为一些布尔表达式,测试人员通常会加一些断言来断定中间过程的正确性。断言支持显示最常见的子表达式的值,包括调用,属性,比较以及二元和一元运算符。Python使用 assert(断言)用于判断一个表达式,在表达式条件为 false 的时候触发异常。
使用方法:
案例如下:
如果没有断言,没有办法判定用例中每一个测试步骤结果的正确性。在项目中适当的使用断言,来对代码的结构、属性、功能、安全性等场景检查与验证。