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监控面板。