引言
　　内容已经有了，但是标题想了很久，最终还是决定用这个。简单清楚明了——总结一场失败的自动化测试案例。

　　文笔欠佳，如有阅读不适，请见谅！

　　自动化测试
　　如今，软件测试行业里，人人都在讲自动化测试，人人都在做自动化测试。如果谁说自己不会自动化测试，都不好意思去面试。现在各大公司招聘信息都是必须会自动化测试，一部分公司招人只招测试开发。甚至有些大头公司都不分测试与开发两个职位。

　　所以，绝大部分公司都有人在搞自动化测试，甚至有一部分公司有一套成熟的自动化测试体系。你可以把它看成标准化流水线，类似现在讲的 Devops。

　　这里，我讲的当然是我在公司的一次自动化测试体会。由于保密协议，这里简单介绍：

　　背景
　　公司是一线大厂的子公司，也可以称为合作伙伴。 类似华为旗下的荣耀。公司去年年初，由于业务越来越繁多，所以人员也是疯狂扩展，所以迭代相当频繁，标准是一周一个迭代，紧急小迭代，也有过两三天的时候。有人会说怎么做到的?

　　拼人啊，加班啊。

　　测试团队
　　先说我们测试团队吧，扩展后测试团队人数大概是 40 左右，其中职位有自动化测试，测试开发，性能测试，安全测试。唯独没有测试工程师。因为公司不招单纯的功能测试。

　　有人可能会质疑，那业务测试谁来做？

　　在这里，我们公司业务测试全职测是自动化测试工程师，他们兼任业务测试和所负责业务中的一部分自动化测试需求。

　　而测试开发是专职于测试体系建设中。性能和安全测试有时候会支援业务测试，但是他们也是专职于性能和安全方面的测试，面向全公司所有系统。

　　测试体系发展
　　起初测试团队是没有对测试技术体系思考，大家做自动化测试都是各自做各自负责的业务系统那一块，用的工具与方法各有千秋，编程语言方面大致分两派 java 和 python。

　　这种分散的自动化测试带来的弊端不限于：

　　1、数据无法可视化；

　　2、脚本维护难；

　　3、增加了学习成本；

　　4、易用性、移植性差；

　　5、无法统一管理；

　　...

　　...

　　这种分散的，小作坊形式的很快就不适应快速迭代的需求和市场变化。最核心的一点是，部门领导无法向老板展示数据。通俗的来讲，就是无法向领导展示我们测试团队存在的价值。

　　嘴巴说，谁都会。但是，领导想看数据，那么平台是唯一秀出测试团队工作中沉淀下来的数据的途径。这样有了数据，团队的 KPI 就出来了。

　　你说你天天在测试，天天在做自动化测试，做了多少，效果如何。领导不可能一个个找你们去统计，去查看。不管你脚本写的多优秀，框架设计得多么出神入化。终究没有所谓的正规化平台好。

　　然后，就这么定了。几位测试开发大神，在领导的安排下，经过多番讨论的设计方案，写了一套后台是 Java 的自动化测试平台。这里说明一下，只所以是 Java，因为公司 99% 的系统是 Java 开发。

　　测试平台
　　时至今日，平台已经完善得差不多了，该有的都有，没有的也有了。简单说一下测试平台的主要功能：

　　1、接口测试；

　　2、UI 测试 (app 和 web)；

　　3、性能测试；

　　4、流量监控；

　　5、接口覆盖率统计；

　　6、安全测试；

　　7、代码质量扫描；

　　8、生产发布卡点；

　　....

　　主流的功能就是这些，其他小功能我就不一一列举了。这套平台已经集成了软件测试中绝大部分的测试技术在里面；可以算得上一套标准的流水线了。

　　以前会自动化测试会觉得高大上，现在平台搭建起来了，并且已经维护了 1 万左右的测试用例在上面了。是不是更加牛逼了？

　　答案：我不知道平台搭建后是否真正牛逼了，但是它的建设至少对测试团队的影响不限于如下几点：

　　1、增加了团队的技术含量 (至少领导不会认为我们只会点点点)；

　　2、提高了团队的作战能力；

　　3、提高了测试效率（因人而异）；

　　4、降低了成本 (待查)；

　　5、提高了产品质量 (待查)；

　　6、降低了学习自动化的难度；

　　...

　　上面只列了六点，对于我们测试团队的影响，也算人们口中常讨论的自动化测试的意义。其实还有很多，这里不一一复述了。

