企业官网建设流程全解析

1. 面试现场还原与问题拆解

前几天公司出了个测试岗位的HC，薪资范围给到18K到25K，面了大概十来个人，绝大多数简历都写着“精通自动化测试”“熟悉 pytest 框架”“能独立搭建自动化测试体系”。结果一个要20K的候选人，让我印象特别深——简历写得确实漂亮，自动化测试经验写了三年，项目里列了接口自动化、UI自动化、持续集成，乍一看完全就是标准的高级测试工程师画像。

可是一问细节就露馅了。我问他用 pytest 写过哪些场景，他说写过登录测试、下单测试，再追问 fixture 和 conftest 是怎么组织的，他愣了几秒说“大概知道”。问接口自动化用的什么库，他说 requests，再问 token 失效后怎么处理，他说“重新登录就行”。问 UI 自动化的元素定位方式，他直接背了 id、class、xpath 几个名词，但完全讲不清什么时候用 xpath 优先、什么情况绝对不能用。整个面试持续了四十分钟，我基本已经确定他的真实水平就是在培训班或者B站教程里学了两三个月的入门级，离“三年经验、要20K”这个定位差了至少两个档次。

说实话，这不算极端个案。我这些年参与过不少技术面试，见过太多把“会用 requests 发个请求”写成“精通接口自动化”的简历，也见过把“跑通了一个 unnitest 脚本”写成了“擅长测试框架开发”的候选人。这背后其实是一个行业现象：自动化的门槛看起来低，人人都能写两行脚本，但真正能支撑起20K薪资的自动化能力，远不是跑通一个 demo 那么简单。这篇文章我就想把这次的面试经历摊开讲清楚，聊聊自动化测试真正的分水岭在哪里，也希望给正在精进这条路的同学一些可参考的坐标。

先说清楚我的立场：我并不是说20K的测试工程师必须是个多牛的架构师，不同公司、不同业务对自动化的深度要求确实不一样。但有一条底线是通用的——你要对“自动化”这件事有系统性的理解，而不是会几个孤立的命令和函数。

2. 20K这一档自动化到底该会什么

2.1 先给“皮毛”画个像

在拆解20K该有的能力之前，先把“只会皮毛”是什么样说清楚，方便对号入座。我总结了面试中高频出现的几类“皮毛症状”：

• 只会跑通脚本：照着教学视频敲代码，能在本地把一条用例跑绿，但完全不理解背后的运行机制。问他 pytest 收集用例的规则、conftest 的作用域、fixture 的 teardown 怎么触发，一概不知。
• 只会调库不会排错：requests、appium、playwright 这些库的 API 都能用，但一报错就懵。最常见的表现是：看到一个 TypeError 或者元素找不到的报错，不会看 traceback，不会定位是环境问题、定位问题还是数据问题，只会把整个报错贴给群友或者直接百度。
• 只会 happy path：写的用例全部走正常流程，输入正确数据、点击正确按钮、断言正确结果。一旦涉及异常流程、边界值、环境抖动、数据状态变化，脚本就废了。这种用例在真实业务里基本不具备稳定执行的条件。
• 只会写代码不会工程化：脚本和项目混在一起，没有分层，没有公共方法封装，没有配置文件管理，用例之间互相耦合。跑起来凭运气，今天能过明天就挂，挂在哪、为什么挂，完全不掌握。
• 只会点点点的人说“会自动化”：这个就更夸张了，不过不是本文讨论的重点。真正的分界点在“能独立设计自动化方案并落地稳定运行”。

如果你发现自己中了三条以上，那说实话，离20K确实还有距离。但别灰心，后面我会把补全这些能力的具体路径拆开。

2.2 20K薪资对应的是一个完整的自动化能力闭环

我自己带团队给高级测试工程师贴的能力标签通常有五个维度：脚本开发、框架设计、工程化落地、稳定性和效率治理、业务结合能力。20K这个档位，市场的普遍预期是前三个维度必须扎实，第四个维度要有体感，第五个维度要能拿出真实案例。

展开来说：

