测试平台思考：自动化测试——香格里拉还是黑洞？-转，很深刻！

自动化测试是谈到软件测试时绕不过去的门槛，价值驱动的自动化测试到底应该遵循哪些原则，让我们来一起探索。

自动化测试仿佛是每个测试人员心中的那一片圣土，能够开发自动化测试脚本的工程师不再是测试工程师，他们被尊称为测试开发工程师，他们谈论着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。

时间回到2012年中，我去的时候三个开发工程师已经实施过几个月了，但是据说效果特别不好。我就是那个他们期待带来奇迹的家伙，然而我当时是一脸懵逼。但是我做了一件至今我仍然觉得很英明的决定，那就是我和我的团队坐在一起，测试人员、我、测试平台的开发工程师，三个脑袋对着这个屏幕，大家一起做测试。

那个测试工程师是个话痨，这也是为啥我选了他。他的嘴特别快，手也特别快，我必须经常性的打断他的操作，问他为啥要这么干。平时半个小时做完的工作他干了两个小时；然后我亲自操作，他俩观摩指导，又来了一遍。

接着，我骚扰了这个团队的每个测试工程师，我成功的发现，原来每个人都有自己的独门技巧。每个人的测试习惯、测试用例、操作方式都不一样，这也导致测试的深度完全不同，有些人的质量很高效率特别低，有的人效率高质量差；有的人靠直觉，有的人靠逻辑；有的人按部就班应付事，有的人认真但是很憋屈。

在一个月之后我们有了成果，终于做出了第二个版本。这个东西的设计思路是基准测试：

将一个XML文件里的测试数据传给本次要发布的程序版本
这个程序会调用指定数据源完成数据提取、转换和上传
将程序上传的这个结果文件与基准（上个版本保存好的结果文件）进行比对
使用SQL或者其他方式访问制定数据源，确认这些差异是符合我们的要求的，测试通过
将最新生成的结果保存成新的基准。
这个设计思路很不错，我也是第一次学习了基准测试。这个测试方法的好处是，我不需要一个详细的需求说明文档告诉我针对每一种数据程序应该是个什么反应，我只需要知道转换规则，然后通过与基准比较出来的差异去抽样，就可以获得很不错的测试效果。

但是在新的测试工具推广半个月后，我发现大家都不爱用这个工具。我发现了几个问题：

有些测试工程师会忘记保存基准，导致下一个人去执行的时候发现，基准是错误的。他需要很费力的重新运行。
有时候程序会出bug，而当测试人员发现问题的时候，他们倾向于直接手工执行，而不是上报这个问题。
程序只能与基准比较，而当我们要确认一些问题的时候，这个工具就不能用了。
这种基准测试会遗漏一些缺陷，导致测试人员不敢信任它通过的结果。
当时的开发经理甚至说出这样的话，“自动化测试只能作为辅助使用，归根结底你们还是要用手工再执行一遍，如果都能用工具自动化了，要你们干什么？”

这可能代表了当时团队所有人的心声，我也遇到了我管理测试团队最大的一次信任危机。我们真的只能使用手工的方式执行测试吗？

当然不是。那四个问题是我和我的团队沟通时他们告诉我的，这里边有程序的问题，有人的问题，有流程的问题。现在想来，自己还是低估了困难。当时的测试工作压力很大，看似同样的任务，事实上有很多隐藏的工作，工作量差异巨大。我的方法很笨拙，我观察到团队都不爱干的活，我就拿来自己干。无论加班到几点，我都要弄清楚，到底这个工作麻烦在哪儿？

经过一个月的深入调查，我发现，最主要的原因是当时的测试方法和测试流程都没有经过完善的设计，测试水平太低。靠自动化来推动流程改革是不可能的，只有我才能推动测试流程改革。

我们当时做的事情是ETL的测试。其中，提取和上传没有逻辑，只有转换才是需要重点验证的焦点。我们有Mapping表，指明了数据源中的字段与标准文件中字段的对应关系和转换逻辑。但是，一个转换逻辑应当由相应的测试数据来验证，而当时我们使用的数据库是从客户那里拿来的真实数据，对于很多特殊逻辑是无法覆盖的。

比如，我们有一个逻辑，要求用户的姓和名不能都为空。那么，至少应当存在四种数据，有姓有名、有姓无名、有名无姓和无名无姓。但是我们的数据源里不一定有这种数据，如果逻辑写错了，我们根本发现不了。到了生产环境，遇到了这种数据，程序执行就出错了。

