测试开发学习路线（2026 最新版）：AI 时代如何从测试走向质量工程

你好，我是 Guide。这是面向测试开发方向的学习路线 2026 最新版。

后台经常有同学问：

Java 后端太卷了，能不能转测开？

测开是不是比开发简单一点？

AI 都能写测试用例了，测试岗位以后还值得学吗？

我的判断比较直接：测开可以作为一个不错的求职方向，但别把它理解成“后端学不动后的备选”。测试开发工程师（Software Development Engineer in Test，简称 SDET）确实在测试体系里更偏技术，但它要求你能把编程、测试理论、工程工具、业务理解和质量保障串起来。

如果只是会点手工测试、会点 Postman、会写几条 Selenium 脚本，在现在的环境里竞争力不太够。更好的方向是：能写自动化框架，能接 CI/CD，能看日志和监控定位问题，能做接口、UI、性能和稳定性验证，还能把 AI 用在用例生成、脚本维护、日志分析、缺陷归因和 AI 应用评测里。

这篇路线主要写给三类同学：

• 计算机相关专业，想准备测试开发、自动化测试、质量工程方向的同学。
• 已经在做功能测试，想补编程和自动化能力的同学。
• 有 Java / Python / 后端基础，想把求职方向扩展到测开的同学。

先提醒一句：如果你未来的长期目标是纯业务开发，测开经历未必总能无缝迁回开发岗。测开的项目成果更多体现为质量体系、自动化效率、问题定位和平台能力，和业务功能开发的叙事不完全一样。后续想回开发岗也可以，但简历和面试表达要提前设计好。

先理解测开到底在做什么

传统测试更关注“这个功能有没有问题”。测开还要往前多走几步：为什么这个问题会漏掉？以后能不能自动发现？这类问题能不能沉淀成工具、平台或流程？

在真实团队里，测开的工作可能包括这些：

• 参与需求评审，提前识别边界条件、异常流程和风险点。
• 设计测试用例，覆盖功能、接口、兼容性、安全、性能和稳定性。
• 编写接口自动化、UI 自动化、App 自动化脚本。
• 建设自动化测试框架，管理测试数据、测试环境和测试报告。
• 把自动化用例接入 Jenkins、GitHub Actions、GitLab CI 等流水线。
• 做性能压测，分析吞吐量、响应时间、错误率、CPU、内存、数据库和缓存指标。
• 开发测试平台，例如用例管理、自动化调度、报告聚合、覆盖率分析和精准测试。
• 测试 AI 应用，例如 RAG 问答、智能客服、Agent 工具调用、多模态应用。

所以，测开的代码主要落在测试框架、测试工具、质量平台和问题定位脚本上。代码量可能没有业务开发大，但对工程链路的理解要更完整。

AI 时代，测开要多学什么

AI 对测试的影响已经很明显了。

一方面，AI 可以帮你提高测试效率。比如根据需求文档生成测试点，帮你补边界用例，改写接口自动化脚本，分析失败日志，生成性能测试报告初稿。以前写 20 条用例要半小时，现在可以先让 AI 出第一版，再由你审查和补充。

另一方面，AI 应用本身也需要测试。传统系统通常是确定性的，接口返回字段错了就是错了；AI 应用更麻烦，同一个问题可能有不同回答，回答看起来流畅但事实不一定对，RAG 检索可能没召回正确材料，Agent 可能选错工具或编错参数。

这意味着测开需要补一块新的能力：评估不确定系统的质量。

你至少要知道这些问题怎么测：

• Prompt 是否容易被注入攻击绕过？
• RAG 是否召回了正确文档，回答有没有忠实于检索材料？
• 大模型输出的 JSON 是否稳定，字段缺失时系统怎么兜底？
• Agent 调用工具时，工具选择、参数生成、执行结果回填是否正确？
• 多轮对话里，上下文污染、历史记忆和权限边界有没有问题？
• 模型切换、Prompt 调整、Embedding 更新后，质量是变好了还是变差了？