• 脚本开发：不只是会写 Python，而是要写出可维护的代码。变量命名有意义，函数职责单一，断言不止是结果比对，还包含前置数据准备、后置清理、失败重试等逻辑。
• 框架设计：能讲清楚分层设计。最常见的是三层结构：基础封装层（定位、请求、驱动管理）、业务操作层（登录、下单、搜索这些业务动作）、用例执行层（测试用例 + 数据驱动 + 断言）。这层的能力体现的是工程思维，而不只是代码水平。
• 工程化落地：代码要能放进 CI 流水线里跑。Git 分支管理、环境配置文件隔离、依赖管理、定时执行、产物归档、通知触达，这每一项都是工程化的一部分。
• 稳定性治理：自动化最怕的是“昨天全绿今天全红”。你至少要知道 rerun、等待策略、数据隔离、用例并发这几种手段分别解决什么问题。出现失败时，能在十分钟内判断这是环境问题、代码问题还是脚本问题。
• 业务结合能力：自动化测试终究是服务业务的。做得好的自动化工程师，会深入理解业务流程，把自动化用例设计和业务风险结合起来。这部分的深度，才是拉开20K和15K差距的真正分水岭。

表格里这个差距，就是20K这档的核心评判标准。很多候选人挂在面试上的原因，不是某个具体技术不会，而是这五个维度里只有第一项勉强合格，其他四项完全没有积累。

2.3 为什么“会调库”不等于“会自动化”

这个道理我每次面试完都想拍桌子强调一遍：requests.post() 能发出请求，这跟自动化能力之间隔着一整个知识体系。用一个生活化的类比来说，能用微波炉热饭不代表你是个厨师；会用 Photoshop 抠图不代表你能做视觉设计。工具的使用只是最外层的一个动作，真正值钱的是里面那层方法论。

以接口自动化为例，候选人口中的“我用 requests 做过接口自动化”可能只是：

import requests resp = requests.post("http://example.com/api/login", json={"user": "a", "pwd": "b"}) print(resp.json())

而真正的接口自动化用例至少要处理这些事：测试数据从哪来、怎么隔离；依赖接口的数据怎么构造；token 过期怎么自动刷新；用例失败后怎么定位是代码问题还是接口变更；大量用例跑起来怎么控制并发和排队；断言怎么写才能既覆盖核心逻辑又不过度耦合。这些问题每一个都能写一篇长文，但基础薄弱的人往往连问题是什么都意识不到。

所以别再拿“我会调 requests”当核心竞争力了。调库只是自动化的起点，就像开车只是司机的基本功一样，真正决定上限的是你对这套体系有没有完整的掌控力。

3. 自动化测试核心技能盘点：真实工作所需的那张地图

3.1 语言基础：Python 的掌握边界

自动化测试领域现在的主流语言还是 Python，Java 在部分金融、政企项目里也还有不小的份额。但不管是 Python 还是 Java，语言基础都要扎实到“能写工程代码”而不是“能写脚本”的程度。

Python 方面，基础语法、函数、类、装饰器、上下文管理器、异常处理是必须的。但很多人卡在装饰器上——这玩意儿在 pytest 里无处不在，比如 @pytest.fixture、@pytest.mark.parametrize、自定义插件里的钩子函数，全是装饰器的应用。如果你不懂装饰器，写 pytest 用例就只能停留在“照着模板改”的阶段，根本没法按需定制。

另外有一个被严重低估的知识点：日志和调试能力。实际写自动化脚本，真正耗时间的是定位问题。print 大法在十几行脚本里够用，在几百个用例的项目里就是灾难。logging 模块怎么配置、日志级别怎么划分、关键操作怎么埋点、失败时怎么快速回放现场，这些是工程实践中非常核心的技能，但在培训班里基本不会重点讲。

举一个非常实际的例子。之前我同事接手一个别人留下的 UI 自动化项目，几千条用例每天稳定跑挂 20% 左右，没人说得清挂在哪一步。后来一看代码，问题非常典型：所有操作都没有日志，断言失败只是抛了个 AssertionError，失败截图也没有归档机制。这种脚本写出来，维护成本比手工测试还高。真正的工程化做法是：每一步关键操作记录日志、失败时自动截图并 attach 到测试报告、加上重试机制和失败用例的现场信息收集。这些能力才是自动化测试的“内功”。

