51Testing软件测试论坛

标题: HttpRunner 的测试用例分层机制 [打印本页]

作者: 雨中漫步_012 时间: 2018-4-3 14:13
标题: HttpRunner 的测试用例分层机制
在HttpRunner中，测试用例引擎最大的特色就是支持YAML/JSON格式的用例描述形式。

采用YAML/JSON格式编写维护测试用例，优势还是很明显的：

相比于表格形式，具有更加强大的灵活性和更丰富的信息承载能力；
相比于代码形式，减少了不必要的编程语言语法重复，并最大化地统一了用例描述形式，提高了用例的可维
护性。
以最常见的登录注销为例，我们的测试用例通常会描述为如下形式：

-

config:
name: demo-login-logoff
variable_binds:
- UserName: test001
- Password: 123456
request:
base_url: http://xxx.debugtalk.com
headers:
Accept: application/json
User-Agent: iOS/10.3
- test:
name: Login
request:
url: /api/v1/Account/Login
method: POST
json:
UserName: $UserName
Pwd: $Password
VerCode: ""
validators:
- eq: ["status_code", 200]
- eq: ["content.IsSuccess", True]
- eq: ["content.Code", 200]
- test:
name: Logoff
request:
url: /api/v1/Account/LoginOff
method: GET
validators:
- eq: ["status_code", 200]
- eq: ["content.IsSuccess", True]
- eq: ["content.Code", 200]

复制代码

相信大家已经对该种用例描述形式十分熟悉了。不过，该种描述形式的问题在于，接口通常会出现在多个测
试场景中，而每次都需要对接口进行定义描述，包括请求的URL、Header、Body、以及预期响应值等，这就
会产生大量的重复。

例如，在某个项目中存在三个测试场景：

场景A：注册新账号（API_1/2）、登录新注册的账号（API_3/4/5）、查看登录状态（API_6）；
场景B：登录已有账号（API_3/4/5）、注销登录（API_7/8）；
场景C：注销登录（API_7/8）、查看登录状态（API_6）、注册新账号（API_1/2）。
按照常规的接口测试用例编写方式，我们需要创建3个场景文件，然后在各个文件中分别描述三个测试场景相
关的接口信息。示意图如下所示。

[attach]112557[/attach]

在本例中，接口（API_1/2/6）在场景A和场景C中都进行了定义；接口（API_3/4/5）在场景A和场景B中都进
行了定义；接口（API_7/8）在场景B和场景C中都进行了定义。可以预见，当测试场景增多以后，接口定义
描述的维护就会变得非常困难和繁琐。

接口的分层定义描述

那要如何进行优化呢？

其实也很简单，在编程语言中，如果出现重复代码块，我们通常会将其封装为类或方法，然后在需要时进行
调用，以此来消除重复。同样地，我们也可以将项目的API进行统一定义，里面包含API的请求和预期响应描
述，然后在测试场景中进行引用即可。

示意图如下所示。
[attach]112558[/attach]

具体地，我们可以约定将项目的所有API接口定义放置在api目录下，并在api目录中按照项目的系统模块来组
织接口的定义；同时，将测试场景放置到testcases目录中。

此时测试用例文件的目录结构如下所示：

✗ tree tests
tests
├── api
│ └── v1
│    ├── Account.yml
│    ├── BusinessTrip.yml
│    ├── Common.yml
│    └── Leave.yml
├── debugtalk.py
└── testcases
├── scenario_A.yml
├── scenario_B.yml
└── scenario_C.yml
而对于API接口的定义，与之前的描述方式基本一致，只做了两点调整：

接口定义块（block）的标识为api；
接口定义块中包含def字段，形式为api_name(*args)，作为接口的唯一标识ID；需要注意的是，即使api没有
参数，也需要带上括号，api_name()；这和编程语言中定义函数是一样的。

- api:
def: api_v1_Account_Login_POST($UserName, $Password)
request:
url: /api/v1/Account/Login
method: POST
json:
UserName: $UserName
Pwd: $Password
VerCode: ""
validators:
- eq: ["status_code", 200]
- eq: ["content.IsSuccess", True]
- eq: ["content.Code", 200]
- api:
def: api_v1_Account_LoginOff_GET()
request:
url: /api/v1/Account/LoginOff
method: GET
validators:
- eq: ["status_code", 200]
- eq: ["content.IsSuccess", True]
- eq: ["content.Code", 200]

复制代码

有了接口的定义描述后，我们编写测试场景时就可以直接引用接口定义了。

同样是背景描述中的登录注销场景，测试用例就描述为变为如下形式。

- config:
name: demo
variable_binds:
- UserName: test001
- Password: 123456
request:
base_url: http://xxx.debugtalk.com
headers:
Accept: application/json
User-Agent: iOS/10.3
- test:
name: Login
api: api_v1_Account_Login_POST($UserName, $Password)
- test:
name: Logoff
api: api_v1_Account_LoginOff_GET()

