刚入行做测试，常被两个问题绕住：一件事到底该手工点还是写脚本，自动化是不是早晚要取代手工。这篇不站队，只给你一套判断口径——什么信号出现就该自动化、什么情况下自动化反而更贵，以及一个从零开始的落地顺序。
刚入行做测试，常被两个问题绕住：一件事到底该手工点还是写脚本，自动化是不是早晚要取代手工。这篇不站队，只给你一套判断口径——什么信号出现就该自动化、什么情况下自动化反而更贵。先记住一句话：自动化不是升级版的手工测试，它是另一种成本结构，用错地方比不做还烧钱。
下面按成本、场景、投入比例、落地顺序、选工具五块拆开讲，每块都给能直接照做的动作。文中不给具体数字，涉及行情的部分到站内相关页面看你当时的实际情况再对照。
两种测试的成本结构不一样，别只比单次快慢
自动化是前期投入高、单次执行几乎零成本；手工是单次成本固定、没有建设期。很多人拿「脚本跑一次几秒钟、手工点一遍半小时」来论证自动化更划算，这忽略了写脚本、调脚本、维护脚本这些前期和后期的投入。用例总共就跑一两遍，自动化一定亏。
- 算总账看三个变量：同一条用例预期要跑多少遍、界面或接口改动频率、维护脚本的人力单价，三个里变动频率最容易被低估
- 需求还在反复改、界面一版一变的时候，脚本维护是无底洞，先手工跑更省事
- 已经稳定、还要长期回归的用例，才值得写脚本，稳定是前提不是结果
- 安全、合规、数据一致性这类必须留证据的检查，哪怕只跑一次也建议脚本化并留日志，这笔账跟成本无关
按场景对号入座：哪些适合自动化，哪些只能手工
不是所有测试都能自动化，也不是所有手工测试都低效。判断的土办法是看这条用例有没有稳定、明确、可程序化判断的预期结果。有明确断言的可以试自动化，靠人的感受和判断的只能手工。
| 场景 | 更适合 | 理由 |
|---|---|---|
| 接口参数组合与边界 | 自动化 | 输入输出明确，可枚举 |
| 批量数据校验 | 自动化 | 人眼看几百行必出错 |
| 回归冒烟、定时巡检 | 自动化 | 重复次数多，越跑越值 |
| 视觉与交互体验 | 手工 | 主观判断，脚本难断言 |
| 探索性测试 | 手工 | 目的是发现未知问题 |
| 需求未定型的原型 | 手工 | 改了脚本就废，纯浪费 |
灰区也要会处理：跨系统串联、断言明确的流程可以自动化，但如果中间依赖验证码、风控或人工审批，硬做脚本会不停失败，先手工跑，再想办法把可自动化的环节拆出来。另外提醒一句，性能与压力测试不属于「手工 vs 自动化」的范畴，它要单独选工具和压测环境，混在一起讨论会跑偏。
团队该投多少比例，看这几个信号再定
小团队比如五个人，先把接口层的回归脚本做起来，UI 自动化优先级放低——界面一改，你可能一半时间花在修选择器上。具体投多少比例没有标准答案，但什么时候该动手，有几个信号可以参考。
- 信号一：同一批用例一周内被重复执行三次以上
- 信号二：上线前回归总要熬夜，说明手工跑不完
- 信号三：漏测集中在固定几处逻辑，说明那块值得脚本兜底
- 信号四：出现人为遗漏导致的线上事故，事后能明确是某条可断言的检查没做，这类直接补成脚本
- 出现两条以上就该动手，只出现一条先观察，别为了自动化而自动化
别定「自动化覆盖率必须达到多少」这种帽子，那只会逼着人写一堆没人维护的脚本。先把最贵的手工重复劳动替换掉，剩下的再评估。团队规模和人员构成不同，这个阈值也不一样，没有通用答案。
从零开始的落地顺序，照着做就行
最怕一上来就大规模铺脚本，跑不通就全组陪着调。按下面顺序走，每一步都有验证点。
- 第一步：做样板挑三条最稳定、最常跑的用例做样板，跑通工具链和 CI 触发，先证明流程能闭环，而不是先追求覆盖多少条。验证标准是：改一次代码，脚本能自动跑起来并给出结果。
- 第二步：抽配置把测试数据、账号、环境地址抽成配置，别写死在脚本里，否则换环境就全废。验证标准是：换一套环境地址不用改脚本内容。
- 第三步：分失败类型脚本失败先分清是产品真错还是脚本过期，加一层「断言失败 vs 元素找不到」的分类，不然告警没人看。验证标准是：告警里能一眼看出该找开发还是找测试自己修。
- 第四步：记维护成本每次需求变更后同步更新脚本，把维护时间当成本记下来，超过阈值就退回手工。验证标准是：一个月后能说出这套脚本总共花了多少人力。
选工具前先量自己的基线，别一上来就买贵的
工具选型最忌讳看别人用什么就跟风。先量清楚自己的基线：接口响应和页面加载的波动范围有多大。波动大的环境做 UI 自动化，会一直在等待上纠缠，脚本今天过明天挂，最后没人信。
- 基线
- 你的接口响应和页面加载在正常情况下的波动范围，波动越大越不适合做界面自动化
- 协议层
- 只跑接口选轻量的工具，要覆盖界面再考虑带录制回放能力的
- 可维护性
- 看脚本能不能被非作者维护，用例命名、目录结构、失败截图这三样缺失，接手的人会很痛苦
- 全成本
- 把工具授权、CI 机时、维护人力一起算，再去比一次手工执行的时间，结论才站得住
成本核算时容易漏掉 CI 机时和维护人力这两块，很多人只算了工具本身的费用。社区版和商业版的差别、各家工具的授权方式，到站内工具目录看你当时需要的功能再对比。行情和费用数字不在本文写死，相关页面会更新。
最后说一句取舍原则：手工和自动化不是替代关系，是分工关系。人负责发现新问题、判断体验，脚本负责守住已经验证过的旧结论。想清楚这条边界，比例问题自己就有答案了。近期的工具和行情变化，可以到站内相关页面核对当时的数字。
下一步去工具目录按接口层和界面层分别筛一遍，对照自己的基线再决定要不要上界面自动化，比直接抄别人的选型清单靠谱。→常见问题
新人是不是应该直接学自动化，手工测试没前途？
不是。手工测试练的是发现问题的直觉和边界感，自动化练的是把它固定成可重复的检查。两者顺序上建议先会手工设计用例，再学怎么把稳定的用例脚本化。只会点脚本但不会设计用例的人，写出来的断言往往只覆盖了顺利路径。
我们团队小，是不是完全不需要自动化？
看重复劳动量。如果每次上线前都要手动跑同一批核心流程，哪怕只有五个人也值得把这几条做成脚本。但如果产品还在频繁改方向、界面一周一变，先手工，等结构稳定了再补，不然维护成本会吃掉省下的时间。
脚本老失败，是继续修还是干脆放弃？
先分类。如果失败原因是产品真的改错了逻辑，那是脚本在发挥作用；如果是选择器或测试数据过期，属于维护债，要评估修一次的耗时。同一批脚本一周内因为非产品原因失败多次，说明这层不适合自动化，退回手工更划算。
