开发转测试,坚持16 年,转型并没错!

Posted 软件测试小dao

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了开发转测试,坚持16 年,转型并没错!相关的知识,希望对你有一定的参考价值。

在这里插入图片描述

“去 QE 时代,测试开发者该如何迎难而上?”

我为何从开发转测试,并坚持了 16 年?

我们聊到自动化测试,我们做 GUI 自动化测试的过程当中,以前就只要把这个自动化做起来就好了,但随着你的用例,用的数量越来越多之后,你不单单是把一个场景自动化就可以了。因为随着你的用例变多之后,你所有的用例设置,包括你的代码的结构,都要考虑这个东西的可维护性,因为可维护性一直是 GUI 自动化测试很大的一个痛点。我们在后面的 GUI 测试过程中,就会去考虑,怎么来做分成?怎么来做基于可重用的脚本?怎么来做基于页面的对象模型?甚至到后面还有 BDD,就完全是业务,用户行为驱动的这种测试。那么,从这些概念当中,可能你已经听出来了,不管是你之前有没有接触过这些概念,你都能够发现一个很重要的信息点,自动化测试没你想的这么简单,也完全不是一个简单的录制,或者回放。

所以说,我自己当时在转型的过程中(从开发转向测试),我就是看到了这些点,觉得这里面的学问,或者说可以做得东西,尤其在当时的大环境下,是非常多的。因为当时没有人去做这块,而且当时是没有有开发经验背景的人会去专门做这一块的东西。我也是看中了这样一个机会,后来事实证明,转型并没有错。

随着时间的发展,后来就越来越证明整个自动化测试到后期的一些基于 API 测试,或者现在很多一些新的测试技术越来越多,而且整个测试地位也越来越高,从早年的并不受重视,或者是一些比较弱的开发去做测试,到现在一个优秀测试工程师可能是比一个开发人员更懂开发代码。因为如果他不懂代码,或者不懂开发是怎么来做得,你让他怎么去发现开发当中的一些问题?这个过程是相辅相成的。

其实我们很多测试已经分为了三大块。

一块是 所谓的传统意义上的基于业务功能的测试, 基于手动测试,或者现在非常流行的,基于探索式测试,也就是说基于一些错误猜测,以及基于一些你做了哪些测试,你假定哪些地方有可能会出错,而且做进一步测试,这样一个过程,所以说这是一部分做业务测试的同学。

那么 第二块是做自动化测试的同学, 自动化测试的同学对业务了解程度并不是很深入,但是他所做的事情是把一些手动的脚本,很方便得把它翻译成一些自动化的脚本,可以让机器去执行,那么他的主要技能是主流的一些 GUI 的 Framework,比如说现在主流的像 Mobile 端的可能就是 API,或者是不同框架的这种自动化开发技术,这是第二类。

第三块是很大的一块,就是现在意义上的叫测试开发。 测试开发并不是传统去做自动化用例的开发,他会去做一些测试平台、测试服务,或者一些测试基础架构的开发。你可能会问,这些基础架构包含什么东西?我可能举两个例子,你可能就知道了,你现在要跑测试,你要跑一个 Web 端的,或者跑一个 API 手机上的一个 Mobile Native 的 app 测试,你肯定一定要有执行环境,你如果是手机端的,你一定要有手机,要有安卓的 Device,或者有 ios 的 Device,去让你跑这些测试,那么这些手机你怎么来?单个来拿吗?你肯定会去建一些机群,甚至建一些私有云,像国外的 Lab 服务,其实包括国内的一些其他服务器,类似云测的服务,就是把这些设备集中在一起。

那么这部分工作是谁做的?就是现在的测试开发去做。

软件测试对于学历的要求高吗?

反问下大家,你在学校里面学的东西是什么呢?你真正去看,学校里面出来,你上了工作岗位之后,学校里的东西立马能用的有多少?我觉得基本上是在 10% 以下的,所以说我觉得学校里面学的是什么呢?我个人认为更多学的是一些思想方法,就是说你面对一项新事物的时候,你会用什么样的方式,如何在很短的时间内用自己的方法,把整个这件事物的来龙去脉搞清楚,并且你能够接受它并且你能够运用它,这是个很重要的点。

