评审技术与静态分析

• 需求可测试性的含义
• 识别不可测试需求的方法
• 五种常见不可测试需求模式及改进

需求可测试性（Testability）指需求是否具备可验证、可判定（通过/失败）的条件，可测试性分析用于在需求阶段识别并改进不可测试的需求。识别方法：检查需求是否可观察（有可观测的输入/输出）、可判定（有明确预期结果）、可量化（有可测量标准）、无歧义（描述唯一）、可观测范围内可复现。五种常见"不可测试需求"模式及改进：其一，模糊形容词（如"响应要快""界面要美观"）——改为量化指标（"响应时间 <500ms""按钮对齐标准"）；其二，缺乏明确预期（如"正确处理异常"）——明确具体的异常处理行为与结果；其三，绝对化表述（如"永远不崩溃""所有数据都正确"）——用可测范围与标准（如"99.9% 可用性""数据一致性校验通过"）；其四，隐含主观判断（如"体验良好"）——用可度量指标（如"任务完成率>90%"）替代；其五，逻辑/条件表述不完整（如"必要时提示"）——补全触发条件与具体行为。改进的核心是"把不可测的模糊表述转化为可量化、可判定、可验证的条件"。

核心是"可测需求=可观察+可判定+可量化+无歧义"。回答要点出识别方法、五种模式与改进。

• 评审入口/出口准则的含义
• 设定准则避免走过场
• 避免评审疲劳的方法

评审的入口/出口准则（Entry/Exit Criteria）用于判断评审"何时可开始、何时可结束"。入口准则（Entry Criteria）：评审开始前应满足的条件，如评审对象（需求/设计/代码）已就绪、评审材料已提前分发、评审者已准备、无阻塞性不求甚解的问题，避免"临时开会、材料未读"导致走过场。出口准则（Exit Criteria）：评审结束前应满足的条件，如所有关键问题已讨论并记录、缺陷已分类、有明确结论与责任人、问题清单已形成，避免"草草收场"导致遗留问题。设定准则可避免走过场：强制"材料预读+准备度检查"让评审有实质内容，出口用"问题清单+跟进"保证结论落地。避免评审疲劳的方法：控制评审时长（如 60-90 分钟，超时拆分）、控制参与人数（聚焦关键角色，避免无关人员）、控制评审材料规模（分块评审而非一次审完）、提前分发材料、主持人控制节奏、避免在例会中夹带评审。合理的准则与组织形式让评审"有实质、不疲劳"。

核心是"用准则保证评审质量、用组织控制疲劳"。回答要点出入口/出口准则与防疲劳措施。

• 评审会议的组织要素
• 过程控制手段
• 提升缺陷发现率与防形式主义

评审会议的组织与过程控制对缺陷发现率至关重要。时长上限：设定单次评审时长上限（如 60-90 分钟），超时则拆分或续议，避免注意力下降导致效果变差；参与人数：控制规模（如 4-7 人），聚焦作者、评审者、主持人、记录员等关键角色，避免"人海战术"效率低下；准备度检查：评审前分发材料、要求评审者提前阅读并记录问题，检查"是否已准备"，避免现场临时阅读；主持人职责：主持人负责控制节奏、引导讨论、防止跑题与争论、确保每个问题被记录并分类、观察时间、汇总结论，是评审过程质量的关键。过程控制提升缺陷发现率：材料预读使评审者带着问题进入、聚焦关键区域；主持人引导让讨论聚焦缺陷而非个人；时间控制保持注意力。同时防止流于形式：用出口准则（问题清单、结论、责任人）强制产出，用度量（缺陷发现率）持续审视评审有效性。组织得当是评审有效的前提。

核心是"组织要素+过程控制"。回答要点出时长、人数、准备度、主持人职责及防形式主义。

• 评审度量的计算方法
• 各度量的使用场景
• 用度量改进评审过程

