云效DevOps实践 - 如何基于云效实现测试自动化集成和分析

对于现代软件研发来说，持续、快速、高质量、低风险地交付需求特性，是业务对研发的主要诉求。而要做到这一点，除了要有良好的架构设计、卓越的工程能力，快速可靠的测试反馈也是其非常重要的一环，达到这一点，需要依靠测试自动化。

作为面向企业开发者的DevOps平台，云效提供了丰富的能力，帮助大家在DevOps流程中落地测试自动化实践。

简单来说，企业自建测试自动化体系，分为三种形式：

形式一：基于开源测试自动化工具

很多企业自建测试自动化，都是从选择一个开源测试自动化工具开始的。一个开源测试自动化工具，往往包含以下几部分（以RobotFramework为例）：

测试执行工具，如robot
测试用例，如.robot文件
测试结果和报告，如执行完生成的log.html和report.html
测试能力库，用来完成特定的测试，如SeleniumLibrary

对于一个测试自动化体系，往往还需要加上：

调度和执行平台
结果分析与统计报表
测试结果通知能力

基于云效，整个的架构是这样的。

测试自动化用例存储在云效代码平台的git仓库中
用于执行测试自动化的测试步骤，基于云效的自定义step能力创建
触发和串联代码、构建和自动化测试的云效流水线
通知机制（钉钉消息）
针对质量情况的数据报表，可以直接显示在流水线测试结果中，也可以将数据发送给自建的数据报表服务展示

以RobotFramework框架为例，在云效上接入开源测试自动化工具有以下几步。

1. 选择或编写对应开源测试自动化工具的flow step

云效没有内置开源测试自动化组件，但是基于其提供flow cli工具，企业可以很容易地定制符合自己要求的测试自动化组件。如何通过flow cli实现并发布一个flow step，可以参考云效学院flow cli相关内容。

这里，仅以RobotFramework为例，对其关键部分做一下说明。

首先通过flow step init命令初始化一个flow step组件的项目。

1.1 执行的环境和命令

在step.yaml文件中，image为测试执行的环境镜像，这里是registry.cn-hangzhou.aliyuncs.com/feiyuw/flow-robotframework:1.0，镜像的内容在Dockerfile里面定义。

在items中添加type为shell的输入框，用于设置执行命令，这里默认值为robot -L Trace -d robot_logs .，当前目录“.”即为代码所在目录。

# ... image: registry.cn-hangzhou.aliyuncs.com/feiyuw/flow-robotframework:1.0 items:   - label: 执行命令     name: STEP_COMMAND     type: shell     value: |       # NOTE: output directory should be robot_logs       robot -L Trace -d robot_logs . # ...

1.2 红线配置

首先在step.yaml中定义红线配置组件，这些组件会在流水线配置步骤的时候显示给用户。

  items:     - label: 红线信息       name: CHECK_REDLINES       type: addable_group       rules:         - require: false       add_button:         type: icon         icon: plus         text: 增加红线         tip:           icon: question-circle           description: 红线校验失败步骤标记为失败       template:         items:           - name: redline             label: 红线             position: flat             type: custom_redline_dropdown             datamap: '[{"key": "PassRate", "type":"GE"}]'             rules:               -requires: false

另外在step.sh的最后添加红线检查部分，如：

redline Passed:成功:$STEP_ROBOT_PASS:Success Failed:失败:$STEP_ROBOT_FAILED:Error PassRate:成功率:$STEP_ROBOT_PASSRATE:Default

flow step编写及调试完毕后，publish到当前企业中。

2. 在代码库中添加测试自动化用例

对于针对整个产品或一个子系统的自动化测试，我们建议自动化测试用例保存在单独的代码仓库中；而对于针对某个特定应用的自动化测试，我们建议其测试用例保存在该应用的代码仓库中，并与开发使用同一个分支（推荐）。

将自动化测试用例与应用代码在同一个代码库中管理，有许多好处：

测试用例与代码互相匹配且是最新的，让自动化测试在开发阶段就可以及时介入
直接复用开发的分支模式，不用考虑自动化用例的版本管理
开发和测试基于git代码库紧密协作，方便落地ATDD这样的优秀实践
容易集成到流水线中，当测试代码或者开发代码变更后都能快速被执行和反馈，加速问题的定位和修复

示例：alpd-bot-ssh的测试自动化用例。

alpd-bot-ssh是一个SSH的服务，提供IP归属地查询和天气查询能力，该测试自动化用例基于RobotFramework框架实现。其测试自动化用例保存在代码库的atest目录下，结构如下：

atest ├── __init__.robot ├── ip.robot                             # 用于ip归属地场景的测试集 ├── resources                                                        # 测试公共资源，包括通用变量定义、公共函数等  │   ├── common_resource.robot │   └── ssh_lib.py └── weather.robot                                                # 用于天气查询场景的测试集