AI 不能替代好的测试判断。它能帮你更快地产出候选用例和脚本，但最终要由你判断覆盖是否完整、断言是否有效、失败是否真的暴露了问题。

测开学习路线概览

如果你从零开始，可以按这条顺序走：

计算机基础 -> 编程语言 -> 数据库/Linux/Git/Docker -> 测试理论
-> 接口自动化 -> UI/App 自动化 -> 性能测试 -> CI/CD 与质量工程
-> AI 辅助测试 -> AI 应用测试 -> 项目和面试表达

不要一上来就学一堆工具。工具可以很快上手，但测开真正拉开差距的是三件事：

• 能不能写出可维护的测试代码，少写一次性脚本。
• 能不能把自动化接进工程流程，跑在 CI 和日常回归里。
• 能不能解释一次失败背后的原因，给出日志、数据和链路证据。

阶段一：补计算机基础

测开面试也会问计算机基础，尤其是校招、实习和大厂面试。

不用按考研 408 的深度全啃一遍，但下面这些内容要能讲清楚：

• 计算机网络：HTTP/HTTPS、TCP/UDP、三次握手和四次挥手、DNS、Cookie / Session / Token、常见状态码、浏览器输入 URL 后发生了什么。
• 操作系统：进程和线程、上下文切换、死锁、内存管理、I/O、Linux 文件权限和常用命令。
• 数据结构与算法：数组、链表、栈、队列、哈希表、树、堆、排序、二分、双指针、DFS / BFS、动态规划基础。
• 基本系统设计意识：缓存、限流、超时、重试、日志、监控、降级。

测开问计网时，经常会贴近排障场景。比如页面加载慢怎么查，接口偶发超时怎么定位，App 抓包看到 401 / 403 / 500 分别可能是什么原因。你不能只背概念，要能顺着请求链路说。

可以配合 JavaGuide 里的内容学习：

• 计算机网络常见面试题
• 操作系统常见面试题
• 进程和线程
• Linux 常用命令总结
• 数据结构与算法

算法不用刷到后端开发岗那么极限，但基本题要做。测试开发依然是技术岗，笔试和一面遇到算法题很正常。

阶段二：选一门主语言，再补一门辅助语言

测开绕不开编程。

语言选择不必纠结太久。Java 和 Python 都能做测开，只是侧重点不一样：

语言	更适合的场景	建议
Java	已经有 Java 基础、目标公司技术栈偏 Java、想做测试平台或后端质量工具	直接用 Java 投测开也可以，重点补 JUnit、TestNG、Rest Assured、Spring Boot
Python	想快速写脚本、接口自动化、数据处理、日志分析、AI 工具链调用	很适合测开入门，重点补 pytest、requests、Playwright、Locust
Java + Python	想覆盖更广的岗位和项目	Java 做平台和工程底座，Python 做自动化脚本和 AI 辅助工具

如果你本来就是 Java 后端，不要为了测开把 Java 扔掉重新学 Python。Java 的 Spring Boot、MySQL、Redis、接口设计、单元测试、日志排查经验都能迁移到测开，简历里也更好讲。

如果你没有明显语言基础，短期准备测开可以先学 Python。它写接口自动化、数据处理、批量脚本和 AI API 调用更轻。

这一阶段至少要做到：

• 能写基本程序，理解函数、类、异常、集合、文件读写和网络请求。
• 能用测试框架写单元测试，例如 Java 的 JUnit / Mockito，Python 的 pytest。
• 能封装 HTTP 请求，处理 Token、Header、Cookie、参数化和断言。
• 能读懂项目目录结构，知道代码、配置、测试、日志分别放在哪里。
• 能写一点简单服务，例如 Spring Boot 或 Flask / FastAPI，用来练接口测试。

Java 相关内容可以看：

• Java 基础常见面试题
• Java 集合常见面试题
• Java 单元测试

阶段三：补数据库、Linux、Git、Docker 和 CI/CD

