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/teardown？
- fixture的scope有几种？什么时候用module、什么时候用session？
- 如何自定义插件？hook函数怎么实现？
如果只能回答“fixture是用来初始化环境的”，那只是抄了几个BaseCase而已。
再比如说Driver管理。一个完整的框架里，你不可能每个用例都新建一个浏览器，也不可能一个用例跑完就把Session关掉。如何设计一个全局的Driver池？怎么在多浏览器、多线程情况下安全使用？这些都属于框架设计范畴。把这些问题想清楚的人，写出来的“框架”是一个能跑的项目，而不是一堆脚本堆在一起的目录。
另外，工程化的自动化一定要有代码质量意识。你写的公共封装、PageObject、数据层，有没有做目录分层？能不能让一个刚接手的新人，通过阅读你的代码和README，快速上手写第一个用例？能，说明你的框架设计成熟；不能，说明你只是在写给自己看的脚本碎片。
3.2 分层策略与数据管理：测试不止是“写用例”
很多“皮毛”候选人喜欢的思路是“录脚本、跑回归”，这在今天已经不管用了。真正值钱的，是对测试分层和测试数据管理有自己的一套策略。
具体来说：
- 知道哪些用例适合做接口自动化，哪些必须走到UI层。
- 知道测试环境怎么隔离，测试数据怎么造、怎么还原。一个自动化项目里，数据稳定性比脚本稳定性更重要。注册了一个新账号，下一次跑重名了怎么办？下单了一个订单，下一次库存变了怎么办？这些都要有预案。
- 知道怎么处理异步逻辑、轮询、幂等。Web页面的等待、接口的轮询，处理不好就是一片红色报错。很多脚本跑挂，原因不是系统有Bug，而是超时策略设得太保守或者太激进。
我会反复强调一句话：自动化测试的核心价值，是提升反馈效率和降低回归成本，而不是证明“我能跑通脚本”。如果你的方案里没有对数据、环境、执行时长的管理，那你只是做了一个“测试辅助工具”，不是“测试平台”。
3.3 持续集成与测试报告闭环：让自动化跑起来有意义
这是“皮毛派”和“真懂行”之间最大的分水岭。一个20K的自动化工程师，不能只管“脚本在自己电脑上跑得绿”，还要让自动化真正融进开发流程。
具体要做的包括：
- 接入CI。在Git Commit后自动触发测试任务，或者在提PR时跑一轮冒烟用例，让开发在合并代码前就收到质量反馈。
- 产出可读性强的报告。不只是“XX个Pass，XX个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 项目经验不要只写“搭建了自动化框架”，要写“解决了什么”
我最烦看到空洞如“负责自动化测试框架的搭建”的措辞。真正有价值，是说清楚：
- 落地前的痛点是什么？手工回归要多久？线上漏测影响了什么？
- 你选的方案是什么？为什么选pytest+Selenium或者pytest+Appium？为什么不用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的人，不是因为面试技巧多好，而是他真的在项目里搞定过那些别人搞不定的问题。如果你是面试官，多花点时间设计几个深挖问题；如果你是求职者，别把力气花在议价上，多把精力放在把工程化这一层想明白。自动化测试这条路，最怕的就是看起来热闹，实际上连自己能覆盖的范围都说不清。把这个基本盘做扎实，薪资和能力才会真的对上号。