在代码根目录下，通过 robot -L Trace atest 执行测试。

3. 添加测试自动化节点到流水线

打开持续集成流水线，如果没有，在flow上创建一个。

编辑流水线，添加一个空白任务

2.添加自定义步骤，“RobotFramework测试”

3.配置执行命令和红线

4. 上传测试报告到云效，以在云效流水线执行结果中展示

编辑第三步的测试自动化节点，添加一个步骤

2.配置测试报告目录（这里是robot_logs）和测试报告入口文件（这里是report.html）

5. 同步测试结果到自建的报表系统

有些时候，我们需要对测试结果进行进一步的统计分析，此时，仅靠测试自动化工具提供的报告就无法满足了。通常，我们会自建一个报表系统。那么，云效中执行的测试自动化结果如何上传到我们自建的报表系统呢？

5.1 确保报表系统能够被云效访问到

由于网络问题，云效无法访问我们建在私有网络环境中的报表系统，要求报表系统开放公网访问接口。为了安全，我们建议仅开放必要的接口，同时做好IP白名单防护。

5.2 在flow step中添加上传报告步骤

打开步骤1的flow step，编辑step.sh，添加上传报告步骤。

注意：
该步骤需要放在redline检查之前，同时建议传递的信息包括：测试结果、代码分支、代码版本、提交者、流水线名字等。

# ... # sh -ex $WORK_SPACE/user_command.sh bash -c "$STEP_COMMAND"  output=`python3 /root/parse_output.py $OUTPUT_XML`  STEP_ROBOT_PASS=`echo $output | awk -F, '{print $1}'` STEP_ROBOT_FAILED=`echo $output | awk -F, '{print $2}'` STEP_ROBOT_PASSRATE=`echo $output | awk -F, '{print $3}'`  # upload test result to report server python3 /root/upload_to_report_server.py $OUTPUT_XML $CI_COMMIT_REF_NAME $CI_COMMIT_SHA $EMPLOYEE_ID $PIPELINE_NAME $BUILD_NUMBER  redline Passed:成功:$STEP_ROBOT_PASS:Success Failed:失败:$STEP_ROBOT_FAILED:Error PassRate:成功率:$STEP_ROBOT_PASSRATE:Default

最后的流水线大致是下面这个样子：

形式二：测试自动化自建Jenkins

对于已经自建Jenkins等工具用于测试自动化调度执行，甚至在Jenkins上进行了二次开发和定制的团队，或者对于像ioT开发这样有特殊环境要求的应用，复用现有的工具资源更为经济。为此，云效提供了与客户现有Jenkins服务无缝对接的能力，帮助企业通过串联起研发测试。

1. 确保自建Jenkins能够被云效访问到

自建Jenkins服务需要支持公网访问，以便云效能够访问并触发对应的任务。同样，为了安全考虑，建议仅开放必要的接口，并开启IP白名单防护。

2. 添加Jenkins任务节点到流水线中

编辑云效流水线，添加一个任务节点，选择Jenkins任务。

接下来，配置Jenkins地址、认证方式、对应的Job名称，以及触发参数（上游的构建镜像）。

3. 查看结果和统计报表

流水线被执行后，结果信息会同步到Jenkins任务组件上，用户可以在云效流水线运行结果上直接跳转到Jenkins Job日志。

对于统计报表，由于这种方式下，云效不会保存执行任务的任何数据，建议在Jenkins任务中完成数据的上传等工作。

形式三：自建测试自动化平台

如果开源测试自动化工具无法满足测试诉求，又有定制化的调度、触发、管控等要求，部分企业会选择自建测试自动化平台。对于这种情况，如何与云效有机整合起来，做到研发一站式呢？

解决的方法和集成开源测试自动化工具类似，所不同的是，我们的自建测试自动化平台需要对云效暴露两个接口：

触发测试执行
获取测试结果

这里我们假设自建测试自动化平台的地址为：http://taplatform.my.corp，两个接口为：

POST /api/v1/runs

request：{"ref_name": "feature/limit_1", "trigger_by": "yunxiao", "suites": "all"}

response：{"code": 0, "run_id": 123}

GET /api/v1/runs/

response: {"code": 0, "status": "RUNNING|PASS|...", "report_link": "http://taplatform.my.corp/reports/1234", "summary": {"total": 1000, "pass": 1000, "duration": 1200}, ...}

1. 编写flow step用于触发测试自动化平台和设置红线

实现方式与集成开源测试自动化工具的方法类似，主要是配置好step.yaml和step.sh。

