新人最容易把这两个词当成对立面：要么以为自动化测试就是功能测试的升级版，要么以为写了脚本就不用管功能覆盖。实际卡住的地方通常在排期和分工上——同一批用例到底该手工跑还是写成脚本、写成脚本之后谁来维护。这篇把两者的定位、判断标准和可执行动作拆开讲，帮你决定先做哪一步。
新人最容易把这两个词当成对立面：要么以为自动化测试就是功能测试的升级版，要么以为写了脚本就不用管功能覆盖。实际卡住的地方通常在排期和分工上——同一批用例到底该手工跑还是写成脚本、写成脚本之后谁来维护。把两者的定位掰开看，你会发现问题不在于哪个更高级，而在于你手上这批事该用哪种方式交付。
这篇按「测什么 / 怎么跑 / 先动哪一步」的顺序拆。每节都给你一个判断口径和一个能当场做的动作。涉及工具清单、脚本跑出来的耗时对比这类会变的东西，别背数字，去站内页面看当时的情况。
先分清：一个问「测什么」，一个问「怎么跑」
功能测试描述的是验证范围：给定输入、执行操作、拿到的结果是否符合需求。它不限定由谁来执行，人点也行、脚本点也行。自动化测试描述的是执行方式：用代码或工具代替人重复触发同一批步骤，它也不限定测什么，可以测接口、测界面、测数据处理。两者是交叉关系，不是升级关系。同一个用例，今天手工跑，下周改成脚本跑，功能覆盖一点没变。
判断口径很直接：如果有人问你「这轮功能测完没有」，他问的是覆盖面，看的是用例清单还剩几条没走；如果有人问你「这套脚本能不能跑」，他问的是执行方式，看的是跑起来有没有报错、跑完谁看结果。这两个问题混着答，排期就会互相甩锅。
- 功能测试
- 回答测什么：需求点有没有被验证到，手工和脚本都算数
- 自动化测试
- 回答怎么跑：步骤由代码或工具触发，重点是能重复、能无人值守
- 交叉点
- 同一批功能用例既可以手工跑也可以脚本跑，换的是执行方式不是覆盖范围
什么功能值得先自动化，什么先别动
优先挑回归频繁、步骤固定、断言明确的用例。典型特征是：每次发版都要重跑、操作路径每次一样、结果能不能通过机器直接判断。登录、下单主链路、权限校验这类属于常见候选。反过来，需求还在反复改、界面结构两天一变、需要人判断「看起来对不对」的视觉和体验类检查，先别动。写出来大概率是今天写完明天改，维护成本直接压过收益。
一个能落地的筛选顺序：先按执行频次排，再按人工耗时排，最后按失败后能不能自动判断排。三项都靠前的排最前面。不适用的情况也说清楚：一次性活动页、上线前才临时验证的配置项、只跑一次的迁移脚本，写脚本的成本高于手工跑一遍，这时候自动化没有意义。
- 高频回归：每次发版必跑的那几条，优先
- 步骤稳定：操作顺序和入口短期内不会改
- 断言明确：结果可以是文本、状态码、数据字段，不依赖肉眼判断
- 人工耗时高：单次执行占用大量时间，重复次数多
- 环境可控：能在本地或独立环境稳定复现，不依赖别人手动准备数据
把用例分成三层再决定谁跑
把手上用例粗略分三层，再决定每层用什么方式跑。接口层断言最稳、跑得最快，适合做成自动化主力，也是新人最好上手的一层，因为不涉及界面元素定位。界面层覆盖关键路径即可，全量堆界面脚本维护成本会迅速压过收益。人工层留给探索性测试、边界联想、易用性判断，这部分本来就补不上，硬上脚本只会得到一堆假绿灯。
分层之后别急着选工具，先写一张对照表，把用例编号、所属层、执行方式、触发时机落到表格里。触发时机要写清楚是每次提交就跑还是每天跑一次，这决定了脚本挂在哪个流水线阶段。表填完，工具选型基本就不用争了，因为约束条件已经摆在那。
| 用例层 | 典型内容 | 建议执行方式 | 触发时机 |
|---|---|---|---|
| 接口层 | 参数校验、状态码、字段返回 | 自动化为主 | 每次提交或每日 |
| 界面层 | 登录、下单、关键跳转 | 自动化只覆盖关键路径 | 每日或发版前 |
| 人工层 | 探索性测试、易用性、异常联想 | 人工执行 | 版本周期内安排 |
| 数据层 | 边界值、脏数据、并发写 | 接口自动化加人工抽查 | 每次提交或每日 |
新人第一周能落地的动作清单
别急着学工具。先把手上功能用例改写成「前置条件—操作步骤—预期结果」三段式。写不清楚的用例，自动化也很难写清楚，这一步是在逼你把需求理解对齐。改完挑三条最常跑的用例手工走一遍并记录每步耗时，这就是你后续判断要不要自动化的依据。
跑通一次现成的测试脚本，比从零写更值。先看懂别人的断言怎么写的、失败日志怎么读、报错信息和真实缺陷怎么区分。脚本跑出来的失败要分类处理，不要一股脑报给开发。相关概念和工具对不上号的时候，去站内把名词和目录对齐，别在术语上打转。
- 改写用例把现有功能用例补成三段式，缺前置条件或预期结果的先标出来，说明理解没对齐
- 手工计时挑三条高频用例手工走一遍，记录单次耗时和卡顿点，作为自动化的收益估算依据
- 读现成脚本找仓库里已经跑通的脚本，重点看断言写法和失败日志格式，先会读再会写
- 对齐名词遇到分不清的概念，去站内名词页和工具目录把定义和分类对齐，避免各说各话
- 失败分类把脚本失败分成环境问题、数据问题、真实缺陷三类，按类走不同处理路径
容易踩的四个坑
第一个坑是把自动化通过率当成质量结论。脚本只覆盖了它写到的部分，没写的等于没测，通过率再好看也说明不了未覆盖区域。第二个坑是断言太松，只判断请求成功不判断返回内容，接口字段改了脚本照样绿灯，这种脚本比没有更危险，因为它会给你一种测过了的错觉。
第三个坑是用例和脚本两份文档各写各的，需求一改只更新了一边。建议以脚本仓库为准，用例文档留注释说明对应脚本位置，改的时候两边一起动。第四个坑是不考虑执行环境和数据隔离，两条用例抢同一份测试数据，失败原因会一直指错方向。排查顺序建议是：先看环境是否干净，再看数据是否被占用，最后才怀疑代码缺陷。
还有一条判断标准值得记住：自动化测试不适用在需求频繁变动、结果需要人主观判断、执行次数只有一两次的场景。遇到这种，老实手工跑反而更快更准。
自动化不是功能测试的升级版，它只是把「怎么跑」这件事换成了机器，覆盖什么还是你自己说了算。下一步去站内工具目录把常见测试工具和适用场景对一遍，再决定你手上这批用例先从哪一层入手。→
常见问题
学会自动化测试是不是就不用做功能测试了？
不是。自动化只是换了执行方式，覆盖范围还是靠功能测试的思路来定。哪些场景要测、边界在哪、预期结果是什么，这些问题脚本回答不了。反过来说，手工跑通一遍也不代表下次改动能被及时发现，两者配合用才稳。
小团队人手少，应该先补哪一块？
先把功能用例写清楚，再挑其中跑得最频繁的几条做成自动化。用例本身含糊的话，写出来的脚本只会把含糊固化成红灯。如果只有一个人负责测试，优先保证关键路径每次发版都过一遍，其余靠探索性测试补。
自动化脚本老是因为环境问题失败，怎么办？
先把失败按原因分堆统计一段时间，看环境类占比到底多高。常见做法是固定测试数据、每次执行前重建环境、把外部依赖做成可控的桩。如果环境本身不稳，先修环境再谈脚本覆盖率，否则红灯会让人逐渐无视告警。
