一、前言

把一个以前自己搭建的自动化测试平台进行了一下重构升级，记录一下过程中的一些问题和总结。

二、简介

搭建的平台语言使用的是Python3.6，未来有空可能考虑加个java版本。前端用的Vue，主体是httprunner2.X+Djangorest-framework，平台作用是公司内部使用，mysql数据库就够用。

三、整体结构

考虑的结构是

后台：

1. drfproject目录，工程创建时的系统的配置数据存放目录，命名根据项目创建时的需求
2. app目录，存放平台下的子应用，目前用户这块的应用直接用自带的应该就够了
   1. 项目模块代码存放目录
   2. 接口模块代码存放目录
   3. 报告模块代码存放目录
   4. 测试用例模块代码存放目录
   5. 用例套件模块代码存放目录
   6. 用户模块代码存放目录(使用系统自带模块)
   7. 环境变量模块代码存放目录
   8. 系统配置模块代码存放目录
   9. 数据统计模块代码存放目录
   10. debugtalk模块代码存放目录
3. util目录，存放一些数据处理的自定义模块，基本上应该存在suits目录，存放将要运行的目录文件，目前的考虑是用时间戳作为存放文件的最外层，避免多次运行的覆盖问题
   1. 最基础的对应数据库数据的读写参数的处理
   2. 网页列表参数的基本的分页过滤数据处理
   3. 因为httprunner所需要的用例格式是‘.yaml’，所以需要对用例文件的创建和文件内容的组装处理
   4. 报告的数据处理，将运行后的参数进行过滤后填充进报告里
   5. 定期清理模块，可加可不加，这方面人工更精准，清理的时间间隔这一块根据平台需求来定(如果数据需要保存的时间周期长或者需要根据需求删选，可以直接人工清理)
   6. 看平台需求的其他功能模块
4. log目录，存放运行中需要记录的日志信息
5. report目录，存放运行完毕后或者数据库导出的报告(嫌麻烦可以使用自带的格式模板，有其他需求可以寻找开源的报告模板)
6. venv目录，虚拟环境数据

前端(Vue)：

首页(数据统计)+8个模块组

数据库(Mysql)

把一个自动化平台的基础结构设计清楚后，下一步就是表与表之间的关联关系、表的字段及对应的数据效验方法设计了。

首先排除无关联关系或者关联关系可有可无的数据表，比如用户表、报告表、环境变量等，把这些表排除之后就可以开始画图考虑关联了(也就是外键关联)。因为平台会使用Django自带的数据库迁移功能，中途的修改重构比较麻烦，所以表结构和表关联的重构次数越少越好，一次搞定是最好的。具体的设计根据自己需要的功能来设计就行。

1. 表与表之间的关联
   1. 例如我刚搭建的平台构思，项目和接口是一对多、项目和debugtalk是一对一、项目和用例套件是一对多、接口和用例是一对多。接口和配置是一对多等等。
2. 表的字段(模块的model)
   1. 最容易出问题的地方，尽可能的考虑周全，最好在设计完之后画一个设计图或者列一个Excel表格，然后开一个小会讨论一下，众人拾柴火焰高。
   2. 设计时不仅要根据需求考虑需要的字段，还要考虑字段的归属表、字段的列属性、字段的数据类型、字段在功能中的属性(可读可写/只读/只写)等，drf中自带的数据效验是根据此时的设计进行的，所以考虑的越周全越好。
   3. 还要根据各个模块需要实现的功能来综合考量。
3. 数据效验(模块的序列化器)
   1. 最重要的地方，可以理解成数据的防火墙，效验规则设计得好可以避免垃圾数据的产生，使整体的数据参数规范化，减少代码冗余，对于整体平台的运行效率会有一个质的提升。
   2. 最基础的数据类型效验drf代劳了，只用考虑剩下的关联关系效验、数据格式效验、功能运行中可能存在的异常情况等。

基本上平台的基础结构这一个框架够用了，本来这一篇也只是做一个思路上的记录和回顾，剩下的等到下一篇在进行深入。代码层面不会过于深入，毕竟技术更新日新月异，但是整体的思路不会变的很快，无非就是细节方面的变化。

等待后续更新完毕后，可能会进行前面博客写的playwright的使用总结或者升级插件的问题总结，到时候再说吧

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

 

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取