前段时间看社区里在讨论测试重业务还是重技术的问题。
就我个人而言，在业务熟练的基础上，技术绝对是个加分项。毕竟业务的门槛相对较低，技术的壁垒会更高点。
如果在职，要看公司的倾向性。目前我所在的这个公司 KPI 就是越来越偏向技术性了，在业务上看不出有多大差距的情况下，技术产出作为突出项来决定年终绩效，前年我们被要求写接口自动化，写得多绩效好；去年接口自动化要写得好，但是必须要有工具的产出；今年开始拥抱 AI，需要有 AI 相关的工具产出，否则就算业务再突出，生产 bug 再少，发现的测试 bug 再多绩效也差。
我有个同事是卷王，几乎没有他不熟的业务，每天加班到 10 点，但是不会自动化，没有工具产出，去年打了最差的绩效，没有年终奖，今年被裁走了。
我们都在吐槽，在公司越来越不好混了，领导的要求越来越高，兼顾业务的同时还要有技术产出，可是能怎么办呢？
如果找工作，要看应聘公司的要求，当然每个公司的要求不一样：
- 只需要业务测试
- 只需要技术，比如工具测开
- 只招业务，但是技术要达标，只是标准不一样。有些只要会点自动化，有些会要求算法，现在还有 AI 相关的知识。 第 1 点这样的公司其实不多了，外包可能会比较多点。第 2 点还是挺多的，有很多公司工具组招人，当然最先裁的也是这样的人，很不幸，我现在就在工具组担惊受怕中。大部分公司还是第 3 点。 总结：其实唯技术论还是唯业务论，都是伪命题，应该唯市场论，人家公司要求什么，你就学什么才是待在这行的长久之道！
说到底还是看领导喜好，向上管理
“毕竟业务的门槛相对较低”，某些业务门槛可是相当高的
你们的业务看来不赚钱呀，在变着花样分类员工了，你也小心点吧，裁员迟早也到你头上的。。
毕竟业务的门槛相对较低，技术的壁垒会更高点。
这个认知就不对了。
我们公司的做法，绩效评定以缺陷逃逸率为主要标准，即（客户反馈回来的缺陷/版本迭代提单缺陷），越低越好。其他的自动化、技能分享等反而是次要的。各项目也建设有接口、UI 自动化，以我了解的情况来看，效果不好，甚至增加了无效工作，公司产品客户多，每个客户都是不同的环境，而且迭代频繁，针对这种情况，需要一个个去适配，还要跟上项目迭代的节奏，很难。各个项目都苦不堪言。当时也不是说技术不重要，我认为归根结底，再牛逼的技术也是为了业务而服务的，从业务中提取共性、找到难点，使用技术去解决这些问题，我认为是对的，但是不应该本末倒置。还有一些高门槛的产品，比如人工智能、大数据。今年公司也在推 AI，但领导在开展的过程中也会着重去评估对工作的提效
尉遲惠婷
回复
是以我目前的认知哈，我去工具组了，招了个实习生来替换我原来的业务测试。有些业务门槛肯定高多了，之前在一个大数据公司呆了几天就扛不住了，直接提离职了
公司需要你干啥 你就干啥
我的理解是最终收口都要落在业务上，技术也是服务于业务，业务永远是第一的
楼主问的其实是公司是重业务还是重技术，这玩意儿给大家主要的反馈在绩效考核，从管理上看，考核的一个作用是为了引导大家努力的方向。但是吧，现在大部分考核制度其实就是为了把前 5% 和后 5% 筛出来而已，也就是他们根本不是为了引导你成为公司需要的那种人，而是完成把人划分三六九等的任务罢了。
从这个角度看，只要你和别人不一样，你就会脱颖而出（注意别整到后 5% 了哈哈），而技术上区分度相对好操作点，so~~
从测试角度看，个人认为业务是 1，技术是在后面加 0，相辅相成。1 和 2 其实区别不大，但是 10 和 200 区别就有点大了~反之 100 和 800 也是有明显差别的~
2 者都好，不容易被淘汰，也更容易有高质量产出
看公司业务是否赚钱，业务赚钱，那会更看重业务能力，如果业务不赚钱，一般没啥卷了就会卷技术。还是看项目赚不赚钱，像前几年区块链虚拟货币交易所项目，那是真暴利，招人硬性要求：必须会相关业务、看懂 K 线图、还要会玩常见的交易所平台。
我发现在 testerhome 里面怎么这么多测试同学都纠结这个技术还是业务哪个更重要的，见过好几个帖子了，以前的帖子有些评论说的也挺中肯的，有疑问的同学可以自己翻翻看看
如果说楼主公司的情况：那显然是不对的，追求技术也不能做二极管。 技术重要，但简单且繁琐的事情，或者技术含量没有那么高的事情，这些总要有人做的。不能全员都做技术不管业务。
但如果抛开楼主公司的情况。单纯去讨论一下，那两者必须是都重要的，业务是基础， 技术是能深入测试产品的基石。 但咱们要明白一件事， 那就是你对自己的要求是只在业务表层上测一层皮。 还是想要测的更深入。
如果是后者， 那技术就是更重要的，因为很多技术产品或者说一个业务产品的底层测试人员， 他们面对的就是技术， 可以说技术就是他们的业务。 比如要你测试一个数据库产品， 如果你不理解底层技术， 那注定你就是一个 sql 的功能 boy（如果连 sql 也无法熟练操作的话，就更低级了。）你不知道怎么测底层组件的功能， 性能， 稳定性， 高可用， 通信， 数据备份等等。
其实应该重人情
不管你重什么，只要在公司有人际关系，都有人出来给你站队
只有有了站队和战队，天平永远向你倾斜
业务？计术？不如会舔
类似的问题其实论坛已经有不少讨论了
Ouroboros
回复
这个表述角度好，很赞同。
【现在大部分考核制度其实就是为了把前 5% 和后 5% 筛出来而已，也就是他们根本不是为了引导你成为公司需要的那种人】
【从这个角度看，只要你和别人不一样，你就会脱颖而出（注意别整到后 5% 了哈哈），而技术上区分度相对好操作点，so~~】
从我的角度看：
- 熟悉业务不等于有竞争力。个人视角，业务 = 了解技术链路 + 熟悉产品形态 + 理解产品规划 + 掌握竞品动态。一句话说，如果给你找个技术很好的打手，你能否从零复制一个产品出来，复制出多少大概等于对产品理解多少。
如果业务技术链路非常简单，没有几个层级的上下游，也没什么历史债务的说法，代码量小场景简单流量低，对应的是业务熟悉门槛低，测试研发替换成本低，熟悉这类业务是竞争力不足的。
- 技术确实是容易突出个体差异，因为业务经验和知识的验证比较依赖一些关键场景彰显（重大需求的测试判断、日常长期的质量保障布局、问题排查现场的思路），这种彰显机会实话说确实不多。技术就很容易在日常工作体现，而且给人的印象是更长远的，比如做了一个测试工具大家会记住很久，但是你线上查出了一个问题不一定会被大家记住。
其实我一直有个疑问？
如果你的业务是简单的，
那么你怎么证明你的工具/设计是很有技术难度的？
~ 纯粹好奇
现实：90% 的公司是「生意型」而非「技术驱动型」，技术只是成本部门，非核心盈利点。
例外：少数大厂/技术壁垒高的行业（如 AI、云计算），技术≈护城河
大多数公司：
→ 技术是 “保下限” 工具
→ 别幻想 “技术改变业务”
→ 活下去才能谈理想
中小公司测试困境：
✓ 人力：1 个测试对 10 个开发
✓ 资源：无自动化设备/云测试平台
✓ 节奏：上午提需求，下午要上线
✓ 结果：手工点点点 → 漏测背锅 → 恶性循环
真相：
功能稳定的产品 → 自动化才有价值
频繁改动的产品 → 自动化维护成本＞收益
技术是否重要 → 取决于公司赚不赚钱
- 赚钱时：技术是 “护城河”
- 亏钱时：技术是 “成本包袱”
大多数人的归宿：
- 要么卷进大厂（真做技术）
- 要么在小厂 “伪技术” 中生存
技术内卷 ≈ 同行攀比 + 市场泡沫 + 人才过剩
- 大厂高薪挖人 → 抬高行业预期
- 中小厂跟风堆技术 → 实际用不到
- 从业者被迫 “镀金” → 技能贬值 现实：80% 的公司技术投入是伪需求，只为融资/PR/招聘贴金。
自动化现状：
✓ 10% 公司：真落地（全流程/高覆盖率）
✓ 30% 公司：半吊子（仅冒烟/核心链路）
✓ 60% 公司：摆烂（简历项目/入职即荒废）
典型问题：
资源不足：无稳定环境/无人维护脚本
需求畸形：业务天天改，自动化成本＞收益
人才错配：招聘要 “自动化大神”，实际工作 “点点点”
小黑子-IKUN
回复
相比较业务而言，技术是更底层的、更抽象的东西，即便不能够放之四海而皆准，也更容易跨行业应用的东西。在我看来就是一些课本上的基础知识和实践的结合，牵强一点就外加一些解决问题的思路或者方法论。
如果一个人的技术，换个行业就需要重新学习，比如从电商到芯片、从金融 ERP 到 AI，那么他所谓的技术其实只是业务的一部分而已。
有些人有时候特别喜欢偷换概念，把技术的范围无限放大，就像我年轻的时候坚持认为管理是一门技术活，所以管理也是技术……这样搞的话，别说业务没有技术重要，职场就只剩下技术了。所以这样一来，是不是业务、管理啥的只剩下皮毛了，最难的可不就是技术么~
像 7 楼说的这些业务方向更能成为自己的壁垒，而且技术也是要为业务服务的，自己在公司卷个云、AI 啥的，远不及别人干几个月。当然也不是说技术不重要，只是在业务没有成为壁垒时就靠技术卷了
更倾向于在能选择的时候优先选择业务方向，选择不了时再卷技术了
干的再好、学的再多有个屁用；还不如有个好亲戚、好 “大树”
技术还是服务业务的，不管怎么样。我团队的安排基础的测试同学 20 接口 case 80 的业务测试。中级 50/50 业务自动化
开会也是推荐多学点技术，技术硬才是真的赢
世界就是一个大的草台班子。
讨论技术，业务哪个重要有啥用？
你是想升职还是加薪还是跳出阶层？
先活下去，然后看命，真的有的选么？你足够卷么。。。
其实更扯淡的是现在软件技术还剩多少门槛？
哪里不都是牛马？
谈技术，ai 最头部可以到 2 亿美元，技术只会越来越垄断，别扯什么技术重要了，说白了都是牛马。
只有芯片稍微好一点，试错成本高，软件还剩个锤子的技术门槛。
magicyang
回复
技术没什么门槛，但是人学习技术还有门槛的，我们做了个接口自动化工具去推广，没想到很多事业部居然不写接口自动化，一流程没有规范化，二很多人都不会写。我们都觉得都 2025 年了这不是只要测试都会吗，还是很多人不会的
你知道为啥很多公司招测试要求高技术吗，就是因为核心的业务型测试不敢放出去，放出去公司瘫痪一两年都不过分，你能在公司的业务层站稳脚跟是很厉害的。
你觉得业务的门槛相对较低，你去试试跟领导，跟客户，跟上下级深入交流，主导跨部门合作，去参加领导的饭局，你看看门槛还低不
我有个同事是卷王，几乎没有他不熟的业务，每天加班到 10 点，但是不会自动化，没有工具产出，去年打了最差的绩效，没有年终奖，今年被裁走了。
这是你的角度，你老板的角度怎么看呢？
技术最终都是要服务于业务的
这么说吧，你想在一个企业呆得久一点，业务是必须要掌握的，技术是其次的。但技术在不同企业都是较为通用，业务在不同企业通用性较差~
阮志明
回复
我个人感觉这是被宣传的误区，业务怎么可能通用性差呢？
业务经验的通用性其实被低估了，尤其在从事相同的领域内（如电商）。
如我测试电商 A 平台积累的经验：用户典型路径的痛点、核心业务规则（库存、订单、支付、促销）的坑、常见业务逻辑漏洞的测试设计思路，几乎可以无缝迁移到电商 B 平台。因为我们服务的本质上是同一批用户，解决的是同一类业务问题。
相反，技术栈和测试工具的通用性反而更受限。A 平台用自研的 Java 微服务 + React + Selenium，B 平台可能是 Go 单体 + Vue + Cypress + 完全不同的 CI/CD 流程。我在 A 平台精通的特定技术工具和针对其架构的测试实现细节，到了 B 平台很可能要推倒重来。
技术底层原理倒是通用的（比如 HTTP 协议、数据库事务），但具体实现、工具链和最佳实践仍然高度依赖公司当前的环境
