最后一句已经指明要点了,个例不代表全部，现在业界能做单测的可以说是很小的一部分团队，单测写起来比写业务可能还复杂还费事的

说一下我个人的理解，你提到的研发对于自己开发的产品要求高，我觉得是好事，这样你就有更多的时间去做更加有趣的事情，比如说提效工具的制作，发现公司现有的研发流程是否存在缺陷，如何改进等等。
再说一下对于测试后期发展的事情吧，其实就我本人而言，工作年限大约 3 年吧，但经历过外企，大厂、小厂（创业公司），你会发现公司属性不同，对于测试岗位的要求并不同，大厂要求高，跟你合作的人能力很强，基本能很迅速的解决问题，但是自己可发挥的空间不是那么好争取到的，小厂的话，正是相反，但是需要你 cover 的东西很多。
出路这个事情吧，我说一下我个人的心态吧，仅供参考，时刻学习，随时准备被裁被淘汰（本人由于公司业务调整，已经被裁过两次了），其实大家说很多只是个人经验，重要在于你怎么看待这份工作，是想长干还是过几年转行，是想好好干，还是差不多就行了。

一般这种情况有以下几个原因：

1. 开发人员比较闲
2. 业务承担风险能力比较强
3. 测试人员能力比较弱，技术型业务弄不了

测试的价值一直都在，测试人员的价值就得靠自己挖掘了，每个团队测试人员表现出来的价值是不同的。

测试人员本来就是检验工程的质量的，如果开发做的够好，确实不需要单独招聘测试。

个人看法，测试工作总是需要的，但是不是意味着都需要专职测试来做，观点如下：
【不需要理由】
1、首先，目前整体而言，不管是叫测试还是质量保障，还是偏支持性的工作，即成本部门，而支持性分工在不同业务场景中，其实就意味着不一定是必需的；
2、然后像一些研发小团队，成员综合能力和自驱力都比较强的，然后交付的业务目标也是比较明确的，确实可以不怎么需要专职测试，而是开发自己可以做测试，甚至还可以做的更好，这是小团队、业务目标明确的情况；
【需要理由】
1、而一些比较大的复杂性系统工程，或者客户目标也可能经常变动的那种，还是需要有专职的分工，这个主要是出于一定业务规模下团队协同效率考虑，特别像不少实体产业领域，严格组织架构下较低的流动效率，技术架构中新老系统并存，实际特殊情况很多，比起追求更新更快变更交付，更看重业务系统的稳定，这种会需要；
2、云原生背景下架构升级带来的测试挑战，很多原先传统功能测试能力可以覆盖到的，也会越来越力不从心，但架构越复杂，通过测试保障质量的工作就越是必要，所以越来越多企业对测试的要求，也是不断往自动化、测开上靠，相当于变相在倒逼测试要求升级，这个角度看，角色是需要的，但是是以另一种要求更高的形态。
【补充】
综上，因为技术的演进带来角色分工的变化，这点不仅对测试，其实像运维、研发等都有同样的挑战及困惑，但可以观察到，产出性工作相对支撑性工作而言，更难被工具替代和冲击（测试、运维、研发、产品等可按该维度代入对比下），像测开，偏技术路线的，其实更多是通过工具化、平台化形式，将测试能力赋能给其他人使用；然后像 BA/PO/PM 等，也有不少测试出身的，偏业务路线的，则是通过拉通底层技术，指导业务设计，都是属于有产出价值、产出效益的，这里既可以是经济效益，也可以是社会效益都行。

当然，该问题还可以有很多分析角度和职业方向，因为每个人都是不一样的，暂时想到这些，欢迎补充。

同样的问题变着花样能问很多次，可以参考这个帖子：https://testerhome.com/topics/32404

感谢您的回复，您这个链接里是整个质量部要做的事情，像一些数据呀，平台化的东西，自动化的我们平时也在做的，除了本人以为我们也有专门的人员去做这些事，我只是一个最小的业务测试人员，平时主要工作就是保证项目的质量，但是现在开发都不需要测试的介入了，我就有点慌了，一开始还庆幸终于没那么忙了，但是现在又怕自己在团队中越来越没有输入出。

