1. 这场面试里到底发生了什么前阵子公司测试团队要补人岗位要求很明确能独立负责自动化测试体系的搭建和维护薪资范围给到了15K到21K。简历筛了一圈约了几个看起来合适的候选人其中一位让我印象特别深——期望薪资20K简历上写着“熟悉Python、Selenium、pytest能独立搭建自动化测试框架”还附带了一个看上去挺完整的Web自动化项目。前面聊得还算正常一到技术深入环节就露馅了。我问得很直接“你之前做自动化测试从用例设计到执行、报告、持续集成整个流程能完整描述一遍吗”他想了想说“我是先用Selenium写脚本把重复的回归用例跑起来。脚本放Git上写完跑一下有Pass有Fail就知道功能坏没坏。”这句话本身没什么问题但接下来问细节时他明显开始吃力。问到pytest的fixture机制怎么用、conftest.py怎么组织、接口测试的断言除了校验响应码还会校验什么内容他基本都是“用过但没细看”、“同事那套代码我直接拿来改的”、“pod里好像有封装”这种回答。问到Jenkins里怎么配自动化任务他说“公司是别人配好的我没碰过”。整场面试大概一小时结束后我给评价表写了一句具备一定的脚本编写能力但缺乏框架设计、流程管理和工程化落地经验距离独立搭建体系有明显差距。最终给的定级是如果愿意接受12K到14K可以从初级自动化测试工程师做起如果要20K目前还接不住。这不是个例。这两年我陆陆续续面了差不多几十个号称“会自动化”的候选人发现“会用工具”和“能做好自动化测试”之间隔着一道巨大的认知鸿沟。今天这篇文章我就把自己在面试中常用的考察思路、常见的“皮毛”特征以及我认为真正值20K的能力模型一次性说清楚。2. 一听就露馅三类典型的“皮毛派”画像在展开能力模型之前先把问题画像聊透。以下三类是我在面试中反复遇到的“皮毛”案例大家看完可以对号入座。2.1 只写脚本不写框架这类候选人最常见的描述是“会Python用过Selenium搭过pytest”。但实际上他只是把某个教程或者公司已有项目里的脚本复制过来改改定位符、改改URL能跑通就算完事。你问他pytest的conftest.py和pytest.ini内容是什么fixture的scope怎么设置用例之间的依赖怎么管理失败重试怎么配置大概率答不上来。更别提“为什么需要数据驱动”“为什么要把业务层和用例层分开”这种偏设计层面的问题。这种“脚本搬运工”本质是在记操作步骤而不是在做工程。自动化测试在多数公司不是一次性任务是需要长期演进、持续维护的软件项目。只懂写脚本的人换一个项目环境可能就玩不转了因为他没有“设计”过体系自然也就不知道怎么扩展和落地。2.2 只会UI自动化不懂接口和分层还有一类候选人从头到尾都在讲UI自动化。“我定位元素用XPath和CSS选择器”“我用过显式等待”“我有封装BasePage”。听起来还可以但你一追问“接口自动化做过吗”他就含糊了。有些人说“我用Postman测试过接口”但是问他那个项目的请求体怎么构造、鉴权怎么处理的就说不清了。再问“UI自动化和接口自动化分别在什么场景下优先使用”更是一片空白。UI自动化确实是自动化测试的重要组成部分但它不是全部甚至不应当是大头。从测试金字塔的角度看底层的单元测试和接口测试覆盖面更广、执行更稳定、成本更低UI自动化更多是补足端到端的关键路径验证。一个只会写UI脚本的人碰到项目里大段的业务逻辑能覆盖的场景很有限。你说公司招个20K的人去做一堆Selenium脚本的堆砌值吗2.3 能跑通Demo解决不了维护难题这一类候选人面试时有Demo展示把代码打开、跑一下看起来像模像样。但你又问了几个实际维护中常见的场景他大概率卡住前端页面改版了原来几百个用例里的定位符大面积失效你怎么办用例跑挂了你怎么快速判断是代码Bug、数据问题还是脚本本身的问题接口的响应数据里有动态变化的字段断言怎么处理一批用例执行十几分钟结果报告没人看自动化的价值怎么体现这些问题才是自动化测试真正的工作日常。Demo能跑通只能证明脚本能“自嗨”不等于能解决“长期可用、可信、可维护”的工程问题。许多“皮毛”候选人被问到这些时回复基本是“我没遇到过”“我们项目没这么复杂”。这话你信吗用户注册、登录、下单这类核心流程任何稍微正规一点的项目都会牵扯到。没遇到过要么是项目太小要么就是从来没负责过全流程。3. 真正的20K水平长什么样值得参考的能力模型面试了这么多人我自己对“值不值20K”有一个相对清晰的标准。它不是看你会多少个工具而是看你能不能把一个自动化的东西当成一个核心项目来运营。我拆成四个维度。3.1 框架设计与底层原理你要理解你在用的东西20K的人应该具备的能力不是“用过pytest”而是“理解pytest背后的运行机制”。举个例子。pytest的fixture、conftest、hook函数、mark机制你到底知道多少面试时我通常会递进式追问fixture是什么为什么用fixture而不是setup/teardownfixture的scope有几种什么时候用module、什么时候用session如何自定义插件hook函数怎么实现如果只能回答“fixture是用来初始化环境的”那只是抄了几个BaseCase而已。再比如说Driver管理。一个完整的框架里你不可能每个用例都新建一个浏览器也不可能一个用例跑完就把Session关掉。如何设计一个全局的Driver池怎么在多浏览器、多线程情况下安全使用这些都属于框架设计范畴。把这些问题想清楚的人写出来的“框架”是一个能跑的项目而不是一堆脚本堆在一起的目录。另外工程化的自动化一定要有代码质量意识。你写的公共封装、PageObject、数据层有没有做目录分层能不能让一个刚接手的新人通过阅读你的代码和README快速上手写第一个用例能说明你的框架设计成熟不能说明你只是在写给自己看的脚本碎片。3.2 分层策略与数据管理测试不止是“写用例”很多“皮毛”候选人喜欢的思路是“录脚本、跑回归”这在今天已经不管用了。真正值钱的是对测试分层和测试数据管理有自己的一套策略。具体来说知道哪些用例适合做接口自动化哪些必须走到UI层。知道测试环境怎么隔离测试数据怎么造、怎么还原。一个自动化项目里数据稳定性比脚本稳定性更重要。注册了一个新账号下一次跑重名了怎么办下单了一个订单下一次库存变了怎么办这些都要有预案。知道怎么处理异步逻辑、轮询、幂等。Web页面的等待、接口的轮询处理不好就是一片红色报错。很多脚本跑挂原因不是系统有Bug而是超时策略设得太保守或者太激进。我会反复强调一句话自动化测试的核心价值是提升反馈效率和降低回归成本而不是证明“我能跑通脚本”。如果你的方案里没有对数据、环境、执行时长的管理那你只是做了一个“测试辅助工具”不是“测试平台”。3.3 持续集成与测试报告闭环让自动化跑起来有意义这是“皮毛派”和“真懂行”之间最大的分水岭。一个20K的自动化工程师不能只管“脚本在自己电脑上跑得绿”还要让自动化真正融进开发流程。具体要做的包括接入CI。在Git Commit后自动触发测试任务或者在提PR时跑一轮冒烟用例让开发在合并代码前就收到质量反馈。产出可读性强的报告。不只是“XX个PassXX个Fail”还要有失败日志、截图、响应数据、调用链信息方便开发快速定位问题。做趋势分析。测试长时间跑下来稳定性是在变好还是在变差失败用例集中在哪个模块自动化对回归效率的提升有没有数据佐证处理环境差异。开发机、测试机、CI容器的差别Jar包、浏览器、Appium节点、服务端口等等怎么通过配置文件和环境变量来区分管理。太理想化吗其实现在的工具已经提供了很多开箱即用的能力。Jenkins有丰富插件Group Runner可以管理用例集Allure可以生成定制报告Docker可以快速搭建环境。一个20K的人应该是能把这一套工程链路串起来的人而不是只会写写脚本。4. 我评估自动化水平时的四个常问问题含考察意图与得分点面试不是背题而是通过几个关键问题快速看穿候选人真实水平。下面是我常问的四个问题也顺带说说我期望听到的答案。4.1 问题一pytest fixture的scope怎么设说说你实际用过的场景考察意图能不能说清楚“作用域”和“复用”的概念。低分回答“我一直用默认的function没太关注过scope。”说明只会跑基础用例不错回答“我会根据资源的创建成本和共用风险来定。比如登录状态是Session级别的每个UITest类实例用Module级别的浏览器实例每条用例需要清库、恢复数据就用Function级别的fixture来隔离。另外我会用conftest统一放公共fixture让不同测试模块不需要重复导入。”能体现实际工程经验4.2 问题二一个弹窗在自动化里始终定位不到你会怎么排查考察意图看候选人对元素定位失败的分析链。低分回答“换成XPath再试。”完全缺乏排查思路不错的分析链路先看页面是否真的出现确认等待条件是不是合理。隐形等待、显式等待各是什么机制。再看元素是否在iframe里、Shadow DOM里或者有没有弹层遮罩。这在我实际经验中非常常见很多刚上手的人卡在这两个地方。再检查当前的定位方式是否依赖了动态属性如果CSS类名或ID是自动生成的应该在定位策略里避免。更好的做法是用相对层级定位给前端约定data-testid属性。最后看浏览器控制台报错有些元素是因为前端JS没有执行完才没渲染出来。能按这个链路排查的人说明有实战中的踩坑经历。4.3 问题三你如何设计一批接口自动化用例考察意图你能不能从“调通接口”上升到“设计用例”。低分回答“用requests调用URL然后断言Status Code是200。”这只能算冒烟测试期望方向接口自动化用例需要覆盖功能验证、参数校验、异常场景、数据正确性。不只是看返回码还要看接口的响应数据是否符合业务预期、数据库中的落库结果是否正确、鉴权是否有效、重复请求的幂等性等等。还要说明用例数据的管理方式是登录态前置还是Mock掉有些外部依赖不能每次跑都让开发帮忙准备数据。4.4 问题四你的自动化项目如何度量收益考察意图自动化不是“看起来高大上”就够了。20K级别的人必须懂业务和成本意识。期望答案的方向统计投入使用后减少的回归测试时间。比如原来手工回归核心流程要2天自动化跑5分钟跑完那收益就是接近2天/轮。持续跟踪Bug发现效率。自动化能拦截到多少开发自测阶段没发现的缺陷如果一批用例跑下来一个Bug都没暴露那要么是业务太稳定要么说明你的用例设计太弱。评估维护成本。用例数量和每日运行量的比例维护一个人天能扛住多少条用例的变化。这些问题没有标准答案但能听到候选人用自己的真实数据来讲就非常加分。反之只会说“我建的自动化框架很完善”我基本不会信。5. 在“热词”背后自动化测试真正的新要求面试中有一个绕不开的话题候选人简历里经常会写“会Appium”“会用Playwright”“熟悉AI自动化测试”。但这些热词里很多人只是蹭了个概念深问下去就露怯。5.1 Appium、Maestro与移动端自动化移动端自动化很多人只知道“调用了Driver点击控件”。但实际工作中真机与模拟器的差异、不同安卓版本的兼容、iOS的XCUITest和安卓的UiAutomator2两种底层引擎怎么选、连接池和并行执行怎么配置全都是坑。会跑一个脚本不等于能做移动端测试。Appium的定位策略也比较特殊XPath在安卓和iOS上效率差异很大如果不了解底层引擎真机上几百个用例跑完可能要两三个小时维护也变得很痛苦。近两年Maestro这类新工具开始在移动端UI测试中崭露头角特点是基于YAML配置上手快适合快速验证关键路径。但它同样不能解决移动端自动化里的工程化难题反而因为自定义语法比较新很多团队会观望一段时间。5.2 AI自动化和“测试脚本”的本质关系现在AI热词满天飞“AI自动化测试”成了一个高频词。但说实话大部分人在简历里写“用过AI写自动化测试脚本”实际经历往往是“让AI把一段Selenium脚本转成Playwright的写法”。这个有价值吗有但很有限。AI可以帮助你生成定位符、整理断言、快速搭骨架这些确实把我平时写脚本的效率提升了不少。但AI解决不了的根本问题是你如何设计一套稳定可靠的测试策略页面元素改了、业务流程变了、数据约束变了仍然需要人来判断。所以面试时如果有人说“我熟悉AI自动化”我会请他展示一个具体案例哪段测试代码是用AI生成后放到生产环境里的他用的什么Prompt策略如何校验AI生成代码的正确性大概率又答不上来。5.3 接口自动化和UI自动化的协同才值钱在二线、三线城市很多公司的自动化测试还停留在“用Selenium录一遍”的阶段。但真正有分量的岗位往往要求接口自动化和UI自动化协同作战。一个项目既有接口层的核心逻辑覆盖又有UI层的关键流转验证再用CI把两层串起来——一层跑核心回归一层跑冒烟观测。能做到这个程度的候选人才是团队真正需要的人。6. 给求职者的实在建议怎么写简历、怎么应对深挖文章看到这里如果你发现自己正是某类“皮毛”候选人也别灰心。绝大多数人只是没意识到面试官会在哪个层面深挖并不是学习能力不行。分享几条亲测有效的建议。6.1 简历里写到的每一个技术点都要准备好“三层追问”我在面试时会这样追问一个技术点第一层你用过它做什么第二层它的核心机制/原理是什么第三层你有没有遇到过它不好用的场景如何解决你自己也可以用这套方法复盘简历。比如你写了“熟悉pytest”那就要准备fixture是什么、scope有哪些、怎么给用例打标记、怎么配缓存、怎么调失败重试、遇到用例间耦合时怎么设计。如果这些你都答不上来趁早去把pytest官方文档过一遍顺便把工程上常用的插件也了解清楚。6.2 项目经验不要只写“搭建了自动化框架”要写“解决了什么”我最烦看到空洞如“负责自动化测试框架的搭建”的措辞。真正有价值是说清楚落地前的痛点是什么手工回归要多久线上漏测影响了什么你选的方案是什么为什么选pytestSelenium或者pytestAppium为什么不用Jest/Cypress你的框架支持多少条用例每日执行情况怎么样数据怎么隔离报告怎么推送维护过程中改过哪些设计比如定位策略优化、CI接入、并行执行。你把这些写成三四条有细节的要点我作为面试官大概率一眼就能判断你是不是真的做过。6.3 多做输出把踩坑记录沉淀成自己的知识面试反映不出来的东西其实是你踩过的坑。我见过一个候选人没有名校背景但博客里有几十篇关于Selenium元素等待、Playwright网络监听、接口Mock的实战记录。他面试时的条理性明显比其他人好一截最后也拿到了不错的offer。写作的过程本身就是在逼你梳理“为什么”。你以为你懂了写的时候才发现很多环节经不起推敲。这对面试准备百利而无一害。把踩过的每个坑整理成文字半年后你会发现自己对自动化的理解完全不一样了。6.4 面试时大胆承认“不知道”但要说你知道怎么学我最怕的不是候选人说不会而是说会但被戳穿。真正靠谱的候选人碰到没接触过的领域会直接说“这个细节我没深挖过我了解的是大致原理。如果入职后需要用到我可以在一周内把这块的官方文档和社区实践梳理出来。”这种回答反而加分。做自动化测试本身就是“快速从未知到可知”的过程项目里永远有没见过的新技术、新框架。你只要能证明自己的学习路径和方法是可靠的面试官是能看出来的。6.5 目标16K到20K的人建议按这个路线补课如果现在的水平离20K还差一段距离建议按这个优先级去补齐先把pytest吃透不只是会写用例还要搞清楚fixture、conftest、hook、插件扩展自己动手写一个小型框架。学会接口测试的整体设计掌握requests/httpx的使用理解鉴权、签名、参数化、数据库断言。学CI基本配置至少会自己在Jenkins上建一个项目把测试任务、shell命令、报告产物串起来。涉猎Playwright这类新一代工具搞明白它和Selenium定位上的差异。不要只停留在“会用”要理解为什么它更稳定、为什么社区在切换。尽早接触Allure报告把“报告可视化”这个体验做出来让开发、产品都能看懂你的测试结果。我一直认为面试的本质上不是“背题”而是“对标你真实的能力水平”。能拿20K的人不是因为面试技巧多好而是他真的在项目里搞定过那些别人搞不定的问题。如果你是面试官多花点时间设计几个深挖问题如果你是求职者别把力气花在议价上多把精力放在把工程化这一层想明白。自动化测试这条路最怕的就是看起来热闹实际上连自己能覆盖的范围都说不清。把这个基本盘做扎实薪资和能力才会真的对上号。 
长河君 · 2026/10/6 14:11:08 · 阅读 1.2k 从会用Selenium到拿下20K：自动化测试工程师真实能力模型解析
1. 这场面试里到底发生了什么前阵子公司测试团队要补人岗位要求很明确能独立负责自动化测试体系的搭建和维护薪资范围给到了15K到21K。简历筛了一圈约了几个看起来合适的候选人其中一位让我印象特别深——期望薪资20K简历上写着“熟悉Python、Selenium、pytest能独立搭建自动化测试框架”还附带了一个看上去挺完整的Web自动化项目。前面聊得还算正常一到技术深入环节就露馅了。我问得很直接“你之前做自动化测试从用例设计到执行、报告、持续集成整个流程能完整描述一遍吗”他想了想说“我是先用Selenium写脚本把重复的回归用例跑起来。脚本放Git上写完跑一下有Pass有Fail就知道功能坏没坏。”这句话本身没什么问题但接下来问细节时他明显开始吃力。问到pytest的fixture机制怎么用、conftest.py怎么组织、接口测试的断言除了校验响应码还会校验什么内容他基本都是“用过但没细看”、“同事那套代码我直接拿来改的”、“pod里好像有封装”这种回答。问到Jenkins里怎么配自动化任务他说“公司是别人配好的我没碰过”。整场面试大概一小时结束后我给评价表写了一句具备一定的脚本编写能力但缺乏框架设计、流程管理和工程化落地经验距离独立搭建体系有明显差距。最终给的定级是如果愿意接受12K到14K可以从初级自动化测试工程师做起如果要20K目前还接不住。这不是个例。这两年我陆陆续续面了差不多几十个号称“会自动化”的候选人发现“会用工具”和“能做好自动化测试”之间隔着一道巨大的认知鸿沟。今天这篇文章我就把自己在面试中常用的考察思路、常见的“皮毛”特征以及我认为真正值20K的能力模型一次性说清楚。2. 一听就露馅三类典型的“皮毛派”画像在展开能力模型之前先把问题画像聊透。以下三类是我在面试中反复遇到的“皮毛”案例大家看完可以对号入座。2.1 只写脚本不写框架这类候选人最常见的描述是“会Python用过Selenium搭过pytest”。但实际上他只是把某个教程或者公司已有项目里的脚本复制过来改改定位符、改改URL能跑通就算完事。你问他pytest的conftest.py和pytest.ini内容是什么fixture的scope怎么设置用例之间的依赖怎么管理失败重试怎么配置大概率答不上来。更别提“为什么需要数据驱动”“为什么要把业务层和用例层分开”这种偏设计层面的问题。这种“脚本搬运工”本质是在记操作步骤而不是在做工程。自动化测试在多数公司不是一次性任务是需要长期演进、持续维护的软件项目。只懂写脚本的人换一个项目环境可能就玩不转了因为他没有“设计”过体系自然也就不知道怎么扩展和落地。2.2 只会UI自动化不懂接口和分层还有一类候选人从头到尾都在讲UI自动化。“我定位元素用XPath和CSS选择器”“我用过显式等待”“我有封装BasePage”。听起来还可以但你一追问“接口自动化做过吗”他就含糊了。有些人说“我用Postman测试过接口”但是问他那个项目的请求体怎么构造、鉴权怎么处理的就说不清了。再问“UI自动化和接口自动化分别在什么场景下优先使用”更是一片空白。UI自动化确实是自动化测试的重要组成部分但它不是全部甚至不应当是大头。从测试金字塔的角度看底层的单元测试和接口测试覆盖面更广、执行更稳定、成本更低UI自动化更多是补足端到端的关键路径验证。一个只会写UI脚本的人碰到项目里大段的业务逻辑能覆盖的场景很有限。你说公司招个20K的人去做一堆Selenium脚本的堆砌值吗2.3 能跑通Demo解决不了维护难题这一类候选人面试时有Demo展示把代码打开、跑一下看起来像模像样。但你又问了几个实际维护中常见的场景他大概率卡住前端页面改版了原来几百个用例里的定位符大面积失效你怎么办用例跑挂了你怎么快速判断是代码Bug、数据问题还是脚本本身的问题接口的响应数据里有动态变化的字段断言怎么处理一批用例执行十几分钟结果报告没人看自动化的价值怎么体现这些问题才是自动化测试真正的工作日常。Demo能跑通只能证明脚本能“自嗨”不等于能解决“长期可用、可信、可维护”的工程问题。许多“皮毛”候选人被问到这些时回复基本是“我没遇到过”“我们项目没这么复杂”。这话你信吗用户注册、登录、下单这类核心流程任何稍微正规一点的项目都会牵扯到。没遇到过要么是项目太小要么就是从来没负责过全流程。3. 真正的20K水平长什么样值得参考的能力模型面试了这么多人我自己对“值不值20K”有一个相对清晰的标准。它不是看你会多少个工具而是看你能不能把一个自动化的东西当成一个核心项目来运营。我拆成四个维度。3.1 框架设计与底层原理你要理解你在用的东西20K的人应该具备的能力不是“用过pytest”而是“理解pytest背后的运行机制”。举个例子。pytest的fixture、conftest、hook函数、mark机制你到底知道多少面试时我通常会递进式追问fixture是什么为什么用fixture而不是setup/teardownfixture的scope有几种什么时候用module、什么时候用session如何自定义插件hook函数怎么实现如果只能回答“fixture是用来初始化环境的”那只是抄了几个BaseCase而已。再比如说Driver管理。一个完整的框架里你不可能每个用例都新建一个浏览器也不可能一个用例跑完就把Session关掉。如何设计一个全局的Driver池怎么在多浏览器、多线程情况下安全使用这些都属于框架设计范畴。把这些问题想清楚的人写出来的“框架”是一个能跑的项目而不是一堆脚本堆在一起的目录。另外工程化的自动化一定要有代码质量意识。你写的公共封装、PageObject、数据层有没有做目录分层能不能让一个刚接手的新人通过阅读你的代码和README快速上手写第一个用例能说明你的框架设计成熟不能说明你只是在写给自己看的脚本碎片。3.2 分层策略与数据管理测试不止是“写用例”很多“皮毛”候选人喜欢的思路是“录脚本、跑回归”这在今天已经不管用了。真正值钱的是对测试分层和测试数据管理有自己的一套策略。具体来说知道哪些用例适合做接口自动化哪些必须走到UI层。知道测试环境怎么隔离测试数据怎么造、怎么还原。一个自动化项目里数据稳定性比脚本稳定性更重要。注册了一个新账号下一次跑重名了怎么办下单了一个订单下一次库存变了怎么办这些都要有预案。知道怎么处理异步逻辑、轮询、幂等。Web页面的等待、接口的轮询处理不好就是一片红色报错。很多脚本跑挂原因不是系统有Bug而是超时策略设得太保守或者太激进。我会反复强调一句话自动化测试的核心价值是提升反馈效率和降低回归成本而不是证明“我能跑通脚本”。如果你的方案里没有对数据、环境、执行时长的管理那你只是做了一个“测试辅助工具”不是“测试平台”。3.3 持续集成与测试报告闭环让自动化跑起来有意义这是“皮毛派”和“真懂行”之间最大的分水岭。一个20K的自动化工程师不能只管“脚本在自己电脑上跑得绿”还要让自动化真正融进开发流程。具体要做的包括接入CI。在Git Commit后自动触发测试任务或者在提PR时跑一轮冒烟用例让开发在合并代码前就收到质量反馈。产出可读性强的报告。不只是“XX个PassXX个Fail”还要有失败日志、截图、响应数据、调用链信息方便开发快速定位问题。做趋势分析。测试长时间跑下来稳定性是在变好还是在变差失败用例集中在哪个模块自动化对回归效率的提升有没有数据佐证处理环境差异。开发机、测试机、CI容器的差别Jar包、浏览器、Appium节点、服务端口等等怎么通过配置文件和环境变量来区分管理。太理想化吗其实现在的工具已经提供了很多开箱即用的能力。Jenkins有丰富插件Group Runner可以管理用例集Allure可以生成定制报告Docker可以快速搭建环境。一个20K的人应该是能把这一套工程链路串起来的人而不是只会写写脚本。4. 我评估自动化水平时的四个常问问题含考察意图与得分点面试不是背题而是通过几个关键问题快速看穿候选人真实水平。下面是我常问的四个问题也顺带说说我期望听到的答案。4.1 问题一pytest fixture的scope怎么设说说你实际用过的场景考察意图能不能说清楚“作用域”和“复用”的概念。低分回答“我一直用默认的function没太关注过scope。”说明只会跑基础用例不错回答“我会根据资源的创建成本和共用风险来定。比如登录状态是Session级别的每个UITest类实例用Module级别的浏览器实例每条用例需要清库、恢复数据就用Function级别的fixture来隔离。另外我会用conftest统一放公共fixture让不同测试模块不需要重复导入。”能体现实际工程经验4.2 问题二一个弹窗在自动化里始终定位不到你会怎么排查考察意图看候选人对元素定位失败的分析链。低分回答“换成XPath再试。”完全缺乏排查思路不错的分析链路先看页面是否真的出现确认等待条件是不是合理。隐形等待、显式等待各是什么机制。再看元素是否在iframe里、Shadow DOM里或者有没有弹层遮罩。这在我实际经验中非常常见很多刚上手的人卡在这两个地方。再检查当前的定位方式是否依赖了动态属性如果CSS类名或ID是自动生成的应该在定位策略里避免。更好的做法是用相对层级定位给前端约定data-testid属性。最后看浏览器控制台报错有些元素是因为前端JS没有执行完才没渲染出来。能按这个链路排查的人说明有实战中的踩坑经历。4.3 问题三你如何设计一批接口自动化用例考察意图你能不能从“调通接口”上升到“设计用例”。低分回答“用requests调用URL然后断言Status Code是200。”这只能算冒烟测试期望方向接口自动化用例需要覆盖功能验证、参数校验、异常场景、数据正确性。不只是看返回码还要看接口的响应数据是否符合业务预期、数据库中的落库结果是否正确、鉴权是否有效、重复请求的幂等性等等。还要说明用例数据的管理方式是登录态前置还是Mock掉有些外部依赖不能每次跑都让开发帮忙准备数据。4.4 问题四你的自动化项目如何度量收益考察意图自动化不是“看起来高大上”就够了。20K级别的人必须懂业务和成本意识。期望答案的方向统计投入使用后减少的回归测试时间。比如原来手工回归核心流程要2天自动化跑5分钟跑完那收益就是接近2天/轮。持续跟踪Bug发现效率。自动化能拦截到多少开发自测阶段没发现的缺陷如果一批用例跑下来一个Bug都没暴露那要么是业务太稳定要么说明你的用例设计太弱。评估维护成本。用例数量和每日运行量的比例维护一个人天能扛住多少条用例的变化。这些问题没有标准答案但能听到候选人用自己的真实数据来讲就非常加分。反之只会说“我建的自动化框架很完善”我基本不会信。5. 在“热词”背后自动化测试真正的新要求面试中有一个绕不开的话题候选人简历里经常会写“会Appium”“会用Playwright”“熟悉AI自动化测试”。但这些热词里很多人只是蹭了个概念深问下去就露怯。5.1 Appium、Maestro与移动端自动化移动端自动化很多人只知道“调用了Driver点击控件”。但实际工作中真机与模拟器的差异、不同安卓版本的兼容、iOS的XCUITest和安卓的UiAutomator2两种底层引擎怎么选、连接池和并行执行怎么配置全都是坑。会跑一个脚本不等于能做移动端测试。Appium的定位策略也比较特殊XPath在安卓和iOS上效率差异很大如果不了解底层引擎真机上几百个用例跑完可能要两三个小时维护也变得很痛苦。近两年Maestro这类新工具开始在移动端UI测试中崭露头角特点是基于YAML配置上手快适合快速验证关键路径。但它同样不能解决移动端自动化里的工程化难题反而因为自定义语法比较新很多团队会观望一段时间。5.2 AI自动化和“测试脚本”的本质关系现在AI热词满天飞“AI自动化测试”成了一个高频词。但说实话大部分人在简历里写“用过AI写自动化测试脚本”实际经历往往是“让AI把一段Selenium脚本转成Playwright的写法”。这个有价值吗有但很有限。AI可以帮助你生成定位符、整理断言、快速搭骨架这些确实把我平时写脚本的效率提升了不少。但AI解决不了的根本问题是你如何设计一套稳定可靠的测试策略页面元素改了、业务流程变了、数据约束变了仍然需要人来判断。所以面试时如果有人说“我熟悉AI自动化”我会请他展示一个具体案例哪段测试代码是用AI生成后放到生产环境里的他用的什么Prompt策略如何校验AI生成代码的正确性大概率又答不上来。5.3 接口自动化和UI自动化的协同才值钱在二线、三线城市很多公司的自动化测试还停留在“用Selenium录一遍”的阶段。但真正有分量的岗位往往要求接口自动化和UI自动化协同作战。一个项目既有接口层的核心逻辑覆盖又有UI层的关键流转验证再用CI把两层串起来——一层跑核心回归一层跑冒烟观测。能做到这个程度的候选人才是团队真正需要的人。6. 给求职者的实在建议怎么写简历、怎么应对深挖文章看到这里如果你发现自己正是某类“皮毛”候选人也别灰心。绝大多数人只是没意识到面试官会在哪个层面深挖并不是学习能力不行。分享几条亲测有效的建议。6.1 简历里写到的每一个技术点都要准备好“三层追问”我在面试时会这样追问一个技术点第一层你用过它做什么第二层它的核心机制/原理是什么第三层你有没有遇到过它不好用的场景如何解决你自己也可以用这套方法复盘简历。比如你写了“熟悉pytest”那就要准备fixture是什么、scope有哪些、怎么给用例打标记、怎么配缓存、怎么调失败重试、遇到用例间耦合时怎么设计。如果这些你都答不上来趁早去把pytest官方文档过一遍顺便把工程上常用的插件也了解清楚。6.2 项目经验不要只写“搭建了自动化框架”要写“解决了什么”我最烦看到空洞如“负责自动化测试框架的搭建”的措辞。真正有价值是说清楚落地前的痛点是什么手工回归要多久线上漏测影响了什么你选的方案是什么为什么选pytestSelenium或者pytestAppium为什么不用Jest/Cypress你的框架支持多少条用例每日执行情况怎么样数据怎么隔离报告怎么推送维护过程中改过哪些设计比如定位策略优化、CI接入、并行执行。你把这些写成三四条有细节的要点我作为面试官大概率一眼就能判断你是不是真的做过。6.3 多做输出把踩坑记录沉淀成自己的知识面试反映不出来的东西其实是你踩过的坑。我见过一个候选人没有名校背景但博客里有几十篇关于Selenium元素等待、Playwright网络监听、接口Mock的实战记录。他面试时的条理性明显比其他人好一截最后也拿到了不错的offer。写作的过程本身就是在逼你梳理“为什么”。你以为你懂了写的时候才发现很多环节经不起推敲。这对面试准备百利而无一害。把踩过的每个坑整理成文字半年后你会发现自己对自动化的理解完全不一样了。6.4 面试时大胆承认“不知道”但要说你知道怎么学我最怕的不是候选人说不会而是说会但被戳穿。真正靠谱的候选人碰到没接触过的领域会直接说“这个细节我没深挖过我了解的是大致原理。如果入职后需要用到我可以在一周内把这块的官方文档和社区实践梳理出来。”这种回答反而加分。做自动化测试本身就是“快速从未知到可知”的过程项目里永远有没见过的新技术、新框架。你只要能证明自己的学习路径和方法是可靠的面试官是能看出来的。6.5 目标16K到20K的人建议按这个路线补课如果现在的水平离20K还差一段距离建议按这个优先级去补齐先把pytest吃透不只是会写用例还要搞清楚fixture、conftest、hook、插件扩展自己动手写一个小型框架。学会接口测试的整体设计掌握requests/httpx的使用理解鉴权、签名、参数化、数据库断言。学CI基本配置至少会自己在Jenkins上建一个项目把测试任务、shell命令、报告产物串起来。涉猎Playwright这类新一代工具搞明白它和Selenium定位上的差异。不要只停留在“会用”要理解为什么它更稳定、为什么社区在切换。尽早接触Allure报告把“报告可视化”这个体验做出来让开发、产品都能看懂你的测试结果。我一直认为面试的本质上不是“背题”而是“对标你真实的能力水平”。能拿20K的人不是因为面试技巧多好而是他真的在项目里搞定过那些别人搞不定的问题。如果你是面试官多花点时间设计几个深挖问题如果你是求职者别把力气花在议价上多把精力放在把工程化这一层想明白。自动化测试这条路最怕的就是看起来热闹实际上连自己能覆盖的范围都说不清。把这个基本盘做扎实薪资和能力才会真的对上号。