在这里看到很多大佬的成功经验，也分享一下自己作为菜鸡的惨痛经验，提出自己工作半年之后的困惑点，欢迎各位前辈给新人提意见~~
缺乏职业规划的懵懂新人
2020 年 7 月硕士毕业，入职做测试开发，之前在外企有过半年 python 软件开发实习经验，接触了 CICD、docker、AWS、flask 基本用法，在大佬的指点下基本能用 python 开始搬砖，从往届师兄师姐那了解到实习公司薪资基本没有啥涨幅，薪资水平在当时的城市属于中等水平，但优点在于轻松【现在回想当时 965，不打卡的日子像做梦一样...】，由于地位位置原因，思来想去还是放弃了转正机会。老家 IT 公司选择较少，自己当初也没有花太多时间准备找工作，基本处于拿着简历，看哪个工作描述与自己实习经验最相似的原则去广撒网的状态，意料之外的收到了几个 offer：java 开发和测试开发，当时跟这两个岗位负责人聊了一下，感觉测试开发内容与实习经验最符合，本人对 java 开发也没有太大研究的兴致，就 “满怀期待” 选择了测试开发岗位。当时天真的以为测试开发=专门做测试工具的开发，毕业前夕还认真的学了一下 vue 和 django 框架，入职前对岗位期望太高，导致入职后迟迟没有进入工作状态。
初期工具人的焦灼
刚入职就直接被丢进项目组开始点点点，当时很疑惑，询问项目经理不是应该做工具开发吗，怎么开始做点点点了？项目经理答 “测试开发=SP 测试，还是要从熟悉业务做起”，简短的一句话让人无法反驳，心里安慰自己，可能这是公司的培养模式，等了解业务了，熟悉整个测试过程了，才能做出对产品线有用的工具......不过在熟悉产品的过程中还是很受打击，之前觉得点点点是一个很简单的事情，奈何公司产品业务太复杂，导致开头两个月每天都在加班，当时关于业务问题记录的笔记都整理了两百多条，每天都是疯狂提问 + 疯狂记录的状态，即便加班时间很长，但内心还是止不住焦虑，感觉没有成长，目前做的工作自己随时都能被替代，这种焦虑在转正答辩期间，副主管 A 提问一句 “这两个月你的工作表现只体现了你是一个合格的测试人员，但没有看到你有侧开思维” 达到顶峰，但主管 B 觉得我对负责模块原理掌握的比较熟悉，反应也比较灵敏，力排众议给我优秀转正了，对于这个结果有些惊讶，但还是有点忧心忡忡......
当时周围其他侧开小伙伴由于在公司实习过，早早的榜上了大腿，要么负责自动化，要么负责专项测试，虽然还是与工具差异很大，但起码还是能接触代码，并且容易做出提升能效的工具，对比自己做的功能测试....心里有点五味杂陈，当时跟导师沟通过这方面困惑，她给出的建议是先把手头的事情做好，再去想开发工具的事情，作为一个测人人员，业务是最基本的，不懂业务的测试是不会被认可的，而且测试设计能力很重要，叮嘱我先将通用测试考核过关再思考其他事情。
后期我卯足劲去完成公司测试基础考核，但后面又是一波三折....
初入自动化的职场阴影
当时公司给新人有三个考核：测试设计考核、用例编写考核、自动化编写考核，前面两个在项目组摸爬滚打，加上对模块原理了解比较清楚，女生本身对文字描述也比较有悟性，很快就通过了，也能基本胜任版本的测试活动，于是盯上了自动化，在不断请求下进入自动化组进一步深度赋能，进去之后发现自动化本质还是业务，而且不稳定，跑多个用例经常会因为一些环境问题导致失败，调试用例的过程极其痛苦：RF 框架不熟练、部分错误用例涉及的业务一脸懵逼，加上当时自动化负责人相对严厉，对提问的艺术要求很高，当时完全的小白，问了几个简单问题被嫌弃之后，没有保持刚入职那会不懂就问的优良品质，害怕被批评，按照自己的一些理解去做一些自动化任务，虽然很快的完成了任务，但是后期检视出了很多问题...记得当时晚上 10 点半了，刚刚走在回家的路上就接到自动化负责人的电话，他的火气隔着手机屏幕都能感受到，一向以为心理素质强大的自己，在这种情况下崩溃的哭了，在自动化轮岗的时光是最自闭和惶恐的一段时间。当初太渴望做技术相关的，但实际并没有让对方满意，心里落差很大，开始变得有点畏手畏脚，对自己也产生了怀疑，难道自己真的没有侧开思维？
带着一些负面情绪进入了师傅的版本继续点点点，由于逐渐害怕与人沟通交流，做事情又比较急躁，没有及时向上对齐，导致执行效率不高，又是被暴击的一段时光，诸如 “对你期望很高，但表现实在让人惊讶，缺乏分析问题，定位问题的能力...”，如果说开始是斗志满满，现在这个阶段应该是信心全无，甚至想要不要离职，但又害怕是从一个坑跳入另外一个坑，从毕业到其他公司做侧开的同学那里了解到侧开终究是测试，除了少数几个专门负责做测试工具以后，其余测试开发也都是业务为主。有种入错行的感觉，但失去应届生身份，又很难再找到一个满意的开发工作，对自己的职业生涯感到迷茫...
年底绩效考评不佳
半年转瞬即逝，就到了年底填绩效计划的时候，测试设计、自动化、专项自己都有了解过，但是没有一个拿的出手的，但当时根本没有重视绩效计划这件事，因为待了三四个版本，要么就是点点有么就是在被打击的路上。也不好意思去问自己绩效点在哪，按照自己的想法填了计划，不过在其中一个项目组，有个项目经理 C 觉得我自驱力强，对很多事情有自己的看法，给了我很多机会，在这个项目组收获了优秀新人的头衔，当初抱侥幸心理，觉得优秀转正 + 优秀新人绩效应该也不会特别难看，但结果出来的时候，绩效也就刚刚合格的地步，加上当时那半年部分出现很多事情 + 领导班子换了两回，绩效评语就一句 “做事情有自己的方法论，但还未落地”，这种模棱两可的绩效评语没起到牵引作用，自己还是不知道应该朝着哪个方向努力，对于这个绩效评定结果有点无奈。
由于打绩效的领导下台，新领导上位，也没有想过去追究自己绩效的事情，但跟无意跟项目经理 C 聊天的过程中聊到了绩效的问题，他说不要老想着别人给你目标，应该自己在日常工作中做出亮点，如果能产出工作职责外的事情绩效才会好看，让我不要东想西想把测试设计这块拿下，以后往管理岗位转。
迷茫项大盘点
【1】所有人都说测试这行门槛低，就个人工作经验而言，要做好测试要学的东西很多，而且又不像开发可以学一些通用业务，有种想努力不知道从何下手的感觉；
【2】自己想往技术方向走，但感觉在紧急项目的情况下，又很难把手工用例实现为自动化，真正提升效能，也是前期被吐槽的缺乏侧开思维，初期可能连手工测试都麻烦，自动化更让人心有余而力不足；
【3】目前已经没办法纯做自动化，只能走 测试设计的路子，但又觉得很难做出亮点，为自己以后的绩效担忧....
【4】一路走来，有过认可，但感觉被质疑的更多，渐渐有些迷茫到底适不适合这行。
加油
又看到方法论（热饭之前提到面试被问及方法论，他这一提也算第一次听到方法论）
恐怕这个词未来要在某些公司以及某些公司出来的领导所去的公司，甚至这个行业风靡了
加油
感觉楼主的问题在于拿开发的本事去测试里熬，另外在说你领导对你的各种暴击，我看你的描述感觉你的工作能力应该还是挺强的，至于 “做事情有自己的方法论，但还未落地” 这种，建议当屁看，但是如果能自己战胜挑战一般都会获得成长。
不过要说我这种干过几年的测试有什么建议的话，还是让自己开心最重要，跟自己内心走。
秦岭
回复
方法论是一种以解决问题为目标的理论体系或系统，通常涉及对问题阶段、任务、工具、方法技巧的论述。方法论会对一系列具体的方法进行分析研究、系统总结并最终提出较为一般性的原则。
如上方法论的释义来自百度百科，说白了就是处理各种问题的套路，请问这个词有啥问题吗？
几十年前的词汇和思想，为何未来会风靡？
楼主说的非常诚恳，正确。实际上现在大多的测开做的都是测试的工作。就是由于行业的卷导致的，测试首先不应该保证质量吗，我个人有时候觉得功能测试都不是很容易的，设计出优秀的用例并没有那么容易。
楼主的担忧就是 一般来说有产出的，比如说测开这些容易拿高绩效，容易晋升，而功能测试相对来说比较拉胯，晋升慢，-以后大多只能走管理路线。
要么辞职，找专门的测开岗，要么先在业务测试上深入，慢慢再转。总之个人认为都不会很理想。。
槽神
回复
之前你听过有多少个公司测试用这个词,你有多先进？
现在拿来包装，说的更高大上，更有利于 KPI，之前这些东西本质都用过，只是没把它拿出来搞一套一套的话术或套路来包装，
至于他风靡的原因，行业掌握话语权的人（比如他技术先进，他推广自己的技术自然会带这些话术，听者觉得高大上，另外他招人来这一套，你自然也要搞这一套才能进去），他跳到行业其他公司推广他的价值观，自然就散开了。据我所知测试界最先搞这一套的人，是来自于头部公司，现在逐渐在不少公司流行了！
哎，这让我想起了 15 年前，我刚入行测试的时候，我 leader 临时换人，新的 leader 要求每周必须执行多少条用例，那时内心的挣扎。
又让我想起 7 年前，部长一句你写代码不行，让我彻底火大，下决心去做开发的日子。
你并没有错，错在这个世界大部分需要的是工具人，有思想有梦想和现实只会差距越来越大。
然而更现实的是从你的行文看，并没有想好怎么去努力，很迷茫，尽快脱离学生思维吧，要么安于现状，要么就彻底去挑战自己不行的地方。
相比方法论，我现在觉得眼界更重要，你怎么看世界，世界就怎么看你。想明白做自己吧。
淡定，安心提高技术，不行就转开发
也经历过新人阶段，认真回答一下：
- 从软件工程理论的角度看测试是很重要的一环，因此不存在天花板低的情况。即使是现实世界中大部分人的职业生涯触还碰不到天花板。之所以有这种说法，那是因为质量对于大部分软件产品都不那么重要，所以对测试的资源投入不足。例如通信类、航天类质量至关重要的领域，测试就很重要，也很有技术含量。对于大部分从事的互联网行业，测试确实知识面比较杂，一个人精力有限，进一步的会感觉什么都不精。如果现在不知道从何下手，其实可以学习一些计算机专业基础知识，这些知识很长时间都不会过时，对你日后的工作、跳槽面试都很有帮助。
- 自动化会涉及到投入产出比，工作中的事情其实都要考虑投入产出比，有些产品、或者有些产品的阶段就是不适合做自动化测试，不必强求。
- 不要过分关注绩效，这个东西很大程度你是控制不了的，你的领导是什么样子的人，你在的团队，公司的成长阶段可能都比你的付出重要。至于领导给你解释的绩效理由，你听听就行，其实没什么意义，是先有结果再有解释。你的长期价值会在招聘市场中公允的体现出来。
- 适合不适合自己，自己喜欢什么，这永远是你要问你自己的问题，也只有自己能探寻答案。不要太在意别人的肯定与否定。
看了你的问题，首先楼主的背景和我当时算是比较相似，勾起了一段相同经历的回忆，也想参与回答一下。
其实不管什么岗位，都是有它存在的价值，软件测试的价值是为了保证质量，其他的自动化、监控、测试用例编写设计都是为了在一定程度上减轻我们测试的压力、提高测试的效率、更好的去保证线上质量。是不是换一种角度，做自动化这块，我觉得是可以往质量保证这方面去靠，如果在一定的投入下能够有效的提升自己负责的业务质量，那我觉得目的就达到了。 我们业务这边是负责自身的业务自动化，可能和你 “对部分错误用例涉及的业务一脸懵逼” 有些许出入，但是不要闷头只写 case，我当时写 case 的时候也是带有很大情绪（平台不稳定、测试环境不稳定、业务路径多且复杂、本身带有一定的抵触心理），后续 get 自己的重点之后，结合自身对业务的了解，其实发现只有自己才知道的一些易出错的点且适合自动化的点，这方面别人也不清楚，自己做的话成就感还是蛮大的（怎么还有一些小骄傲呢~）。
其次是心态吧，我是相信如果一个人优秀的话，是不管做什么事情，都不会特别差，除非是自己真的不适合。看的出楼主有一定的开发能力，也有想做出改变，愿意接受挑战的心理（不断请求进入自动化小组），同时提出自己的疑惑，应该是个不服输的人，所以更不应该让长时间的焦虑占据你自己的心理。因为组里同样存在一些特别优秀的人，我有这样困惑的时候就在想，为什么别人处理的这么好，而为什么到了自己这块，就不行了呢，真的是自己太差了嘛？答案肯定不是那样的，我觉得楼主以一定不是最差的那一个。同时相比楼主，我应该是更幸运，因为组里的人不存在严厉的情况，更多的是帮助你分析自己现在的问题，以及解决方法。但是我始终觉得，不应该因为别人的批评否定你自己，只有自己真的想放弃，所以遇到这样的情况下，及时排解自己的低落的心情，出去逛逛、和朋友约饭、或者做些自己喜欢的事情，尽快走出低落的心情，才能更好的整理自己，分析当时的问题、产生的原因以及解决方法，可以让朋友站在旁观者的角度帮助自己提提意见之类的。
最后结合楼上的评论：要认清自己喜欢什么，适合什么，如果真的在付出了成果和努力之后依旧没有达成自己的预期（我说的是自己的预期，而不是绩效和别人，我理解这些东西是同比增长的，但是首先是让自己满意，不要太在意别人的评论），是否考虑果断换行，毕竟让自己开心最重要，人生辣么长，何必苦了自己呢，工作不是为了更好地生活嘛~
科班还是非科班？
非科班做研发去补基础，现在学习资源那么多，对自己狠一点。
不要用学校或者测试的要求要求自己技术，那样你会放过你自己的。。。
然后还要告诉你，测开就有技术了？开发就是做技术了？多少八股文，多少 CTRL+V。想脱离业务，请科班硕士。国内又不是靠技术吃饭的。。。
不过国内的大厂也真给的起钱，5 年的推荐大头兵，可以给到 200+。但你们也别光看薪水，我同学去年阿里招算法要求是 5 年工作经验的博士。
测试除了大厂几个知名的开源测试框架，有多少说白了就是前端封了一层皮的？而且你认为的大厂测试开发，落地压力更大。
有的时候是我们要的太多，又想轻松，又想有发展。又想着 40 不失业，又不愿意去挑战未知。
但是还请脚踏实地，自己想做啥，能做啥都想明白了。
PS:不过有一说一，部分测试管理的技术水平是真的烂，研发相对好一点。
作为带过校招生的人来看，我觉得你在进入写自动化时候困难重重以及被自动化负责人喷这件事上来看。我觉得还是组织的团队培养体系和知识体系问题。因为对于一个没有工作经历的人来说，一些思想上经验上挺容易导致自动化用例写的不好。我觉得喷你的自动化负责人也该自省下，为什么没有 review 的时候发现问题，为什么代码 merge 前没有 pipeline 自动检查自动化用例是否 ok，你也不用太沮丧，越是担心犯错就越会容易放错，如果现在被喷的没有自信。可以先从自己拿手的领域先找回点自信
其中你现在面临的主要问题是岗位与期望不符，理想的发展路线是 测开->测开 但是现岗位确实业务->测开，这种差异也导致你对现环境有些不满，可是你也没办法，除了跳槽！
专职测开是要注意公司规模及产品情况的，参与到业务测试组内基本就是你现在的这种情况，如果不想跳槽抛弃掉应届生的身份，就坚持下去，熟悉业务流程，自我巩固技术层，期望与某一天公司立志与创建自己的测试服务小组，开发自己的测试工具或平台。
空有屠龙术，却卖屠户家，确实是不甘的
建议投简历面下其它公司，多试试，毕竟还年轻
不熟悉业务是没法做自动化的。。。
各行各业都有其门槛，真的要做好测试工作没那么简单。测试干到后面，不仅要能灵活贯通各个业务，了解各种系统环境（windows、linux、mac）。各种自动化：接口自动化、app 自动化，性能测试，各种专项测试：弱网、支付、音视频质量。而且随着现在 devops、testops 的兴起，测试又要有一定的 CI/CD 能力。测试看着门槛低，但你要成为一个好的测试其实很难，就跟演员和歌手一样的。
觉得新人不需要妄自菲薄，路还很长。你可以去看一些知名开源项目，先去学习一下人家的思路，甚至你可以先定一个小目标，写一些能对你在日常工作中有帮助的小脚本，例如造一些随机数据什么的。
“让我不要东想西想把测试设计这块拿下，以后往管理岗位转。”
这句话非常有共鸣！在工作这些年，别人对我说过这句话，我也对自己说过这句话，最近有个技术 leader 试图跟我说这句话，被我拒绝了，因为我要转测试开发。我曾经相信了这句话，放弃了技术学习，专搞项目业务测试那一套，等到跳槽时才看到差距。视野内的管理岗很多也都是技术大牛担任的，不搞技术未来发展会越来越窄，这不是说业务不重要，业务是开发和测试共同的基础，只不过测试相对来说技术积累少很多，导致容易迷茫看不到成长，换家公司就没用了。千万不要被别人定性了，也千万不要听所谓过来人，尤其是非测试的项目管理者的言论，有时候他们只需要听话的工具人而已。我也喜欢东想西想，现在除了想还在做，多实践，多写代码，多看看机会，把视线从公司放到整个市场来。
实在不喜欢测试，完全可以转开发，身边就有个妹子，也是被调到做测试，结果实在受不了点点点，转 C++ 了。
测试开发体系
回复
谢谢前辈的指点，我们公司的测试纯黑盒，基本不会接触什么代码，自动化使用 RF，本质也只是调用别人写好的关键字，听了你的建议大概知道怎么做了，已经不寄托希望能在工作中提升代码能力，只能自己多挤出时间提升自己了~~
尼古拉斯赵四
回复
好嘞，谢谢前辈的建议，习惯了从自身找原因，突然觉得偶尔找一下别人的原因，感觉舒服多啦，前辈肯定是个耐心、会引导下属的好领导~ 调整心态，哪里跌倒就在哪里站起来！！
jie
回复
不过做测试管理真的比做纯技术简单很多。
有门槛的技术岗位千不足一。我同学还在做技术的在企业的已经很少很少了。
如果非科班，真的能不能在业余的时间静下心来补基础，跟前沿，看 paper，还是很难很难的。
年轻可以试错，去试个 1，2 年吧。看看到底什么适合自己。
昨天脉脉看到一个讨论底层的贴子。其中一个回答分享一下：设计模式，代码规范，重构决定了程序员的下限。操作系统，计算机组成结构，数据库原理，数论决定了程序员的上限。
我这有坑，待遇不输大厂（保底奖金 4 个月），qa 组内技术氛围好（团队近百人，测架构组/cicd/测试开发），外企风格，加班不严重，经常有团队分享。有兴趣不，可以给个简历电话面试一波。（我是为了赚内推奖金）
沉下心来,打好基础,测试分析,用例的设计,对于当前工作和后续的自动化工作都有很大的作用,如果不了解业务,还真的很难开发出好的自动化工具,写好自动化用例,一切都是为业务质量服务的,追根溯源,还是要一步一步来,不能急躁
同测试开发岗位，我们内部叫做效能师，，这个名称更加确切。
我是 19 本科应届生，目前工作 1.5 年，属于工程效能团队的一员，一些我个人的经验，希望能有帮助。
1.明确定位，找准长期目标，确定自己到底想要做什么
2.随着技术的深入，确定你的定位，提高编码能力，阅读优秀的源码
3.发挥沟通能力，尝试有所精进，很多时候沟通也是艺术
4.深入到具体的项目和流程中，发现流程或者部门内的问题
5.拿到需求后想一想用户到底要的是什么，不要急于上手就做
6.从测试的角度入手，加强对业务系统的深入了解，并且，加强对开发、测试之间协作工作模式的现有积累、痛点和弊端的了解，知己知彼，从解决问题到创造需求。
我的情况可能和您还不太一样，我入职的时候本身编码能力还可以，Java,Python,PHP,NodeJS 的主流框架，以及 React，Vue 这些都是可以直接上手写项目的，试用期的时候学了 docker 和 docker-compose 相关，学了 seleium 和 JMeter 等常见的工具和框架，目前在负责公司的测试中台架构及实施，还算是有些阶段性成果的。
个人觉得测开最重要的是三点，
- 发挥你高于一般测试人员的技术能力（至少编码能力要强，不强就去变强），对于频繁出现的重复性工作，发挥你的编码能力去解决，比如环境运维，数据生成及准备，报告生成，等等。
- 一定要站在一个全局的视角，而不是囿于自己的测试项目这一亩三分地，纵观整个产品线，全生命周期的去考量可以提高工程效能的点，很多时候测试时的麻烦事完全是前期的一些小问题，解决这些问题可能会对效率有质的提升。 3.阔宽视野，积极主动学习，主动向业内前沿的经验实践靠拢，取其精华纳为自己的能力。
祝顺利。
RF 框架不是很难，主要是
接别人的盘确实非常痛苦
这种经历帖真的有很多大佬分享看法，真的能学到东西，对于小白来说很有引导作用