　　自动化测试现状
　　平台是完善好了，前面说了，平台已经维护了 1 万左右的接口测试用例，其他数据我暂时没看。显然平台健壮性是毋庸置疑的，易用性也很好，入门简单。

　　那么问题来了，对于迭代频繁的项目，我们在什么时候去编写接口测试用例呢？

　　这种问题，绝大多数的人都知道，常规的回答不限于这些：

　　1、接口测试需求评审了 (绝大多数是没有)；

　　2、什么开发接口开发好了，开发提供了接口文档之类的，我们就可以去平台维护接口测试用例了；

　　3、开发自测通过，代码提交；

　　...

　　...

　　这些回答都很标准，很理想。但是，你有没有想过，现实是很骨感的，就是会出现不限于如下情形：

　　现状一：

　　版本变化得让你根本没时间维护的时候，你只有加班抽时间来维护，而且这种情况只有在领导发话了，大家才会去维护上去。有些人由于业务线确实忙，所以没维护，有些是自己写脚本，根本不想维护上去。当然也有人主动的去维护。

　　针对这个现状，领导又出必杀技，将接口测试用例设计和覆盖率的指标定下来，并且放到 KPI 考核项里去。

　　KPI 你们都懂，这里就不讲述它的作用了。这个大招一放，大家都自觉的去平台上维护了。

　　现状二：

　　现状二就是现状一的延伸版，就是每次版本有新增的接口后，大家为了 KPI 会主动上去维护。然后有一大部分人也仅仅上去维护这次，后面版本接口有变更，也不会花时间去更新已经维护上去的接口。

　　其中原因，有些可能是真正的忙，没有时间。有些可能因为懒，不想去维护。总而言之，测试团队中有一部分人是没有去更新接口测试用例的。

　　现状三：

　　谈到自动化测试的用途时，大家都会记得其中一个是用于回归测试，减少人力投入到版本回归测试中去，从而把节省出来的时间和人力，用于更多的业务测试或者其他测试中去。

　　但是，现实却是，在版本变更中，真正去执行以前维护的接口测试用例来回归测试的人太少了。据我观察和了解，在短期迭代中，上个迭代维护的用例，这个迭代没人会去跑，哪怕只用一分钟的时间。

　　出现这种情况，一方面由于自信，太自信于觉得之前的接口没有变动，没必要去跑，另一方面，时间太短，又要交付测试，功能测好，直接就进入产品&业务验收环节。就把这一步省略掉。

　　当然，还有其他很多原因，这里不细说。结果都是一样，没有去维护历史数据。

　　现状四：

　　自从公司招进外包测试后，现在部分项目测试工作分配如下：

　　测试工程师专门负责设计用例，然后交给外包团队来将这些用例再翻译成测试脚本，这样的做法，效率不低下才怪。

　　首先外包同志不熟悉业务线，直接转化，还是得从了解业务开始。

　　其次功能测试用例直接翻译成自动化测试脚本存在重复性劳动，同时也会出现场景遗漏，场景不可用的情况。

　　总而言之，这种做法收益大大低于投入。

　　正确的姿势是：测试工程师自己就将测试脚本交付出来。对于那些全栈工程师而言，最正确的姿势是：开发人员自己就动手将测试脚本写出来。根据我对微软的了解，微软的 Visual Studio 团队，就是这么做的，他们根本就不区分开发和测试。

　　现状五：

　　谈自动化测试的时候，我们经常会讲到它的优点，其中一个就是降低错误率，发现人工无法发现的缺陷。那么，在这里统计的结果，我们做接口测试真正发现的缺陷是屈指可数，凤毛麟角的。

　　有的甚至一个都没有。当然接口测试本身也是有局限性的，他不可能完全代替手工去发现手工测试的缺陷。

　　这里只讲它的现状...

　　现状六：

　　...

　　...

　　综上所述，还有很多现状，我这里不一一列举，可以看出来，出现这种想象，一方面是由于个人原因，测试的责任和态度。

　　一方面领导要求所有项目都要做接口自动化测试，从来不评估哪些项目适合做接口自动化测试。

　　有点盲目跟风，做了自动化测试就闪光辉，而实际带来的价值，却是 0。

　　还有一方面，也是关键的一点领导对自动化测试管理方面的欠佳，光靠 KPI 来触发是不行的。

　　失败的背景
　　上面已经讲了，目前公司自动化测试存在的普遍问题。

