一、自动化的核心概念
- 用于回归测试：软件迭代新版本时，验证新增功能是否影响历史功能的正常运行。
- 自动化测试不能完全取代人工测试：需人工编写脚本，且功能变更后需维护更新，可靠性未必优于人工。
- 自动化测试不能 “大幅度降低工作量”：仅能 “一定程度” 减少重复工作，需注意表述的严谨性。
二、自动化测试的分类
自动化是统称，包含多种类型，核心分类及说明如下：
| 接口自动化 | 针对软件接口的测试，目的是验证接口的功能、性能、稳定性等。 |
| UI 自动化 |
针对软件界面的测试，包含： 1. 移动端自动化：通过模拟器在电脑上编写脚本，测试手机应用；稳定性较差（受设备、系统版本等环境因素影响）。 2. Web 自动化：模拟浏览器操作（如自动打开百度、执行搜索），替代人工完成网页操作与验证。 |
以 “百度搜索” 为例，Web 自动化的执行逻辑是：自动打开浏览器→访问百度首页→在搜索框输入内容→执行搜索→验证结果，以此替代人工的重复操作，提升测试效率。
三、自动化测试金字塔
1.理想的自动化测试金字塔
- 从下到上依次为：单元测试 → API / 集成 / 组件测试 → UI 自动化测试 → 手动 / 探索性测试。
- 核心特点：投入产出比从下到上递减—— 底层的单元测试消耗更少时间 / 精力，却能发现更多问题，投资回报率更高；上层的 UI 自动化、手动测试则需更多资源，但回报更低。
2.企业实际的 “冰淇淋蛋筒模式”
- 核心特点：投入产出比从下到上递增—— 企业实际中常将更多资源投入上层（UI 自动化、手动测试），但这些环节的投资回报率更低；底层的单元测试投入较少。
3.核心结论
自动化测试与手动测试并非互斥，而是互补：
- 底层自动化（单元、接口）适合长期降本，保障基础质量；
- 上层测试（UI、手动）适合覆盖复杂场景、探索性验证，提供短期保障。
四、Web 自动化测试
1.驱动的核心作用
计算机有了驱动程序就可以与设备（⽿机，摄像头，⻨克⻛，键盘，显⽰器等等设备）进⾏通信。
2.驱动管理工具：WebDriverManager
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() = 你通过渠道告诉司机 “去百度这个地址”。
| 定位逻辑 | 从整个页面找 “id=chat-textarea” 的任意元素 | 从 HTML 根节点（/html）开始，按 “层级路径” 找元素 |
| 稳定性 | 高（只要 id 不变，页面结构变了也能找到） | 极低（页面任意层级改了，路径就失效） |
| 长度 / 可读性 | 短、易读、易维护 | 超长、难读、难维护 |
| 依赖页面结构 | 不依赖（通过属性定位，和层级无关） | 完全依赖（层级错 1 个就定位失败） |
| 实际使用场景 | 工作中首选（99% 的场景用这个） | 仅临时调试 / 无属性可定位的极端场景 |
3.Selenium + 驱动 + 浏览器的工作原理
三者通过HTTP 通信实现自动化，流程为：
脚本的核心是「做事儿」，不是「造东西 / 练手」
| 核心目的 | 完成具体的、落地的任务（比如搜百度、批量改文件、自动发消息） | 学习 / 验证语法、造工具 / 结构（比如练打印、写链表、算算法） |
| 执行方式 | 「一键运行」就能自动干完所有事，不用手动干预 | 要么只输出一个结果，要么只是定义 “工具”（比如定义个类 / 链表），没实际干活 |
| 举例子 | “开百度→输文字→关浏览器” 代码 | 单行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编写的⾃动化脚本代码中，可以在终端看到创建的驱动服务地址。
