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

  文笔欠佳,如有阅读不适,请见谅!

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

  所以,绝大部分公司都有人在搞自动化测试,甚至有一部分公司有一套成熟的自动化测试体系。你可以把它看成标准化流水线,类似现在讲的 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


↙↙↙阅读原文可查看相关链接,并与作者交流