大多数工程团队都知道需要测试自动化。理由并不难理解：发布延期、回归缺陷流向用户、人工 QA 在每个迭代中都成了瓶颈。真正困难的并不是要不要自动化，而是怎样把它做成一套真正能持续运行的机制。

那些尝试过自动化却失败的团队，通常不是因为选错了工具，而是因为想一次性自动化所有内容，最终得到一套脆弱且没人信任的测试集，然后又悄悄回到手工测试。

测试自动化本质

测试自动化是借助软件执行测试、把实际结果与预期结果比较并报告结果的过程，不需要人工逐项执行检查。QA 工程师不必在每次发布前手动点击完整用户流程，脚本可以按任意计划完成同样的工作：速度更快，执行没有差异。

定义听起来很简单，但更容易被忽略的是：自动化不是什么。

它不是 QA 工程师的替代品。自动化处理重复且可脚本化的工作，无法取代人的判断、好奇心，也无法替代人发现：虽然技术上通过了，但体验仍不对的能力。
它不是一个有明确结束日期的项目。每个上线功能都会带来需要维护的新测试。自动化是一项基础设施：需要逐步建设，并长期维护。
它不是一键切换的开关。成功的团队会让自动化和手工测试并行运行；只有自动化版本已经赢得信任时，才把某个流程交给它负责。

手工与自动化

维度	手工测试	测试自动化
速度	受人工执行速度限制	可在几分钟内运行数千项检查
一致性	会受测试人员、疲劳程度和时间影响	每次执行完全一致
覆盖范围	深度高，但难以扩展到多设备和多操作系统	可在任意矩阵上大范围、重复地执行
新功能	很擅长，人能发现意料之外的问题	较弱，只会测试被明确告知的内容
维护成本	较稳定，但随团队规模增长	前期投入较高，测试集成熟后会下降
最适用场景	探索式测试、新 UX、边界场景	回归、冒烟、高频流程

两种方式都不能替代另一种。成熟团队会有意识地同时使用：自动化覆盖已知、可预测、可重复的部分；手工测试覆盖需要人来思考的部分。

测试类型

测试自动化不是单一事物。不同类型解决不同问题；成熟的计划会叠加多种测试，而不是把赌注押在一种方法上。

单元测试

单元测试会隔离其他一切，验证最小的可测试代码单元，例如单个函数或方法。它是严肃测试计划的基础。

集成测试

集成测试验证组件能否正确协作。单元测试检查函数是否返回正确值；集成测试则检查调用该函数的 API 端点是否以正确格式返回正确响应和数据库数据。

功能与 E2E 测试

功能测试和端到端测试（E2E）会驱动真实或模拟的应用完成完整用户流程，例如从登录到结算、从完成引导到首次关键操作、从搜索到看到结果。它们以真实用户的体验方式测试整个系统。

回归测试

回归测试确认代码变更后，既有功能没有损坏。它是 QA 团队中最常见的自动化测试类型，直接回答了一个问题：我们是否改坏了什么？

冒烟测试

冒烟测试是一组小而快的检查，通常只有 5 到 15 个测试，用来确认应用能启动，最关键的路径仍可工作。可以把它理解为执行其他工作前的楼里着火了吗检查。

API 测试

API 测试验证后端端点是否返回正确响应、是否正确处理边界条件和错误，以及是否独立于 UI 执行服务间契约。因为它绕过了前端，所以速度快、稳定性高且可靠。

性能测试

性能测试衡量应用在负载下的表现，包括高峰和超高峰流量下的响应时间、吞吐量、错误率和资源消耗。

测试金字塔

测试金字塔是决定各层测试应该投入多少覆盖的最常用心智模型。它表达了一个关键取舍：越底层的测试，编写成本越低、执行越快、越稳定；越上层的测试，成本高、速度慢、容易脆弱，但对于捕获全系统问题不可替代。

     / E2E \\            少量：价值高，成本也高
    /-------\\
   / 集成测试 \\          部分：捕获跨组件缺陷
  /-----------\\
 /  单元测试   \\        大量：快、稳定，及早发现回归
