Web 自动化测试入门：从概念到百度搜索实战

Web 自动化测试入门：从概念到百度搜索实战 | 极客日志

Web 自动化测试入门

一、自动化的核心概念

定义：通过自动方式替代人工操作完成任务，生活中常见案例（自动洒水机、自动洗手液、超市闸机）体现了'减少人力消耗、提升效率/质量'的特点。
软件自动化测试的核心目的：
- 用于回归测试：软件迭代新版本时，验证新增功能是否影响历史功能的正常运行。
常见面试题解析：
- 自动化测试不能完全取代人工测试：需人工编写脚本，且功能变更后需维护更新，可靠性未必优于人工。
- 自动化测试不能'大幅度降低工作量'：仅能'一定程度'减少重复工作，需注意表述的严谨性。

文章配图

二、自动化测试的分类

自动化是统称，包含多种类型，核心分类及说明如下：

分类	说明
接口自动化	针对软件接口的测试，目的是验证接口的功能、性能、稳定性等。
UI 自动化	针对软件界面的测试，包含：
1. 移动端自动化	通过模拟器在电脑上编写脚本，测试手机应用；稳定性较差（受设备、系统版本等环境因素影响）。
2. Web 自动化	模拟浏览器操作（如自动打开百度、执行搜索），替代人工完成网页操作与验证。

以'百度搜索'为例，Web 自动化的执行逻辑是：自动打开浏览器→访问百度首页→在搜索框输入内容→执行搜索→验证结果，以此替代人工的重复操作，提升测试效率。

文章配图

三、自动化测试金字塔

文章配图

1. 理想的自动化测试金字塔

结构与逻辑：
- 从下到上依次为：单元测试 → API / 集成 / 组件测试 → UI 自动化测试 → 手动 / 探索性测试。
- 核心特点：投入产出比从下到上递减——底层的单元测试消耗更少时间/精力，却能发现更多问题，投资回报率更高；上层的 UI 自动化、手动测试则需更多资源，但回报更低。
设计目的：倡导企业优先在底层（单元测试、接口测试）投入自动化，以更低成本保障软件质量。

2. 企业实际的'冰淇淋蛋筒模式'

结构与逻辑：与理想模型倒置：从下到上依次为：单元测试 → API / 集成 / 组件测试 → UI 自动化测试 → 手动 / 探索性测试。
- 核心特点：投入产出比从下到上递增——企业实际中常将更多资源投入上层（UI 自动化、手动测试），但这些环节的投资回报率更低；底层的单元测试投入较少。
现实原因：自动化需大量初始投入（如脚本开发、框架搭建），企业往往优先选择'看得见效果'的上层测试，但长期来看，底层自动化的成本收益更优。

文章配图

3. 核心结论

自动化测试与手动测试并非互斥，而是互补：

底层自动化（单元、接口）适合长期降本，保障基础质量；
上层测试（UI、手动）适合覆盖复杂场景、探索性验证，提供短期保障。

四、Web 自动化测试

1. 驱动的核心作用

类比理解：驱动类似于'汽车的发动机''电脑的设备驱动程序'——程序要操作浏览器（如打开、输入、点击），需要通过**WebDriver（浏览器驱动）**建立程序与浏览器的通信，实现自动化操作。
Web 自动化中的定位：手动测试需人工操作浏览器，而自动化程序需通过 WebDriver 作为'桥梁'，让代码能控制浏览器执行预设流程。

计算机有了驱动程序就可以与设备（耳机，摄像头，麦克风，键盘，显示器等等设备）进行通信。

文章配图

2. 驱动管理工具：WebDriverManager

功能：是一个开源 Java 库，可自动管理 Selenium WebDriver 所需的浏览器驱动（如 ChromeDriver、GeckoDriver 等），包括自动下载、配置驱动版本，还能识别本地浏览器版本并匹配对应驱动。
使用方式（Maven 依赖示例）：通过在项目中引入如下依赖，即可自动管理驱动：

文章配图

WebDriverManager 解决了'手动下载、匹配驱动版本'的繁琐问题，降低了 Web 自动化测试的环境搭建成本，提升了自动化脚本的可维护性。

五、Selenium（Web 自动化测试工具）

1. Selenium 的定位

Selenium 是主流的 Web 自动化测试工具，提供丰富的 API（方法），用于模拟人工在浏览器中的操作（如打开页面、输入内容、点击按钮等），是编写 Web 自动化脚本的核心工具。

2. 简单的 Selenium 自动化示例

1. 环境依赖（Maven）

需在项目中引入 Selenium 的 Java 库依赖：

文章配图

2. 自动化脚本逻辑（以'百度搜索'为例）

代码实现'打开 Chrome 浏览器→访问百度→搜索关键词→点击搜索→关闭浏览器'的流程，核心步骤：

文章配图

创建浏览器配置对象（ChromeOptions/EdgeOptions）