3.2 接口自动化：数据、鉴权、依赖和断言

接口自动化是性价比最高、稳定性最好、也是最值得投入的自动化方向。它不像 UI 自动化那样容易被前端改动影响，运行速度和反馈效率又远高于 UI 层。在面试里，如果候选人接口自动化的思路清晰，整体评价通常不会低。

做接口自动化时要处理的核心命题有几个：

第一是测试数据管理。接口测试离不开各种测试数据：账号、订单号、商品 ID、优惠券等。这些数据从哪里来？是预置在库里还是通过接口动态创建？如何保证并发跑用例时不同用例之间数据不冲突？最简单的做法是每个用例用独立的数据前缀，复杂一点的做法是打造一套数据工厂，通过调用业务接口或者直连数据库来构造数据。

第二是鉴权与 token 管理。现在绝大多数系统的接口都要求登录后拿 token，而且 token 有有效期。自动化用例跑着跑着 token 过期了，是让每条用例重新登录，还是搞一个 session 级别的共享 token？重试机制里 token 刷新怎么处理？这些细节没想清楚，你的接口自动化就永远只能在理想环境里玩。

第三是接口依赖。业务接口通常不是独立的：下单依赖商品信息，支付依赖订单状态，退款依赖支付记录。用例之间的依赖怎么管理？最推荐的做法是把依赖接口的调用封装成公共方法，返回你需要的数据，而不是让用例 A 的结果直接影响用例 B。这样用例之间保持独立，任意一条都可以单独执行。

第四是断言策略。很多人断言只检查 HTTP 状态码和响应里的 code 字段，这是远远不够的。一个完整的接口断言至少要覆盖这么几层：状态码、业务码、关键字段值、数据库落库结果、敏感的副作用（比如发消息、扣库存、写日志）。当然断言也不是越多越好，过度断言会导致用例对非核心逻辑变化过于敏感，维护成本陡增。这个度怎么把握，就是经验的价值。

一个比较靠谱的接口自动化落地结构是这样：

api_test_project/ ├── config/ # 环境配置，区分 dev/test/prod │ └── config.yaml ├── api/ # 接口层，每个接口一个方法 │ ├── user_api.py │ └── order_api.py ├── core/ # 核心封装，请求会话、鉴权、日志 │ ├── http_client.py │ ├── auth.py │ └── logger.py ├── tests/ # 用例层，按业务模块组织 │ ├── test_login.py │ └── test_order.py ├── data/ # 测试数据文件 │ └── user_data.json ├── utils/ # 工具类，随机数、加密、日期等 ├── conftest.py ├── pytest.ini └── requirements.txt

这个结构本身不神秘，但它的价值在于把“变化”隔离开了。接口地址变了只改 api 层，测试数据变了只改 data 层，用例逻辑只关注业务场景本身。我面试时喜欢让候选人讲讲他项目里的目录结构怎么组织的，能讲清楚这一层的候选人，基本就筛掉了六成“皮毛型选手”。

3.3 UI 自动化：Web 与 App 的关键差异

UI 自动化在很多人眼里就是“录制脚本 + 回放”，其实完全不是这么回事。真正在生产环境里长期运行且价值显著的 UI 自动化，需要处理的问题远比录制脚本复杂。

Web 端的话，元素定位策略是最基本的能力。id、name、class name、tag name、link text、partial link text、xpath、css selector 各有适用场景。我的经验是：优先用 id，其次用 css selector，xpath 最后考虑。原因很简单，xpath 的可读性和维护性在复杂页面里会急剧恶化，而且某些场景下执行性能也更差。但 xpath 又是绕不开的——没有 id、没有稳定 class 的页面元素，xpath 里的 text 定位和轴定位（比如找兄弟节点、父节点）就很重要。懂不懂“什么时候用什么手段”，其实就是自动化经验的分水岭。

另外一个关键点是等待策略。90% 的 UI 自动化不稳定都是等待策略写得太随意。很多人只会用 time.sleep()，一睡睡三秒，慢不说，网络波动大时还是会失败。业界的主流方案是显式等待（WebDriverWait + expected_conditions），针对不同元素、不同状态设置不同超时时间。更高级的做法是封装一个自定义的“操作元素”方法，内部统一处理等待、可见性校验、点击、异常截图，把稳定性问题收敛到一个公共模块里。

