# 1. 测试驱动开发（TDD）的红-绿-重构循环与工程实践 A Red 阶段要求测试通过，Green 阶段要求测试失败，保证测试有效 B Red 阶段先写一个失败的测试，Green 阶段用最小实现让其通过，Refactor 阶段在测试保护下改进设计 ✓ 正确答案 C 三个阶段的顺序可以任意调整，只要最后测试通过即可 D 重构阶段必须重写所有测试以匹配新实现
# 2. 行为驱动开发（BDD）的 Gherkin 语法与活文档 A Given 表示动作，When 表示前置条件，Then 表示期望结果 B Feature 文件既是需求规格又是可执行测试，并自动生成文档，称为活文档 ✓ 正确答案 C Gherkin 只用于记录文档，不参与测试执行 D 谓词 Given/When/Then 必须与具体实现代码一一对应且不能有占位符
# 3. 测试覆盖率度量中行覆盖、分支覆盖与变异覆盖的差异 A 变异覆盖能检验测试能否发现代码微小改动引入的缺陷，比行覆盖和分支覆盖更强 ✓ 正确答案 B 行覆盖是衡量测试质量的最强指标 C 分支覆盖只能统计代码行的执行比例，无法区分条件分支 D 三种度量相互独立，没有任何强弱关系
# 4. 契约测试（Pact）在微服务架构中的工程落地 A 消费者定义契约并发布到 Pact Broker，Provider 端验证契约后即可安全发布，避免频繁真实联调 ✓ 正确答案 B 契约测试替代了所有 E2E 测试，无需再验证真实链路 C 契约测试只能通过真实服务联调验证，无法在 CI 中执行 D 契约文件一旦生成便永久有效，无需版本管理
# 5. 属性测试（Property-Based Testing）与 QuickCheck 模式 A 属性测试要求测试者手工列出所有可能的输入和输出 B 反例收缩会让测试范围无限扩大，无法收敛 C 属性测试只适用于纯函数，无法用于任何业务逻辑 D 测试者声明属性，由框架自动生成大量随机输入验证，并在失败时收缩成最小反例 ✓ 正确答案
# 6. 测试代码的可读性与维护性中 Given-When-Then 模式 A 该模式只用于 BDD 的 Gherkin 文件，不适用于代码级单元测试 B 三段式结构要求每个测试只能有一个断言，否则无法通过 C 通过 Given 准备、When 动作、Then 断言的三段结构和 Builder/夹具减少重复，可提升可读性与可维护性 ✓ 正确答案 D 命名应尽量描述内部实现细节，方便调试
# 7. 测试脆弱性（Flaky Test）的识别、分类与治理 A 识别后应优先消除根因（用轮询等待替代 sleep、注入 Clock/Random 保证确定性），并快速从门禁中隔离避免阻塞 CI ✓ 正确答案 B Flaky Test 说明测试代码本身可靠，只是 CI 机器性能问题 C 对 flaky 测试唯一正确的做法是删除，无需分析原因 D 增加固定的 sleep 时间可以彻底解决所有时序类 flaky 问题
# 8. 测试金字塔中单元、集成与 E2E 测试的比例和分层策略，各层的速度、稳定性与故障定位差异？ A 单元测试数量最多、速度最快、最稳定，故障定位最精确，应承担大部分验证责任 ✓ 正确答案 B E2E 测试故障定位最容易，因为它覆盖了完整链路 C 集成测试比单元测试更稳定，比 E2E 更快 D 各层测试数量应平均分配，才能保证质量
# 9. 测试代码的 Code Review 标准与最佳实践中可读性、独立性、运行时间如何设门槛？ A 测试代码应专注于提高覆盖率，可读性和运行时间无关紧要 B 测试越慢越能发现真实问题，不应对运行时间设门槛 C 测试只要运行通过就不需要评审 D 评审应关注可读性、独立性（不依赖执行顺序与共享状态）、运行时间与断言质量，并配合自动化门槛 ✓ 正确答案
# 10. 变异测试（Mutation Testing）的原理与 pitest/stryker 实践 A 变异测试成本极低，可以全量无条件地对所有模块执行 B 变异测试与覆盖率度量完全相同，都只统计代码被执行的百分比 C 变异测试通过修改代码生成变异体，用测试杀死它们，变异评分能反映测试有效性 ✓ 正确答案 D 变异体存活说明代码没问题，测试越少越好
# 11. 测试替身（Test Double）中 Mock/Stub/Fake/Spy 的选型边界 A Stub 和 Mock 都可以验证交互，用途完全相同 B Spy 只提供数据，不记录任何调用 C Fake 就是 Mock 的别名，二者等价 D 只需要提供数据让流程走通时用 Stub/Fake，需要验证交互时用 Mock/Spy，Fake 是带真实行为的轻量实现 ✓ 正确答案
# 12. 测试数据管理中工厂模式、Builder 与测试夹具 A 工厂、Builder、Fixture 三者的实现完全相同，用法无差别 B 测试数据越复杂越好，能覆盖更多情况 C 每个测试都应完整手写所有对象的初始化代码，以保证准确 D 用 Builder/工厂的默认值吸收无关字段、Fixture 复用公共上下文，可让测试只突出与意图相关的差异 ✓ 正确答案
# 13. 测试覆盖率的质量门禁与合理阈值设定 A 覆盖率越高，测试质量一定越高，应一律设 100% B 覆盖率门禁只统计行数，与分支、变异无关 C 应避免一刀切阈值，按模块风险分级，并用增量覆盖率校验分支/变异，防止测试倒退 ✓ 正确答案 D 只要覆盖率达标，无论断言多弱都算通过
# 14. 测试报告的可视化与趋势分析 A 测试报告只需显示最终通过/失败数量，无需分析趋势 B 覆盖率不随时间变化，无需纳入趋势分析 C 趋势分析只对单次构建有效，历史数据没有意义 D 通过汇总看板、失败详情与跨时间趋势监控，可发现 flaky、退化与耗时膨胀，驱动持续改进 ✓ 正确答案
# 15. 单元测试的"断言质量"中如何避免断言过弱（只验证非空）或过强（耦合实现细节）？ A 断言只验证非空即可，测试便足够可靠 B 断言越强越好，把内部调用细节都断言出来 C 应断言被测单元的对外契约行为，避免过弱（只验证非空）也避免过强（耦合实现细节） ✓ 正确答案 D 断言数量越多，测试质量越高
# 16. 测试隔离中共享数据库与静态状态的顺序依赖如何破坏确定性，随机化执行顺序如何暴露问题？ A 共享静态状态和数据库不会影响测试结果，因为测试彼此独立 B 共享可变状态产生顺序依赖，破坏确定性；随机化执行顺序可暴露此类问题，修复应让每个测试自包含 ✓ 正确答案 C 随机化执行顺序会引入全新 bug，应禁止使用 D 顺序依赖只影响测试速度，不影响正确性
# 17. 测试命名与失败信息中 should/when 命名风格与断言信息如何让失败一目了然？ A should/when 命名描述"行为+条件"，配合描述期望/实际的断言消息，可让失败一目了然 ✓ 正确答案 B 测试方法名和断言消息对失败定位没有帮助，调试只能靠断点 C 测试命名越短越好，`test1` 即可 D 断言不需要消息，框架会自动生成足够清晰的信息
# 18. 测试左移（设计期/CI）与右移（生产验证）如何结合，各自的度量与工具如何选择？ A 左移比右移更高级，有左移就不需要右移 B 左移在开发/CI 阶段尽早发现缺陷，右移在生产用金丝雀/监控/混沌验证真实行为，二者互补形成完整质量保障 ✓ 正确答案 C 右移取代左移，所有测试都应放到生产进行 D 左移和右移是同一阶段的两种叫法
# 19. AI 生成测试的覆盖盲区如何用变异测试补足，成本如何控制？ A AI 生成的测试已经覆盖所有边界与异常，无需补充 B 变异测试通过存活变异体暴露 AI 测试的覆盖盲区，并可通过范围限制、增量、抽样、超时控制成本 ✓ 正确答案 C 变异测试的成本远低于普通测试，可全量无条件执行 D 变异测试只统计代码行数，无法定位盲区
# 20. 测试执行的分层与时间预算中 PR 快速集与夜间全量如何划分，超时测试如何治理？ A PR 阶段应运行全部测试包括所有 E2E，以保证每次改动都全量验证 B 测试执行越快越好，夜间全量测试没有意义 C PR 快速集跑单元/关键集成/契约测试以保证分钟级反馈，夜间全量跑慢速深度测试，超时测试要拆分、降级、标记治理 ✓ 正确答案 D 超时测试应直接删除，无需优化
