会写代码，只是测试开发工程师的门槛——关于「软素质」的讨论

很多人一提到「测试开发工程师」，第一反应还是：

会写代码的测试。

我必须要指出，也许10年前是这样，但是在越来越卷的今天，“会写代码”，或者说有一定的技术能力，只是这个岗位的门槛。想进入这个岗位，或者想在这个岗位发展下去，真正重要的，是一整套“软素质”。

毫无疑问： 这些软素质，往往不会写在 JD 里，却决定了在团队里的位置、话语权，以及职业上限。如果你是个学生，想走测开方向｜或者你是个开发，想转测开｜亦或是你已经在测开岗位上，我都希望我的这篇文章能对你有些帮助。

这篇文章，我想系统聊聊：测试开发工程师，到底需要哪些软素质。

在开始之前：为什么“软素质”听起来这么虚？

很多测试开发，特别是学生，当从猎头或者HR处打听到：

需要重点考察候选人的软素质

内心第一反应往往是：

• 这是不是面试官的“自由发挥空间”？

• 是不是不好量化，才统一丢给“软素质”？

• 会不会变成一种人为拔高、事后解释的虚无标准？

这种感觉其实非常正常。

因为在大多数公司的语境里：

• 硬技能，有明确清单：语言、框架、工具、经验年限

• 软素质，却往往只剩下一些模糊词汇：

• 沟通能力好

• 有责任心

• 主动性强

听起来正确，但几乎无法操作，也无法复盘。

但如果你真的参与过测试开发的面试设计，或者带过人，就会发现：

领导口中的“软素质”，并不是性格评价，而是那些没法写成代码、却直接影响结果的能力。

它们之所以显得“不可量化”，只是因为很难用几道题考出来，

但几乎每一次线上事故，都会和它们有关。

一、对“风险”的敏感度，而不是对“BUG”的执念

很多测试新人都会有一个阶段：

• 看到 BUG 就兴奋

• BUG 数量 = 自我价值

• 修不完的 BUG = 成就感

有一个经典梗，说BUG多就扣开发的绩效，BUG少就扣测试的绩效。但这只是一个梗而已，BUG的多少不能说明开发的能力，也不能说明测试的能力。

测试开发工程师的视野要迈过的第一道坎，是从“找 BUG”转向“控风险”。

成熟的测试关注的是：

• 这个问题会不会影响用户？

• 会不会影响核心链路？

• 上线后出现，代价有多大？

然后便会开始自然地做取舍，而不是“雨露均沾”。

不是所有 BUG 都值得挡版本，但有些风险，哪怕只有 1% 的概率，也必须死磕。

这是一种业务判断力，也是测试的第一软素质。

---

二、站在“整体系统”视角，而不是模块视角

测试开发工程师，最怕的一句话是：

“这个不归我测。”

当然，职责边界很重要。 但系统性思维，恰恰是测试开发最重要的软能力之一。

你需要天然地关心：

• 这个改动会不会影响上下游？

• 数据结构变了，历史数据怎么办？

• 多端是否一致？

• 异常情况下，系统如何自愈？

很多线上事故，并不是因为功能没测，而是因为：

没有人从“系统整体”去看它。

而测试，往往是最后一个、也是最合适站出来补这个视角的角色。

---

三、沟通能力：不是“会说话”，而是“会对齐”

测试开发工程师的沟通，并不等同于：

• 能吵架

• 能输出长文档

• 能在群里持续刷屏

当然，“会说话”、能输出、维护人际关系都是优势，但对于沟通能力来说，只有一个目标：降低不确定性，让事情更快往前走。

包括但不限于：

• 把模糊需求问清楚

• 把风险说清楚

• 把结论说短

• 把分歧前置

很多测试“背锅”，本质上都是信息不对称。

而优秀的测试开发，会主动去“对齐信息”，而不是事后证明自己是对的。

---

四、敢于坚持，但知道什么时候该让步

这是一个非常微妙、但极其重要的软素质。

