谈谈对自动化测试的理解

我们都知道对互联网行业，需要我们真真切切的认识到自动化测试，很多人可能都编写过自动化脚本，但是写了很多自动化脚本的你，真的理解自动化吗？真正的自动化测试到底是什么？

1、什么是自动化测试

例举一个形象点得例子，咱们在同一个公司，关系也不错，有一天你说：“XXX，你这么帅又有热心，能不能每天下午2点准时到工位上把我叫起床啊？”我对于这种诚实的人，我当然会同意了，于是我开始每天下午两点准时叫去拍他起床，只为他叫我一声靓仔。但是过了一星期的时间，我觉得每天都去叫，都是重复的，又累又麻烦，而且还要每天都记得，于是我决定，花费一个礼拜的时间来做一个机器人，这个机器人每天下午两点去把这个诚实的小伙子拍醒，这样我就可以去做别的事情了，解放了我自己的人力来提升效率。这就是简单的自动化，翻译回官方语言就是：把人的测试行为，转化成机器执行的过程，目的在于节约成本，提高测试效率。尽管定义很简单，那是实际上，在我们推动自动化测试的过程中会产生或多对自动化测试的错误理解，，所以我们就要思考另一个问题，你的项目中，自动化测试的目标什么呢？

2、自动化测试意义

其实很多人在做自动化测试的过程中，脚本写了一大堆，很多问题要逆向思考，脚本确实是自动化的产出物，但是你能说自动化就是写脚本吗？大多人在公司做自动化，可能都是一脸懵逼，老铁为啥要做自动化测试呀？领导要做，我就做呗，难道这不是自动化？自动化不就是写脚本吗？我们觉得这样很好。为什么做自动化是领导决定的，我们是执行的，以前都这么做，有毛病吗？行老铁这句话真的一丝毛病都没有，我都忍不住给你刷礼物了，但是，正式因为这个对自动化根本认识不清的问题，会让我们漫无目的的投入自动化，让个人或企业在自动化测试的道路上走一条大弯路，你的思想就会像某些司机，带着你环城旅行之后，在把你送到目的地。

我理解，实质上自动化的真正产出并不是代码？而是更好的流程和效率。自动化测试要考虑的是-ROI，也就是投入产出比。

很多情况下，不懂自动化的企业领导，都会对自动化测试抱有不太实际的幻想，觉着，有了自动化测试可以省下很多人力成本，自动化测试能做到一切想做的事，这叫黄粱梦，自动化必然不是万能的，你想，你有一个大房子，你做个机器人，按一下按钮，它就给你拖地，擦桌子，窗户，擦天花板，刷马桶？实际上自动化只是我们整个工作中一个辅助性工具，再优秀的测试用例，在稳定的系统，也不可能100%自动化。功能业务、复杂的逻辑、探索性的特殊操作，以及测试人员的经验，都是不能被自动化的。所以。我们对自动化的期望不宜过高，也不能低，回到上边的问题，自动化测试的目的，意义是什么？谨慎的说，**就是把我们的自动化测试应用到项目中去，在保证质量的前提下，让项目的测试成本，低于手工测试。**如果满足这个要求，我们就可以认为，自动化测试是有意义的，接下来把这句话拆分，来理解他

自动化测试：自动化测试的范畴有多大，很多人看自动化，就是那么可视化的UI层自动化，QTP啊，seleiuma，appium啊，这些东西，单实质上远远不是，更不是人多人看的，写个脚本就是自动化测试了。或者更进一步，我们可以写很长叫脚本，深知可以实现持续集成，就算账务自动化了吗？

一个好的自动化设计，不单单要让要用户方便使用，还要符合一些基本原则。这些原则包括：可服用、已维护、定时处理、持续集成、可调试、测试结果自动通知等等。所以高效的自动化需要优秀的框架，而框架的概念，是一系列的被事先定义好的标准和规范。

在自动化测试中，我们需要对测试需求解析、脚本设计、测试执行、测试报告、维护管理，通过框架将他们串起来，从而使框架的终端用户，能够翻方便的使用。

成本：做自动化的核心成本在于首次编写自动化脚本的时间成本，再加上每次迭代、每一次修改过程中维护自动化脚本的成本。越好的自动化设计，越能够进一步降低自动化脚本编写和维护上的成本。

低于：是一个比较级的此，所以要与手工测试做对比，也就是前边所阐述的正向收益，公式应该是这样的
收益 = 自动化覆盖部分的手工测试成本 - 首次编写自动化脚本的成本 - 自动化测试脚本的维护成本
收益为正的时候，则正确自动化确实是卓有成效的，但是如果大家写过一些自动化测试脚本的话，就会发现，在瀑布式、不稳定或者是小项目流程下，这个收益很可能为负收益，那么既然会出现负收益，为什么还要做自动化呢？换个提问方式？什么样的项目时候做自动化？

什么样的项目时候做自动化？

国内外大多自动化比较成熟的公司，都有共同的特征：稳定 & 迭代。
想淘宝这种大的系统，一个版本发布要支持很多年，做的大多都是bug修改或者活动上的迭代，这样自动化的受益就会非常可观，这种情况下公式就会变为：
受益 = 自动化测试覆盖部分的手工测试成本 * 迭代次数 - 首次自动化编写自动化脚本的成本 - 自动化测试脚本维护成本 * 迭代次数
我们就会发现，只要每个迭代中自动化维护成本小于手工测试成本，那么随着迭代次数的增加，自动化的收益就会无限增加，所以，一个项目早期不适合做自动化，原因是需求和业务逻辑的不断变化，会增加自动化的成本，同时也并不是每个项目都适合高度自动化，产品UI会频繁变动的，我们可能会用接口自动化来替身自动化的覆盖率。

其实成本还包含一项，也就是延误成本。什么是延误成本呢？
这里边我觉得更多的是管理、分支方面带来的困难，有很多团队的测试总监，针对一套框架不断的进行会议评审、讨论、架构调整，更有团队leader甚至老板多次更换自动化测试工具，还有更糟糕的，切换语言，来来来，咱不用java了，用python，为啥尼，python火啊，对啊，确实上火，一旦出现珍重情况，自动化测试的延误成本将变得无限高，收益和效率就没得谈，自动化测试也就成了笑谈了，结局无疑不是砍掉自动化，就是变成鸡肋的自动化。