不要纠结，那个用人部门对这个的要求都不同，大公司会叫你去做螺丝钉，往深处搞，小公司喜欢啥都要搞，搞的不深，so。

做测试开发干嘛不做开发，做业务测试又被人瞧不起。所以总体来说测试就是 lowb 职位。

是啊，无论从公司结构和发展空间看，测试最高是测试总监，开发最高是 CTO，测试的角色并不是公司的必需品

个人觉得什么都接触下对自己职业发展有好处，当然也有只关注一个点成功的人，但个不是天才型选手这种职业发展成功率太小

测试开发的工作不该是把主要时间用在写写测试用例上，测试开发应该把时间花费在自动化脚本上和框架平台的开发上。写测试用例是功能测试主要做的事情。

职责分工不是通用的，每个公司不一样。去面试当然要 “迎合” 面试官的口味，以提高成功率。

我在的公司没有测试开发的职位，做测试开发只能去大公司，小公司或者业务不成熟的公司，慢慢会变成业务测试，如果实力强，建议找到好的机会转开发

我对测试、测试开发、开发有以下观点：
1、开发是学习了相关技术技能就可以运用到项目开发当中去的，并且他们的工作内容基本不会受整体项目流程影响
2、测试是学习了相关技术（自动化，性能，测试开发）并不一定可以运用到项目中，测试的内容是受整体项目流程影响的。例如有的公司没有自动化测试（项目不稳定，版本迭代快），有的公司没有性能测试（项目受众人群小，日活少等等）
3、大公司不必说了职位划分十分细致，职责划分也很清晰，个人认为那大部分公司对于测试这个职位或说职责并不是按照技能技术去划分的，而是根据项目需要（需要一名测试，可以做功能，也可以做性能），让测试来解决一些项目中的痛点问题。
4、从 3 来看，这也是为什么一些公司无法推自动化测试或者其它测试的原因及测试地位 low 的原因，如果测试的存在不是为了解决项目中的痛点问题（这个解决不是说解决开发问题，解决 bug,而是对项目质量产品质量保证的问题，例如保证性能，保证开发测试效率），那如何让领导让开发认可测试的工作，如何提高测试地位？
5、回到问题本身，功能测试和测试开发应该有怎样的职责分工？别逗了，这么 low 的职业还区分什么职责，服务好开发和领导，拍好马屁有口饭吃就好了，最后说一句做测试死路一条。。。

最后的最后，我认为不要过分的追求技术，根据自己的兴趣拓展自己的技术层面，根据自己工作项目加深技术层次，做出结果给上头的人看才是王道，谁特么看你有多努力的学习各种技术。。。。

追求技术，就去做码农。
很少有公司招 50% 时间做 CODER 的测试开发。

往开发转型中

这不是测试论坛嘛，怎么变把测试说的一无是处了呢？是不是要删帖了？

某老湿匿名都匿的这么潇洒，果然屌

有人说既然都做测试开发了，为什么不去做开发。
那么我想问问，如果你的测试开发做得好，开发水平能和普通的开发平齐，那么公司为什么要招开发。。。
一个不擅长测试的开发好，还是一个懂测试的开发好嘛。
要相信测试有测试的必要性。不设立专门的测试岗位，和不需要测试是两回事。

不熟悉业务 开发出来的东西，业务测试都不爱用，能说成功么? 你可以说你是根据产品文档来开发的，然而这并不能弥补你不懂业务的短板，用的人和做的人不一样，感受是大不相同的。个人觉得测试开发，首先不能脱离业务，否则就是闭门造车，做不好的

13 楼我能踩你吗

