用例编写规范与评审

• 测试用例的完整要素
• 各要素的质量要求
• 劣质用例反例

一条高质量测试用例的完整要素包括：编号（唯一标识，便于追溯）、标题（概括测什么，简洁明确）、前置条件（执行前需满足的状态/数据）、测试步骤（具体、可执行、有序）、预期结果（可观察、可判定、明确）、优先级（反映风险与重要性）、测试数据（输入数据、边界数据）。各要素质量要求：编号唯一稳定、标题"一句话说清测什么"、前置条件完整（不靠记忆）、步骤"一个动作一步、可复现"、预期结果"可观察可判定不主观"、优先级按风险分级、数据明确。常见劣质用例反例：标题含糊（如"测试登录"）、步骤笼统（"输入正确信息"）、预期主观（"系统正常"）、缺前置（"登录后"无后续）、多个验证点混在一个用例（难定位失败）、数据不明确（"输入任意值"）、优先级一刀切。高质量用例标准是"可执行、可复现、可判定、可追溯"。

测试用例的要素是"可执行性、可追溯性"的载体。高质量用例"每个要素都明确、可判定"，劣质用例"要素含糊、不可复现、不可判定"。把握"可执行、可复现、可判定、可追溯"四标准，是编写高质量用例的核心。

• 用例评审流程
• 覆盖度、可执行性、可维护性标准
• 评审检查清单

用例评审流程：作者自检 → 同行评审 → 记录评审意见 → 作者修改 → 确认闭环。评审关注三方面标准：覆盖度——是否覆盖需求全部功能点、正常/异常/边界流是否齐全、有无需求遗漏（对照需求追踪矩阵/需求清单）、高风险区域是否覆盖；可执行性——步骤是否具体可执行、预期是否可判定、前置条件是否完整、数据是否明确、用例能否被他人直接执行；可维护性——用例是否模块化（步骤与数据分离）、是否与需求关联（需求变更可定位）、命名是否清晰、是否无冗余重复、是否便于自动化转化。检查清单即按这三方面逐项核对（如"需求是否全覆盖""步骤是否清晰""是否可复用""是否与需求可追溯"）。评审重点是"覆盖度防遗漏、可执行性防无效、可维护性防腐化"。

用例评审的三大标准（覆盖度/可执行性/可维护性）分别对应"测全、能测、好维护"。评审流程要"自检→互评→修改→闭环"，检查清单按三标准逐项核对。评审的价值是"靠他人视角发现作者的盲区"，防遗漏、防无效、防腐化。

• 从需求提取等价类
• 有效/无效等价类
• 边界值取点（on/off/in）

等价类与边界值在用例设计中的落地：第一步，从需求读取每个输入条件的约束（范围、类型、格式、必填），据此划分有效等价类（满足约束的输入）与无效等价类（违反约束的输入）；第二步，对每个有效/无效等价类取代表值设计用例；第三步，对每个等价类边界做边界值取点：on 点（恰好在边界上的值）、off 点（边界之外紧邻的值）、in 点（边界之内紧邻的值）。例如年龄 18-65：on 点取 18、65（边界上），off 点取 17、66（边界外紧邻），in 点取 19、64（边界内紧邻）。操作规则：on-off 两点法覆盖边界与边界外，on-in-off 三点法再覆盖边界内紧邻（用于开闭区间歧义）。落地时把"等价类代表值 + 边界 on/off/in 点"都转化为用例，确保"类覆盖 + 边界覆盖"。有效等价类用例验证"该测的接受"，无效等价类用例验证"不该测的拒绝"，边界值用例验证"边界行为正确"。

落地要点是"从需求提约束→分等价类→类内取代表值→边界取 on/off/in 点"。on 是边界上、off 是边界外、in 是边界内，三者组合覆盖边界判断的开闭区间语义。这是黑盒测试用例设计最常用、最实用的方法。

• 步骤与数据分离
• 参数化与数据驱动
• 共享步骤组织

