自动化测试与手工测试的区别 案例分析

团队里一提到测试就有人喊「全上自动化」，也有人坚持「手工点一遍更踏实」。真到排期的时候，钱和时间都有限，到底哪些用例该自动化、哪些留给人工，谁也说不清。这篇给一套按「执行频次—判断复杂度—维护成本」三维判断的对照方法，配几个常见业务场景的取舍过程，让你下次评审测试方案时能直接拍板，而不是靠感觉。

团队里一提到测试就有人喊「全上自动化」，也有人坚持「手工点一遍更踏实」。真到排期的时候，钱和时间都有限，到底哪些用例该自动化、哪些留给人工，谁也说不清。这篇按「执行频次—判断复杂度—维护成本」三个维度给一套对照方法，配几个常见业务场景的取舍过程，让你下次评审测试方案时能直接拍板。

先说结论：自动化和手工不是替代关系，是分活关系。脚本擅长重复、稳定、断言能写成机器判断的活；人擅长第一次走查、找体验问题、发现「说不清哪里不对」的异常。下面按节拆开讲，每节都带判断标准和可执行动作。

先看频次和稳定性：哪些用例天生适合自动化

筛选自动化候选用例，看三个条件是否同时成立：跑得多不多、逻辑变不变、断言写不写得清楚。三个都满足的，优先写成脚本；缺任何一个，先缓一缓。回归测试、接口冒烟、数据一致性校验这三类通常命中率最高，因为每次发版都要跑，输入输出明确，出错就是出错。

• 回归测试里那些「上个版本改过、这个版本可能受影响」的用例，先自动化
• 接口层的参数组合与边界值，脚本比人跑得全，不要靠手点
• 数据校验类，比如对账、批量导入导出后的字段比对，机器判断更可靠
• 一次性验证和探索性验证别做脚本，写完就跑一次，纯浪费
• 需求还在频繁改动的模块，先手工守住，等接口稳定再补脚本

手工不可替代的几类活：别为了覆盖率硬写成脚本

有一类测试是为了「发现脚本想不到的问题」而存在的。探索性测试、易用性判断、异常路径里那种「感觉不对」、首次上线的完整业务走查，这些交给人工。人工的产出不只是通过或不通过，还有缺陷线索、体验反馈、和需求对不上的地方，脚本只能告诉你断言是真是假，不会告诉你这个流程蠢不蠢。

举例：一家 5 人小团队做后台管理系统首次发版，核心链路是登录、权限分配、订单处理。第一版优先人工把这三条链路完整走一遍，顺带记录哪里文案别扭、哪里跳转多余；等第二版接口稳定了，再把登录和权限分配抽成接口脚本，订单处理因为涉及审核规则变化频繁，继续留人工。

判断标准：什么时候人工产出比脚本值

判断复杂度高

需要人做主观评价，比如颜色、文案、交互顺不顺手，脚本写不出来

路径不确定

找不到固定步骤，靠经验临场发挥，写成脚本反而僵化

首次或低频执行

跑不了几次，脚本编写成本根本收不回来

需要产出改进建议

不只要通过与否，还要告诉开发哪里可以更好

算账方式：别只看脚本写得快不快，要看维护要多少人力

自动化的成本是三块加起来的：编写成本、每次需求变更的重写成本、环境与数据准备成本。只算第一块必然低估。一个用例值不值得自动化，用「用例生命周期内预计执行次数乘以单次人工耗时」跟「脚本编写加维护总量」比，前者大才值得。

1. 估执行次数问产品和开发，这个模块未来几个版本还会不会频繁回归，跑不到几次的直接放弃自动化
2. 估单次人工耗时人工跑一遍要多久，注意算上环境准备和数据清理的时间，不是只算点页面的时间
3. 估脚本总成本编写时间加每个版本因为需求变更要改的时间，再算上调试环境失败的时间，这三块别漏
4. 算比值再拍板执行次数乘以单次人工耗时，大于脚本总成本就做，否则先手工顶着，把用例记下来再说

环境不稳、数据依赖重、依赖第三方页面结构的场景，脚本会很脆，动不动就红。这种时候手工总成本反而更低。判断标准很简单：如果脚本每周都要因为环境问题挂几次，而每次排查都要人介入，那这套脚本的收益已经被吃掉了。

混着用的落地做法：分层、分工与失败处理

实际落地不是选边站，是分层。接口层和逻辑层用脚本挡住回归，界面层和主观体验层留人工，界面脚本只覆盖最核心的几条主路径，别追求界面脚本全覆盖。这样脚本数量可控，维护压力小，人工也能集中在真正需要人的地方。

失败处理要提前定规矩：脚本失败先判是环境问题还是真缺陷，别直接转人工重跑一遍就算过。环境问题走环境修复流程，真缺陷开单，重复出现的环境问题要把这个用例标记为待观察，连续几次都误报就把它从脚本里摘出来，改回人工。

• 把手工用例的产出结构化，攒到一定量再集体决定哪批转脚本，别零散地想起来就写一个
• 判断标准写进团队规范，比如什么特征必须自动化、什么情况必须人工，避免每次评审重新吵
• 脚本失败的分类结果要有人看，环境误报比例高说明环境该修了，不是加脚本能解决的
• 每次版本复盘回看一遍脚本和人工的分工，需求变了分工也得跟着调