评审度量用于衡量评审的有效性与效率。缺陷发现率（Review Defect Detection Rate）：评审发现缺陷数/应发现缺陷总数（或某阶段评审发现的缺陷占比），反映评审发现缺陷的能力，用于评估评审有效性；评审效率（Review Efficiency）：评审发现缺陷数/评审人时（或评审材料规模），反映单位投入产出，用于评估评审性价比；缺陷密度（Defect Density）：评审中发现缺陷数/评审对象规模（如每页需求、每千行代码），反映评审对象质量，用于识别质量薄弱环节。使用场景：发现率用于对比不同评审方式/人员的有效性，效率用于评估投入产出与资源分配，密度用于定位问题集中区域。用度量改进评审过程：基于发现率与效率，识别评审方法是否有效（不足则改进评审技术、检查清单、参与度）；基于缺陷密度定位薄弱模块，重点加强评审；通过多轮度量对比，验证评审改进措施（如调整参与人、改进检查清单、控制时长）的效果，形成"度量→分析→改进→再度量"的闭环。

核心是"度量驱动评审改进"。回答要点出计算方法、使用场景与闭环改进。

• 静态分析工具的定位与能力
• 能发现的问题类型
• 不能替代的人工审查活动

静态分析工具（如 SonarQube、ESLint、Semgrep）在代码审查中的定位是"自动化辅助检查工具"，它能在不运行代码的情况下扫描代码，发现确定性的、规则可定义的问题：语法错误与规范问题（命名、格式化、代码风格）、常见缺陷模式（空指针、未使用变量、资源泄漏、重复代码）、复杂度与可维护性度量（圈复杂度、代码行数）、潜在安全漏洞（SQL 注入、XSS、硬编码密钥）、依赖漏洞与坏味道。但它不能替代人工审查活动：无法判断业务逻辑正确性、需求符合性、设计合理性、架构合理性；无法发现跨模块的语义错误、业务规则缺陷、并发时序问题、边界场景的隐含假设；无法评估需求是否被正确理解、可测性、以及人为决策（如设计权衡）。因此静态分析是"左移的自动化检查"与"人工审查的辅助"，两者互补：静态分析抓确定性技术问题，人工审查抓语义、业务与设计问题。

核心是"静态分析抓确定性技术问题、人工抓语义业务问题"。回答要点出静态分析能力与人工审查的不可替代性。

• 同行评审与正式检查的差异
• Fagan Inspection 的角色分工
• 准备阶段与缺陷分类提升发现率

同行评审（Peer Review）与正式检查（Inspection）的差异：同行评审是较正式/非正式、由作者同事参与的评审，流程较轻、角色灵活；正式检查（Inspection，Fagan Inspection）是结构化的正式评审，有严格的流程、角色分工与度量。Fagan Inspection 的角色分工：Moderator（主持人）——组织并控制检查过程、确保流程执行，不参与内容修改；Author（作者）——产出被检查对象，负责澄清与被检查，不主导评审；Reviewer（评审者）——独立审查材料，发现缺陷，是最主要的缺陷发现者；Scribe（记录员）——记录发现的缺陷与决策，不参与内容判断。准备阶段：评审前作者公布材料、评审者独立预读并记录个体缺陷，正式检查会先开"检查计划会"再进入"检查会"，预读让评审者带着个体发现进入集体讨论，显著提升发现率。缺陷分类：把发现的缺陷按类型（逻辑、规范、接口、可维护性等）与严重度分类，便于统计根因与后续改进。Fagan 的"角色分工+准备阶段+缺陷分类"使检查结构化、可度量，从而大幅提升缺陷发现率。

核心是"正式检查的结构化（角色+准备+分类）"。回答要点出 Fagan 角色分工与准备/分类的价值。

• 静态分析在 CI 中的集成方式
• 规则定制与增量分析
• 质量门禁的配置策略

