首先作为一个初级测试人，我对初级的定义一般是在 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，它为什么能够支持？为什么能够做这么多支持？
第三类就是测试开发工程师， 那么测试开发工程师可以不用讲太多，因为我说白了，他就是个开发，只不过他开发的产品不一样。他是为测试服务的产品，仅此而已。所以对第三类的成长路径，完全就是一个开发的成长路径，你必须作为一个开发人员的角度去做，去让你自己慢慢成长为比较好的开发人员。
但是跟开发又有一个小的不同点。你还是需要理解测试的上下文，你才能做得比较好，你才能真正知道你的产品怎么帮客户去解决测试问题，你还是需要一些对于这种测试的理解，或者是对于这个测试服务需求的这种抽象化的能力。
基于这个问题，聊得比较多，因为这个问题比较典刑，展开的就会比较多，希望不同的人都能，这三类人当中都能有各自的收获。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
