前言

一个软件做出来，最不能少的是谁？毫无疑问是开发，开发是最了解软件运作的那个人，早期就有不少一人撸网站或者APP的例子，相当于一个人同时是产品、研发、测试、运维等等。

随着软件的复杂程度的提高i，一个人是撸不出真正的大学商业软件的，所以开始各司其职。

要明确一点：别拿测试不当研发。测试岗本身就是从研发分出来的，大部分的公司也会把测试归类于研发中心，所以你认为测试知识偏业务的点点点小兵，那就大错特错了。

但是测试确实又不如研发，因为测试本身是个成本岗位，说白了就是不负责产出，理论上来说研发能力够强和自测做的好，测试甚至可以打酱油，这也是许多公司不怎么看好测试的原因，测试前景好不好，看你自己怎么定位测试这个职业，是偏向产品与业务的功能测试?还是偏向于研发的自动化、性能或者测开？

技能树

测试人员的难点在于如果你只是想安安静静的当一个纯粹的测试人员，那确实没有啥前景和出路，实际上测试走到最后都是要点技能树转职的：

1、点业务技能点的，以后可以成为半个产品，甚至业务专家，这在金融领域等重业务的公司是很吃香的。

2、点研发技能点的，以后可以成为测开、自动化、性能、安全等等，有研发能力的测试在大多数互联网公司都是很受欢迎的，一是开发愿意跟你沟通，二是互联网的测试内容需要一点的技术底子。

3、点管理技能点的，因为测试本身处在整个需求生命周期的中后端，也就是前期没啥事，后期能不能上线全看测试的表现，所以也有测试兼职做项目管理的，做着做着最后就成了实际的管理者了，所以如果你见到一个项目的负责人是测试不要觉得奇怪，这系统能不能上是他来点头的。

这既是测试的优点、也是难点，优点在于测试转岗的能力是仅次于开发的，缺点就在于纯测试的上限也确实是最低的，相比于业务、研发这两大直接产出职能来说，不信你瞧瞧各公司的高层、创始人，几乎没谁是一路测试干上来的。

转型方向

所以测试到了中后期是一定要转型的，而后期能不能转型成功全看你头几年的个人积累。我的建议是，你擅长干什么，或者喜欢干什么，就往那个方向转。

如果你业务贼牛，功能很熟练，整个公司比你更熟悉这个系统功能的人没几个，那你就尝试着转型项目负责人或者产品，不要只是被动的等需求。

如果你仍然把自己当作研发，那就去写代码，看代码，不要只会有问题就提BUG，要了解系统是如何运作的，要知道问题出在哪，最好是代码要改哪一行都给研发指出来，然后自己平时搞点自动化，前端后台都搞搞，弄个小的自动化平台出来，了解一点底层的知识，学到最后你就已经跟开发无异了。

我来给你说说一个测试工程师提BUG是分几个等级的：

初级：只知道提BUG，原因是啥不知道，让开发自己去研究。

中级：大概知道是哪里出了问题，能提供数据和日志，细致的还得开发自己去排查代码。

高级：有代码阅读能力，已经能把问题定位到具体的模块甚至具体的代码块了。

专家：拿个小版凳坐在开发旁边，用手指着开发的屏幕，呐，就这里出问题了，我来告诉你怎么改，你如果不会的话我甚至可以亲自帮你改。

其实我一直都认为测试应该就跟开发排排坐，两个人盯着代码慢慢的debug，而不是测试只管提BUG，一问怎么出问题的啥都不知道，那样只会降低测试的权威性。

为什么有些公司的测试没人权，而有些公司的测试地位高。主要就是看测试对这个系统的熟悉程度，某些老测试堪称百科全书，这个系统从业务到代码都懂，这种人他指出的问题即便是研发大佬都不太敢反驳，但实际上更多的人只是用例执行人，BUG收集器，一问三不知，反正就有问题，代码看不懂，原理不了解，一看就感觉这人不太靠谱，所以这也是为何有些研发会认为测试门槛低是个人就能做的原因。