给你一个项目，接口自动化测试怎么开展的？
1、需求分析 -
1.了解业务/功能 -
2.项目现状TDD -
2.1 那些模块适合做自动化测试，那些不需要
2.2 如果这些项目只有半年时间，不需要做自动化
2.3 自动化项目都是一些长期迭代的项目适合做
2.4 项目有一定的周期，
2.5 历史功能的回归测试- 覆盖一些手工测试的旧功能，提高效率
2.6 TDD - 就是测试驱动开发，测试与开发保持同步，注意的是开发人员一定要做单元测试
2.7 接口自动化是自动化里面效率最高的，稳定性比较好
3.历史功能/稳定的功能/新的功能/线上问题最多的历史功能模块？核心功能/自己负责的部分
2、接口的了解 -
1.首先是要了解接口文档以及他的属性业务，可以通过一下方式来了解：
swagger：
1.1 swagger（可以自动生成接口文档）：前提是开发人员要配合，开发人员要按照一定的规则来写，否则则是生成不出来的
swagger生成机制：根据开发人员的代码里面按照他的规则去识别到对应的接口，把他的信息拿过来
1.2 yapi:
抓包（不建议）：
1. 需要花费较多的时间，特别是比较多的时候，会懵，
2. 这个方式只适合辅助你去了解接口的业务，并不能决定接口文档
向上抛出-
1. 找领导协商外部资源，开发提供接口
2. 领导之间协调比较好
3、自动化框架或者工具的选择：
1. 工具的可扩展性以及扩展语言
1.1 测试接口的工具：postman/soapui/HttpRunner
1.2 如果有指定用指定的，如果没有指定，使用自己最熟悉的那个工具
选择什么工具需要看所处的环境
1.3 还要确保几个复杂的接口这个工具可以实现，例如在：鉴权和断言方面的处理
4、写接口用例？
1.在面试的时候特别要注意一个问题：
比如有个面试官问你：你们项目做了多少个接口的自动化，你如何回答？
1.一般回答至少要50+个接口，少于10个没必要做接口的自动化
2.假设平均每个接口5个用例，50个接口也有至少也有1000条用例
3.写用例（excel里）花了多长时间？需要注意回答
3.1 初期可能接口业务不熟悉,进度比较慢，一天1-2个接口左右
3.2 后期做熟练了，速度自然而然就提升了，基于业务的理解，可能一天5-6个左右
3.3 还需要看接口的复杂程度，简单比较快，难得可能一天一个都有可能
4. 你一天写多少个用例？
4.1 一个接口至少15+个用例，写完需要进行运行调试，修改，都需要时间
4.2 一天至少5个用例，这里的用例是包括 excel的用例和加代码 一起
2.写接口用例脚本，要尽可能的早加入jenkins集成
2.1 一般来说做了1-2个接口的时候就要考虑进行jenkins集成
2.2 问题可以早点发现，进行调整优化
2.3 每天用例数量的增长过程，在jenkins平台上一清二楚，包括通过率，在一个持续的调试和优化中，
减少自己脚本的问题，如果出现错误，那就是接口那边的问题，可以看到整个接口自动化的的曲线，
可以有一个比较好的数据让领导看到
3.需要定期汇报
4.测试报告 -
1.需要去分析用例失败的原因，是接口还是脚本处理上的问题
5.从你最开始做自动化，到一直做自动化的一个过程中，你需要做：
1.需要按照日期记录下发现的bug，可以形成一个历史bug的曲线
2.用excel或者其他记录
5、所有的用例脚本写完了就进入——维护阶段
1.如果开发修改了接口，那么我们也需要同步修改我们写的用例，保持一致
2.新增接口，在现有的基础上新增新的接口
3.遇到了问题或者哟了新的方案，进行优化框架，使框架更加完善
4. 一个项目做自动化的时候，只是一个框架，不会是两个
自动化测试方案？
6、自动化框架提供了哪些功能
比如说我用你的框架，可以使用哪些功能？
1、编写用例(前置后置、断言)、执行用例、数据库校验，生成测试报告。
2、日志功能，回溯问题
针对接口测试：
1.配置文件的处理
2.excel用例数据的读取-数据参数化(数据驱动思想)实现
3.http请求封装：鉴权处理，请求头处理，url处理，data的处理，发送请求
4.接口关联的处理，接口之间的传递
5.提取响应的结果的提取
6.数据替换处理
7.连接数据库的处理
8.数据生成处理
9.路径的处理
7、框架的整体结构、结构设计
1.进行分层设计思想，每个py文件放在指定的目录下，避免路路径混乱
2.可以更加有效的进行操作，比较清晰明了
3.分层设计思想主要有以下几层：
3.1 Conf 配置层（这个是配置文件的）
1.数据库连接配置
2.全局变量url配置
3.日志配置
4.全局共用数据配置
3.2 Output 输出层
1 logs 文件夹（这个是输出的日志的路径）
1.主要是放日志文件的放置
2.reports 文件夹（这个是输出的测试报告的路径）
2.生成的测试报告的文件放置
3.3 Public 公共工具层：
1.配置文件的处理
2.excel用例数据的读取-数据参数化(数据驱动思想)实现
3.http请求封装：鉴权处理，请求头处理，url处理，data的处理，发送请求
4.接口关联的处理，接口之间的传递
5.提取响应的结果的提取
6.数据替换处理
7.连接数据库的处理
8.数据生成处理
9.路径的处理
10.读取日志的处理
3.4 TesatData 文件夹（这个是放测试用例的路径）：
1.就是excel用例的
2.ini配置文件
3.脚本生成的数据
3.5 TesatCase 文件夹（这个是测试用例执行的路径和用例收集与测试报告生成的路径）：
1.用例执行文件：
unittest实现
ddt模块
3.6 main.py文件
1.框架的入口文件
2.执行他，会自动收集用例执行用例生成报告
8.框架的运行流流程是怎样的的：
概念：先想明白用例逻辑/实现-步骤、断言、哪些数据是动态替换，才去写代码。
1.编写excel测试数据
用例步骤：
2.根据表单读取到用例数据
3.使用unittest框架定义测试类。并使用ddt模块应用数据驱动思想
4.类前置当中，清除环境变量类当中的动态属性
# 从第五步开始是每个数据都要做的事
5.替换请求数据当中，需要动态替换的数据(来自于接口返回值、配置文件、脚本生成的)。
6.如果有前置sql语句，还需要替换sql查询到的数据
7.发送请求
8.若有提取表达式，在响应结果当中，jsonpath提取数据，并设置为环境变量
9.若有断言表达式，则以字典的形式，比对期望和实际结果。
10.若有sql检查，则在数据库中执行sql数据，与期望结果比对。