为什么我们的自动化测试“要”这么难

八戒你干嘛

笔者在别的贴子里面曾提过，自己所在部门的自动化测试经历了几次步进式的建设，都具有阶段性的成果，但是总的看来却不是一个成功的案例。因为赶进度，仓促的投入让一大堆的脚本质量比较低下，有几个测试组由于没有人力投入自动化开发而又不得不完成自动化的KPI，只好聘请外包来帮忙完成自动化。理智地想一想，咱们花的那点钱请到过真正精通自动化技术又肯主动深入考察我们公司业务系统特征的外包么？况且外包终究还是要离开的，所以我们不得不接收一堆没有经过精心设计、没有组织性的脚本——尤其是在没有通用测试框架的情况下。且不说UI测试的自动化脚本本身就运行不了多久就会面临界面变更，单单是要让我们接收别人迥然不同的设计风格就是一件很难的事情。结果呢？要么延续这种无组织性，让脚本数量更加庞大、更加杂乱无章，要么就是放弃对这些脚本的维护，任其自生自灭，最终变成一堆废材。
再想一想如今我们有几个人在利用自动化脚本帮助自己的测试？高通过率的脚本是否就一定有它存在的意义呢？会不会出现为了应付指标数据，我们让我们的脚本设计和验证得尽可能地简单、尽可能地能运行通过的情况呢？他们可能即便不放心自动化测试结果，也可以手工再回归测试一遍……这种滑稽的现象表明自动化测试已经彻底的成了包袱！虽然我们公司崇尚结果导向，但是我觉得我们应该首先从根本上弄清楚什么目标才是我们最终想达到的。KPI考核的导向性作用很强，但是如果KPI并没有能够帮助我们得到我们想要的结果，那么KPI的设定就不是SMART的，持续改进意识不仅仅是流程规范，还有我们的KPI，对于自动化测试来说尤其重要。
我们有一部分同事宣称：“我知道自动化能给我带来便利，但是我实在没有时间投入脚本开发”，其实就是骨子里抵触自动化测试，抵触工作方式的改变。另一部分人则很狂热，看到自动化的些许好处就开始盲目崇拜自动化测试，也正是由于这种急功近利的心态，让他们在“看到”一些失败之后就将矛头直指测试工具，而并不去反思自己在整个实施过程中采用的方法。攻击某种工具是如何的不好，另一种工具如何的优秀，但是不去分析其中的差异，武断地对大家宣称换一种测试工具能够节省成本、提高测试有效性。其实各种测试工具各有优点侧重，其应用范围和方法都有所不同，还是要理性地去看待这些问题。我本可以把别的测试工具数落一番，但我又不敢，因为我着实还没有精通它们的使用方法，所以也不是非常明了它们的弱点，单就大家常说的QTP的弱点来说：
1. 需要付出昂贵的工具许可费用，的确是很大一笔费用。但是买都买了，莫非我们还要找厂商去退货？再者，我们省掉的可能是工具许可费用，但是要付出的则是培训人员新技能的费用、开发测试管理工具和新测试工具接口的费用和为仍然可能出现的失败买单的代价；
2. 需要大批的运行客户端，情况的确是这样，但是做真实的页面模拟测试，并且不能绕开我们系统的SSO认证，用什么工具都是一样的，不信的话可以自己去验证一下；
3. 对象经常不能识别，凡以此为由贬低QTP的人都可以回去面壁了，那么简单的技术都用不好又何必再言其他？我相信也有一些QTP粉丝们在对开源测试工具的易用性不断地腹诽，论坛上甚至还有谩骂声；
4. 运行经常莫名其妙的失败，这是测试环境问题、运行客户端问题、脚本健壮性问题，这些问题可以得到解决，我们也可以通过解决这些问题来更加深入的了解我们的测试工具。
这些现象从根本上反映了人在出发点的心态和对工具的认知水平才是决定自动化测试实施成败的关键。对自动化测试工具的使用来说，我很庆幸自己选择了一个由简单到复杂的学习过程；如果先学习了较为复杂的，再去使用这些所谓“简单”的商业工具，很容易产生刚入门就轻视的情绪。正是为了避免自己“半瓶水瞎晃荡”，我们试图努力地去学习、了解别人的所思所想，可结果是，越学越迷茫、越学越恐慌——以前眼中的小小领域竟然包含如此之多的知识，学海无涯一说实诚不我欺也！而在学习的同时也深深的为我所看到的一些现状担忧，正是由于这种担忧，即便知道自己只是半瓶水，但还是忍不住站出来，东一榔头、西一棒槌的“晃荡”几下，继续扮演领导眼中一个不明真相的围观群众的角色。
别试图用底层测试取代页面测试
测试基础理论告诉我们：缺陷发现的越早，修复所花的成本越低；所以对于自动化测试来说，如果应用的越早，它的收益就应该越多。所以现在很多公司都在推行集成测试、单元测试的自动化建设，我们也不例外。我们把这些自动化测试工作纳入测试部门的日常工作中来，试图在每日回归自动化中使用这些测试，而同时测试环境和版本管理非常严格，那么这部分的自动化测试执行还是要等到版本一板一眼的把流程走完，部署到测试环境之后才能开始。如此一来，这部分集成测试和单元测试的自动化的执行时间并没有被提前，和敏捷更是挂不上边。我们的版本流程清晰的从时间上分开了单元测试、集成和系统测试，也从流程上基本上消灭了在测试环境做非系统功能、性能测试的可能性。所以，如果说要开展以赢得更多效益为目的的底层的自动化测试，还是需要推动编码人员去实施这部分测试内容或者变革版本流程，做到将底层的自动化测试在开发环境进行运行，达到测试出口之后再进入系统测试阶段。
单元测试和集成测试全部通过完成之后是否就意味着本次构建测试就是通过的呢？当然不是。在很多夹杂着复杂业务逻辑的软件中，复杂的操作场景和数据逻辑的正确性验证还是要依赖大量的UI层面上的验证测试。所以对于有些形态（例如金融类）的软件产品的自动化测试来说，有足够强大的UI层自动化测试支持也是必需的。早已有很多人已经给底层测试覆盖的作用盖棺定论：并不是每一个功能点和每一个分支测试通过就意味着软件质量是合格的，因为对于不同结构的系统来说，有些程序逻辑很依赖前端，有些程序逻辑更偏向于倚重核心，加上数据的复杂业务特性也不允许我们忽略复杂场景组合带来的一些新问题。也就是网友所说的“代码覆盖只能告诉你什么没有测试，却不能告诉你软件是否通过了有效测试”，正是基于这点，如果倾向于用单元测试或者集成用例测试来丰富自动化回归测试范围的话，我们能够理解；但是如果想用单元测试或者集成测试用例来替代回归测试中对应的内容，那么就没有什么意义了。而且笔者提倡如果某个功能如果同时能够通过页面和底层去验证的话，就尽量不要去做底层的测试，至少在非敏捷的项目中或者在测试部门的系统测试工作中，不要去这么做。不知道这种说法是不是颠覆了一些人心中的观念，且不要急着拍砖，下面我们继续讨论。
页面测试工具的选择有什么规律
首先要赞扬Selenium和WebDriver这些开源WEB自动化测试工具的灵活性（注：WebDriver就是基于Selenium的一个自动化测试类库，但它不再是运行在浏览器内的JS程序，而是自己可以控制浏览器），这些工具在与大多数测试平台的整合以及其所支持的脚本语言种类上都有很大优势（Java、dotNET、Perl、Python、Ruby、C#等）。由于它们是专一的WEB自动化测试工具，它们在处理WEB应用的问题上显得非常专业，结合一些Hook程序的使用，使得它们的运行速度明显快于QTP。而同QTP一样，他们在处理一些第三方插件的时候都需要借助另外的插件和程序，这一点也正好印证了开源工具的特征：为了解决我们需要的需求，可以采取一些额外的手段来协助。不过商业工具也不是就甘心这样让出他们的市场的，HP为QTP10.0及以上的版本增加了Extensibility Accelerator组件，专门用来为测试人员自定义开发与发布插件类库。该组件在其易用性在还没有被广泛验证之前一直显得比较低调，通过对QTP11的简单试用，笔者觉得这是开源的冲击终于让像HP这样的厂商不得不放低姿态，开放一些核心的、更有价值的东西给大家使用，其一直鼓吹的傻瓜式关键字驱动不再成为其宣传的核心卖点。总的来说在易用性和扩展性上，最新版本的商业工具（QTP）和这里提到的两种开源工具其实是旗鼓相当的；只不过在平台整合和所支持的脚本语言上，QTP还是显得比较单纯，虽然厂商在不断地丰富着它所提供的AOM接口方法。
其次，单就WEB自动化测试来说，我们选择任何工具，只要能进行WEB测试，那么它几乎可以全部应付我们绝大多数的自动化需求；只不过为了自动化实施的更加便利，我们对WEB应用类型还是可以再细分一下。由于Selenium和WebDriver这些开源是基于浏览器的测试工具，它们在快速响应UI交互请求和流程性、逻辑较为简单的应用程序的测试上优势巨大。但是对于业务逻辑复杂和流程性很强的软件来说，要是使用他们就必须有足够强大的测试框架：要处理不同的第三方插件程序，要完成类型众多的参数Mapping解析和文件操作、数据库操作等，要处理调度管理和大规模执行的种种条件依赖，要完成复杂的断言分析设定，定义出错之后的处理方法……即便是为其专门定制的测试管理工具Bromine也无法很好的满足我们日常这些复杂的需求。虽然这些组件开发完成之后组装起来的框架通用性比一般的QTP自动化测试框架要高一些，但是其开发的技术难度显然比后者高很多，必须要考虑员工技能现状，这就需要我们仔细地考虑清楚其开发成本是否有足够的优势。相较之下，虽然QTP这些商业工具入门简单，但随着测试人员不断地学习和深入，我们会发现它也能够满足一些更复杂的逻辑和流程验证。因为QTP的起点很低，即便起初没有测试框架，使用QTP+QC提供的一套原始的框架也可以替代管理，完全没有技术难度可言，用于处理大部分流程性比较复杂的系统来说都足够了，后续框架建立起自己所需要的框架之后也可以把离散的脚本程序纳入新的框架中去管理，其核心问题是对执行环境和测试数据等方面因素要求非常高。而QTP脱离QC的框架也有很多，不过大同小异，开发难度也不高，笔者认为这是在B/S结构的金融软件UI自动化测试中使用得最多、最为成熟的一种形态。有了这种应用系统特征的区分意识，我们就能够理解Google和百度这样的门户网站为何很少去使用QTP测试，因为这种应用要使用QTP测试实在是让被测程序委屈（操作慢）、让测试工具委屈（综合实力无法体现），更让测试人员委屈（得不偿失）——如果他们能够熟练运用Selenium和WebDriver这类开源工具和框架的话。
总之，工具的选择一方面要看被测应用的特征，一方面要看组织内部人员技能水平现状。如果要追求技术上的行业领先地位，充分利用现有的强大的技术优势，那么使用开源工具和框架无疑是一种不错的选择；而且开源的思想使得工具更加能够区分体现不同的社会产业领域的软件在自动化测试上的不同特征，为更加全面的认识自动化测试铺下坚实的基础。但是由于开源的自动化测试实施在一开始就要把调度平台、测试框架相关的内容全部准备好，就从根本上决定了它们不适合在探索性的测试自动化建设中大规模使用。同时我们知道，QTP这种商业工具在初级到中高级水平的自动化测试实施过程中还是比较有优势的，只不过在实施的过程中所遇到的问题远远要比这些开源工具更加闹心，随时有让人想放弃这种工具的感觉。但是在达到一定规模和水平之后，无论任何工具，在界面测试自动化实施上，我们回头看的时候就将会发现，选择开源测试工具还是商业测试工具无非是郁闷在起点还是郁闷在过程中的问题，其本质上都是一样的，没有什么卓越到让傻瓜都能变得无比强大的测试工具。通常，互联网应用和门户网站的UI测试更推荐使用Selenium和WebDriver这些开源工具；而对于有着复杂业务逻辑和业务流程的B/S结构的企业ERP应用来说，如果自动化测试实施的规模较大、测试人员技能水平一般的话，那么最好还是先使用QTP这种类似的商业工具。
我们不妨扪心自问：我们追求的是什么？我们的现状又是怎么样的？我们是否已经把我们当前这个自动化测试的建设做到出现瓶颈了？在遇到瓶颈的时候我们还有没有继续进行深入的研究呢？如果再三思考之后还是想到可能会有可改进的地方，觉得有可能越过某个点之后就会得到新的效应，那么请不妨回头继续把当下的建设做完。就像围着5米宽的圆环型跑道寻找遗失的物品，无论单次走的是内圈还是外圈，都应该走到头，否则达成你的目标就只能靠碰运气了。如果你们在开展大规模的自动化建设，并且你们发现根本无法在跨越目前的瓶颈了，那么可能真的需要尝试一些新的工具或者框架了。

