我们的自动化测试为什么这么难？

　　笔者在别的贴子里面曾提过，自己所在部门的自动化测试经历了几次步进式的建设，都具有阶段性的成果，但是总的看来却不是一个成功的案例。因为赶进度，仓促的投入让一大堆的脚本质量比较低下，有几个测试组由于没有人力投入自动化开发而又不得不完成自动化的KPI，只好聘请外包来帮忙完成自动化。理智地想一想，咱们花的那点钱请到过真正精通自动化技术又肯主动深入考察我们公司业务系统特征的外包么?况且外包终究还是要离开的，所以我们不得不接收一堆没有经过精心设计、没有组织性的脚本——尤其是在没有通用测试框架的情况下。且不说UI测试的自动化脚本本身就运行不了多久就会面临界面变更，单单是要让我们接收别人迥然不同的设计风格就是一件很难的事情。结果呢?要么延续这种无组织性，让脚本数量更加庞大、更加杂乱无章，要么就是放弃对这些脚本的维护，任其自生自灭，最终变成一堆废材。

　　再想一想如今我们有几个人在利用自动化脚本帮助自己的测试?高通过率的脚本是否就一定有它存在的意义呢?会不会出现为了应付指标数据，我们让我们的脚本设计和验证得尽可能地简单、尽可能地能运行通过的情况呢?他们可能即便不放心自动化测试结果，也可以手工再回归测试一遍……这种滑稽的现象表明自动化测试已经彻底的成了包袱!虽然我们公司崇尚结果导向，但是我觉得我们应该首先从根本上弄清楚什么目标才是我们最终想达到的。KPI考核的导向性作用很强，但是如果KPI并没有能够帮助我们得到我们想要的结果，那么KPI的设定就不是SMART的，持续改进意识不仅仅是流程规范，还有我们的KPI，对于自动化测试来说尤其重要。

　　我们有一部分同事宣称：“我知道自动化能给我带来便利，但是我实在没有时间投入脚本开发”，其实就是骨子里抵触自动化测试，抵触工作方式的改变。另一部分人则很狂热，看到自动化的些许好处就开始盲目崇拜自动化测试，也正是由于这种急功近利的心态，让他们在“看到”一些失败之后就将矛头直指测试工具，而并不去反思自己在整个实施过程中采用的方法。攻击某种工具是如何的不好，另一种工具如何的优秀，但是不去分析其中的差异，武断地对大家宣称换一种测试工具能够节省成本、提高测试有效性。其实各种测试工具各有优点侧重，其应用范围和方法都有所不同，还是要理性地去看待这些问题。我本可以把别的测试工具数落一番，但我又不敢，因为我着实还没有精通它们的使用方法，所以也不是非常明了它们的弱点，单就大家常说的QTP的弱点来说：

　　需要付出昂贵的工具许可费用，的确是很大一笔费用。但是买都买了，莫非我们还要找厂商去退货?再者，我们省掉的可能是工具许可费用，但是要付出的则是培训人员新技能的费用、开发测试管理工具和新测试工具接口的费用和为仍然可能出现的失败买单的代价;

　　需要大批的运行客户端，情况的确是这样，但是做真实的页面模拟测试，并且不能绕开我们系统的SSO认证，用什么工具都是一样的，不信的话可以自己去验证一下;

　　对象经常不能识别，凡以此为由贬低QTP的人都可以回去面壁了，那么简单的技术都用不好又何必再言其他?我相信也有一些QTP粉丝们在对开源测试工具的易用性不断地腹诽，论坛上甚至还有谩骂声;

　　运行经常莫名其妙的失败，这是测试环境问题、运行客户端问题、脚本健壮性问题，这些问题可以得到解决，我们也可以通过解决这些问题来更加深入的了解我们的测试工具。

　　这些现象从根本上反映了人在出发点的心态和对工具的认知水平才是决定自动化测试实施成败的关键。对自动化测试工具的使用来说，我很庆幸自己选择了一个由简单到复杂的学习过程;如果先学习了较为复杂的，再去使用这些所谓“简单”的商业工具，很容易产生刚入门就轻视的情绪。正是为了避免自己“半瓶水瞎晃荡”，我们试图努力地去学习、了解别人的所思所想，可结果是，越学越迷茫、越学越恐慌——以前眼中的小小领域竟然包含如此之多的知识，学海无涯一说实诚不我欺也!而在学习的同时也深深的为我所看到的一些现状担忧，正是由于这种担忧，即便知道自己只是半瓶水，但还是忍不住站出来，东一榔头、西一棒槌的“晃荡”几下，继续扮演领导眼中一个不明真相的围观群众的角色。

　　别试图用底层测试取代页面测试

　　测试基础理论告诉我们：缺陷发现的越早，修复所花的成本越低;所以对于自动化测试来说，如果应用的越早，它的收益就应该越多。所以现在很多公司都在推行集成测试、单元测试的自动化建设，我们也不例外。我们把这些自动化测试工作纳入测试部门的日常工作中来，试图在每日回归自动化中使用这些测试，而同时测试环境和版本管理非常严格，那么这部分的自动化测试执行还是要等到版本一板一眼的把流程走完，部署到测试环境之后才能开始。如此一来，这部分集成测试和单元测试的自动化的执行时间并没有被提前，和敏捷更是挂不上边。我们的版本流程清晰的从时间上分开了单元测试、集成和系统测试，也从流程上基本上消灭了在测试环境做非系统功能、性能测试的可能性。所以，如果说要开展以赢得更多效益为目的的底层的自动化测试，还是需要推动编码人员去实施这部分测试内容或者变革版本流程，做到将底层的自动化测试在开发环境进行运行，达到测试出口之后再进入系统测试阶段。

　　单元测试和集成测试全部通过完成之后是否就意味着本次构建测试就是通过的呢?当然不是。在很多夹杂着复杂业务逻辑的软件中，复杂的操作场景和数据逻辑的正确性验证还是要依赖大量的UI层面上的验证测试。所以对于有些形态(例如金融类)的软件产品的自动化测试来说，有足够强大的UI层自动化测试支持也是必需的。早已有很多人已经给底层测试覆盖的作用盖棺定论：并不是每一个功能点和每一个分支测试通过就意味着软件质量是合格的，因为对于不同结构的系统来说，有些程序逻辑很依赖前端，有些程序逻辑更偏向于倚重核心，加上数据的复杂业务特性也不允许我们忽略复杂场景组合带来的一些新问题。也就是网友所说的“代码覆盖只能告诉你什么没有测试，却不能告诉你软件是否通过了有效测试”，正是基于这点，如果倾向于用单元测试或者集成用例测试来丰富自动化回归测试范围的话，我们能够理解;但是如果想用单元测试或者集成测试用例来替代回归测试中对应的内容，那么就没有什么意义了。而且笔者提倡如果某个功能如果同时能够通过页面和底层去验证的话，就尽量不要去做底层的测试，至少在非敏捷的项目中或者在测试部门的系统测试工作中，不要去这么做。不知道这种说法是不是颠覆了一些人心中的观念，且不要急着拍砖，下面我们继续讨论。

原文转自：http://www.ltesting.net