用例的步骤与数据分离指"把用例的"操作步骤"与"输入数据/预期"分离，用同一套步骤驱动多组数据，提升复用度。参数化与数据驱动：步骤写成"模板"（用参数占位），数据放在数据表（CSV/JSON/Excel），执行时逐数据行代入模板，实现"一个步骤逻辑、多组测试数据"。复用度的提升：同一功能的不同数据（边界、非法、正常）复用同一步骤，新增用例只需加数据行；不同场景可复用公共步骤。共享步骤的组织：把"公共操作"（如登录、下单、打开页面）抽取为共享步骤/封装函数，用例通过"调用共享步骤"复用，避免重复编写；共享步骤按"功能/模块"组织，维护时只改一处。数据驱动是"数据与步骤分离"，共享步骤是"公共操作抽取"，两者结合实现"高复用、低重复、易维护"。落地时用测试框架（如参数化注解、数据驱动框架）实现。

步骤与数据分离+"共享步骤"是提升用例复用、降低维护成本的核心。数据驱动让"一个逻辑多组数据"，共享步骤让"公共操作复用"，共同减少重复用例。这既是设计规范（可维护性），也是自动化落地的基础。

• 预期结果的书写规范
• 可观察、可判定、不主观
• 劣质预期反例

预期结果的书写规范核心是"可观察、可判定、不依赖主观判断"：可观察——写明"能看到/能验证的具体现象"（如"页面提示'登录成功'""返回 200 状态码"）；可判定——写明"明确的是/否判据"（如"文件一字节不少""金额为 19.99"），能据此判断通过/失败；不主观——避免"系统正常""体验良好""符合预期"这类依赖主观评价的表述。常见劣质预期反例：主观模糊（"系统正常""没有问题""体验不错"）、不完整（"操作成功"没说成功标志）、无具体值（"数据已保存"没说保存成什么）、与步骤无关（"系统稳定"）、不可验证（"运行良好"）。好预期示例："点击登录后跳转到首页，顶部显示用户名'张三'"——可观察（跳转、显示）、可判定（用户名=张三）、不主观。规范是"写具体现象 + 明确判据 + 避免形容词"。

预期结果是"用例是否通过"的唯一判据，必须"可观察、可判定、不主观"。偷懒或主观的预期会导致"明明通过却无法判定"或"靠感觉判断"，破坏用例的可判定性。规范是"写具体可观察的现象与明确判据"。

• 测试点提取方法
• 需求→测试点→用例的分解
• 不遗漏的保证

测试点提取是从需求到测试设计的中间层，方法：先把需求拆解为"功能点"（每个独立功能/流程），再对每个功能点提取"测试点"（要验证的维度/行为），最后把测试点细化为"测试用例"（具体步骤+预期）。保证不遗漏的方法：1）用结构化模板逐项提取——按"功能（正常/异常/边界）、数据、状态、交互、安全、性能、兼容"等维度逐一核对每个功能点，防止漏维度；2）用需求追踪矩阵（RTM）——把需求↔测试点建立映射，逐条需求核对"是否有测试点"，反向检查无用例的需求（防漏测）；3）用测试设计技术辅助——等价类/边界值/判定表/状态图系统枚举，防止逻辑漏项；4）评审确认——测试点清单经评审（对照需求与检查清单）确认无遗漏。分解的"不遗漏"核心是"结构化提取 + 需求映射 + 设计技术系统化 + 评审兜底"。

需求→测试点→用例的三层分解，关键是"测试点层"的完整性，因为测试点决定用例覆盖。不遗漏靠"结构化维度提取 + RTM 需求映射 + 设计技术系统化 + 评审确认"四重保障。测试点是"需求与用例"的桥梁，抓到实处。

• 用例粒度的权衡
• 过粗/过细的风险
• 按风险分级定粒度

用例粒度指"一个用例覆盖的范围大小"。过粗（一个用例覆盖太多步骤/验证点）会导致漏测（某分支未单独验证、失败时难定位）；过细（一个用例只验证极小点）会导致用例数量庞大、维护成本高、执行冗余。正确做法是按风险分级确定粒度：高风险功能（金额、安全、核心流程、复杂逻辑）用细粒度用例——每个关键分支/异常单独成用例，便于精确定位与充分验证；低风险功能（简单展示、成熟稳定）用粗粒度用例——合并相关验证点，减少用例数量。粒度判断标准：一个用例应"聚焦一个可独立判定的行为/test point"，"失败时能快速定位到具体功能点"，同时"避免不必要的碎散"。核心是"按风险分配粒度：高风险细、低风险粗"，在"覆盖充分"与"维护成本"间平衡。

用例粒度是"覆盖充分性"与"维护成本"的权衡。过粗漏测、过细成本高。按风险分级（高风险细、低风险粗）是解决之道，让粒度匹配风险。判断标准是"一个用例聚焦一个可判定行为、失败可定位"。

