背景
想必每一位测试工程师都很熟悉 AWS 和 GCP 的环境，这是日常测试工作中都会用到的环境。但和公司内部大部分的测试工程师不同的是，我所在的部门对在 Cloud 环境上的测试不会专注于某个 MicroStrategy Product 功能的测试，而是更侧重于平台层面的测试。
在之前的日常测试过程中，我们一般需要：
创建cluster，等待它创建完成
在cluster上创建env，等待它创建完成
升级env，等待它升级完成
连接上cluster，执行多个需求的测试脚本，等待各个脚本执行完成
删除env，等待它被彻底删除
删除cluster，等待它被彻底删除
聪明的小伙伴们一定发现了，我们会花很多时间在等待上。并且在多个 Cloud 环境上下文切换的同时，要保证正确性的话，会消耗我们很多的精力，这对于测试工程师来说，有一定的挑战性，尤其在 Release Validation/GA Validation 阶段，还要分别满足2天/1天的时间限制。为了解决这这些问题， Cloud 部门开发了这套测试框架。
下面，我将通过 Q&A 的形式来介绍这个框架。这样大家可以更有针对性地，查阅自己感兴趣的部分。
Q&A
1
框架的主要流程有哪些？
这套测试框架主要的流程如下：
准备环境，然后执行所有的测试用例
删除环境
每个流程可以通过命令行分别执行，触发后不需要任何人为的操作，解放了测试人员的生产力。
2
框架目前支持的Cloud平台有？
Cloud平台 | 内容 |
GCP MCP | 支持 |
GCP MCE | 支持 |
Shippable | 支持 |
MCG | 不支持，详情如下：
|
3
该框架是否是基于什么开源框架开发的？
是基于 pytest 进行开发的。
另外在决策阶段，我们决定不采用 Cloud 平台原生的服务进行测试，因为：
这些服务有较多的限制，使得编码逻辑变得更复杂；
每一个 Cloud 平台使用的原生服务不同，需要一定的学习成本；
这样只需要根据当前的需求，学习部分对应的 API 和 CLI 命令即可；
4
测试结果以哪些方式呈现？
测试结束会自动生成测试报告，并发送测试报告到服务器，做到测试结果可追溯；
自动发送测试结果到 Teams channel；
5
框架可以重复利用已有的环境吗？
可以，具体信息如下：
在创建资源（例如cluster/environment）的时候，会给资源设置一个名字；
在创建资源前，会用这个名字去查找资源；
如果查到对应的资源，则使用该资源；
如果没有查到对应的资源，则新建该资源；
通过重用资源，来达到节约资源使用经费的目的。
