# 1. 测试框架选型考量，从团队技能、项目类型、生态集成、维护成本四个维度如何评估？ A 选功能最强大的框架即可 B 只应看团队技能 C 从团队技能、项目类型、生态集成、维护成本四维评估并结合 POC 验证 ✓ 正确答案 D 框架选型与维护成本无关
# 2. 测试框架与 CI 的适配设计，如何利用框架的钩子/扩展机制（pytest hooks、JUnit Extensions、Jest reporters）在 CI 中实现报告聚合、失败分类与重试？ A CI 应直接解析每个测试的内部实现 B 重试后应直接标记为通过 C 报告无法聚合 D 利用框架钩子/扩展生成统一报告、做失败分类与重试标记，CI 消费统一结果 ✓ 正确答案
# 3. 测试执行环境的容器化，Docker 中运行测试的依赖、时区、网络与资源限制问题如何处理 A 需固化依赖、显式设置时区、配置网络拓扑并限制匹配资源，保证环境一致 ✓ 正确答案 B 容器内网络总是可达 C 容器默认时区与本地一致，无需处理 D 资源无需限制
# 4. 测试在 CI 流水线中的分层执行策略，单元测试→集成测试→E2E 测试的触发条件和失败处理？ A 单元测试每次提交跑、集成测试按变更触发、E2E 后置，前层通过才进后层 ✓ 正确答案 B E2E 失败一律阻断 C 分层执行与反馈速度无关 D 每次提交都先跑全量 E2E
# 5. 测试分片(Test Sharding)策略，如何按执行时间、文件依赖或历史失败率进行分片？分片不均匀（straggler problem）的解决方案？ A 分片不均不影响整体 B 按文件平均分片总是均衡 C 按执行时间/失败率加权分片，并用动态调度缓解 straggler 问题 ✓ 正确答案 D 分片只能按文件
# 6. 测试重试策略的设计原则，区分 flaky 重试与确定性失败、重试次数上限、重试后结果标记（flaky vs passed）的工程实践？ A 区分可重试的 flaky 与确定性失败，设上限，重试通过后标记 flaky 而非 passed ✓ 正确答案 B 重试次数应无限 C 重试后应直接标记为通过 D 所有失败都应重试
# 7. CI 中的测试缓存机制，Jest 的 --cache、Turborepo 的 remote cache、Bazel 的 remote execution 如何加速测试执行？缓存命中率的度量？ A 缓存与输入无关 B Jest/Turborepo/Bazel 按输入哈希复用未变任务的测试结果，命中率衡量缓存有效性 ✓ 正确答案 C 缓存命中率无需度量 D 缓存键包含越多文件越好
# 8. 失败用例的观测增强，截图、日志、堆栈与视频自动归档，如何在 CI 中一键定位失败根因 A 证据无法自动化 B 只需记录失败断言信息 C 失败时自动归档截图、视频、日志、堆栈并关联元数据，CI 中一键定位根因 ✓ 正确答案 D 日志归档无需关联用例
# 9. CI 中测试的超时与并发控制，流水线超时、测试集群资源池划分与排队策略 A 设置超时防挂死、资源池划分保隔离、优先级排队保公平（带各池并发上限） ✓ 正确答案 B 超时越久越好 C 无需限制并发 D 排队无需优先级
# 10. JUnit5/pytest/Jest 的并行执行与隔离机制对比，进程级 vs 线程级并行的资源竞争与结果确定性如何保证？ A 线程级并行天然无竞争 B 所有框架并行方式相同 C 并行执行无需隔离 D 进程级隔离强开销大、线程级快但易竞争，结果确定性依赖用例彻底隔离 ✓ 正确答案
# 11. 测试执行时长的治理，如何用耗时分布识别慢用例，并通过拆分、降级与并行压缩关键路径反馈时间？ A 用耗时分布识别慢用例，通过拆分、降级、并行治理，并压缩关键路径反馈时间 ✓ 正确答案 B 所有用例都必须跑关键路径 C 慢用例只能等待 D 时长治理无法监控
# 12. CI 中测试执行的确定性，用例间的隐式顺序依赖如何识别与治理？随机化执行顺序如何暴露脆弱用例？ A 测试顺序依赖无需处理 B 用例共享全局状态没问题 C 随机化执行顺序暴露隐式依赖，配合用例独立数据/清理共享状态来保证确定性 ✓ 正确答案 D 顺序依赖无法识别
# 13. 构建-测试-缺陷的可追溯链，如何把代码提交、构建产物、测试结果与缺陷报告串联，失败时快速定位引入变更？ A 用提交哈希、构建号、测试报告、缺陷记录互相引用，失败时沿链回溯定位引入变更 ✓ 正确答案 B 各环节无需关联 C 失败无法定位到提交 D 可追溯链只用于审计
# 14. '重试 3 次'策略为何会掩盖真问题？如何设计合理的测试重试机制？ A 无差别重试会掩盖确定性失败，应只对可重试失败重试、设上限并标记 flaky ✓ 正确答案 B 重试次数越多越好 C 重试后不用标记 D 重试 3 次能可靠发现所有问题
# 15. 多项目/多语言的测试报告聚合，如何将不同框架（JUnit/pytest/Jest）的结果统一为标准格式（JUnit XML/TAP）并生成全局质量看板？ A 各框架格式无需统一 B 看板只能看单项目 C 无法跨语言聚合 D 先将各框架结果转为 JUnit XML/TAP 标准格式，再聚合 schema 生成全局质量看板 ✓ 正确答案
# 16. CI 测试环境的搭建，自托管 Runner 与托管 CI（GitHub Actions/GitLab CI）在依赖缓存、网络与成本上的取舍？ A 自托管 Runner 永远更好 B 托管 CI 省运维但缓存/内网受限，自托管网游可控、缓存持久但需运维，按规模与内网依赖取舍 ✓ 正确答案 C 托管 CI 网络总是可控 D 两者完全等价
# 17. 测试失败通知与分级告警，钉钉/Slack/邮件通知的触发条件、分级与责任人路由如何设计？ A 所有失败都立即全员通知 B 无需路由到责任人 C 按严重度分级、按变更归属路由到责任人、flaky 汇总免打扰，避免告警疲劳 ✓ 正确答案 D 告警越多越好
# 18. CI 流水线的软失败与硬失败，性能、视觉等非阻断测试如何独立标记，避免软失败掩盖真实回归？ A 软失败应完全忽略 B 所有失败都应软失败 C 关键回归用硬失败阻断，性能/视觉等非关键用软失败独立标记并通过阈值升级与趋势监控防掩盖 ✓ 正确答案 D 软失败无需追踪
