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

你大概遇到过这种场面：团队说要提效，于是把回归用例全塞进自动化脚本，结果维护成本比手动跑还高；或者反过来，全都靠人点，一到发版前就通宵。这篇不讲概念定义，直接把两类测试的判断标准、切换时机和落地清单摊开，帮你决定哪些用例该写脚本、哪些必须留给人，以及判断失效在什么条件下不成立。

团队说提效，最常见的动作就是把回归用例全塞进自动化脚本，结果维护成本比手动跑还高；另一个极端是全都靠人点，一到发版前就通宵。问题不在自动化好不好，而在你有没有一套判断标准，决定哪些用例该写脚本、哪些必须留给人。

这篇不讲概念定义，直接从四个维度给打分口径，再补两笔成本账、分层分工、流水线触发方式和复盘信号。判断标准都有失效条件，会一并写清什么情况下不适用。

先看四个维度，再决定要不要写脚本

四项都高的用例才适合自动化，只满足一两项的硬做脚本通常得不偿失。判断不适用的情况也要先说清：一次性上线活动、需求一周内还会推翻的模块、结果只能靠人主观打分的功能，先别投入自动化，等形态稳定了再回来评估。

• 执行频次高但输入不稳定：先做数据构造工具，别急着写断言
• 输入稳定但结果只能主观判定：保留人工，脚本只做前置数据准备
• 失败后果高但频次低：写成手动检查清单，定期抽查
• 四项都低的用例：直接从回归集里删掉，别两边都留着

算清两笔账：脚本的写和维护

成本不止首次编写，还包括选择器变更、接口字段调整、环境更换带来的持续维护。评估时按「写一次 + 每周维护」的口径估，而不是只看第一次写完的那天，否则很容易出现首版很爽、三个月后没人敢改的局面。

首次编写成本

从设计用例到脚本稳定跑通所花的人时，通常只占全生命周期的一小部分

持续维护成本

每次产品改动后修脚本、修数据、修环境所花的人时，是决定自动化划不划算的主项

重试成本

用重试掩盖不稳定用例带来的隐性成本，会让红灯失去信号价值

对照口径可以用每秒执行耗时和人力分钟数做换算，具体单价与额度到 /tools/model-cost-calculator 和 /usage 核对当时的数字，不同环境跑出来的结果差很多，别用印象估。

按层分工：脚本守底层，人守上层

把系统按稳定性分两层：稳定层（接口契约、纯函数、数据校验）交给脚本做高频回归；变化层（页面布局、文案、多步交互）留给人快速抽查。改动影响面大但用例稳定的，优先自动化；改动影响面小却每次都靠人重新摸索的，写进手动检查清单而不是脚本。

1. 列出现有回归用例按稳定层、变化层打标，标不出来的先去问需求方最近会不会改
2. 按层分配归属稳定层写脚本、变化层进手动清单，两层都要有人认领
3. 做一张对照表写明每层负责人和失败后的第一联系人，避免两边都不管导致漏测
4. 留出交叉区边界模糊的用例先归手动，连续多次手动发现问题再升级成脚本候选

分层之后最怕的是责任真空。对照表要落到具体人，不能只写团队名；每次发版后花几分钟更新一次，比事后追责便宜得多。

接进流水线：怎么触发、怎么拦住

自动化用例按耗时拆成提交前跑的精简集和合并前跑的完整集，别把全量套件塞进每次提交。全量跑一次要等很久的话，大家会习惯性忽略红灯，红灯一失去威信，整套自动化就白搭了。

• 提交前：只跑与改动文件相关的精简集，控制在能等得住的时长内
• 合并前：跑完整回归集，失败就拦住合并，不允许带病进主干
• 定时：低频但重要的长链路用例放到夜间跑，结果第二天早上看
• 手动结果回流：每次手动发现问题记一笔，积累到阈值再决定是否脚本化

红灯处理顺序固定下来：先判断是用例本身失效还是产品缺陷，再看是不是环境问题。接口连通性排查可参考 /tools/verify 的检测口径，中转类接口的稳定性验证另有一套方法，别直接套用普通 HTTP 检测。

怎么判断这套分工有没有跑偏

跑一段时间后看三个信号：脚本维护工时是否超过它节省的手动工时、手动发现的缺陷是否集中在脚本已经覆盖的那一层、红灯是否长期无人处理。任何一个信号出现，说明分工该调了，不是加人加班就能解决。

每隔一段时间复盘一次用例清单，删掉长期没抓到问题的脚本，把连续多次手动漏测的点补进自动化候选。指标数字不用自己拍，站内 /benchmarks 与 /crowd-radar 提供了多人多时段交叉验证的口径参考，可以拿来对齐自己的统计方式。

自动化和手动不是二选一，而是按用例的稳定性和失败后果分工，分工错了，两种都费钱。