关注「软件测试就业联盟」公众号，陪你走好校招求职的每一步
导读
学自动化测试，最容易走偏的一点是：一上来就盯着工具。
有人直接学 Selenium，有人直接学 Playwright，有人直接背 Pytest、Jenkins、Docker，也有人看到 AI 测试火了，就开始研究 Agent、用例生成、智能执行。
但真正进入企业项目后会发现，自动化测试不是“会写脚本”就够了。
它背后其实是一套完整的质量能力体系：
从基础测试能力，到自动化专项能力；
从测试工程化，到线上质量运营；
再到质量治理、测试左移右移、行业业务理解。
也就是说，自动化测试不是一个孤立技能，而是测试工程师从“执行测试”走向“构建质量体系”的关键入口。
阅读目录
- 自动化测试到底学什么，不只是写脚本
- 第一阶段：先把基础测试能力打牢
- 第二阶段：从接口自动化切入，比 UI 自动化更稳
- 第三阶段：掌握自动化框架，而不是堆脚本
- 第四阶段：接入 CI/CD，让自动化真正跑起来
- 第五阶段：走向测试工程化，解决数据、环境、稳定性问题
- 第六阶段：结合 AI，提升测试设计与问题分析效率
- 从0到1学习路线建议
- 最后：自动化测试的价值，不止是减少手工操作
一、自动化测试到底学什么，不只是写脚本
很多人理解自动化测试，第一反应是：
用代码代替人工点页面、调接口、校验结果。
这个理解没错，但不完整。 真正的自动化测试至少包含四层能力：
从这张能力图看，自动化测试不是单点技能，而是一条成长路径。
- 低阶自动化解决的是“重复执行”的问题。
- 中阶自动化解决的是“稳定回归”的问题。
- 高阶自动化解决的是“质量体系建设”的问题。
所以从0到1学自动化测试，不能只问：
我应该学 Selenium 还是 Playwright？
更应该问：
我怎么从测试基础出发，逐步具备独立搭建自动化体系的能力？
二、第一阶段：先把基础测试能力打牢
自动化测试的前提，不是会代码，而是知道“测什么”。
如果测试设计能力薄弱，自动化脚本写得越多，问题越大。
常见情况是：
- 脚本很多，但覆盖不到核心业务风险；
- 用例很多，但断言非常浅，只判断页面有没有打开；
- 测试跑通了，但线上还是频繁出问题；
- 自动化维护成本越来越高，最后没人敢动。
所以第一阶段，要先补齐基础测试能力。
1. UI 测试
不是简单点页面，而是理解：
- 页面元素是否正确展示；
- 表单校验是否完整；
- 用户操作路径是否符合预期；
- 异常输入、边界条件是否处理合理；
- 不同浏览器、不同分辨率下是否稳定。
2. 接口测试
接口测试是自动化测试最重要的入口之一。 需要重点掌握：
- 请求方法：GET、POST、PUT、DELETE；
- 参数类型：query、path、body、header；
- 状态码含义；
- JSON 数据结构；
- 鉴权方式；
- 业务断言；
- 数据库校验。
接口自动化之所以适合作为入门方向，是因为它比 UI 自动化更稳定，也更接近业务逻辑。
3. App 测试
如果项目涉及移动端，还需要理解：
- Android / iOS 基础差异；
- 安装、启动、卸载流程；
- 弱网、切后台、权限弹窗；
- 机型兼容；
- App 日志分析。
4. 测试用例设计
自动化脚本不是凭感觉写的，而是由测试用例转化而来。
常见测试设计方法包括：
- 等价类；
- 边界值；
- 判定表；
- 状态迁移；
- 场景法；
- 异常路径设计。
一个合格的自动化测试工程师，首先要能写出有价值的测试用例。
三、第二阶段：从接口自动化切入，比 UI 自动化更稳
从0到1学习自动化测试，建议优先从接口自动化开始，而不是直接做 UI 自动化。
原因很简单：
- UI 自动化容易受页面变化影响，维护成本高；
- 接口自动化更稳定，更适合建立自动化测试思维。
接口自动化要掌握的核心能力
| 能力 | 具体内容 |
|---|---|
| HTTP 基础 | 请求方法、状态码、Header、Cookie、Token |
| 接口调试 | Postman、Apifox、curl |
| 编程语言 | Python 或 Java，建议先选一种 |
| 自动化框架 | Pytest、Requests、Allure |
| 数据驱动 | YAML、JSON、Excel、数据库 |
| 断言设计 | 状态码、字段值、业务状态、数据库结果 |
| 鉴权处理 | Token、Session、签名、OAuth |
| 报告生成 | Allure、HTML Report |
| 持续集成 | Jenkins、GitLab CI、流水线触发 |
一个接口自动化用例，不能只写成这样：
assert response.status_code == 200
这种断言太浅，只能说明接口返回成功，不能说明业务正确。 更合理的断言应该包含：
def test_create_order(api_client):
response = api_client.post("/api/orders", json={
"sku_id": 1001,
"count": 1
})
assert response.status_code == 200
data = response.json()
assert data["code"] == 0
assert data["data"]["order_id"] is not None
assert data["data"]["status"] == "created"
如果是关键业务，还需要进一步校验数据库、消息队列、库存变化、支付状态等。 自动化测试的核心不是“请求成功”，而是“业务结果正确”。
四、第三阶段：掌握自动化框架，而不是堆脚本
很多团队自动化做不起来，不是因为不会写脚本，而是因为没有框架思维。
一开始写几个脚本没问题，几十个脚本还能维护。
但当用例达到几百条、上千条时，如果没有统一封装，项目很快会失控。
一个基础自动化框架通常包含这些模块：
自动化框架至少要解决五个问题
- 第一，配置不能写死。 不同环境的域名、账号、数据库连接，要统一管理。
- 第二，测试数据要可维护。 测试数据不要散落在脚本里，否则后期维护非常痛苦。
- 第三，公共方法要封装。 登录、鉴权、下单、查询、清理数据，应该抽成公共能力。
- 第四，日志和报告要清晰。 失败时能快速定位是接口问题、数据问题、环境问题，还是脚本问题。
- 第五，用例要分层。 冒烟用例、回归用例、核心链路用例、异常场景用例，要能分组执行。 自动化测试项目的成熟度，不是看脚本数量，而是看它是否可维护、可扩展、可定位。
五、第四阶段：接入 CI/CD，让自动化真正跑起来
自动化测试如果只能在本地手动执行，价值会打折。
真正有价值的自动化测试，应该进入研发交付流程。
比如：
- 开发提交代码后触发接口自动化；
- 测试环境部署后自动执行冒烟测试；
- 合并主干前执行核心回归；
- 发布前执行关键业务链路验证；
- 执行结果自动通知到群里；
- 失败用例自动生成报告并定位日志。
这就是测试工程化能力。
这一步需要掌握：
- Git 基础；
- Jenkins 或 GitLab CI；
- Linux 命令；
- Docker 容器；
- 测试环境部署流程；
- 测试报告归档；
- 失败通知机制。
这也是很多测试工程师拉开差距的地方。 只会写脚本，更多是自动化执行者。
能把自动化接入研发流程，才开始具备测试工程化能力。
六、第五阶段：走向测试工程化，解决数据、环境、稳定性问题
自动化测试项目真正难的地方，通常不是写第一条用例，而是长期稳定运行。
企业里常见的问题包括：
- 测试数据经常被污染；
- 测试环境不稳定；
- 第三方接口不可控；
- 用例之间互相依赖；
- 脚本执行顺序一变就失败；
- UI 元素变动导致大量脚本失效；
- 报告只有失败截图，没有定位信息；
- 自动化跑完了，但没人看结果。
所以测试工程化阶段，要重点解决三个问题。
1. 测试数据治理
测试数据要尽量做到：
- 用例前准备数据；
- 用例后清理数据；
- 不依赖脏数据；
- 关键数据可重复构造；
- 不同用例之间相互隔离。
- 测试环境治理 测试环境要关注：
- 环境版本是否一致；
- 配置是否可追踪；
- 服务是否全部启动；
- 数据库、缓存、消息队列是否正常；
- 失败时能不能区分是环境问题还是业务问题。
- 自动化稳定性治理 自动化不是跑一次成功就算成功，而是要稳定跑很多次。
需要关注：
- 用例失败率；
- 误报率；
- 平均执行耗时；
- flaky 用例数量；
- 用例维护成本；
- 失败定位效率。
自动化测试的目标，不是让脚本越来越多，而是让质量反馈越来越快、越来越准。
七、第六阶段：结合 AI，提升测试设计与问题分析效率
现在 AI 已经开始进入测试流程，但它更适合做“辅助增强”，而不是完全替代测试工程师。
AI 在自动化测试中的典型应用包括：
- 根据需求文档生成测试点；
- 根据接口文档生成接口用例；
- 根据页面结构生成 UI 自动化脚本；
- 根据报错日志分析失败原因；
- 根据缺陷记录归纳高风险模块；
- 辅助生成测试数据；
- 辅助编写 Mock、断言、脚本模板。
例如，我们可以让 AI 根据接口文档生成测试用例初稿，但测试工程师必须继续判断：
- 业务路径是否完整；
- 异常场景是否覆盖；
- 断言是否有效；
- 数据构造是否合理；
- 是否存在权限、并发、幂等问题；
- 是否符合真实业务规则。
AI 能提升效率，但不能替代质量判断。 未来测试工程师的竞争力，不是“会不会用 AI 写脚本”，而是能不能把 AI 放进测试体系里，变成可控、可验证、可维护的工程能力。
八、从0到1学习路线建议
如果完全从零开始，可以按下面这条路线走。
第1阶段：测试基础与业务理解
重点学习：
- 软件测试流程；
- 测试用例设计；
- 缺陷管理；
- Web 项目基础；
- HTTP 协议；
- 接口测试；
- 数据库基础；
- Linux 常用命令。
阶段目标：
能独立完成一个业务模块的测试分析、用例设计、接口测试和缺陷跟踪。
第2阶段：接口自动化入门
重点学习：
- Python 基础；
- Requests；
- Pytest；
- 接口鉴权；
- 数据驱动；
- Allure 报告；
- 日志封装；
- 配置管理。
阶段目标：
能独立搭建一个基础接口自动化项目，并完成核心接口回归。
第3阶段：UI 自动化补充
重点学习：
- Selenium 或 Playwright；
- 元素定位；
- 页面等待；
- Page Object 模型；
- 浏览器兼容；
- 截图与失败重试；
- 核心业务链路自动化。
阶段目标：
能完成稳定的核心页面流程自动化，而不是把所有页面都机械自动化。
第4阶段：持续集成与工程化
重点学习：
- Git；
- Jenkins；
- Docker；
- CI/CD 流水线；
- 自动化报告推送；
- 测试环境管理；
- 测试数据管理；
- 失败用例分析。
阶段目标：
能把自动化测试接入研发流程，形成持续反馈机制。
第5阶段：专项能力与质量体系
重点学习：
- 性能测试；
- 安全测试基础；
- 测试左移；
- 线上质量监控；
- 日志分析；
- APM 链路追踪；
- 灰度验证；
- 质量度量；
- AI 辅助测试。
阶段目标：
从“写自动化脚本”升级到“参与质量体系建设”。
九、不同阶段应该产出什么作品
学习自动化测试，最好不要只停留在看课和记笔记。
每个阶段都应该有明确产出。
| 阶段 | 建议产出 |
|---|---|
| 测试基础 | 一个完整模块的测试用例文档 |
| 接口测试 | 一套接口测试用例和接口测试报告 |
| 接口自动化 | 一个可运行的 Pytest 接口自动化项目 |
| UI 自动化 | 一个核心业务链路自动化项目 |
| 工程化 | Jenkins 自动执行与报告推送 |
| 质量治理 | 自动化稳定性分析、失败分类、质量看板 |
尤其是准备求职或转岗时，不要只写“熟悉自动化测试”。
更好的表达是：
基于 Pytest + Requests 搭建接口自动化框架，支持多环境配置、数据驱动、Token 鉴权、Allure 报告生成，并接入 Jenkins 实现每日定时回归。
这种表达更具体，也更像真实项目经验。
十、自动化测试常见误区
误区一：先学 UI 自动化，忽略接口自动化
UI 自动化更直观，但维护成本高。
接口自动化更稳定，也更适合作为自动化入门主线。
误区二：只判断状态码，不做业务断言
状态码 200 不代表业务正确。
自动化测试一定要关注业务结果，而不是只关注请求是否成功。
误区三：脚本越多越好
脚本数量不是核心指标。
真正重要的是覆盖核心风险、稳定运行、失败可定位。
误区四：不会代码就不能学自动化
代码确实要学，但不需要一开始就学得很深。
先掌握变量、函数、类、文件操作、异常处理、常用数据结构，再结合测试场景训练，效率会更高。
误区五：AI 可以直接替代测试工程师
AI 可以生成用例、脚本和分析思路，但质量判断仍然需要人来负责。
测试工程师的价值会从“执行测试”转向“设计验证体系”。
最后：自动化测试的价值，不止是减少手工操作
从0到1学自动化测试，不是为了把手工测试全部替掉。
它真正的价值在于：
- 让核心回归更稳定；
- 让质量反馈更及时；
- 让研发交付更可控；
- 让测试从后置验证走向过程保障；
- 让测试工程师具备更强的工程能力。
结合这张“测试工程师质量体系能力全景图”来看，自动化测试只是起点，不是终点。
它向下连接基础测试能力，向上连接测试工程化、线上质量运营、质量治理和 AI 辅助测试。
所以学习路径可以简单概括为一句话：
先会测，再会写脚本；先能跑，再能稳定跑；先做自动化，再做质量体系。
真正有竞争力的测试工程师，不只是发现 Bug，而是能参与构建一套稳定、可持续、可度量的质量保障体系。
👇 如果你正在准备实习/校招，这里会对你有帮助
📌 扫码进群，获取【大厂机会 + 内推信息 + 求职指导】
从实习到秋招，持续同步真实招聘信息和面试经验
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
