- 日期：2025-12-20
- 企业与岗位：未披露企业｜Senior SDET相关讨论
- 适用层级：高级
内容说明
内容说明
本篇为社区对用户分享面经的整理汇编，旨在帮助求职者了解面试考察方向。问题部分力求忠实还原原帖问答脉络；「参考答案 / 复盘思路」为整理方结合工程实践原创补充，仅供交流参考，不代表官方标准答案。
原分享主要记录实操要求或考察方向，下文列出的是任务要点，并非面试官逐字提问。
一、原帖涉及的考核任务/方向（4项）
1. 算法题（LeetCode类型，未披露具体题目）。
参考答案 / 复盘思路： 原分享只提到LeetCode类型算法题，没有披露具体题目，所以不能把任何一道算法题写成该公司原题。备考可覆盖数组、哈希、滑动窗口、链表和树等常见结构，并训练先问清边界、再解释复杂度、最后写可测试代码的表达。对高级SDET而言，算法之外还要展示如何为算法设计测试样本：空输入、重复值、极端规模、随机对拍和复杂度退化。答题时说清输入规模与时间空间约束，比死记题解更重要。
2. 给定一个系统，说明如何设计测试策略。
参考答案 / 复盘思路： 面对陌生系统先问业务关键路径、用户角色、数据流、非功能目标及外部依赖，画出高风险边界。测试策略可按单元/组件、API契约、集成、E2E和生产监测分层组织，并说明每一层主要发现什么问题。支付、权限、库存、幂等和故障恢复等高风险场景应有独立验证。对大系统还需要质量门禁、环境隔离、测试数据、观测指标与回滚方案。高级岗位的关键不是罗列很多测试类型，而是说明在时间和资源有限时为什么优先这些验证。
3. 怎样拆分不同层次的测试？
参考答案 / 复盘思路： 分层原则是尽量把确定性、廉价且高频的验证放低层，把少量真正需要用户视角的业务链路放高层。单元测试覆盖局部规则，契约测试验证服务接口边界，集成测试检查多服务交互，E2E验证关键旅程。拆分时要避免各层重复断言同一实现细节，也不能一味降低UI测试数量导致重要前端交互无人覆盖。面试可举一个登录加权限变更案例，说明前端显示、接口鉴权和数据隔离分别在哪层测试，层次就会很具体。
4. 不同测试如何安排进入CI/CD流水线？
参考答案 / 复盘思路： 按反馈速度和风险安排流水线：每次PR运行静态检查、单元测试和快速契约/API冒烟；合并后运行跨服务集成与核心E2E；夜间或发布前运行全面回归、性能及高成本故障注入。高风险功能可以配置强制门禁，非关键的不稳定用例应单独治理而不是长期忽略。质量报告需要能追溯代码版本、环境、测试数据与失败证据。若业务包含Agent，还可把固定评测集的快速用例放在PR，把多次采样和全量评测放夜间，但这是社区延伸，不是原帖逐字原题。
延伸思考（社区补充）
一个Agent评测项目调用成本较高，团队应该如何决定哪些测试放进每次PR检查，哪些安排夜间回归，又有哪些适合在模型版本升级时执行？
思考方向： 可根据风险、成本、反馈时效和样本稳定性分层：PR跑低成本高价值基准，夜间扩大覆盖，版本升级做完整专项评测。
参考链接
https://www.reddit.com/r/QualityAssurance/comments/1pr59cn/
