亲身体会第一种会比较好，第二种的重心和资源不会在测试这里。相对来说也没有话语权。

各有优劣。
第一种优点是人员成长路径清晰，人员培养环境好，测试各种流程相对规范，测试话语权更高。
缺点是有可能和研发内耗，把做好测试和做好项目等同起来，为了一些内部 KPI 搞很多花里胡哨的东西。和开发合作也有重重阻碍。

第二种优点是可以深入接触代码，如果团队测试认知度高 + 测试人员能力强的话，也不会影响测试的话语权。你想弄的任何东西，只要对项目有好处，都可以获取支持。
缺点也很明显，如果项目测试影响不大（对线上问题容忍度高）或者测试资源紧张，或者测试人员普遍能力偏弱，基本就是工具人，被边缘化成点工。没有成长路径。同时这个依赖团队和负责人对测试的认知，不重视测试的团队，日子很不好过。

看具体的业务需求吧 和自身的发展规划,觉得业务测试好些 专门做效能，或觉得自身喜欢代码的 在开发团队中互相学习 逼迫自己去成长，对自己帮助会更大一些。

感谢老哥详细的回复！针对第 2 种场景，可能你说的 团队测试认知度高 + 测试人员能力强 貌似这个挺难实现的

两种都有亲身经历过，第一种测试地位跟开发、产品地位一样，形成三国鼎立，各自相互关联的同时，相互约束，跟开发讨论技术方案时，开发也会着重考虑测试的方案；第二种的话，相当于测试最底层的了，一般产品>开发>测试，以前开讨论会的时候，测试都不太敢出声，都是听从开发来。个人比较倾向的是，三国鼎立的状态吧，相互约束，团队内不断进步

我个人比较喜欢代码, 当前觉得和个人职业规划关系挺大的。如果想往 java 测开方向发展, 那么一定需要找个 JAVA 系的公司.这样才会有后续的 ” 通过 开发的代码 review“ + ” 平常和开发的交流项目” 提升代码能力。如果个人规划是 java，找个 C++ 为主的团队，这种技术栈不符的话，应该帮助不太大...

当前我也觉得第一种比较好.针对一般的公司而言，第 2 种形式一般都不太好. 不知道在一些中大厂中，会不会有这种形式，有没有这种形式的最佳实践， 实现双赢！

这两种都有经历。同一家公司，起初是测试和开发不同的领导，一个属于研发部，一个属于管理部。后来领导层改变，测试属于研发侧。干的活并无区别，忙的时候测试左右不了开发（开发说要发版本就发，评审等环节弱化），闲的时候按照标准流程走（需求评审。。。。）。对于个人成长来说，还是看领导。没在研发侧，也是可以看代码等。

在专门的测试团队中做测试

我理解这种是测试同学属于一个质量保障大部门独立运行，测试同学以资源小组的形式打散到不同业务中去支持业务发展，与业务线的产品研发不在一个大部门中。

• 优点：人多力量大，这种架构下质量大部门下会孵化出单独的中台质量技术团队，去探索先进测试技术，会做质量平台和工具来提效，这时候测试同学有更多机会往技术深入的方向发展，测试的方法论和目标一般会好，工作更加讲求效能逻辑、效能、计划。另外，不同业务线中的同学，有机会互相交流探讨不同业务形态下的测试工作差异。
• 缺点：并不是每个人都可以去干最有含金量的事情，看清现实吧……其实还是要看所支持的产品线，如果产品线资源很紧张迭代非常快，其实测试同学也没精力去搞啥技术，只能从大部门中把测试拿过来业务上落地。不过这并不妨碍个人从大环境中学习成长。

在开发团队中做测试

我理解这种是测试同学跟业务绑定，和产品研发同属于一个团队。

• 优点：研发测试沟通协作或许会更好（只是或许，不一定比第一种就好），有更多机会深入到业务中做建设，跟研发交流。
• 缺点：缺少测试技术标杆，一般这种团队下成长起来的测试同学对测试体系的理解不深，更多是带着研发视角来看待问题。而且由于缺少大部门高纬度的工作方针指导，也没了大部门的撑腰，测试同学很可能沦为产品研发的下游角色，只负责最低端的测试工作，发展上限低。

总结：我更偏向于第一种，因为第一种才真正代表着质量保障团队在发展壮大，测试同学才可以跟着大部门水涨船高，对于大多数人来说单打独斗是非常难做出彩的，长期来看少了对应指导也会让职业中后期产生认知和视野上的劣势。

总结的很到位！已设为最佳回复！

1