企业官网建设流程全解析

自动化测试不是万能药 — 什么时候该做，什么时候不该做

11年测试老兵的血泪教训：不是所有测试都该自动化，也不是所有自动化都有价值。盲目追求数字的"覆盖率"，最后只会得到一堆没人维护的废弃脚本。

一、开篇：一个真实的"伪自动化"故事

2018年，我刚转做测试开发，接手一个项目的自动化测试任务。领导要求"半年内自动化覆盖率达到70%"。

我拼了命写脚本，3个月写了200+条自动化用例，覆盖率从0飙到68%。PPT汇报时全场掌声——

但3个月后，这200条用例只有32条还在跑。

为什么？

• 120条因为UI改版全废了，没人更新
• 48条因为数据过期失败，没人维护
• 30条因为环境不稳定频繁假失败，直接被跳过

最终真正有效的自动化用例只有32条，覆盖率从68%暴跌到12%。

这个故事告诉我们：自动化测试不是万能药，用错了地方就是毒药。

二、自动化测试的3个核心价值

在讨论"该不该做"之前，先明确自动化测试到底解决什么问题：

1. 效率价值 — 重复劳动的终结者

这是最直观的价值。我后来重新规划了自动化策略，只对高频执行的回归场景做自动化：

💡效率提升不是"跑得更快"，而是"跑得更频繁"。自动化真正的力量在于让你敢跑、能跑、常跑。

2. 一致性价值 — 消除人为差异

手工测试最大的隐患：同一个用例，10个人跑出10种结果。

自动化脚本每次执行步骤完全一致：

• 操作顺序一致
• 等待时间一致
• 检查点一致
• 结果判定一致

我在指纹锁测试中，20万次模拟操作循环如果靠人手工做，不可能保证每次操作标准统一。自动化让每一次操作都精确如初。

3. 覆盖价值 — 做人做不到的事

有些测试人根本做不了：

• 大数据量测试：1万条并发请求，人敲不了
• 长时间稳定性测试：1000小时不间断运行，人盯不了
• 边界值穷举：浮点数边界、编码边界，人想不全
• 多环境并行：5个OS版本同时跑，人管不了

这才是自动化的"甜蜜区"——做人力不可及的事，而不是替代人力可及的事。

三、什么时候该做自动化？

✅ 强烈推荐的场景

⚠️ 可以做但ROI一般

❌ 不应该自动化的场景

四、ROI计算 — 用数据说话，别凭感觉

自动化测试的ROI不是"覆盖率"，而是投入产出比。

计算公式

自动化ROI = (节省的测试时间 × 执行频次 - 开发维护成本) / 开发维护成本 其中： - 节省的测试时间 = 手工执行时间 - 自动化执行时间 - 执行频次 = 用例生命周期内预计执行次数 - 开发维护成本 = 编写时间 + 维护时间 × 维护频次

实际计算示例

结论：用例A值得自动化，用例B不值得。ROI差了30倍。

💡实战建议：在开始写自动化之前，先做一次ROI评估。宁可只自动化20条高ROI用例，也不要写200条废弃脚本。

五、自动化测试的4个常见陷阱

陷阱1：覆盖率崇拜

现象：追求"覆盖率80%+"的KPI，不管用例质量。

真实代价：

• 高覆盖率 ≠ 高质量
• 大量低价值用例稀释维护精力
• 数字好看，实际回归缺陷发现率很低

正确做法：追求有效覆盖率——只统计仍在运行、能发现真实缺陷的用例。

陷阱2：自动化 = 录制回放

现象：用Selenium IDE录制脚本就算"自动化"了。

真实代价：

• 录制的脚本没有抽象，UI一改全废
• 无法参数化，一条脚本只能测一个数据
• 没有断言设计，跑了等于白跑

正确做法：录制只是起点，必须做Page Object封装 + 数据驱动 + 断言设计。（后面章节会详细讲）

陷阱3：忽视维护成本

现象：只算开发成本，不算维护成本。

真实代价：

我做过统计，一个自动化用例的生命周期成本分布大概是：

开发：30% 维护：50% ← 最大头 环境适配：15% 文档：5%

维护成本是开发的1.67倍！如果只看开发成本就决定做不做，必然高估ROI。

正确做法：评估时把维护成本算进去。公式里已经有维护成本项，别忽略。

陷阱4：自动化替代人工

现象：“有了自动化，测试人员可以裁员了。”

真实代价：

• 自动化只能验证"已知的预期行为"
• 探索性测试、边界直觉、用户体验判断，AI和脚本都做不了
• 自动化测试发现的是"已知的已知"，人工测试发现的是"未知的未知"

正确做法：自动化 + 人工 = 最佳组合。自动化做重复，人工做探索。

六、我的自动化测试决策清单

经过11年踩坑，我总结了一个简单的决策清单。每次接到"这个要不要自动化"的问题，过一遍这个清单：

决策流程图

第1步：这个测试会执行超过5次吗？ ├─ 否 → 不自动化 ❌ └─ 是 → 继续 第2步：功能稳定吗？（最近3个月没大改） ├─ 否 → 暂不自动化，等稳定 ⏸️ └─ 是 → 继续 第3步：手工执行很痛苦吗？（耗时长/重复度高/容易出错） ├─ 否 → 低优先级，可以晚点做 🟡 └─ 是 → 继续 第4步：ROI > 1.0 吗？ ├─ 否 → 不值得自动化 ❌ └─ 是 → 值得自动化 ✅ 第5步：有人能维护吗？ ├─ 否 → 先解决维护问题再自动化 ⚠️ └─ 是 → 开干 ✅

快速判断口诀

高频、稳定、痛苦、有人维护 — 四条全中，毫不犹豫上自动化。
低频、易变、简单、无人维护 — 碰都别碰。

七、自动化测试的分层策略

不要一上来就搞UI自动化。正确的优先级是：

╱ UI自动化 ╲ ← 最少（10-15%） ╱ 接口自动化 ╲ ← 最多（60-70%） ╱ 单元测试自动化 ╲ ← 基础（15-20%） ╱────────────────────╲

💡接口自动化是ROI之王。投入低、稳定性高、发现缺陷率高。如果预算有限，先做接口自动化。

八、总结：自动化测试的"三要三不要"

✅ 三要

1. 要算ROI— 用数据决策，不是用感觉
2. 要分层— 接口优先，UI兜底，单测打基础
3. 要维护— 自动化不是一锤子买卖，持续维护才是生命线

❌ 三不要

1. 不要追覆盖率— 有效覆盖率 > 纸面覆盖率
2. 不要录制即用— 录制是起点，封装才是终点
3. 不要替代人工— 自动化做重复，人工做探索

下篇预告

下一篇：《2026自动化测试工具全景图 — 选型不再迷茫》

我将横评Selenium、Appium、Playwright、Pytest、Cypress、Katalon、Airtest、Hopper（鸿蒙）等主流工具，按场景给出选型决策树，帮你用一张图解决"该用什么工具"的纠结。

专栏持续更新中，点个关注不迷路。

作者：11年测试开发老兵，主导200+用例自动化转化，5人天回归压缩至0.5人天。专注Python自动化、数据库测试、硬件测试、AI辅助测试、鸿蒙应用测试。

本文为作者原创，转载请注明出处。