背景
目前市面上的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。也问下大家，有没有这样的平台，有的话我就不继续写了，打算转行收破烂了。