测试开发我的理解是，以测试为主技术为辅助。一切测试技术都是为测试而服务的，所以如果测试开发懂业务和测试的话，那对于测试工具开发事半功倍，且更能贴合功能测试人员实际应用场景。如果不懂业务的话，在公司组织架构上需要另设自动化测试接口人，来承接测试开发和功能测试之间的信息交流，否则会出现楼上所说的闭门造车。假如把职业目标放置在更高一层的测试架构师的话，那我觉得测试开发更懂功能测试和业务是完全有必要的。另外，我想说，测试没有楼上那些同学说的那么 low，我公司很多测试比开发还更懂技术，未来测试的分工会更加细，测试未来要么往需求方面转，要么往架构方面转，只懂手工测试的测试人员未来是会被淘汰的，纯粹个人理解

参考一下 google 测试之道 目前来讲功能测试是越来越边缘化, 逐步退出历史舞台, 如果追求测试发展的话, 测试是必须具备开发技能的, 如果说这个公司不能接受你这种说法,不去也罢, 去了长期也没有什么发展的.
另外测试开发绝对不仅仅是开发自动化案例或者自动化脚本的编写, 要有一定的针对性, 目前国内的三巨头 BAT 可以去了解一下, 更多的核心都是工程效率, 那么自动化测试仅仅是其中的一个环节. 不要局限在测试的范围内, 其实可以做的更多.

你的这点我同意，不管是测试还是测试开发，只是职能不同，最后的目标都会提升到质量和效率这个层次，这时需要放宽自己的视野往上面瞧瞧，看看在这个目标下，自己能做什么能提出什么不同的观点，才是最重要的

我就不喜欢只写代码的测试,不就是自动化测试和测试开发么？谁还不会似的

我来细分一下各种测试和测试开发人员，
从测试开发开始，先分 2 种角色，再分人：
一个是框架开发与维护，属于偏开发的
一个是测试脚本开发与维护，属于偏业务的

第一种角色的框架开发与维护还能细分两种，
一种人擅长做图形界面的测试平台，姑且称为 1.测试平台开发人员和这种人配合的是 2.不会写代码的测试人员或者只会一丁点代码的测试人员

另一种人擅长做无界面的框架，也像是一个软件项目的架构师，我叫他们 3 测试框架开发人员和这种人配合的能写点代码的测试人员，又或者叫 4.测试脚本的开发人员。

楼主想做 1 或 3，但大多数公司要的是既能做 13 又能做 24 的人，目前大公司很多大 QA 时代的东西是由 1+2 来完成测试，但依我看现在相对来说比较好的分工是 3+4
我这里有十多年前 1 做的测试平台，让我一个做惯了 3+4 的人来用，我感觉智商受到暴击，硬生生要把我变成 2.

1 是最容易脱离业务做出 2 不想用的平台的测试开发。我不是说 1 不好，1 客观上讲要求比 3 高，正因为要求高，很多达不到的人做了 1，最终做出很恶心的平台。1 是最应该关注使用体验的，然而往往我们遇不到高端的 1。低端的 1 虽然有一定的技术，但是我最不想遇到的同事。用他的工具会不断对我的智商造成伤害。

2 是技术方面发展最差的人，俗称苦力。一般会尝试搞业务或转管理。

3 需要比较高素质的团队，离了 4，3 什么也不是。而 3 和 3 区别很大，开发能力一般也能做框架，开发能力很强也能做，两者的使用体验完全不同。高端的 3 和高端的 1 并列在测试自动化领域较高的位置上。低端的 3 和 4 没多大区别。

4 是还不错的新人入门推荐岗位。比较容易提升到 3。比如一个新人掌握了接口测试框架的开发技能，某种意义上就到 3 了。

上面 1234 现在全叫测试开发。

此外还有罕见的 5 测试工具开发，和跨界而来的 6.devops。

5 最大的问题是岗位很少，很多 5 等同于低端的 1，做的工具很难用。有的公司 5 就等于打入冷宫的开发。

6.现在已经把持了测试的上游技术。我们单位的 6 打算搞人工智能干掉低端的 2 和 4。但我们单位的 6 的代码质量令人不敢恭维，和低端的 1 半斤八两。