一、自动化的核心概念
- 定义：通过自动方式替代人工操作完成任务，生活中常见案例（自动洒水机、自动洗手液、超市闸机）体现了'减少人力消耗、提升效率 / 质量'的特点。
- 软件自动化测试的核心目的：
- 用于回归测试：软件迭代新版本时，验证新增功能是否影响历史功能的正常运行。
- 常见面试题解析：
- 自动化测试不能完全取代人工测试：需人工编写脚本，且功能变更后需维护更新，可靠性未必优于人工。
- 自动化测试不能'大幅度降低工作量'：仅能'一定程度'减少重复工作，需注意表述的严谨性。
二、自动化测试的分类
自动化是统称，包含多种类型，核心分类及说明如下：
| 分类 | 说明 |
|---|---|
| 接口自动化 | 针对软件接口的测试，目的是验证接口的功能、性能、稳定性等。 |
| UI 自动化 | 针对软件界面的测试，包含： |
- 移动端自动化：通过模拟器在电脑上编写脚本，测试手机应用；稳定性较差（受设备、系统版本等环境因素影响）。
- Web 自动化：模拟浏览器操作（如自动打开百度、执行搜索），替代人工完成网页操作与验证。 |
以'百度搜索'为例，Web 自动化的执行逻辑是：自动打开浏览器→访问百度首页→在搜索框输入内容→执行搜索→验证结果，以此替代人工的重复操作，提升测试效率。
三、自动化测试金字塔
1. 理想的自动化测试金字塔
- 结构与逻辑：
- 从下到上依次为：单元测试 → API / 集成 / 组件测试 → UI 自动化测试 → 手动 / 探索性测试。
- 核心特点：投入产出比从下到上递减——底层的单元测试消耗更少时间 / 精力，却能发现更多问题，投资回报率更高；上层的 UI 自动化、手动测试则需更多资源，但回报更低。
- 设计目的：倡导企业优先在底层（单元测试、接口测试）投入自动化，以更低成本保障软件质量。
2. 企业实际的'冰淇淋蛋筒模式'
- 结构与逻辑：测试层级类型相同，但资源投入分布倒置。
- 核心特点：企业实际中常将更多资源投入上层（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 自动化测试的核心执行工具。
