- 日期：2026-05（面试月份）
- 企业与岗位：Certa｜测开-3多轮面试
- 适用层级：高级测开／自动化架构
本篇为社区对用户分享面经的整理汇编，旨在帮助求职者了解面试考察方向。问题部分力求忠实还原原帖问答脉络；「参考答案 / 复盘思路」为整理方结合工程实践原创补充，仅供交流参考，不代表官方标准答案。
面试问题与参考答案
1. 交流环节：HR初步沟通：经历、职业方向与岗位期望（交流环节）
参考答案 / 复盘思路
HR沟通主要用于核对岗位匹配、沟通能力、到岗和薪酬期望。应把过去项目中的技术贡献说清楚，避免把后续技术轮才会考察的细节提前编造成HR原题。对高级岗位，最好能用可量化的质量改进成果解释为什么要做自动化架构。
2. 考核方向：第一技术轮：两道编程题（原记录未披露具体题干）
参考答案 / 复盘思路
练习时应准备数组、字符串、哈希、数据转换与边界条件等常见编程能力，但不要宣称这些就是Certa的原题。真正的验收标准是输入输出明确、复杂度合理、异常输入有处理，并能口头解释方案取舍。提交前用空输入、重复值和大数据量做最小测试。
面试者只披露“两道编码题”而未给题干，因此练习材料应标为自拟。对于高级SDET，更能体现工程能力的是测试设计：例如如何为纯函数设计性质测试和异常路径。
3. 考核方向：第一技术轮：Selenium/Playwright自动化编码场景
参考答案 / 复盘思路
可用登录后检索、筛选和提交表单等场景练习：优先稳定定位、显式等待业务状态、隔离测试数据、失败截图和网络证据。Playwright侧重locator自动等待，Selenium通常需更明确地管理等待与驱动。两者都不能靠固定sleep解决异步竞态。
可进一步检查网络mock是否与真实接口契约一致、并行执行是否争抢同一账号。若自动化测试只能在本地跑通而无法在CI稳定运行，框架设计仍不算完整。
4. 考核方向：第一技术轮：自动化框架设计与实现
参考答案 / 复盘思路
推荐按测试层级、页面/接口客户端、数据工厂、环境配置、断言、报告和CI适配划分模块。框架应能并行运行、支持失败重试但保留原始失败、隔离账号与数据。设计时先用一个高价值流程做端到端POC，再扩展到不同浏览器和环境，避免先造过度复杂的抽象。
框架应明确哪些层能复用、哪些不能：例如页面对象负责操作语义，断言应尽量贴近业务规则；公共fixture只管理生命周期，避免把所有逻辑塞进一个BaseTest。
5. 考核方向：第一技术轮：阅读并解释CI/CD相关代码片段
参考答案 / 复盘思路
先说清触发条件、构建与依赖安装、测试分层、并行矩阵、凭证注入、制品与失败门禁。审查时重点找凭证泄露、缓存污染、共享测试数据、错误的allow-failure以及只看脚本退出码不看报告等风险。可建议为每次运行绑定commit SHA和环境版本，保证失败可回放。
可以设计一次故障注入：让依赖安装失败、测试用例返回非零退出码或报告上传超时，检查流水线是否正确标红。只在“全绿”场景跑通不代表CI集成可靠。
6. 考核方向：第二技术轮：端到端自动化测试方法
参考答案 / 复盘思路
E2E覆盖关键业务链路而非堆积页面点击，需确认测试前置数据、外部依赖、支付或通知副作用以及最终状态。合理划分单元、接口、契约与少量关键E2E，避免全量UI测试拖慢发布。对不稳定第三方系统用受控mock做主回归，再安排少量真实集成验证。
例如一条审批流可能横跨身份服务、业务API和通知系统；关键验收应覆盖最终审批状态和消息去重。E2E无法穷举所有边界，因此还需用接口测试覆盖异常组合。
7. 考核方向：第二技术轮：从手工测试向自动化迁移
参考答案 / 复盘思路
先盘点高频、稳定、可重复且有清晰预期的用例，评估收益和维护成本。迁移顺序一般先接口与核心回归，再补少量UI；对探索性测试和体验判断保留人工。衡量迁移成效应看回归耗时、漏检率、误报率与维护工时，不应只汇报自动化覆盖条数。
迁移时建议先建立用例稳定性基线，区分“重复但价值低”的用例与“手工成本高且高风险”的用例。只有把维护成本算进去，自动化ROI才可信。
8. 考核方向：第二技术轮：QA流程中的CI/CD集成
参考答案 / 复盘思路
把快速单测与静态检查放在PR阶段，接口和契约回归放在合并前，较慢的E2E与兼容性测试放到夜间或发布候选阶段。失败门禁需分级，阻断真正的产品缺陷，隔离已确认的环境波动。构建、镜像、数据集和报告都要有版本标识，方便回溯。
PR门禁还应设置最大执行时长与失败证据保存策略，避免测试无限挂起。对外部依赖不稳定的用例，可独立成非阻断监控，但必须保留缺陷跟踪责任。
9. 考核方向：第二技术轮：问题定位和调试思路
参考答案 / 复盘思路
从现象、复现条件和最近变更入手，按浏览器、API、数据库、消息队列与外部依赖分层采集证据。用请求ID关联trace与日志，先确认是产品缺陷还是测试数据、环境和脚本问题。每次排障记录假设、验证实验与结论，避免只通过重跑掩盖根因。
如果错误只在CI出现，应对比环境变量、时区、CPU资源、网络出口、依赖版本与并发数；先缩小差异再动测试脚本。频繁重试只能帮助确认概率，不能替代根因分析。
10. 考核方向：第二技术轮：冲突场景与困难处理
参考答案 / 复盘思路
高级SDET要说明如何用事实和风险优先级推动共识：复现步骤、用户影响、概率、回滚方案与验证成本。与研发对“是否阻断发布”意见不同，可以先对齐验收规则，必要时给出带证据的风险接受建议。不要把团队沟通问题回答成个人情绪宣泄。
可以给出一个“上线前发现支付幂等问题”的讨论模板：先确认复现频率与金额风险，再讨论是否可灰度、回滚与增加监控。目标是可审计的质量决策，而不是谁声音更大。
11. 考核方向：第二技术轮：AI在测试中的使用和提效
参考答案 / 复盘思路
AI适合辅助生成候选用例、脚本草稿、日志聚类与失败分析，但预期结果必须来自需求或人工确认的规则。应测量采纳率、有效缺陷发现率、误报率和审阅时间。对模型输出做代码审查、最小可复现验证和权限限制，防止AI把产品错误写成测试通过。
可以用缺陷注入验证AI方案：故意改变一个关键业务断言，观察AI生成用例是否能发现错误。若AI把真实错误解释为正常行为，应记录为评测失败并加入回归集。
12. 考核方向：管理视角轮：优先级、风险评估与利益相关方协作
参考答案 / 复盘思路
用影响面×发生概率×可检测性建立风险排序，结合发布时间、测试成本与回滚能力确定最小放行集。沟通时分别向产品解释用户影响，向研发提供复现证据，向管理者报告剩余风险和明确决策人。高质量的答案需要说明取舍依据，而不是一律“全部测完再发”。
建议输出一张风险清单，列出阻断项、可接受项、责任人、回滚预案和验证时间点。面试官想看到的是工程判断与沟通闭环，不是脱离约束的理想化流程。
13. 考核方向：最终轮：项目成果、合作方式和AI应用讨论
参考答案 / 复盘思路
准备一个真实的质量改进案例，交代基线、技术动作、结果指标和失败教训。谈AI时既要讲提效，也要讲审阅责任、数据合规和错误传播风险。原记录属于整体考核方向，不能声称面试官逐字提出了某个未披露的问题。
量化指标要讲口径：例如回归时间从90分钟降到30分钟，必须确保比较的是相同业务范围和稳定环境。也应报告新增误报与维护成本，避免只呈现漂亮的收益数字。
延伸思考（社区补充）
如何证明AI生成的自动化脚本确实能发现真实缺陷，而不只是把测试通过率做高？
