Web 自动化测试平台设计与落地-概览

巴黎的灯光下

引言



关于Web自动化测试，投入产出比是一个绕不开的话题，对于走到2017年的测试人，这时候可能已经有很多人会想到著名的自动化测试金字塔。它形象地展示了Mike Cohn对自动化分层中各层所应该投入比重的看法，可以作为我们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概览


















六、待完善部分平台目前有两个较大的功能欠缺：

• 账户体系和权限控制
• 代码动态编译运行的安全控制(沙箱)
  

账户体系和权限控制目前没有实现，主要是时间成本的问题，考虑目前平台都是公司内部各测试组使用，暂时没有特别强的需求。至于动态编译运行的安全问题，主要是难度和时间成本两方面的原因，对于这个安全问题，目前我自己还没有一个周全的解决方案，另一方面，作为内网运行的平台，安全需求相对较低，欢迎提出宝贵意见。

草帽路飞UU

以前也写过一个这种类似的平台，不过后面没有用起来！ 当时 过于侧重测试用例的管理，而不关注 用例编写的灵活性，导致用例编写和维护困难！

乐哈哈yoyo

赞一个,是否有开源计划?

巴黎的灯光下

草帽路飞UU 发表于 2017-6-27 10:00
以前也写过一个这种类似的平台，不过后面没有用起来！ 当时 过于侧重测试用例的管理，而不关注 用例编写的 ...

嗯，难的从来不是coding。
我也经历过自己做的东西远没有达到自己预期的情况。我觉得要做这类平台，首先自己要对业务测试本身有相当的了解，然后，公司产品比较多的，需要进行一些归类和分析，每个类型的系统至少熟悉一个产品的业务特性和系统设计风格，这对做出一个能顺利落地的平台是很重要的，因为这些将影响首版的设计，如果首版不能成功落地，不管是对使用者还是对自己，都有很消极的影响。
我自己来说，对公司多数产品业务都有一定了解，系统的接口设计风格也都比较清楚，请求、返回、身份验证这些细节等等，最初设计的时候就会考虑如何适用于各种不同设计风格，需要考虑在表现层进行一些针对性的设计来增强易用性，最终做出来的平台目前算是顺利落地了，有的用来做对外接口的自动化，有的用来做业务冒烟，也有纯后端平台的同学用来做业务测试。中间也有一些不满足需求的地方，这种时候我会尽量快速响应，并收集一些他们的想法。

巴黎的灯光下

平台后端代码本身倒是基于github管理的，平台的多数功能，也具备通用性，但一来对于身份认证部分，各公司肯定会有所不同，而来这是一个系统，而不是一个基础框架，之前设计的时候没有考虑开源方面的事情，所以算是没有开源计划。有时间的话后面会拿一些关键逻辑放到后续文章。