本人自工作来做的一直都是自动化测试，python 脚本、测试工具、测试平台的开发工作，但是没有任何业务测试的经验。
所以想问下各位大佬/过来人接下来我该怎么办呢？
是开始接触业务测试，还是继续深入技术？
因为听我最开始实习的领导说纯技术的测开很吃香，但越到后面越发感觉不是这样的，有点迷茫了...希望大佬们能指点迷津。
哪个能产生价值就做哪个，公司裁人时候不会考量你技术高低，只看你做事是否有价值。
实话实说，如果没有一点业务经验的话，就很难向下兼容，也很难带领团队，举个例子，你带个测试团队，团队成员有遇到问题，你业务一点都不懂，是不是不太好。特别是很多公司的测开岗位其实兼着干点工的活的，到时候换工作都不好找。所以建议还是学点业务的。
你都能做上侧开了，还怕什么业务测试，自己去找原型，然后整理出来也是一样的啊
我也是喜欢技术, 不喜欢做业务
价值向导，建议贴近业务，从业务中找到价值输出点，我也是从你这时候过来的，现在带领（测试 + 测开）团队。
业务测试这个可以通过定期到业务组轮岗之类的来进行，不一定就要直接转岗。需要的是你有这方面的经历和经验，对业务有一定的熟悉度。
个人觉得，作为测试团队的一员，没有业务测试经验光做工具开发，容易和测试团队缺少共鸣。
测开的主要业务来源就是给测试部门赋能，不了解单纯去做，确实会在一定程度上对赋能这块的内容产生认知不全不到位的情况，除非给你们测开部门单独配个懂业务的产品单独给你派任务，但是这样的话，还不如直接走业务开发，都没必要走测开了。换个说话，你可以理解的就是一个不懂游戏的人没有游戏经验的人，来做游戏，是一个道理，虽然他有开发经验，但是在实际工作中，在认识还有开发过程中有较大的学习成本在，楼上恒捷大佬说的是对的，轮岗是个相对比较好的提升捷径。轮岗也有对应的节奏，开发阶段真空期选择轮岗尤佳，让你的测开 Leader 去安排。
sonic1680
回复
既然要在业务中找价值，那直接投入到业务实实在在的做几次，才能更清楚知道需求点了吧。现在基本是业务方提需求给我做，主动去发现痛点真的很少
5t5
回复
首先感谢每位大佬的指导建议！！
这看来确实是个办法，我打算跟我头头提下这个建议了，之前真空期确实无所事事，自学也坚持不了多久，时间久了自己也焦虑，倒不如补点业务经验
都已经做了测开，表示有一定的产品设计开发能力，还有编程语言的深入，这种情况下，想要了解下业务应该不是很难吧。
更多的是自己愿不愿意去做这个事情。
基本原则：技术只是工具，它的价值由被其所解决的问题定义。
迁移一下，测试开发的价值就是被其所支持的业务决定，而好的业务（价值高的业务），不可能对一个测试开发只有代码能力上的要求。
我觉得得看你的部门性质，如果是那种中台或者公版的部门，纯测开是挺好的，专注于做工程效能提升中共性的部分，太看业务反而束手束脚。如果你是给业务做测开，辅助测试提效的话，就还是要了解业务的好，针对性的开发。
没有业务能力的测试开发，只是一个支撑角色，它的价值在于业务测试团队的认可。
我之前在的大厂，业务测试人员的价值就是要大于纯测试开发的，绩效也是偏向于业务测试人员。因为团队可以没有测试开发，但是不能没有业务测试。
作为测试前三年你可以关注技术，但是至少你工作 3 年以后，你不管做什么你都要开始沉淀业务，足够的业务深度才能体现你的价值
纯技术没有业务能力的测开，就好像都没有摸过飞机的轮子，你告诉我你整天都在造飞机一样
业务和技术是硬币的两面，干啥都有出路，路是自己走出来的。业务对公司有价值，对个人不能说没有价值，个人的价值依附于业务。但是你一个打工的，除非换公司不换业务，打工换工作那都是缘分随机的，大概率由不得你，要是一换，攒那么多年业务就打水漂了，要是坚持在一个公司，多几年应届生都倒挂你。技术可以帮助业务测试提升效率，技术也可以帮助自己不做测试，技术攒下就是自己的，换到哪都是自己的。所以，两手抓，两手都得硬，就看自己偏重哪块，像我偏技术，业务带着脑子带着沟通带着笑脸，点点点就好
顺带一嘴，像研发岗位，经常自嘲自己 crud boy，技术？你自己的都写代码，也知道啊，技术其实也就那样。回到正题，楼主找工作别给自己种自己不行的观念，业务带着脑子一般都能干，门槛它低啊。面试自信点，干，别给别人传达你不行的情绪，也别让人觉得你心高气傲不想点点点。如果安了心做测试，就得两手抓。
我不理解有的楼里的说法，好像业务测试可以把技术型的测试开发给比下去。
业务测试的发展空间有限，而纯技术开发测试可以走的路比较多，上升空间大，向下可以做自动化，功能测试，向上可以做测试架构，开发等。
如果你在当前公司做纯技术的测试开发没有受到认可，那估计是你当前公司是真的不需要这种角色，要不你转型业务测试，要不换个公司。
当然，我并不是说干了技术型开发测试就可以完全不必去了解业务，而是根据你当前的工作来决定做什么。
而且我相信，能够把技术干好的测试开发，想要做好业务测试也没有多少难度，关键在于自己愿不愿意去做去花时间。
润安
回复
感谢老哥，手工的门槛是相对较低，但我不应该一点都没接触，现在找工作也是吃了没经验的亏，以往我是想深入一条路，主打的就是个精通，现在看来两手抓或许更适应我的现状，多条路多条选择吧，这样机会也更多点
相信这是很多测试开发都会面临的问题，关于这个有几点感受：
【谈谈问题】
- 业务增长快的时候，公司会更着眼于长期价值投资，如自动化建设、平台建设等；
- 从效率角度考虑，一方面，生产工具建设本身就比较复杂，一些通用设计也不一定与业务强相关，所以测开人力投进去就不好兼顾业务版本，就是专人专用；另一方面，因为测开需要更多时间精力用来学习，业务测试自然也就无法很好兼顾，导致的问题就是业务经验不足；
- 从 ROI 角度考虑，一方面，工具要求越高，实现可能就越复杂，建设周期就会越长，短期 ROI 不明显；另一方面，服务业务的产品没有基于深刻的业务理解，没有带来预期的用户体验或效率提升，用户接受度自然不高，与此同时，如果没有后期持续的产品打磨，很可能长期下来工具就废弃了，这点看长期 ROI 更不容易体现，即付出大量心血却不一定得到承认，进而容易让人对未来发展感到迷茫。
【谈谈现状】
- 整体经济增速放缓，实体业务普遍增长受阻甚至萎缩，倒逼企业重视现金收入（相比过去的大幅扩张投产），放弃长尾业务或项目，即降本增效；
- 在降本背景下，测试团队作为成本部门，就容易首当其冲，其中功能测试专职作为与业务关系最密切的部分，会有一定程度的保留，具体视业务复杂情况而定，而其他非业务强相关的岗位则不一定，即在关注生存阶段，能带来短期 ROI 优先级会更高，如业务测试，而长期可能低 ROI 的会更容易会被调整优化，当然也不乏其他职场因素（懂的都懂）；
【谈谈思路】
- 从很多技术发展历程来看，最后能经受住市场考验，存活下来发展壮大的，都是能真正帮助到人们提升生产效率的，从这个角度看，测开发展的破局之道，自然也是从哪里来，到哪里去，即回归到对业务、对用户的理解本身，而不仅仅只是参与业务测试；
- 技术动力源于业务，技术发展推动业务，搞自动化或是写工具背后的本质，是通过工程化的思维，综合利用各种技术手段，来解决传统测试人员不好解决的事情，而不断学习所带来的技术视野，也是帮助在遇到困难时，能有更多解决问题的方法和思路，所以方向没有问题，就是有时换个角度看问题，可能会有不一样的收获。
哎，又摸鱼了
get 到新的认知 我以为测开都知道业务逻辑，原来还有不知道的 那怎么开发工具？
没有测开经验的业务测试没有出路吗？
不了解业务怎么开发测试工具，测试工具都是跟具体的业务核心功能耦合的。你需要用到多少业务知识，你就要了解多少。
还有一种就是探索性的主动去分析业务测试痛点，开发相应的工具提升测试效能，这种情况下更需要对业务有深入的了解了。
没有深入理解业务，做出来的工具平台也不会好用