谈到软件测试，“功能测试 vs 自动化测试”往往是最常被拿来对比的一对概念。但坦白说，这种比较本身有些跑偏——两者根本不在同一个维度上对立。它们回答的是两个截然不同的问题：一个关注“测什么”，另一个关注“怎么测”。你可以只执行其中一种，也可以两者兼顾。但如果你非要把它们当成二选一的抉择，团队很容易陷入一套拧巴的测试策略。

这篇文章就是想把这个概念理清楚：这两个术语分别属于哪个维度，在实际的 API 测试工作流中应该如何合理配置。

范畴错误

混淆的根源在于，把两个不同问题的答案拉到一起比较。

• 功能测试回答的是：“我们在测什么？”——它检验软件是否实现了预期的功能、行为、输出和特性。
• 自动化测试回答的是：“我们怎么执行这些测试？”——它利用软件工具替代人工去运行步骤。

这两件事互相独立。“测什么”和“怎么执行”是两个不同的轴。功能测试可以手动运行，也可以自动运行；自动化测试可以检查功能行为，也可以检查非功能行为（比如性能）。因此，真正的对比并非“功能 vs 自动化”，而是碰巧被放在一起的两个不同维度。一旦想通这点，“咱们该选功能测试还是自动化测试？”这类问题便失去了意义。正确的问题是：我们应该测什么，以及其中的哪些测试值得自动化？

什么是功能测试

功能测试验证应用的每个功能是否符合需求。它通常采用黑盒测试方式：不查看内部代码，只关注输入和输出。给定一个输入，观察输出，然后与需求文档中的预期结果进行对比。

放到 API 上，功能测试就是确认某个 Endpoint 返回了正确的数据、正确的状态码和正确的错误响应。POST /orders 到底有没有成功创建订单？用 400 状态码拒绝无效 Payload 时是否正确？响应格式与文档中的 Schema 是否一致？这些检查都依赖于 API 断言（assertions）来对比实际响应与预期响应。

功能测试的好处是直击要害：它检验的是用户真正关心的东西——功能是否好用。局限性也很明显：单靠它无法了解速度、负载下的稳定性或安全性。一个 Endpoint 功能上完美，但流量一上来就崩溃，这个缺口就需要性能测试（performance testing）来填补。功能测试是必需的，但不是全部。

功能测试真正的对立面是非功能测试（性能、负载、安全、易用性等），这才是一组正确的对应项，而不是“自动化测试”。

什么是自动化测试

自动化测试借助工具和脚本来执行测试并检查结果，而不是依靠人工一步步点击。你定义好测试用例、输入和预期结果，工具就能按需、按计划或每次代码变更时运行。

自动化测试的对立面是手动测试——人工执行每一步。这才是一组正确的对应项。

自动化的价值在于一致性和规模。机器运行第1000次与第1次完全一致，而且永远不会疲劳。它让回归测试的成本低到可以在每次提交时都执行一遍。代价是：测试需要编写和维护，而且它只能检查你明确告诉它要查的东西，无法做出主观判断。关于这一点，可以查阅什么是自动化测试的深入讨论。

关键点在于：自动化是一种交付机制，而不是一种测试类型。你自动化的是某种测试（功能的、性能的、安全的）。“自动化测试”本身并没有说明在检查什么。

两个维度的结合

把这两个轴放在一起，你会得到四个实际存在的象限，每个在实践里都很常见：

表格里的每个格子都是一种合法且常见的测试类型。左上角的“手动功能测试”是大多数人听到“测试”时脑海里浮现的场景。左下角的“自动化功能测试”是现代 API 测试套件的主力：自动检查功能的脚本或场景。右边两列是非功能性工作，同样可以手动或自动执行。

因此，有意义的决策不是“功能还是自动化”，而是：

• 测哪些行为？——功能和非功能都需要覆盖。
• 哪些测试应自动化？——选择那些稳定、重复、价值高的部分；把探索性和依赖主观判断的检查留给手动。

一个测试可以落在任何一个格子里，健康的测试策略应该覆盖所有四个象限。

API 测试中的应用

API 测试是这两个维度结合得最紧密的领域，因为 API 天生适合做自动化功能测试。

