首先作为一个初级测试人,我对初级的定义一般是在 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,它为什么能够支持?为什么能够做这么多支持?
第三类就是测试开发工程师, 那么测试开发工程师可以不用讲太多,因为我说白了,他就是个开发,只不过他开发的产品不一样。他是为测试服务的产品,仅此而已。所以对第三类的成长路径,完全就是一个开发的成长路径,你必须作为一个开发人员的角度去做,去让你自己慢慢成长为比较好的开发人员。
但是跟开发又有一个小的不同点。你还是需要理解测试的上下文,你才能做得比较好,你才能真正知道你的产品怎么帮客户去解决测试问题,你还是需要一些对于这种测试的理解,或者是对于这个测试服务需求的这种抽象化的能力。
基于这个问题,聊得比较多,因为这个问题比较典刑,展开的就会比较多,希望不同的人都能,这三类人当中都能有各自的收获。
作者:佚名
来源:http://www.51testing.com/html/18/n-4478018.html