测开的工作不只发生在浏览器页面上。很多问题最后都要落到数据、环境、日志和发布流程上。

数据库这块，MySQL 是重点。你至少要会：

• 写常见 SQL：查询、过滤、排序、分页、聚合、关联查询。
• 看懂表结构，知道主键、唯一索引、普通索引、外键的影响。
• 理解事务、隔离级别、脏读、不可重复读、幻读。
• 用 SQL 构造测试数据，验证接口返回和数据库状态是否一致。
• 能解释慢 SQL、索引失效、连接数耗尽这类常见问题。

Linux 主要用于部署、日志查看和排障。常用命令要熟：cd、ls、cat、tail、grep、awk、sed、ps、top、df、du、curl、netstat / ss。

Git 要会分支、提交、合并、解决冲突、回滚和查看提交历史。Docker 要会拉镜像、写简单 Dockerfile、启动容器、挂载配置、查看日志。CI/CD 至少要知道流水线怎么触发、怎么执行测试、怎么生成报告、失败时怎么定位。

推荐配套阅读：

• MySQL 常见面试题
• Git 入门教程
• Docker 入门教程

这一阶段的练习可以很具体：自己写一个小服务，用 Docker 启动 MySQL 和后端服务，再用 GitHub Actions 或 Jenkins 跑一组接口自动化测试。哪怕功能很小，只要链路完整，就比只学工具强很多。

阶段四：测试理论和用例设计

测试理论不该停在背名词。它解决的是一个具体问题：面对一个功能，你怎么判断自己测得够不够？

基础内容包括：

• 测试流程：需求分析、测试计划、用例设计、执行、缺陷跟踪、回归、上线验证、复盘。
• 测试分类：单元测试、集成测试、系统测试、验收测试、回归测试、冒烟测试。
• 测试类型：功能、接口、性能、安全、兼容性、易用性、稳定性。
• 用例设计方法：等价类、边界值、判定表、因果图、状态迁移、正交实验、错误推测。
• 缺陷管理：缺陷标题、复现步骤、实际结果、期望结果、环境信息、日志和截图。

面试里很常见的场景题，比如测试电梯、水杯、登录页、购物车、微信朋友圈、红包、文件上传。回答时别只按功能点罗列，可以按维度展开：

• 功能流程：正常路径和异常路径。
• 数据边界：空值、超长、特殊字符、重复、非法格式。
• 权限和安全：未登录、越权、敏感信息、频率限制。
• 兼容性：浏览器、系统版本、网络状态、屏幕尺寸。
• 性能和稳定性：高并发、弱网、重复提交、长时间运行。
• 可观测性：日志、埋点、告警、错误码是否可定位。

AI 可以帮你生成初稿，但你要会审。比如让 AI 生成登录页测试点，它可能会覆盖账号密码、验证码、记住登录这些常规点，但经常漏掉风控、频率限制、账号锁定、第三方登录、Token 续期、并发登录和审计日志。

测开要能补上这些漏掉的地方。

阶段五：接口测试和接口自动化

接口自动化是测开最应该优先拿下的一块。

原因很简单：接口比 UI 更稳定，执行速度更快，也更容易接入 CI。很多团队的自动化测试主力都是接口回归。

先从工具开始。Postman、Apifox、Reqable、Insomnia 这类工具至少会一个，能完成接口调试、环境变量、前置脚本、后置断言和测试集合执行。

然后写代码。Python 可以用 requests + pytest，Java 可以用 JUnit / TestNG + Rest Assured。一个像样的接口自动化框架，至少要包含：

• 环境配置：测试环境、预发环境、接口域名、账号和 Token。
• 请求封装：统一处理 Header、Cookie、鉴权、超时、重试。
• 数据管理：测试数据准备、清理、参数化、数据库校验。
• 断言体系：状态码、响应字段、业务码、数据库状态、消息队列副作用。
• 报告输出：Allure、HTML 报告、失败日志、请求和响应详情。
• CI 集成：每次提交或每天定时执行，失败后能定位到具体用例。