• RTM 的概念
• 覆盖率量化
• 漏测风险暴露与跟踪

需求追踪矩阵（RTM）是"需求↔用例↔缺陷"的映射表，用于保证需求都被测试覆盖。量化覆盖率：在 RTM 中为每条需求标注"是否有对应用例、用例是否执行、是否通过"，需求覆盖率 = 有用例覆盖的需求数 / 总需求数，也可细化为"已执行/已通过"比例；通过 RTM 可量化"每条需求有多少用例、用例是否全部通过"。暴露漏测风险：RTM 中"无对应用例的需求"即漏测风险点，一目了然；跟踪漏测：把"无用例/未通过"的需求标记为风险项，分配责任人、设定补测优先级与截止时间，纳入评审与发布门禁（未覆盖的关键需求不予发布）。RTM 的价值是"把需求覆盖变成可量化、可跟踪、可追溯"，防止"需求没测却发布"。核心是"需求↔用例映射 + 覆盖率量化 + 漏测项跟踪闭环"。

RTM 是"需求覆盖的量化与追溯工具"，把"需求有没有被测"变成可追踪的指标。覆盖率量化（需求覆盖率）暴露漏测，漏测风险通过"标记+责任人+门禁"跟踪闭环。RTM 是"需求可追溯"的保障，防"漏测发布"。

• RPN 风险优先级
• 用例执行顺序
• 回归范围

用例优先级与风险分级用 RPN（风险优先级数）= 严重性 × 可能性 来量化：严重性（缺陷影响多大，如金额/安全/核心流程严重性高）、可能性（缺陷发生的概率，如复杂/易变代码概率高）。RPN 高 = 高优先级。用 RPN 决定用例执行顺序：按 RPN 从高到低排序，RPN 高的用例（严重性高×可能性高）优先执行，确保"高风险场景先被验证"；时间不足时优先保 RPN 高的用例。决定回归范围：回归用例集按 RPN 分级——RPN 高的核心用例（涉及金额、安全、核心流程）必回归，RPN 中等的按需回归，RPN 低的（低风险稳定）可抽样或延后；需求变更/修复时，变更影响相关的用例（RPN 高）优先回归。核心是"按 RPN 分级，让有限测试资源优先投向高风险场景"。RPN 需定期评估（需求/代码变化后重算）。

RPN（严重性×可能性）是"风险驱动"的量化工具，把"哪个用例重要"变成可排序的数值。高 RPN 的用例优先执行、必回归，低 RPN 的抽样或延后。这保证测试资源投向高风险场景，是"风险优先策略"的落地。

• 手工用例转自动化
• 步骤/预期→数据驱动与断言
• 避免盲目自动化

手工用例沉淀为自动化的方法：把"稳定、可重复、回归价值高"的手工用例作为自动化候选，将其步骤转化为自动化脚本（或数据驱动模板），将"预期结果"转化为断言（把可观察/可判定的预期写成程序断言，如返回值、状态码、界面元素、数据库状态）。数据驱动落地：把步骤参数化，数据行从手工用例的测试数据提取，实现"一个脚本多组数据"。避免"为了自动化而自动化"：先判断用例是否适合自动化——不适合自动化的（UI 视觉主观判断、需人工直觉、一次性/探索性、频繁变更的）不强行自动化；自动化应聚焦"高回归价值、稳定、可重复"的用例；评估自动化 ROI（投入 vs 回归收益），避免把"边缘一次性用例"自动化造成浪费。沉淀原则是"从高价值稳定用例入手，重断言、重数据驱动，避免为自动化而自动化"。

手工转自动化的核心是"步骤→脚本、预期→断言、数据→数据驱动"。"为了自动化而自动化"的规避靠"选对用例（稳定高回归价值）+ 评估 ROI + 不强行自动化不适合的用例"。自动化是手段，目标是"回归保障"。

• 用例四要素
• 各要素缺失的后果
• 完整性检查

