自动化测试与手工测试的区别

刚接测试岗，常被两件事夹住：老板说要提效上自动化，可你连哪些用例值得脚本化都还没想明白。这篇不站队，只给你一套判断标准：哪些活手工干更快、哪些必须脚本兜住、两者怎么串成一条流水线，以及接错方向时怎么退回来。

刚接测试岗的人常被两件事夹住：老板说要提效上自动化，可你连哪些用例值得脚本化都还没想明白。更麻烦的是，网上讲这块的内容要么站队说自动化必学，要么把两种测试说得像两个物种。这篇不站队，只给你一套判断标准：哪些活手工干更快、哪些必须脚本兜住、两者怎么串成一条流水线，以及接错方向时怎么退回来。

先说结论：它们不是替代关系，而是分工关系。手工测试和自动化测试的差别不在工具上，而在“谁在判断”。搞清这一点，后面所有的取舍都会变得简单，你也不用再纠结要不要学自动化。下面按差异、成本、分流、配合、上手顺序、不适用场景、排查、衡量八块讲，每块都给你能直接照做的动作。

先把两者的差别说到底：不是工具有没有，而是谁在判断

很多人以为手工测试就是用手点、自动化测试就是用工具点，这个理解太表面了。真正的差别有两个：执行者是人还是程序，以及最终的结果判断由谁来做。程序只能判断你事先写好的条件，人不只判断条件，还会顺手注意到界面别扭、文案奇怪、流程绕、加载慢这些没写进用例里的东西。

手工测试的执行者

人。靠人的注意力和经验做判断，能捕捉意料之外的问题

自动化的执行者

程序。按脚本跑固定步骤，只对照事先写死的断言

手工的优势场景

探索新功能、找隐藏缺陷、评估体验和可用性

自动化的优势场景

重复执行、稳定回归、批量校验、每次发版前都得跑的那些

共同点

都以用例设计为前提，用例设计烂，两种方式都测不好

所以判断一条活该归谁，先问两个问题：这条检查需不需要人的主观判断？它未来会被重复执行多少次？第一问答“需要”的，偏手工；第二问答“很多次”的，偏自动化。两个都不满足的，先手工跑一遍，观察观察再说。

成本曲线不一样：手工是线性，自动化是前期高后期平

新人最容易踩的坑，是拿一次性任务的投入产出比去套自动化。手工测试的成本随执行次数线性增长，跑一百次就是一百次人力，谁也逃不掉。自动化不一样，它前期要写脚本、搭环境、配数据、定断言，投入全都压在头几次执行上，真正的收益来自“同一用例被反复执行”这件事。

也就是说，跑一两次的用例做自动化基本是亏的，跑几十次的核心回归项才有意义。中间那条界线在哪，取决于你的需求稳定度和执行频率，可以到 /guides 里翻翻同类项目的经验帖，再结合自己团队的真实节奏判断，别照搬别人的结论。

哪些用例值得脚本化：一张对照表帮你分流

分流不需要复杂的评估模型，看两个指标就够了：这条用例未来会被重复执行多少次，以及它的断言是否明确。断言写得出来、执行频率又高的，优先脚本化；断言含糊、还得靠人感觉的，先留在手工侧。下面这张表可以直接贴到团队文档里当分流依据。

• 优先脚本化：核心链路、主流程冒烟、接口契约校验、数据计算类逻辑、每次都跑的回归项
• 优先手工：首次探索新功能、界面与交互体验、一次性活动页、需求还在反复改的模块
• 介于两者之间：把手工发现的稳定缺陷点事后补成脚本，让同类问题不再靠人盯
• 判断口诀：看这条用例未来会被重复执行多少次、断言是否明确，两个都满足再投入脚本化
• 反向检查：如果一条用例三个月内只跑一次，基本不用考虑自动化

两者怎么配合：把手工发现的东西喂回自动化

手工和自动化最自然的配合节奏是“先探索后固化”。新功能刚上线，先手工跑通、跑熟，摸清主链路有哪些关键节点、哪些地方容易出问题；等需求稳定下来，再把主干路径固化成脚本，让机器替你盯住“以前好的地方没坏”。这个顺序反了会很痛苦：需求还没定就写脚本，改起来比手点还累。

1. 手工探索阶段新功能先用人工跑，重点记两件事：主链路有哪些节点，哪些地方反复出错；这两样都会成为后面脚本的骨架
2. 固化主干路径需求稳定后，把最核心的路径写成脚本；别贪多，先把主流程冒烟跑通，能稳定执行才算数
3. 挂进日常执行把脚本接到提交或发版前的检查环节，让它替你盯住回归；跑不动的先修稳定性，别急着扩规模
4. 缺陷回流手工阶段记下的缺陷，判断是否属于“会重复出现”的类型，是就补进脚本集合，让同类问题不再靠人盯
5. 定期瘦身每隔一段时间回看脚本集合，长期没失败也没改动的冗余脚本清掉，别让维护成本白白涨上去