用测试的语言说，这是由于数据多样性不足以覆盖需求导致的测试覆盖率不足。

解决的方法是改变测试用例编写流程。我要求：

每个测试人员针对Mapping文件提取出所有的逻辑作为测试点，列上编号。
针对每个测试点设计测试用例
针对每个测试用例，找到至少一个测试数据（如果没有就修改一条）
这样，我确保每一个需求都被完善的覆盖，经过测试团队修改过的数据库变成标准库，所有的测试都只有在这些标准数据库执行过，才能通过。

同时，我给测试工具开发团队定了目标，必须让每一个测试人员都爱上你的工具。他们蹲守在测试人员身边，陪着他们一点一点跑通，随时给与指导。他们完善这个工具，让他们自动上传、读取基准文件，在虚拟机上接受本地传递的配置文件，将测试报告自动发送给群组邮箱。这个功能实现后，我要求每个测试人员至少同时处理三个任务。

到了2013年中，测试团队的测试效率提升了至少5倍，同时我们的缺陷发现率呈现了井喷式增长，开发团队修改了自己的流程，他们的代码评审开始使用我们的用例、工具和测试数据。

这次的经历带给我什么样的启迪和感悟呢？我认为至少有三条：

测试工具的自动化并非银弹，它需要团队配合、流程配合才能成功；
自动化工具的开发者必须了解测试人员的痛点，将力气用在刀刃上，不能闭门造车；
自动化工具对团队内部和外部来说都是新鲜事物，我们需要花费大量的力气让大家接受它。
第二次杨帆
2014年我在另一家公司开始了新的征程。这家公司主要是线下收单业务，所以有大量的POS机和复杂的后台作业系统。这个公司的业务特点决定了他们的页面内容很简单，但是后台接口很多，复杂的业务逻辑需要通过这些接口实现。因此，我需要一个接口测试平台。

这次我有了一个架构师来帮我实现我的自动化测试平台，Bravo！这次我画了一个PPT来说明这个测试平台的未来，这个平台将分四步走：

驱动与执行。平台需要能够完成基本的接口调用，能够组装请求并记录响应。
数据准备和验证。平台能初始化数据并在接口调用结束后验证数据库中的数据。
图形化界面。平台需要图形化界面支持测试人员在网页上通过拖拽的方式组装用例，通过设置检查点并以所见即所得的方式检验结果。
完善的用例管理。平台可以通过预设的用例生成逻辑来自动生成用例，支持用例间关系维护，并可以在运行期根据用例间关系自动安排执行顺序。
当时我还孤陋寡闻，如果是今天我会加上第五步，将用例生成和结果判断都交给机器学习（纯粹胡扯）。

用例自动生成这个事儿其实是有理论支撑的，下面这段可以不看（可以直接搜索“全对偶测试”）。

作为接口测试来说，待测接口一般是这样的（原谅我没找到下角标）：

function(arg a0,arg a1,arg a2...arg aN-1){
……
}
这个接口包含了 [公式] 一共N个参数。我们假设针对每一个参数都有自己独立的测试数据，例如，针对a0号参数，我们有p0个可能的输入，构成输入集合K0，针对a1，我们有p1个可能输入，构成输入集合K1，等等等等。

[公式]

假设我们有一套标准的N个参数的输入值，比如说，我们让a0等于K0集合中的第一个元素k00，a1等于K1集合中的第一个元素k10，a2=k20，等等等，这就是我们的第一个标准测试用例，或者叫BVT用例。

[公式]

在这个BVT用例的基础上，我们可以通过修改一个参数的值，来生成一个新的测试用例。比如说，，那么我们的第二个用例就是在BVT用例的基础上，让其他参数不变，只是让a0等于K0集合中的第二个元素k01。那么我们就得到了一个新的用例，这个用例与BVT用例的差异就只有这一个参数的取值变化。这样做的好处是，变动被限制在一个参数内，而且我们可以很方便的确认这个变化到底会带来怎样的后果，作为我们的预期结果。

如果我们每次只修改一个参数的值，让其他的参数值都与BVT用例相同，让a0的值遍历K0集合，再让a0=k00，a1的值遍历K1集合，如此循环操作每一个参数，我们就得到了一组测试用例。这组测试用例以每次修改一个参数的方式遍历了所有的可能输入，我给他们起了个名字叫做N+1，N指参数的总数。