测试开发工程师，既不能：

• 一味妥协，什么都放

也不能：

• 逢版必刚，逢人就怼

你需要非常清楚：

• 哪些问题是原则问题

• 哪些问题是成本问题

• 哪些问题是认知差异

坚持，是为了降低系统性风险，而不是为了赢一场争论。

成熟的测试，会在关键点上寸步不让， 也会在非关键点上，体面退场。

---

五、负责程度：可以摸鱼，但该盯的东西一定要盯

很多人一听到“负责”，心里会本能抗拒。 因为现实中，“负责”这个词，常常被滥用成：

• 多干一点

• 多扛一点

• 最后兜底

• 出事问责

但成熟的团队，对测试负责程度的期待，远没有这么简单粗暴。

更接近真实情况的是：

你可以不一直高强度输出，可以不显得特别忙，甚至可以在一些无关紧要的地方适度摸鱼，但在关键时刻，你有没有把该盯的东西真正盯住。

比如版本临近时：

• 核心链路有没有被完整验证

• 风险结论是不是拍脑袋得出来的

• 灰度、回滚方案是不是只停留在文档层面

• 线上指标异常时，有没有人持续跟进而不是丢一句“已反馈”

这些事情，往往不会写进测试用例，也不会每天有人追着你问。但一旦出问题，所有人都会回头复盘：当时，这件事有没有被当成一件必须安全落地的事情在盯。

这里有一个非常现实、但很多测试心里都明白的对比：

开发可以明确地说，这不是我负责的模块，这块逻辑我没有改动。

这在开发体系里是成立的，因为开发的职责边界，本身就是围绕模块划分的。

而测试的职责，天然更偏向结果。

当问题跨模块、跨服务、跨团队时，如果测试也选择只站在自己的那一小块范围内，问题往往就会在边界处被不断传递、不断稀释，直到某一天以事故的形式爆出来。

所以很多时候，测试的负责，并不是亲自解决问题，而是确保问题不会悄无声息地消失。

你不一定是最终的 owner，但需要知道：

• 这个问题现在卡在哪一步

• 当前是谁在处理

• 是否存在被忽略或被低估的风险

也正因为如此，在事故复盘或面试追问中，经常会出现类似的问题：

• 这个问题当时你是怎么看的。

• 这个问题为什么没有继续往下追。

• 如果再来一次，你会在哪个节点多盯一步。

这些问题表面看起来在问判断，实质上在确认一件事。

当系统开始变复杂、责任开始变模糊时，你会不会依然选择对结果保持关注。

这也是测试开发工程师“负责程度”最核心、也最难被量化的一部分。

---

六、自我驱动：没人逼你，但你知道该补哪里

测试开发工程师往往处在一个比较尴尬的位置：

• 成果不容易被量化，价值不容易被即时感知。

• 很多事情，做与不做，在短期内看起来差别并不明显。

不得不说，开发这个岗位要求定期交付一定的成果，但测试要“混”起来还是比较容易的，这就决定了，自我驱动能力，几乎决定了一个测试开发的成长上限：

• 是否会在没人要求的情况下，主动去补系统知识。

• 是否会在流程卡顿时，想着是不是能通过工具或机制减少重复劳动。

• 是否会在多次踩坑后，总结出一套可以复用的方法，而不是只停留在经验层面。

这些行为，很少会被直接写进绩效目标，但它们会慢慢改变你在团队中的位置：

• 从被动接需求的人，变成大家默认会提前拉你参与讨论的人。

• 从版本末尾被通知的人，变成关键节点必须被同步的人。

这种变化，往往不是某一次技术突破带来的，而是长期自我驱动积累的结果。

---

七、和测试工程师相比，测试开发工程师的软素质差异在哪里

很多讨论软素质的问题，绕不开一个对比对象。

测试工程师和测试开发工程师。

这两者在技术栈上的差异，大家已经讨论得很多了。但事实上，发展到今天，我认为二者已经没有什么本质区别。硬要说的话，我认为有以下几点，且并不是谁高谁低，而是关注点不同、承担的隐性责任不同。