静态分析在 CI 中的集成实践：把 SonarQube/ESLint/Semgrep 等工具接入 CI 流水线，在每次提交/合并时自动扫描代码。规则定制：根据项目语言、技术栈与团队规范定制规则集，启用高价值规则、禁用噪音规则，避免默认规则集产生大量误报淹没真实问题。增量分析：只分析本次变更的代码（如 SonarQube 的 New Code 分析、ESLint 只检查变更文件），避免全量扫描的耗时与噪音，聚焦新增问题，使反馈快速且针对性强。质量门禁（Quality Gate）配置：基于增量分析设置门禁条件，如"新增代码覆盖率 >=80%""新增代码无 blocker/critical 问题""重复率 <=3%""复杂度不超过阈值"，只有当增量代码满足门禁才允许合并（merge），否则阻断。配置策略要点：门禁要"可达成、有区分度"，避免过严导致形同虚设或过松失去意义；用增量（New Code）而非全量作为门禁依据，避免历史问题阻塞新代码；门禁与人工评审结合，静态分析结果作为评审输入而非替代。这样 CI 静态分析既快速又聚焦，形成"扫描→门禁→反馈"的闭环。

核心是"规则定制+增量分析+质量门禁"。回答要点出三者及门禁配置策略。

• 变异分析的概念与原理
• 变异存活率与测试强度的关系
• 用变异分析指导评审优先级

变异分析（Mutation Analysis）通过引入微小的、有意的代码变更（变异体，如改运算符、改边界条件、删除语句），然后运行测试套件，观察测试是否"杀死"变异体（即测试能否发现变异导致的错误）。变异存活率（Mutation Score）指"未被测试杀死的变异体比例"：存活率越高，说明现有测试对相应代码的验证越薄弱、无法发现这些错误。因此变异存活率高的模块意味着测试强度不足、缺陷隐藏风险大。用变异分析指导代码评审优先级：对变异存活率高的模块，优先安排深入代码评审，因为测试未覆盖的逻辑需要人工审查来发现潜在缺陷；同时结合"存活率高且逻辑复杂/业务关键"的模块，明确评审重点与检查清单；评审时可结合变异体的类型（如边界条件、运算符、逻辑分支）定位测试薄弱点与易错点，指导测试补充与人工审查。本质是"用变异分析量化测试薄弱点，从而科学确定评审优先级与重点"。

核心是"变异存活率高=测试薄弱，应优先评审"。回答要点出原理与优先级指导。

• 走查、技术评审、正式审查的定义与特点
• 三者的正式程度、流程与适用
• 各自的角色与产出

评审按正式程度分为走查、技术评审与正式审查三种。走查（Walkthrough）：非正式、由作者向参与者介绍并漫步式讲解材料，参与者提问与讨论，灵活、成本低、气氛轻松，适用早期需求/设计草案的快速检查，产出是讨论记录与改进意见，不以严格发现缺陷为主。技术评审（Technical Review）：介于走查与正式审查之间，由技术专家对产品或文档进行技术性评估，关注技术正确性、可维护性、架构合理性，有较明确流程与角色，适用设计评审、技术方案评审，产出是技术问题清单与改进建议。正式审查（Inspection，如 Fagan）：最正式、结构化，有严格流程、角色分工（主持人/作者/评审者/记录员）、准备阶段、缺陷分类与度量，以发现缺陷为主要目标，适用关键需求、设计、代码的正式检查，产出是经过统计的缺陷清单与评审报告。三者的递进是"正式程度、流程强度、缺陷发现要求"逐级提升，根据对象的重要性与成本选择合适类型。

核心是"正式程度递进"。回答要点出三种类型的正式度、流程与适用场景。

• 静态分析规则的分级
• 误报的抑制与治理
• 反馈闭环

静态分析工具的规则分级与误报治理目标是"让工具结果可信、可行动、不淹没真实问题"。规则分级：为规则设置严重级别（如 blocker/critical/major/minor/info，或 error/warning），不同级别对应不同的处理优先级（如 blocker 阻断合并、warning 提示），分级让团队聚焦高价值问题。误报抑制：对"误报"（规则不适用或确实不是问题）采用抑制手段——行内/文件级抑制注释（如 ESLint 的 eslint-disable）、配置规则例外、标记为 false positive、维护抑制白名单，避免同一误报反复出现。反馈闭环：制定"抑制即反馈"机制——每次抑制都应记录原因并由人工确认，统计各类规则的误报率，对误报率高的规则降级或关闭，对漏报的补充规则，形成"规则执行→误报反馈→规则调整"的闭环，持续优化规则集使其既有效又低噪音。分级+抑制+闭环让静态分析从"报警闹钟"变成"精准可用的质量检查"。