不要只断言 status_code == 200。接口测试真正有价值的断言，应该能证明业务状态正确。例如创建订单接口执行后，要验证订单表、库存变化、支付状态、消息事件或审计日志。

AI 在这一阶段很适合做三件事：

• 根据 OpenAPI / Swagger 文档生成初版测试用例。
• 根据接口返回生成数据模型和断言模板。
• 帮你审查用例是否只测了成功路径。

但测试数据、业务断言和环境清理要自己把关。AI 不知道你们系统里哪些字段会影响后续流程。

阶段六：UI 自动化和 App 自动化

UI 自动化能做，但不要一上来就把所有回归都押在 UI 上。

UI 自动化的成本比接口自动化高。页面结构会变，元素定位会失效，网络和渲染会带来不稳定，维护不好很容易变成“每天都有人修脚本”。所以 UI 自动化更适合覆盖高价值、稳定、跨页面的主流程，比如登录、下单、支付、审批、发布。

Web UI 自动化可以重点看：

• Playwright：现代 Web 自动化工具，等待机制、调试体验、并行执行和多浏览器支持都比较好。
• Selenium：历史更久，企业存量项目多，面试也常问原理。
• Cypress：前端团队用得多，适合 Web 应用端到端测试。

如果从 2026 年开始新学，我更建议优先学 Playwright，再了解 Selenium。Selenium 的生态和面试价值仍然在，但新项目的稳定性和开发体验，Playwright 往往更舒服。

App 自动化主要看 Appium。你要理解设备连接、元素定位、等待、滑动、权限弹窗、日志抓取、弱网和多机型兼容。

UI / App 自动化要重点掌握：

• Page Object Model，别把元素定位和业务步骤全部写在一个文件里。
• 稳定等待，少用固定 sleep。
• 截图、视频、Trace 和失败日志留存。
• 测试数据隔离，避免用例互相污染。
• 并行执行和失败重试，但重试不能掩盖真实问题。

AI 可以帮你从页面结构生成初版脚本，也可以根据失败截图猜测定位问题。但 UI 自动化的稳定性来自工程设计，脚本生成速度只是开始。

阶段七：性能测试和稳定性测试

性能测试不能只停在打开 JMeter 压一下，然后贴一张 QPS 图。

你要先明确测试目标：验证单接口容量、核心链路容量、峰值流量、稳定性、限流降级，还是找瓶颈。目标不同，压测模型也不同。

常见工具：

• JMeter：企业里很常见，适合接口和 Web 服务压测。
• k6：脚本化体验更现代，适合开发者协作。
• Locust：Python 编写场景，适合复杂用户行为建模。
• Gatling：性能不错，Scala 技术栈里更常见。

需要关注的指标：

• 吞吐量：QPS、TPS。
• 响应时间：平均值、P95、P99。
• 错误率：HTTP 错误、业务错误、超时。
• 资源指标：CPU、内存、磁盘 I/O、网络 I/O、线程数、连接数。
• 依赖指标：数据库慢 SQL、连接池、Redis 命中率、消息队列堆积。

性能测试报告要能回答几个问题：

• 这次压测的业务场景是什么？
• 并发用户、请求比例、数据规模和持续时间是多少？
• 瓶颈出在哪里，证据是什么？
• 优化前后指标变化如何？
• 当前结论的边界是什么？

没有监控的压测价值很低。至少要能看到服务日志、系统资源、数据库指标和错误堆栈。遇到响应慢，先判断是应用线程耗尽、数据库慢、外部接口慢、GC、网络，还是压测脚本本身有问题。

阶段八：CI/CD、质量平台和精准测试

测开进阶的分水岭，通常在脚本之外：能不能把质量能力沉淀进团队流程。

第一步是 CI/CD。把接口自动化、单元测试、静态检查、UI 冒烟、测试报告接进流水线。每次合并代码后自动跑一批关键用例，失败时能看到日志、截图、请求响应和负责模块。