复制代码

不难看出，对API接口进行分层定义后，我们在测试用例场景中引用接口定义时，与编程语言里面调用函数的
形式基本完全一样，只需要指定接口的名称，以及所需传递的参数值；同样的，即使没有参数，也需要带上
括号。

实现接口的分层定义描述后，我们就可以避免接口的重复定义。但是，我们回过头来看之前的案例，发现仍然
会存在一定的重复。
[attach]112559[/attach]

如上图所示，场景A和场景C都包含了注册新账号（API_1/2）和查看登录状态（API_6），场景A和场景B都包
含了登录已有账号（API_3/4/5），场景B和场景C都包含了注销登录（API_7/8）。

虽然我们已经将接口的定义描述抽离出来，避免了重复的定义；但是在实际业务场景中，某些功能（例如登录、
注销）会在多个场景中重复出现，而该功能又涉及到多个接口的组合调用，这同样也会出现大量的重复。

接口的模块化封装

玩过积木的同学可能就会想到，我们也可以将系统的常用功能封装为模块（suite），只需要在模块中定义一
次，然后就可以在测试场景中重复进行引用，从而避免了模块功能的重复描述。

[attach]112560[/attach]

具体地，我们可以约定将项目的所有模块定义放置在suite目录下，并在suite目录中按照项目的功能来组织模
块的定义。

后续，我们在testcases目录中描述测试场景时，就可同时引用接口定义和模块定义了；模块和接口的混合调
用，必将为我们编写测试场景带来极大的灵活性。

此时测试用例文件的目录结构如下所示：

✗ tree tests
tests
├── api
│ └── v1
│    ├── Account.yml
│    ├── BusinessTrip.yml
│    ├── Common.yml
│    └── Leave.yml
├── debugtalk.py
├── suite
│ ├── BusinessTravelApplication
│ │ ├── approve-application.yml
│ │ ├── executive-application.yml
│ │ ├── reject-application.yml
│ │ └── submit-application.yml
│ └── LeaveApplication
│    ├── approve.yml
│    ├── cancel.yml
│    └── submit-application.yml
└── testcases
├── scenario_A.yml
├── scenario_B.yml
└── scenario_C.yml
需要注意的是，我们在组织测试用例描述的文件目录结构时，遵循约定大于配置的原则：

API接口定义必须放置在api目录下
模块定义必须放置在suite目录下
测试场景文件必须放置在testcases目录下
相关的函数定义放置在debugtalk.py中
至此，我们实现了测试用例的接口-模块-场景分层，从而彻底避免了重复定义描述。

脚手架工具

得益于约定大于配置的原则，在HttpRunner中实现了一个脚手架工具，可以快速创建项目的目录结构。该想
法来源于Django的django-admin.py startproject project_name。

使用方式也与Django类似，只需要通过--startproject指定新项目的名称即可。

$ hrun --startproject helloworld
INFO:root: Start to create new project: /Users/Leo/MyProjects/helloworld
INFO:root:    created folder: /Users/Leo/MyProjects/helloworld
INFO:root:    created folder: /Users/Leo/MyProjects/helloworld/tests
INFO:root:    created folder: /Users/Leo/MyProjects/helloworld/tests/api
INFO:root:    created folder: /Users/Leo/MyProjects/helloworld/tests/suite
INFO:root:    created folder: /Users/Leo/MyProjects/helloworld/tests/testcases
INFO:root:    created file: /Users/Leo/MyProjects/helloworld/tests/debugtalk.py
运行之后，就会在指定的目录中生成新项目的目录结构，接下来，我们就可以按照测试用例的接口-模块-场
景分层原则往里面添加用例描述信息了。

总结

如果看到这里你还不明白测试用例分层的必要性，那也没关系，测试用例分层不是必须的，你还是可以按照
之前的方式组织测试用例。不过当你某一天发现需要进行分层管理时，你会发现它就在那里，很实用。

最后，在HttpRunner项目的examples/HelloWorld目录中，包含了一份完整的分层测试用例示例，相信会对大
家有所帮助。

作者: auto_tester 时间: 2018-8-28 16:34
写的很好，虽然我看的不太懂，必须点赞！

作者: zongxunqiang 时间: 2019-2-21 20:20
正要使用httprunner做测试用例分层，看了楼主说的，大概理解了测试分层的必要性以及思路。但是直接下载了httprunner框架针对业务场景不知道怎么下手，楼主可以留下联系方式咨询一下么

作者: zongxunqiang 时间: 2019-2-21 21:04
还想问一下楼主，涉及到case解析呢？

作者: ~~~xiaoxiaohei 时间: 2020-9-21 18:03
请问楼主httprunner3.0的框架目录你有研究过吗

作者: vtest-top 时间: 2020-11-14 15:46
学习了

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)