编者按: 沈昊的履历上写满了“大跨度”——从旧金山的初创公司到东莞的Oracle工厂级测试,从SSD嵌入式固件到金融定价系统,再到如今带队开发LLM驱动的测试智能体。我们和他聊了聊,一个后端工程师如何在不同技术域之间跳跃,又如何在看似庞杂的系统里找到自己的主线。

问:你的职业经历跨度不小,从存储固件、金融交易系统,到现在Oracle的自动化测试平台。你觉得自己最核心的技术主线是什么?

沈昊: 表面上看是换了几个行业,但底层逻辑没变——我一直在和“大规模系统的质量与效率”打交道。在Scaleflux做SSD固件,要保证千万级IOPS下的数据一致性;在DBS做定价系统,要处理多币种、变期限的复杂计算,容不得半点误差;现在做自动化测试平台,面对的是一套百万行级别的嵌入式系统,要让它自己“学会”怎么被测试。

说到底,我关注的是:怎么用系统化的方式,让一个复杂系统更可靠、更可控。只是手段从手写测试用例,进化到了构建自动化框架,再到现在的LLM智能体。

问:说到LLM驱动的测试智能体,这个项目听起来很前沿。它是怎么开始的?

沈昊: 灵感其实来自经典的Monkey Testing——就是让程序随机乱点,看系统会不会崩溃。但我们面对的是工厂级验证环境,场景极其固定,纯粹的随机测试效率太低。于是我想:能不能让AI来“理解”系统界面和业务逻辑,然后自主生成有意义的操作序列?

我们做的不是简单调API,而是构建了一个完整的Agent框架:它能把界面元素映射成可操作对象,能根据历史反馈调整策略,还能自动判断测试结果是“通过”、“失败”还是“无效”。这套东西现在已经在内部几条产品线上跑起来了,测试覆盖率提升的同时,手动脚本维护工作量降了不少。

问:你提到“自主生成测试用例”,这涉及到生成式AI的不确定性,怎么保证它不会胡来?

沈昊: 这确实是最难的部分。我们的做法是加两层约束:第一层是“动作空间约束”,Agent只能在预定义的、语义合法的操作集合里选择;第二层是“结果校验约束”,生成的操作序列必须经过一个轻量级的规则引擎验证,比如“不能连续三次做同一类操作”、“不能跳过必要的登录步骤”等等。

另外,我们保留了人工审核的“闸门”——关键测试场景的生成结果会推送给测试负责人确认,确认后才会进入自动化执行流水线。这样既保留了AI的灵活性,又把风险控制在可接受范围内。

问:你曾在DBS做金融系统,又在Oracle带测试团队,这两种角色对“系统设计”的要求有什么不同?

沈昊: 在DBS,系统设计的第一优先级是正确性和事务一致性。一个利率算错了,可能直接造成交易损失。所以设计时要把边界条件、异常回滚、幂等性这些东西想得极其清楚,代码要写得像数学证明一样严谨。

在Oracle,系统设计的核心变成了扩展性和可维护性。因为测试平台要服务于多条产品线,每种产品的接口、协议、数据格式都不一样。如果为每个场景写一套定制代码,项目很快就失控了。所以我的大部分精力花在抽象通用能力上——比如脚本生成引擎、测试数据构造器、结果聚合分析器,这些组件一旦设计好,就能复用到几十个测试场景里。

问:你管理着一个工程师团队,同时自己还在写核心代码。这种“技术领导+一线开发”的双重角色,怎么平衡?

沈昊: 说实话,没法完全平衡,只能动态取舍。我给自己定了个原则:凡是涉及架构决策和关键模块的代码,我必须亲自写第一版,这样我才能深刻理解它可能带来的性能瓶颈和运维痛点。而一些相对标准化的功能实现,我会交给团队成员去做,我只负责设计接口和做代码审查。

这样做的好处是,我在向上汇报进度、向下分配任务时,心里非常有底——我知道每个模块的复杂度在哪,也知道谁有能力啃哪块硬骨头。坏处嘛……就是经常加班看代码(笑)。

问:你的教育背景里有“信息学”硕士,也有“计算机科学”本科,这些训练对你后来的工作帮助最大的是什么?

沈昊: 本科的CS训练给了我系统层面的思维——操作系统、计算机体系结构、编译原理,这些东西让我在写高性能代码时,能下意识地思考CPU缓存、内存布局、系统调用开销。后来做存储固件和分布式系统时,这些知识直接派上了用场。

硕士的“信息学”更偏向数据处理和信息基础设施,比如网络协议、数据库设计、云架构。那段学习让我补齐了后端工程化能力的短板——比如怎么做服务降级、怎么做分库分表、怎么设计高可用的微服务拓扑。

问:对于想走类似“后端+自动化+AI”路线的年轻工程师,你有什么建议?

沈昊: 三点吧。

第一,不要把“测试”看成二等公民的工作。好的测试平台本身就是一套复杂的分布式系统,它要有调度引擎、要有数据管道、要有分析后台,技术挑战一点不亚于业务系统。而且你做的东西直接决定产品发布速度和质量,成就感很直接。

第二,多接触实际的生产环境。很多问题只在真实负载下才会暴露——比如内存泄漏、连接池耗尽、日志风暴。如果你只在本地跑几个单元测试,永远看不到这些。

第三,保持对工具链的敏感度。我早年用Jenkins做持续集成,后来接触了GitHub Actions、Argo Workflows,现在又用上了LLM的Agent框架。技术工具在快速迭代,你得愿意不断跳出舒适区去学新东西。但也要记住,工具是手段,解决质量问题的思路才是根本。

问:最后一个问题,你未来几年想往哪个方向走?

沈昊: 我想把“AI辅助的自动化质量体系”这件事做得更深。现在LLM Agent还只是用于测试用例生成,但我觉得它可以延伸到更广的范围——比如自动分析测试结果、智能定位根因、甚至主动建议代码修复方案。

技术上讲,这需要融合代码分析、日志挖掘、和生成式推理;工程上讲,这需要打造一个能闭环反馈的持续优化系统。我觉得这个方向很有价值,也足够有挑战性,够我忙上好几年了。

免责声明：市场有风险，选择需谨慎！此文仅供参考，不作买卖依据。