测试开发就是开发。
别跟我整一些有的没的。

我不相信一个开发技术了得的测试开发还会去做点点点的业务测试，还会去自己写测试用例？

著名的管理学家德鲁克，提倡把一些非核心的工作从一些核心员工身上剥离，找专门的人统一去做，大大提升了组织的效率，

说的极对！

只要是测试，它就具有 “从属性”，“从属性” 意味着不是核心，不是核心就可以随时被开、被移除。测试开发和测试是 IT 行业发展阶段性的产物，阶段性产物意味着它是妥协出来的，行业高速发展，用于质量建设的人才梯队跟不上，就只能退而求其次的招聘点点点工人。行业越发展到后期，成熟度越高，人才梯度结构趋于合理，用于质量保障的角色绝对不是测试这个岗位，测试不会消失，但是岗位会。在未来，测试就是开发的一项必备技能，测试必然融入更大的技术洪流中，测试只是个研发的工序和基本技能，而不再是个技术岗位。

说的太棒了，我也这么觉得
测试自研左一个框架，右一个框架，都是 demo 而已
什么采用了 A+B+C+D 的技术 ,说起来好像很高大上，实际能解决多少问题？泛用性如何呢？
等哪一天测试界也出现 spring 这种好用又泛用的全家桶，这个行业才真正找到了突破点

不要想太多，只要能为公司带来价值，为自己带来提升，就够了，好好加油!

你太敏感了，27 楼只是说哪种方式更适合女性，并没有否定的意思。如果真的一心向技术，转战一线 RD 也没什么。随便讨论讨论直接就被扣上三观不正的帽子，也是醉了

唉，都啥三观，把性别歧视说的那么冠冕堂皇，还被赞说得很棒……
当然，受到质疑的时候还是一样的话来回：我说的是国内的现状……

说的很棒~

这个其实就是选择的问题。我自己目前不会向纯工具开发转了，我的优势不在这里，虽然工作这些年也做了不少工具。选择了不同的方向其实也决定了你以后学习的侧重，如果真的转向工具开发，就像其他同学说的，可能要比很多 RD 都要精通，侧重的是技术的深度。如果选择高级业务测试，其实你更需要关注对于某些问题的测试保障方案，可能更关注于广度，当然也要对技术有较为深入的了解。具体如何选择，还是要结合个人的情况决定

这确实是很多公司都存在的一个状况

赞同，好的测试开发往往都是技术和测试能力都是一把好手，但是匹配的薪资待遇往往还不如一般开发，那有这个水平，为什么还要做测试开发而不是转开发呢？行业里太多前辈转行就是这么个套路

我同意你的看法，能做出来好的测试工具的测试开发水平可能比一般开发还强，好的测试工具就是 ToB 的业务，你想想你要了解你使用的人，都是专家，你能做出让专家满意的东西，你能不强吗。只是大部分老板没有意识到而已。既然工资给不到，那么其实大部分工具质量不高是可以理解的

我说的 20-35 通常是公司的平均开出薪资 市场价位，肯定有不同的公司给的高 这些不稀奇

好的 测试 和 好的开发，

好的测试人员 需要哪些：

单元、接口、UI、性能、软件部署、需求分析、外部客户培训、有时候市场调研、起码拥有可以很方便的编写一个商城平台的代码能力，数据库性能调优、容器性能调优，生产环境的压力、系统埋点的任务分析、同时 还要跟着 时代，学习，ABC AI，DB，云； 对了 还有运维，这些技能你都要拥有； 踏踏实实学习，你需要 5-10 年，只看技术技能的情况下，20-35

好的开发人员 需要哪些专业：

深度的学习开发语言，达到关注 内核、内存、网络协议 这些层的东西，最好是可以 开发出一套 适用于自己公司的 优化架构；马马虎虎学习，5 年；只看技术技能的情况下，25-35

有时间 有经历 希望在技术上专研的， 建议男生 直接转行开发，

女性，也有厉害的人员；可是等你有了孩子只后，母性光辉，我听其他人说 怀孕傻三年，那你技术基本就跟不上了，其实也不建议你，拼命，教育好孩子，也是功劳；

所以 男性，测试可以晃荡 2-4 年，以后你就直接转开发 你要赚钱养家；女性想时间充足，兼顾家庭，年轻的时候学习一些技术，进入大公司；熬时间；

最近看很多公司要求的测试开发要有服务端或者前端的实际开发经验 能力，又要会一大堆测试工具 测试理论，以及服务端 前端 性能 安全全栈测试。
关键是测试工具的开发，并不像公司产品的业务开发那样有众多框架 模板可用 有相对稳定的技术可借鉴，以及像普通产品开发那样更有可行性，那样容易落地， 而且测试开发在大领导眼里地位还是不如开发