八戒你干嘛

大规模自动化实施也有流程定势
笔者理解，一般的小型项目和系统在快速的测试过程中对测试框架的需求不是很明显，因为三五十个测试用例的管理对与我们来说不是什么问题。但是如果用例多到几百上千乃至上万的话，没有科学的组织管理方式将会是个灾难。我们这里先看看大型项目和系统或者系统群的自动化实施，它们在自动化实现从无到有、由浅入深的过程中都需要关注哪些方面。

首先是人员的技能，这是最基本的条件，缺少这个条件，一切后续的工作都没有办法继续下去。所以一个公司要进行自动化实施，在这个实施周期的最初阶段就需要解决的是人员技能的问题，一般有人才引进、引入培训或者聘请顾问咨询等办法。自动化测试框架与平台不能单靠“求同存异”这四个字就能定义的，因为它们需要全部兼容绝大多数类型的系统、解决绝大多数问题。所以调研分析虽说用不着细致入微，但还是应该把所有系统的设计特征和业务流程都了解清楚。所以这对负责人的技能要求非常高，否则会带来频繁且不必要的框架、平台的变更，给测试管理带来很大不便。就像做接口测试自动化，我们公司的产险业务系统中的业务规则多依赖于JAVA程序，但是养老险则基本都依赖数据库PACKAGE，拿其中一个做所谓的DEMO去向另一个去推行，阻力就会大到基本不可行的程度。这就是负责人对系统特征理解单一、对整个公司的应用系统的架构特点不了解所导致的。
自动化测试平台的搭建需要考虑其各方面的表现，因为它是一个较为通用的应用程序，故而，它的兼容性和健壮性要求很高。在一个测试组织或者一个公司内部，一般自动化测试平台应该可以做到通用于所有的系统测试，即便它们所采用的技术乃至理念会有所不同。就像我们通过测试平台STAF可以实现调度像QTP、SELENIUM这种UI层的自动化测试，也可以完成对JUNIT测试用例的运行调度和管理。而测试结果的分析也可以通过相应的报表系统来完成，按照我们自己的需求，把调度管理和分析管理等其他功能模块有机组合在一起，形成一个功能较为完整的测试平台。平台建设得好，无论是单纯的UI层验证测试还是敏捷测试，我们应该都能够支持得好。
我们知道，并不是一个自动化测试框架就能够应用于所有系统的自动化开发，因为被测程序的特点本身就本不相同，即便在同一个公司，也会因不同的开发风格和开发技术而要求有不同的测试方法。所以自动化测试框架虽不需要每个系统单独开发一套，但是也很难做到用一个框架支持所有系统的测试，最好的办法就是根据开发技术划分所需要使用的测试框架种类，例如QTP测试的纯WEB型、GUI型和各种插件开发型（如dotNet、JAVA等）。
关于自动化测试平台和框架的异同等方面，笔者曾在另外一篇自己的学习总结《软件测试自动化的探索与管理》中曾有过阐述，这里不再赘述。在完成这些基础建设之后我们才能够开始我们的大规模的人力投入，来进行针对每一个项目和系统的具体实施，否则如果先后颠倒或者本末倒置，势必会让我们面临纠结的重复建设和开发投入。而另一方面，在自动化测试实施的过程中，我们可能会随时面临很多的问题和困扰，但是在解决这些问题之后，我们测试人员的技能又能够得到提升。在技能提升的前提下，后续又可以进行新的改进和新需求的达成，这是一个循环的过程，也是自动化测试建设本身的持续优化。
从上图可以看到，这一系列的过程都是围绕着一个中心进行的，那就是自动化测试的KPI指标。前文曾简单提到过KPI的导向作用，我们千万不要小看那么几组小小的数字，更不要指望测试人员能够“跳出考核指标，为真理而奋斗”。所以如果我们的指标指向偏离我们的核心目标，那么自动化建设就会被引入误区，可能产生形式化、教条化甚至作假问题的产生。我们核心的目标是系统可用率和缺陷消除率（在一个分层扁平式管理的大型IT公司里，考核除了依赖对这些基础的贡献度的考察，我们还真没有想到其他更好的办法，虽然有敏捷思想的冲击和新考核建议的提出，但是在体制下和运营方式没有发生大的变化之前，或许只有这种考核方式才能勉强应付用户的资金投入和期许了），既然缺陷的消除对我们如此重要，那么我们的自动化测试行为就应该围绕着应可能多的发现应用缺陷这个主题来进行。所以自动化测试的覆盖率、运行通过率等指标都只是过程中的参考数据，根本不能用来考核自动化的成果，这些指标的作用在自动化测试实施层面上还不如同行专家评审，虽然它们对中高层管理者来说有一定的参考意义。虽然很多人一再强调，UI自动化测试只是用来验证系统的正常运行，增加测试人员的信心，但是我始终不以为然。如果一个版本周期只在版本即将封版的时候运行一两次，或许可以这么说；但是自动化测试是可以投入系统测试阶段中使用的，至少可以进行基本的冒烟测试执行。如果在自动化应用于冒烟测试却发现不了缺陷，而手工执行能够发现一些严重问题，那么这个系统的自动化测试程序绝对是不合格的。依托自动化测试管理平台，我们适当提高运行频率，通过大面积自动化的页面操作，一定能够发现很多问题——如果我们愿意为脚本灌入足够多的测试数据，愿意在运行结束之后仔细地分析测试结果，那么自动化测试绝对是有产出的。
自动化测试的指标也是可以持续优化的，通过不同阶段的现状，适当调整自动化测试的KPI，用以指导自动化测试工作的开展。笔者认为无论高层的KPI如何定制，但是拆解到自动化测试实施的过程中，就需要更加有可行性并且具备正确的引导作用。例如我们可以考虑采集如下数据进行分析，来判断的自动化脚本开发的有效性和自动化测试建设对于我们的系统测试的帮助有多少：
a) 脚本评审通过率：通过评审的测试脚本/所有通过开发、调试的测试脚本
b) 脚本同步及时率：在应用缺陷修复之后指定时间内完成的测试脚本数/所有运行失败脚本数
c) 测试缺陷发现率：通过自动化测试发现的缺陷数/所有系统测试缺陷数
d) 功能选择活动率：三个月内涉及功能变更的测试脚本数/所有测试脚本数
e) 资源占用超标率：平均运行时间超过手工测试用例平均执行时间的脚本/所有测试脚本数
如是种种，各位不妨结合自己的实际进行参考或者设置，笔者这里只是简单举例，并不具备通用性；只是希望大家可以多参与交流、多思考，组织头脑风暴神马的都可以，只是千万不要闭门造车。
结束语
测试人员需要能够胜任重复性的工作，但是测试人员绝不需要胜任被引导着去重蹈覆辙的行为，自动化测试建设成功与否，完全取决于参与建设的人的素质。本文标题里有个“要”字，是因为笔者认为自动化测试建设的成败、自动化测试之路走得是否通顺完全在人，而并非测试工具等其他外在因素。
可一败，不可再败！慎！慎！
万事开头难，但绝不该始终都难！三思！三思！

梦想家

嗯确实难

pneocean

自动化测试建设成功与否，完全取决于参与建设的人的素质，这话很有道理。
我们公司之所以从接口和UI自动化从搭建到持续维护都很成功，主要有以下几个原因：
1. 测试框架老大写的，持续集成老大搞的，人都是老大招的
2. 测试人员无论招进来时级别如何，转正前都要求掌握代码开发能力
3. 测试老大是我