-
第一个问题的答案就是用到了requests库的哪些知识。requests底层的一些参数信息，data,json , 代理，超时，
-
第二个问题，接口自动化的实现思路：一开始的时候，代码耦合性很严重，优化代码结构，业务人员没办法写业务用例及相关的断言信息。写接口的同学也是跟业务耦合的。所以分层，了解业务的同学只写业务用例，了解接口协议的可以专心写接口。中间碰到了复杂断言，大量数据，多层嵌套的响应断言的优化，以及结合jenkins，进行多场景的切换。
-
第三个问题，添加token之前判断，如果存在则不获取。
-
第四个问题，接口产生的垃圾数据如何清理？
设计用例
部门管理接口测试用例.xlsx (14.6 KB)
接口用例测试脚本
把面条式的代码归为4类，哪部分信息是跟业务没关系的？可以抽离出来。做功能测试的时候更关注哪一个？（2，3，4跟业务强相关）
优化代码架构
UML类图，体现模块与模块之间的关系，用例模块关注测试步骤，断言，调用api模块里的接口。在API模块把接口的详情信息封装好。api模块继承自更底层的API层，
接口自动化测试框架封装思路
-
WeworkApi层
-
API层
-
用例层
-
utils工具层
多层嵌套响应信息断言的优化，使用jsonpath
多环境切换场景优化
-
配置不同环境的信息，如基地址url，跟账号相关的app_id和secret
-
读取配置文件的信息，
在方法上边加@property装饰器, 就将方法转变成了属性，调用的时候不用加括号
-
在WeworkApi中修改base_url和app_id和secret
第一个步骤：在命令行设置环境变量
整体结构响应断言
除了跟业务强相关的字段，可以提取出来断言，其他相应信息返回的字段特别多，只关注它的结构，数据类型，关注这个字段有没有以及它的数据类型，不关心它具体的值。比如查询页面列表信息，返回的字段一般比较多
