面灵AI→

恒生电子 测试开发一面(10.9)

轮次
一面
时间
2026-10
来源
牛客网

《面试题目》

  1. 自我介绍。
  2. 学校项目的盘问:具体流程以及你负责的模块是什么?
  3. 集创赛项目的具体流程以及你负责的模块是什么?
  4. 实习中有用过 AI 相关的工具吗?
  5. 你用自制压测工具的情况是怎么样的?
  6. 学习和工作中遇到的难解决的问题是什么,如何解决的?
  7. 实习中关于测试的工作是否是黑盒?
  8. 你对数据库的了解有多少?
  9. 你对恒生的了解有多少?
  10. 家是哪里的?
  11. 反问:具体的测试工作(不同部门负责的部分不一致,有专门负责功能测试的、也有专门负责性能等非功能测试的);具体结果发布时间(要等 HR 统一流程)。

《参考解析》

项目盘问的答法是「一句话说清项目做什么 → 我负责的模块 → 模块的输入输出与关键接口 → 我遇到的坑和怎么验证」。测试岗特别看重「负责的模块」能不能说细,因为这会直接引出「你怎么测它」。以集创赛这类竞赛项目为例,要能说清:团队几个人、我负责哪一块(硬件/驱动/算法/上位机)、模块之间的接口是什么(串口协议?HTTP?共享内存?)、我怎么验证自己的部分(单元测试、对拍、长时间跑数据比对)。面试官通常会追问两个方向:一是「这个模块的边界条件你测过哪些」,二是「如果换一种实现会怎样」——准备时把测试边界列出来(空输入、超范围值、并发、异常断连、长时间运行),比只讲功能实现得分高。

**「实习的测试是不是黑盒」**要答得准确:黑盒测试指不关心内部实现、只依据需求和接口设计用例(等价类划分、边界值、判定表、场景法、错误推测);实际实习里大多是「以黑盒为主、辅以灰盒」——做接口测试时要看日志和数据库确认链路,做性能测试时要看服务端指标,做问题定位时要读代码或加日志。如果能说出自己在实习里做过哪些非功能测试(接口自动化、性能/压测、兼容性、稳定性、数据校验),以及自动化框架是怎么搭的(用例管理、数据驱动、报告、CI 集成),会显著加分。要避免的答法是「我做的就是点点点」——即便真的以手工为主,也要讲清你如何设计用例、如何保证覆盖率、如何做缺陷跟踪与回归。

自制压测工具是很好的展开点,因为能同时体现编码能力和测试理解。结构上应该能讲:用什么写的(Python + 多线程/asyncio,或 Go,或 JMeter 的 Java Sampler)、怎么控制并发(线程池 / 协程 / 令牌桶限流发压)、怎么统计指标(TPS、成功率、P50/P95/P99 时延——用 time.perf_counter() 记录每个请求耗时后排序取分位,而不是只算平均)、怎么生成测试数据、怎么做结果对比。要主动说清楚它的局限:单机压测容易自己被 CPU/网络打满导致压不上去(要先确认压测机水位,或用多机分布式)、客户端开销(统计和日志)会污染结果、没有做连接复用和预热会导致首轮数字偏低。以及「怎么用它得出结论」:找到 TPS 随并发变化的拐点、确认瓶颈在服务端还是压测端,这些比工具本身更重要。

数据库了解程度按「会用 → 会查 → 会调」三层准备。会用:建表与常见类型选择、主键/唯一/外键/索引、INSERT/UPDATE/DELETE/SELECT、JOIN 与分组聚合、事务与隔离级别。会查:EXPLAIN 看执行计划(type、rows、key、Extra 里的 Using filesort/Using temporary)、慢查询日志、联合索引与最左前缀、索引失效的常见情形(列上做函数、隐式类型转换、LIKE '%x')。会调:分页深翻优化、覆盖索引避免回表、读写分离与缓存、数据归档。测试岗常见的落点是「做数据校验」——比如造数据、比对上下游表的数据一致性、写 SQL 做对账,能举出一个具体例子(「我用一条 SQL 比对过 A 表和 B 表的差异,发现是某类订单没同步」)比背概念有效。

**「对公司的了解」**别只说「大公司、平台好」。恒生电子的关键词是金融科技(券商、基金、银行的核心业务系统,如 UF2.0、O45 这类产品线)、B 端项目制交付、客户是金融机构因此对稳定性和合规要求极高、总部在杭州。答题时可以把自己的取向接上:「金融系统的特点是变更谨慎、对回归测试和数据一致性要求高,这正好是我做测试想积累的方向」,并且结合面试官透露的信息(测试按部门分工,有功能测试也有性能等非功能测试)表达对岗位的具体理解。AI 工具那一问如果能给出真实用法会更有说服力:用 AI 生成测试用例草稿并人工筛选、用 AI 辅助写自动化脚本和定位报错、用 AI 做日志聚类找异常模式——同时说清边界(生成的用例必须人工评审,不能替代对业务的理解)。

**「难解决的问题」和「家是哪里的」**分别是行为题和稳定性考察。前者用 STAR 讲一个有技术含量的排查故事:现象(比如压测时 TPS 上不去、或者某接口偶发超时)→ 怎么缩小范围(单接口复现、看服务端指标、对比正常和异常请求)→ 根因(连接池打满 / 慢 SQL / 锁竞争 / 压测端瓶颈)→ 改法与验证(改完复测数字对比)。后者如实回答即可,如果家在本地或邻近城市,直接说明这是选择这家公司的一个加分项,回答要干脆,不要含糊。