自动化测试与手工测试的区别。常见问题

团队里一喊「上自动化」，常见反应是两极：要么觉得手工测试该淘汰了，要么写了几百条脚本没人维护、一改需求全红。真实情况是两者管的根本不是同一类活。这篇按工程落地的角度讲差异、讲坑、讲成本怎么估，最后给一份可照着走的判断顺序。

团队里一喊「上自动化」，常见反应是两极：要么觉得手工测试该淘汰了，要么写了几百条脚本没人维护、一改需求全红。真实情况是两者管的根本不是同一类活，不是新旧替代关系，而是分工关系。

这篇按工程落地的角度讲差异、讲坑、讲成本怎么估，最后给一份可照着走的判断顺序。看完你至少能判断出：手上这批用例里哪些该做脚本、哪些该留在人手里。

两者的差别不在快慢，在「谁来判断」

手工测试的价值是人的判断：界面别扭、流程别扭、边界没写进需求却明显不对，这些脚本发现不了，因为它只检查你写下的断言。自动化的价值是可重复和可回归：同一批用例每天跑几十遍，结果一致，人不用守着；但它只覆盖你写下来的那部分判断。

所以分界线不是「重要不重要」，而是「这条用例的判断标准能不能被明确写出来」。写不出明确预期的，先留给手工。比如「这个页面用起来顺不顺」就没法写成断言，而「提交后状态字段变成已完成」可以。

适合自动化的用例

预期结果明确、步骤固定、会被反复执行的那批

适合手工的用例

探索性测试、体验类判断、需求还在变动中的新功能

不适用的情况

一次性上线前的探索、UI 大改版、需求本身还在晃的时候，先别急着把这些做成脚本，改一次废一次

成本怎么估：别只算写脚本那几天

自动化成本是三段：首次编写、每次需求变更后的维护、脚本失效后的排查。团队最容易低估后两段，通常维护才是长期大头。手工成本是每次执行都要投人，好处是不用维护，坏处是回归量一涨，人力就线性吃紧。

粗略判断法：一条用例预期会被重复执行多少次、变更频率多高。重复次数少或变更极频繁的，做自动化基本回不了本。具体的单价和人力折算不要凭感觉，去站内 /tools/model-cost-calculator 这类换算工具对齐口径，或者到 /coding-plans 看团队订阅额度怎么摊到人头上，再决定投多少人在测试上。

• 先数这条用例一个月大概会跑几次，跑不到几次的先别做
• 再看这个功能的需求最近改动频率，一周改好几次的缓一缓
• 把维护人力单独列一行，别混进「写脚本」那项里
• 环境搭建和数据准备的成本也算进去，这部分经常被漏掉
• 拿不准就先去站内工具页对齐口径，别用拍脑袋的数字算账

常见坑：脚本自己变成新的负债

很多团队做自动化的失败不是技术问题，而是脚本本身变成了没人敢动的负债。下面几条是最常踩的，按出现频率排的。

1. 别用固定等待用了固定等待，环境一慢就大面积假失败，团队很快就不看结果了。等待要挂在实际状态上，比如元素出现、接口返回，验证方法是把环境拖慢后重跑一遍，看结果是否还稳定。
2. 砍掉用例间的依赖前一条造的数据被后一条吃掉，单跑能过、整跑就挂。每条用例自己造数据、自己收尾，验证方式是乱序执行一遍，结果应该和顺序执行一致。
3. 别写「页面能打开就行」的断言跑绿了但什么都没验，属于虚假的安全感。改法是把断言落到具体字段值、状态变化或接口响应上，验证方式是故意改坏产品代码，看脚本能不能变红。
4. 先隔离环境几个人同时跑同一套，数据库互相污染。先确定这套脚本跑在哪套环境、数据从哪来，再谈覆盖多少，验证方式是同一时间多人各跑一遍，结果互不影响。

脚本跑绿不代表产品没问题，只代表你写下的那几条断言没被打破。

卡住了按这个顺序排查

脚本变红的时候，最常见的错误反应是直接改脚本。先按下面这个顺序走，能省掉大量无用修改。

• 先分清是脚本写错了还是产品真坏了，看失败日志里断言的具体值，对比上一次通过的记录
• 再看是不是环境问题，同一批用例换个时间、换台机器跑一遍，结果不同就先修环境别改脚本
• 然后看数据依赖，是不是上一条用例留下的状态导致这条失败，单独跑一遍验证
• 最后才考虑断言本身是否过期，需求改了但断言没改，是维护问题不是产品问题
• 改完补一条记录，别让同一条用例反复踩同一个坑

这个顺序的核心逻辑是：从最外层的干扰因素往里收，环境、数据、断言、最后才是产品本身。反过来从里往外查，很容易改坏本来正常的用例。更多回归策略和排错清单可以到 /guides 看当时的整理。

最后提醒一句：判断标准和团队规模、项目阶段强相关，一家 5 人小团队和几十人的测试组，切分线不会一样。别人写好的经验可以借鉴，但「哪些做自动化」这个决定必须结合自己项目的变更频率和回归量来定。