天猫技术专家:测试十二年,能否找回初心

发表于:2018-11-20 08:51

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:高翔    来源:简书

  很久没写文章了,之前测试十年,也是在自己有变化的时候 ,强迫自己写了一篇文章,说了自己的困惑和痛苦和思考,也得到一些共鸣。现在测试十二年了,相当于一个轮回,也有一些新的痛苦和感悟,趁还在这个圈子里面,纪念一下,当然了,YY比较多,干货也不多,反正纪念下,或许我是真的不太可能写测试15年的文章了。大家有任何问题,欢迎讨论,欢迎吐槽。
  其实写这篇文章之前,我一直是犹豫的,感觉写不出啥花样来,一是因为水平有限,另外就是因为测试这个圈子里面说不出啥新花样出来,还是老生常谈的那些,而且不同水平的读者想看的内容也不一样,很难写的深入人心,反正真的差点放弃了;但是我内心是渴望的,想说些那些不一样的,了解我的人都知道,我是不甘平庸的,是有自己的思考和底线的,很多时候可能被现实打败,但是我还会站起来,继续战斗。
  12年 / 这两年我干了啥
  我是一个很怀旧的人,简单说说这2年干啥了,这两年做天猫新零售的业务,这是一个新业务,大家应该理解新业务的背后的意义吧,我这里就不赘述了,团队成员都非常给力,拿到了不错的结果;其实大家都知道,测试在一个业务的发展过程中,自己能起到了哪些作用,不管这个业务是发展了多长时间,我们都是会经过三步走,很多时候我们就是在平衡这三步的比例和深度。
  【质量】
  测试人员核心的产出,发现bug,提升产品质量和用户体验,尽量少的把bug遗漏到线上去,让用户或者监控发现;是的,这两年来,对于一个新业务来说,我们在这么多、这么变、这么复杂的需求和迭代项目中,我们拼劲了全力,新业务的质量有了稳步的提升,线下bug的数量、线上bug的数量和趋势、系统的稳定性等各个角度来看结果,都说明了我们真的不错,是的,这是我们的基本工作,也就那样吧。
  【效率】
  对于一个新业务,对测试效率的要求也是更加考验,新零售是链接线上和线下、商家和消费者之间的桥梁,我们在测试效率上也是面对很大的考验;是的,这两年来,对于一个新业务来说,我们在这么多、这么变、这么复杂的需求和迭代项目中,我们继续拼劲了全力,新业务的研发效率有了稳步的提升,开发自测质量提升、初级bug、ISV对接效率、全网回归效率、10+测试数据工具等各个角度来看结果,都说明了我们真的不错,是的,这好像也是我们的基本工作,有了一些进步,还不错的,不过也就那样吧。
  【技术驱动业务】
  你是开玩笑吧,是的,我没有开玩笑,对于测试来说,驱动业务简直是难如登天,开发是天生的,测试是后天养的;天猫智慧门店在线下业务的拓展过程中,我们对每一个商家、每一个线下门店都会有质量的责任,我们经历过双11,经历了痛点。是的,这两年来,对于一个新业务来说,我们在这么多、这么变、这么复杂的需求和迭代项目中,我们再次拼劲了全力,我们在商家业务配置检查、商家ISV验收、线下门店预演等一系列的结果上来驱动天猫新零售商家和门店的规模化发展,我觉得我们是技术驱动业务了,为业务高速发展提供了保护伞,都说明了我们真的不错,是的,这好像也可能是我们的基本工作,有了更多进步,还不错的,不过好像技术含量比较低,扩展性一般,其实也就那样吧。
  好吧,刚刚都是自夸,看不下去了吧;其实我想说的是,这两年,我们做的还不错,各个层面都有结果,特别是第三个层面的,有的时候是可遇不可求的,总体上团队能力和技术都有提升,但是在某些结果上的确不让人满意,我们的一些测试大佬们既要、也要、还要、反正什么都要,你要是哪个没有,不好意思,只能这样了。说实话,我有时候也能理解他们,真的理解。
  12年 / 国内测试都在关注啥?
  这个话题有点大,其实真的不敢写,但是无知者无畏,虽然在阿里干测试9年多了,自我感觉蛮了解的,比起”阿里测试都在关注什么”,我觉得我更敢写这个,其实也有点心虚的。这些年,我一直专注在我们自己的业务和系统、测试问题,这些细节非常多,我们的目标和规划都围绕这个来,非常接地气;是的,说这个就说明我对国内测试在发生什么,在追求什么,其实对细节了解不多,但是在微博、在大会的主题、在相关的ppt和群讨论中,还是能感知到一些的,接下来就说说,很多理解不一定对和全面的,欢迎大家补充讨论。
  在正式的说之前,大家回想我之前说的一句话,我们干测试的,很多时候就是在平衡这三步的比例和深度,在质量、效率、驱动业务上不断的调整策略和战术,根据不同的业务阶段、根据不同的目标、根据当前的大事件驱动等。
  我们最怕干的是就是平衡,因为平衡的好,前途光明,平衡的不好,万丈深渊。大家都知道我们干测试的,杂活特别多,很多事情都需要投入一点,很多事情做起来很多人看来也没有亮点,那我们很多时候就是在不断的平衡一些事情,但是不管怎么样,我们的目标还是比较聚焦的,就是对应自己的业务和开发技术,以及未来的业务发展,在质量和效率上如何做的更好,成本上越来越低,解决方案也越来越有技术含量。
  大家都知道,不同行业对应测试的要求是不一样的,那么测试技术和要解决的问题也是不一样的,但是有几个套路其实是差不多的,大体上分这几个方向。
  1. 基于模型的测试:这块领域很多人不太熟悉,而且在不同的行业的实践和效果是差异比较大的,但是不能否定这个方向带来的价值,在通讯、IOT、嵌入式等领域都有非常多的实践,效果也不错,我认为是测试前移比较重要的一块;但是很多人对于这块只是基本的了解,很多时候都有可能直接放弃;最后的结果,可能是我们的开发同学先开始业务建模,先开始各种模型抽象,提升开发效率,然后再到测试的模型和效率提升,很显然,我们是被动的,而且很多时候我们错过了一些风景,可能感知不到呢。
  2. 可测试性:这块话题,其实是大家聊的比较少的,因为很多方面是偏理论的,真正落到实践到项目过程中,和业务项目的技术架构、技术能力、技术人员思维都有比较大的关系;而这块对于大公司是比较看重的,特别是微软、google级别的重视技术体现的公司,我们作为测试开发工程师的重点是从开发角度去做测试工作,会把主要精力投入在系统设计和编码阶段。开发人员关注某个功能最优实现方案,而我们测试要有整体产品的视野。所以测试在设计阶段,帮助开发人员完成代码复用和模块交互方面的设计,在设计review的时候,保持目的性:完整性、正确性、一致性、设计、接口与协议、测试(可测试性)。还有一个明显的,就是做这块,需要沉下心来,慢慢积累和思考,对于很多急功近利的公司来看,绩效和沉淀方面难说了,而且这块的确是我们测试的短板,接下来我觉得还是有可能会重新重视起来。
  3. 自动化测试:这个是很明显的提升测试效率的手段,这里面不同的行业的自动化测试策略和框架也可能不一样,但是的确是互联网企业发扬光大的,包括分层自动化测试实践,其效果也是非常显著的,不管是什么行业领域,都是逃不掉的;不管你是采用流量录制和回放、页面录制和回放、关键字驱动、数据驱动的自动化脚本运行,这些经验和沉淀目前也是国内的公司强烈关注的,为什么非要关注这块,说实话,这些能带来XX平台的沉淀,XX平台的开发和技术品牌、XX平台的能力透出;如果我们加上功能依赖分析、系统依赖分析、代码覆盖率等各个因素的影响,我们可以加上精准测试的方向,进一步提升自动化测试效率,这块上国内有一些公司都在沉淀和探索,也有一些不错的结果。
  4. 灰度&监控:这块话题,是测试右移的核心思路,基本上也是互联网和移动互联网企业的测试策略的标配,测试和开发一起共建,来加强灰度的落地,监控覆盖率和提升;但是测试在其中的体现到底多少,价值多少,这个就很难说了,我们的沉淀的方向到底是什么呢?我们开发有没有加上这块的监控、开发为什么没有加上这块的监控、我们测试是不是要监控开发是否加上了某块的监控、我们测试是不是要来Review开发是否加了某些监控、监控的方法和策略的沉淀开发和测试的关系在哪里。这也是测试自己没办法的策略,很多时候我们不怕出现线上bug,我们就怕不能快速fix bug;我们就怕我们的系统监控没有发现这样的线上bug,反而让客户主动报了相关线上bug;但是这个策略是不是唯一的,依赖它的程度到底是多少,我们测试线下需要做到什么样的程度,又是一个平衡的问题了,这块上,我们可以再思考多一点,想想测试在这里面的定位是什么,是和开发绑在一起,分享系统稳定性的结果,还是思考它对于测试体系的位置到底什么样的。
  5. 大数据测试:有两种情况,一种是大数据产品的本身的测试体系的建设,包括常态化的测试策略和大数据的数据监控策略,这里面的监控可能是测试工程师的重点产出;另外一个情况是利用大数据的手段来提升测试效率,来监控线上质量,反过来驱动线下测试覆盖率和效率。第一个应该有比较成熟的体系了;第二个也是在探索阶段,对于产品特点、体系架构有一定关联,同时配合多个手段来提升,如果加上某些机器学习、和算法、精准测试策略、可能会包装成AI智能化测试,解决大数据量情况下的功能测试问题。但是这方面可能不仅仅是测试这个领域,包括运维和体系化架构设计等一个闭环的打造,测试其中启到什么关键的作用,还是值得期待的。
  6. 探索式测试:4-5年前比较火,目前基本上是冷却了一大半了,现在是邰晓梅老师一个人独立坚守着,在国内各个公司和线下活动不断的布道和实践,目前来看,国内的很多公司都有了解和参与,在测试的本身价值上,测试本身的能力建设上还是有很多的进步的,这些对于持续在测试能力上有特定思考(包括和敏捷测试的结合)的同学,他们的体感会非常强,但是对于一些开发技术为核心套路的可能觉得偏理论,不够技术含量,很难继续深挖,很难形成平台化效应,是的,我本人也是最近几年都没有在这方面进行学习和探索,很是愧疚和遗憾,但这就是现实。
  总体上来看,国内测试技术和方向也是解决部分的问题,还有些可能是大趋势中找到自己的位置,到底有几分是自己独立思考的,有几分是在真正的研究和探索的,目前看到的不多,很多都是在围城里面走套路,大家一起走,反正现实有很多的问题需要解决。另外就是很多行业领域里面的测试技术探索,比如游戏测试领域、IOT领域、AI领域、区块链领域、三方生态领域等。
  12年 / 国外测试在走什么方向?
  好了,我们的所有测试技术和方向的探索,国外基本上前几年都已经开搞了,有些领域可能领先十几年,有些大家都在同步探索阶段。我们需要更大视野去看国外测试技术和体系的发展,不仅仅是某个框架或工具的角度去看,甚至不是某个行业的测试解决方案来看。我们知道某一个技术的开始和发展,不仅仅是和企业的工程领域有关系,很多时候和学术领域有关;国外测试领域里面包括很多学派,它们分别代表了不同的测试领域的思考和沉淀,不仅仅是不同的测试类型,还包括很多测试理论上的思考,包括自动化测试学派、质量保障和规范学派、上下文驱动学派、开发测试学派等,每个学派都有自己主张的观点、方法、实践方案、工具体系等,而且每年都是有序的讨论和发展(有那种百家争鸣的感觉,在工程和学术领域同步开花结果);在这里,我们在看看一个很明显的区别点,国外的测试大会上和国内的测试大会上的topci就可以看到一些区别了。
  这里面有一些共性的topic包括敏捷测试、Test in ops、性能测试、监控、安全测试、自动化测试、国际化本地化测试;但是国外的很多topic是强调测试本身的思考的,包括测试信息输入论、探索式测试、基于风险的测试、测试管理、测试策略和计划、某领域的测试设计方法。这里,很多人其实都看到了不同点,国内这方面的沉淀相对来说少很多,很多人都不感兴趣的,觉得都是理论的多,对我的技术没有帮助。
  另外一个层面来看国外测试就是测试大师们,国内从事一线测试工作的工程师基本上10年以下的,10年以上的基本上都是管理的、或者走其他路线了;持续在某个领域进行测试技术体现的研究在国内很难找到,但是也是有的(陈能技、朱老师、领测贺老师、CSATQB周老师、阿尔卡特郑老师、顾问邰老师等等,这些老师很有可能和其他些人观点非常冲突,互相不被认可),整体上来看还是缺少很多的,大部分人对于测试生涯、测试价值、测试发展、测试方向都有一种悲观的预感。反看国外测试工作10-20几年的测试大师们非常多,他们在测试本身价值上进行了非常多的思考和沉淀,一点点形成自己的思考和理论,一点点去实践自己想要的测试方式和思路,感兴趣的同学可以去多看看国外的测试论坛,你肯定会看到不一样的测试理解的,好了,我也好久没看了,赶紧补课去(对绩效啥好处都没有,我真的要看?)。
  12年 / 测试生涯还剩多少?
  我们先讨论一个热门词语“测试开发工程师”,大家可以思考下为什么不叫"开发测试工程师"呢?大家都知道的是未来开发测试是融为一体的,很多一些外企也做到了,开发测试的融合,互相backup,互相对产品质量和稳定性负责,其乐融融的感觉。说实话,最近几年我对外企里面测试的理解不多,这里不敢多说,怕说错了;但是国内的测试里面,大家其实都能感觉到,那就是我们更多的在关注我们是不是会写自动化测试脚本,会写java代码,懂很多开发技术,做过很多平台或工具等。这里面的技能重要不重要,当然重要了,但是不是我们考察一个测试开发工程师唯一的思考点呢;我们的批判性思维、我们的打破砂锅问到底的精神、我们的错误猜测的思路、我们的细心专一的用心、我们的异常逻辑判断的方法、我们的流程优化的意识等等,这些我们到底有多关心呢,不好意思,不怎么关心,因为干了这么久,干了这么多,看不到产出、说不清投入、显不出能力。
  我们再分析下,我们测试开发工程师要干的事情到底哪些呢,之前就是说过了,保障产品质量和提升研发效率,这两块我们的投入的比重呢,这两块我们看结果的思路呢,这两块我们要沉淀的方向和方法的抽象呢?这些说实话,大家看到的都很少,我自己也是一样。说直白了,未来测试工程师会越来越少,质量很多时候都是开发去负责、或者其他灰度监控手段去避免,那意味着我们在质量上的投入会越来越少,在效率上投入会越来越多,其中的道理大家都应该理解的吧。
  当我们第一眼要追求的是效率问题时,我们更多的关心开发技术的提升,以及开发技术在解决效率问题时的应用,因为这些价值是显而易见的,是被高度认可的(对于无线适配测试平台,阿里每个大BU都有,起码6-7个平台,但是80%的功能是一样的);我们打着效率提升的口号,似乎也能解决质量的问题,但是扪心自问,真的能解决吗?大家知道自己产品的用户是怎么用我们的产品的吗,我们的用户遇到了哪些问题吗,每天都暴了哪些线上bug给你吗,其实很多时候,我们都是不敢正视这些问题的,因为我们会被彻底打败,太丢人了啦。好了,我知道了,测试不可能测试全面的,那样成本也是非常高的,我们还是快速发布第一位的。因为我们不能真正的去面对这些线上bug,所以大家有真正的去思考线上bug遗漏的真正原因吗,有多少是从测试设计角度去思考的,更多是从监控、fix效率等角度来加强和避免。
  当我们去加强测试工具的开发、测试平台的建设、监控平台的建设时,我们测试开发工程师还剩下什么?我们只能做这些事情吗?难道就因为这些能拿到好的绩效、能体现你的技术能力、能快速晋升?好了,不能说太多了,这里有可能会带来吐槽。其实我不反对这些事情的价值所在,我只是想想我们在干这些事情的时候,有没有去思考测试本身的核心定位,测试本身的经验教训到底是什么?

  上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。  
21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号