# 1. 需求可测试性(Testability)分析方法，如何识别不可测试的需求？请列举五种常见的'不可测试需求'模式及改进建议。 A 模糊形容词（如"响应要快"）已足够可测 B 可测试需求须可观察、可判定、可量化、无歧义，模糊形容词、绝对化、主观表述等不可测模式需改为可量化可判定的标准 ✓ 正确答案 C 需求可测试性只影响开发不影响测试 D 所有需求天然可测
# 2. 评审的入口/出口准则（entry/exit criteria）如何设定，避免评审走过场与评审疲劳 A 评审无需材料预读即可开始 B 参与人数越多评审越有效 C 评审时长越长效果越好 D 入口准则（材料就绪、预读、准备度检查）与出口准则（问题清单、结论责任人）避免走过场，控制时长人数分块评审可避免疲劳 ✓ 正确答案
# 3. 评审会议的组织与过程控制，时长上限、参与人数、准备度检查与主持人职责如何提升缺陷发现率，并防止评审流于形式？ A 主持人无需控制节奏 B 评审人数越多发现缺陷越多 C 评审无需材料预读 D 控制时长与人数、强制材料预读与准备度检查、规范主持人职责（节奏/记录/结论）能提升缺陷发现率并防止流于形式 ✓ 正确答案
# 4. 评审度量（缺陷发现率、评审效率、缺陷密度）的计算方法和使用场景？如何用评审度量改进评审过程？ A 评审缺陷密度反映评审投入产出 B 评审度量与改进无关 C 单一评审度量即可全面评估 D 缺陷发现率评估发现缺陷能力、评审效率评估投入产出、缺陷密度定位薄弱区域，通过度量→分析→改进→再度量闭环优化评审 ✓ 正确答案
# 5. 静态分析工具(SonarQube/ESLint)在代码审查中的定位，它能发现哪些类型的问题？不能替代哪些人工审查活动？ A 静态分析能判断业务逻辑正确性 B 静态分析能发现规范、常见缺陷模式、复杂度与安全漏洞等规则化问题，但不能替代人工审查业务逻辑、架构与需求符合性 ✓ 正确答案 C 静态分析可完全替代人工代码审查 D 静态分析只用于安全测试
# 6. 同行评审(Peer Review)与正式检查(Inspection)的差异，Fagan Inspection 的角色分工（Moderator/Author/Reviewer/Scribe）、准备阶段和缺陷分类如何提升发现率？ A 同行评审比正式检查更结构化 B Fagan Inspection 有严格角色分工（主持人/作者/评审者/记录员）、准备阶段并经缺陷分类，其结构化流程显著提升缺陷发现率 ✓ 正确答案 C 正式检查无需角色分工 D 准备阶段会降低发现率
# 7. 静态分析在 CI 中的集成实践，SonarQube/ESLint/Semgrep 的规则定制、增量分析（只分析变更代码）和质量门禁(quality gate)的配置策略？ A 全量扫描是最佳做法 B 质量门禁越严越好 C 规则定制避免噪音、增量分析聚焦变更代码、质量门禁基于新增代码设置（如覆盖率、无严重问题）形成快速反馈闭环 ✓ 正确答案 D 静态分析可替代人工评审
# 8. 变异分析(Mutation Analysis)如何指导代码评审优先级，哪些模块的变异存活率高说明测试薄弱，应优先评审？ A 变异存活率越高说明测试越充分 B 变异存活率与评审优先级无关 C 变异存活率高说明测试对相应代码验证薄弱、缺陷隐藏风险大，应优先对这类模块安排深入代码评审 ✓ 正确答案 D 变异分析无需运行测试
# 9. 评审的类型，走查、技术评审与正式审查？ A 正式审查最非正式 B 走查非正式灵活、技术评审较正式评估技术正确性、正式审查（Inspection）最结构化以发现缺陷为主，三者正式程度递进 ✓ 正确答案 C 走查以发现缺陷为主要目标 D 技术评审最正式
# 10. 静态分析工具的规则分级与误报治理，如何把 warning/error 分级、抑制与反馈闭环落地 A 规则分级（blocker/critical/warning）聚焦处理优先级，误报用抑制白名单记录原因，并通过误报率反馈调整规则形成闭环 ✓ 正确答案 B 误报应全部忽略无需反馈 C 所有规则都应设为 error 级别 D 抑制注释无需记录原因
# 11. 代码评审中测试人员应重点检查哪些内容（可测性、断言完整性、边界处理、错误分支）？如何输出可执行的评审意见？ A 测试人员只关注测试用例数量 B 边界处理无需测试人员关注 C 评审意见可泛泛而谈 D 应重点检查可测性、断言完整性、边界处理与错误分支，并输出具体位置、问题与可操作建议的可执行评审意见 ✓ 正确答案
# 12. 需求评审、设计评审与代码评审的检查重点与典型缺陷类型差异，三者如何衔接形成分层评审防线？ A 三类评审检查重点完全相同 B 需求评审查完整性与可测性、设计评审查架构合理性、代码评审查实现正确性，三层评审逐层拦截不同层次缺陷形成分层防线 ✓ 正确答案 C 代码评审可覆盖需求缺陷 D 需求评审在后期进行
# 13. 静态分析为何难以发现跨模块语义、并发时序与业务规则类缺陷？人工评审与动态测试如何补位？ A 静态分析能发现并发时序问题 B 静态分析缺跨模块语义、运行时与时序理解，难发现跨模块语义、并发时序、业务规则缺陷，需人工评审与动态测试补位 ✓ 正确答案 C 静态分析能判断业务规则正确性 D 静态分析可覆盖所有缺陷类型
# 14. BDD(Behavior-Driven Development)中 Gherkin 场景的编写规范，如何避免场景过于技术化或过于模糊？ A 场景应避免技术实现细节（用业务语言）又避免模糊（前置与预期具体可判定），用 Given/When/Then 描述可执行的需求 ✓ 正确答案 B 场景无需明确预期结果 C 场景越模糊越好以保持通用 D 场景应写满技术实现细节
# 15. 架构适应度函数(Architecture Fitness Functions)，如何用自动化测试（ArchUnit/depcheck）持续验证架构约束（分层依赖、循环依赖、命名规范）？ A 用 ArchUnit/depcheck 等把架构约束写成自动化检查，在 CI 持续验证分层依赖、循环依赖、命名规范，防止架构腐化 ✓ 正确答案 B 架构约束只能靠文档人工维护 C 适应度函数无法自动化 D 架构约束无需持续验证
# 16. 评审的产出，问题清单与跟踪？ A 评审无需记录问题 B 问题清单只需记录问题数量 C 评审结论无需闭环 D 评审产出问题清单（描述/位置/类型/严重度/责任人/建议），通过跟踪机制与复查闭环确保问题被解决，否则评审失去意义 ✓ 正确答案
# 17. 静态分析左移的落地，IDE 插件、pre-commit 钩子与 PR 扫描三个环节如何分工，如何避免重复扫描与噪音？ A 三个环节都跑完整规则集 B 左移会降低问题发现率 C IDE 插件做编码时即时反馈、pre-commit 做提交前快速拦截、PR 扫描做合入前完整门禁，通过差异化规则配置避免重复扫描与噪音 ✓ 正确答案 D 静态分析只需 PR 扫描一个环节
# 18. 评审中「检查清单(Checklist)」驱动的评审与自由评审的效果差异？如何持续更新检查清单？ A 新人应使用自由评审 B 自由评审覆盖最全面 C 检查清单一旦建立无需更新 D 检查清单保覆盖不漏项但可能机械，自由评审灵活能发现新颖问题但依赖经验，两者常结合，清单需基于缺陷数据与漏检率持续更新 ✓ 正确答案
# 19. 远程/异步代码评审与同步评审会议的效率差异，异步评审的缺陷发现率如何保障？ A 异步评审一定比同步评审发现缺陷少 B 异步评审时间灵活可深度思考但讨论弱，同步评审即时互动但成本高，通过检查清单、评审 SLA、自动化辅助与关键变更同步可保障异步缺陷发现率 ✓ 正确答案 C 异步评审无需检查清单 D 同步评审无需控制参与人数