Mobile 端自动化很多同学接触的是 Appium，但常常会用不会调。这里必须知道几个关键概念：desired capabilities 是干什么的，每个参数对连接和会话有什么影响；UIAutomator2 和 XCUITest 两种引擎的差异；真机调试和模拟器的区别；没有稳定控件定位时（比如游戏、H5 页面）怎么绕过；iOS 和 Android 在自动化上的能力差异。你不需要原来就是一个移动端开发专家，但至少要清楚自己在自动化每个环节用的什么驱动、为什么选它、遇到某些控件定位不到时有没有替代方案。

3.4 现代化工具栈：playwright 与 maestro 代表的趋势

这两年工具链的变化非常快，我在面试中也开始看重候选人有没有主动学习新工具的意识和能力。Playwright 在 Web 自动化领域几乎要取代 Selenium 成为新一代主流了，它最大的优势是事件驱动架构，等待机制更智能，还能自动处理很多曾经需要手动封装的问题。关键是它的多浏览器支持、移动端 Web 模拟、网络拦截能力，让 UI 自动化的场景边界大大拓宽。

用 Playwright 写用例和用 Selenium 完全不同，举个最简单的例子：

from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch(headless=False) page = browser.new_page() page.goto("https://example.com") page.get_by_role("button", name="登录").click() page.wait_for_url("**/home") browser.close()

看到区别了吗？Playwright 的定位器更贴近用户视角，get_by_role、get_by_text、get_by_placeholder 这些 API 让定位策略脱离了脆弱的 DOM 结构。再加上自动等待机制，脚本稳定性上了一个台阶。

移动端这边，Maestro 这类基于 YAML 描述流程的新工具也在快速流行：

appId: com.example.app --- - launchApp - tapOn: "登录" - inputText: "user@example.com" - tapOn: "下一步"

这种声明式的方式极大降低了脚本编写和阅读的成本，我在团队里评估过，有些简单的回归场景用 Maestro 能比 Appium 节省超过一半的维护量。当然，它不是万能的，复杂断言和深度定制场景还是得回到 Appium 这类底层框架。

我想强调的是，工具永远在变，而底层能力是相通的：对定位、等待、数据、断言、稳定性的理解，才是跨工具的通用资产。如果一个人只背了个工具名，换个工具就抓瞎，那只能说明他过去的学习方式太死板了。

3.5 运维与交付侧：CI 流水线不是加分项，是标配

以前自动化测试脚本是“能跑就行”，现在行业里基本达成共识：自动化测试的价值在于持续执行和快速反馈，脚本跑一次就扔进角落吃灰，毫无意义。所以 CI（持续集成）已经从一个“加分项”变成了“标配能力”。

这一块常见的技能点包括：

• 版本管理：git 的基本流程和分支策略，至少你要知道怎么把代码放到仓库里、怎么协作、怎么打 tag。
• 流水线配置：Jenkins 的 Pipeline 语法、GitLab CI 的 yml 文件配置、GitHub Actions 的 workflow 定义。你不需要是运维专家，但至少能独立搭一条“拉代码 → 准备环境 → 跑测试 → 生成报告 → 发通知”的流水线。
• 容器化基础：Docker 的基本用法，比如把测试环境封装成镜像、在容器里跑测试脚本、管理依赖的一致性。这个技能在团队环境里非常实用。
• 产物和报告归档：Allure、pytest-html 这些报告工具的接入和配置，以及失败产物的收集与通知触达（钉钉、企微、邮件）。

举一个具体场景：公司要求每天早上八点跑完冒烟测试，九点开发上班前把结果推到群里。这个需求实现起来并不复杂，但考察的点很综合：测试脚本要稳定、环境要可复用、流水线要可靠、通知要触达。我在面试里特别喜欢问这类“从零到一搭建流程”的经历，因为这个问题能把候选人的工程能力和执行力一起带出来。

4. 面试官视角：怎么问穿“皮毛型选手”

4.1 深挖式提问：别让候选人背概念

