刚做测试的人常遇到两种极端：要么什么都手工点一遍，回归一轮累到崩溃；要么听说自动化测试更高级，上来就给一个还在天天改的页面写脚本，写完两周全废。这篇不站队，只给一套判断标准：什么信号说明该手工、什么信号说明该自动化，以及决定上自动化之后先做哪几步。文中不写具体数字和工具排名，遇到需要对比的地方会告诉你到站内哪个页面去看当时的情况。
刚做测试的人常遇到两种极端：要么什么都手工点一遍，回归一轮累到崩溃；要么听说自动化测试更高级，上来就给一个还在天天改的页面写脚本，写完两周全废。这篇不站队，只给一套判断标准：什么信号说明该手工、什么信号说明该自动化，以及决定上自动化之后先做哪几步。
先说清一件事：本文不写具体数字和工具排名，遇到需要对比的地方会告诉你到站内哪个页面去看当时的情况。你要带走的是判断顺序，而不是某个结论。
两者的差别不只是「谁点鼠标」
很多人把区别理解成工具不同，其实核心差别在「谁来下判断」。手工测试靠人的经验、直觉和联想，能在你事先没设想过的地方发现异常；自动化测试靠人写死的断言，只能判断你预先想到、并且明确写进脚本里的那部分。
- 手工测试
- 每次执行都消耗人力，但人能临时变通、能发现意料之外的问题
- 自动化测试
- 一次性投入换长期重复执行，代价是脚本本身也要维护，页面或接口一改就可能失效
- 维护成本
- 脚本也是代码，没人维护的脚本比没有脚本更糟，因为它会给出错误的安全感
所以判断时看的不是「哪个更先进」，而是一件事会被重复做多少次、预期结果能不能说清楚。重复次数高、预期明确，自动化才划算；重复次数低、预期模糊，手工更省事。
这些情况先别急着写脚本
新手最容易踩的坑，是在需求还没定型的时候就上自动化。页面和接口一两天就变，你写完的脚本还没跑几次就全红，修脚本的时间比手工点一遍还长。
- 需求还在反复改，界面和接口随时会动，此时写脚本基本等于给自己挖坑
- 需要审美、主观判断或探索性找 bug 的活，比如新功能首次验收、交互体验走查
- 只跑一次或极少数次的检查，写脚本的时间比手工点一遍还长
- 需要临场换思路、顺着一个异常继续深挖的场景，脚本只会按固定路线走
不适用的情况也要说清：如果一个功能已经稳定、又每次发版都要重跑，那即便你觉得「手工也能点」，也值得考虑自动化，因为重复次数会慢慢把成本拉回来。
出现这几个信号，就值得上自动化
自动化不是越早越好，而是踩到信号再上。下面这些信号出现一个，就可以开始评估；出现两个以上，基本可以动手了。
| 信号 | 为什么值得上 | 什么情况下不适用 |
|---|---|---|
| 同一批用例每隔一段时间就要重跑 | 重复次数多，人力成本会持续累积 | 只跑一次或极少数次的检查 |
| 接口稳定、字段约定清楚 | 断言能写得明确，不容易误报 | 字段还在频繁调整、约定没定 |
| 多人协作需要统一的结果 | 大家看同一份执行结果，不用「我这边点过了」 | 团队只有一两个人、沟通成本本来就低 |
| 核心链路必须每次发版都验 | 漏一次代价大，自动化能兜底 | 发版频率很低，几个月才发一次 |
还要注意一个常被忽略的点：自动化跑出来的结果，只有被人看、被人处理才有价值。没人看结果的流水线，跟没跑一样。所以决定上自动化之前，先想清楚失败之后谁来跟进。
决定上自动化之后，按这个顺序落地
顺序比工具重要。下面四步是按依赖关系排的，前一步没做好，后一步做出来也白搭。
- 先整理手工用例把现有手工用例写成有明确预期结果的清单，写不出预期结果的先剔除。这步偷懒，后面全是返工，因为脚本没法断言一个说不清的结果。
- 从一条链路开始挑最稳定、最核心、重跑次数最多的那条链路先跑通，跑通一条再铺开。不要一上来就铺全量，铺得越大越难定位问题。
- 接进日常流程把脚本挂到提交时、发版前这类固定节点自动跑。没人触发的脚本等于没写，放在本地文件里更是白费。
- 定好失败处理规则失败分三类：真 bug、脚本过期、环境问题。三类分开记录、分开跟进，不然很快就会没人看结果。
这四步做完再谈扩展和工具替换。顺序错了，通常不是慢一点，而是整套推倒重来。
选型时该看哪些维度
到选型阶段，最容易犯的错是照搬别人推荐的工具。别人团队有人会写代码、发版频繁，你这边可能只有一两个人、几个月才发一次，结论完全不同。
- 先看维护成本，而不是看「先进程度」，团队没人会写代码时，门槛低的方案往往更实际
- 看团队现状：人力、发版节奏、代码基础，这三项不同，结论就会不同
- 需要对比具体方案时，到 /tools/quality-check 与 /ai-nav/category/ai-coding 看当时的清单，不要照搬别人的结论
- 遇到涉及成本的地方，到 /price-watch 核对当时的数字，别凭印象拍板
判断标准说到底就一句：选那个你们团队真的能长期维护下去的方案。再高级的工具，没人维护也是负担。想横向看看别的团队怎么做，可以去 /sites 和 /rankings 了解当时的整体情况。
下一步把团队最近一个月的回归清单拿出来，按「重复次数」和「预期是否明确」两条筛一遍，标出其中适合自动化的那几条，再去站内页面核对当时的工具与成本情况。→常见问题
自动化测试是不是迟早要取代手工测试？
不会。自动化只能验证你写进脚本的那部分预期，探索性测试、首次验收、体验类判断还得靠人。现实中更常见的是两者分工：稳定的核心链路交给脚本反复跑，新功能和主观判断留给人。是否值得上自动化，看的是这件事会被重复做多少次、预期结果能不能写清楚。
小团队人手少，是不是就不该碰自动化？
不一定，但不该一上来就铺全量。人手少的时候优先把用例和预期结果写清楚，再挑一条最稳定、重跑最频繁的核心链路做自动化。如果发版频率很低、需求还在天天改，先把手工用例质量做扎实更划算。具体取舍可以按前面落地步骤里的四步来排优先级。
脚本老是跑失败，是不是自动化不靠谱？
多数是维护问题不是方案问题。失败要分类：真 bug、脚本过期（页面或字段改了）、环境或数据问题。三类混在一起报，很快就会没人看结果。建议每次失败都归一次类，脚本过期的立刻修或下掉，长期不跑的用例直接删除，不要留着当摆设。