核心是"分级+抑制+闭环"。回答要点出规则分级、误报抑制方法与反馈闭环。

• 测试人员在代码评审中的检查重点
• 可测性、断言完整性、边界处理、错误分支
• 输出可执行评审意见

测试人员在代码评审中应从测试视角重点检查：可测性（Testability）——代码是否易于测试，是否有依赖注入/可注入点、是否有隐藏的全局状态、内部逻辑是否可隔离、是否暴露了测试可观察的接口；断言完整性（Assertion Completeness）——测试用例的断言是否足够、是否断言了关键行为而非仅执行通过、是否覆盖了预期结果的核心；边界处理（Boundary Handling）——是否处理了边界值（最小/最大、空、越界、特殊字符）、边界条件是否会导致异常；错误分支（Error Branch）——异常/错误路径是否被处理并测试、失败时是否有合理反馈、是否覆盖了 error 分支。输出可执行的评审意见：意见要具体、可操作、可落地——指出具体位置（文件/行号/方法）、问题是什么、为什么是问题、建议如何改（如"该分支缺少边界测试，建议补充 xx 用例"），而非泛泛而谈（如"增强测试"）。给出可执行的建议（补用例、加断言、改进可测性），便于开发与测试后续落实，让评审意见成为改进依据而非空话。

核心是"测试视角的评审重点+可执行输出"。回答要点出检查内容与具体意见的写法。

• 三类评审的检查重点与典型缺陷
• 三类评审的差异
• 分层评审防线

需求评审、设计评审与代码评审的检查重点与典型缺陷不同。需求评审（Requirements Review）：检查需求是否完整、清晰、可测、无歧义、一致，典型缺陷是需求遗漏、模糊、可测试性差、矛盾。设计评审（Design Review）：检查架构与设计是否合理、满足需求、可扩展、可维护、模块划分是否清晰，典型缺陷是设计不合理、耦合高、接口不一致、性能与安全设计缺陷。代码评审（Code Review）：检查代码实现是否正确、规范、易维护、是否有缺陷，典型缺陷是逻辑错误、边界问题、规范问题、安全隐患、代码坏味道。差异在于评审对象与关注层次（需求=做什么、设计=怎么做、代码=做出来）。三者衔接形成分层评审防线：需求评审把"需求层的缺陷"挡在最早阶段，设计评审拦截"设计层的缺陷"，代码评审拦截"实现层的缺陷"，层层过滤、逐层降低缺陷进入下游的成本（依据左移原则，越早发现修复成本越低）。测试人员在需求评审聚焦可测性、设计评审聚焦可测试性、代码评审聚焦实现验证，形成从需求到实现的完整质量防线。

核心是"三层评审对象与缺陷层次不同，层层衔接"。回答要点出差异与分层防线价值。

• 静态分析的局限
• 跨模块语义、并发时序、业务规则缺陷的静态分析难点
• 人工评审与动态测试的补位

静态分析难以发现跨模块语义、并发时序与业务规则类缺陷，原因在于其工作原理：静态分析基于规则与代码结构做模式匹配，缺乏对"模块间语义关系、运行时行为、具体业务上下文"的理解。跨模块语义缺陷：静态分析难跨模块追踪数据流与调用语义，无法判断模块间接口的业务含义是否一致；并发时序缺陷：静态分析不执行代码，难以模拟线程调度、竞争条件、死锁等运行时时序问题；业务规则缺陷：业务规则往往体现在需求语义中，静态分析不理解业务意图，无法判断实现是否符合业务规则。补位方式：人工评审——评审者具备业务与架构知识，能发现跨模块语义不匹配、业务规则理解偏差、并发设计缺陷；动态测试——通过执行代码（并发压力测试、集成测试、业务场景测试）验证运行时行为，暴露并发竞态、时序与业务规则错误。因此静态分析应与人工评审、动态测试结合，分别覆盖"静态结构问题、语义业务问题、运行时行为问题"。