所以说跟学历没有必然的关系。像乔布斯这种公司,它不注重你的出生,或者你是从哪个方面去做这个事情,他看中的是你的思维方式,你的能力。 这又让我想到另外一个点,现在讲到面试,我个人是十分反对刷题的。 因为我们碰到过一些同学,面试过程中,你给他一个算法去做一下,如果他能立马给出一个最优解,那这个肯定是有问题的。因为我的理解,正常的情况下,你不可能一下子就找到这么一个非常好的最优解,你能找到这个最优解的前提一定是你之前看到过这样的算法,或者是你看到过这样一个最优的解法。

我们想看到的是一个什么样情况呢?你不是给我一个最优解,而是你给了我一个方法,这个方法不一定完美,但在我们的引导下,你逐渐把它完善,逐渐发现你这个算法的问题在哪里,哪些地方可以去做更多的改进,然后把这个算法逐渐变完美。 这个是我们想看到的,我们是想看到的是你在面对一个有挑战事物的情况下,你是怎么把一个大问题化解成一个小问题,每个小问题又是如何去解决,最终解决这个大问题,解决了这个大问题之后,再去回顾一下,你在解决这个大问题的过程当中,有哪些地方是可以改进的,是可以优化的。我们是想看到的是这种过程,所以是这样一个情况。

去 QE 时代,测试工程师该如何修炼?

首先我想先解释一下,什么是“去 QE”。“去 QE”这个概念在国内还是非常新,但是在一些像 Facebook、Google、Ebay 这样的公司,已经都在做这些事情,而且有很多都已经真正落地了。首先我先表明我的一个观点,我并不是“去测试”这样模式的推崇者,因为去不去测试根本的原因不在于说,你觉得能不能去,而是完全取决于你的组织上下文、你的组织成熟度、你成员的水平、你工具的成熟度、你的体系、你的上下文、你生态的成熟度。

那为什么 Google 能做?

因为 Google 拉任何一个测试工程师出来,直接去做开发是没有任何问题的,但在国内,你让测试去做开发通常是比较难的, 所以你面对的上下文、面对的环境,差异性就非常大。这种情况下,你说去 QE 一定好,或者去 QE 一定不好,都是没有一个定论的。

我的观点在于,并不是一定要说那个好,而是我们应该面对一个特定的项目,或者面对某一个组织,我们怎样去两边取各自的长处,两边去各自的短处,有机地结合在一起。这也就是现在所谓的“去 QE”,就是“没有测试工程师,开发自己做测试”这种架构。

那么哪些情况下是适合让开发自己去做测试的?哪些情况下还是需要一些专业的测试人员来做测试的?

传统的测试策略,更多的是一个金字塔模型,也就是说 UT 会做的比较多,中间层,像 API 的集成,或者是集成测试会做的相对少一点,最上层的 UI 一般是更少,是个轻量级。

但在现在互联网的时代,尤其是一些去 QE 的公司,他是怎么玩儿呢?他会把整个三角形变成一个类似于菱形这样的一个架构,也就是说 UT 这块是非常的少了,中间层,API 这一层,由于微服务化,这层会非常的厚,上层的 UI,会做的相对比较少,而且更会去做端到端的,面向对终端用户的这种测试。除此以外,这个菱形的顶上还飘了一朵小的云,这朵小的云就是现在非常流行的 ET,也就是所谓的探索式测试。

