目前市面上招聘，都是偏向于招测试开发工程师，而测试开发工程师的工资也是奇高无比
轻则 30K，重则 50K
但是工作内容无外乎 UI 自动化，接口自动化，最多再跟运维，开发抢枪活
比如运维负责环境搭建，然后测开说 ：我也会搭建环境，你 k8s 里的一个参数改成 20，系统性能会更好~，然后留下运维表面佩服内心 mmp
比如拿着代码对开发说：你这么写在高并发下回产生死锁，赶紧给我改，不改好不许下班。。如此种种
但是我始终认为，测开一定要以测试为主，测试过程中需要开发一些工具，然后有能力自己去开发，而不是去跟开发，产品，运维去各种抢活
干开发和运维的活有利于，有利于从测试的角度，优化流程，整合资源。眼界离不开测试环节，做得东西也就是想着怎么用代码替代点点点，眼界放宽了，能做的东西更多
比如运维负责环境搭建，然后测开说 ：我也会搭建环境，你 k8s 里的一个参数改成 20，系统性能会更好~，然后留下运维表面佩服内心 mmp
比如拿着代码对开发说：你这么写在高并发下回产生死锁，赶紧给我改，不改好不许下班。。如此种种
没理解，这两个可以提升质量的举措，为啥就变成抢活了？当然不是很认可里面的一些态度做法（这个场景看起来太强势和草率），但我并不觉得给运维、开发提质量保障方面的意见，是在抢活。测开去做测试的活，也应该不只做普通的用例设计、用例执行，还应该深入到技术方案评审、代码 review 等能更深入和高效保障质量的地方，否则这个开发技能就没啥意义了。
另外，你提到的这两种自动化，在我接触的不少团队里，都应该是归到高级业务测试需要掌握的技能了。测开要做的更多应该是其他对开发技能要求更高的地方（如建设测试平台），不应该把主要精力放在这里。
不过有个点确实是要注意的，那就是测试领域内的东西都还没做好的时候，不要过早跨界，先搞好测试的并能让其他角色也用上（比如开发联调用了也可以省事，开始认可），再逐步向外扩展，要不很容易会拉仇恨。
不过有个点确实是要注意的，那就是测试领域内的东西都还没做好的时候，不要过早跨界，先搞好测试的并能让其他角色也用上（比如开发联调用了也可以省事，开始认可），再逐步向外扩展，要不很容易会拉仇恨
深表赞同
比如运维负责环境搭建，然后测开说 ：我也会搭建环境，你 k8s 里的一个参数改成 20，系统性能会更好~，然后留下运维表面佩服内心 mmp
作为运维，正确的姿势是：k8s 里这么设定参数是基于系统整体运维方面的考虑，而不是局部。你能给出建议说明你也具备一定的运维技能，但如果想在这个领域有更多成就的话，推荐你先看完这几本书，《运维从入门到精通》、《21 天入门运维》……，建议仔细研读，有看不懂的地方可以来问我或 Jeffrey，共同探讨共同进步。
比如拿着代码对开发说：你这么写在高并发下回产生死锁，赶紧给我改，不改好不许下班。
作为开发，正确的姿势是：这么写是基于系统开发整体方面的考虑，而不是局部。你能给出建议说明你也具备一定的开发技能，但如果想在这个领域有更多成就的话，推荐你先看完这几本书，《编程从入门到精通》、《21 天入门编程》……，建议仔细研读，有看不懂的地方可以来问我或 Jeffrey，共同探讨共同进步。
叫抢活了，那只能说太闲了。。。手上事情多的时候，那不叫抢，那叫帮忙分担~
楼主举的例子也不叫抢活，我觉得是去别人的专业领域指手画脚。
