01 认识测试开发

狂师2026/8/25...大约 9 分钟

01 认识测试开发

在投入几个月学习时间之前，先想清楚：测试开发到底在做什么，AI 时代它变成了什么样。

为什么重要

后台经常有同学问：

功能测试太卷了，往测试开发方向转还来得及吗？测开是不是比开发简单一点？ AI 都能直接写测试脚本了，测试岗位以后还值得学吗？

先摆正一个定位：测开不是跳出测试行业的去处，它就是测试行业里的技术进阶方向。测试开发工程师（Software Development Engineer in Test，简称 SDET）在测试体系里更偏技术，它要求你能把编程、测试理论、工程工具、业务理解和质量保障串起来。

这是个不错的求职方向，但别把它理解成「开发学不动后的备选」。

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

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

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

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

测开到底在做什么

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

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

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

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

测开的能力分层

同样是「测试开发」，不同阶段的能力要求差异很大。可以用这个四层模型给自己定位：

层级	核心能力	典型产出	常见岗位对应
L1 工具使用者	会用 Postman、JMeter、抓包工具，按用例手工执行、记录结果、描述可复现的缺陷	手工用例、缺陷单、测试报告	初级测试
L2 脚本编写者	用一门语言独立写接口 / UI 自动化脚本，会数据准备和断言设计，脚本失败能自己排查	稳定可重复执行的自动化用例集	初级测开
L3 框架建设者	设计分层框架（封装、配置、报告、CI 集成），让自动化别人也能维护；能独立扛起性能、监控定位等专项	自动化框架、CI 流水线、测试平台模块、性能定位报告	中高级测开
L4 质量工程负责人	定义团队质量标准与度量体系，主导左移右移、精准测试和质量风险决策，把质量能力沉淀成平台	质量度量体系、质量策略、平台规划	测试专家 / 质量负责人

给自己定位时别数工具，看三把尺子——分别问三个问题：你产出什么？谁在用你的产出？你失手一次会波及多大范围？

产出形态：执行记录 → 脚本 → 框架与平台 → 标准与体系。
服务对象：自己够用 → 小组复用 → 团队依赖 → 影响组织决策。
失败代价：漏一个 bug 上线 → 一个模块漏出一波 bug → 误报泛滥、团队整套自动化停用 → 质量误判，影响一次发布决策。

其中 L2 到 L3 是最关键的一跳：从「写能跑的脚本」跨到「设计别人能维护的工程」。很多人卡在这一步——脚本越写越多，但没有分层、封装和 CI 接入，就还不算跨过去。

这条路线的目标，是把你从 L1 带到 L2-L3。L4 需要实际业务场景的多年沉淀，但认知可以提前建立。

岗位名称的现实情况：现在很多公司（尤其是大厂）已经不再单独区分「业务测试」和「测试开发」岗级，招聘统一叫「测试工程师」。入职后日常仍以业务测试为主，但要具备测开能力——写自动化、接 CI、用工具提效，这已经是基本要求。所以不必纠结目标公司有没有单独的「测试开发」岗位：能力分层比岗位名称重要。能力到了 L2-L3，不管 title 叫什么，你做的都是测开的事，求职叙事也按这个讲。

和相邻岗位的区别

和功能测试：功能测试以「发现缺陷」为核心动作；测开以「让发现问题这件事可复制、可规模化」为核心动作。测开也做功能测试，但更多时间花在自动化、工具和流程上。
和业务开发：开发对功能交付负责，测开对质量风险负责。测开写的代码是「验证代码」——验证别人的代码是否正确，所以对稳定性和可维护性的要求一点不低。
和测试经理：测试经理偏人和流程管理，测开偏技术建设。两者可以互相转化。

AI 时代，测开要多学什么

AI 对测试的影响已经很明显了，而且是两个方向同时发生。

方向一：AI 成为测开的效率工具。

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

方向二：AI 应用本身成为被测对象。

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

这意味着测开需要补一块新的能力：评估不确定系统的质量。你至少要知道这些问题怎么测：

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

这一部分展开在第 11 章。

AI 不能替代好的测试判断。它能帮你更快地产出候选用例和脚本，但最终要由你判断覆盖是否完整、断言是否有效、失败是否真的暴露了问题。AI 时代的测开，不是和 AI 比谁写用例快，而是成为那个定义「什么算质量」、并验证 AI 产出质量的人。

学习建议与常见误区

误区一：把测开当上岸捷径。 因为「开发太卷所以去测开」的人，往往撑不过阶段二和阶段五的编程关。测开是技术岗，编程绕不开。
误区二：收集工具等于会测开。 简历上写十个工具名，不如一个能跑起来、接了 CI、有完整报告的自动化项目。
误区三：AI 时代学测试没有前途。 恰恰相反，AI 应用越普及，「验证不确定系统质量」的人才缺口越大。焦虑的正确出口是把它列进学习计划，而不是放弃。
建议：先建立全景认知再开学。 花半天把这条路线的 13 章标题都看一遍，知道自己要去哪里，学习时的每一步才有方向感。

自查清单

读完这一章，你应该能回答：

测开和功能测试的核心区别是什么？（提示：可复制、可规模化）
测开写的代码通常落在哪四类载体上？
你现在处于能力四层模型的哪一层？目标是什么？
AI 对测试的两个方向的影响分别是什么？各举一个例子。
「评估不确定系统的质量」为什么不能只用「输入等于输出」的思路？