Web自动化测试平台的设计与落地
前言
我最初开始接触Web自动化测试的时候,没有直接的领路人,测试行业知识也远不及如今这么丰富和易获取,当时我对于自动化测试的分层几乎没有什么了解,更不知道什么金字塔,就如很多同行一样,我一开始先入的是UI自动化的坑,那时候我还没有养成搜索英文资料的习惯,关于Selenuim2、WebDriver的中文信息还相当有限,国内主流还在Selenuim1, 先熟悉API,熟悉元素定位方式,进行一些简单的封装,到后来的PageObject,干劲十足。
不过在UI自动化这个阶段的后期,我已经对自动化测试有了更多的认识,加上工作变动,开始跳接口自动化的坑,通过工作经历、朋友和网络,对现状有了一定的了解,大约2015年的时候,心里隐约有一些想法,我们的测试对象的架构从最简单的三层架构,到分布式架构,再到SOA,到微服务,一路向前,而再看我们测试人对Web系统接口自动化的实现方式,直接使用如 Postman这样成熟工具的先不谈,就自研框架而言,有用Java的,如Junit/TestNG + Ant( + Jenkins + JMeter + xxx),有用Python的,比如基于广为人知的RobotFramework,有用Ruby的,可能基于BDD界耳熟能详的Cucumber,等等,技术栈可能各有不同,本质上,大多是孤立的工程 + 文件形式管理的数据和用例。
可能四五年前,我看到的,大多是这样的方案,到今天,测试从业者的数量大幅度增长,有良好代码能力的并且能将其用到测试工作中的也越来越多,然而我看到的,这些的方案仍然占大多数,除开国内几家顶尖的互联网企业,就我所了解的以及网络上能搜索到的,尝试将方案走到简单Web系统的形式,用数据库存储数据,在线管理自动化实施的,很少。就这些方案本身,我觉得只要能达到自己团队的目的,都是很好的,没有优劣之分,我在意的是,我看到的变化低于预期很多,新的尝试低于预期很多,我觉得很多新的尝试,对于现在的测试人来说,难度并不会比以前的方案高多少,所需要的时间成本,也并不会高出多少,我希望我们测试人在做自动化实施的时候,能够像做业务测试一样,能够不局限于某一个方向。
既然看到的尝试很少,那我就想自己去做一做,慢慢形成一些思路,到2016年,公司原有的自动化方案不能支撑一些新产品的需求,开始投入精力去设计和实现一个Web类型的测试平台,当时感觉就像当年刚开始自主实施UI自动化一样,有一股劲。设计选型、编码、首版服务端上线、第一个团队开始使用、首版UI上线、1.6、2.0、...在功能方面来说,算是做出了勉强接近自己预期的系统(如果不考虑那拙劣UI的话)。 平台明面上是我单独完成的,但实际上,同行大牛对思路的肯定、工作安排上的支持、业务线伙伴的需求,都是不可或缺的。本来今年年就计划写关于这部分的文章,但由于今年工作、生活上都很忙,这半年几乎没有一个周末有自己独立的时间,加上拖延症作祟,所以直到今天才总算开始码了。
虽然并不确定这次计划输出的内容对读者能有多少帮助,但还是计划分几篇来写,当然具体能输出几篇现在我也没底,拖延症是个强敌,所以决定第一篇先做一个总览
这期的引言太长了点,抱歉。希望本文能为有耐心读到这里的人带来些许价值
一、目标和定位
首选需要说明的是,由于近年的工作重心主要在Web服务端,同时根据团队当前的工作情况,定的自动化策略是优先实施接口层而非UI层,所以平台当前的主要功能是围绕HTTP层的自动化测试展开的。
平台的定位是作为公司各业务线服务端的自动化公共平台,目标是通过快速落地自动化测试来支撑公司各产品组提高测试效率。
二、平台特点
最基本的特点,平台是一个前后端分离的Web服务、由数据库管理基本信息和测试用例、在线查看测试报告。详细一点的话,我认为通过对比的方式来呈现可能比较明了。这里以引言中提到的实施方案与本文所述的测试平台进行对比。
对比项 | 业界常见项目 | 本文平台 |
---|---|---|
定位 | 支撑某一产品线的接口自动化需求 | 支撑各产品线的多种自动化需求 |
适用性 | 适用于特定Web系统接口的自动化 | 适用于不同产品、不同设计理念接口的自动化 |
基础架构 | 独立的工程,基于文件管理数据 | 前后端分离的Web服务,基于数据库管理数据 |
落地方式 | 本地搭建运行环境,获取工程并运行以调试新用例 | 在线UI操作,开放接口便于CI集成 |
数据管理 | 通过更新/上传文件的形式管理用例 | 在线创建/更新用例,使用MySQL管理数据 |
运行方式 | 通过编辑Jenkins job/Crontab等实现运行计划管理 | 在线自定义运行时间计划和运行内容 |
结果校验 | 校验粒度较粗,数据库校验可能在代码中 | 基于Json解析的细粒度校验,在线管理数据库校验 |
历史数据 | 历史数据缺乏有效管理 | 在线查看历史运行记录和测试报告 |
?
三、系统架构
整个平台的大体系统架构如下图,其中产品数据库交互主要是数据预置/清理/校验
平台系统架构
四、相关技术栈
应用 | 技术/工具 |
---|---|
Web服务基础框架 | Spring Boot |
Web容器 | Jetty |
持久层框架 | MyBatis |
HTTP调用和校验基础框架 | REST-assured |
用例调度执行 | TestNG |
HTML报告 | Allure |
平台接口信息 | Swagger |
基础UI组件 | Bootstrap |
前后端交互 | AJAX(Jquery) |
在线代码编辑 | Ace |
?
关于在线代码编辑,主要提供给有基础代码能力的同学应用在复杂场景的自动化实施,普通的接口自动化需求不需要。后续文章会做更多的说明。
五、UI概览
基础信息管理
用例管理
?
在线场景编辑
定时计划管理
用例调试
在线报告
?
邮件样例
六、待完善部分
平台目前有两个较大的功能欠缺:
- 账户体系和权限控制
- 代码动态编译运行的安全控制(沙箱)
账户体系和权限控制目前没有实现,主要是时间成本的问题,考虑目前平台都是公司内部各测试组使用,暂时没有特别强的需求。至于动态编译运行的安全问题,主要是难度和时间成本两方面的原因,对于这个安全问题,目前我自己还没有一个周全的解决方案,欢迎提出宝贵意见,另一方面,作为内网运行的平台,安全需求相对较低。
感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取?
?
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!