作者：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 自动化测试平台建设，让测试从成本中心变成效率引擎。