听“过来人”谈谈他对软件测试行业的看法

lsekfe

首先一个软件做出来，最不能少的人是谁？不用说就是开发，因为开发是最了解软件运作的那个人，早期不少一人撸网站或者APP的例子，相当于一个人同时是产品、研发、测试、运维等等，这也是为何开发是地位和上限是最高的职位。
　　而随着软件的复杂度越来越高，一个人是撸不出真正的大型商业软件的，所以才开始各司其职，产品去调研需求，开发负责实现功能，测试负责把控质量，运维负责照看环境等等。
　　所以要明确一点：别拿测试不当研发。测试岗本身就是从研发分出来的，绝大多数公司也都会把测试归类于研发中心，所以如果你以为测试只是偏业务的点点点小兵，那就大错特错了。
　　但是测试确实是又不如研发，因为测试本身是个成本岗位，说白了就是不负责产出的，理论上研发的能力强和自测做的好，测试甚至可以打酱油，这也是为什么有些公司或者领导不怎么看中测试的原因。所以测试前景好不好，现在是看你自己怎么定位测试这个职业，你是偏向产品和业务的功能测试？还是偏向于研发的自动化、性能或者测开？
　　所以测试人员的难点其实就是如果你只想安安静静的当一个纯粹的测试人员，那确实没啥前景和出路，实际上测试走到最后都是要点技能树转职的：
　　1、点业务技能点的，以后可以成为半个产品，甚至业务专家，这在金融领域等重业务的公司是很吃香的。
　　2、点研发技能点的，以后可以成为测开、自动化、性能、安全等等，有研发能力的测试在大多数互联网公司都是很受欢迎的，一是开发愿意跟你沟通，二是互联网的测试内容需要一点的技术底子。
　　3、点管理技能点的，因为测试本身处在整个需求生命周期的中后端，也就是前期没啥事，后期能不能上线全看测试的表现，所以也有测试兼职做项目管理的，做着做着最后就成了实际的管理者了，所以如果你见到一个项目的负责人是测试不要觉得奇怪，这系统能不能上是他来点头的。
　　这既是测试的优点、也是难点，优点在于测试转岗的能力是仅次于开发的，缺点就在于纯测试的上限也确实是最低的，相比于业务、研发这两大直接产出职能来说，不信你瞧瞧各公司的高层、创始人，几乎没谁是一路测试干上来的。
　　所以测试到了中后期是一定要转型的，而后期能不能转型成功全看你头几年的个人积累。我的建议是，你擅长干什么，或者喜欢干什么，就往那个方向转。
　　如果你业务贼牛，功能很熟练，整个公司比你更熟悉这个系统功能的人没几个，那你就尝试着转型项目负责人或者产品，不要只是被动的等需求。
　　如果你仍然把自己当作研发，那就去写代码，看代码，不要只会有问题就提BUG，要了解系统是如何运作的，要知道问题出在哪，最好是代码要改哪一行都给研发指出来，然后自己平时搞点自动化，前端后台都搞搞，弄个小的自动化平台出来，了解一点底层的知识，学到最后你就已经跟开发无异了。
　　我来给你说说一个测试工程师提BUG是分几个等级的：
　　初级：只知道提BUG，原因是啥不知道，让开发自己去研究。
　　中级：大概知道是哪里出了问题，能提供数据和日志，细致的还得开发自己去排查代码。
　　高级：有代码阅读能力，已经能把问题定位到具体的模块甚至具体的代码块了。
　　专家：拿个小版凳坐在开发旁边，用手指着开发的屏幕，呐，就这里出问题了，我来告诉你怎么改，你如果不会的话我甚至可以亲自帮你改。其实我一直都认为测试应该就跟开发排排坐，两个人盯着代码慢慢的debug，而不是测试只管提BUG，一问怎么出问题的啥都不知道，那样只会降低测试的权威性。
　　什么是测试的权威性？为什么有些公司的测试没人权，而有些公司的测试地位高。主要就是看测试对这个系统的熟悉程度，某些老测试堪称百科全书，这个系统从业务到代码都懂，这种人他指出的问题即便是研发大佬都不太敢反驳，但实际上更多的人只是用例执行人，BUG收集器，一问三不知，反正就有问题，代码看不懂，原理不了解，一看就感觉这人不太靠谱，所以这也是为何有些研发会认为测试门槛低是个人就能做的原因。
　　说了这么多，简单提炼一下：
　　1、纯粹只干测试上限来的快，要趁着年轻多积累，争取转型的机会。
　　2、尽量提高个人的权威性，不论是技术、还是业务，这都需要更深入的学习和积累。