API 有清晰的契约（Contract）、结构化的请求和响应，没有 UI 需要渲染。它的功能行为很容易用脚本检查，也能做精确断言。因此，对于 API 而言，大部分功能测试都应自动化。当工具能在每次提交时自动完成这项工作，就没有理由让人手动重复发送相同的请求、肉眼盯着响应看几百遍。

一个实际的 API 测试方法大致是：将功能检查（状态码、响应体、Schema 符合性、错误格式）编写为测试用例（test cases），然后组合成测试场景（test scenarios）。这些场景通过 CI/CD 在每次变更时自动运行。非功能检查（负载和性能）也按计划自动执行。手动精力则投入到探索性测试和验证 API 是否真正解决了问题上——那些需要主观判断、靠脚本无法完成的确认（validation）工作。

哪些该自动化，哪些该保留手动

看清这两个维度后，真正的问题就浮现了：在所有可运行的功能测试中，哪些值得自动化？全部自动化是浪费，而自动化错的东西会产生又慢又脆弱的测试套件。下面几条规则可以帮助判断：

• 自动化重复且稳定的部分。 如果一个功能检查在未来两年每次提交都要运行，那就是完美的自动化候选。编写它的成本会被几百倍的回报覆盖。回归测试（确认旧功能依然正常）是最典型的例子。
• 优先自动化高价值路径。 登录流程、结账、核心 API Endpoint——一旦失败就会引发重大问题的地方，尽早自动化。这些是在 deadline 压力下你不敢跳过的手动测试，自动化直接消除了这种诱惑。
• 别自动化不稳定或罕见的部分。 只运行两次的检查不值得写脚本；每天都在变的功能每天都在破坏它的测试——等它稳定下来再说。对变动目标过早自动化，只会产生维护噪音。
• 探索性测试保持手动。 自动化测试只能发现你让它找的东西。人工用非脚本化的方式“试探”软件，能发现没人预料到的 Bug。这项工作也是功能测试，而且应该有目的地保持手动。
• 基于判断的检查保持手动。 错误消息到底有没有用？工作流是否连贯？API 到底有没有解决用户的问题？这些都需要人来判断，没有任何断言能捕捉到。

最终形成一种深思熟虑的分工：一个庞大的自动化功能套件覆盖稳定、关键、重复的路径，外加一个较小但持续的手动工作，专注于探索和判断。团队如果带着理性做自动化，就能获得快速反馈，而不是脆弱的套件；那些试图自动化一切的人，最后会陷入“维护测试”而不是“交付产品”的泥潭。

常见问题解答

• 自动化测试是功能测试的一种吗？ 不是。自动化测试是运行测试的一种方式。功能测试是关于测试什么的一个类别。自动化测试可以是功能性的，也可以是非功能性的；功能测试可以是手动的，也可以是自动化的。
• 功能测试可以自动化吗？ 可以，而且对 API 来说通常应该自动化。自动化功能测试（在每次变更时检查功能的脚本或场景）是现代 API 测试套件的核心。
• 功能测试真正的对立面是什么？ 非功能测试：性能、负载、安全和易用性。这些检查的是功能是否产生正确输出之外的特性。
• 每个功能测试都应该自动化吗？ 不。自动化稳定的、重复的、高价值的检查。探索性测试和基于判断的验证保持手动，因为自动化没法判断某样东西是否真正“好”，只能判断它是否符合预期。
• 团队应该从哪里开始？ 从自动化功能 API 测试开始。它们快速、稳定，且覆盖核心逻辑。在此基础上增加自动化非功能测试和手动探索性测试。
• 自动化测试会取代手动测试人员吗？ 不会。它取代的是工作中重复的部分（重复运行相同的检查），这样测试人员可以专注在探索性测试、边缘情况以及判断软件是否真正优秀上。这些任务需要人，而且比手动点击回归清单的价值高得多。
• 同一个测试可以既是功能性的又是自动化的吗？ 是的，大多数 API 测试正是这样：自动化功能测试。一个调用 Endpoint 并断言响应正确的脚本，既检查了功能，又是自动运行的。这两个标签描述的是同一个测试的不同方面，不是矛盾关系。