第二步是测试平台。一个简单的平台也可以很有价值，比如：

• 用例管理：维护接口、场景、优先级、标签、执行状态。
• 自动化调度：按项目、分支、环境、标签触发测试。
• 报告聚合：展示通过率、失败原因、历史趋势。
• 测试数据管理：准备账号、订单、库存、审批流等数据。
• 缺陷联动：失败用例自动关联缺陷或通知负责人。

第三步是覆盖率和精准测试。Java 可以看 JaCoCo，Python 可以看 Coverage.py。它们能告诉你自动化用例覆盖了哪些代码行、分支和方法。更进一步，可以结合代码变更范围、调用链和历史失败记录，优先执行更可能发现问题的用例。

精准测试对校招生不一定是硬要求，但它很适合作为进阶项目。相比“我写了一个接口自动化框架”，能说清“我根据代码覆盖率和变更文件筛选回归用例”，技术含量会高不少。

阶段九：AI 辅助测试怎么用

AI 辅助测试不要停留在“帮我写测试用例”。

更实用的用法是把任务拆细，让 AI 做候选生成和辅助审查：

请根据下面的需求说明，输出测试点。
要求：
1. 按功能、接口、权限、安全、兼容性、性能、异常场景分类；
2. 每个测试点写出前置条件、操作步骤、预期结果；
3. 单独列出你不确定、需要产品确认的点；
4. 不要编造需求里没有出现的业务规则。

接口自动化可以这样用：

请根据这份 OpenAPI 文档生成 pytest 接口测试用例初稿。
要求：
1. 区分正常路径和异常路径；
2. 每个用例都要有明确断言；
3. 不要只断言 HTTP 200；
4. 标出需要人工补充测试数据的地方。

失败日志分析可以这样用：

请分析下面这次 CI 失败日志。
要求：
1. 先判断失败发生在环境、测试数据、断言、接口还是业务代码；
2. 给出最可能的 3 个原因；
3. 给出下一步排查命令或需要查看的日志；
4. 不要直接下结论，缺证据的地方标注“不确定”。

这类 Prompt 的价值在于让 AI 把候选空间列出来。真正的判断仍然来自日志、数据、代码和业务规则。

更进一步，可以用 AI 做质量审查。比如让它检查自动化框架里有没有硬编码环境、用例是否互相依赖、断言是否太弱、失败重试是否掩盖问题。这个方向和 AI 编程实践指南 里的 Spec Coding、代码审查和本地验证思路是相通的。

阶段十：AI 应用测试和大模型评测

如果你想让测开路线更符合 AI 时代要求，这一块一定要补。

AI 应用测试可以先分成四类：

方向	重点测试内容	示例
LLM API 应用	结构化输出、超时重试、限流、降级、成本、审计	简历解析、客服问答、文本分类
RAG 应用	文档解析、分块、召回、Rerank、答案忠实度、引用溯源	企业知识库、制度问答
Agent 应用	工具选择、参数生成、执行轨迹、权限边界、失败恢复	自动查订单、自动生成报告
多模态应用	图片/音频输入、识别准确性、异常文件、安全边界	图片审核、票据识别

这里不能只用传统“输入等于输出”的思路。AI 应用的输出经常有多个可接受答案，评测要更像一套质量回归体系。

你可以先从这些概念入手：

• Golden Set：准备一批高质量测试集，覆盖正常问题、边界问题、对抗问题和高风险业务问题。
• 检索评测：看正确文档有没有被召回，TopK 里位置是否靠前。
• 生成评测：看回答是否正确、是否忠实于材料、是否引用证据。
• 工具调用评测：看 Agent 有没有选对工具、参数是否准确、失败后有没有恢复。
• 安全评测：提示词注入、越狱、敏感信息泄露、越权访问。

