效能度量 自动化测试实践总结

隔壁老牛 for TesterHome北上广深测试圈 · 2020年11月03日 · 最后由 剑玄 回复于 2020年11月09日 · 520 次阅读

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

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

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

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

共收到 30 条回复 时间 点赞

项目要上阿里云,就是系统上阿里云,至于什么原因,就不说了,涉及保密协议。

骗补?

楼主说的透彻,就是为了薪资 搞这些

但我一直以为只有小公司才会这样。大公司应该有很好的管理制度及流程。怎么说楼主应该也是一线大厂,不至于这么混乱。

应该仔细想想 “为什么你们的自动化发现不了问题”,
搞清楚了这个问题,一切疑惑 就都烟消云散了

666,这就是瞎忙,让你们看起来很忙,有逼格,实际产出贼少。总结起来,要有一个对自动化有了解的领导,然后知道什么场景可以用,要做什么自动化,有哪些是可以评估产出~总之多磨一磨,镀金,并且从你反思来看。。。。。。你懂的,哈哈

为啥切换环境之后前端框架还能不一样,这个没提前跟开发沟通么,然后 web 自动化没跟前端约定一个元素定位规范么?

解决痛点才是关键

深有同感,UI 自动化的难点一直都是在实际落地上,从沟通到部署,再到迭代维护,再到如何让它的影响力尽可能的渗透出去,让功能测试同学拥抱变化,让开发同学信任测试结果,中间要做的事,要克服的困难太多了,而这些困难基本都是人的原因造成的。纸上得来终觉浅大抵如此。

自动化后要有持续集成。至少每天跑一次。

1.测试工程化大部分情况下和学校差不多,不会投入大量人力去做工程抽象和兼容易用的问题。
2.价值问题,创造价值难度巨大。用的人多才会有价值,这是最难的最难的。
3.技术视野有限,测试技术和行业、开发工具链强绑定。通用的价值不大,专用的很难做,或者说是不知道怎么做。

前几天还在脉脉上怼过一个 P7 快升 P8 的兄弟。工具做到跨 BU,和后端绑定才有价值。就不可能是 UI 这个层次的。
我是一只菜鸡,大家不喜欢轻喷。。。

没有接触过正规的自动化测试。目前在公司就 4 个测试人员(其中我和另一个兼职做运维),只有我一个人编写一些 UI 自动化,用 python+selenium。目前作用主要是用于跑一些测试数据或者说流程(比如我要一个功能,前面有很多步骤要走,我就会用自动化先跑前面的流程)。目前我觉得自动化对我的帮助就是这些,但是由于没有大佬带过,又没人请教都是自己摸索所以还是挺迷茫的。不知道大厂的自动化到底是怎么做的,有什么作用。

大厂业务多吖

这种分散的自动化测试带来的弊端就是:1、数据无法可视化;2、脚本维护难;3、增加了学习成本;4、易用性、移植性差;5、无法统一管理;

为什么 2、3 和 4 的问题会是分散的自动化测试带来的?二者并无直接关系,可以详述吗?

我不知道平台搭建后是否真正牛逼了,但是它的建设至少对测试团队的影响有如下几点:
  1、增加了团队的技术含量 (至少领导不会认为我们只会点点点);
  2、提高了团队的作战能力;
  3、提高了测试效率(因人而异);
  4、降低了成本 (待查);
  5、提高了产品质量 (待查);
  6、降低了学习自动化的难度;

从前文来看,你们的自动化测试平台只是用来方便自动化测试运行和统计用的,跟你总结的 6 点都不沾边啊。尤其是 4、5 和 6 这 3 条,这不太可能,怎么可能通过你们这样的测试平台得到这样的结果呢?

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

之前 “分散的自动化测试” 的时候,大家是不是也因为这些原因不去维护接口测试用例?如果之前大家都很积极主动去维护,那么是不是应该反思:这个自动化测试平台是不是反而降低了大家的工作积极性?

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

自动化脚本的实现和维护都付出了相当大的成本,却没人真正去执行,这不是暴殄天物嘛!你们可以设定自动化测试任务按条件触发或定时自动运行。

测试工程师专门负责设计用例,然后交给外包团队来将这些用例再翻译成测试脚本,这样的做法,效率不低下才怪。
首先外包同志不熟悉业务线,直接转化,还是得从了解业务开始。
其次功能测试用例直接翻译成自动化测试脚本存在重复性劳动,同时也会出现场景遗漏,场景不可用的情况。
正确的姿势是:测试工程师自己就将测试脚本交付出来。

这种体现分工思想的做法其实是可以提高效率的。
首先,这种分工,外包团队就不需要熟悉业务线,因为用例测试工程师团队专门负责设计。
其次,这种分工,怎么会存在重复性劳动,同时也会出现场景遗漏,场景不可用的情况?应该是可以避免才对。
正确的姿势,既可以是测试工程师设计用例并实现自动化脚本,又可以是不负责设计用例只实现(翻译)自动化脚本。

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

