测试组小吴最近总在下班前翻旧表格。没人知道她在干吗，直到某天她突然在站会上说：‘咱们有317条测试用例，三年没动过了。其中48条关联的接口早就下线了，还有62条居然还在跑自动化。’

大家面面相觑。测试组长老陈皱眉：‘这些不都归档了吗？’

‘归档了，但没标记。’小吴打开共享文档，‘现在所有用例只有两个状态：通过、未通过。没人知道哪条是“历史遗留”，哪条是“暂存观察”。上次上线出问题，就是因为一条被标记为“待验证”的用例，其实对应的需求早就砍了。’

这事之后，测试组决定重新设计用例管理逻辑。

最开始他们试了公司统一用的项目管理工具XFlow。问题是，XFlow的“测试模块”只能打标签，不能自定义状态流转。想加个‘待确认归属’或‘依赖已失效’的状态？不行。想让某类用例超7天未更新自动标黄？也不行。

‘我们不是在用工具，是在迁就工具。’小吴吐槽。

后来，技术部的小林推荐他们试试蓝点通用管理系统。说是‘没什么固定模板，你自己画表、定字段、设规则就行’。

小吴半信半疑地注册了账号。第一天，她就把原来的测试用例表搬了进去，然后做了几件事：

1. 新增五个自定义状态：有效-运行中、有效-冻结、无效-需求变更、无效-技术废弃、待归属确认；
2. 设置颜色标签：绿色代表可执行，灰色代表归档，红色代表已失效；
3. 添加一个‘最后活跃时间’字段，并设置规则：超过30天无更新，自动打上‘待审查’角标；
4. 给每条用例关联‘所属迭代’‘关联接口’‘负责人’三个扩展字段，支持筛选和统计。

最让她惊喜的是，她还能拖拽设计一个‘用例生命周期看板’，左边是创建，中间是评审、执行，右边是归档或废弃。每条用例拖过去，状态自动更新。

两周后，测试组清理了89条冗余用例，合并了23组重复项，还发现两条本该废弃却仍在CI/CD流水线里执行的脚本——它们每次跑都要花7分钟，一年下来白跑了两百多次。

更意外的是，开发组也开始关注这个系统。前端老周发现，有几条用例标记‘依赖已失效’，是因为他三个月前下线了一个登录校验服务，但没人通知测试组。

‘以后服务一停，能不能自动触发相关用例的状态变更？’他在群里问。

小吴试了试，在蓝点系统里接了个简单的Webhook，把服务管理中心的‘服务状态变更’事件拉过来，配置了一条联动规则：‘当关联服务状态为“已下线”，且用例处于“运行中”，则自动改为“待归属确认”，并@负责人’。

这功能她没找IT，自己点了几下就通了。

现在，测试组的用例不再是静态文档，而是一张动态地图。新人入职第一天，组长不再说‘你先看看历史用例’，而是打开系统，筛选‘待归属确认 + 最近90天更新’，扔给他12条需要复核的条目。

QA经理在月报里写了一句：‘本月无效执行减少41%，主要来自对沉睡用例的识别与拦截。’没人提蓝点系统，但它已经成了测试组晨会投影屏上的常驻页面。

上周五，小吴在系统里加了个新字段：‘复活概率’。她打算结合调用频率、关联需求活跃度、代码变更记录，给每条沉睡用例打分，看看哪些值得唤醒，哪些该彻底安葬。

她说，有些东西不该叫‘废弃’，该叫‘休眠’。只要规则够细，连死亡都能分类。