公司计划系统的开展接口自动化测试,须要我这边调研一下主流的接口测试框架给后端测试(主要测试接口)的同事介绍一下每一个框架的特定和使用方式。后端同事根据他们接口的特色提出一下需求,看哪一个框架更适合咱们。html
一、接口编写方便。
二、方便调试接口。
三、支持数据初始化。
四、生成测试报告。
五、支持参数化。python
优势ios
关键字驱动,自定义用户关键字。数据库
支持测试日志和报告生成。json
支持系统关键字开发,可扩展性好。后端
支持数据库操做。api
缺点app
接口测试用例写起来不简洁。框架
须要掌握特定语法。dom
*** Settings *** Library RequestsLibrary Library Collections *** Test Cases *** test_get_event_list # 查询发布会(GET请求) ${payload}= Create Dictionary eid=1 Create Session event http://127.0.0.1:8000/api ${r}= Get Request event /get_event_list/ params=${payload} Should Be Equal As Strings ${r.status_code} 200 log ${r.json()} ${dict} Set variable ${r.json()} #断言结果 ${msg} Get From Dictionary ${dict} message Should Be Equal ${msg} success ${sta} Get From Dictionary ${dict} status ${status} Evaluate int(200) Should Be Equal ${sta} ${status}
结果:不考虑,没人愿意这么写接口用例。
优势
支持参数化
不须要写代码
缺点
建立接口用例效率不高。
不能生成查看每个接口执行状况的测试报告。
总结:不考虑,接口编写不方便,最主要是不能生成测试报告,若是作接口性能的话能够考虑。
优势:
基于YAML/JSON格式,专一于接口自己的编写。
接口编写简单
生成测试报告
接口录制功能。
缺点:
没有编辑器插件对语法校验,容易出错。
官方文档没有详细的说明。
扩展不方便。
[ { "config": { "name": "testcase description", "variables": [], "request": { "base_url": "http://127.0.0.1:5000", "headers": { "User-Agent": "python-requests/2.18.4" } } } }, { "test": { "name": "test case name", "request": { "url": "/api/get-token", "headers": { "device_sn": "FwgRiO7CNA50DSU", "user_agent": "iOS/10.3", "os_platform": "ios", "app_version": "2.8.6", "Content-Type": "application/json" }, "method": "POST", "date": {"sign": "958a05393efef0ac7c0fb80a7eac45e24fd40c27"} }, "validate": [ {"eq": ["status_code", 200]}, {"eq": ["headers.Content-Type", "application/json"]}, {"eq": ["content.success", true]}, {"eq": ["content.token", "baNLX1zhFYP11Seb"]} ] } }]
总结:能够考虑,至于接口数据的初始化可能须要单独处理。
doc: https://cn.httprunner.org/quickstart/
BDD行为驱动测试框架。
优势:
行为文件与脚本文件分离,本质上实现了数据驱动。
功能强大灵活,本质上还用Python写接口用例。
自动生成测试报告。
VS Code有支持插件
缺点:
门槛略高,须要了解BDD的用法。
须要会markdworn语法
行为描述文件:
## test post request * post "http://httpbin.org/post" interface |key | status_code| |------|-----------| |value1|200 | |value2|200 | |value3|200 |
测试脚本:
…… @step("post <url> interface <table>") def test_get_request(url, table): values = [] status_codes = [] for word in table.get_column_values_with_name("key"): values.append(word) for word in table.get_column_values_with_name("status_code"): status_codes.append(word) for i in range(len(values)): r = requests.post(url, data={"key": values[i]}) result = r.json() assert r.status_code == int(status_codes[i])
总结:推荐使用,BDD有必定门槛,看测试人员的学些能力和接受速度。
doc: https://docs.gauge.org/latest/writing-specifications.html#special-parameter-csv
利用现有的框架和库本身定制。
优势:
缺点:
数据文件:
{ "test_case1": { "key": "value1", "status_code": 200 }, "test_case2": { "key": "value2", "status_code": 200 }, "test_case3": { "key": "value3", "status_code": 200 }, "test_case4": { "key": "value4", "status_code": 200 }}
测试用例:
import requests import unittest from ddt import ddt, file_data @ddtclass InterfaceTest(unittest.TestCase): def setUp(self): self.url = "http://httpbin.org/post" def tearDown(self): print(self.result) @file_data("./data/test_data_dict.json") def test_post_request(self, key, status_code): r = requests.post(self.url, data={"key": key}) self.result = r.json() self.assertEqual(r.status_code, status_code)
总结:推荐使用,代码相对简单,功能足够灵活。
~~~~~~
我花了两天时间整理这些框架,其实重点就是了解HttpRunner 和 gauge 。
yg
HttpRunner 没有编辑器插件,自己就是一个YAML/JSON配置文件,因此配置写错了,但只要是合法的YAML/JSON格式,也看不出来,只有运行的事后才知道。就像你用记事本写代码同样,只有运行了才知道代码有没有写错。
另外,扩展起来也不是特别方便,单独用python实现一些函数:在json文件中
{"device_sn": "${gen_random_string(15)}"}
以这样的方式引用gen_random_string()
函数。
gauge我已经分享过两篇基础文章了,虽然用BDD拿来作接口理念不搭,但并非不能够,惟一的缺点是用BDD来描述接口行为不合适,其余的都没毛病,能够参数化,断言写起来也简单,测试报告也漂亮,本质上仍是用Python实现一些功能,因此很是灵活。
unittest + requests + HTMLTestRunner是我最熟悉的方案,几乎没什么短板。之前经过这种方案写过不少测试用例,此次把ddt加上彷佛更完美了。