没去 QE 之前,整个架构是金字塔,底部 UT 是开发做,API 测试跟 UI 测试都是测试人员来做,但是在去 QE 之后,是什么样的一个架构呢?UT 开发做,API 测试也是开发做,UI 测试还是开发做。 唯一是测试人员可以做的是哪里呢?是顶上飘的那块小云,也就上面那个 ET,探索式测试。 因为这一块需要更多的是一些发散性的思维,而且需要你对业务有非常好的理解。这还需要你除了理解业务外,还要明白产品内部的一些实现,以及它的架构,才能比较有针对性的去做一些探索性的测试。在这里插入图片描述
面对这样一个大的变革,你可以看到有点类似于把测试上移了,就是你原来的测试工程师只是做上面的 ET 部分,但是原来的那些像下面的 API 测试,或者 UT,或者基于 UI 测试,这些测试谁做呢?由开发做,但是由开发做不表示这个活没有,测试这个活还是在的,只不过是换了一批人去做这个事情,本质上并没有根本性的变化。根本性的变化就在于可能从组织架构的角度来看,现在可能不再有集中的一个测试团队了,这些负责测试业务的测试工程师会打散到各个开发团队里面去,而且他承担的角色也不一定是全职的测试,他有可能会做一部分开发,也会去做一部分的测试

开发人员哪有那么多时间测试?

这是个非常好的问题,也从两个点来讲,就是开发很忙,开发最大的价值在哪里?它是开发功能,这是它的核心价值,测试不是他的核心价值。 那么以前为什么说开发不做测试,没有问题?因为后面是有测试帮你做的,你的工作范围不包含测试,也就是说你在打分的时候,你所有的绩效是不把测试的工作量算进去的。测试的工作是由后期专门的测试人员去做的。那么现在开发去做测试,他就会把测试这部分工作量算到它的打分里面,也就是说测试的工作量是算在了开发上面,那么势必就会让开发的工作量就会变少了。

第二个点,以前测试人员做测试的时候,测试有很多辅助的东西,其实开发人员并不知道,比如说测试执行环境,还有去搭建测试执行环境, 比如说你拿到一个包,这个包你要去部署,你怎么先把这个包部完,然后才开始测试,就简单来讲就装环境。当时这种模式下,这种协调都是测试人员自己去做的,因为测试人员天天在做这些事情,他对跨 demo 非常清楚,他知道这些数据怎么来,并且这些数据在每个团队里面是怎么来。但如果让开发人员去做,开发人员就不清楚了,他很难找到,或者说他要找到,需要花很多额外的精力才能去创建出这样一个 case,创建出这样一批测试数据出来,或者说他要花很长的精力去找到一个测试环境,或者去做一次测试包的部署,他都非常累。

正是因为这些问题,所以就会有后面我们想聊的 工程效能团队的概念,现在非常流行,包括 Google 现在也在运行的模式。 工程效能团队这批人,一般都是由当时的测试开发人员组成。刚才我谈到有三类人,通常只有第三种人,也就是说工具平台 Service,平台化正式开发的人,他会转到工程效能团队里去。这个 Team 做什么事情呢?他就是给开发赋能,赋给开发测试的能力。

那么他通过什么样的方式来给开发赋能?他提供非常简单的 Service,可以让开发去创造任何他想要的数据,他可以给开发人员提供一套部署好的测试执行的环境,他可以给让开发人员非常方便地去创建一个包,并且让它自动化的部署完成。这些都是工程效能团队为了提高开发本身的执行效率、提高它的工程效能,所做的一些平台化,服务化,工具化的东西。这个模式现在是非常的流行,目前像 eBay 就在运行这样的模式,Google 就是业内做的非常成功的一家公司。在这里插入图片描述 Google 引起“去 QE”的故事

做测试的同学肯定知道一件事情,Google 在业内有一个非常知名的大会,叫 GTAC,它是 Google 在全球的自动化测试大会,每年都会在伦敦、欧洲、亚洲等地方举行。但是到了去年,也就是 2017 年的时候,Google 突然把这个大会停掉了,并在官网上给出了这样一个说明,说了我们为什么会把这个大会停掉?我们的原因在哪里?

这个大会成立已经有十多年了,当时成立这第一届到现在第十几届的时候,他这个初衷是什么?Google 是想提高自动化,提高测试的创新,测试的高效方法,来提高整个工程效率。但到了 17 年的时候,Google 意识到,单靠测试已经不是最好的途径去提高整个企业研发的效能了,所以说,他在这时候把大会停掉,并且提出了 Google 在 2018 年会回归,但会把这个会的名字改掉,不再是一个测试大会,而会是变成一个工程效能 Topic 的大会。

