支付宝分层与端到端回归平台建设实践

一、方案特色

  1. 一体化:统一技术体系、统一管控模式、统一调度模式、统一用户体验,有效地提升了平台本身的可维护性,极大地提升了平台的用户体验,降低了使用成本;
  2. 分层回归:支持分层自动化(单元测试、接口测试、WebUI自动化、前端测试)和端到端(全链路WebUI自动化)持续回归;
  3. 集成性:提供丰富的API,便于与其他平台(如研发协作平台等)的集成;
  4. 原子性:方案的运作具备独立的使用周期,不依赖于其他平台或系统;
  5. 扩展性:自主研发,可快速进行方案扩展,如代码质量度量体系、覆盖率、持续集成等;
  6. 业务解耦:自动化管控模块AQC-Auto与手动用例管控模块AQC-Case解耦,自动化用例和手动用例将进行有机结合,为用例管控带来了新的模式;
  7. 平台规划:为开发自测、开发对产品质量负责、持续集成奠定基石;
  8. 质量2.0:沿袭小微产品质量团队质量2.0,着力探索和落地技术助力效率提升理念。

二、方案解读

整个平台主要涵盖四大功能模块,Web管控、调度中心、心跳中心、资源管控,具体请参见图1。方案架构图请参见图2,在后面将逐一进行解读。

支付宝分层与端到端回归平台建设实践_第1张图片

图1

支付宝分层与端到端回归平台建设实践_第2张图片

图2

1. 工程管理

1) 测试工程:众所周知,支付宝自动化测试用例(单元测试、接口测试、Web UI自动化测试)都是在标准的Java工程中;

2) 自动化用例:对于Java工程,测试class中的method,我们定义为平台的自动化用例;

3) 用例同步:通过parse器对SVN的Java工程解析,确保实时的同步或增量同步到我们的自动化用例库中,见图3。

支付宝分层与端到端回归平台建设实践_第3张图片

图3

2. 实验室管理

1) 测试实验室:用户可以基于测试工程,选择待测用例集,新建测试实验室,并配置相关的运行时候所必备的参数;

2) 调度模式:实验室支持3种运行方式(OnEvent:提供API供其他平台调用执行,有效提升平台的集成性;OnManual:通过人工触发,便于随时执行;OnTime:无人值守定时触发模式。),调度设置见图4。

支付宝分层与端到端回归平台建设实践_第4张图片

图4

3) 执行粒度:为了提升用例执行的便捷性,本平台还支持通过Web页面,人工手动运行单个用例或多个用例的方式;

4) 通知机制:支持邮件、邮件组、旺旺等通知机制;

5) 调度记录:可以查看不同实验室的不同运行记录以及运行明细,图5与图6。

支付宝分层与端到端回归平台建设实践_第5张图片

图5

支付宝分层与端到端回归平台建设实践_第6张图片

图6

3. 回归管理

1) 回归实验室:一个回归实验室,对应多个测试实验室,见图7;

支付宝分层与端到端回归平台建设实践_第7张图片

图7

2) 调度模式:可以批量执行多个同类型实验室,以适应sit回归、端到端回归、资损用例回归等业务需求,见图8。

支付宝分层与端到端回归平台建设实践_第8张图片

图8

4. 报告管理

1) 报告粒度:提供测试实验室和回归实验室的执行报告,用户可以快速的定位到特定实验室在特定的轮次中的特定用例的运行情况,见图9。

支付宝分层与端到端回归平台建设实践_第9张图片

图9

2) 透明化:透明化了用例的整个执行过程,可以动态查看到测试工程编译失败日志等,见图10。

支付宝分层与端到端回归平台建设实践_第10张图片

图10

3) 趋势分析:透明化各个测试实验室运行趋势信息,为用例维护推动提供便捷,见图11。

支付宝分层与端到端回归平台建设实践_第11张图片

5. 调度中心

1) 服务注册:不同类型的实验室调度模式是不一样的,需要将不同的调度模式的接口注册到调度中心,实现业务的解耦和调度中心的通用性;

2) 任务管控:不同的测试运行,都会形成任务队列中的一个任务,任务的执行与触发,是通过执行调度中心的任务模块去完成的。