那么，我有幸读到过一篇论文，很有趣。这个论文的结论说，对于一个N个参数的接口来说，N+2的用例覆盖率就约等于N+N，也就是正交法设计出来的测试用例。通俗的说，只要每次改变两个参数的值，我们就几乎等于完成了正交法的覆盖率。

你会发现这个方法很适合自动化测试，你只要把这N个参数列出来，然后给他们分别指定输入域就可以了。考虑到大部分的测试数据都是类似的，因此你甚至可以复制一套输入，略微增删即可。然后就把剩下的工作交给机器吧，你可以让它尝试N+1或者N+2，这已经足够好了。

https://en.wikipedia.org/wiki/All-pairs_testing
​en.wikipedia.org/wiki/All-pairs_testing
在写下这一段时我还不知道全对偶（All Pairs）在组合测试中的大名，有兴趣的同学可以阅读上面的wiki介绍，我所谓的N+N，就是N-wise testing，“N度测试”。
让我们回到我的接口自动化测试平台。我给出了一个大而全的设计，这个设计的目的是

让所有的手工测试逐步迁移到自动化测试平台上来，不需要再有手工测试，所有的测试都可以在自动化测试平台上完成；
尽可能的降低测试人员与代码的联系，测试人员面对的只有数据和页面，这样可以让他们更专注于业务和用例设计；
尽可能的把所有的重复性工作全部由平台完成，不仅仅局限于接口响应报文，还要包括数据源校验。
那么按照套路，下一步肯定遇到问题了，那么这些问题是什么呢？

测试人员看不懂接口
测试人员看不懂数据结构
测试人员不会准备初始化数据
测试人员懒得维护频繁变化的脚本
没有开发资源了！
是的，你看这些问题的顺序就可以大概猜出来我当时经历了什么。我空降到这个团队，公司发生剧烈变动，有经验的测试人员相继离职，我紧急喊来了一个测试经理来帮忙，我们两个带着三个应届生就出发了。

这三只小猫甚至不知道接口是啥，我从最基本的OSI七层模型开始讲起，一步一步带他们梳理大学学过的知识，手把手的教他们什么叫接口，数据库表是怎么设计的，好不容易我们的核心系统全部自动化了，结果我的开发资源突然没了！

你猜这个平台停留在了第几步？

这一次我的经验和教训是：

建设自动化测试平台跟创业没什么两样，资金链随时可能断裂！别贪多贪大，完善的设计不如马上就能跑的程序。
测试人员的技术水平不高，不仅仅体现在代码能力上，还体现在对系统设计、数据库设计的理解上。
但是测试人员对业务理解都不错，可以选择在这里突破。

第三次启航
经过了两次惊心动魄的平台建设后，我终于从这个轮回中涅槃出来，这一次，我来给你们讲一个别人成功的故事。

这位同学很有趣，她以前做过开发打下了代码基础，2016年她做性能测试并且参加了多场架构评审，这让她对系统设计和数据结构都有了了解。2017年，她第一次开始尝试将公司的一个自动化测试平台应用到本部门的测试工作中。

第一次的过程是非常漫长且痛苦的，我最经常看到的就是她在加班写代码。她用了很大的力气希望能够把这个平台应用到更多的系统上去，但是平台本身的缺陷导致引入一个新的系统就要花费极大的力气。每个系统都有自己的复杂性，而平台既缺少相关的驱动，又没有管理，还需要测试人员自己写代码。

第一次就这么漫长的失败了，年中组织调整，我们深入的讨论了一下，认为这个平台本身缺少的内容太多了，并且使用的groovy脚本看起来虽然很方便，但是实际上和开发团队的框架结合得并不好。

有了第一次的经验，我建议她是否可以考虑使用界面化的方式，规避测试人员学习代码。她对此的看法是，一方面界面化的工作量非常大，她等不起；另一方面，测试人员事实上非常喜欢学习代码和数据库，他们很开心自己能参与到开发工作中来。

2017年下半年，她换了个支持更给力的平台（历史长，自动化测试平台就多，我听说的就有四个），再一次开始一个系统一个系统的引入。

她依然选择一个人战斗，每天加班写代码。关于为什么她要写代码，我和她聊过一次。我认为，你只要把需求提给平台开发团队，让他们实现就好了。她告诉我，平台开发团队并不关心前场在应用的时候到底遇到了什么困难，他们有自己的节奏，因此平台缺失而我们又有需要的功能，我们只能自己干。