作为面试官，我的追问思路很简单：从具体项目入手，往深处挖细节，不满足于空洞的技术名词。自动化测试的简历高频词就那些，不问也知道候选人都能背，真正有意义的是看他能不能把概念和场景结合在一起。

常见的追问问题汇总如下：

• “你说你独立搭建过接口自动化框架。那这个框架从零到一用了哪些组件？为什么选 pytest 而不是 unnitest？你自己的代码和原生 pytest 有什么区别？”
• “你的用例跑挂了，第一反应排查什么问题？怎么区分是环境问题、数据问题还是脚本问题？给我一个你印象最深刻的失败排查经历。”
• “接口测试里有个场景：创建订单时依赖一个商品 ID，而这个商品 ID 每次测试前需要先生成。你怎么处理这种依赖？”（这里考察数据构造和依赖管理）
• “你们的接口自动化用例有多少条？全量跑完要多久？跑挂率大概多少？挂了你怎么办？”（这里考察真实落地情况，编的人很容易露馅）
• “UI 自动化里你遇到过元素定位不稳定的情况吗？怎么解决的？讲一个具体例子。”（这里考察等待策略和定位策略的深度理解）
• “token 有效期两小时，你们的自动化用例怎么确保执行过程中 token 不失效？如果失效了用例会怎么表现？”

这些问题的共同特点是：没有标准答案，但有标准质量。真正做过的人能讲出很多细节、很自然的决策过程；没做过的人只能挤牙膏，回答漏洞百出。面试这事儿就是这样，用户量和代码量是很难装的。

4.2 现场能力测试：给一段代码，让他说出问题

除了口头追问，我还会安排一个小环节：给候选人一段有明显问题的自动化测试代码，让他说说这段代码写得好不好、哪里有坑、怎么改进。这比背概念靠谱得多。

我经常用的一段示例是这样的：

import time import requests def test_order(): # 用户登录 resp = requests.post("http://api.test.com/login", json={"username": "test01", "password": "123456"}) token = resp.json()["data"]["token"] # 获取商品 resp2 = requests.get("http://api.test.com/products", headers={"Authorization": f"Bearer {token}"}) product_id = resp2.json()["data"][0]["id"] # 下单 resp3 = requests.post("http://api.test.com/order", headers={"Authorization": f"Bearer {token}"}, json={"product_id": product_id, "num": 1}) assert resp3.status_code == 200 time.sleep(2) # 查询订单 resp4 = requests.get(f"http://api.test.com/order/{resp3.json()['data']['order_id']}", headers={"Authorization": f"Bearer {token}"}) assert resp4.json()["data"]["status"] == "PAID"

这段代码问题非常典型，但我见过的候选人里，能指出超过四个问题的不足两成。问题包括：

• 登录逻辑写死在用例内部，token 无法复用，且无法处理过期刷新；
• 用例依赖“第一个商品”这种不确定数据，测试数据不可控；
• 断言覆盖不足：没有校验响应业务码，也没有校验数据库状态；
• time.sleep 硬等待，不能应对响应时间波动；
• 没有日志，失败后无法快速定位是哪一步的问题；
• base URL 直接硬编码，环境切换几乎不可能；
• 用例名 test_order 写的是下单，实际还覆盖了登录和查单，职责不单一。

这道题其实不难，但非常能检验一个人平时写代码时的思考深度。排除“没准备过这种题”的因素，真正有经验的测试开发几乎都能脱口而出几个关键问题。

4.3 项目经历深挖：讲细节、讲决策、讲踩坑

还有一个高阶环节是我最喜欢的：让候选人讲他的项目里最有技术含量的一个点，反复追问其中的细节和决策依据。比如候选人说“我为项目搭了接口自动化框架”，我就会追问：

• 框架目录怎么组织的？
• 环境配置怎么实现多环境切换的？
• 报告接的是什么？失败用例怎么定位？
• 用例之间有依赖吗？怎么处理？
• 你团队里其他同事用你这个框架吗？他们反馈过什么问题？
• 你后来重构过几次？每次因为什么原因重构？

这些问题一问，真实性和深度就全出来了。做过的人能滔滔不绝半小时，没做过的人两三个问题就沉默。

面试本来就不是为了刁难人，而是为了给候选人一个展示自己的舞台。可惜的是，我面过的很多“皮毛型选手”面对这些追问，能接住的少之又少。

