# 1. Cyclomatic Complexity（圈复杂度）与 Cognitive Complexity（认知复杂度）的差异；为何 SonarQube 切换到认知度量对深层嵌套的缺陷更敏感 A 两者计算方式完全相同，只是命名不同 B 认知复杂度只统计 if 语句，不统计循环与异常 C 圈复杂度比认知复杂度更能反映代码的可读性 D 认知复杂度对嵌套结构加权，能更敏感地反映深层嵌套带来的认知负担 ✓ 正确答案
# 2. NPath 复杂度与 Halstead 复杂度的工程价值；如何在 CodeScene、CodeMR 中作为热力图识别重构候选 A NPath 复杂度与圈复杂度数值永远相等 B Halstead 复杂度衡量的是运行时性能 C 热力图只反映代码行数，与复杂度无关 D NPath 复杂度统计函数所有可能执行路径的数量，可反映路径组合爆炸 ✓ 正确答案
# 3. 单函数圈复杂度的项目门限（一般 10、关键模块 5）的合理性 A 所有模块的门限必须完全相同 B 一般项目单函数门限为 10，关键模块为 5，体现按风险分级治理 ✓ 正确答案 C 圈复杂度门限越高越好，代表代码越高效 D 圈复杂度门限主要由代码行数决定
# 4. 代码度量的相关性验证中如何用历史缺陷数据验证复杂度、变更频率与缺陷密度的相关性，避免凭直觉设定阈值？ A 阈值应完全凭专家经验设定，无需数据验证 B 缺陷密度与复杂度无关，无需分析 C 通过历史缺陷数据与复杂度、变更频率的相关性分析，可数据驱动地设定并校准阈值 ✓ 正确答案 D 变更频率越高代表代码质量越好
# 5. ISO/IEC 25010（SQuaRE 产品质量模型）的八大特性（功能适合性、性能效率、兼容性、易用性、可靠性、安全性、可维护性、可移植性）如何逐一映射到可落地的工程度量（覆盖率、复杂度、缺陷密度、SLO、SAST/SCA 结果、依赖新鲜度），并据此设计平衡的质量看板？ A 八大特性只有可维护性一项有对应的工程度量 B 每个特性都可映射到具体工程度量，看板应均衡展示各维度 ✓ 正确答案 C 质量看板只需关注代码覆盖率一项 D 安全性只能通过人工审计体现，无法用工具度量
# 6. 嵌套层级最大深度（一般 3-4 层）的项目门禁与 SonarQube 规则 A 一般项目设 3-4 层上限，超出用提前返回与提取方法降低嵌套 ✓ 正确答案 B 嵌套深度门禁越深越好，代表功能强大 C 嵌套深度与代码可读性无关 D SonarQube 无法检测嵌套深度
# 7. 代码行数（LOC）作为度量的局限，与复杂度、可读性的关系 A LOC 越少代表代码质量一定越好 B LOC 是衡量代码质量最科学的指标 C LOC 只反映文本规模，与逻辑复杂度、可读性并非单调相关 ✓ 正确答案 D LOC 可以直接用作绩效考核的唯一标准
# 8. 认知复杂度（Cognitive Complexity）的计算规则中嵌套增量、结构增量、增量减免 A 认知复杂度只统计 if 语句，与其他结构无关 B 认知复杂度包含结构增量、嵌套增量与增量减免三类规则 ✓ 正确答案 C 嵌套越深，认知复杂度越低 D 认知复杂度与圈复杂度计算规则完全相同
# 9. Halstead 复杂度指标中程序词汇量、长度、体积、难度、工作量 A Halstead 只统计代码行数 B Halstead 基于操作符与操作数的计数，衍生出体积、难度、工作量等指标 ✓ 正确答案 C Halstead 与圈复杂度含义完全相同 D Halstead 指标衡量运行时内存占用
# 10. 可维护性指数（Maintainability Index）的计算中圈复杂度 + LOC + Halstead 体积 A MI 只由代码注释数量决定 B MI 综合圈复杂度、LOC、Halstead 体积等维度，合成 0-100 的可维护性分数 ✓ 正确答案 C MI 分数越高代表代码越难维护 D MI 与圈复杂度是完全独立的两个指标
# 11. 代码度量中复杂度、重复率与覆盖率？ A 三者分别从结构风险、复用成本、测试保障角度互补，共同构成质量度量体系 ✓ 正确答案 B 三者互不相关，可只关注其中一项 C 覆盖率能完全替代复杂度度量 D 重复率越高说明代码质量越好
# 12. 度量的可视化中趋势、基线与目标？ A 只需展示单个数值，无需趋势 B 目标值应与基线保持一致 C 基线一旦设定就永远不变 D 趋势、基线与目标三者结合，才能将度量变成可决策的质量信号 ✓ 正确答案
# 13. 代码度量的团队口径对齐中覆盖率范围、生成代码排除、统计周期等口径如何统一，使跨团队数据可比且不被操纵？ A 各团队可自行随意定义度量口径 B 统一覆盖率范围、生成代码排除、统计周期等口径，才能保证跨团队可比且防操纵 ✓ 正确答案 C 生成代码应计入覆盖率以放大数字 D 度量口径无需版本控制
# 14. ISO/IEC 5055（自动化源代码质量度量）如何基于 ISO/IEC 25010 定义可维护性、可靠性、安全性与性能效率四项结构质量度量，并以映射到 CWE 的结构性弱点（structural flaws）作为计分单元，与 SonarQube 类技术债度量在口径上有何差异？ A 两者完全等价，口径无差异 B ISO/IEC 5055 以映射 CWE 的结构性弱点为计分单元，SonarQube 技术债以修复时间估算为主 ✓ 正确答案 C ISO/IEC 5055 只衡量代码覆盖率 D ISO/IEC 5055 与 25010 完全无关
# 15. 代码度量指标的阈值设定与团队基线建立 A 先基于团队现状建立基线，再结合历史数据与经验设定阈值并渐进收紧 ✓ 正确答案 B 阈值应凭直觉设定且永不调整 C 基线建立后无需重算 D 阈值应高于所有模块当前值
# 16. 度量的误用中指标游戏与局部优化？ A 指标越高说明实际质量一定越好 B 单一指标应直接绑定绩效以激励改进 C 为了指标好看可以修改统计口径 D 指标游戏与局部优化会扭曲度量，治理关键是多指标平衡与口径管理 ✓ 正确答案
# 17. 度量体系的建设中指标、基线与趋势？ A 指标越多越好，无需取舍 B 度量体系只需关注单一指标 C 基线一旦建立就无需更新 D 指标、基线、趋势构成"是什么、现状、方向"的完整闭环 ✓ 正确答案