6. 心跳中心

1) 适配中心:本平台是一体化平台,但是针对不同测试类型的实验室,需要不同的runner去适配;

2) 环境治理:不同类型的用例对环境的要求不一样,可以通过一些通用脚本的执行,完成环境的初始化和清理工作;

3) 回调管理:主要是将运行的结果、日志、运行情况写入平台。

7. 设备管控

1) 设备管理:平台提供分门别类的设备管理和开放的OpenApi,承载着回归体系所需要的硬件资源,进行统筹和调配;

2) 透明化:为了透明化测试资源的使用情况,这里会提供相应的报警机制,让用户可以实时查看到机器设备的使用状况,便于即可对硬件资源做相应的处理;提供OpenApi,因为本平台不单单承载在PC自动化回归体系所需要的设备,目前工具研发团队所研发的安全产品测试平台的硬件资源也来源于此;

3) 资源池:提出资源池的概念,源于特定测试回归实验室对硬件资源的配置性要求的不同,确保回归实验室的原子性和隔离性,在平台资源管控中,我们也设定了相应的公共资源池,有效提升资源利用率;

4) 快捷操作:提供一些便捷的操作,如重启tomcat、安装jdk、安装maven等;

5) 统一资源池:本设备管理模块即将成为小微回归体系平台的资源池,为业务的扩展做好充分的准备,见图12。

支付宝分层与端到端回归平台建设实践_第12张图片

图12

三、案例启示

笔者认为,工具平台不是目的,只是助力效率提升的手段,不论是工具平台建设的本身,还是工具平台的服务化能力,高质高量研发出高效的效率工具,助力业务成长,提升研发效率,才是根本,在自动化回归体系建设中,工具平台构建起三套回归体系(无线、全站、CRO),走出去,引进来,打造互联网金融测试之回归体系标杆,和业界同仁一起共促自动化回归体系建设。

附录一:笔者主导研发的支付宝自动化回归体系盘点:

  1. 无线-自动化回归体系:针对快捷支付、钱包、商户APP特点,无缝支持自主研发框架(TRobot)和开源框架(如Robotium);支持性能监测、安装卸载启动测试的无缝接入;
  2. 全站-PC端分层与端到端回归体系:无缝支持从分层(单元测试、接口测试、WebUI自动化、前端测试)回归和端到端(全链路WebUI自动化)回归;
  3. 安全部-安全产品回归体系:支持无线客户端产品的回归,支持Python、Ruby等语言用例。

附录二:笔者自动化建设和工具平台建设感悟:

  1. 自动化不是万能的,但自动化必将越来越受重视,将作为手动测试的必要补充;
  2. 自动化回归体系也许将成为开发自测、开发对产品质量负责的必备武器;
  3. 提升自动化回归体系服务化能力,将成为自动化建设的核心之一;
  4. 自动化价值最大化,才能提升全员对自动化的信心;
  5. 工具平台建设,不同于传统的研发,我们每个同学都需要具备PD+DEV+TESTER能力;
  6. 作为工具研发团队,我们不仅仅要输出我们的工具平台,还要提升工具服务化能力;
  7. 作为工具研发团队,我们更要输出我们的技术,提升技术服务化能力,促进构建线下工具平台建设生态体系,让工具去驱动未来,让工具去为研发保驾护航。

作者简介

王超,花名于龙,现任支付宝高级技术专家。2007年计算机软件与理论专业硕士毕业,先后在微软、SAP、淘宝网从事自动化测试用例开发、自动化框架研发、测试平台建设、信息系统研发、测试工具研发团队管理等工作,主导研发淘宝网PC自动化测试框架AutomanX、支付宝质量风险防控平台AQC、支付宝无线测试平台、资损防控T+1核对平台等产品,目前负责支付宝产品质量部工具研发团队,专注于支付宝线下工具平台建设,业务涉及持续集成、自动化回归体系、数据平台、资损防控、技术风险防控、性能评测中心、测试管控等平台或工具建设。作者邮箱:[email protected]

你可能感兴趣的:(支付宝分层与端到端回归平台建设实践)