API自动化架构及分层

构建一个结合了Python、Robot Framework的自动化测试项目,并计划部署在Google Cloud的Kubernetes(GKE)集群上,通过Bitbucket的pipelines定时调度,同时通过Jenkins进行发送邮件、Microsoft Teams通知的场景下,一个详尽的项目结构和关键组成部分如下: 

my-robot-test-automation/
│
├── testCase/                 # 测试用例
│
├── testData/                 # 测试数据
│   ├── testdata1.csv
│   ├── testdata2.ini
│   ├── testdata3.yml
│   ├── testdata5.py
│   └── ...
│
├── config/                   # 配置文件
│   ├── env_configs1.py 
│   ├── env_configs2.robot
│   ├── env_configs3.json       
│   └── ...
│
├── keywords/                 # 关键字库
│   ├── common_keywords.robot
│   └── ...
│
├── libraries/                # 自定义库
│   ├── selenium_extensions.py
│   └── ...
│
├── Dockerfile                # Docker镜像构建文件
│
├── k8s/   
│   ├── job_template.yaml                   # Kubernetes配置文件
│   ├── deployment.yaml
│   ├── service.yaml
│   └── ingress.yaml
│
├── requirements.txt          # Python依赖
│
├── Jenkinsfile               # Jenkins Pipeline配置文件
│
├── notification_scripts/     # 通知脚本
│   ├── send_email.py
│   ├── send_teams_notification.py
│   └── ...
│
├── scripts/                  # 启动和管理脚本
│   ├── pre_launch_checks.sh  # 预启动检查脚本
│   ├── run_script_dev.sh  # 启动Robot Framework测试脚本
│   └── cleanup.sh            # 清理脚本(可选)
│
├── README.md                 # 项目文档
└── ...

### 关键组件说明

1. **testCase**: 包含所有Robot Framework测试脚本,根据测试类型(如冒烟测试、回归测试)组织目录结构。

2. **testData**: 存放测试用例所需的各类数据文件,便于数据驱动测试。

3. **config**: 配置文件夹,用于存放环境配置、数据库连接等配置信息。

4. **keywords**: 自定义关键字库,封装重复使用的测试操作,提高测试脚本的抽象层次。

5. **libraries**: 自定义库文件,扩展Robot Framework的功能,例如集成特定的自动化工具或框架。包括变量文件,可作为variables导入robot

6. **Dockerfile**: 定义Docker镜像构建过程,包括安装依赖、复制项目文件、设置启动命令等。

7. **k8s**: Kubernetes配置文件,定义了部署、服务和(可选的)Ingress规则,用于在GKE上部署应用和测试环境。可定义一个kind为job类型的,这样执行任务完毕,pod自动销毁。

8. **Jenkinsfile**: Jenkins Pipeline配置,负责自动化构建、测试执行、结果评估及触发通知脚本。

9. **notification_scripts**: 包含发送测试结果通知的脚本,可以是通过SMTP发送邮件的脚本或调用Microsoft Graph API发送Teams消息的脚本。

10. **scripts**: 启动和管理脚本,如预启动检查脚本确保所有依赖服务就绪,启动测试脚本直接调用Robot Framework执行测试,以及可能的清理脚本。启动脚本在Dockerfile文件里面定义成entrypiont,这样容器启动就会自动执行

11. **bitbucket-pipelines.yml**:在bitbucket-pipelines.yml中定义CI/CD流程,包括构建Docker镜像、推送到私有或公共的Docker registry(如Google Container Registry, GCR),以及部署到GKE集群。

### 注意事项

- 确保所有脚本具有执行权限,并在Dockerfile中正确复制和设置执行入口点。

- 启动脚本里面调用里robot的命令行工作或者python命令行工具执行相关的用例或者python文件


- 在Pipeline中正确配置环境变量,如Jenkins/Bitbucket凭证、GCP服务账户密钥等,以确保与外部服务的安全交互。pipeline的Resporiry variables可以放置一些key_file等敏感信息,只有仓库的admin才能有权限查看和操作,pipeline执行时可以传递给pipeline,不对外暴露确定了安全性。

- 镜像构建:用镜像构建脚本构建镜像,主要包括docker build和docker push。镜像构建就是根据Dockerfile文件进行的。构建镜像是基础,构建好之后才会有之后的k8s拉取镜像并启动容器。


- 用例执行过程:pipeline定时任务调度-----kubectl apply job_template.yaml启动gcs里面的k8s执行实际的用例脚本(pipeline的步骤有一步骤是跟gcs的k8s交互的,kubectl apply命令相当于请求Kubernetes 的api,因为带了google对应的上下文,调用kubectl apply会自动指向对应google集群的GKE进行交互,相当于调用api的时候前面的url指向的是对应google的对应GKE服务器,还在api的header传了需要的凭证信息,对应的google的GKE收到api的请求,根据job_template.yaml中的镜像拉取镜像并启动容器(这个过程靠的是CRI与容器containerd交互,containered有docker类似功能,但是又天然支持CRI),启动容器的过程中entrypoint的启动脚本自动执行,从而实现的执行用例)


- 日志查看:日志可以在google Cloud logging或者rancher或者ELK查看。因为是kind是job类型,rancher中只有脚本正在执行才能查看到pod以及相关的日志。

- 报告的保存地址:在启动脚本中把容器生成的报告通过gcs的命令行工具传到了google storage(gcs)

- 与teams的交互是通过teams的webhook实现的(比如incoming webhook),webhook的地址就是一个api,通过在teams配置好webhook的地址,在自动化中直接调用这个api,传递对应格式的json数据就行(Adaptive Cards开源卡片格式)

- 自动化跟k8s项目一样,同样可以接入grafana监控面板。

你可能感兴趣的:(自动化,python)