那么如果水平与开发一样，有开发的实际经验与能力，为什么还要做测试开发而不是做开发呢！

有人抱怨测试开发没有产出 推进事情我觉得两方面都有原因 需要带动的是代码能力弱一点的测试 但是这个事情有多难 只有做过的人知道 事情大部分不是一方面的问题 但是需要一方面的人负责任 世界就这么运转

我觉得测试开发不纯粹是开发框架的 测试开发测业务 应该是用代码的地方用代码 需要业务的时候用业务知识 需要自动化的时候自动化 代码应该是随手就能写出来 这应该是大部分测试需要达到的水平 可惜现实中没有这么多 测试用例的代码难度没有那么大也没有那么简单 但是往往工作量大 这也就是为什么好多开发不愿意写单测代码也好集成也好的一个很重要原因 解决工作量大的问题同时还要解决欠债太多问题 这个真不是一般测试开发搞得定的 无解 混日子 工资到手就可以

我其实更想知道楼主，你想干么？准备怎么做？
有没有初步的计划和进度表？

很有意思~

因为培训机构需要测试开发这个噱头。

其实这么两种截然不同的观点，大致上是自己的经历，以及自己公司的格局，技术大领导对测试开发的定位，整个技术架构综合决定的。
这些观点，这些决策，都是经过思考，大致上也是比较符合自己公司目前的情况，但是却不一定适合别的公司。

我来说说把 这个问题我之前和 x 顿教育的 测试经理谈过一次； （实话实说，想喷随便）

他问我： 你怎么看测试开发 ？

我说：测试开发的职责，怎么划定，他的职责就在那，但是现有的 测试团队，没有测试架构师的情况下，测试开发的职位，没有发挥出他们的 优势，可以暂时不考虑招聘；

他说： 测试开发，可以在日常工作中，协助测试人员，提供工具辅助，小工具，技能分享，专项分析；

我说：这些 高级测试，也可以做到，比测试开发 薪资低；而且 高级测试，基本要求是，快速熟悉业务，熟练的可以在不同场景中，规避很多 测试陋习， 所以我偏向 高级测试，然而 价值意义 上，高级测试更符合测试团队，利益， 团队和谐，团队建设也是；

他说：测试开发 是现在 很多公司 都有的，他们可以快速的 帮助测试团队很多；

我说：帮助有那些， 开发框架么， 开发测试平台么，还是 做一套自有的测试流程； 但是 要明白一个问题是，团队人员 有多少人可以，配合 测试开发 一起，是一起成长； 如果不可以，那测试团队 招聘测试开发，就是在 害人家；

他说：大厂都有测试开发，不论通过 框架，平台，都对 测试团队有很长的帮助；

我说：一朝天子，一朝臣子，测试团队的建设 ，都是 功能测试人员、自动化测试人人员、接口测试人员、性能测试人员， 一个一个人员 堆积起来的， 你见过那个 测试团队 一开始就，招聘测试开发的，这就说明 招聘测试开发，要符合测试团队建设，且 测试团队可以快速 在测试开发的帮助下，提升测试团队整体实力，达到转型的目标； 然而 在有测试开发人员，之前的测试人员，基本都是老员工了，或多或少的，都有些 怠慢，或者工作不积极； 这个人员本身；还有就是 公司的业务，公司还处于 创业期，很多东西都需要协调，你搞一套东西，能不能落地，测试开发心里也没有低； 好就算可以落地，你给他多大的支持，

他说： 要人 给人 要资源 给资源，可以 快速提升团队实力；

我说： 测试经理，没有人事 和 绩效；只有在自己的仅限的地盘转，再说了 如果真可以，你自己不会搞，非要等到现在；

说了这么多，我对团队测试开发 还是支持态度的；但是测试开发人员，思想要改变，就是你既是测试，也是开发；有开发任务，可以做开发，有测试任务可以做测试； 这个也是大趋势，这就是为什么 有些 团队测试开发可以开到 50K；

嗯嗯嗯，你们说的都对，我无可辩驳