用例四要素（前置条件、步骤、预期结果、测试数据）各自缺失会导致不同问题：缺前置条件——执行者不知"从什么状态开始"，用例无法执行/复现，评审时无法判断前提；缺步骤——执行者不知"怎么操作"，用例不可执行，无法复现；缺预期结果——执行者不知"怎么判断通过"，用例无法判定，缺陷无法确认；缺测试数据——执行者不知"用什么数据"，用例不可执行或结果不确定，无法复现。完整性检查方法：逐用例核对四要素是否齐全，缺一即不合格；执行前检查"四要素是否可执行、可判定、可复现"；评审时把"四要素完整"作为检查点。核心是"四要素齐全是用例可执行、可判定、可复现的基础"，任一缺失都会破坏用例的可用性。

四要素是"用例可执行性"的支柱：前置定起点、步骤定操作、预期定判据、数据定输入。任一缺失都会导致"不可执行""不可判定""不可复现"。完整性检查是保证用例质量的第一道关。

• 评审度量指标
• 评审缺陷发现率、用例缺陷密度计算
• 反哺编写规范

用例评审的度量用于评估"用例质量与评审有效性"。评审缺陷发现率（评审效率）——评审中发现的用例缺陷数 / 评审的用例数（或评审时长），衡量"每次评审能发现多少用例问题"，反映评审有效性；用例缺陷密度——用例中存在的缺陷数 / 用例总数（或用例数 × 步骤数），衡量"用例的质量水平"，反映编写规范执行情况。计算后反哺编写规范：评审缺陷发现率高（发现大量问题）说明用例质量差、编写规范需强化（针对高频缺陷类型补充规范）；用例缺陷密度高说明整体编写水平低，需培训与规范修订；通过分析缺陷类型（如"缺预期""缺前置""步骤不清"）占比，针对性地完善编写规范与检查清单，形成"评审发现→归类→规范改进→再评审"的闭环。核心是"用度量数据驱动编写规范持续改进"。

评审度量让"用例质量"可量化：评审缺陷发现率衡量"评审效率"，用例缺陷密度衡量"用例质量"。度量数据反哺规范——按缺陷类型占比改进编写规范与检查清单，形成质量改进闭环。这使评审从"主观"走向"数据驱动"。

• 三维检查法
• 正面/负面/边界的枚举
• 配比评估

用例设计的三维检查法是从"正面、负面、边界"三个维度系统枚举用例：正面（正常流）——主流程、正常输入、正常分支，验证"功能正确"；负面（异常流）——错误输入、非法操作、权限不足、外部失败、超时，验证"系统对异常的处理与防御"；边界（极限值）——最大/最小、空、越界、0、临界值，验证"边界行为"。系统枚举：对每个功能点，分别从三个维度反问"正常情况怎么测""异常情况怎么测""边界情况怎么测"，用等价类/边界值/判定表辅助补全。配比评估：正常流用例保证主流程覆盖，但负面与边界用例通常占更大比例（缺陷多源于异常与边界），合理配比"正常流约 30%、负面约 40%、边界约 30%"（依风险调整）；核心是"负面与边界占比不低于正常流"，避免只测一帆风顺。配比合理性评估结合"缺陷发现率"（若负面/边界用例持续发现缺陷，说明配比合理）。

三维检查法（正面/负面/边界）是"用例完整性"的系统框架，保证"正常、异常、边界"三类都被覆盖。配比评估的核心是"负面+边界占比合理（不低于正面）"，因为缺陷集中于异常与边界。三维枚举+配比合理是防漏测的关键。

• 评审角色分层
• 各角色检查维度
• 评审成本控制

用例评审角色分层：作者自检（作者写完后自查）——适合检查"基础要素"（四要素是否齐全、步骤是否可执行、预期是否可判定、命名是否规范），是最初步的自我把关；同行互评（同级测试人员互审）——适合检查"设计质量"（覆盖度是否充分、等价类/边界是否完整、场景是否覆盖、是否有冗余），借助他人视角发现盲区；专家评审（资深/专家或有负责人）——适合检查"风险与架构层面"（高风险需求覆盖、与业务规则是否一致、需求追踪是否完整、是否影响发布），做最终把关。避免评审成本无限上升：分层让"基础问题在自检阶段解决、质量问题在互评阶段解决、框架问题在专家评审解决"，避免所有问题都堆到专家评审；按风险分级评审——高风险用例专家评审、低风险用例自检+互评即可；控制评审时长与范围（聚焦、限时）。核心是"分层负责 + 按风险分级 + 控制范围"，避免评审成"全体审所有"的高成本。

