根据我目前的工作情况回答下：
1、大多数是按照日构建，少部分会按小时或分钟构建，相当于承担了一部分监控职能
2、接口自动化发现的问题其实很少，要么是服务挂了，要么是响应的内容发生了变动
3、如果已知接口有变动，会提交做维护，大多是构建失败的时候人工确认再调整

其实我对于发现的问题比较好奇，接口自动化会在工作中发生哪些问题？看上面的评论，好像也就是那几种了，还请大神们补充下。
1、某个服务挂了，导致接口报错
2、字段值发生变动，未及时通知相关人员，导致断言失败
3、数据结构发生改变，跟 2 类似，都是接口变动导致断言失败
4、业务逻辑变动，接口存在依赖内容，影响到接口数据正确性，其结果也是导致断言失败等情况 (感觉这个最重要，接口存在依赖，可能涉及到的影响范围广，但不一定能断言到存在问题)

1、建议日构建，发布构建太频繁不建议使用；
2、出现执行失败要分析，环境问题、数据问题、用例问题、出现 bug；大部分接口自动化发现的问题都是误修改引发的，比如修改 A 接口，影响了 B 接口，导致 B 接口用例执行失败；
3、根据研发流程来，如果有较详细的接口文档，可以修后接口用例后再执行；不然就是执行失败后再针对性调整；

就是修改影响范围的测试啊，修改一个小模块，导致其他可能没想到的模块如果有 bug，需要手工测试的话会增加测试负担，接口自动化可以解放这一部分的人力，比如把冒烟用例做成自动化的话，本来每次发测都要手工做冒烟测试，这样就可以直接发布自动构建执行一次，就能直接看通过不通过了

我这边都是测试案例写完，直接写接口测试代码的，能发现问题