　　现在从我这个小团队来讲，项目要上阿里云，就是系统上阿里云，至于什么原因，就不说了，涉及保密协议。

　　系统上阿里云，当然没有那么简单，所有与系统相关的服务、数据库、中间件、流量等等，相对于迭代版本，这是一次比较大的变更过程。

　　然后，我们测试在里面承担了什么角色呢？

　　自动化测试在这次迁移的价值会是怎样呢？

　　失败的经历
　　项目上云，当然我们测试要保证项目上云后，所有功能都能正常使用。但是切换的那一段时间，你有多少时间去验证所有的功能都正常呢？

　　只有两三个小时，一年积累下来的功能，两三个小时如何验证完呢？

　　这个时候就是自动化测试该上场了。

　　这个项目自动化测试交给外包维护了，是在我们测试平台上维护的，主要是维护 WebUI 功能测试用例。接口测试用例是我们几个在维护。

　　到了那一天凌晨，大家都准备好了，准备上云。然后验证。

　　最后发现，没有维护一个 WebUI 测试用例 (生产环境)。

　　临近上云的几个小时前，我问他维护了多少用例，他说测试环境维护了，生产环境没有。

　　我当时傻眼了，因为这个外包是专职安排弄 UI 自动化，用于上云验证。云上 UI 前端框架和云下前端框架是不一样，也就是页面元素不一样，所以测试环境维护的用例，根本无法在生产环境使用。

　　然后我们这边由于时间太赶了，接口测试用例还没有更新到云上环境的域名以及调试好。这个失职也是在于我。

　　导致，我们这次上云验证，没有跑过一个自动化相关的用例。

　　简单来说，等于这次上云，我们用于回归测试的自动化测试相关的用例及脚本，没有一个。

　　但是，我们投入在自动化测试的时间，差不多跟我们业务测试用例编写的时间趋于一致。

　　投入与产出是 1 比 0 的，结果是惨不忍睹。

　　我们 4 个测试，靠着经久不衰的手法，一路闪电带火花的点点点，来验证系统所有功能是否在云上正常。

　　一直验到第二天上午人家来上班...

　　假设，我们准备充分，接口和 UI 自动化测试用例都遍历了所有功能，我们也不至于熬了一个整整通宵，也不会这么辛苦，这么累。

　　失败总结
　　经过这次项目上云，发现了平时我们打着自动化测试的口号：降本增效，提高质量。而到了实际要用时，却发挥不出一点作用。当然，这里有很多原因，有个人，也有团队管理方面的。

　　但是，抛开原因不追究，其惨痛结果，反应一个问题，自动化测试是有意义的，也有价值。

　　但是，如果你运用和管理不当，它的价值没有发挥出来，将成为一堆废铁，终将百无一用。

　　试问有多少人，多少公司做的自动化测试 (那些 BAT、TMD 一线大厂里面的测试团队除外，毕竟技术与管理体系已经非常完善)，真正发挥了它的价值呢？

　　你们有评估自动化测试 (包括平台) 的收益吗？

　　如何评估的呢？

　　真正达到产出高于投入的有多少呢？

　　学习自动化测试的人越来越多，自动化测试在软件测试中已经是人人参与的，但是，如果不真正发挥它的作用，你们做的自动化测试，包括测试平台，可能就是：

　　1、为了体现测试团队的技术 (面子)；

　　2、为了团队 KPI；

　　3、自娱自乐；

　　4、为了面试，拿高薪；

　　5、安慰自己；

　　6、为了装 13；

　　7、盲目跟风，不管有没有价值，先要有这个东西存在；

　　...

　　...

　　综上，也有其他动机和目的，但是，在这里，我想说的是，做自动化测试，一定要在做之前思考不限于以下六个问题：

　　1、这个项目为什么要做自动化测试？

　　2、什么项目适合做？

　　3、什么时候做？

　　4、做哪些核心业务模块？

　　5、谁来做？

　　6、如何做？如何发挥它的核心价值？

　　其实搞清楚 1,4,6 三个问题就可以了，最关键的是做好第六点，我想你做出来的自动化测试，肯定在项目中得到良好的收益。

欢迎大家来点评，来吐槽一下，也想知道各位做的自动化测试是怎样的，到达什么程度，获得怎样收益。

另外，此篇文章来自我博客：https://blog.csdn.net/liudinglong1989/article/details/108899513