你可以想象，一个测试人员，一个人孤军奋战，攻克一个个技术难题，完善这个平台；而平台开发团队则醉心于提供一个大而全的平台，让你在上面“干什么都行”。

我跟她表示，如果有需要，我可以带领我的开发团队来加班帮你——然而还没等我们帮忙，她自己干完了。

这一次，她们是从一个系统开始的，将这个系统100%的测试用例全部自动化。在这个过程，她培养出来了一个测试小伙伴，这个小伙伴帮助她来将更多的用例自动化，她则添加更多的功能，例如数据库检查工具、用例管理、数据初始化工具等等。每开发出一个新的工具，这些培养出来的小伙伴们就会更新自己的自动化测试用例库。

这样做的好处是：

每个测试人员都会逐步的参与进来，这个过程不快也不慢，大家都参与，于是每个人的需要都被考虑到了，所以大家都认可。
测试工具的开发者是资深测试人员，她清楚自己目前最需要的是什么，她提供的功能让所有的测试人员都用得舒服，她的代码解决的是最实际的一线问题。
从业务用例着手，拒绝理论正确。还记得之前我的总结，测试人员的业务远远优于技术。所以让她们挑选那些最频繁被使用的、最重要最核心的业务用例，把好钢用在刀刃上。
小步快跑的结果就是，你可以亲眼见到她们的成果，这些成果会给整个团队极强的信心，让她们继续搞下去。每个人（包括领导）都会有这样的信念，我要提高，我要参与，我们能行！
这就是价值驱动的自动化测试平台建设思路，2018年她继续拓展她的平台，现在又在一家新的公司建设自动化测试平台了。

价值驱动的自动化测试平台建设
如果你问我，自动化测试平台建设的目的是什么，我可能说不出来，但是我知道一个不会错的答案，那就是：产出价值。

这个价值一定是客户导向的。我们之前说过，测试团队的客户有：

产品的最终用户
项目负责人以及更高层次的领导们
开发团队
其他相关的团队成员
而自动化测试平台的客户就是测试团队本身，这个平台通过服务测试团队来服务测试团队的客户们。

所以，这个平台要能够帮助测试团队完成他们的使命，要能够达成下面这两点：

用户的关键业务
严重的生产事故
额外的，平台还能通过自动化来提升测试团队的工作效率。

所以，自动化测试平台最重要的场景，就是针对这些核心业务用例的回归测试。

假如你是平台建设者，你只有一个月的时间，只有一名开发人员，你到底应该做点儿什么？

我认为，你至少要把冒烟测试给自动化了，就这一条就足以产生肉眼可见的价值。如果你的动作足够快，你甚至可以把核心业务用例的回归测试全给做了，哪怕你只验证了响应报文不管数据库。

围绕着产品质量和团队效率两个价值核心不断丰富你的自动化平台，能够帮助你更容易地推销你的平台，领导会对你更有信心，测试团队会更爱你。这样，你应该不会像我一样遇到资金链断裂的问题，你想要推动测试团队改革他们的流程也会遇到更小的阻碍，因为他们相信你能给他们带来价值。

是的，自动化测试平台一直是各个企业技术资源的黑洞，很多公司建设自动化测试平台的初衷往往是希望有一个高大上的解决方案让自己的测试水平起来没那么Low。很多测试总监也出于提升自己团队地位的考虑希望能够通过这样的平台来获得更多的权力。而测试平台的设计师则往往是严重脱离生产实际的技术人员，他们会醉心于大而全的设计，高大上的功能，最前沿的技术，把他们认为最美好的东西疯狂的堆砌到自己的框架里。

而这种思维造就的结果就是，这个平台会成为一个黑洞，疯狂的吞噬掉大量的技术资源，然而你几乎见不到它发出什么光来。

“它能用来干什么？”

“你用它干什么都行！”

事实上，他干什么都不行。当然，我并不否认应当有整体设计和有前瞻性的布局，但是自动化“测试”平台，我们应该关注这个平台到底能为测试团队带来什么价值，到底能为公司带来什么价值。

只有关注了这个，你的平台才会成功。甚至，你不需要看什么“自动化测试平台有哪些误区”，因为你的客户关心的，有价值的那些东西，一定不会是误区。

这也是我写这篇文章的目的，我希望自己不仅能指出哪些路不通，我还要告诉你，这条路几乎一定通。