AWS 和 Azure 想必每个 tester 都非常熟悉了，几乎是每天的测试工作中都要使用到的环境。和大部分 tester 不同，我所在的小组在 cloud 环境上的测试不会专注于某个 MicroStrategy Product 功能的测试，而是更侧重于平台层面的测试。不管是创建环境还是升级环境，整个过程都会耗时若干个小时并且还要在过程中进行一些 test points 的检查。可见在没有 automation 的条件下测试多个 e2e case 时，所需要的时间便会是若干个小时的叠加，给测试带来了极大的负担。
下面我将以 OCU(One Click Upgrade) 为例来和大家详细说明当前我们在 cloud 环境中使用的 automation，是如何将 tester 从繁重的 e2e 测试中解救出来的！
# 什么是OCU(One Click Upgrade)
当你有一个低于当前GA 版本（11.3.12）的AWS/Azure 环境（eg. 11.3.10），就可以通过 OCU对这个环境进行升级。
1. 点击 “Upgrade Available” 对环境进行 pre-check
2. 点击 “Upgrade Now” 对环境进行升级
3. 当 “Upgrade Complete” 出现，代表这个环境已经 OCU 成功
# Automation 中的 Q&A
测试一次 e2e OCU 需要以下步骤：创建环境 → 等待环境创建成功 → 在环境里创建 test object → 点击 “Upgrade Available” → 等待 pre-check 完成 → 点击 “Upgrade Now” → 等待升级完成 → 验证环境中的 test object 是否升级成功 → 删除环境。
Q
如何自动化在 provisioning portal 上的多次点击行为？
Provision API. 所有在 provisioning portal 对环境进行操作的行为都可以用 provision api 来进行，包括创建，开启，停止或者终止环境。当然我们也可以通过provision api来对环境进行 pre-check和upgrade。
Q
如何下载脚本到 cloud 环境中并且执行脚本来创建 test objects 以及验证环境是否升级成功？
Run Automation API. 考虑到维护成本以及逻辑的简洁性，我们尽量寻求一个统一的方法可以共同作用于 AWS 和 Azure 环境, 这便意味着我们不能使用专属 AWS 或者 Azure 的 service 来实现，这也是我们初期遇到的较大的难点。最终我们决定采用 MSTR 开发的 API来实现这一目标，即 Run Automation API。只要我们准备一个包含我们所需要的 command 的 yaml 文件并且将它上传到 S3(AWS storage) 以及 Blob(Azure storage), 就可以调用 Run Automation API 将 yaml 文件下载到 AWS/ Azure 环境中并执行 yaml 中包含的 command。
例如我们将在验证环境中的 test object 是否升级成功时通过 Run Automation API 来运行如下 yaml 文件中的 command，其中包含下载代码包，运行 python 脚本，将最终的测试结果上传到 AWS 的 S3 storage 等。
Variables:tmp_dir: '/tmp/validate_env'ConfigParams:stop_on_error: Falseparse_only: FalsePreStopConfig:oscommands:- ['rm -rf {0}', tmp_dir]- ['mkdir {0}', tmp_dir]- ['aws s3 cp s3://<bucket name>/cloud-remote-scripts/cloud-remote-scripts.zip {0}', tmp_dir]- ['unzip -o {0}/cloud-remote-scripts.zip -d {0}', tmp_dir]- ['python3 {0}/validate_env/validate_ocu.py', tmp_dir]- ['zip -jrm -q {0}/{1}.zip /home/mstr/validate_env.log', tmp_dir, EnvId]- ['zip -jrm -q {0}/{1}.zip /home/mstr/validate_results.json', tmp_dir, EnvId]- ['aws s3 cp {0}/{1}.zip s3://{2}/cld-test-automation/{1}.zip --acl bucket-owner-full-control', tmp_dir, EnvId, S3Bucket]
Q
现在我们可以自动化 OCU e2e 测试中的每个步骤，但我们要怎么将每个步骤都串联起来呢？以及当上一步结束了，如何让它自动进入下一步呢？
一开始我们计划采用 AWS 的两个服务 —— Step Function + Lambda。Lambda 负责调用各个 api，step function 负责将每一步串联，但考虑到 Step Function 和 Lambda 是 AWS 的收费 service，从 cost 角度我们舍弃了这个方案。后来就有了当前 MSTRBak 以及 OCU 都在使用的 automation framework。
当前的 automation framework 总体采用 Docker+Ruby+Cucumber 的方式，使 OCU e2e automation 成功实现了以下目的：
串联起了整个OCU e2e 测试的过程，确保上一步成功完成才会进入下一步
可以实现多个e2e OCU 同时进行的测试，大大缩短了测试时长
使用 feature文件来管理test case，简洁并且易于管理
以下是 light_regression.feature 文件中一个简单的 OCU e2e scenario 示例：
通过 cucumber framework 使 test case 更加简洁易懂
可以在一个 e2e scenario 加入多个步骤，例如创建环境，触发 pre-check，触发 upgrade 等等
当某一条件满足时才进入下一步。以下图为例，只有pre-check PASS 时才会进入 upgrade 流程
Scenario Outline: OCU E2EGiven a client wants to use <provision> service of provisionApiAnd initialize state management# Create Env<code># Trigger pre-check<code>Then the JSON in response should compatibly match the baseline_upgrade_env_check.json in folder baseline# Trigger upgrade<code># Wait for OCU<code># Check final Upgrade completed status occur<code># Terminate env<code>
Q
如何 trigger automation？
Trigger automation 只需要一个 docker 环境并运行以下命令：
ruby tests/executor/run_test.rb --tag @aws_mce_ocu以下是 tag @aws_mce_ocu
在light_regression.feature 文件中的示例：
当运行 tag @aws_mce_ocu 时，会同时运行3条 e2e OCU case, 从而达到多个e2e OCU 并行的测试
@aws_mce_ocuExamples:<e2e case 1><e2e case 2><e2e case 3>
虽然上文仅从 OCU 出发介绍了 cloud 环境中的 automation framework，但不仅仅是 OCU，任何需要对 AWS/Azure 环境进行操作的测试都可以通过这套框架来实现自动化，希望文中所述可以给大家对 AWS/Azure 环境进行开发或测试工作时提供更多灵感。