感谢回复，现在我们也不是百分百的不需要测试，一些项目尤其是时间周期略长，多业务合作的，测试去推进业务，或者说开发人员找到了用例中的问题，或者测试人员测出了 BUG 都是很有成久感的。但是也在想不需要写用例和测试的，我们测试人员但测试这个环节又需要做些什么吗？不是说很大的范围 ，我只是个小小测试员我就想我做为一个测试要做什么？

感谢回复，这就是我想问的点，我要怎么去挖掘，内卷的历害，我也是想向大家取取经

感谢回复，我还是想长期干的，但是不想学习的理由也千千万。但是也不想放弃不学习，部分今年刚换了大领导，我这小兵子也迷茫了

有这个问题往往是对测试自身的价值认知不足
1、作为业务测试来说，首先就是要对被测系统的整个业务有一个清晰的认识，这往往是开发人员不具备的
2、除了业务之外还要熟悉开发方案，这往往是业务人员不具备的，有些业务连接口都不懂
3、结合以上两点，你就能发现，测试不光是点点点，还是制定质量标准的人员，你的能力直接决定了被测系统的质量高低

有些业务的开发人员都不需要测试人员的介入 ... 好多业务不需要测试介入，测试人员对业务就不能进行深入的了解。测试人员的出路在哪呢？或者说测试人员要做些什么呢？

没太看懂，到底是少量开发人员不需要介入，还是大部分？

另外，由于开发同学需要深入很多细节，所以在整体系统的全局视角上一般不如测试，比较明显的就是除了自己负责的模块，其他模块基本只了解皮毛，所以导致开发在做整体系统的集成测试方面不如测试考虑全面（如果测试连这个都比不过开发，那真得好好反思下了）。测试可以从整体系统集成这个方面去看，整体系统质量如何。还可以进一步看哪些地方质量风险大，怎么去做 “预防”，而不仅仅是设计用例和执行测试做 “验证” 。

感谢回复，在我所在的业务线来说大概有一半的开发做的业务是不需要测试介入的，我们这个团队人员非常的踏实，大部分的开发人员待了有 6，7 年了。而我们的业务又是比较固定的。可扩展性不强，底层的数据这么多年来也就那几样，在这几样业务上也不玩不出什么花来了。我目前就是觉得除了写用例和执行测试外，不知道我还能再干什么。我想过接口测试，但是我看了好多的文档又说服不了我做接口自动化测试，总觉得不如页面测试快，可能我接口自动化测试太烂了

因果倒置了。
最初之所以有测试，其实就是因为你说的这种完美的情况无法普及。
如果真的这么好普及，测试也不会出现并发展成行业很重要的一环。

结合了帖主的各种回复，大概明白帖主想拿到什么答案，我尝试补充一下答案。

首先，从帖主所在的团队来看，是属于成熟稳定的团队，但是帖主没说研发人数和版本周期，我从上下文去看，应该是一个迭代很慢的平台产品，而且整体质量比较高。在这种情况下，研发自己写单测保障质量，那基本可以等价理解为研发具备充足的时间来自己保障质量，这个业务产品的迭代交付压力小。

从这样的背景来看，测试应该要做的是什么？还是结合实际分析现状和痛点，我下面给一些思路但不能照搬。

1. 质量是不是真的非常好，它到底还有没有风险点？ —— 要弄清楚这个问题，一个方向是正向梳理全量业务场景，利用业务经验和测试标准体系（功能、性能、容量、容灾、兼容、安全……）去判断；另一个方向是负向基于线上问题来定位风险，反推建设目标。好，假设这两个点都没什么可以做的，这个系统真的就稳定得一匹，那还有另一条路。