首先，在风险视角上，两者的重心并不完全一样。

测试工程师，更多是在既定需求和实现方案下，尽可能发现问题。

关注的是功能是否符合预期，边界条件有没有覆盖，现有用例是否还能兜住改动。

而测试开发工程师，往往需要在更早的阶段介入。

在需求还不够清晰、方案还没完全落地时，就开始判断系统性风险，评估设计是否可测试、可回滚、可监控。

这就决定了，测试开发的软素质中，前置判断能力占比会更高。

其次，在责任边界的处理方式上，两者也有所不同。

测试工程师的职责边界，相对更清晰。

在测试阶段内，把分配到的需求测清楚、问题提清楚，本身就是一件合格甚至优秀的事情。

而测试开发工程师，往往会被默认承担一些没人明确指派、但又必须有人持续关注的事情。

比如测试体系是否可持续，环境是否稳定，数据和依赖是否可靠，线上质量指标是否长期健康。

这些事情，很难和某一个版本强绑定，也不容易量化。

于是它们自然就落进了软素质的范畴。

第三，在沟通方式上，两者的侧重点也不同。

测试工程师的沟通，更多围绕具体问题展开。

而测试开发工程师的沟通，更多是在做取舍和对齐，是在参与决策，而不仅仅是反馈问题。

最后，在成长路径上，两者对软素质的依赖程度也不同。

测试工程师可以在执行和验证路径上持续深耕。

而测试开发工程师，如果只停留在会写代码的测试，软素质迟早会成为瓶颈。

因为越往后走，技术能力会逐渐同质化，真正拉开差距的，是在复杂系统中持续做判断的能力。

---

八、为什么开发更懂代码，但招聘往往并不偏爱开发转测试

从表面看，开发转测试似乎是一个非常合理的路径：开发懂代码、懂架构、懂实现细节，按理说做测试开发应该更有优势。但现实中，很多团队在招聘测试开发时，反而会对纯开发背景转测试保持谨慎。

这并不是对能力的否定，而是对角色认知差异的担忧。

首先，开发和测试在思维起点上就不一样。

开发的核心目标，是把事情做成。

在需求明确、方案既定的前提下，功能跑通、本次需求交付完成，往往就是阶段性成功。

而测试开发的核心目标，是尽可能提前发现事情可能会出问题的地方。

需要在方案还没完全敲定、代码还没完全落地时，就开始反向思考风险和失败路径。

很多开发转测试的人，在早期都会不自觉地带着实现视角。

更容易站在够用即可的位置，而不是持续追问极端情况下系统会怎样。

其次，开发更容易天然地为代码和方案辩护。

这不是主观问题，而是一种长期形成的职业惯性。

当你亲手设计和实现过大量功能后，很难在心理上迅速切换到一个完全反向的角色。

在评审或讨论中，容易出现替方案解释合理性、低估异常概率、用后续优化换当前推进的倾向。

而测试开发，往往需要站在一个不太讨喜的位置，把这些问题一遍遍拉回台面。

第三，招聘真正担心的不是技术，而是角色认同。

测试开发不是过渡岗位，也不是技术退路。

它意味着你要长期接受一个现实：

• 你做了很多事，但不一定被感知。

• 你阻止了很多问题，但它们不会被记录为成功。

• 你更多是在降低损失，而不是创造显性收益。

如果一个人内心仍然把测试当成次优选择，这种心态迟早会在工作中显现。

这也是为什么面试中，面试官会反复追问转岗动机。包括应届生面试中，如果同时投递了开发和测试开发，也会反复追问职业规划。

最后需要说明的是，这并不意味着开发不能成为优秀的测试开发工程师。

一旦完成角色认知和思维方式的切换，我认为确实有开发背景的人往往上手更快、上限也更高。我的身边就存在着既有深厚技术功底又有极好风险意识的开发，也正是这样的人给我带来职业危机感，促使我不断学习进步。