5. 求职者视角：别让“皮毛”两个字害了你的前程

5.1 重新盘点：你现在的能力能支撑多少薪资

站在求职者的角度，要20K之前，最好先做个诚实的自我盘点。我把自动化测试工程师的能力模型画成一个四层金字塔，你可以对照一下自己目前在哪个层级：

第一层：工具应用层（对应薪资8K-12K）

• 能写脚本，会调库，能照着模板完成任务
• 了解 pytest 的基本用法，但不理解 fixture、插件的完整机制
• 能跑通 demo，但项目里的稳定性很差

第二层：框架理解层（对应薪资12K-18K）

• 理解分层设计，能搭建基础框架
• 能处理数据驱动、配置管理、断言策略等核心问题
• 知道等待策略、失败重试这些稳定性手段，并能实际运用

第三层：工程落地层（对应薪资18K-25K）

• 能独立设计并落地一套测试体系，包含 CI、报告、通知、环境管理
• 能解决稳定性问题，建立失败排查机制
• 对团队效率有实际贡献，能带动其他同事提升自动化能力

第四层：效率治理层（对应薪资25K以上）

• 能基于 ROI 评估哪些场景适合自动化、哪些不适合
• 能做技术选型、搭建平台、建设测试基础设施
• 有能力影响测试流程和团队协作方式

很多要20K的候选人，能力可能只在第二层中段。典型的落差就是：自认为自己第三层，实际只有第二层。这中间的差距不是靠简历包装能弥补的，面试官几个问题就能戳穿。

5.2 学习路线建议：从“皮毛”到“扎实”的正确路径

如果你发现自己正在“皮毛区”徘徊，完全不用焦虑。自动化这条路是清晰的，只要按正确顺序把欠的账补上，进步会非常快。

我的建议学习路径是这样的：

第一阶段：语言基础补齐（2-4周）

• 把 Python 的函数、类、装饰器、上下文管理器过一遍，尤其是装饰器，pytest 全家桶都建立在它上面
• 学一下 logging 模块的配置方式，养成写日志的习惯
• 写一个小的 API 调用脚本，加入异常处理和日志，练习看 traceback

第二阶段：接口自动化深度实践（4-8周）

• 用 pytest + requests 从零搭一个小框架，不要再用现成的脚手架
• 自己实现 fixture 管理 token、数据构造、环境切换
• 把断言策略、日志、报告完整接入
• 扔到 CI 里，让它每天自动跑一次

第三阶段：UI 自动化掌握（4-6周）

• 先学 Playwright 再学 Selenium，习惯用新工具但理解底层原理
• 重点踩等待策略和定位策略这两个坎
• 每个用例都要加失败截图和重试，养成稳定性的习惯

第四阶段：工程化和运维能力（4-6周）

• 学 Docker 基础，把测试环境容器化
• 学 GitLab CI 或 Jenkins Pipeline，搭一条完整的流水线
• 把报告、通知、产物归档全部串起来

这条路径不是看看教程就行，而是每一步都要有一个“真实项目”来承载。没有真实业务场景，学的都是空中楼阁。我见过很多同学拿“公司没自动化项目”当借口，其实完全可以用开源项目、个人网站接口、甚至自己 mock 一套服务来练手。重要的是“做了完整的项目”，而不是“在真实公司做的项目”。

5.3 简历上怎么写、面试中怎么讲才能站得住

最后给正在准备面试的同学几个非常务实的建议。第一，简历里的技术栈一定要想清楚每个词背后的应用场景。你写了 pytest，那就要经得起追问 fixture、plugin、hook、参数化；你写了 Appium，那就要能说清楚和 UIAutomator2/XCUITest 的关系。写上去的每个技术词，都是面试官深挖的靶子。

第二，项目经历不要只写“做了什么”，要写“怎么做的”和“为什么这么做”。比如：

“搭建接口自动化框架，通过 pytest fixture 统一管理 token，实现用例间数据隔离；接入 Allure 报告和飞书通知，跑挂率从 15% 降到 3%。”

这种写法至少有三个信息点，每一个都能展开聊：token 管理怎么做的、数据隔离怎么设计的、跑挂率怎么降下来的。不是空话，每一句背后都有故事。