2. 研发自己做质量保障，有没有什么难题，能否为他们提效？ —— 比如让研发更简单地测试，让研发更直观地了解质量……说白了就是要造工具造平台造框架为研发服务，提高研发效能。具体能做些啥社区有 N 个帖子讨论过，就不展开了。好，假设这个也没得做，那就要回答一下自己待在这里到底是图什么，公司组织对你的期望是什么，需要你解决的问题是什么，这里面你真正能解决的问题又是什么……如果这些你自己答不出来，可能要考虑一下后路，除非你的人力成本性价比很高……

感谢回复，说到心坎里去了，首先说一下我为什么还待在这，因为这种情况也只是一部分，还有一部分也是需要测试的，在一个我在这个团队待了 13 年了，说出来可能丢人，人没啥出息，不想操心当领导，有机会的时侯也没把握就想在一线干。您回复的这些对我还是有启发的，我觉得第一点的去深研质量是不是真的好，其实我想的是可以从出的线上 BUG 入手。第二里的造工具造平台这个是有专门的人去做然后供我们使用。当然后也是我个人能力问题可能也搞 不了。所以总结出来就是我可能还是偏质量流程上去做改进。

再补充一点，去年我做的事情是写的用例怎么让开发更易读，更直观的去看用例。今年的话，就是根据看板的去匹配用例，用例不会很庞大，因为一个项目多个开发人员，开发人员也不用去在一个大的用例里去找自己做的那一部分，用例的提供更有针对性

1. 挖掘新的质量关注点。比如安全，这个很好推进，一般正常点的领导都不会忽视安全的。安全测试、安全设计、渗透测试、安全攻防、secOps 等等
2. 建设强大有效易用的测试基建。
3. 对个人来说的话，你想获取工作中的正反馈，可以先做点团队里大家都不想干的脏活累活难活，能让这些活不脏不累不难，这就是价值。

问题是您说的这些：
感谢大家给我的回复，下边是我通过大家的回复总结的我个人想要研究的点
1、研发流程中的改进
2、如何挖掘测试人员的价值
3、为什么有的团体队还需要测试，怎么让他们成长的不需要测试
4、接口自动化
5、开发方案多参与，对于用例和测试能更全面
6、性能，安全
7、调研不需要测试的开发人员看看他们是如何做自测的，是否需要测试人员提供协助

哪个开发或者架构师不能做？放弃幻想吧，这个高水平的团队里面测试就要和开发开发能力相当才行。否则连他们讨论什么担心什么都不知道。

打击我

1. owner 心态不是每个开发都有的，有的也是少数。
2. 未知的东西往往价值更高，有时候把未知变成全部已知并评价，难度只会更大。
3. 对于多数人来说，在广度上扩展比在深度上扩展更加容易，也更加贴近市场。
4. 想突破自己，付出的努力比大部分人想象的要大的太多太多，很少有人能坚持下来。同时就算突破，也不会带来本质上的财富变化。

只是就事论事的讨论，

1. 比如说 owner 心态不是每个开发都有的，有的也是少数， 把每个开发换成每个人也对的 - 所以呢？讨论测试还是讨论人？
2. 未知的东西往往价值更高，有时候把未知变成全部已知并评价，难度只会更大- 对，问题是已知的东西都没怎么搞懂，去能搞未知的？
3. 想突破自己，付出的努力比大部分人想象的要大的太多太多，很少有人能坚持下来。同时就算突破，也不会带来本质上的财富变化 -- 还是不要讨论什么财富的变化了，先有工作做吧

结论是，别多提什么概念了，做软件测试的，最少要知道软件怎么做出来的吧？一门语言要熟悉吧，代码能写写吧，文档能看懂吧，出了问题自己能解决一些吧？最少最少别出来一堆英文报错，连怎么找资料怎么修复一下吧

换个对测试要求/需求更高的公司？业务形态和研发节奏决定了你现在公司测试能提供的价值。

因为敏捷研发，既要快，又要稳；才需要更精细化的分工。在那种节奏下，测试才能发挥最大的价值。不过就是要求高，完了，人也很累就是了。

有点类似之前我问过同样的问题，不过我问的是：“测试的天花板很低吗？”

你这个直击心底，确实不精通，只是照猫画虎能写写

想要的太多，又哪个也不精通，就是现在的我