作者：AITester 团队
转载请联系授权
一个让测试经理崩溃的场景
上周和一位做 ToB 业务的朋友吃饭，他诉苦说：
“我们自动化测试做了三年，脚本攒了 800 多个。结果每次发版前，团队还是全员上阵手工点。问为什么，测试同学说：‘自动化脚本那玩意儿，信不过。’”
我问他：“800 多个脚本，都跑一遍要多久？”
他说：“理论上 4 小时。实际上三天能跑完就不错了，中间一半时间都在修脚本。”
这就是很多企业自动化测试的真实状态：不是没做，而是做了之后比没做还累。
下面这张图，很能说明问题：脚本化测试的维护成本，会随着时间和用例规模一路飙升。
图 1-1 自动化测试维护成本曲线：脚本化测试与平台化测试的对比
自动化测试的三大幻觉
我后来想了想，之所以会出现这种情况，是因为大家对自动化测试有三个幻觉。
幻觉一：录制回放就是自动化
很多团队起步阶段用录制工具，点几下鼠标就能生成一段脚本，看起来很美好。
但问题也很明显：
- 前端改一个 class 名，脚本就挂了。
- 页面布局一调整，选择器全失效。
- 业务逻辑稍微复杂一点，录制出来的脚本根本没法维护。
录制回放不是自动化，它只是把手工操作变成了不可维护的代码。
幻觉二：脚本越多，覆盖越全
800 个脚本听起来很多，但如果里面藏着大量重复、低价值的用例，反而是一种负担。
我见过一个团队，光是“登录后检查首页标题”这个场景就有 17 个脚本，分布在不同测试套件里。每次首页文案改一个字，17 个脚本全红。
数量不等于质量，重复不等于覆盖。
幻觉三：自动化测试是测试团队的事
很多公司把自动化测试当成测试团队的 KPI，开发和测试各干各的。
结果是：测试脚本里写的选择器，开发看不懂；前端改了 DOM 结构，也不会通知测试。两边信息割裂，脚本越来越脆弱。
自动化测试要真正跑起来，必须是开发、测试、产品一起参与的工程实践。
为什么自动化测试会变成“面子工程”？
这三大幻觉背后，其实是一个更深层的问题：大家把自动化测试当成工具问题来解决，而不是工程问题。
什么叫工具问题？
- 买个商业工具
- 引入一个开源框架
- 招聘几个会写脚本的人
这些当然重要，但工具只能解决“执行”的问题，解决不了“设计、管理、协作、度量”的问题。
真正的自动化测试平台建设，至少要回答四个问题：
1. 测什么？ 哪些场景值得自动化？哪些场景手工更快？
2. 怎么表达？ 用例是写在脚本文件里，还是抽象成可复用的场景？
3. 谁来维护？ 脚本挂了，是测试一个人修，还是开发测试一起修？
4. 怎么持续？ 自动化测试是 CI 的一环，还是发版前的突击任务？
如果这四个问题没想清楚，工具再先进也只是一堆漂亮的脚本。
我们把自动化测试从“脚本堆”改成“场景库”后，发生了什么？
我们服务过一家做供应链系统的客户，他们的状态和我朋友很像：
- 自动化脚本 600 多个
- 回归一次 2 天
- 脚本失败率长期 30% 以上
- 团队士气低迷，都在怀疑自动化测试到底有没有价值
我们做的第一件事不是换工具，而是把他们的脚本按业务场景重新归类。
原来他们的脚本长这样：
test_login.py
test_homepage.py
test_order_create.py
test_order_approve.py
…
按业务场景重组后变成：
场景：采购订单创建
├── 步骤：登录
├── 步骤：进入采购模块
├── 步骤：填写订单
├── 步骤：提交订单
└── 步骤：验证订单状态
场景：采购订单审批
├── 步骤：审批人登录
├── 步骤：进入审批中心
├── 步骤：通过订单
└── 步骤：验证流程状态
区别就像下面这张图：左边是传统脚本化测试，登录、导航、断言逻辑分散在每个脚本里，重复且难维护；右边是平台化测试，用例只描述业务场景，公共能力收敛到步骤执行器里统一实现。
图 1-2 传统脚本化测试与平台化测试的对比
就这么一个结构调整，带来的好处是：
- 业务语义清晰了：新人看到场景名就知道这个用例在测什么。
- 重复用例被合并了：登录、导航等公共步骤被抽象成可复用组件。
- 维护成本下降了：页面元素变了，只需要改一处公共步骤，而不是 17 个脚本。
这个客户后面才有了信心引入更稳定的执行引擎和自愈定位机制，但第一步，一定是先把“脚本思维”改成“场景思维”。
自动化测试平台真正的价值，不是“自动跑”，而是“自动维护”
很多人问我：什么样的自动化测试平台才算好？
我的标准很简单：上线三个月后，维护成本是不是比手工测试低。
如果三个月后，你每周还要花两三天修脚本，那这个平台就是失败的。不管它用的技术多先进。
要做到这一点，平台需要具备几个能力：
1. 用例模型化
测试用例不应该是一段自由发挥的代码，而应该是有结构的数据：
- 导航
- 点击
- 填写表单
- 验证
- 等待
- 清理
每个步骤都有明确的语义和参数。这样即使执行引擎换了，用例本身也不用重写。
2. 元素定位自愈
前端 DOM 结构变了，脚本就挂，这是脚本脆弱的核心原因。
自愈定位的思路是：不要只依赖一个选择器，而是综合多个属性（ID、class、文本、位置、角色等）进行加权匹配。当主选择器失效时，能自动找到最可能的新元素。
这不是为了偷懒，而是为了让脚本具备一定的容错能力。
3. 多角色流程支持
企业系统里大量测试场景涉及多角色：
- 员工提交请假
- 主管审批
- HR 归档
- 财务付款
传统脚本测试这种流程非常痛苦，因为需要不断切换用户 session。好的平台应该能自然支持多角色、多会话的流程编排。
4. 测试过程可观测
不是等脚本跑完了看一个失败率，而是在执行过程中就能看到：
- 哪个步骤在跑
- 哪个步骤慢了
- 哪个步骤失败了
- 失败原因是什么
可观测性让自动化测试从“黑盒运行”变成“白盒调试”。
写在最后
自动化测试不是神话，也不是面子工程。它本质上是一种工程能力。
这种能力需要：
- 清晰的用例建模
- 稳定的执行引擎
- 合理的分工协作
- 持续的度量优化
工具只是其中一环。如果你只买了工具，其他都没跟上，那自动化测试最终还是会变成“上线前手工点一遍”的悲惨结局。
如果你想快速评估一下，你们团队的自动化测试平台建设到了哪个阶段，可以领取我们整理的《企业自动化测试平台建设 Checklist》。
里面把我们过去服务客户时踩过的坑、必须检查的 96 个事项整理成了清单，从规划、建设、运营到度量，每个阶段该做什么、不该做什么，都列得很清楚。
需要的朋友可以在后台回复 【Checklist】，我会发给你。
AITester：专注企业级 Web 自动化测试平台建设，让测试从成本中心变成效率引擎。
