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

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

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

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

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

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

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

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

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

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

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

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

以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. 在代码库中添加测试自动化用例

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

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

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

示例: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上创建一个。

  1. 编辑流水线,添加一个空白任务

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

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

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

3.配置执行命令和红线

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 查看结果和统计报表

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

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

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

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

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

  1. 触发测试执行
  2. 获取测试结果

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

  1. POST /api/v1/runs

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

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

  1. 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中主要完成:

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

如:

# 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到对应的企业中)。在步骤中配置好测试平台地址和测试用例,并设置好红线信息。

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

3. 查看测试报告

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

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

4. 数据统计与报表

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

总结

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

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

原文链接

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

上一篇:圆桌问题


下一篇:jS事件:target与currentTarget区别