工具上可以了解 DeepEval、RAGAS、promptfoo 这类评测框架，也可以先自己写一个轻量脚本：读取测试集，批量调用应用接口，保存问题、答案、引用、耗时、Token 成本和人工打分。

JavaGuide 里和这块相关的内容可以看：

• 大模型 API 调用工程实践
• 大模型结构化输出详解
• AI 应用评测体系
• RAG 基础概念
• 大模型提示词工程实践指南

这一阶段的目标不在模型算法。测开更应该关注工程质量：模型输出怎么验，质量下降怎么发现，线上问题怎么回放，发布前怎么证明这次改动没有让效果变差。

项目应该怎么做

测开简历最怕项目太虚。只写“熟悉自动化测试”“会使用 JMeter”“了解 AI 测试”，面试官很难判断你的真实能力。

更好的方式是做 2 到 3 个能跑起来、能讲清楚的项目。

项目一：接口自动化测试框架

选一个真实或半真实系统，比如电商、博客、在线教育、后台管理。至少覆盖登录、用户、商品、订单、支付回调这类接口。

项目要包含：

• 接口文档解析和测试用例设计。
• 请求封装、鉴权、参数化、数据准备和清理。
• 数据库校验，不能只看接口返回。
• Allure / HTML 测试报告。
• GitHub Actions / Jenkins 自动执行。
• 失败日志、请求响应和环境信息留存。

面试时可以讲：你如何设计目录结构，如何处理 Token，如何管理测试数据，如何避免用例互相依赖，如何接入流水线。

项目二：Web UI 自动化或 App 自动化

Web 方向建议用 Playwright 或 Selenium，App 方向可以用 Appium。

不要做太多页面，先把主流程做扎实。例如后台管理系统的登录、用户管理、角色权限、文章发布、订单处理。

项目要包含：

• Page Object Model。
• 多环境配置。
• 截图、Trace、失败视频或日志。
• 用例标签，例如冒烟、回归、核心流程。
• 并行执行和失败重试策略。
• CI 定时执行和报告归档。

面试时重点讲稳定性：元素定位怎么选，等待怎么处理，页面变化后怎么维护，失败怎么判断是脚本问题还是业务问题。

项目三：性能测试和问题定位

选一个接口链路，例如商品查询、下单、登录、搜索。

项目要包含：

• 压测场景设计：单接口、混合场景、峰值场景、稳定性场景。
• JMeter、k6 或 Locust 脚本。
• 监控指标采集：CPU、内存、数据库、Redis、应用日志。
• 性能报告：QPS、P95、P99、错误率和瓶颈分析。
• 至少一次优化前后对比，例如增加索引、调整连接池、减少慢 SQL。

这个项目很适合证明你会定位问题，工具执行只是其中一环。

项目四：AI 应用质量评测平台

如果想突出 AI 时代的测开能力，可以做一个轻量评测平台。

比如做一个 RAG 问答系统评测工具：

• 支持导入 Golden Set：问题、标准答案、期望引用文档。
• 批量调用 RAG 接口，记录答案、引用片段、耗时和 Token 成本。
• 计算召回命中、答案是否包含关键事实、是否引用正确材料。
• 支持人工打分和失败样本标记。
• 输出对比报告：模型 A 和模型 B、Prompt v1 和 Prompt v2、不同 TopK 配置的效果差异。

这个项目不用做得很大。关键是能体现你理解 AI 应用的质量评估方式，而不只是会让模型回答问题。

面试时怎么讲测开能力

测开面试不要把自己讲成“会很多工具的人”。工具只是入口，面试官真正想知道的是你能不能保障质量。

简历和面试表达可以按这条线组织：

• 我负责过什么系统或模块的质量保障。
• 我如何分析需求并设计测试点。
• 我做了哪些自动化能力，覆盖了哪些接口或流程。
• 自动化怎么接入 CI/CD，失败后如何通知和定位。
• 我发现过什么问题，怎么定位，最后怎么修复或推动修复。
• 我做过哪些效率提升，例如报告聚合、测试数据构造、覆盖率统计、用例筛选。
• 我如何使用 AI 辅助测试，但如何保证 AI 输出被人工和自动化校验。

