- 日期：未公开
- 企业与岗位：Prophecy AI｜Senior SDET
- 适用层级：高级
本篇为社区对用户分享面经的整理汇编，旨在帮助求职者了解面试考察方向。问题部分力求忠实还原原帖问答脉络；「参考答案 / 复盘思路」为整理方结合工程实践原创补充，仅供交流参考，不代表官方标准答案。
技术面｜约1小时
1. 现场编程：实现支持type、undo、redo的简单文本编辑器
参考答案 / 复盘思路：
可用字符列表维护当前文本，再用两个栈管理已执行操作和可重做操作。最简单实现是维护状态快照历史，便于正确性验证但空间成本较高；更工程化的是把每次编辑建模为可逆命令。undo回退最近一次可撤销操作，redo重新执行；在undo后发生新type时必须清空redo栈。测试覆盖空文本撤销、连续撤销、连续重做和分叉历史。实现时要提前说明时间复杂度与历史上限：若每次保存全文快照，长文本编辑会放大内存；若采用命令模式，需确保逆操作在删除、替换等未来扩展下仍可逆。还可用属性测试随机生成命令序列，校验undo/redo不会破坏状态不变量。
2. 针对文本编辑器补充边界测试
参考答案 / 复盘思路：
至少覆盖空栈undo/redo、重复redo、undo超过历史长度、输入空字符或Unicode字符、连续输入后多次撤销，以及undo后重新type导致redo失效。建立状态模型作为oracle：每执行一条命令都比较实际文本与模型文本。若系统允许多字符输入，需明确撤销粒度是字符还是命令，不能默认两者相同。边界测试不应只写示例列表，还可以构造一份参考状态机，逐步生成随机命令并比较每一步文本；同时检查redo历史是否按规则被清除。若出现崩溃或重复执行，保存最短失败命令序列，便于定位历史栈更新顺序的问题。
3. 如何测试类似Jenkins的调度器系统？
参考答案 / 复盘思路：
先按任务创建、触发、排队、执行、重试、取消和完成状态建模。覆盖定时表达式、时区与夏令时、重复触发、节点故障、执行超时和任务依赖。用可控时钟模拟跨天边界，用事件日志核对每次触发是否恰好执行一次或满足约定的至少一次语义。对失败重试，验证幂等性与状态最终一致性。对于分布式调度，必须先和业务确认交付语义：at-most-once可能丢任务，at-least-once可能重复，所谓exactly-once通常要靠幂等副作用和事务边界实现。模拟数据库短暂不可用、worker心跳丢失和领导者切换，检查任务不会永久卡在运行中。
4. 调度器有哪些测试场景？
参考答案 / 复盘思路：
从功能、并发、容错和安全四个维度展开：Cron合法性与非法表达式、同一任务并发上限、优先级饥饿、队列积压、节点宕机迁移、重复消息、取消与重试竞争，以及不同租户的任务隔离。性能测试看排队时延P95、调度漂移和执行成功率。关键是检查“任务状态”和真实副作用是否一致。建议建立状态转移表，把“已排队→运行中→成功/失败/取消”以及非法跳转写成断言。并发用例要能重复触发相同竞争窗口，可使用屏障同步而非随机sleep。若系统支持优先级，需统计低优先级任务在高负载下的最长等待时间。
5. 调度平台自动化测试怎么规划？
参考答案 / 复盘思路：
将纯逻辑的时间计算与状态迁移放在单测，调度API和持久化放在集成测试，少量端到端验证任务实际运行。通过Fake Clock和Fake Worker控制时间与执行结果，避免依赖真实等待造成慢测；并在CI中加入多节点竞争和故障注入。对定时任务保留事件ID、traceId与状态轨迹，方便复现偶发问题。执行环境尽量容器化，并把队列、数据库和worker版本固定，防止CI与本地行为不一致。每个测试使用独立任务ID与命名空间，结束时清理未完成任务；在每日构建里跑随机故障序列，对状态机违例生成可复现种子。
6. 自动化框架维护的挑战、可靠性和扩展性如何解决？
参考答案 / 复盘思路：
常见难点包括测试数据污染、环境漂移、脆弱定位器、并发竞争与外部依赖不稳定。设计时把用例、数据、驱动和报告解耦；使用隔离环境、确定性等待与可控Mock，并对失败按产品缺陷、环境故障和脚本缺陷分类。扩展并发前先评估共享资源瓶颈，跟踪flaky率、重跑成本和CI反馈时间，而非只追求用例数量。稳定性治理先做失败分类而不是提高重跑次数：定位器变化、网络抖动、共享账号污染和真实产品缺陷对应不同处理方式。指标上同时追踪首次通过率、重跑后通过率、平均定位耗时和用例维护工时，避免“绿灯多了”却掩盖真实缺陷。
延伸思考（社区补充）
延伸问题：
如果调度器在节点宕机时重新派发任务，怎样区分重复执行、幂等副作用和任务丢失？
复盘思路：
先明确业务状态机、幂等与失败恢复的可观测证据，再设计可重复执行的故障注入；对最终状态采用业务对账断言，不以单一页面提示或HTTP状态码判定成功。
·# 推荐学习
