1. 课程导入

大家好，我是这门课的主讲。今天咱们聊聊自动化测试最基础的东西——它到底是什么，能干什么，不能干什么。

我见过不少团队，一上来就喊「我们要搞自动化」，结果花了大价钱买了工具，招了人，最后产出寥寥。说白了，就是没想清楚自动化测试的定位。这一章，咱们把地基打牢。

1.1 什么是自动化测试

自动化测试，就是用代码或工具来代替手工操作，去执行测试用例、比对结果、输出报告的过程。

你想想看，手工测试就是一个人坐在电脑前，点点点、输数据、看页面。自动化测试呢？就是写一段脚本，让机器替你做这些重复劳动。

举个例子。你要测一个登录功能：

• 手工测：打开浏览器 → 输入网址 → 输入账号密码 → 点登录 → 看页面跳转
• 自动化测：写一段 Python 脚本，用 Selenium 控制浏览器，自动完成上述步骤，并断言结果

我个人习惯把自动化测试分成三个层次：脚本层、框架层、平台层。初学者先别想平台的事，把脚本写好再说。

1.2 自动化测试的优缺点

任何技术都有两面性。我见过太多人只看到自动化的好处，忽略了它的成本。咱们客观地列一下。

优势	劣势
回归测试效率高，跑一遍只要几分钟	前期投入大，脚本开发成本高
可重复执行，不受人为情绪影响	维护成本高，UI 一变脚本就废
能执行手工难以覆盖的场景（如并发、大数据量）	发现新缺陷的能力弱，只能验证已知逻辑
可集成到 CI/CD 流水线，实现持续测试	对测试环境稳定性要求高
测试结果可量化，便于统计和分析	无法完全替代人工的探索性测试

所以我的建议是：自动化测试不是银弹。它擅长的是「重复验证」，不擅长「发现未知」。

1.3 自动化测试的适用场景

什么时候该上自动化？我总结了几条硬指标：

1. 需求稳定、变动少——比如核心业务流程、登录注册、支付结算
2. 回归频率高——每次发版都要跑一遍的用例
3. 数据量大、手工难以模拟——比如 1000 个用户的并发登录
4. 跨平台、跨浏览器——同一套逻辑要在 Chrome、Firefox、Safari 上验证
5. 需要集成到 CI/CD——每次代码提交自动触发测试

反过来，下面这些场景我建议你慎重：

• 界面频繁改版、交互逻辑不固定
• 一次性测试，跑完就扔
• 需要大量人工判断的视觉/体验测试
• 团队没有专职的自动化工程师

1.4 自动化测试金字塔模型

这是自动化测试领域最经典的模型，没有之一。Mike Cohn 在 2009 年提出，到现在依然是行业共识。

金字塔分三层，从下往上依次是：

• 底层：单元测试——测试函数、方法、类。跑得最快，成本最低
• 中间层：服务/接口测试——测试 API、微服务、业务逻辑。性价比最高
• 顶层：UI 测试——模拟用户操作。跑得最慢，维护成本最高

我见过很多团队把金字塔倒过来——UI 测试写了一大堆，单元测试几乎没有。结果呢？每次跑全量用例要 3 个小时，还经常因为元素定位失败而挂掉。

下面这张图，是我自己画的自动化测试金字塔结构，你看一眼就明白了。

你看，金字塔越往下，测试越稳定、执行越快、成本越低。所以我的建议是：把大部分精力放在中间层——接口测试。

为什么？因为接口测试既不像单元测试那样需要深入代码细节，又不像 UI 测试那样脆弱。我在项目中做过统计，接口测试的 ROI（投入产出比）通常是 UI 测试的 3-5 倍。

本章小结

这一章咱们聊了四个核心问题：

• 自动化测试是什么——用代码代替手工执行测试
• 它的优缺点——效率高但维护成本也高
• 适用场景——稳定、高频、数据量大的场景
• 金字塔模型——单元测试打底，接口测试为主，UI 测试为辅