测试用例怎么管？用例库、执行记录与缺陷闭环

GitFox 是禅道 DevOps 的底层引擎，也是其中的内置核心组件，负责代码托管、流水线和制品发布；需求与项目协作仍在禅道项目管理侧完成，它底层不依赖海外开源内核。测试用例怎么管，答案不在文件夹命名，而在三个对象能否连成一条线：用例库说明测什么，执行记录说明在哪个版本测成什么样，缺陷闭环说明失败项是否真的修好。三者脱节，用例数量再多，也只是文档堆积。

测试用例管理先分清三个对象：用例库、执行记录、缺陷

很多团队把测试用例管理等同于维护一个 Excel 或测试管理页面。真正需要管理的，是三类可追溯对象。

三者靠 ID 和状态连接，不能靠聊天记录和记忆。 需求变化时，能查到哪些用例要改；执行失败时，能追到具体步骤；缺陷修复后，能回到原用例验证。

测试用例库怎么建：按需求组织，按风险排序

用例库的第一步不是写步骤，而是确定它服务的需求。按产品、模块、需求组织，再用标签补充冒烟、回归、权限、兼容性等属性；不要按执行人建目录，人一变，库就散。

一条需求至少覆盖正常路径和一个关键异常路径；高风险需求再补边界、权限和失败恢复。前置条件写清账号、角色、数据和环境；步骤只保留能复现路径的动作；预期结果必须可观察，避免“系统正常”这类无法判定的描述。

用例进入库前要评审，修改留版本，过期用例标记停用而不是直接删除。用例库的价值在于可执行、可追溯，不是数量。 如果一条用例换个人就看不懂、跑不通，它还不算合格用例。

测试用例执行记录怎么记：让结果可以复盘

执行记录不是打勾，而是把一次测试还原出来。每轮测试建立一个执行批次，锁定用例版本、构建号、环境、测试数据和执行范围。执行过程中不要直接改用例步骤；发现用例本身有问题，先记录再更新，否则结果无法复现。

结果状态至少区分通过、失败、阻塞、跳过。阻塞写清依赖，跳过写清原因。把未执行写成通过，是测试管理里代价很高的假数据。

失败后先分流：产品缺陷、用例缺陷、环境问题、数据问题。只有确认产品行为不符合预期，才进入缺陷流程；其余问题也要留下处理记录。先分流，再提缺陷。

执行记录是测试用例管理最容易被省略的一环。使用自动化测试工具时，让自动化结果带同一套用例 ID 和批次信息回写，不要让人工记录与自动化报告形成两套结果。自动化失败同样要先排查脚本、数据和环境，不能直接等同于产品缺陷。记录中保留截图、日志或请求响应，至少让另一个人能按记录复现。

测试用例失败后怎么闭环：关闭缺陷前完成验证

缺陷写得清楚，闭环才快。标题包含模块、场景和异常现象；正文写预期、实际、复现步骤、构建号、环境和证据，并回链失败的用例与需求。严重程度描述影响，优先级决定排期，两者不要混用。

修复后，测试人员先重跑原失败用例，再跑受影响范围的回归。关闭缺陷不是改状态，而是完成验证链。 关闭条件至少包括：修复提交可定位、原问题验证通过、相关回归通过、用例和需求关联已更新。只把状态改成“已关闭”，不算闭环。

如果重测失败，带新证据重开；如果缺陷来自漏测，补一条能覆盖该场景的用例。把缺陷与代码提交、需求记录串起来，才能判断一次修复影响了哪些版本。指标上，除了关闭率，还要看重开率和漏测数。关闭率可以通过批量关单变好看，重开率更能暴露验证质量。

测试用例管理怎么落地：先跑通一条链路

不要一上来整理全量历史用例。选一个核心需求，用四周跑通一条链路：

• 第一周，统一最小字段集，明确谁维护用例、谁执行、谁验证缺陷。
• 第二周，把该需求拆成用例，检查需求覆盖率。
• 第三周，按批次执行，所有失败结果完成分流，产品缺陷回链用例和构建号。
• 第四周，复盘执行完成率、阻塞原因、重开率和漏测，再决定哪些用例适合自动化。

先跑通一条链路，再扩展全量用例库。 发布前设置质量门禁：关键用例未执行、阻塞未处理或高严重程度缺陷未验证，不进入发布。

度量看趋势而不是单点。需求覆盖率、执行完成率、有效缺陷率、缺陷重开率、漏测数，比用例总数更有判断价值。

测试用例管理做扎实，靠的不是更多表格，而是每条用例有来源、每次执行有记录、每个失败有去向。

测试用例管理常见问题

测试用例库是不是越大越好？

不是。用例库的价值在于覆盖需求、能被执行和方便维护。与其追求数量，不如先保证每条需求有对应用例，过期用例及时停用。

手工测试用例还需要维护吗？

需要。自动化测试工具通常覆盖稳定、重复的路径，探索性测试、异常场景和新需求验证仍要依靠手工用例。两类结果应回写到同一套用例和执行记录里。

缺陷关闭后还要补测试用例吗？

如果缺陷来自漏测，要补。新用例至少覆盖这次失败的场景，并加入相应回归范围；否则同类问题仍可能再次漏掉。