step.yaml中配置自建测试平台的地址，以及测试用例的筛选参数，如：

items:   - label: 测试平台地址     name: TEST_PLATFORM_HOST     type: input     value: http://taplatform.my.corp   - label: 用例     name: SUITES     type: input     value: all # 用例筛选条件

step.sh中主要完成：

触发测试平台执行对应测试用例
等待测试完成
获取测试结果
验证红线卡点

如：

# sh -ex $WORK_SPACE/user_command.sh output=`python3 /root/run_and_wait_until_finish.py $TEST_PLATFORM_HOST $SUITES $EMPLOYEE_ID`  STEP_ROBOT_PASS=`echo $output | awk -F, '{print $1}'` STEP_ROBOT_FAILED=`echo $output | awk -F, '{print $2}'` STEP_ROBOT_PASSRATE=`echo $output | awk -F, '{print $3}'`  redline Passed:成功:$STEP_ROBOT_PASS:Success Failed:失败:$STEP_ROBOT_FAILED:Error PassRate:成功率:$STEP_ROBOT_PASSRATE:Default

其中run_and_wait_until_finish.py的实现步骤大致如下：

import os import time import sys import requests   def start_test_task(ta_host, suites, trigger_by):  resp = requests.post(f'{ta_host}/api/v1/runs', json={'trigger_by': trigger_by, 'suites': suites})  if not resp.ok or resp.json()['code'] != 0:  raise RuntimeError(f'create test task error: {resp.content}')  return resp.json()['run_id']   def generate_report(ta_host, report_link):  if not os.path.exists('report'):  os.mkdir('report')  with open('index.html', 'w') as fp:  fp.write(f'''<html> <head> <title>Test Report</title> <meta http-equiv="refresh" content="0;URL={ta_host}/reports/{report_link}" /> </head> <body> <p>forwarding...</p> </body> </html>''')   def wait_until_task_done(ta_host, run_id):  while True:  resp = requests.get(f'{ta_host}/api/v1/runs/{run_id}')  if not resp.ok:  raise RuntimeError(f'task error: {resp.content}')  data = resp.json()  if data.get('code') != 0:  raise RuntimeError(f'task error: {data}')  if data['status'] in ('PASS', 'FAILED'):  generate_report(ta_host, data['report_link'])  return data  time.sleep(5)   if __name__ == '__main__':  if len(sys.argv) != 4:  raise RuntimeError('invalid arguments')  ta_host, suites, employee_id = sys.argv[1:]  run_id = start_test_task(ta_host, suites, employee_id)  run_info = wait_until_task_done(ta_host, run_id)  summary = run_info['summary']  pass_cnt = summary['pass']  total_cnt = summary['total']  pass_rate = pass_cnt * 100 / total_cnt  print('%d,%d,%d' % (pass_cnt, total_cnt-pass_cnt, pass_rate))

其中调用了测试平台的两个接口，并且生成了一个index.html的测试报告文件。注意：该测试报告只是将请求转发到了自建测试平台的对应页面上。

2. 添加测试自动化节点到流水线

在流水线上添加空白任务节点，在其中添加一个步骤，选择前面我们自定义的flow step（记得publish到对应的企业中）。在步骤中配置好测试平台地址和测试用例，并设置好红线信息。

3. 查看测试报告

在测试节点添加报告上传步骤，测试报告目录填“report”，测试报告入口文件为“index.html”。

4. 数据统计与报表

在流水线执行结果中可以看到通过率等summary信息，详细的统计与报表建议在自建测试自动化平台内实现。

总结

针对上面提到的三种自建测试自动化的形态，这里给一个简单的小结，帮助大家更好地进行选择。

当下还没有实践测试自动化且打算开始建设测试自动化能力：建议选择形式一，基于开源测试自动化工具来建设。这样可以把我们的精力集中到具体的测试工作，让测试自动化能够快速落地，同时又能享受到开源社区的大量的技术沉淀，少走弯路。
已经搭建了jenkins，但是没有进行二次开发，仅用来执行自动化测试：建议选择形式一，基于开源测试自动化工具来建设。这样可以节省维护jenkins的成本，同时测试报告和卡点可以更好地与研发过程整合，避免工具割裂和数据孤岛。
基于jenkins搭建了CICD流水线，或基于jenkins进行了二次开发和工具整合：建议选择形式二，测试自动化自建jenkins。这样能更快地进行系统整合，同时，也不会影响后续的迁移和改进动作。
自研测试自动化执行和分析平台：建议选择形式三，自建测试自动化平台。如果不打算推倒重建，我们还是建议采用现有系统与云效整合的方式，避免工具切换对团队的干扰，也可以更好地复用已有资源。

原文链接

本文为阿里云原创内容，未经允许不得转载。