作者:陆麟
转载请征得作者同意.
2026.6.19

简单点说结果，当一个应聘者回答问题时，能恰好回答出超出工作内容知识点范畴一点点，我会觉得他大概率是个潜力股。

为什么我会这样考虑呢？今天有个应聘测试岗位的先生，碰巧我随口问了一下工作中常见的缺陷是哪些。对方随手就列举了3类常见软件缺陷。 我顺势就问了一下发现缺陷后是否参与根因分析。对方一下子不能理解“根因分析”是个什么事情。我内心就在猜测，他大概率验证一个缺陷就 只看错误的结果在同样的步骤下是否消失。由于根因分析并不是测试岗位的职责所在，不会导致我认为对方能力不足，只影响我判断对方 是否大概率有发展潜力。根因分析是开发同事们的职责所在。之所以测试如果参与根因分析有可能变成潜力股，是因为根因分析能让测试形成 新的测试观点。

对方是车载测试工作人员，我就顺着问了一下，问对方工作是否只看错误结果有无被消除，还是要验证产生错误的原因有无被消除？例如执行故障， 可能是算法错误，也可能是温度超设备工作范围导致无法正常稳定工作。如果只观察错误结果是否被修复，就不会去验证工作温度。因为刚开机温 度就是正常的。但是如果参与了根因分析，分析到了故障原因，测试点就变成观察工作温度范围是否被控制。同一个故障现象，分析出的原因不同， 会形成并指向不同的验证内容。

根因分析不是测试的本职，但是能让测试人员水平和知识结构突破性发展。会使得人能够恰好掌握到超出工作范畴一点点的全新知识。多经历几次 后，一个有潜力的人员会自发摸索进新领域。从而不停冒出新问题深入挖掘。当然今天的应聘人员能随口说出3类常态遇到的问题，专业知识肯定 并不差。并不能因为对方碰巧没有经历过根因分析而否认对方的专业能力。

回过来讲自己的故事。200X年，公司开发一款名叫 OAS 的产品。可能很多人不清楚 OAS 是什么，我简单做个介绍。

进行大带宽、高速数据传输时，我们普遍会使用光纤。一根光纤可以同时传输多种不同波长的光，在发射端完成调制编码，接收端再做解调解码， 这也是当前主流的高速数据传输实现方式。

每一条光纤构成一条通信通路，OAS 设备两端同时接入多路光纤，划分主用通路与备用通路。设备会实时监测在用通道的光信号状态，一旦检测到 信号丢失并持续超过设定阈值，就自动将通信链路切换至备用通路。它多用于保护关键通信节点：当正在使用的光纤被切断、弯折，或是老化到无法 正常传输时，可以快速切到备用光路，保障业务尽量不中断。还有一种用法，是把某一根光纤的状态，作为整根光缆的健康参考指标 —— 逻辑是如果 这根光纤发生断裂，大概率同缆的其他光纤也已经通信失效。

铺垫完这些背景，来讲讲当年遇到的故障。我家里有一套 OAS 测试系统，会间歇性检测到光纤线路信号低于阈值，频繁触发主备光路切换。作为软件 开发人员，很多时候也是第一批硬件测试人员，开发过程总会碰到各类软硬结合的疑难问题。我把故障现象反馈给了台湾的硬件团队。一开始硬件侧的 排查思路，优先怀疑激光发射器件、光电接收模块本身存在缺陷。 但最终根因分析得出的结论，却是温度带来的影响：激光器发射器件受环境温度变化，自身输出激光的中心波长会发生轻微漂移； 漂移后的波长超出了 接收器件的有效响应区间，系统就误判光信号异常。

故障发生时，上海的环境气温远低于高雄。高雄的硬件研发团队所处环境温度偏高，在本地实验室始终复现不出这个问题。而且故障只会出现在开机后 的前几分钟：设备冷启动，激光器芯片温度跟随环境处于低温状态；工作一段时间后器件自身发热，芯片温度上升，输出波长回归正常区间，故障现象 便自行消失。

从这种随机偶发的故障里定位根因，非常依赖知识积累。这次问题，也让我在根因分析的过程中补上了温度这个关键变量。类似的经历在职业生涯 中时有发生，只要愿意用心复盘，每一次疑难故障都可以成为知识突破点，日积月累慢慢成长为领域内行。如果不去深究底层机理，很多人只会看到 “更换硬件之后，光检测数值不再越界告警”，不会建立起 “温度是重要变量” 的认知。人与人在技术认知上的差距，往往就体现在这里：看见 温度这个底层诱因，而不是仅仅停留在更换硬件解决表面现象。企业的knowhow是不会完全体现在文档里面。测试用例的网罗度则又依赖 这些knowhow本身。每个岗位潜力股多了，自然团队就强了。