那么 Google 官方的主页都去宣称了这样的一些策略,以及他的想法,对于工程效能的一个定位,并且提供了一篇很漂亮的文章,去解释 Google 的测试开发、测试工程师,及他们的定位,以及在工程效能团队之后,他们这帮人是怎么来定位的。大家可以在 Google 的会议官网首页里找到这篇文章的链接,大家可以去读一下,还是蛮有意思的。

针对初级测试人员,有没有什么建议的学习路线?

这个是个非常好的问题,而且非常具有典型性。

首先作为一个初级测试人,我对初级的定义一般是在 0 到 5 年,或者 0 到 3 年。要回答这个问题,先明确的一点是,前面我们讲到测试已经不是以前传统的测试,是一个大的测试,是一个广义的测试,那么在这种情况下,测试分为三类人:一类是做业务功能的测试;一类就是做自动化测试,把这些业务功能的测试转换成自动化的脚本;那么第三类人就是做测试平台、测试工具、测试服务开发的。

你首先需要明确的是,你想在这三块当中所做的是哪一块?明确了这个之后,我们再来看每一块怎么去做发展。

第一类,你想做一个业务的专家, 也就是说你怎么来把业务做得非常的精通。这类人在将来应该还是比较吃香的,但是,这类人的数量应该是非常少。为什么?你会发现这类人他非常懂业务,它的业务可以懂到什么程度呢?他可能就变成了一个类似于产品经理的角色,他可以很好的定位这个产品,怎么使用,怎么提高转化率,怎么提高变成一个能够带来流量、带来用户活跃度这样一个角色。他会基于探索式测试的方式,基于对业务的理解,在业务的理解基础上去优化整个流程,提供 UX 这种测试,提高一整个产品的转化率。

那么对于这样一类人,他的成长路径,或者学习方法是什么呢?非常简单,他关注的就是业务,要把这个业务本身的来龙去脉,用户的用户场景,以及用户怎么来用你的产品,以及这个产品怎么样帮助用户去解决问题,并且整个业务流程是怎么来操作的,这些业务流程有哪些分支都要懂得清清楚楚。 但这个也是蛮寂寞的,而且劣势也是有的,一旦你离开了这个领域,你是很难找到更好的机会,除非你还在这个领域里跳槽,或者在这个领域找同样的类型。如果离开了这个领域,你的业务积累是没有用的,这是第一类人。

第二类人,开发测试工程师。 这种就比较简单了,他的点在于他有些高效的 case 组织方法,或者对于不同测试框架的应用,或者对于不同的测试框架之间的差异、优势劣势有自己的理解,并且能够基于这些测试框架的优势、劣势来选择最适合目前自己产品,或者最适合目前项目的框架选型,并且基于这样的框架选型来定义它的测试的力度,测试用例的力度,测试封装层次,以及代码的结构,并且能够提供一个高稳定性、低维护成本的这种 case。那么这类人更多的是对工具的熟悉。

这个学习主要是一些工具的学习。这个工具学习当中,我认为有一个非常重要的点,因为我接触很多刚刚接触自动化测试,或者刚刚开始做测试的同学,他们对于这种工具的理解是有一个很大的短板,这个短板在哪里呢?他们过度地强调怎么去使用这个工具,也就是说他们拿到的工具,我举个例子来讲,早期的 selenium 1.0 或者现在 selenium 2.0,他就拿过来用,他就根据培训机构手把手交的步骤,把整个东西建立起来,把测试跑起来,然后就完了。自己做一些封装,做一些额外的操作,让这个脚本跑得漂亮就完了。但实际上,我觉得欠缺了一个很重要的关键点,你必须搞清楚这个工具的原理,如果你不能搞清楚这个工具原理,一旦碰到任何问题,你就不知道怎么解决,你也不知道,你在做一些更深层次事情的时候,你怎么来去设计你的方案。

就比如我可能问在听课的大家,你用过 selenium 2.0?你知道 selenium 2.0 真正的原理吗?你能讲出它的原理是怎么实现的吗?你能讲出 selenium 1.0 的原理吗?1.0 和 2.0 是完全不同的事情,虽然看上去只是两个版本的差异,但它的实现原理,内部的机制是完全不同的。