核心是"静态分析缺语义与运行时理解"。回答要点出局限原因与人工/动态补位。

• Gherkin 场景的结构（Given/When/Then）
• 避免过于技术化或过于模糊
• 场景编写规范

BDD 中 Gherkin 场景使用 Given/When/Then 结构描述行为，编写规范要避免"过于技术化"与"过于模糊"两个极端。避免过于技术化：场景应描述业务行为而非实现细节——避免在步骤中写 SQL、接口调用、控件选择器等实现层内容，用业务语言描述（"用户登录成功""提交订单"而非"调用 login 接口传参"），让非技术（产品、业务）也能理解，从而保持行为文档的普适性。避免过于模糊：场景应给出具体、可判定的前置条件与预期结果——避免"当用户输入错误时提示"这类无具体输入与结果的模糊描述，应写明具体数据（"当用户输入密码 '123' 且密码字段要求 6 位时"）与明确预期（"应提示'密码长度不足 6 位'且不提交"）。规范要点：每个场景一个行为、前置条件具体、动作明确、预期可判定、用业务语言、避免技术实现细节、避免主观模糊词。好的 Gherkin 场景是"可执行的需求"——既被业务理解，又能驱动自动化测试。

核心是"业务语言+具体可判定"的平衡。回答要点出避免两个极端的具体做法。

• 架构适应度函数的概念
• 用自动化测试验证架构约束
• 工具（ArchUnit/depcheck）与持续验证

架构适应度函数（Architecture Fitness Functions）指用自动化测试/检查持续验证系统是否满足架构约束的机制，使架构约束"可执行、可度量、可持续验证"。实现方式：把架构规则写成可运行的自动化检查（如 ArchUnit 用于 Java 架构测试、depcheck 用于依赖检查），在 CI 中持续执行，一旦违反约束即失败。典型验证内容：分层依赖——验证各层（如 Controller→Service→Dao）只允许特定方向的依赖，禁止倒置或跨层依赖；循环依赖——验证包/模块间无循环依赖（A 依赖 B、B 又依赖 A），可用 depcheck/JDepend 检测；命名规范——验证类/方法/包命名符合约定（如实现类以 Impl 结尾、包结构符合模块划分），可用 ArchUnit 的命名规则。持续验证机制：把适应度函数纳入 CI 流水线，每次变更自动运行，违反即阻断合入，使架构约束"左移、持续、自动化"，防止架构腐化。适应度函数让"架构原则"从文档变成可执行的守卫，是架构治理的自动化手段。

核心是"架构约束可执行化"。回答要点出 ArchUnit/depcheck 对分层、循环、命名的验证及持续集成。

• 评审的产出（问题清单）
• 问题跟踪机制
• 评审结论的闭环

评审的产出关键是问题清单与跟踪机制，确保评审发现问题被落实。问题清单（Issue List）：评审中发现的每个问题需记录——问题描述、位置（文档/代码/需求章节）、类型（缺陷/改进/疑问）、严重度、责任人、建议，形成可追溯的记录；问题分类（按严重度/类型）便于排序与统计。跟踪机制：为每个问题分配负责人与截止时间，通过缺陷/任务管理系统（如 Jira）或评审跟踪表跟踪状态（待处理/处理中/已解决/已验证），评审会议后需复核对问题是否解决；用问题关闭率（问题解决并验证的比例）度量评审闭环。结论闭环：评审结束时明确"通过/有条件通过/不通过"，有条件通过需在问题解决后复验，不通过需重新评审。没有问题清单与跟踪，评审会变成"开完会就忘了"，问题得不到解决，评审失去意义。因此"问题清单+跟踪+闭环"是评审价值落地的保障。

核心是"评审问题要可追踪、可闭环"。回答要点出问题清单要素与跟踪闭环机制。