/---------------\\

对多数移动团队而言，实践建议如下：

单元测试：覆盖全部业务逻辑、数据转换和工具函数，目标是获得较高覆盖率。
集成测试：覆盖服务间契约、数据库交互和 API 层行为。
E2E / 功能测试：只覆盖 5 至 10 条最关键的用户旅程，而非所有可能流程。

团队若反向操作，金字塔就会失效：单元测试很少，却有大量脆弱的 E2E 测试。这会形成所谓冰激凌蛋筒结构，最昂贵、最慢、最脆弱的测试承担了最多责任。这正是大多数自动化计划被放弃的模式。

自动化优先级

早期自动化最常见的错误，是从不合适的测试开始。团队会自动化看起来重要的内容，而不是采用一套决策框架，结果花数周构建的测试一年只能节省 20 分钟。

在投入任何工程时间前，请让每个候选测试通过频率、稳定性、后果三个筛选条件。

三项筛选条件

筛选条件 1：频率。这个测试运行多频繁？每次构建都执行的测试每天都会产生价值；每季度才运行一次的测试，可能不值得承担建设和维护开销。先从运行最频繁的测试开始。

筛选条件 2：稳定性。功能是否仍在活跃开发？为每个迭代都在变化的功能自动化，是浪费时间：更新测试的时间会超过它节省的时间。先自动化稳定、成熟的功能；正在变化的功能可以稍后处理。

筛选条件 3：后果。这个测试漏掉缺陷会怎样？登录流程影响每位用户；管理员账单设置页只影响少数人。无论技术复杂度如何，高后果流程都应排在前面。

| 频率 | 稳定性 | 后果 | 决策 |
| --- | --- | --- |
| 高 | 稳定 | 高 | 本周自动化 |
| 高 | 稳定 | 低 | 下个月自动化 |
| 低 | 稳定 | 高 | 最终应自动化 |
| 任意 | 不稳定 | 任意 | 暂缓，功能仍在变化 |
| 低 | 任意 | 低 | 长期保留手工测试 |

优先级结果

应用这三个筛选条件，几乎总会得到同一份短清单：

登录和认证流程：频率高、稳定，一旦出错后果严重。
核心用户旅程：产品最根本的工作，例如下单、发消息、转账。它经常运行、上线后稳定，出错影响巨大。
已经流入生产环境的缺陷对应的回归测试：某个缺陷曾影响过用户，就可能再次发生。每个生产缺陷都应产生一个能阻止其复发的自动化测试。
关键 API 端点：它们稳定、快速、后果严重，却经常被只关注 UI 测试的移动优先团队忽略。

从 10 个测试开始，不要从 50 个或 100 个开始。10 个完全信任的测试，胜过 100 个自己也拿不准的测试。

测试工具选型

工具选择得到的关注通常超过了它应得的程度。多数框架之争，实质上都在回答一个更基本的问题：团队里是否有能熟练编写代码的工程师？对这个问题的真实回答，在你比较任何功能之前，就决定了工具类型。

工具决策速览

你的情况	推荐路径
有编码能力的网页团队	Playwright
有编码能力，仅 Android	Espresso
有编码能力，仅 iOS	XCUITest
有编码能力，覆盖两个移动平台	Appium
没有编码背景的 QA 团队	AI 驱动的低代码工具
之前尝试失败，原因是脆弱选择器	先诊断根因，再考虑基于 AI 识别元素的工具
之前尝试失败，原因是无人维护	先修复责任归属模式，再选择新工具

选好起点后，下一步是以小范围并行方式让首批测试进入 CI，逐步接管回归，并避免体系在维护阶段失效。

收录于 FunTester 原创专题：软件测试的道与术

↙↙↙阅读原文可查看相关链接，并与作者交流