那么现在非常流行 API,如果你把 selenium 原理搞得非常清楚的话,你就能很容易地理解 API 了,否则你可能觉得 API 又是另外一套新的东西。实际上不是,它还是基于 selenium 那套东西在走。如果你能真正理解了它实现的原理,也就能够面对变化的时候,你能知道知其然,知其所以然,并且甚至能够开发自己的框架去应对,你可能想过 selenium 为什么可以支持各种各样的语言,有 Python,有 Java,有各种各样的语言支持,有 Ruby,它为什么能够支持?为什么能够做这么多支持?

如果你不懂它的原理,你是很难理解它为什么能支持这么多语言的,但如果你能够理解它的这个原理,你就豁然开朗,原来它是这样子做的,所以它能支持更多的语言。关于这些东西原理的理解,在我的《软件测试 52 讲》专栏里,我也会去做非常深入的讲解,我会讲到一些工具,比如 selenium、API,我可能不会太多的去讲你怎么来使用这个工具,因为我认为怎么来使用这个工具,官方文档永远是最好的一个教材。官方文档永远是最权威,而且是最新的,如果通过文字的教材,或者通过这种手把手这种教程,它早晚是过时的,而且是跟不上变化的,我建议是这种工具的使用是通过官方的文档。

我的专栏更多的是会基于这些工具,它背后的原理,它怎么做得,它的来龙去脉,以及我们知道了来龙去脉之后怎么用好这些工具,更多的是会讲这样的东西。这样的东西会给你带来更多的价值,而且可以跟市面上现有的一些教材,或者书籍,或者跟官方文档体现出一些差异性,而且能够给你带来真正的一些价值,所以是这样一个状态。

第三类就是测试开发工程师, 那么测试开发工程师可以不用讲太多,因为我说白了,他就是个开发,只不过他开发的产品不一样。他是为测试服务的产品,仅此而已。所以对第三类的成长路径,完全就是一个开发的成长路径,你必须作为一个开发人员的角度去做,去让你自己慢慢成长为比较好的开发人员。

但是跟开发又有一个小的不同点。你还是需要理解测试的上下文,你才能做得比较好,你才能真正知道你的产品怎么帮客户去解决测试问题,你还是需要一些对于这种测试的理解,或者是对于这个测试服务需求的这种抽象化的能力。

基于这个问题,聊得比较多,因为这个问题比较典刑,展开的就会比较多,希望不同的人都能,这三类人当中都能有各自的收获。

最后

为了帮助大家迅速建立测试思维能力,早日斩获大厂Offer、掌握职场话语权,下面这份《软件测试全栈学习路线图》应该会对你很有帮助在这里插入图片描述
从测试概念到最后的测试开发,希望大家能照着这个体系,在3-4年内完成这样一个体系的构建,可以说,这个过程会让你痛不欲生,但只要你熬过去了,以后的生活就会轻松很多,正所谓完事开头难,只要迈出了第一步,你就已经成功了一半,古人说的好:不积跬步无以至千里,等到完成之后在回顾这段路程的时候,你肯定会感慨良多,掌握了以上技术,在任何一线互联网大厂测试岗位都能独挡一面

下面是一些配套的资源,希望能帮到大家
在这里插入图片描述
这些资料,对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师走过最艰难的路程,希望也能帮助到你!凡事要趁早,特别是技术行业,一定要提升技术功底。
关注我的微信公众号【软件测试小dao】免费获取~

我的学习交流群:644956177 群里有技术大牛一起交流分享~

如果我的博客对你有帮助、如果你喜欢我的博客内容,请 “点赞” “评论” “收藏” 一键三连哦!

以上是关于开发转测试,坚持16 年,转型并没错!的主要内容,如果未能解决你的问题,请参考以下文章

超实用面对枯燥的源码,如何才能坚持看下去?[转]

博客专家贡献(2022年至今)--2022-11-29(转)

转go开发随感

敏捷开发确实有捷径可走!!

操作系统的“冷板凳”要坐多久?万字长文解读16年开源老兵的坚持

今天来和大家聊聊敏捷开发的路径