引言
自动化金字塔-灵魂手绘版
关于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服务、由数据库管理基本信息和测试用例、在线查看测试报告。详细一点的话，我认为通过对比的方式来呈现可能比较明了。这里以引言中提到的实施方案与本文所述的测试平台进行对比。
三、系统架构
整个平台的大体系统架构如下图，其中产品数据库交互主要是数据预置/清理/校验。
平台系统架构
四、相关技术栈
五、UI概览
基础信息管理
用例管理
定时计划管理
用例调试
在线报告
邮件样例平台目前有两个较大的功能欠缺：
账户体系和权限控制
代码动态编译运行的安全控制(沙箱)
账户体系和权限控制目前没有实现，主要是时间成本的问题，考虑目前平台都是公司内部各测试组使用，暂时没有特别强的需求。至于动态编译运行的安全问题，主要是难度和时间成本两方面的原因，对于这个安全问题，目前我自己还没有一个周全的解决方案，欢迎提出宝贵意见，另一方面，作为内网运行的平台，安全需求相对较低。
