在《HttpRunner 2.0 正式发布》中提到,HttpRunner 从 2.0 版本开始,对测试用例组织形式进行了较大的调整,更正了之前在自动化测试概念上的偏差。
对应地,测试用例分层机制也进行了重新设计,因此在概念和使用方法方面都会出现很大的差异。本文便是对新的测试用例分层机制进行介绍。
关于为什么要使用测试用例分层机制,在《HttpRunner 的测试用例分层机制(已过期)》中已经进行了详细的介绍,虽然使用方法变化了,但原理上都是相同的。
概括来说,测试用例分层机制的核心是将接口定义、测试步骤、测试用例、测试场景进行分离,单独进行描述和维护,从而尽可能地减少自动化测试用例的维护成本。
逻辑关系图如下所示:
同时,强调如下几点核心概念:
有序
集合,每一个测试步骤对应一个 API 的请求描述无序
集合,集合中的测试用例应该都是相互独立,不存在先后依赖关系的;如果确实存在先后依赖关系,那就需要在测试用例中完成依赖的处理如果对于上述第三点感觉难以理解,不妨看下上图中的示例:
理解了测试用例分层模型,接下来我们再来看下在分层模型下,接口、测试用例、测试用例集的描述形式。
为了更好地对接口描述进行管理,推荐使用独立的文件对接口描述进行存储,即每个文件对应一个接口描述。
接口定义描述的主要内容包括:name、variables、request、base_url、validate 等,形式如下:
name: get headers
base_url: http://httpbin.org
variables:
expected_status_code: 200
request:
url: /headers
method: GET
validate:
- eq: ["status_code", $expected_status_code]
- eq: [content.headers.Host, "httpbin.org"]
其中,name 和 request 部分是必须的,request 中的描述形式与 requests.request 完全相同。
另外,API 描述需要尽量保持完整,做到可以单独运行。如果在接口描述中存在变量引用的情况,可在 variables 中对参数进行定义。通过这种方式,可以很好地实现单个接口的调试。
$ hrun api/get_headers.yml
INFO Start to run testcase: get headers
headers
INFO GET http://httpbin.org/headers
INFO status_code: 200, response_time(ms): 477.32 ms, response_length: 157 bytes
.
----------------------------------------------------------------------
Ran 1 test in 0.478s
OK
有了接口的定义描述后,我们编写测试场景时就可以直接引用接口定义了。
在测试步骤(teststep)中,可通过 api
字段引用接口定义,引用方式为对应 API 文件的路径,绝对路径或相对路径均可。推荐使用相对路径,路径基准为项目根目录,即 debugtalk.py
所在的目录路径。
- config:
name: "setup and reset all."
variables:
user_agent: 'iOS/10.3'
device_sn: "TESTCASE_SETUP_XXX"
os_platform: 'ios'
app_version: '2.8.6'
base_url: "http://127.0.0.1:5000"
verify: False
output:
- session_token
- test:
name: get token (setup)
api: api/get_token.yml
variables:
user_agent: 'iOS/10.3'
device_sn: $device_sn
os_platform: 'ios'
app_version: '2.8.6'
extract:
- session_token: content.token
validate:
- eq: ["status_code", 200]
- len_eq: ["content.token", 16]
- test:
name: reset all users
api: api/reset_all.yml
variables:
token: $session_token
若需要控制或改变接口定义中的参数值,可在测试步骤中指定 variables 参数,覆盖 API 中的 variables 实现。
同样地,在测试步骤中定义 validate 后,也会与 API 中的 validate 合并覆盖。因此推荐的做法是,在 API 定义中的 validate 只描述最基本的校验项,例如 status_code,对于与业务逻辑相关的更多校验项,在测试步骤的 validate 中进行描述。
在测试用例的测试步骤中,除了可以引用接口定义,还可以引用其它测试用例。通过这种方式,可以在避免重复描述的同时,解决测试用例的依赖关系,从而保证每个测试用例都是独立可运行的。
在测试步骤(teststep)中,可通过 testcase
字段引用其它测试用例,引用方式为对应测试用例文件的路径,绝对路径或相对路径均可。推荐使用相对路径,路径基准为项目根目录,即 debugtalk.py
所在的目录路径。
例如,在上面的测试用例("setup and reset all.")中,实现了对获取 token 功能的测试;同时,在很多其它功能中都会依赖于获取 token 的功能,如果将该功能的测试步骤脚本拷贝到其它功能的测试用例中,那么就会存在大量重复,当需要对该部分进行修改时就需要修改所有地方,显然不便于维护。
比较好的做法是,在其它功能的测试用例(如创建用户)中,引用获取 token 功能的测试用例(testcases/setup.yml)作为一个测试步骤,从而创建用户("create user and check result.")这个测试用例也变得独立可运行了。
- config:
name: "create user and check result."
id: create_user
base_url: "http://127.0.0.1:5000"
variables:
uid: 9001
device_sn: "TESTCASE_CREATE_XXX"
output:
- session_token
- test:
name: setup and reset all (override) for $device_sn.
testcase: testcases/setup.yml
output:
- session_token
- test:
name: create user and check result.
variables:
token: $session_token
testcase: testcases/deps/check_and_create.yml
当测试用例数量比较多以后,为了方便管理和实现批量运行,通常需要使用测试用例集来对测试用例进行组织。
在前文的测试用例分层模型中也强调了,测试用例集(testsuite)是测试用例的 无序
集合,集合中的测试用例应该都是相互独立,不存在先后依赖关系的;如果确实存在先后依赖关系,那就需要在测试用例中完成依赖的处理。
因为是 无序
集合,因此测试用例集的描述形式会与测试用例有些不同,在每个测试用例集文件中,第一层级存在两类字段:
config:
name: create users with uid
variables:
device_sn: ${gen_random_string(15)}
var_a: ${gen_random_string(5)}
var_b: $var_a
base_url: "http://127.0.0.1:5000"
testcases:
create user 1000 and check result.:
testcase: testcases/create_user.yml
variables:
uid: 1000
var_c: ${gen_random_string(5)}
var_d: $var_c
create user 1001 and check result.:
testcase: testcases/create_user.yml
variables:
uid: 1001
var_c: ${gen_random_string(5)}
var_d: $var_c
对于参数化场景,可通过 parameters 实现,描述形式如下所示。
config:
name: create users with parameters
variables:
device_sn: ${gen_random_string(15)}
base_url: "http://127.0.0.1:5000"
testcases:
create user $uid and check result for $device_sn.:
testcase: testcases/create_user.yml
variables:
uid: 1000
device_sn: TESTSUITE_XXX
parameters:
uid: [101, 102, 103]
device_sn: [TESTSUITE_X1, TESTSUITE_X2]
参数化后,parameters 中的变量将采用笛卡尔积组合形成参数列表,依次覆盖 variables 中的参数,驱动测试用例的运行。
在对测试用例文件进行组织管理时,对于文件的存储位置均没有要求和限制,在引用时只需要指定对应的文件路径即可。但从约定大于配置的角度,最好是按照推荐的文件夹名称进行存储管理,并可通过子目录实现项目模块分类管理。
总结如下:
debugtalk.py
放置在项目根目录下,假设为 PRJ_ROOT_DIR
PRJ_ROOT_DIR/api
目录下PRJ_ROOT_DIR/testcases
目录下PRJ_ROOT_DIR/testsuite
目录下目录结构如下所示:
$ tree tests
tests
├── api
│ ├── create_user.yml
│ ├── get_headers.yml
│ ├── get_token.yml
│ ├── get_user.yml
│ └── reset_all.yml
├── debugtalk.py
├── testcases
│ ├── create_user.yml
│ ├── deps
│ │ └── check_and_create.yml
│ └── setup.yml
└── testsuites
├── create_users.yml
└── create_users_with_parameters.yml
同时,在 HttpRunner
中实现了一个脚手架工具,可以快速创建项目的目录结构。该想法来源于 Django
的 django-admin.py startproject project_name
。
使用方式也与 Django
类似,只需要通过 --startproject
指定新项目的名称即可。
$ hrun --startproject demo
Start to create new project: demo
CWD: /Users/debugtalk/MyProjects/examples
created folder: demo
created folder: demo/api
created folder: demo/testcases
created folder: demo/testsuites
created folder: demo/reports
created file: demo/debugtalk.py
created file: demo/.env