评审角色分层是"成本与质量"的平衡：自检解决基础、互评解决设计、专家解决风险，各层职责分明，避免低效的"全员全审"。成本控制靠"按风险分级评审 + 限时聚焦"。分层让评审"该审的审、不该审的不审"。

• 用例与缺陷的双向追溯
• 用例-缺陷-修复-回归链条
• 反哺用例库维护

用例与缺陷的双向追溯指"用例↔缺陷"互相关联：由用例能查到其发现的缺陷，由缺陷能查到对应的用例。链条"用例→缺陷→修复→回归"：测试执行用例发现缺陷→缺陷关联其用例→修复后回归该用例验证。评估用例有效性：统计"每个用例发现的缺陷数、缺陷严重度、回归通过率"——发现缺陷多且严重的用例有效性高（高价值）；长时间未发现缺陷的用例如果覆盖的是高风险代码，可能是"测试无效"（需检查断言/覆盖），若是低风险稳定代码则仍有效。反哺用例库维护：把"发现缺陷的用例"标记为高价值（保留并强化），把"长期无缺陷且覆盖重复/低价值"的用例分析是否有冗余（删除或合并），把"被缺陷暴露的缺失场景"补充为新用例；用"缺陷反推缺失用例"（缺陷未关联任何用例说明该场景漏测，需补用例）。核心是"用缺陷数据评估用例价值，驱动用例库的增删改与优化"。

双向追溯让"用例价值"可量化：用"发现缺陷数+严重度"评估用例有效性，用"缺陷反推缺失用例"补漏，用"长期无缺陷"判断冗余。这使用例库从"静态维护"变为"缺陷数据驱动"的持续优化。

• 用例管理工具选型
• 各工具特点
• 用例版本管理

用例管理工具选型要考虑团队规模、需求、成本与集成：TestRail——专业测试管理工具，支持用例、执行、报告、与 JIRA 等集成、权限与复核流程，适合中大型团队、需要专业测试管理的场景（付费）；禅道——国产开源项目管理工具，集用例、缺陷、需求、项目于一体，适合国内团队、需要一体化管理且控制成本（免费/开源）；Excel——轻量、灵活、无需部署，适合小团队/初期/简单场景，但缺乏权限控制、版本管理弱、多人协作差、报告能力弱。选型依据：团队规模（小团队 Excel 够用、中大型用 TestRail/禅道）、预算（开源选禅道）、集成需求（TestRail 集成好）、协作需求（Excel 弱）。用例版本管理实践：工具内置版本管理（TestRail 基线/快照、禅道版本）或通过命名/目录管理（Excel 命名带版本号）；需求/界面变更时生成用例新版本，保留旧版本基线，标注变更原因；版本管理保证"可追溯、可回滚、可对比"。核心是"按团队规模与需求选型 + 用工具内置/命名机制做版本管理"。

选型是"规模、成本、协作、集成"的权衡：大团队+专业管理用 TestRail，国内一体化+开源用禅道，小团队/轻量用 Excel。版本管理靠工具基线或命名机制，保证可追溯。选型要匹配团队发展阶段，避免过度/不足。

• 用例复用与基线管理
• 回归用例集维护
• 冗余清理与变更影响分析

用例复用与基线管理：回归用例集是"稳定、可复用、用于回归"的用例集合，维护原则是"随需求变更动态更新"。回归用例集维护：定期评审回归集，删除失效（需求已变/功能已删）用例，补充新增需求用例，更新预期，保证回归集"与当前需求一致"。冗余清理：通过"用例覆盖分析"（哪些用例覆盖同一代码/功能、长期无缺陷且重复）识别冗余，删除或合并重复用例，控制回归集规模。变更影响分析（基于需求变更联动）：需求变更时，通过"需求↔用例"映射（RTM）定位受影响的用例（该需求对应用例及其关联），评估变更影响范围，确定需新增/修改/删除的用例，联动更新回归集；把"变更影响分析"作为需求变更的标准流程，避免"需求变了回归集没更新"导致回归失效。核心是"回归集随需求联动维护 + 冗余清理 + 变更影响分析"，保证用例集与需求同步、不冗余、不失效。

回归用例集维护的核心是"与需求变更联动"：需求变了，回归集要同步增删改。冗余清理靠"覆盖分析+缺陷数据"识别重复，变更影响分析靠"RTM 映射"定位受影响用例。这样回归集"不冗余、不失效、与需求同步"，是回归质量的基础。