自动化测试目的不在发现缺陷,而在回归。你们没有怎么发现缺陷会不会是迭代版本没怎么对已有功能造成影响,换句话说这也是开发团队能力强的表现?

文章中描述的失败经历里的那一段感觉挺那啥的, 测试 repo 里维护不同的分支以应对不同的版本和环境是最基本分支管理策略,怎么会在这种地方出问题呢。 正式员工设计测试用例,外包人员写脚本这个也挺迷的, 这都是多少年前的操作方式了。 而且外包人员本身的能力就非常有限, 怎么可能会写出好的代码呢, 没有好的代码设计又怎么能快速的兼容需求变化呢。 把覆盖率当成 KPI 也挺魔幻的, 大家都知道覆盖率就是个参考,不能作为主要的考核目标。 我们这边评估自动化最主要的指标是减少了多少的人力成本。 比如我们我们一条产品线上执行一遍全回归测试需要这里所有的 qa 一块上,执行一周时间 (机器学习产品,TO B 业务, 产品庞大,业务复杂), 我们在积累了 2000 多条 UI 自动化后,这个时间缩短到了 1 天。 提升了多少效率才应该是我们评估自动化的方式。

这是一种恶性循环,一开始就没有用好的方式和有足够能力的人去做自动化, 后面就会导致效果越来越差, 脚本越来越难维护,最后就是把这玩意当成 KPI 了。

鄙人一点愚见,没有专职维护 UI 的人,或者业务太忙来不及维护,就将主流程实现下。每天跑一次来作为监督, 剩余的精力搞接口自动化就好了。 当然接口自动化维护的时候最好做到密切关联,比如测试环境你购买商品,id=222,那么正式就不一样了,所以要去商品列表接口获取。以此类推,接口测试才能在正式、测试环境无缝切换

小酷 回复

前端整个框架变了,上云前要按阿里那一套搞。符合公司标准后才可以上。

有个很大的疑问,为啥上云之后环境还能不一样?真的,太奇怪了。
另外,自动化用例,一万条用例,你们执行时间是多少?UI 可能会慢点,你接口用例?这时间应该是很短的吧?

领导一般年龄大或者不懂自动化,只是道听途说某某大公司自动化节省多少成本,然后只要一需要人就想自动化来节省成本,这种事情还是挺多的,无论适不适合自动化

说实话,有些项目真不适合做,强行做,基本做着做着就成了摆设。

而且自动化测试也是个产品,开发一个产品,规划、资源、跟踪反馈、运维缺一不可。

抱着学习的态度做自动化测试更是要不得。。。

楼主看的真是透彻。

😁 可能这就是很多公司自动化的现状吧

自动化做久了,才明白一个道理:别管什么乱七八糟的初衷和目标,做自动化测试离不开一个词——提效。
编码这个东西,拿出来就是提效的,机器代替人工。
本着提效的目的去做自动化才有价值。提效之后,我可以多 “摸鱼”,提效之后,我可以早点下班……
当然,提效这个敞开说,又是另一个话题了。没有提效思维,自动化做出来也不尽人意。

楼主的理解深入,确实是长期奋斗在一线的大佬。 很多内容都深有感触和认同!
之前很多公司的自动化 就是人手一套,什么都不统一,也没法量化,完全是自娱自乐,良莠不齐,结果无法让人信服,也基本看不到自动跑出来的 bug,每次上线前都是自动化回归完毕,然后上线还是漏掉问题。
-- 这属于典型的 自动化第二阶段。
所以为了统一,为了降低人员更换成本,学习成本,开发成本,我建议进入到第三阶段- 大型平台集成化。
楼主说平台上有上万条用例,想都不用想,肯定是接口用例。如果是上万条 ui 自动化的用例这个基本不太可能了感觉,光是维护都维护不过来。
-- 所以我也建议,可以考虑进入第四阶段,AI 机器学习~
根据大数据/深度学习/无限矫正的特点,降低开发和维护成本,降低自动化人员风险在其中的影响。

关于为什么要打造自动化,或者说平台。确实对于每个公司每个组织每个人来说,目的都不单纯。
其实所有人都明白的,只是这是一个共同的泡沫,存在就是有原因的。

1.最简单的思路是完成开发提的需求。
2.冒烟测试 跑完标记出哪些跑了哪些没跑,一开始需要验证是否是自动化问题,做了一定累积和自动化返回数据定义后。
就可以慢慢信任。
3.挂钩子提交后,多条分支版本是否可以拉起来,到哪里是通的(用例上体现)。
有时候推广和维护都是心血投入,不是只是开发完就算了。

感觉后期的维护更新也很重要,并不是搭建完框架写完一遍用例就完事了

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册