做软件测试的人，手里都有一堆测试用例。刚开始写的时候挺认真，每一步都抠得明明白白。可项目一忙起来，需求一变再变，那些曾经精心设计的用例就慢慢变成了“僵尸文档”——看着还在，其实早就不顶用了。
为什么测试用例总在“过期”？
最常见的场景是产品经理改需求。上周还在测“用户注册要填身份证”，这周改成“支持手机号一键登录”。原来的用例还停留在老流程，照着跑一遍，发现根本走不通。这时候如果不去动它，下次回归测试照样出错，浪费时间还查不出问题根源。
另一个情况是系统重构。比如把登录模块从旧框架迁到新服务，接口全换了。但测试用例里写的还是老URL和参数格式，执行自动化脚本直接报404。这种时候光修脚本不行，用例本身也得同步更新，不然下个人接手又得重新踩坑。
怎么维护才不累？
与其等出问题再补救，不如把更新动作嵌入日常流程。每次需求评审会后，测试人员顺手拉一下相关用例清单，标记哪些需要调整。开发提测时，核对实际功能点和用例是否一致，就像做饭前先看一遍菜谱有没有缺调料。
对于团队共用的用例库，建议设置定期巡检机制。比如每个月抽出半天，集中清理三类内容：已经下线的功能用例、长期未被执行的冗余用例、以及步骤描述模糊的老用例。可以像整理衣柜一样，该删的删，该归档的归档。
举个真实例子
有次我们上线一个优惠券功能，原本用例写了“满100减10”。后来运营临时决定改成阶梯规则，“满100减10，满200减25”。测试同学没改用例，只在执行时口头调整，结果漏了边界值检查。上线后用户发现满199块也能减25，公司白白多赔了几千块。
打那以后，我们定了一条规矩：任何逻辑变更，必须先改用例再执行。哪怕只是改一行字，也要留记录。现在用的是TestLink这类工具，修改历史能追溯，谁改的、什么时候改的，一清二楚。
代码示例：如何标记待更新的用例
在自动化测试中，可以用状态标签快速识别问题用例。比如在Python + Pytest的框架里：
@pytest.mark.skip(reason="待更新：登录接口已迁移至v2")
def test_user_login_v1():
assert login('old_api_url') == 200
这样运行时会自动跳过，并提示原因。等更新完成后，去掉 @pytest.mark.skip 就行。比直接注释掉代码更规范，也方便后续跟踪。
测试用例不是写完就完事的文档，它是活的检查清单。更新维护做得好，每次回归测试才能真正起到“兜底”的作用。别小看每次改动那一两分钟的同步时间，省下的可能是几小时的排查成本。