关于 Web 自动化测试，投入产出比是一个绕不开的话题，对于走到 2017 年的测试人，这时候可能已经有很多人会想到著名的自动化测试金字塔。它形象地展示了 Mike Cohn 对自动化分层中各层所应该投入比重的看法，可以作为我们 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 |
关于在线代码编辑，主要提供给有基础代码能力的同学应用在复杂场景的自动化实施，普通的接口自动化需求不需要。后续文章会做更多的说明。
基础信息管理
用例管理
在线场景编辑
定时计划管理
用例调试
在线报告
邮件样例
平台目前有两个较大的功能欠缺：
账户体系和权限控制目前没有实现，主要是时间成本的问题，考虑目前平台都是公司内部各测试组使用，暂时没有特别强的需求。至于动态编译运行的安全问题，主要是难度和时间成本两方面的原因，对于这个安全问题，目前我自己还没有一个周全的解决方案，另一方面，作为内网运行的平台，安全需求相对较低，欢迎提出宝贵意见。
