每年到了跳槽季，我这边都会收到不少测试朋友的私信，内容集中在几类：要么是“帮我看下这份测试题怎么答”，要么是“面试挂在了基础题上，复盘下来还是八股没背熟”。今年尤其多，有个做功能测试的朋友去面中厂，前面项目聊得挺好，结果被一道等价类划分的设计题问住，出来以后跟我说：测试这行，八股文真的不能不当回事。
我理解他说的“八股文”不是贬义，而是行业里对高频基础面试题的俗称。软件测试岗位的面试，看起来不如后端、算法那样硬核，但实际上考察维度很杂：理论基础、工具掌握、项目经验、代码能力、沟通表达，甚至还要看你对业务的理解程度。很多题确实有“标准答案”或固定的答题框架，不准备是真的吃亏。这篇文章我按照自己的经验，把这些年面试别人和被别人面试时反复出现的高频考点整理成一份超详细清单，每个知识点都附上回答思路和避坑提醒，适合准备跳槽的测试老手，也适合刚入行、准备找第一份测试实习的新人。
1. 面试之前：软件测试八股文到底在考什么
1.1 什么是测试八股文，为什么它绕不开
“八股文”这个词在程序员圈子里流传已久，意思是指那些有固定题型、固定答案模板的面试题。软件测试领域的八股文，通常会覆盖计算机基础、软件测试理论、测试工具、数据库、Linux命令、接口测试、自动化测试、性能测试等几大板块。
我见过不少测试新人有个误区，觉得做测试就是“点点点”，面试根本不需要准备。实际上恰恰相反，测试岗位的面试题数量大、范围广，而且由于门槛相对不高，竞争非常激烈。同样一个岗位，候选人的基础扎实不扎实，通过几道基础题就能拉开差距。你背过和没背过的区别，在面试官眼里非常明显——没背过的人往往答得支离破碎，只能说出几个名词，背过的人能把概念、作用、使用场景串起来讲。
1.2 面试官真正想从八股文里看到什么
理解了这一点，你就会明白面试官问八股文不是在为难你，而是在快速做筛选。从我的经验看，面试官问基础题通常想确认三件事。
第一，你的知识体系是否完整。测试入门容易，但很多人干了几年还是只会按测试用例点点点，对测试理论、缺陷流转、接口交互、数据库原理缺乏系统认知。通过问你“等价类怎么划分”“bug的生命周期是什么”，面试官能快速判断你是有体系地工作，还是凭感觉在混。
第二，你的表达是否清晰。技术基础题都有相对标准的答案，能清楚、准确地表达出来，说明你有基本的沟通能力。测试岗位特别需要和开发、产品、项目经理沟通，表达混乱的人在团队里会非常消耗协作效率。
第三，你有没有持续学习。如果你的简历上写了熟练使用Postman，但面试时连接口测试要测哪些点都说不全，面试官几乎马上就能得出结论——你简历注水了，平时没有真正钻研过技术。
1.3 不同测试岗位对八股的要求差异
软件测试并不是一个单一岗位，功能测试、测试开发、自动化测试、性能测试、安全测试，每一种岗位对八股的要求侧重点都不一样。
- 纯功能测试岗位：更看重测试理论、用例设计、缺陷管理、业务理解，代码要求偏低。
- 测试开发岗位：必须会写代码，Python或Java至少熟练掌握一种，会问自动化框架原理、持续集成、测试平台建设。
- 性能测试岗位：必须懂并发模型、性能指标、压测工具和瓶颈分析方法。
- 安全测试岗位：可能会涉及渗透测试、OWASP Top 10、认证授权和常见漏洞原理。
面试前一定要仔细看清楚岗位JD，有针对性地准备。如果你是面测试开发，结果花了80%的时间背等价类、边界值，代码题却一问三不知，那基本上就凉了。
2. 最容易被问烂的测试理论，答得比别人深一点
2.1 测试用例设计：别只会说“等价类、边界值”
测试用例设计是面试中出场率最高的考区。几乎每个测试面试者都会被问到“你平时怎么设计测试用例”，如果你只回答“等价类、边界值、场景法”，那只能拿基础分。面试官通常追问下去：具体拿一个功能来试试。
我面试别人的时候，最喜欢拿“登录功能”和“手机号输入框”来考。比如手机号输入框该怎么设计用例，这时候不能只说正常输入。你需要把等价类划分具体化：合法手机号是一个有效等价类，空值、非数字、长度不足、长度超标、包含特殊字符、包含空格、重复号码等，各自是不同无效等价类。边界值要关注11位长度的边界，同时还要考虑校验层级的差异：前端提示、后端校验、数据库字段长度限制。
实操设计思路可以按这个顺序展开：
- 先找输入域，明确这个框接受什么格式的数据。
- 划分有效等价类和无效等价类，每一类至少设计一条正向用例和一条反向用例。
- 在边界值上做文章，尤其是最小值、最大值、刚刚超过最大值的场景。
- 补充业务规则，比如验证码是否过期、当天是否超限、账号是否被拉黑。
这样答，面试官会觉得你真的设计过用例，而不是只会背名词。
2.2 缺陷的生命周期：从提交到关闭的完整闭环
关于缺陷（bug），面试官最爱问的几个方向是：bug的定义、bug的生命周期、严重程度和优先级的区别、以及如何高效提交一个bug。
bug的生命周期需要把状态流转说清楚。通常包含：新建、指派、确认、修复、验证、关闭。如果验证不通过，会重新打开；如果开发认为不是bug，会有拒绝或延后处理的状态。这里有个容易扣分的细节，就是面试官特别关注“开发不承认这是bug时你怎么处理”的场景。建议回答思路是：先自己复述一下预期的行为与实际的行为，从文档和需求中找依据；如果文档描述含糊，再拉产品经理一起确认；最后若确实是缺陷，把影响范围描述清楚再和开发沟通。
严重程度和优先级是两个容易混淆的概念。严重程度是缺陷本身对系统的影响程度，优先级是修复的先后次序。高严重程度的bug可能优先级低，比如只有特定版本、特定机型才触发的崩溃；低严重程度的bug也可能优先级高，比如官网首页的错别字，严重程度不高，但影响品牌形象，必须尽快改。能把这个关系讲清楚，面试官会觉得你对缺陷管理有真正的理解。
2.3 软件研发流程与测试介入时机
这一块面试官通常围绕流程和管理模型来提问。经典的V模型、W模型、敏捷开发流程，你需要了解它们在测试视角下分别意味着什么。
V模型强调开发和测试的对应关系：需求分析对应验收测试、概要设计对应系统测试、详细设计对应集成测试、编码对应单元测试。W模型也叫双V模型，强调测试活动与开发活动同步开展，测试对象不只是代码，还包括需求、设计文档。敏捷开发模型则更加强调测试左移，测试人员从需求评审阶段就参与进去，把质量保障前移，而不是等开发交付后再去测。
我在之前公司带过项目，敏捷迭代周期只有两周，测试真正执行的时间往往只有三到四天。没有提前参与需求评审、没有提前写用例，根本无法按时上线。所以当面试官问你“在敏捷流程中，测试人员应该怎么做”时，你至少要说到：尽早介入需求评审、明确验收标准、用例设计前置、在测试执行中区分优先级、自动化回归保障核心流程。
2.4 必问经典题：测试时间不够怎么办
这道题是面试官用来考察候选人风险识别和沟通能力的。切忌不要回答“加班测完”，也不要回答“那我就简简单单测一下”。一个比较稳妥的回答框架是：
- 先按用例优先级做排序，核心功能和影响用户主流程的用例优先执行。
- 把风险暴露给产品经理和项目经理，而不是自己扛着。
- 区分必须人工测试的点和可以用自动化回归的点，释放时间给高优先级场景。
- 最后在测试报告中明确标注风险范围，说明哪些模块测试不充分，建议灰度发布或下个迭代补测。
这个回答既体现了你有优先级意识，还体现你有沟通协调能力，比硬着头皮说“通宵测”高级得多。
3. 接口测试、自动化测试和性能测试的常考点
3.1 接口测试到底测什么，才显得你真的懂
现在纯界面的功能测试岗位越来越少了，接口测试基本是测试岗位的标配技能。面试官问接口测试，本质上是要考察你懂不懂HTTP协议、懂不懂前后端交互。
接口测试的常规验证点包括：协议是否正确、请求头参数是否传全、参数类型是否校验、必填项缺失时是否有明确报错、业务返回码是否符合规范、异常输入时后端是否直接抛异常、数据库字段是否和接口返回一致。如果你有实战经验，还应该说到幂等性测试：比如支付接口同样的请求重复提交，必须只处理一次。
我建议面试前自己动手搭一个简单的接口测试脚本。我之前用过Python的requests库写过，核心流程就是读测试数据、发起请求、校验响应体、校验数据库、最后生成报告。你把过程讲清楚，面试官很容易判断出你是真做过还是只看了教程。
3.2 自动化测试的价值和适用场景
自动化测试几乎是每家公司在招聘测试岗位时都会提到的关键词，但真正理解它的人其实不多。面试官如果问“你们项目怎么落地自动化”，你千万不要一上来就说“我们用Selenium写用例”，这样太浅了。
一个比较完整的回答思路是三层：第一，先说明自动化测试的目的不是替代手工，而是提高回归效率，释放人力去做探索性测试；第二，需要根据项目阶段来选择，项目前期需求变动频繁时不适合大规模自动化，功能稳定后逐步投入才有性价比；第三，自动化测试要分层，UI自动化适合覆盖用户主流程，接口自动化适合覆盖业务规则，单元测试适合覆盖代码逻辑，越往下层越稳定、维护成本越低。
如果面试官追问框架，至少要知道页面对象模式（PO模式）这个经典概念。PO模式把页面元素和操作封装成页面对象，测试用例里只写业务逻辑，页面改动时只改页面类。加上数据驱动、日志收集、失败截图、报告生成，基本上就是一个合格的企业级自动化方案。
3.3 性能测试的完整流程与核心指标
性能测试题出现频率没前几个高，但只要你简历写了“熟悉性能测试”，面试官就不可能放过你。常见的连环问是：性能测试的流程、核心指标、压测工具、如何定位瓶颈。
性能测试流程可以用这几步概括：分析需求、评估场景、设计模型、准备环境与数据、执行压测、监控资源、定位瓶颈、输出调优建议。这里有一个必须注意的要点：压测环境要尽量和生产环境保持一致，如果你用一台2核4G的服务器压测，结果完全没有参考价值，这是典型的“数据失真”。
指标方面，至少要知道响应时间、吞吐量（TPS/QPS）、并发用户数、错误率、资源利用率。别看这几个词简单，面试官会具体问：90线是什么？为什么要看90线而不是平均响应时间？因为平均响应时间容易被极端值拉高，90线表示90%的请求都低于该时间，更能反映大多数用户体验。
3.4 环境搭建和测试数据准备，最容易暴露经验短板
环境问题是测试日常工作中最头疼的部分之一。面试时如果被问“测试环境由谁维护”“测试数据怎么准备”，不要轻飘飘说“有专门的运维负责”，那等于告诉面试官你从没独立搞定过环境问题。
测试环境的搭建通常涉及应用部署、依赖服务、数据库初始化和配置管理。很多公司的测试环境其实是要测试自己搭的，尤其是接口测试和自动化测试跑在哪个环境，各个环境用的数据库、Redis、MQ的地址是什么，这些你必须门儿清。测试数据的准备则要关注数据隔离：同一套测试环境多个测试同时使用，数据串了会导致用例失败，所以要么用独立账号、独立数据前缀，要么每次执行前做数据清理。
4. 面试常考的技术工具与代码题，掰开揉碎讲
4.1 抓包工具：Charles和Fiddler的高频考点
抓包工具是测试日常排查问题最常用的工具。面试官问“你现在碰到一个问题，线上接口报错，你会怎么排查”，大部分人会回答看日志，但更好的回答是抓包看请求和返回到底是什么。
Charles和Fiddler的使用要点其实都差不多。第一，能配置代理抓取HTTP和HTTPS流量，HTTPS需要安装证书，这个步骤要熟悉；第二，能断点修改请求和响应，这用来模拟各种异常场景特别方便，比如模拟超时、模拟500错误；第三，能过滤域名，自动保存响应，方便和开发对比数据。移动端测试还得会设置手机代理抓包。
4.2 数据库SQL：看起来送分，实际容易翻车
测试岗面试对数据库的要求不会像后端那么深，但SQL题几乎是必考的。最常考的是多表联查、分组统计、去重、排序，以及更新和删除操作。
我整理几个高频题目大家感受一下：
- 查询成绩大于80分的学生姓名及分数。
- 统计每个部门的人数，按人数降序排列。
- 查出每门课程的最高分和对应学生。
- 找出重复数据并删除，只保留一条。
看似简单，但现场写SQL很容易漏掉group by和having的区别，或者忘记where和having的执行顺序差别。扎实的写法应该是：先确定查哪几张表，再确定关联条件，最后考虑过滤条件应该放在where里面还是having里面。另外，你一定要知道索引的基本知识，比如为什么索引能加快查询、最左前缀原则是什么，以及哪些情况下索引会失效。
4.3 Linux命令：测试排查的必备技能
面试时Linux命令通常是问几个高频场景题，而不是让你背命令列表。常见的场景有：如何查看日志的最新内容、如何实时监控日志、如何查找某个进程、如何查看系统资源占用、如何查看端口占用情况。
我建议至少把这些命令掌握到脱口而出的程度：tail -f用于实时跟踪日志，grep用于过滤关键字，ps aux | grep或pgrep用于查进程，netstat -tlnp或ss -lntp用于查端口，top和free用于看CPU与内存，df -h看磁盘。你能在面试中说清楚“之前线上排查问题时，用tail -f app.log实时追踪报错，再用grep把异常堆栈提取出来，最后结合top看是不是资源耗尽”，这比单独背命令效果强得多。
4.4 编程语言：测试开发绕不开的代码考点
功能测试岗位对代码的要求不高，但如果你面的是测试开发或自动化测试岗位，面试官一定会考代码。语言方面无非两种：Python或Java。
Python方向的常考点包括列表推导式、字典操作、装饰器、生成器、多线程和多进程的基本概念，以及怎么用requests库、unittest或pytest框架写自动化脚本。Java方向的常考点包括集合框架的差异（比如ArrayList和LinkedList的区别）、HashMap原理、线程安全、反射、Spring基础注解等。
面试前建议把常见算法题也刷一下，不用刷很多，但字符串处理、列表去重、排序、二分查找这几个高频类型要能写出来。不用追求最优解，但至少思路清晰，能写出能运行的代码。毕竟，面试官要的不是你的算法竞赛水平，而是你是否有代码落地能力。
5. 项目经验怎么讲，才能不被追问到破防
5.1 用STAR法则把你的项目讲成一个完整故事
项目介绍是面试中的重头戏，很多人基础题答得不错，一到项目环节却讲得非常散。这时候面试官通常会打断你，然后追问几个细节，你就开始慌了。问题出在项目讲法没有结构。
我建议用STAR法则来组织你的项目表达，这是我在带团队时反复强调的方法：
- S（背景）：项目是什么，面向什么用户，解决了什么问题。
- T（任务）：你在项目中担任什么角色，负责哪部分测试工作。
- A（行动）：你具体做了哪些事情，用了什么工具方法，流程上有什么改进。
- R（结果）：取得了什么可度量的结果，比如缺陷率下降、回归时间缩短、线上漏测减少。
很多人自我介绍时总是说“我负责XX系统的功能测试，参与了需求评审，编写测试用例，执行测试并跟踪bug”，这就是典型的流水账。用STAR法则重构之后，哪怕项目很简单，也能讲出你的思考。
5.2 项目经验里最容易翻车的三个坑
第一个坑是项目含金量不够，但又不会包装。有的人简历上写“电商系统测试”，细问之下就是后台管理系统的几个CRUD接口，没有任何挑战性。包装不是让你造假，而是要把难点挖出来：数据正确性怎么保证？接口报错怎么排查？多环境怎么切换？你只要深入做过，任何事情都能挖出细节。
第二个坑是只讲职责，不讲产出。面试官听完你的项目介绍后，最想听到的是“因为你做了什么，所以带来了什么结果”。不要只说“我写了300条用例”，要说“通过场景法补充了异常链路用例，上线前拦截了N个原本会遗漏到线上的问题”。
第三个坑是项目细节经不起追问。一旦面试官问到具体某个功能的测试数据、某个bug的排查过程，你支支吾吾答不上来，基本就露馅了。所以面试前一定要把项目的细节再过一遍：业务流程、核心表单字段、异常场景、具体bug案例。
5.3 面试官高频追问及回答思路
项目环节常见的追问方向有：你负责的模块里最有挑战的问题是什么？印象最深的bug是什么？线上出现了漏测怎么处理？
印象最深的bug这道题，几乎每次面试都会被问到，建议提前准备一个真实案例，按照“现象—定位—修复—验证—复盘”五个环节来讲，并重点突出你如何通过抓包或日志定位到问题源头。比如我处理过一个数据串号问题：两个用户登录后看到对方的订单，最终排查发现是接口请求头里的token没有做用户隔离，后端同学在业务代码里取错了用户ID。这个问题的价值在于发现了测试用例里缺少账户隔离维度的检查，后来我在每个接口测试里都增加了“A用户操作不产生B用户数据”的校验点。
线上漏测题比较考验情商。切忌推卸责任说“是开发改了需求没告诉我”或者“是产品没说清楚”。推荐思路是：先说明漏测发生后的紧急处理流程，再复盘漏测原因，最后给出后续改进措施，比如补充测试用例、增加开发自测清单、在CI流程上加接口校验。
6. 不同测试方向的高频考点差异
6.1 银行/金融项目测试：严谨性第一
金融项目测试是软件测试领域薪资相对较高的方向，但要求也更严格。银行项目面试中，八股考点除了常规测试理论，还会重点考察业务合规和数据准确性。
你需要了解清结算、账务核算、风控规则等基础概念。金融系统测试特别关注金钱计算的精度问题，面试官可能会问“1.0 - 0.9 为什么不等于 0.1”，这其实是在考察浮点数精度和数据存储类型知识。金融系统的测试用例设计要覆盖幂等性、数据一致性、并发扣款等场景。另外，银行项目对文档规范度和测试过程记录要求很高，面试中如果你能体现严谨的记录习惯，会加很多分。
6.2 嵌入式软件测试：软硬结合是门槛
嵌入式测试的门槛比普通应用测试高，因为它还涉及硬件环境。面试官会考察你对交叉编译、串口调试、板级调试工具等概念的了解程度。
嵌入式测试的八股考点通常集中在：测试环境搭建（宿主机和开发板的关系）、资源受限场景下的测试策略（内存、CPU不足时系统的表现）、中断处理逻辑、实时性要求、看门狗机制等。还有一个高频题是“硬件的稳定性问题如何定位是软件还是硬件故障”，建议回答思路是先通过日志和数据分析软件执行的完整路径，再用替换法排除硬件因素。
6.3 游戏测试八股：玩得明白不如测得明白
游戏测试的热度在近两年涨了不少，热搜词里也出现了“游戏测试八股文”。游戏测试和传统软件测试最大的区别在于，除了功能、性能、兼容性以外，还有很多游戏特有的测试维度，比如数值测试、手感测试和游戏平衡性测试。
游戏测试面试中可能被问到的问题包括：如何看待奖金掉落概率的随机性问题、弱网环境下玩家的体验如何保证、游戏的兼容性测试要覆盖哪些设备和系统版本。这类问题没有绝对标准答案，更看重你是否理解玩家的视角和游戏的业务逻辑。
6.4 大模型/AI产品测试：新的考点正在出现
最近一两年，AI产品测试的面试题开始增多。所谓大模型八股文，里面除了常规软件测试理论，还会考察你如何测试大模型应用，内容涉及Prompt质量、生成内容准确率、幻觉问题、RAG检索效果评估等方向。
如果你面试的是AI相关项目的测试岗位，至少要了解这些基本概念：评测集是什么、准确率和召回率怎么算、如何判断生成内容是否存在误导。这类岗位现在还处于边界模糊阶段，很多公司也说不清楚要什么样的人，反而给了测试思维扎实、学习能力强的人机会。
7. 面试全流程中的实战经验和避坑技巧
7.1 简历环节：筛选中最重要的关键词
简历决定了你能不能拿到面试机会。很多面试者技术不差，但简历写得像岗位说明书，没有任何亮点，被猎头和HR直接过滤。
写测试简历时，建议围绕这几个关键词去写：你在项目中使用的工具、你负责的测试类型、你的产出数据。例如“使用Charles抓包定位接口异常，减少无效bug单30%”就比“熟悉接口测试工具”打动人。如果做过自动化测试，把框架类型和用例规模写清楚。简历上每个项目最好都能扩写成STAR结构，这样可以确保面试时项目介绍不散。
7.2 面试环节：表达里的加分与减分项
面试是一次沟通，不是你背答案的汇报。很多候选人技术没问题，但表达太差，导致面试官无法判断真实水平。我总结几个高频踩坑点。
第一，语速太快、没有停顿。你太紧张，一口气倒出所有内容，面试官根本没听清。技巧是讲重点时放慢速度，每说完一个要点稍微停顿两秒，给面试官提问和消化的空间。第二，不正面回答问题。面试官问你“怎么设计登录功能用例”，你答了一堆“我会先看需求文档，再……”，就是不落到具体用例上，这是典型的不回应。第三，遇到不会的题不要直接沉默。可以说“这个点我之前接触得比较少，但基于现有经验，我的理解是……”，起码要展现你的思考过程。
7.3 反问环节：怎么问才能显出你的专业度
面试结束前，面试官通常会问“你有什么想问我的”，很多人不知道答什么就直接说“没有”，这其实浪费了一个展示自己的机会。
我建议根据面试过程提几个高质量的问题。如果面试聊得比较好，可以问：“这个岗位负责的产品线未来半年的测试目标是什么？”这类问题体现你对这份工作的兴趣。如果你想了解公司技术建设，可以问：“团队目前在自动化测试和持续集成方面做到什么程度了？”这类问题既有深度，也能帮你判断这家公司是否值得去。切忌问“加班多不多”“公积金交多少”这类问题，除非你已经到了谈offer阶段。
8. 面试前一周的高效冲刺方法，帮你快速查缺补漏
8.1 用思维导图刷基础，不许有死角
面试准备不要漫无目的地看文档，我习惯的做法是画一张知识结构图，把测试岗位面试涉及的模块全部列出：测试理论、计算机基础、网络基础、SQL、Linux、接口测试、自动化、性能、项目经验、软素质。每天挑两到三个模块，把每个模块下的高频题过一遍，不会的就记录下来，当天集中解决。
面试高频的基础题里，有几个几乎百发百中的题值得反复练习：输入框怎么设计测试用例、bug的生命周期、发现开发不认bug怎么办、网页访问很慢怎么排查、接口测试测哪些点、selenium元素定位有哪些策略。这些题建议自己对着镜子练三遍以上，确保表达顺畅。
8.2 利用“写复盘笔记”代替“抄答案”
很多人准备八股文就是在网上收集题目和答案，然后用背诵的方式备面试。这样背出来的东西非常僵硬，一旦面试官换个问法就答不上来。我推荐的方法是把题目当成场景，用自己的话写一遍复盘笔记，每个题都要问自己三个问题：为什么答案是这样？这个点用在我的项目里怎么落地？如果我被继续追问，可能会问什么？
比如背到“等价类划分”，你别只背定义。你用自己的话写下游玩：手机号框有18个用户输入，字段要求11位数字，有效等价类有符合规则的数字，无效等价类有空、非数字、10位、12位、特殊字符、重复号等，每个类再结合前端拦截和后端校验去展开。当你把“背答案”变成“写复盘”，面试时哪怕题目变形，你也能灵活应对。
8.3 一个人练面试：对着录音听自己的问题
这个方法我推荐给所有候选人。准备面试的时候，用手机录音功能模拟回答问题，然后回放听自己的表达。你会发现很多自己平时注意不到的问题：口头禅太多、卡壳时间太长、同一个词重复好几遍、语速忽快忽慢。录完以后，重新组织语言再讲一遍，直到自己能流畅地讲完，再进入下一题。
如果你觉得自己的项目讲解总是很弱，可以先画一张项目流程图，把核心流程、你在流程中的动作、每一步的产出物写清楚，再按照流程图讲。讲的时候手里有“图纸”，你的大脑就不会一片空白。
9. 关于年龄焦虑和技术成长：33岁的测试还能不能继续干
热搜词里有一条“软件测试一般能干到多少岁”，这个问题我身边很多朋友都问过。我自己见过三十多岁的功能测试还在点点点，也见过四十多岁的测试负责人带整个质量团队，年龄本身不是瓶颈，能力结构才是。
测试工程师的成长路线通常有几个方向：从测试执行走向测试设计，从手工测试走向自动化测试和性能测试，从执行者走向测试管理，或者从业务测试转向垂直领域专家，比如金融测试、嵌入式测试、AI产品测试。如果你干了三五年还是只做最基础的用例执行，没有积累代码能力、没有深入理解业务，那涨薪和晋升都会很难。
我建议大家每年都做一次技术体检：今年我的自动化测试能力有提升吗？我是否理解了某个业务领域的核心链路？我能不能独立完成一个中等项目的测试方案设计和执行复盘？如果有缺口，就在工作中有意识地补上。面试准备本身也是一次技术体检，八股文背得再熟也只是手段，真正值钱的，是你从每一道题里对测试工作的深层理解。
