自动化测试与手工测试的区别 选择原则

测试团队最常卡住的不是「要不要上自动化」，而是「这条用例到底该不该自动化」。全上脚本，维护成本压垮人；全靠手工，回归一遍要熬夜。这篇给一套按用例特征做判断的顺序，以及自动化和手工怎么分工的做法，照着对一遍就能定下来。

测试团队最常卡住的不是「要不要上自动化」，而是「这条用例到底该不该自动化」。全上脚本，维护成本压垮人；全靠手工，回归一遍要熬夜。这篇给一套按用例特征做判断的顺序，以及自动化和手工怎么分工的做法，照着对一遍就能定下来。

先记住一句：自动化不是「更高级的手工」，它是另一种东西。把它当升级版来铺，通常会得到一堆跑不动又不敢删的脚本。把它当成一个「按特征派活」的问题，反而好办。

两者差的不是「快慢」，是判断方式

自动化执行的是预先写死的断言，它只能验证「预期内有没有变」；手工靠人的观察和联想，能发现预期外的问题。同一句「这个页面正常吗」，脚本回答的是「那几个字段还是不是原来的值」，人回答的是「看着别扭不别扭、点下去顺不顺」。

• 结果能不能被明确字段或状态码判断，能判断才谈得上自动化；
• 这条用例会不会反复跑，只跑一两次的不值得写脚本；
• 需求本身还会不会大改，大改期间写脚本等于挖坑；
• 发现问题后要不要人临场判断，要判断的留给手工。

什么情况下值得写成自动化

判定标准就三条：反复跑、结果可枚举、需求相对稳定。三条都满足再动手，缺一条就先放一放。高频回归、接口层校验、数据计算、权限与鉴权分支、批量参数组合，这几类通常最划算，因为跑得越多越省人力。

1. 列回归频率把最近几次发版都手动跑过的用例挑出来，这些是自动化候选，频率不够的先不动。
2. 看断言可写性问自己能不能用字段、状态码、返回值把「对错」写清楚，只能靠「看起来对不对」的，先排除。
3. 挑一小批试点从候选里选一小批跑通一轮，验证维护成本，再决定扩不扩，别一上来铺全量。
4. 定期回头看跑了一段时间后，统计哪些脚本经常因为界面改动而修，这些就是该退回的。

什么情况下手工更划算

探索性测试、首次验收、新功能体验、视觉与交互细节、跨端兼容的观感差异，这些自动化的覆盖成本远高于收益。它们要的不是「跑一遍有没有报错」，而是「走下来顺不顺、报错文案会不会误导人、异常中断后用户能不能自己恢复」。

• 探索性测试：没有固定脚本，靠人边试边想，脚本替代不了；
• 新功能首验：需求刚落地，脚本跟着改的损失比手工大；
• 视觉与交互：按钮位置、文案语气、动效是否别扭，靠人眼；
• 跨端观感：不同设备上的实际感受，脚本很难完整描述；
• 异常恢复：中途断网、返回、刷新之后用户能否自己走回来。

反过来也要看清楚：已经稳定几个月、每次发版都要重跑一遍的用例，还留在手工清单里就是纯消耗。判断标准是「这条用例最近几次发版有没有真的发现问题」，没有发现又在反复跑的，就该进待评估队列。

分工怎么定，以及什么时候要重估

常见分法是：核心链路在接口层用自动化兜底，界面层只自动化稳定路径，剩下的交给手工按发版节奏抽查。注意，这个分法不是一次定死的，它会随着需求冻结程度、上线频率和团队人力三件事变化。

落地动作很简单：把用例清单打上「自动化/手工/待评估」三个标记，每次发版后改一次标记。比写一份分工文档有用，因为标记是活的，文档写完就过期了。

判断一条用例该给谁做，看三件事：跑得勤不勤、结果能不能写清楚、需求还会不会大改。