如果你是后端转测开，可以强调这些优势：

• 更懂接口设计和后端实现，能从代码和日志定位问题。
• 更懂数据库、缓存、消息队列和分布式链路，能测到功能表面以外的风险。
• 能开发测试工具或平台，工作不止于执行用例。

如果你是功能测试转测开，可以强调这些优势：

• 更懂业务流程和测试思维。
• 更知道哪些场景容易漏测。
• 自动化要承接已有人工经验，把高频、稳定、可重复的部分沉淀成脚本和平台。

常见面试题可以按这些方向准备：

• 如何设计登录、购物车、电梯、水杯、文件上传的测试用例？
• 接口自动化框架怎么设计？
• pytest 和 unittest 有什么区别？JUnit 和 Mockito 怎么配合？
• Selenium、Playwright、Cypress 的区别是什么？
• UI 自动化不稳定怎么办？
• JMeter 压测报告怎么看？P95 和 P99 分别代表什么？
• 接口偶发超时怎么排查？
• 线上 bug 漏测了，如何复盘？
• AI 生成的测试用例怎么验证质量？
• 如何测试一个 RAG 问答系统或 Agent 工具调用系统？

一份 3 到 6 个月的学习节奏

如果你每天能稳定学习 2 到 4 小时，可以按这个节奏推进。

第 1 个月，补基础。完成一门语言入门，能写脚本和单测；同时补 HTTP、Linux、MySQL、Git。这个月的目标是写得出代码，看得懂日志，能调接口。

第 2 个月，拿下测试理论和接口自动化。系统练用例设计，完成一个接口自动化框架，接入测试报告和 CI。这个月结束时，简历里应该有一个能讲清楚的接口自动化项目。

第 3 个月，做 UI 自动化和性能测试。Web 方向优先 Playwright，性能方向选 JMeter 或 Locust。不要贪多，把登录、下单、查询这类主流程做稳定，再做一次完整压测报告。

第 4 个月，补质量工程。学习 Jenkins / GitHub Actions、Docker、覆盖率、测试平台思路。把前面两个项目接进流水线，自动生成报告，失败时能定位。

第 5 个月，补 AI 辅助测试和 AI 应用测试。用 AI 生成用例、审查测试代码、分析日志；再做一个小型 RAG 或 Agent 评测项目，理解 Golden Set、召回、答案忠实度和工具调用评测。

第 6 个月，集中准备简历和面试。把项目改成面试能讲的版本：背景、方案、技术选型、难点、结果、风险、复盘。刷高频测试场景题、算法基础题和项目追问。

时间不够的话，优先级是：编程语言、接口自动化、测试理论、Linux / MySQL / Git、一个完整项目。UI 自动化、性能测试、AI 评测和测试平台可以按目标岗位要求补。

最后给几个判断

测开不适合只想轻松上岸的人。它比传统功能测试更技术化，比纯业务开发更强调质量视角。你既要会写代码，也要愿意反复琢磨边界、异常、失败和风险。

AI 会让低质量重复劳动变少，但不会让质量保障消失。需求理解、用例设计、断言选择、风险判断、问题定位、评测体系，这些仍然需要人来负责。

如果你准备走测开路线，建议尽早把学习成果落成项目。别只收藏路线图，也别只刷工具教程。一个接口自动化框架、一个 UI 自动化主流程、一次压测报告、一个 AI 应用评测小项目，比“熟悉一堆工具”更有说服力。

先把一条链路跑通：从需求到用例，从接口到断言，从脚本到 CI，从失败到定位。测开的竞争力，就是在这一条链路里一点点长出来的。

参考资料

• 测试开发工程师的学习路线与学习资源个人总结
• 黑马程序员 AI 测试学习路线图（2026 官方完整版）
• 测试、测开完整学习路线（纯干货）