背景
-
目前市面上的api测试工具有
jmeter、postman。当jmeter需要添加一个PreProcessor的时候,支持java、JavaScript语言在上面编写代码,不支持python,数据参数化也不方便。postman用来做接口调试,用作自动化测试也并不方便,还有参数化行为。 -
测试框架
不同语言的单元测试框架,Junit,unittest,pytest。包括一些TDD的相关工具。其实这些都是为了基于函数级别的单元测试。当然也能作为接口测试或UI的框架。用它来编写接口自动化或者UI自动化,想要所有接口都测试全面也并不容易。 -
关于需求
需求的增删改,多数的公司我相信没有如此规范化的流程,一个开发人员修改了api文档的一些小细节,未必会(当然也有可能不是故意的)通知需求或者测试人员。而且文档也未必会写的全面,例如响应的参数不全,请求的参数说明不够充分等等 -
关于测试人员
测试人员未必会想请求参数参数化非常全面并保存整理。测试人员或产品经理对外提供api文档可能会自己整理一份文件形式的文档。上面说的这些情况都会产生各个技术人员之间大量的交流,在交流的背后更多的是无用的工作。如何解决它?
关于接口自动化的一些思考
-
第一步思考:api测试的根据是什么
显而易见是接口文档。文档是规范性文件,就必须要制定其规范性写法。就像restful风格一样,可以不是强制性代码规则,是一种约定的规范。DELETE请求也可以做POST行为,但是不建议如此编写。 -
第一步解决
统一的api文档,由开发+测试+产品/项目经理多方进行平台化管理,不同技术人员编辑维护不同的部分。例如:开发人员编辑api文档的基本要素,请求路径、方法、参数、响应等,测试主要维护和编写一些用例生成规则,产品直接导出api文档就ok了 -
第二步思考:如何定义接口文档(此步就直接为如何定义api_json吧)
根要素:版本、接口名称、路径、方法、预先行为(setup)、请求头、请求参数、请求预期、额外添加Case、结束行为(teardown)
请求字段参数中的详细要素:参数名称、参数类型、参数位置、是否必填、是否为空、是否唯一、描述、是否预获取、额外失败
{
"name": "登录接口",
"code": "login_api",
"versions": ['v1.0', 'v2.0'],
"route": "/user/login",
"method": "POST",
"setup": [
],
"headers": {
"Content-Type": "application/json",
},
"fields": [
{
"name": "account",
"require": {
"default": True,
"unexpected_result": {"$.code": "40001", "$.msg": "账号必填"}
},
"null": {
"default": False,
"unexpected_result": {"$.code": "40001", "$.msg": "账号必填"}
},
"data_type": "str",
"location": 1,
"pre_get": {
"true": "{{ config.get('$.localhost.account') }}",
"false": "xxxxxxxx",
"unexpected_result": {"$.msg": "账号不存在"}
},
"failures": [("admin1234", {"$.msg": "此用户未授角色"})],
"desc": "账号",
},
{
"name": "password",
"require": {
"default": True,
"unexpected_result": {"$.code": "40002", "$.msg": "密码必填"}
},
"null": {
"default": False,
"unexpected_result": {"$.code": "40002", "$.msg": "密码必填"}
},
"data_type": "str",
"location": 1,
"pre_get": {
"true": "{{ config.get('$.localhost.password') }}",
"false": "xxxxxxxx",
"unexpected_result": {"$.msg": "密码验证失败"}
},
"desc": "密码",
},
],
"teardown": [
],
"extra_case": [
],
"response": {
"expected_result": {
"$.code": "200",
"$.data.token": "\\w+",
}
}
}
- 第二步解决:
知道如何定义之后,就可以思考如何通过这种结构化的json来生成用用例并运行。目前写了一个这样的框架,不方便过多透露。 - 第三步思考:如何编写一些非纯粹字符串的内容,
比如setup、预获取字段参数、teardown等中如何编写,如何解析执行自定义语法。当然未必需要掌握ast语法树技能,有其他方法解决。 - 第三步解决:可以通过模板字符串来解析
- 第四部:参数化生成用例
- 第五步:...
更多关于接口自动化的想法
加权接口,进行负载测试,性能测试等
有兴趣加v或qq,838863149。也问下大家,有没有这样的平台,有的话我就不继续写了,打算转行收破烂了。
网友评论