自动化平台总结(httprunner+djangorestframework+python3+Mysql+Vue)【基础结构构思】
一、前言
把一个以前自己搭建的自动化测试平台进行了一下重构升级，记录一下过程中的一些问题和总结。
二、简介
搭建的平台语言使用的是Python3.6，未来有空可能考虑加个java版本。前端用的Vue，主体是httprunner2.X+Djangorest-framework，平台作用是公司内部使用，mysql数据库就够用。
三、整体结构
考虑的结构是
后台：
- drfproject目录，工程创建时的系统的配置数据存放目录，命名根据项目创建时的需求
- app目录，存放平台下的子应用，目前用户这块的应用直接用自带的应该就够了
- 项目模块代码存放目录
- 接口模块代码存放目录
- 报告模块代码存放目录
- 测试用例模块代码存放目录
- 用例套件模块代码存放目录
- 用户模块代码存放目录(使用系统自带模块)
- 环境变量模块代码存放目录
- 系统配置模块代码存放目录
- 数据统计模块代码存放目录
- debugtalk模块代码存放目录
- util目录，存放一些数据处理的自定义模块，基本上应该存在suits目录，存放将要运行的目录文件，目前的考虑是用时间戳作为存放文件的最外层，避免多次运行的覆盖问题
- 最基础的对应数据库数据的读写参数的处理
- 网页列表参数的基本的分页过滤数据处理
- 因为httprunner所需要的用例格式是‘.yaml’，所以需要对用例文件的创建和文件内容的组装处理
- 报告的数据处理，将运行后的参数进行过滤后填充进报告里
- 定期清理模块，可加可不加，这方面人工更精准，清理的时间间隔这一块根据平台需求来定(如果数据需要保存的时间周期长或者需要根据需求删选，可以直接人工清理)
- 看平台需求的其他功能模块
- log目录，存放运行中需要记录的日志信息
- report目录，存放运行完毕后或者数据库导出的报告(嫌麻烦可以使用自带的格式模板，有其他需求可以寻找开源的报告模板)
- venv目录，虚拟环境数据
前端(Vue)：
首页(数据统计)+8个模块组
数据库(Mysql)
把一个自动化平台的基础结构设计清楚后，下一步就是表与表之间的关联关系、表的字段及对应的数据效验方法设计了。
首先排除无关联关系或者关联关系可有可无的数据表，比如用户表、报告表、环境变量等，把这些表排除之后就可以开始画图考虑关联了(也就是外键关联)。因为平台会使用Django自带的数据库迁移功能，中途的修改重构比较麻烦，所以表结构和表关联的重构次数越少越好，一次搞定是最好的。具体的设计根据自己需要的功能来设计就行。
- 表与表之间的关联
- 例如我刚搭建的平台构思，项目和接口是一对多、项目和debugtalk是一对一、项目和用例套件是一对多、接口和用例是一对多。接口和配置是一对多等等。
- 表的字段(模块的model)
- 最容易出问题的地方，尽可能的考虑周全，最好在设计完之后画一个设计图或者列一个Excel表格，然后开一个小会讨论一下，众人拾柴火焰高。
- 设计时不仅要根据需求考虑需要的字段，还要考虑字段的归属表、字段的列属性、字段的数据类型、字段在功能中的属性(可读可写/只读/只写)等，drf中自带的数据效验是根据此时的设计进行的，所以考虑的越周全越好。
- 还要根据各个模块需要实现的功能来综合考量。
- 数据效验(模块的序列化器)
- 最重要的地方，可以理解成数据的防火墙，效验规则设计得好可以避免垃圾数据的产生，使整体的数据参数规范化，减少代码冗余，对于整体平台的运行效率会有一个质的提升。
- 最基础的数据类型效验drf代劳了，只用考虑剩下的关联关系效验、数据格式效验、功能运行中可能存在的异常情况等。
基本上平台的基础结构这一个框架够用了，本来这一篇也只是做一个思路上的记录和回顾，剩下的等到下一篇在进行深入。代码层面不会过于深入，毕竟技术更新日新月异，但是整体的思路不会变的很快，无非就是细节方面的变化。
等待后续更新完毕后，可能会进行前面博客写的playwright的使用总结或者升级插件的问题总结，到时候再说吧
