为什么你的自动化测试一直没有价值？

某团队花了半年时间搭自动化测试框架，写了将近两千条用例。每次上线前 CI 跑一遍，绿了才敢发版。

看起来很规范，对吧？

但有一次，一个支付页面的金额计算逻辑出了问题，用户多扣了钱。这个 Bug 在线上跑了将近三天，才被用户投诉发现。然后大家去查自动化用例——那个计算逻辑，有用例，而且用例是通过的。为什么？因为用例写的是：点击"立即支付"按钮，页面跳转到成功页。金额对不对？没人管。

一、问题的根源：我们把"有测试"当成了"有保障"

这是自动化测试领域最普遍、最隐蔽的认知陷阱。

很多团队对自动化测试的理解停留在：

• 有没有框架？✅ 有，Selenium / Cypress / Playwright，随便挑
• 有没有用例？✅ 有，几百条甚至几千条
• CI 里有没有跑？✅ 有，每次提交都会触发
• 用例通过率多少？✅ 98%，很高

然后就觉得测试做得不错了。但这几个指标，一个都没有回答那个最关键的问题：你的测试，有没有在保护真正重要的业务逻辑？

二、自动化测试没有价值的五个死法

死法1：只测"流程通了"，不测"结果对了"

这是最常见的写法：

def  test_checkout():
    click("立即购买")
    click("确认支付")
    assert "支付成功" in page.text  # 只要有这行字就算过

用户看到"支付成功"，不代表账单是对的，不代表库存扣了，不代表订单状态写入了数据库。正确的测试应该验证副作用，而不只是验证 UI 状态。支付完成后，你要查数据库，对比金额；你要查库存，确认扣减；你要查订单表，确认状态变更。只有这些都对，这条测试才有意义。

死法2：用例覆盖了"正常路径"，对"边界情况"视而不见

用户输入 1 件商品，测试通过了。用户输入 0 件呢？输入 -1 件呢？输入 99999 件超出库存呢？

在正常情况下，代码往往没什么问题。真正的 Bug，藏在边界里。但大多数自动化用例，都是在模拟"一个行为正常、数据合法、网络顺畅的理想用户"。这种用户，现实中基本不存在。

死法3：测试和代码一起烂掉

代码改了，测试没跟着改，于是测试开始报红。然后怎么处理的？注释掉。或者改一个 assert，让它强行通过。

久而久之，用例池里出现了大量"僵尸用例"——它们活着，但保护不了任何东西。你去看那些老项目的测试代码，里面注释着大段大段的 assert，原因写的是："暂时跳过，待修复"。这个"暂时"，往往是一两年前的事了。

测试的技术债，比业务代码的技术债更难还清，因为它从来不在排期里。

死法4：测试粒度全错了

两种极端都很常见。

第一种：全是端到端测试，没有单元测试。

每次跑 CI，要等 40 分钟。一个函数改了三行，触发全量回归，跑完发现和那三行根本没关系。时间长了，开发不等 CI 结果就合并代码。自动化测试沦为摆设。

第二种：全是单元测试，没有集成测试。

每个函数都通过了，组合在一起就出问题。接口之间的契约没人测，上下游联调靠人工，数据库事务有没有问题全靠祈祷。合理的做法，是分层：单元测试快速覆盖核心逻辑，集成测试验证模块协作，端到端测试覆盖核心业务链路。金字塔结构，不是倒三角。

死法5：测试不跑在"真实环境"里

Mock 了数据库，Mock 了第三方服务，Mock 了时间，Mock 了随机数……

最后，你的测试跑在一个精心构造的幻象世界里，和生产环境的差距越来越大。Mock 本身没有问题，问题是过度 Mock。当你 Mock 掉的东西，恰好就是 Bug 藏身的地方时，测试就永远发现不了问题。

三、那什么样的自动化测试才有价值？

说几个实操原则，不废话。

原则1：每条测试，都要能回答"如果这条挂了，用户会受到什么影响"这个问题。

回答不上来的，要么删掉，要么重写。

原则2：测试要有"信息量"。

信息量的意思是：一条测试挂了，你能快速定位是哪里的问题，而不是花一小时 debug 才能搞清楚测试为什么失败。写测试的时候，assert 的错误提示要有意义。比如：

# 没有信息量
assert result == True

# 有信息量
assert order.amount == 99.00, f"订单金额应为99.00，实际为{order.amount}，可能是折扣计算逻辑有误"

原则3：测试要"稳定"。

一条测试，今天过，明天挂，后天又过——这比没有测试更糟糕。因为它会让团队失去对测试结果的信任，最终的结果是：红了也没人理。不稳定的测试，绝大多数来自两个原因：依赖了时间（如 datetime.now()），或者依赖了顺序（测试之间有状态共享）。治好这两个，稳定性问题基本解决一大半。

原则4：把"高价值路径"和"低价值路径"分开维护。

不是所有功能都值得花相同力气测试。支付、核心数据写入、权限校验——这些是高价值路径，值得写详尽的测试，值得定期 review。一个信息展示页、一个皮肤切换功能——测一个正常 case 够了，别浪费精力。测试预算是有限的，要花在刀刃上。

结尾

很多团队建立自动化测试体系，初衷是对的：想让人从重复的手工测试中解放出来，让机器替人守夜。

但执行着执行着，变味了——变成了一个"证明我们有测试"的工具，而不是"真正保护业务"的工具。

用例数量变成了 KPI，覆盖率变成了考核指标，测试通过率变成了上线门票。

当这些数字变成目的本身，测试的价值就已经死了。一个团队的测试文化是否健康，有一个最简单的判断标准：当 CI 全绿、测试全过的情况下，你们上线前，还有多少人心里是踏实的？如果答案是"不太踏实"，那问题不在测试工具，不在框架选型，不在用例数量。问题在于，测试从来没有真正和业务风险挂上钩。