公司计划系统的开展接口自动化测试,需要我这边调研一下主流的接口测试框架给后端测试(主要测试接口)的同事介绍一下每个框架的特定和使用方式。后端同事根据他们接口的特点提出一下需求,看哪个框架更适合我们。
需求
1、接口编写方便。
2、方便调试接口。
3、支持数据初始化。
4、生成测试报告。
5、支持参数化。
### robot framework
优点
-
关键字驱动,自定义用户关键字。
-
支持测试日志和报告生成。
-
支持系统关键字开发,可扩展性好。
-
支持数据库操作。
缺点
-
接口测试用例写起来不简洁。
-
需要掌握特定语法。
*** Settings ***
Library RequestsLibrary
Library Collections*** Test Cases ***
test_get_event_list # 查询发布会(GET请求)${payload}= Create Dictionary eid=1Create 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} 200log ${r.json()}${dict} Set variable ${r.json()}#断言结果${msg} Get From Dictionary ${dict} messageShould Be Equal ${msg} success${sta} Get From Dictionary ${dict} status${status} Evaluate int(200)Should Be Equal ${sta} ${status}
结果:不考虑,没人愿意这么写接口用例。
###JMeter
优点
-
支持参数化
-
不需要写代码
缺点
-
创建接口用例效率不高。
-
不能生成查看每一个接口执行情况的测试报告。
总结:不考虑,接口编写不方便,最主要是不能生成测试报告,如果做接口性能的话可以考虑。
###HttpRunner
优点:
基于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"]}]}}]
总结:可以考虑,至于接口数据的初始化可能需要单独处理。
###gauge
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有一定门槛,看测试人员的学些能力和接受速度。
###Unittest+Request+HTMLRunner
利用现有的框架和库自己定制。
优点:
足够灵活强大: 分层测试、数据驱动、测试报告,集成CI...
缺点:
有一定的学习成本
数据文件:
{"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加上似乎更完美了。
【软件测试行业现状】2023年了你还敢学软件测试?未来已寄..测试人该何去何从?【自动化测试、测试开发、性能测试】
总结:
感谢每一个认真阅读我文章的人!!!
作为一位过来人也是希望大家少走一些弯路,如果你不想再体验一次学习时找不到资料,没人解答问题,坚持几天便放弃的感受的话,在这里我给大家分享一些自动化测试的学习资源,希望能给你前进的路上带来帮助。
文档获取方式:
加入我的软件测试交流群:632880530免费获取~(同行大佬一起学术交流,每晚都有大佬直播分享技术知识点)
这份文档,对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!
以上均可以分享,只需要你搜索vx公众号:程序员雨果,即可免费领取