八、自动化测试

有些东西像树上的苹果，好看而诱人，大家都说好，于是大家都去摘，只是有人家里的苹果已经红透，摘下来时鲜美可口，有的人家苹果刚刚成长，强行摘下苦涩异常。自动化测试就好像这个苹果。

8.1、被神化的自动化测试

每家公司都要搞自动化测试，这也确实是整个测试行业的整体趋势，但往往好大喜功，不管目前自身条件是否具备，声势浩大开场，而又往往虎头蛇尾结束。真正搞过自动化的人，经常开玩笑称自动化测试已经被神化了，脱离了实际，人为有意无意的忽视了任何测试技术手段都有他的边界，并非完全普世，而自动化脚本的维护成本，更是经常被忽视，而这其实是自动化测试的一个致命短板。

造成这种被神化的现象，究其原因，往往是团队主管急与向领导表忠心，表能力，表态度，自动化测试的意义不知不觉中逐渐变成了面子工程、献礼工程，华而不实。而身居高位的领导，则由于多年不接触基层，只是知道自动化的概念，再一看别的公司也在搞，自身当然也要搞，大手一挥 “开干”，开始时锣鼓喧天、鞭炮齐鸣，煞是有人民公社初期的高涨革命热情，人力财力都大幅倾斜，但实际一测试，发现坏了，界面大面积变更，脚本需要大规模维护，环境版本不稳定，需要人为频繁干预，各种弊端显露无疑，当年吹过的牛，自己挖过的坑历历在目，再也无法填平，一次项目之后，无人敢再提实施，但牛还要继续吹，于是开始转向自动化测试理论，各种华而不实的自动化测试方案漫天飞舞。

任何技术、模式、方法都有自身的优势与约束，单方面强调优势，可以回避劣势，只能华而不实，被神化的自动化测试，以行业历史发展的眼光看，自动化诚然是未来的趋势，例如现在业界发展的自动化运维一样，随着技术的指数型发展，基础软硬件设施的不断完善，自动化开发的概念相信也会在不久的将来横空出世，但从业人员要像《月亮与六便士》一样，随仰望星空，却一定要脚踏实地，清晰认识到自动化测试的优势与约束，才能有效发挥自动化测试的威力。

8.2、效果与趋势

自动化测试的理想效果是想通过少量的人员投入，通过系统自动测试的方式，来达到较好的测试成果。在笔者所在公司（200 余个重大项目群，5000 余人 IT 从业者），历时近 10 年的时间里，曾前后三次大规模推广自动化测试，经过不断的摸索与实践，总结出相对成熟的自动化实施方案，并在如支付结算、存贷款等大型项目中取得显著成果，在这两个项目中积累自动化脚本 3000 余份，曾经需要 80 人天的测试工作，自动化测试则只需要 5 个人工，跑 24 小时既能轻松完成。可谓效果显著，但反之，在企业现金管理项目中实施的自动化测试项目，则效果不明显，其投入的总人工成本甚至比纯人工成本还要高。面对如此大的效果差异，笔者曾牵头组织进行过详细分析，发现这两个项目的主要区别在于以下两点：

1、前者界面十分稳定，自动化测试脚本维护工作量不大，一次编制可以应用两年甚至几年以上，后者界面变化十分频繁，维护调试工作量巨大

2、前者的测试环境和版本要比后者稳定的多，每次跑脚本都比较顺畅，基本不需要人工干预，而后者版本十分不稳定，经常需要人工调整。

另外自动化测试在基础数据准备方面表现也十分优异，对于银行测试来说的基础数据包括客户信息、账号以及存款业务，而这开立这些基础数据如果通过人工来做，每个数据均需要 20 分钟左右的时间，才能全部准备齐全，而使用了自动化脚本后，效率提升了 100 倍，笔者曾经安排下属人员详细对比，20 分钟内，自动化脚本至少可以开立 100 条数据，而且不需要人工干预，这样就可以利用晚上时间，设置脚本定时运行，第二天早上测试人员来之后，机器就已经将数据准备充分而妥当。

随着业界越来越多的公司开始搞自动化测试，其大规模普及的趋势也越来越明显，而伴随着自动化测试相匹配的开发测试模式也在不断调整和创新，如持续集成模式等等。但当前阶段，自动化测试想要在大范围内取代人工测试，则仍不具备条件，尚需要技术再向前发展，相信不久的将来，自动化测试必然会迎来革命性的进展。

8.3、成本与约束

自动化测试的成本体现在脚本的编制和维护上面，脚本的编制一般在测试准备阶段进行，理想情况下，在执行阶段前期进行简单调试工作，在中后期发力，进行脚本的运行工作，而运行期理论上不需要人工进行过多干预，故准备阶段的投入占比较大。

但实际情况中，就项目阶段而言，由于开发情况不一定十分理想，界面随时会进行变化，而自动化技术目前主要依赖于界面识别，每次界面变动都会带来频繁的脚本改动与调试，而在准备阶段想进行充分的调试又是不显示的，详细的调试往往推迟到测试开始各协同方版本都已部署后，而这个时期本来环境版本十分不稳定，所以调试也十分困难，这时测试效果体现不出来，而管理层往往看不到测试进度，测试组压力会由此剧增，投入的人员甚至比手工测试人员还要多，而项目结束之后，也很难形成有效的资产，因为版本频繁变更，界面频繁变更，下次版本可能又会重新编制调试，成本也一直居高不下。

另一方面，基本上规模大一些的公司都需要对自动化工具进行二次开发，建立属于本公司的自动化测试框架，以适应本公司的 IT 环境条件，以笔者所在公司举例，在 10 年前就开始做自动化，当时是以业界成熟而昂贵的 QTP 最为基础软件，在其基础上进行二次开发自动化测试框架，而笔者有幸参与了框架开发工作，单纯从技术角度看，框架开发是十分成功的，其大幅降低了自动化测试人员的准入门槛，基本上纯业务人员也可以方便的使用，另外优化了脚本输入输出之间的相互关联，并可以联动 QC，进行自动化测试案例的自动管理，经过多年的完善，框架本身也越来越丰富了，但这期间也花费了大量的成本，既包括购买软件的成本，也包括二次开发的人工成本投入，因此公司在引进自动化测试时，应对成本进行全方位的预算判断，方能保证最后成功落实。

8.4、边界选择

为了让自动化测试能够切实可行的落地，而不是 “此物只有天上有”，一是要上下形成共识，自动化不能取代人工测试，二是要清晰明确自动化测试的边界，不能什么项目不管三七二十一，都要上自动化。

明确边界，其实也就是明确自动化适用的情况，建议如有如下情况，建议适用自动化：

(1)、项目上线已经有一段时间，核心功能相对稳定，界面变化较低，脚本后续复用率高

(2)、版本关联方相对稳定，开发计划可控，可预知环境版本相对稳定

(3)、版本需要开展接口测试，接口十分稳定，可做接口层面自动化

(4)、公共数据准备相关交易十分稳定，可用自动化方式准备基础数据

(5)、基础软硬件升级，可使用自动化脚本进行回归测试

(6)、持续集成的开发测试模式，每个版本上线内容少，可考虑做每日重要交易回归测试

除了上述情况外，选择自动化测试要小心谨慎，特别是新项目上线，不建议直接上来就用自动化测试，毕竟 “宝剑虽好，双面利刃”！