# 界面自动化基本流程
请先完成项目配置的流程
# 一、基本执行逻辑
# 接口管理中管理接口信息，测试用例中对接口进行组装生成测试用例
# 二、公共参数
# 第一，第二，第三加载顺序的意思
- 这个指的是执行顺序，不管是在接口管理中点击执行，还是在用例或是定时任务中点击执行，公共参数都是第一加载到缓存中，而第一，第二，第三则是公共参数自己的加载顺序
# 第一加载-自定义
- 采取key，value的形式，加载到缓存中
- 后续可以通过数据提取进行使用，后续的第二，第三加载包括接口管理中，包括用例都可以使用
# 第二加载-SQL
- 跟jmeter类型，同一个sql需要确保只能查询到一条数据
# 第三加载-登录
- 当是第三加载的时候，key的填写是无效的，而value则需要填写登录接口的ID
- 在加载过程中会根据填写的ID，调用登录接口
- 使用场景是初始化登录的token或者cookie，免得在用例中重复填写登录接口
# 三、请求头管理
- 可以根据自己的项目实际使用headers填写，可以填的很多，实际使用的时候会进行勾选
- 接口管理中使用
- 接口管理中的headers是空的话，则使用请求头管理中的默认开启的headers
- 用例中使用
- 用例中的前置headers如果是空的，则直接使用请求头管理中的默认开启的headers
- 用例的前置headers跟用例中的接口headers有覆盖关系，下面是依次覆盖过程：
- 如果用例配置了headers，则直接使用用例的headers，放弃请求头管理中默认开启的headers
- 如果用例没有配置headers，那么则直接使用默认开启的headers
- 会有覆盖的情况：用例接口配置的优先级最大，会覆盖用例的headers，或者覆盖请求头管理中默认开始的headers，当然，是一条一条覆盖的，不是全部覆盖
# 四、接口管理
- 用户可以在这里配置接口的信息，如：名称，url，请求的数据，固定的后置操作，等等
- 不过多介绍，这里只是先配置请求，类似postman调用一下
- 如果你们的产品是直接通过url拼接的，如：127.0.0.1:8000/get/info/123456 假设这个123456是一个查询的ID，那么这个在配置的时候需要直接使用数据提取方法，在后续的流程中补充进来
- api的调用，使用的是python的request库来完成的，如果发现无法调用的情况，自己可以使用request库来请求试试看
- 参数的填写：
- 参数：通过参数形式的接口，以json格式填写，示例127.0.0.1:8000/get/info?id=123，则填写：{"id": "123"}
- 表单：通过表单形式的接口，以json格式填写
- json：通过json形式的接口，以json格式填写
- 文件：
# 五、测试用例
用例支持选择接口管理中的接口来进行请求
用例的前置：
用例的后置：
- 只支持sql的执行操作
接口的执行： 前置后置
一个接口可以配置多个场景来执行
