自动化的核心概念
自动化本质上是用机器替代人工操作,生活中随处可见——自动洒水机、超市闸机,核心都是减少人力消耗并提升效率。在软件领域,自动化测试的核心目的很明确:回归测试。当软件迭代新版本时,我们需要验证新增功能是否破坏了历史功能的正常运行。
这里有个常见的误区需要澄清:
- 自动化不能完全取代人工。脚本需要人编写,功能变更后需维护更新,其可靠性未必优于资深测试人员。
- 自动化不能'大幅度降低工作量'。它只能'一定程度'减少重复劳动,表述上要注意严谨性。

自动化测试的分类
自动化是个统称,主要包含接口和 UI 两大类:
| 分类 | 说明 |
|---|---|
| 接口自动化 | 针对软件接口的测试,验证功能、性能、稳定性等。 |
| UI 自动化 | 针对软件界面的测试,分为移动端和 Web 端。 |
其中 Web 自动化 模拟浏览器操作(如打开百度、执行搜索),替代人工完成网页操作与验证。以'百度搜索'为例,逻辑是:自动打开浏览器 → 访问首页 → 输入内容 → 执行搜索 → 验证结果。

自动化测试金字塔
理想的测试结构像一座金字塔,底层稳固,上层精简:

1. 理想模型
从下到上依次为:单元测试 → API/集成测试 → UI 自动化 → 手动测试。 核心特点是投入产出比递减。底层的单元测试耗时少、发现 bug 多,ROI 高;上层的 UI 自动化和手动测试资源消耗大,回报相对较低。企业应优先在底层投入自动化,以低成本保障质量。
2. 现实模式
实际中常出现'冰淇淋蛋筒模式',即上层重、下层轻。原因是自动化需要大量初始投入(脚本开发、框架搭建),企业往往优先选择'看得见效果'的 UI 层,但长期来看,底层自动化的成本收益更优。
3. 结论
自动化与手动并非互斥,而是互补。底层自动化适合长期降本,上层测试适合覆盖复杂场景和探索性验证。

Web 自动化测试实战
驱动的核心作用
WebDriver 类似于汽车的发动机或电脑的驱动程序。程序要操作浏览器(打开、输入、点击),必须通过 WebDriver 建立通信。手动测试靠人手,自动化则靠代码通过 WebDriver 作为桥梁控制浏览器。





