前言
自动化测试是谈到软件测试时绕不过去的门槛，价值驱动的自动化测试到底应该遵循哪些原则，让我们来一起探索。
自动化测试仿佛是每个测试人员心中的那一片圣土，能够开发自动化测试脚本的工程师不再是测试工程师，他们被尊称为测试开发工程师，他们谈论着IoC、AOP，他们仿佛行走在水面上，受到所有功能测试工程师的敬仰。另一个获此殊荣的群体是性能测试工程师，没错，他们也使用自动化测试工具。
我接触过的很多测试工程师，都认为自动化测试是自己技术上一个很好的突破口。基本上，每个有追求的测试工程师的电脑上，都会搭起一套Selenium或者Loadrunner。测试总监们则希望自动化测试能够帮助他们腾飞，至少要与外面那些妖艳贱货不一样。
我印象中，在2010年左右，自动化功能测试呈现了井喷的状态。我被要求去研究QTP，甚至还要做两套解决方案，一套使用HP的QC+QTP+LR，另一套则要包含Bugzilla+Selenium+JMeter。前一个可以在当时北京三环买套房，后一个除了工时以外完全免费。
在当时，如果你可以搭建起一套自动化测试框架，你的薪水可以比当时的项目经理还要高。哪怕你只是做过自动化测试，能够编写测试脚本，你的薪水已经可以是功能测试工程师的至少两倍以上。那是个全民狂热的年代，新的技术异常火爆，IOS、Android工程师的薪水轻松突破30万，高过所有的基层管理人员。
在疯狂的探索之后，2015年，这股热度开始有了消退的迹象。2018年，在我的上家公司搞出来的第四个自动化测试平台后，我终于见到了一个务实的测试经理，能够把自动化测试恰如其分的在团队中应用起来。
那些收获与教训
自动化测试工具的原理
2005年我第一次接触Loadrunner，这个工具挺好用，既可以做性能测试，也可以做功能测试。后来我在面试性能测试工程师的时候很喜欢让他们给我讲一讲Loadrunner的原理（如果他们常用的话）。以至于2010年我接触QTP的时候发现，这个东西和Loadrunner看起来有点儿像，虽然他们的实现并不同。
Loadrunner的原理其实很简单，无非就是个发包抓包工具。围绕着这个核心，Loadrunner包装出了一套管理逻辑和图形界面。
QTP的原理也是一样的，Selenium也是，JMeter也是，所有的自动化工具都是模拟用户输入，然后验证输出，这就是软件测试的通用方法。所以，你懂测试，你就一定懂自动化；如果你不懂自动化，说明你不够懂测试。
所以在2010年，我调研了市场上所有流行的自动化测试工具后，2011年我自己搭了一个。说起来还挺惭愧，因为这个自动化工具的使用者只有我自己而已。但是这个过程很有趣，它让我明白一个自动化测试平台到底包含什么内容，这个平台的各个部分都是干嘛的。因此在后来我在设计其他的自动化测试平台的时候，我知道当我可能遇到什么问题的时候我需要设计个什么东西来解决。
所以你大可以忘记各种各样的自动化测试工具，他们归根结底只是各种工具而已，是螺丝刀、扳手和锤子。的确我们遇到过拧螺丝特别快的人，但是现在我们都用电钻拧了，又快又好。这是我在2011年学到的一个经验，关注原理，把自动化测试框架抽象到你的脑子里。
自动化测试工具包括：
- 自动化测试脚本编写
- 自动化测试脚本执行
- 生成报告
其中，自动化测试脚本编写包括：
- 用例间关系维护
- 数据准备
- 驱动准备
- 检查点和预期结果
自动化测试脚本执行包括：
- 用例执行计划管理
- 脚本执行
- 收集执行结果
生成报告不说了，这一块怎么玩儿的都有。你看现在的自动化测试框架里，基本上都可以归类到这几个部分里去。JUnit、TestNG是脚本执行的内容，Spring的IoC、DBUnit、Mock都是数据准备的内容。
测试人员需要动脑子的，就是设计用例、准备初始化数据、设置检查点和预期结果。驱动让开发准备即可，其他的都是自动的。有了这些观念，我们来看看我第一次试水。
第一次试水
所以2012年很自然的，我被派到一个测试团队，帮助他们实现自动化测试。说实话我对我遇到的困难有过预期，但是我没想到困难有那~么~大！他们是一群做ETL的人，面对的是各种乱七八糟的数据源。
数据库用过吧？MySQL是不是挺好用的？那你用过SQLServer吗？也用过？Access呢？也还好吧？VFP这种东西到底是啥？还有用二进制文件存储的？这种二十年前的数据存储方式真的需要我们支持吗？！！
我在这个公司半年的时间我都不知道他们到底在搞个什么鬼。半年以后我终于学明白了，原来他们是搞ETL的啊！那时候，ETL、数据仓库、SaaS服务，在国内都算比较新的概念，但是在美国这就是很基础的东西，随便一群Geek就弄出来了，还卖给了Intuit。