引言
内容已经有了，可是标题想了好久，最终仍是决定用这个。简单清楚明了——总结一场失败的自动化测试案例。前端
文笔欠佳，若有阅读不适，请见谅！java
自动化测试
现在，软件测试行业里，人人都在讲自动化测试，人人都在作自动化测试。若是谁说本身不会自动化测试，都很差意思去面试。如今各大公司招聘信息都是必须会自动化测试，一部分公司招人只招测试开发。甚至有些大头公司都不分测试与开发两个职位。python
因此，绝大部分公司都有人在搞自动化测试，甚至有一部分公司有一套成熟的自动化测试体系。你能够把它当作标准化流水线，相似如今讲的Devops。程序员
这里，我讲的固然是我在公司的一次自动化测试体会。因为保密协议，这里简单介绍：web
背景
公司是一线大厂的子公司，也能够称为合做伙伴。 相似华为旗下的荣耀。公司去年年初，因为业务愈来愈繁多，因此人员也是疯狂扩展，因此迭代至关频繁，标准是一周一个迭代，紧急小迭代，也有过两三天的时候。有人会说怎么作到的，拼人啊，加班啊。面试
测试团队
先说咱们测试团队吧，扩展后测试团队人数大概是40左右，其中职位有自动化测试，测试开发，性能测试，安全测试。惟独没有测试工程师。由于公司不招单纯的功能测试。sql
有人可能会质疑，那业务测试谁来作？数据库
在这里，咱们公司业务测试全职测是自动化测试，而测试开发是专职于测试体系建设中。性能和安全测试有时候会支援业务测试，可是他们也是专职于性能和安全方面的测试，面向全公司全部系统。编程
测试体系发展
起初测试团队是没有对测试技术体系思考，你们作自动化测试都是各自作各自负责的业务系统那一块，用的工具与方面各色各样，编程方面大体分两派java和python。安全
这种分散的自动化测试带来的弊端就是：
一、数据没法可视化；
二、脚本维护难；
三、增长了学习成本；
四、易用性、移植性差；
这种分散的，小做坊形式的很快就不适应快速迭代的需求及市场变化。最核心的一点是，部门领导没法向老板展现数据。通俗的来说，就是没法向领导展现咱们测试团队存在的价值。
嘴巴说，谁都会。可是，领导想看数据，那么平台是惟一秀出测试团队工做中沉淀下来的数据的途径。这样有了数据，团队的KPI就出来了。
你说你每天在测试，每天在作自动化测试，作了多少，效果如何。领导不可能一个个找大家去统计，去查看。无论你脚本写的多优秀，框架设计得多么出神入化。终究没有所谓的正规化平台好。
而后，就这么定了。几位测试开发大神，在领导的安排下，通过多番讨论的设计方案，写了一套后台是Java的自动化测试平台。这里说明一下，只因此是Java，由于公司是Java系统。
测试平台
时至今日，平台已经完善得差很少了，该有的都有，没有的也有了。简单说一下平台的功能：
一、接口测试；
二、UI测试(app和web)；
三、性能测试；
四、流量监控；
五、接口覆盖率统计；
六、安全测试；
七、代码质量扫描；
八、生产发布卡点；
....
主流的功能就是这些，其余小功能我就不一一列举了。这套平台已经集成了软件测试中绝大部分的测试技术在里面；能够算得上一套标准的流水线了。
之前会自动化测试会以为高大上，如今平台搭建起来了，而且已经维护了1万左右的测试用例在上面了。是否是更加牛逼了？
答案我不知道平台搭建后是否真正牛逼了，可是它的建设至少对测试团队的影响有以下几点：
一、增长了团队的技术含量(至少领导不会认为咱们只会点点点)；
二、提升了团队的做战能力；
三、提升了测试效率(因人而异)；
四、下降了成本(待查)；
五、提升了产品质量(待查)；
六、下降了学习自动化的难度；
...
上面只列了六点，对于咱们测试团队的影响，也算人们口中常说的自动化测试的意义。其实还有不少，就不说了。
自动化测试现状
平台是完善好了，前面说了，平台已经维护了1万左右的接口测试用例，其余数据我暂时没看。显然平台健壮性是毋庸置疑的，易用性也很好，入门简单。
那么问题来了，对于迭代频繁的项目，咱们在何时去编写接口测试用例呢？
这种问题，绝大多数的人都知道，常规的回答不限于这些：
一、接口测试需求评审了(绝大多数是没有)；
二、什么开发接口开发好了，开发提供了接口文档之类的，咱们就能够去平台维护接口测试用例了；
三、开发自测经过，代码提交；
...
...
这些回答都很标准，很理想。可是，你有没有想过，现实是很骨感的，就是会出现以下情形：
现状一：
版本变化得让你根本没时间维护的时候，你只有加班抽时间来维护，并且这种状况只有在领导发话了，你们才会去维护上去。有些人因为业务线确实忙，因此没维护，有些是本身写脚本，根本不想维护上去。固然也有人主动的去维护。
针对这个现状，领导又出必杀技，将接口测试用例设计和覆盖率的指标定下来，而且放到KPI考核项里去。
KPI大家都懂，这里就不讲述它的做用了。这个大招一放，你们都自觉的去平台上维护了。
现状二：
现状二就是现状一的延伸版，就是每次版本有新增的接口后，你们为了KPI会主动上去维护。而后有一大部分人也仅仅上去维护此次，后面版本接口有变动，也不会花时间去更新已经维护上去的接口。
其中缘由，有些多是真正的忙，没有时间。有些可能由于懒，不想去维护。总而言之，测试团队中有一部分人是没有去更新接口测试用例的。
现状三：
谈到自动化测试的用途时，你们都会记得其中一个是用于回归测试，减小人力投入到版本回归测试中去，从而把节省出来的时间和人力，用于更多的业务测试或者其余测试中去。
可是，现实倒是，在版本变动中，真正去执行之前维护的接口测试用例来回归测试的人太少了。据我观察和了解，在短时间迭代中，上个迭代维护的用例，这个迭代没人会去跑，哪怕只用一分钟的时间。
出现这种状况，一方面因为自信，太自信于以为以前的接口没有变更，不必去跑，另外一方面，时间过短，又要交付测试，功能测好，直接就进入产品&业务验收环节。就把这一步省略掉。
固然，还有其余不少缘由，这里不细说。结果都是同样，没有去维护历史数据。
现状四：
自从公司招进外包测试后，如今部分项目测试工做分配以下：
测试工程师专门负责设计用例，而后交给外包团队来将这些用例再翻译成测试脚本，这样的作法，效率不低下才怪。
首先外包同志不熟悉业务线，直接转化，仍是得从了解业务开始。
其次功能测试用例直接翻译成自动化测试脚本存在重复性劳动，同时也会出现场景遗漏，场景不可用的状况。
总而言之，这种作法收益大大低于投入。
正确的姿式是：测试工程师本身就将测试脚本交付出来。对于那些全栈工程师而言，最正确的姿式是：开发人员本身就动手将测试脚本写出来。根据我对微软的了解，微软的 Visual Studio 团队，就是这么作的，他们根本就不区分开发和测试。
现状五：
谈自动化测试的时候，咱们常常会讲到它的优势，其中一个就是下降错误率，发现人工没法发现的缺陷。那么，在这里统计的结果，咱们作接口测试真正发现的缺陷是屈指可数，百里挑一的。
有的甚至一个都没有。固然接口测试自己也是有局限性的，他不可能彻底代替手工去发现手工测试的缺陷。
这里只讲它的现状...
现状六：
...
...
综上所述，还有不少现状，我这里不一一列举，能够看出来，出现这种想象，一方面是因为我的缘由，测试的责任和态度。
一方面领导要求全部项目都要作接口自动化测试，历来不评估哪些项目适合作接口自动化测试。
有点盲目跟风，作了自动化测试就闪光辉，而实际带来的价值，倒是0。
还有一方面，也是关键的一点领导对自动化测试管理方面的欠佳，光靠KPI来触发是不行的。
失败的背景
上面已经讲了，目前公司自动化测试存在的广泛问题。
如今从我这个小团队来说，项目要上阿里云，就是系统上阿里云，至于什么缘由，就不说了，涉及保密协议。
系统上阿里云，固然没有那么简单，全部与系统相关的服务、数据库、中间件、流量等等，相对于迭代版本，这是一次比较大的变动过程。
而后，咱们测试在里面承担了什么角色呢？
自动化测试在此次迁移的价值会是怎样呢？
失败的经历
项目上云，固然咱们测试要保证项目上云后，全部功能都能正常使用。可是切换的那一段时间，你有多少时间去验证全部的功能都正常呢？
只有两三个小时，一年积累下来的功能，两三个小时如何验证完呢？
这个时候就是自动化测试该上场了。
这个项目自动化测试交给外包维护了，是在咱们测试平台上维护的，主要是维护WebUI功能测试用例。接口测试用例是咱们几个在维护。
到了那一天凌晨，你们都准备好了，准备上云。而后验证。
最后发现，没有维护一个WebUI测试用例(生产环境)。
临近上云的几个小时前，我问他维护了多少用例，他说测试环境维护了，生产环境没有。
我当时傻眼了，由于这个外包是专职安排弄UI自动化，用于上云验证。云上UI前端框架和云下前端框架是不同，也就是页面元素不同，因此测试环境维护的用例，根本没法在生产环境使用。
而后咱们这边因为时间太赶了，接口测试用例尚未更新到云上环境的域名以及调试好。这个失职也是在于我。
致使，咱们此次上云验证，没有跑过一个自动化相关的用例。
简单来讲，等于此次上云，咱们用于回归测试的自动化测试相关的用例及脚本，没有一个。
可是，咱们投入在自动化测试的时间，差很少跟咱们业务测试用例编写的时间趋于一致。
投入与产出是1比0的，结果是惨不忍睹。
咱们4个测试，靠着经久不衰的手法，一路闪电带火花的点点点，来验证系统全部功能是否在云上正常。
一直验到次日上午人家来上班...
假设，咱们准备充分，接口和UI自动化测试用例都遍历了全部功能，咱们也不至于熬了一个整整通宵，也不会这么辛苦，这么累。
失败总结
通过此次项目上云，发现了平时咱们打着自动化测试的口号：降本增效，提升质量。而到了实际要用时，却发挥不出一点做用。固然，这里有不少缘由，有我的，也有团队管理方面的。
可是，抛开缘由不追究，其惨痛结果，反应一个问题，自动化测试是噱头，没价值？
答案是否认的，自动化测试是有意义的，也有价值。
可是，若是你运用和管理不当，它的价值没有发挥出来，将成为一堆废铁，终将百无一用。
试问有多少人，多少公司作的自动化测试(那些BAT、TMD一线大厂里面的测试团队除外，毕竟技术与管理体系已经很是完善)，真正发挥了它的价值呢？
大家有评估自动化测试(包括平台)的收益吗？
如何评估的呢？
真正达到产出高于投入的有多少呢？
学习自动化测试的人愈来愈多，自动化测试在软件测试中已是人人参与的，可是，若是不真正发挥它的做用，大家作的自动化测试，包括测试平台，可能就是：
一、为了体现测试团队的技术(面子)；
二、为了团队KPI；
三、自娱自乐；
四、为了面试，拿高薪；
五、安慰本身；
六、为了装13；
七、盲目跟风，无论有没有价值，先要有这个东西存在；
...
...
综上，也有其余动机和目的，可是，在这里，我想说的是，作自动化测试，必定要在作以前思考不限于如下六个问题：
一、这个项目为何要作自动化测试？
二、什么项目适合作？
三、何时作？
四、作哪些核心业务模块？
五、谁来作？
六、如何作？如何发挥它的核心价值？
其实搞清楚1,4,6三个问题就能够了，最关键的是作好第六点，我想你作出来的自动化测试，确定在项目中获得良好的收益。
最后：
欢迎关注公众号：程序员一凡，领取一份Python自动化测试工程师核心知识点总结！
这些资料的内容都是面试时面试官必问的知识点，篇章包括了不少知识点，其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。