测试开发做的是水平赋能，如果仅仅把目标或者职责定位为工具、自动化开发，视角就略显局限了，也很难把工具、自动化做好，注意这里说的是做好，而不是做完，同时，团队多了重复造轮子的也就多了。
对于测试开发而言，其本质不是需要掌握开发能力，更需要的是测试解决方案能力，这是要建立在测试理解、测试策略设计能力之上的，并不是仅仅会某一种开发语言。测试开发提供的是测试解决方案的技术实现的设计、开发服务，寻求质量和效率的平衡。同时解决方案绝不是解决局部问题。
对于上述，虽然看起来 “要求太高”，但并不是不具备可行性。
发展总是需要时间，由测试到测试开发的过程中各阶段的策略也是不同，比如从纯手工测试到测试能力分层到测试开发。

对

老哥讲得很在理。

落地在任何时候都是很难的事情。
落地很多时候需要的不是技术能力，而是产品和项目思维，不再是单纯的技术，可能是成本（包含沟通成本，人力成本）。
我以前也迷茫过，在脉脉上问过测试开发落地的问题，阿里有测试开发同学落地很好的，人家测试开发比 1：30。手工测试的人力基本全部节约出来。如果真正要能做到把手工解放出来，可能比开发还要懂开发。

开源的越多，确实使技术门槛变低，不用再去重复开发一些通用型工具 (比如接口测试啊)，但是解决方案的变多不会大幅减少实践落地成本。现在这部分是有些脱节的，我们有很多高效好用的工具，但是由于各种原因，落地情况其实并不理想，这后续会成为测试开发同学能力提现的地方

方向 2 的话是要求你根据实际需要定制性的开发一些工具，毕竟通用型效率工具不能解决所有问题。但是这也不是必须的，如果有完善的效率团队支持，也可以将痛点梳理出来，交由相关同学来开发。如果测试开发绝大部分时间都在开发一些业务耦合度较高的工具，后续迭代以及维护会成为一个不小的挑战，造轮子可以，但是不能一直造烂轮子

做对用户有益的工具，而不是对测试有益的工具。
做对节约人力有益的工具，而不要管手工测试的人力减少。。。
感觉无论是测试，还是测试开发，整体的需求在下降。
开源的越多，技术门槛越低，程序员越没饭吃，测试更惨，很多时候只能点点点。

不要限定自己的角色，做了测试开发又怎样，真正专业的工具还是开发实现具体功能；只不过是不要满足于现状，坚持学习尽可能体现自己的价值

我理解测试和测试开发不应该分的这么细致，只有在业务一线的同学才会感受到测试过程中的痛点，而工具都是从这些痛点提炼出来的；抛开业务测试开发能做的就只有一些通用的能力，而其他的业务同学的痛点感知不到

嗯，分析的比较到位，专业的事情还是交给专业的人去做，其实我们现在已经有很多优秀的工具，不管是公司内部的还是开源的，现在是落地比较难。传统的手工测试人员的比例会逐渐降低，高级业务测试的比例会提高，有效的承接效率工具的输入将会变成一项重要的能力，什么都想搞，可能什么都搞不好

在国内的公司有独立的工具研发组的少之又少，特别在一些大公司，通用效率工具的研发是由 RD 来进行，而不是由测试开发来做。我也说几乎等于测试，不过这样的公司应该不多，你知道哪些公司可以放出来给大家看看，可能是我孤陋寡闻了

国内现在这种现象确实很普遍，但是这也是因为从业人员水平普遍偏低导致，如果把测试和测试开发在一起，会导致楼主说的现象，，但是分开也会有问题，首先手工测试人员知识面比较匮乏，不少工作中缺乏思考，他们想不到那些可以技术化，提不出有效的建议，其实哪怕是做手工测试也要了解技术，哪怕你不会写代码，也要知道哪些工具、框架是干什么的，能干些什么，这样你在工作中多多思考，就会有不少有效需求；其次目前从业的测试开发人员大部分都是手工转的或者网上找的资料自学的。导致对很多东西一知半解，做出来的东西，充其量能用，谈不上产品这种档次，也就很难体现出专业，这就导致测试人员提出的不怎么有效的需求，和测试开发做出的不怎么专业的工具之间的矛盾，导致互不信任，一个觉得你春提个需求都不会，一个觉得你垃圾，做的东西随便点点都是小问题。
还有就是管理的问题，很多测试领导只是想着要有测试开发，要做系统做工具，但是没想着有了以后怎么做，导致做了很多系统做一个废一个。

"这种时间分散的时间管理模式可能导致在这两个方向上都没有较好的产出"
那是你们家的国内，是你遇到的情况是这样的不代表所有人都这样
再说了，人挪死树挪活，不要把自己限定在某个角色中

那是你们家的国内……在下以及在下的盆友做测开就是开发，偶尔帮忙搞一下自动化之类的框架而已~