第三，面试时遇到不会的问题，千万不要硬编。诚实地讲“这个我了解得不多，但我的理解是……”比编一个答案要好得多。面试官也是从业者，一眼就能看出真假。真诚展示自己的真实水平，再用学习能力补充，反而能留下好印象。

6. 常见问题速查表：绕开自动化路上的那些坑

6.1 写脚本总是莫名失败，可能是这些原因

自动化测试落地过程中我见到的典型问题，整理了一张速查表给大家：

这张表里每一项都有对应的深入文章可以展开，但核心思想是一致的：自动化测试脚本是代码，代码工程上犯过的错，自动化脚本一个都跑不掉。很多人把脚本当“临时脚本”写，不讲究工程规范，最终换来的就是无穷无尽的维护痛苦。

6.2 我面试时最反感的几种回答

作为一个面过很多候选人的面试官，我来说说最不耐烦的几种回答：

第一种是“当时是别人搭的框架，我只是写用例”。这个回答本身不是问题，问题是对框架内部一问三不知。你写用例至少要知道 fixture、conftest 怎么组织的吧，不然用例怎么跑起来的都不知道？

第二种是“这个我项目里用过，但具体细节记不清了”。如果连具体细节都记不清，要么是项目参与深度不足，要么是基础知识不够扎实。面试是展示最好的自己，不是展示“我好像用过”。

第三种是“这题我没遇到过，但我会百度”。学习能力确实重要，但完全靠百度解决问题，说明过去没有形成系统的方法论。面试官想听的不是“我能百度”，而是“我知道这个问题应该从哪些方向入手排查”。

当然，面试是双向的。候选人也要对面试官反问他关心的东西，比如团队的自动化程度、测试基础设置、技术栈选择。都坦诚一点，效率反而高很多。

6.3 给团队管理者的几条避坑建议

最后这条是写给负责招聘的同行们的。既然市场上“皮毛型选手”这么多，筛选效率就得靠流程设计来保证。我分享几条我们团队现在用的经验：

• 简历初筛加关键词场景：不止看技术栈关键词，还要看有没有“从零搭建”“跑挂率”“稳定性治理”“数据隔离”这类场景型描述。有这类字眼的简历，电话面试通过率明显高一些。
• 先电话面试深挖一个点：别急着约现场，电话里花二十分钟深挖一个项目经历，基本就能判断水平了。重点问“为什么选这个方案”“遇到什么问题”“怎么解决”，这比任何笔试都高效。
• 安排一个动手测试：给候选人发一个小的代码任务，比如“写一个接口自动化脚本，连接我们的 mock 服务”，两小时内交回来。这个环节能筛掉至少四成简历好看但实际动手能力弱的人。
• 关注学习能力而不是知识面：知识面可以靠积累补，学习能力才是决定一个人能不能持续成长的关键。一个不懂 Playwright 但能讲清楚 Selenium 底层原理的候选人，比一个背了很多工具名但说不清原理的人值得培养得多。

7. 写在最后：把自动化的“皮毛”长成真正的铠甲

面试结束以后我一直在想一个事：为什么“只会皮毛”的人敢要20K？后来我想明白了，是因为他们自己也不知道20K的自动化到底应该是什么样。他们看到市场上自动化测试的火爆，看到培训班的海报写着“三个月转行自动化测试月薪20K”，就觉得自己学了几个月差不多到了。这种认知错位，不能全怪个人，行业信息不透明才是根源。

所以这篇文章真正的目的不是吐槽任何人，而是把20K这档自动化的能力边界尽量清晰地画出来。对还在观望的同学，我希望你看完能知道自己在哪一层、缺什么、往哪补。对已经是团队骨干的同学，我希望这份能力地图能帮你更准确地评估自己和团队成员的状态。

我个人在这么多年的面试和带团队过程中的体会是：自动化测试的能力成长，本质上就是工程素养的成长。你去认真搭一个框架、解决一次稳定性问题、读一遍 pytest 源码，比看十个教学视频都有用。把一件事做深，才会发现它背后的体系有多大，也只有这样，你开口谈薪资的时候，才能理直气壮。