思路
分离业务代码和测试数据，提高代码可维护性，实现自动化，减少重复劳动。
一个测试框架大概由配置文件，测试数据，测试用例，相关文件（发送邮件等），测试日志，断言和测试报告等模块组成。
结构
以页面为基本单位进行构建自动化脚本。如下图
.idea: 存放项目的配置信息。这个文件夹是自动生成，版本控制信息等，包括历史记录。pycharm创建工程成功后会自动创建
venv: Python环境,一套"独立"的运行环境,pycharm创建时可以选则创建
config: 配置文件
baseConfig.ini: 基本的配置文件，比如url
schoolSystem.ini: 学校系统配置文件（这儿只是个举例）
studentSystem.ini: 学生系统配置文件（这儿只是个举例）
data: 测试数据
存放上传数据，还可以细分，例如image、video、txt等
download: 存放下载的数据
存放下载的数据，还可以细分，例如image、video、txt等
errorImage: 存放用例执行失败时页面截图文件
drivers: 驱动文件，如chromedriver.exe、edgedriver.exe等
log: 日志文件，执行过程中的日志，.log文件
report: 测试报告，html文件
test: 测试文件
common: 公用方法，项目相关的方法
pages: 以页面为单位，每个页面封装一套测试方法
case: 测试用例
runner: 对测试case进行组织，比如执行那些用例，跳过那些用例
utils: 存放一些其他的方法
HTMLTestRunner.py: 生成测试报告文件
log.py: 生成日志文件，主要设置日志的输出级别、格式、文件名等
mail.py: 用例执行完成，将测试报告以邮件的形式发送给相关人员
readConfig.py: 对配置文件 ini 的读取
findElement.py: 对webdriver的二次封装
...
主要存放和测试相关，但是与项目无关的一些文件
run.py: 执行，主要是对test/runner下组织的用例进行执行并且生成测试报告
使用提示
1、在使用要根据项目和业务进行，有依有据的进行构造。例如：根据手动功能测试的测试用例进行。或者以业务逻辑进行。总之选则最合适的
2、前段时间在听一个分享会时，有一点特别深刻，拿来套用一下：以需求为基准。即前期方向一定要做对，比如打算用三个月完成从计划到自动化的竣工。那么申清需求以及构思框架等花2个月时间也是值得的。方向一定要要走对，如果开始就是错误的那么后期质量再高也是徒劳的。
3、多人进行时一定做多勤沟通、有效沟通。避免各自为阵。这样做出来的结构才清晰，项目紧密度高。高内聚、低耦合。