这条流水线的关键在“回流”两个字。手工测试不是给自动化打杂，它负责发现新问题，自动化负责守住老问题。两者接上以后，你的时间会逐渐从重复点击里释放出来，挪到设计和探索上去。

新人上手顺序：别一上来就啃框架

很多新人一接触自动化就去啃框架源码、研究分层架构，结果两周过去一条脚本都没跑起来。正确的顺序是先跑通再抽象：先手工把被测系统跑熟，再挑几条最稳定的用例用最简单的方式脚本化，跑通就算成功，别在没跑起来之前纠结架构。

• 第一步：先把被测系统的核心流程手工跑通，能说出主链路有哪几个关键节点
• 第二步：挑 5-10 条最稳定的用例，用最简单的形式脚本化，跑通就算成功
• 第三步：接入到日常执行里，观察它是否真的每轮都跑，跑不动就先修稳定性
• 第四步：再考虑分层（接口层、界面层）和组织方式，别在没跑起来前纠结架构
• 第五步：找一两个同伴互相 review 脚本，一个人维护的脚本集合很容易烂掉

这套顺序的核心逻辑是：能跑起来的粗糙脚本，价值远大于设计精美但没跑过的框架。团队里如果只有你一个人在维护脚本，更要把规模控制住，宁可少而稳，不要多而烂。

什么情况下不该硬上自动化

自动化不是万能药，有些场景硬上只会浪费人力。判断标准很简单：如果你的脚本大概率活不过需求的下一次改动，或者断言根本写不出来，那这段时间就该留给手工。下面几种情况尤其要按住手。

• 需求还在高频变动、断言都还没定下来的模块，脚本写完就得改
• 一次性验证、生命周期极短的页面或活动，投入产出比不划算
• 强依赖人的主观判断的检查项，比如视觉美感、文案语气、体验流畅度
• 团队里没人能维护脚本时，先别扩大脚本规模，否则欠的是技术债
• 被测系统本身不稳定、环境经常挂的时候，先修环境，再谈脚本化

注意“不该硬上”不等于“永远不做”。它只是说当前这个时间点不划算，等你需求稳定了、环境可用了、断言能写清楚了，再回头把当初的用例补成脚本也不迟。判断依据是当前状态，不是永久结论。

脚本三天两头挂掉：一套排查顺序

脚本维护是自动化成本里最容易被低估的一块。脚本挂掉时，新手常犯的错是直接改脚本让它跑过，结果把真缺陷也一起盖掉了。正确的做法是先定性再定位：先判断是产品真坏了还是脚本坏了，这两者的处理方式完全不同。

1. 先定性脚本失败了，先人工按同样步骤跑一遍；人工也失败，就是产品问题，转去提缺陷，别动脚本
2. 查断言人工能过、脚本不过，先看断言是不是写得太死，比如把整段响应全字比对，稍有无关字段变化就挂
3. 查定位再看元素定位是否依赖动态属性、随机 ID、会变的文案，这类定位方式天生不稳
4. 查数据接着查测试数据是否被上一次跑脏了，同一条数据重复使用是常见污染源
5. 查环境最后看环境类问题：依赖服务是否可用、接口是否超时、并发太高是否被限流
6. 按序推进前一步没排除就不要往后查，否则定位问题的时间会全花在猜测上

这套顺序的价值在于“排除法”。每一步都在缩小范围，比凭感觉乱改脚本靠谱得多。脚本挂得频繁时不要只修单条，回头看看是不是同类定位或数据问题批量存在。想了解不同提供方在稳定性上的差别，可以到 /sites 看看各家公开的可用性说明。

怎么衡量这套组合有没有变好

衡量测试组合的改进，不要只看脚本条数。条数多不代表覆盖住关键路径，反而可能是维护负担。更值得盯的是三个方向：重复劳动占比有没有下降、发版前回归耗时有没有缩短、脚本的稳定执行率有没有提高。前者代表你从重复点击里释放了多少时间，后两者代表脚本有没有真正在替你干活。

还有一个动作值得定期做：拿一次真实缺陷往回看，问一句“这个问题如果早点脚本化，能不能更早被发现”。如果答案是能，说明分流表该更新了；如果答案是不能，说明这条缺陷本来就该靠手工探索来抓，不用硬塞进脚本里。站内 /tools/speed-test 可以帮你顺手测测接口响应，把不稳定因素早点暴露出来。

手工负责发现新问题，自动化负责守住老问题；两者接上以后，测试才是一条流水线，而不是两拨人各干各的。