之前有同事问我，为什么你那么 High，总是有时间出去玩。实际上了解我的人应该知道，平时上班的时候我几乎不休假，除非有重要的事情需要去处理。所以当我我觉得需求休息的时候，基本上我都是连续请几天假，然后安排一次小环线自驾。就如到新公司快半年了，一个小时的假都没有休过。所以就会造成我经常出去玩的一个假象，实际上是我只要休息就会出去转转而已。实际上也是自律的一种表现。
好了，今天我们要讲的是接口自动化。实际上开展这项工作之前，我一直不敢对这个领域下手。原因在于移动互联网产品对于接口的依赖，而自组织的平台能够对接口提供多少支持，我心里没底。是否可以取代常规的 RF、Jmeter、Postman 或者直接通过脚本实现的接口测试。直到有一天，测试部的王大爷和霍 Sir 给了我很好的建议和支持，他们的理念是平台只针对接口的健壮性提供常规的验证，而接口逻辑层面的功能，应该还是交给 RF 之类的专业工具来实现，平台可以另外提供执行和跟进的功能。
对于接口健壮性层面，王大爷提供了框架可以根据接口的 header、data 规则，通过边界值、等价类划分等方法生成接口的常规测试点。关于框架是如何实现的，我这里不做介绍，希望后面看到王大爷精彩的分享。下面我们介绍代码层面的实现和逻辑。

Form

接口用例

• EmbeddedDocument 可以理解为内嵌的 json 数据格式，这里的 heder、data、assert 全部采用了这种方式。
• internal 作为界定接口提供的对象，对于不同的对象有不同的验签处理。
• smoke、regression 为不同的测试计划类型。
• interfaceType 这里泛指 Restful 风格的接口请求类型。
• deleted 用于记录是否逻辑删除，flask_admin 默认是物理删除，需要特殊处理。
• @queryset_manager用于重写 form 的返回数据范围，对于不同的测试计划，我只想符合符合测试计划类型的用例。

测试计划

• testCases 用于用户对于符合条件的用例进行多选。
• hour、minute、seconds 用于对测试计划进行定时触发。
• queryset_manager 也是同样只想返回符合条件的测试计划给前端页面，这里用了环境变量作为锁进行处理，更理想的锁应该用 Redis，这个问题就是几个月前朋友圈发的困扰了我三天的那个问题。

View

新增执行按钮

生成测试 Instance

逻辑删除

返回只有权限的测试计划或用例

手动执行测试用例或计划

Controller

生成 Instance

这个模块是小琳对接的，逻辑比较复杂，这里只截取记录到数据库的部分。
大概的业务逻辑就是根据测试用例里面对请求头和请求负载的限制描述，在这里调用生成 Instance 的过程。

执行 instance

只列出部分代码，这里大概的执行逻辑就是，不管是任务自动触发还是手动执行，都会走到这里的逻辑。然后根据 instance 里面的接口 headers、data、url 做请求处理。
然后存入到数据库里面。

Demo

测试用例

测试计划

测试结果

详细报告那里就不打开了，太丑了。需要我们团队的成员来优化，今天就写到这里。感谢大家的耐心阅读，下次将介绍 Mock 的实现。