它的作用是'给浏览器设置启动参数/规则'，就像你打开浏览器前先设置：

'要不要无痕模式？要不要允许跨域？要不要最大化窗口？'

文章配图

如果没有这个配置对象：浏览器会以'默认裸状态'启动，可能触发跨域报错、窗口太小导致元素找不到、弹窗拦截操作等问题，自动化容易失败。

实例化驱动对象（WebDriver）并关联配置

文章配图

这里的逻辑是：

ChromeDriver是驱动的具体实现（对应 Chrome）；
传入options后，驱动启动浏览器时会'带着配置规则'打开浏览器；
driver本质是'驱动的实例'，不是'浏览器实例'——你操作driver，就是驱动帮你控制浏览器。

把整个流程比作'你指挥司机开汽车'：

驱动（ChromeDriver）= 司机（懂怎么开 Chrome 这款'车'）；
浏览器配置对象（ChromeOptions）= 你给司机的'开车规则'（比如'开之前先开窗、关空调、走高速'）；
driver = 你和司机的'沟通渠道'；
你调用driver.get() = 你通过渠道告诉司机'去百度这个地址'。

维度	简写 XPath（相对 XPath）	Full XPath（绝对 XPath）
定位逻辑	从整个页面找'id=chat-textarea'的任意元素	从 HTML 根节点（/html）开始，按'层级路径'找元素
稳定性	高（只要 id 不变，页面结构变了也能找到）	极低（页面任意层级改了，路径就失效）
长度/可读性	短、易读、易维护	超长、难读、难维护
依赖页面结构	不依赖（通过属性定位，和层级无关）	完全依赖（层级错 1 个就定位失败）
实际使用场景	工作中首选（99% 的场景用这个）	仅临时调试/无属性可定位的极端场景

3. Selenium + 驱动 + 浏览器的工作原理

三者通过HTTP 通信实现自动化，流程为：

启动服务：Selenium 脚本启动ChromeDriverService，创建本地服务（IP: localhost，端口由服务分配）；
连接驱动：脚本通过服务地址向 WebDriver（浏览器驱动）发送 HTTP 请求；
驱动解析：WebDriver 解析请求，打开浏览器并生成sessionid（后续操作需携带此 ID 标识会话）；
执行操作：Selenium 的所有操作（访问地址、定位元素等）通过服务发送请求到 WebDriver，再由 WebDriver 转发给浏览器；
浏览器执行：浏览器解析请求并执行对应操作，将结果通过 WebDriver 返回给 Selenium 脚本。

文章配图

六、脚本的核心是「做事儿」，不是「造东西/练手」

特征	是脚本	不是脚本
核心目的	完成具体的、落地的任务（比如搜百度、批量改文件、自动发消息）	学习/验证语法、造工具/结构（比如练打印、写链表、算算法）
执行方式	「一键运行」就能自动干完所有事，不用手动干预	要么只输出一个结果，要么只是定义'工具'（比如定义个类/链表），没实际干活
举例子	'开百度→输文字→关浏览器'代码	单行`System.out.println("hello")`、写个二叉树类、写冒泡排序

1. 为啥'单行打印 hello'不算脚本？

目的：只是验证'能不能输出文字'，没有完成任何「有价值的落地任务」（比如打印 hello 解决了啥问题？啥都没解决）；
执行：只输出一个字符串，没有'步骤链'，也没有'自动化价值'——就算跑 100 次，也只是打印 100 次 hello，没干任何实际活。

2. 那'写个数据结构（比如链表/二叉树）'算脚本吗？

只写「数据结构的定义」（比如定义链表节点、写 add/delete 方法）→ 不算脚本：你只是造了个'工具'，但没拿这个工具干任何事（比如用链表存 100 个学生成绩、排序），本质是'练手写工具'，不是'用工具做事'；
若你写：「定义链表 + 往链表加 10 个数据 + 遍历打印所有数据 + 输出到文件」→ 算脚本：因为你用数据结构完成了「存数据→打印→存文件」的具体任务，是'按步骤自动干活'。

代码内容	算不算脚本？	核心判断
写个 for 循环，打印 1 到 100	算「极简脚本」	完成了'输出 1-100'的具体小任务
写个计算器函数（加/减），但只定义不调用	不算	只造工具，没实际算任何数
写计算器函数 + 输入 2 个数 + 调用加法 + 打印结果	算脚本	完成了'计算 2 数之和'的具体任务

跑代码后，如果它能「自动完成一件你需要的具体事儿」，就是脚本；如果只是'练语法/造工具/出个无意义结果'，就不是。

核心价值

Selenium 通过'脚本→驱动→浏览器'的分层通信，实现了代码对浏览器的无人工干预控制，是 Web 自动化测试的核心执行工具。

验证方式：执行 Selenium 编写的自动化脚本代码时，可以在终端看到创建的驱动服务地址。

Web 自动化测试入门：从概念到百度搜索实战