• 静态分析左移的三个环节
• 各环节的分工
• 避免重复扫描与噪音

静态分析左移通过 IDE 插件、pre-commit 钩子与 PR 扫描三个环节分工落地：IDE 插件（开发时实时反馈）——开发者在编码时即时看到静态问题，问题在产生的最早阶段被修复，成本最低，负责"即时捕捉"；pre-commit 钩子（提交前检查）——在本地提交前运行快速检查，拦截明显问题（如格式、明显的 lint 错误），防止问题进入版本库，负责"提交前拦截"；PR 扫描（合并前检查）——在合并请求/PR 阶段运行完整静态分析（如 SonarQube 质量门禁），作为 CI 门禁把关，负责"合入前把关"。分工是"编码时即时→提交前拦截→合入前把关"，逐层左移。避免重复扫描与噪音：配置差异化——IDE 与 pre-commit 只跑快速热门的规则（lint），PR 扫描跑完整规则（含质量门禁、安全、覆盖率），避免每层跑全量造成重复；忽略规则——在不同环节用不同规则集，避免低价值问题在每层重复出现；噪音治理——用抑制白名单、误报反馈维护规则集，保证各环节的问题"有区分度、有行动价值"，避免同一问题反复出现形成噪音。三层分工+差异化配置实现"左移且不重复、不噪音"。

核心是"三层分工+差异化配置"。回答要点出各环节职责与防重复防噪音策略。

• 检查清单驱动与自由评审的差异
• 两者的效果对比
• 检查清单的持续更新

检查清单（Checklist）驱动的评审与自由评审（不依赖清单）的效果有明显差异。检查清单驱动：基于预定义的检查项（常见缺陷类型、规范、边界、风险点）逐项核对，优点是覆盖全面、不漏项、标准化、便于新人上手、结果可追溯，缺点是可能"机械核对"、忽略清单外的新问题、缺乏灵活性；自由评审：评审者凭经验自由审查，优点是灵活、能发现清单未覆盖的深层与新颖问题、适用探索性，缺点是依赖个人经验、容易漏项、覆盖不均衡、新人效果差。实践中常结合：以检查清单打底保证覆盖与规范，辅以自由探索发现清单外问题。检查清单的持续更新：从缺陷数据与评审中识别"高频漏检问题"补充进清单；基于新技术、新规范、新框架更新检查项；根据"清单漏检率"（清单外发现的缺陷）调整——若清单外频繁发现某类问题，说明该问题应加入清单；定期评审清单本身，去除过时低效项，保持清单精炼有效。持续更新使清单"跟得上变化、查得到盲区"。

核心是"清单保覆盖、自由补深度"。回答要点出两者差异与清单更新方法。

• 异步评审与同步评审的差异
• 各自的效率特点
• 异步评审缺陷发现率的保障

远程/异步代码评审（如 PR 评论、GitLab Merge Request 评审）与同步评审会议（共同在场讨论）在效率上有差异。异步评审：评审者按自己节奏独立审查、时间灵活、可深度思考、可自动记录、适合分布团队，效率上"个人时间利用好、无时空限制"，但缺乏即时互动、讨论较弱、可能延迟；同步评审：即时讨论、共识快、能当场澄清、互动性强，但时间成本高、需协调、人多时效率低。异步评审的缺陷发现率保障：其一，为异步评审提供明确检查清单与评审标准，保证覆盖全面、不漏项；其二，设置评审 SLA（如 24 小时内完成首次评审）避免延迟影响质量；其三，用自动化工具辅助（静态分析、测试、Lint 先过滤基础问题），让评审者聚焦语义与业务问题；其四，强制关键变更/高风险模块走同步讨论或评审会议，弥补异步讨论不足；其五，对异步评审的缺陷发现率做度量与复盘，持续优化评审流程。通过"清单+SLS+自动化+关键变更同步+度量"，异步评审能保证缺陷发现率与同步评审相当，同时兼顾效率。

核心是"异步兼顾效率与质量"。回答要点出差异与保障异步缺陷发现率的措施。