• BDD/Gherkin 的 Given/When/Then
• 需求评审与自动化的价值
• 过度形式化的风险

BDD/Gherkin 用 Given/When/Then 描述用例：Given（前置条件）、When（触发动作）、Then（预期结果），用自然语言描述行为，作为"需求与测试的共同语言"。价值：需求评审——Given/When/Then 让业务、开发、测试用同一语言评审用例，把需求转成可验收的行为描述，便于确认需求是否正确、是否可测；自动化——Gherkin 场景可直接映射到 Cucumber 等框架的步骤定义执行，实现"需求即用例、用例即自动化"，降低维护成本。过度形式化的风险：若把每个用例都写成 Gherkin 并强制自动化，会导致大量形式化样板、维护成本高、可读性下降；且"形式化描述不一定等于测试有效"，过度倚重形式会忽略测试设计实质。规避：只对"关键业务/验收场景"用 Gherkin 描述，普通用例用标准用例格式；自动化聚焦高价值场景；避免"为 BDD 而 BDD"的形式主义。核心是"用 Gherkin 做共同语言与验收驱动，但控制形式化范围，避免过度"。

BDD 的价值是"共同语言（Given/When/Then）+ 验收驱动 + 用例即自动化"，降低沟通与维护成本。过度形式化的风险是"样板多、维护重、重形式轻内容"。规避靠"控制 Gherkin 适用范围（关键场景）+ 聚焦自动化价值"。把握"形式化帮你，不绑架你"。

• 用例库的重复与交叉覆盖
• 冗余检测方法
• 去重与复用基线

用例库的重复与交叉覆盖治理：用例库随规模增长容易出现"重复用例"（同一场景多份用例）与"交叉覆盖"（不同用例覆盖同一功能/代码），导致冗余与维护成本高。冗余检测方法：用关键词维度——按标题/步骤中的关键词（如"登录""支付"）检索，找出描述相似的用例群；用模块维度——按功能模块/需求分类统计用例，检测"同一模块/同一功能点被多个用例重复覆盖"；结合代码覆盖分析（多用例覆盖同一代码）识别交叉覆盖。建立去重与复用基线：先定义"用例唯一性标准"（同一功能+同一数据+同一预期视为重复），对冗余用例做去重（保留覆盖最全、断言最清晰的，合并/删除重复）；建立"复用基线"——把公共功能（登录、下单）的用例沉淀为共享/基础用例，供其他用例复用，避免重复编写；用工具（测试管理工具的用例查重、关键词检索）维护。定期评估用例库，防止冗余再增长。核心是"用关键词/模块检测冗余 + 去重 + 共享复用基线"，控制用例库规模与质量。

用例库治理的核心是"检测冗余（关键词/模块/覆盖）+ 去重（保留最优）+ 复用基线（共享公共用例）"。冗余源于"重复编写"与"交叉覆盖"，去重与复用基线能把用例库从"膨胀"变为"精炼"。这控制维护成本，保证用例库质量。

• 用例编号与命名规范
• 多模块多版本的 ID 规则
• ID 漂移规避

用例编号与命名规范：ID 规则要"稳定、唯一、可追溯、有意义"。多模块多版本项目中的稳定 ID 规则设计：采用"前缀+模块+序号"结构，如"模块码-用例序号"（M-xxx），或"项目-模块-层级-序号"（如 LOGIN-001、PAY-001-01）；模块码用稳定缩写（如 LOGIN=登录、PAY=支付），序号按模块递增；版本信息不放在 ID 中（版本变化会改 ID），而是通过"版本字段/基线"管理，避免 ID 随版本漂移。避免 ID 漂移破坏追溯：ID 一旦分配即保持稳定，不因需求变更/用例修改而改动 ID（除非用例本质变化）；删除用例不重用其 ID（避免歧义）；用唯一 ID 关联需求、缺陷、自动化（追溯链稳定）；命名规范（标题）也保持"变化时更新但不破坏 ID"。核心是"ID 稳定不变 + 版本用独立字段管理 + 不重用已删 ID"，保证追溯链不被 ID 漂移破坏。

ID 漂移是"多模块多版本"项目中追溯被破坏的根源。稳定 ID 规则的核心是"ID 与版本解耦（版本用独立字段）+ 模块化稳定前缀 + 不重用已删 ID"。这保证"需求-用例-缺陷-自动化"的追溯链长期稳定，是测试资产可管理的基础。