模板
教程
環(huán)境
性能
功能
管理
HttpRunner 的測試用例分層機制
在 HttpRunner 中，測試用例引擎最大的特色就是支持 YAML/JSON 格式的用例描述形式。
采用 YAML/JSON 格式編寫(xiě)維護測試用例，優(yōu)勢還是很明顯的：
- 相比于表格形式，具有更加強大的靈活性和更豐富的信息承載能力；
- 相比于代碼形式，減少了不必要的編程語(yǔ)言語(yǔ)法重復，并最大化地統一了用例描述形式，提高了用例的可維護性。
以最常見(jiàn)的登錄注銷(xiāo)為例，我們的測試用例通常會(huì )描述為如下形式：
- 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]
相信大家已經(jīng)對該種用例描述形式十分熟悉了。不過(guò)，該種描述形式的問(wèn)題在于，接口通常會(huì )出現在多個(gè)測試場(chǎng)景中，而每次都需要對接口進(jìn)行定義描述，包括請求的URL、Header、Body、以及預期響應值等，這就會(huì )產(chǎn)生大量的重復。
例如，在某個(gè)項目中存在三個(gè)測試場(chǎng)景：
-
場(chǎng)景A：注冊新賬號（
API_1/2）、登錄新注冊的賬號（API_3/4/5）、查看登錄狀態(tài)（API_6）； -
場(chǎng)景B：登錄已有賬號（
API_3/4/5）、注銷(xiāo)登錄（API_7/8）； -
場(chǎng)景C：注銷(xiāo)登錄（
API_7/8）、查看登錄狀態(tài)（API_6）、注冊新賬號（API_1/2）。
按照常規的接口測試用例編寫(xiě)方式，我們需要創(chuàng )建3個(gè)場(chǎng)景文件，然后在各個(gè)文件中分別描述三個(gè)測試場(chǎng)景相關(guān)的接口信息。示意圖如下所示。
在本例中，接口（ API_1/2/6 ）在場(chǎng)景A和場(chǎng)景C中都進(jìn)行了定義；接口（ API_3/4/5 ）在場(chǎng)景A和場(chǎng)景B中都進(jìn)行了定義；接口（ API_7/8 ）在場(chǎng)景B和場(chǎng)景C中都進(jìn)行了定義?？梢灶A見(jiàn)，當測試場(chǎng)景增多以后，接口定義描述的維護就會(huì )變得非常困難和繁瑣。
接口的分層定義描述
那要如何進(jìn)行優(yōu)化呢？
其實(shí)也很簡(jiǎn)單，在編程語(yǔ)言中，如果出現重復代碼塊，我們通常會(huì )將其封裝為類(lèi)或方法，然后在需要時(shí)進(jìn)行調用，以此來(lái)消除重復。同樣地，我們也可以將項目的API進(jìn)行統一定義，里面包含API的請求和預期響應描述，然后在測試場(chǎng)景中進(jìn)行引用即可。
示意圖如下所示。
具體地，我們可以約定將項目的所有API接口定義放置在 api 目錄下，并在 api 目錄中按照項目的系統模塊來(lái)組織接口的定義；同時(shí)，將測試場(chǎng)景放置到 testcases 目錄中。
此時(shí)測試用例文件的目錄結構如下所示：
? 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
而對于A(yíng)PI接口的定義，與之前的描述方式基本一致，只做了兩點(diǎn)調整：
-
接口定義塊（
block）的標識為api； -
接口定義塊中包含
def字段，形式為api_name(*args)，作為接口的唯一標識ID；需要注意的是，即使api沒(méi)有參數，也需要帶上括號，api_name()；這和編程語(yǔ)言中定義函數是一樣的。
- 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]
有了接口的定義描述后，我們編寫(xiě)測試場(chǎng)景時(shí)就可以直接引用接口定義了。
同樣是背景描述中的登錄注銷(xiāo)場(chǎng)景，測試用例就描述為變?yōu)槿缦滦问健?/p>
- 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接口進(jìn)行分層定義后，我們在測試用例場(chǎng)景中引用接口定義時(shí)，與編程語(yǔ)言里面調用函數的形式基本完全一樣，只需要指定接口的名稱(chēng)，以及所需傳遞的參數值；同樣的，即使沒(méi)有參數，也需要帶上括號。
實(shí)現接口的分層定義描述后，我們就可以避免接口的重復定義。但是，我們回過(guò)頭來(lái)看之前的案例，發(fā)現仍然會(huì )存在一定的重復。
如上圖所示，場(chǎng)景A和場(chǎng)景C都包含了注冊新賬號（ API_1/2 ）和查看登錄狀態(tài)（ API_6 ），場(chǎng)景A和場(chǎng)景B都包含了登錄已有賬號（ API_3/4/5 ），場(chǎng)景B和場(chǎng)景C都包含了注銷(xiāo)登錄（ API_7/8 ）。
雖然我們已經(jīng)將接口的定義描述抽離出來(lái)，避免了重復的定義；但是在實(shí)際業(yè)務(wù)場(chǎng)景中，某些功能（例如登錄、注銷(xiāo)）會(huì )在多個(gè)場(chǎng)景中重復出現，而該功能又涉及到多個(gè)接口的組合調用，這同樣也會(huì )出現大量的重復。
接口的模塊化封裝
玩過(guò)積木的同學(xué)可能就會(huì )想到，我們也可以將系統的常用功能封裝為模塊（suite），只需要在模塊中定義一次，然后就可以在測試場(chǎng)景中重復進(jìn)行引用，從而避免了模塊功能的重復描述。
具體地，我們可以約定將項目的所有模塊定義放置在 suite 目錄下，并在 suite 目錄中按照項目的功能來(lái)組織模塊的定義。
后續，我們在 testcases 目錄中描述測試場(chǎng)景時(shí)，就可同時(shí)引用接口定義和模塊定義了；模塊和接口的混合調用，必將為我們編寫(xiě)測試場(chǎng)景帶來(lái)極大的靈活性。
此時(shí)測試用例文件的目錄結構如下所示：
? 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
需要注意的是，我們在組織測試用例描述的文件目錄結構時(shí)，遵循約定大于配置的原則：
-
API接口定義必須放置在
api目錄下 -
模塊定義必須放置在
suite目錄下 -
測試場(chǎng)景文件必須放置在
testcases目錄下 -
相關(guān)的函數定義放置在
debugtalk.py中
至此，我們實(shí)現了測試用例的 接口-模塊-場(chǎng)景 分層，從而徹底避免了重復定義描述。
腳手架工具
得益于約定大于配置的原則，在 HttpRunner 中實(shí)現了一個(gè)腳手架工具，可以快速創(chuàng )建項目的目錄結構。該想法來(lái)源于 Django 的 django-admin.py startproject project_name 。
使用方式也與 Django 類(lèi)似，只需要通過(guò) --startproject 指定新項目的名稱(chēng)即可。
$ 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
運行之后，就會(huì )在指定的目錄中生成新項目的目錄結構，接下來(lái)，我們就可以按照測試用例的 接口-模塊-場(chǎng)景 分層原則往里面添加用例描述信息了。
總結
如果看到這里你還不明白測試用例分層的必要性，那也沒(méi)關(guān)系，測試用例分層不是必須的，你還是可以按照之前的方式組織測試用例。不過(guò)當你某一天發(fā)現需要進(jìn)行分層管理時(shí)，你會(huì )發(fā)現它就在那里，很實(shí)用。
最后，在 HttpRunner 項目的 examples/HelloWorld 目錄中，包含了一份完整的分層測試用例示例，相信會(huì )對大家有所幫助。
原文轉自：http://debugtalk.com/post/HttpRunner-testcase-layer/
