尧图网站建设 
很多同学在准备自动化测试时都会遇到同一个尴尬教程看了一大堆Selenium 能跑通 DemoPostman 的接口也能调通但一旦回到真实项目还是不知道从哪下手。领导问“自动化测试覆盖率多少”你只能回答“脚本能跑”脚本跑挂了你不仅不知道日志怎么看还可能被“非预期弹窗”活活折磨一整天。这篇内容不是把工具罗列一遍完事而是想给你一条真正能落地的路径从接口自动化到 Web UI 自动化再到移动端和 AI 辅助测试最后落到框架设计和项目实战。文章里会给出完整可运行的代码示例、选型对比、常见问题排查思路也会说清楚哪些地方容易踩坑。我的核心判断是零基础入门自动化测试第一优先级是接口自动化而不是一上来就死磕 Selenium这背后的原因后面会详细展开。1. 为什么自动化测试总在“学会后又不会了”先聊一个现象。很多人学自动化测试的顺序是先学 Python 基础再学 Selenium然后试着写“打开浏览器、输入账号密码、点击登录”的脚本。学的时候很爽觉得自动化不过如此。到了真实项目里发现元素定位不稳定、测试数据要天天改、用例之间互相依赖、跑一次要十几分钟、CI 里还总是莫名其妙挂掉。于是一边改脚本一边怀疑人生。这个问题的根源不在工具而在缺少一个“工程化”的视角。自动化测试不是“把手工用例翻译成代码”它是一项需要控制成本、保证稳定、持续集成的工程活动。真实项目里一个用例的价值不只是它是否能跑过而是它是否能在每次代码变更后给你可信的反馈。为了做到这一点你需要考虑测试分层哪些用例放在接口层哪些放在 UI 层。数据准备用例执行前怎么构造数据执行后怎么清理。等待策略怎样避免固定 sleep 带来的不稳定。报告与日志失败时能不能直接定位到是前端问题、后端问题还是测试脚本问题。环境与权限测试环境、预发布环境、生产环境的配置如何隔离。换句话说你缺的不是“更多工具”而是一套能回答“为什么测、测什么、怎么稳定地测”的方法。这也很自然地引出了文章的第一个建议不要“一套工具打天下”要先做分层再选技术最后再写代码。下面的章节会按这个逻辑展开。2. 自动化测试技术全景先选型再学习自动化测试这个领域最让人觉得“学不完”的原因是技术栈实在太多。这里我们先把主流技术做一个分类方便你建立全局认知。测试层典型工具/框架适合场景学习优先级接口测试Postman、curl、Python requests、pytest、Java RestAssured后端接口回归、业务流程校验、系统间联调高单元测试JUnit、pytest、TestNG代码级逻辑校验中Web UI 测试Selenium、Playwright、Cypress关键端到端流程、表单交互、页面跳转中高移动端测试Appium、AirtestAndroid/iOS App 自动化中性能/协议级JMeter、Locust、gRPC/WebSocket 测试性能基准、容量评估可选硬件/车载/特定域CApl、UDS、示波器自动化汽车电子、嵌入式测试专项岗如果只看热度自动化测试相关搜索词里“接口自动化测试框架怎么搭建”“Selenium 自动化测试框架”“Python 自动化测试”“Appium”“Airtest”是常年热门。这说明多数人在自学时还是会从接口和 Web UI 入手这是有道理的。需要特别说明的是“接口测试优先”。理由有三个接口测试反馈速度快单次执行时间通常在秒级比 UI 脚本稳定得多。接口是系统稳定性的核心后端一次改动影响多个接口接口用例能有效兜底。接口测试对前端页面依赖低只要接口设计合理就算 UI 没开发完也能先跑。当然这不意味着 UI 自动化不重要。像购物车提交、登录注册这类端到端流程UI 自动化仍然是最终验证用户体感的手段。只不过它应该放在接口测试之后而不是用来“入门”。还有一类最近很热的“AI 自动化测试”比如用大模型生成用例、用 Codex Agent 辅助写脚本、用 Playwright 的录制与跟踪能力降低写代码成本。我的观点是AI 可以提效但不能替代你对业务逻辑和技术的判断。后面专门有一章来讲。3. 零基础环境准备与前置技能在写第一行测试代码之前先把环境搭起来。这里以 Python 为例因为它是目前自动化测试生态最友好的语言。你不需要把 Python 学得很深能写函数、能导入包、能看懂异常就够用了。3.1 安装 Python 与虚拟环境建议安装 Python 3.9 以上版本。具体版本以你电脑上能装到的稳定版为准不需要追求最新。为了避免项目之间的依赖冲突强烈建议使用虚拟环境。# Windows PowerShell python -m venv venv venv\Scripts\activate # Linux / macOS python3 -m venv venv source venv/bin/activate激活后命令行前缀会出现(venv)说明你在虚拟环境里。3.2 安装接口测试与 UI 测试依赖接口测试基础依赖主要是requests和pytest。UI 测试再安装selenium以及用于管理浏览器驱动的webdriver-manager。pip install requests pytest selenium webdriver-manager也可以把依赖写入requirements.txt方便以后重建环境requests2.31.0 pytest7.4.0 selenium4.15.0 webdriver-manager4.0.1注意版本号不要照抄具体以你安装时最新稳定版为准。webdriver-manager不是必须的但它能自动下载匹配的浏览器驱动省去手动配置 ChromeDriver 的麻烦特别适合入门阶段。3.3 接口调试工具代码写之前先用 Postman 或 Apifox 把接口调通确认请求方式、请求头、请求体和返回结构。这样做的好处是你先把业务规则摸清楚了再写自动化用例时就能把精力放在“断言什么”而不是“接口怎么调”。Postman 还有一个用处调试完的集合可以通过 Newman 在命令行里跑。这对于快速验证一组手工整理的回归用例很方便但对复杂断言和前置数据处理还是建议用 pytest 这类代码框架。3.4 项目目录规划从第一天开始就别把所有脚本堆在一个文件里。一个最小但可扩展的接口测试项目建议这样组织project/ ├── config/ │ └── config.yaml ├── testcases/ │ └── test_login.py ├── common/ │ ├── http_client.py │ └── read_config.py ├── data/ │ └── login_cases.json └── requirements.txt这个结构不复杂但已经体现了“配置分离、用例分离、公共方法分离”的思路。真实项目的框架可以在此基础上扩展。4. 接口自动化测试入门从最小请求到可维护用例接口自动化是性价比最高的一环所以我们先从这里开始。下面会用一个类似“登录接口”的示例带你走完整个最小闭环。4.1 用 requests 发送第一个接口请求先写一个最简单的脚本请求一个公开接口并打印返回内容。这里你可以把它替换成自己项目的接口地址。# test_first_request.py import requests url https://httpbin.org/get resp requests.get(url, timeout5) print(resp.status_code) print(resp.json())在命令行执行python test_first_request.py如果看到类似200和 JSON 输出说明依赖安装正常请求链路通了。这里重点是理解requests的返回对象resp.status_code是状态码resp.json()可以把 JSON 响应转成字典resp.text是原始文本。后续所有断言都基于这些字段。4.2 用 pytest 组织第一条用例直接写脚本不是自动化测试因为缺少断言、用例组织和报告。我们把刚才的请求改成 pytest 用例# testcases/test_api_demo.py import requests def test_get_request_returns_200(): resp requests.get(https://httpbin.org/get, timeout5) assert resp.status_code 200 assert resp.headers.get(Content-Type) is not None执行pytest -v testcases/test_api_demo.py看到PASSED就说明用例通过。如果断言失败pytest 会打印出期望值和实际值这是定位问题最直接的依据。对于登录类接口通常还需要传递 Header、Body 和 Cookie。这里给一个带请求头和 JSON Body 的示例# testcases/test_login.py import requests def test_login_success(): url https://your-server/api/login payload {username: demo, password: 123456} headers {Content-Type: application/json} resp requests.post(url, jsonpayload, headersheaders, timeout5) assert resp.status_code 200 assert resp.json()[code] 0 assert resp.json()[data][token] ! 注意上面的接口地址和返回结构是演示用的你要换成自己项目真实的结构。在实际项目中请求头里的Content-Type、Authorization一般从配置文件或公共方法里读取不会每个用例都写一遍。4.3 统一管理 Base URL、登录态和公共方法如果每个用例都写一遍requests.post维护成本会快速上升。更常见的做法是在conftest.py里定义公共 fixture统一处理请求地址、会话保持和登录 token。下面是一个最小示例# testcases/conftest.py import pytest import requests BASE_URL https://your-server pytest.fixture(scopesession) def base_url(): return BASE_URL pytest.fixture(scopesession) def session(): s requests.Session() # 如果有登录接口在这里先拿到 token 并放进 session headers resp s.post( f{BASE_URL}/api/login, json{username: demo, password: 123456}, timeout5, ) token resp.json()[data][token] s.headers.update({Authorization: fBearer {token}}) return s pytest.fixture() def client(session, base_url): # 简单封装让用例不直接依赖 requests def do_request(method, path, **kwargs): return session.request(method, f{base_url}{path}, **kwargs) return do_request这样用例可以简化为# testcases/test_user.py def test_get_user_info(client): resp client(GET, /api/user/me) assert resp.status_code 200你可能会问登录失败怎么办这要看你的业务设计。如果登录是绝大多数接口的前置条件就应该用一个 session fixture 统一去拿 token并在报错时及时失败避免一堆用例因为登录失败而全部报错。如果某些接口是匿名可访问的就不要走登录态单独用一个无 token 的 client。4.4 数据驱动把测试数据从代码里拆出去真实项目的用例会非常多如果每个用例都写一个函数代码会膨胀且难以维护。常见的做法是用pytest.mark.parametrize做参数化或者把数据放到 JSON/YAML 文件里。参数化示例# testcases/test_login_param.py import pytest import requests cases [ ({username: demo, password: 123456}, 200), ({username: demo, password: wrong}, 401), ] pytest.mark.parametrize(payload,expected_status, cases) def test_login_cases(payload, expected_status): resp requests.post(https://your-server/api/login, jsonpayload, timeout5) assert resp.status_code expected_status如果需要把数据放到 JSON 文件可以用json.load读取后传参。示例# testcases/test_json_data.py import json import pytest import requests BASE_URL https://your-server def load_cases(): with open(data/login_cases.json, encodingutf-8) as f: return json.load(f) pytest.mark.parametrize(case, load_cases()) def test_login_from_json(case): resp requests.post( f{BASE_URL}/api/login, jsoncase[payload], timeout5, ) assert resp.status_code case[expected_status]data/login_cases.json示例[ { payload: {username: demo, password: 123456}, expected_status: 200 }, { payload: {username: demo, password: wrong}, expected_status: 401 } ]这样的好处是测试数据修改不需要改代码非测试人员也能维护一部分用例数据。但也要注意数据驱动不是越多越好如果每个用例的业务逻辑完全不同硬塞进同一个表格只会让可读性变差。4.5 接口测试中容易忽视的坑接口自动化看起来简单但真实项目会遇到几个比较普遍的问题断言做得太浅只校验状态码为 200不校验返回字段内容结果接口返回了错误文案也能通过。依赖测试顺序用例 A 给用例 B 造数据一旦 A 失败B 全挂。建议尽量让用例独立数据通过前置接口动态构造。没有超时设置接口长时间无响应导致用例卡死。用timeout5这种显式超时。测试数据污染登录、下单、注册类用例反复写同一批数据导致第二次执行失败。想办法在用例前置里创建唯一数据或者执行后清理。忽略鉴权过期token 有效期短接口用例跑着跑着突然 401。可以在 session fixture 里根据返回码自动重新登录。这些坑看起来很小但正是它们决定了你的自动化测试“能不能真正跑在 CI 里”。5. Web UI 自动化测试Selenium 还是 Playwright接口测试能覆盖业务逻辑但覆盖不了页面交互、前端渲染和端到端流程。所以第二个必学方向是 Web UI 自动化。5.1 选型对比现在最主流的选择是 Selenium 和 Playwright。两者都能做浏览器自动化但使用体验有差异。维度SeleniumPlaywright语言支持Java、Python、JS 等Java、Python、JS、.NET元素定位稳定资料多稳定API 更现代自动等待需要写得比较细内置自动等待相对友好浏览器支持Chrome、Firefox、Safari 等Chrome、Firefox、Safari、Edge录制工具Selenium IDEPlaywright Codegen对新手友好度中中上生态成熟度极高快速上升如果你的公司已经有大量 Selenium 脚本那继续用 Selenium 没有错。如果你是从零开始搭新项目Playwright 很值得尝试因为它在等待策略和调试体验上做得好不少。不过考虑到 Selenium 仍是很多教程和招聘 JD 里的关键词本文会以 Selenium 为例讲解核心思路然后你也够很容易迁移到 Playwright。5.2 第一个 Selenium 脚本登录与断言下面是一个用 Selenium 打开登录页面、输入账号密码并断言登录成功的示例。这里只演示结构实际页面元素需要按你的项目调整。# test_web_login.py from selenium.webdriver import Chrome from selenium.webdriver.chrome.service import Service from webdriver_manager.chrome import ChromeDriverManager from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def test_login(): driver Chrome(serviceService(ChromeDriverManager().install())) driver.maximize_window() driver.get(https://your-app/login) driver.find_element(By.ID, username).send_keys(demo) driver.find_element(By.ID, password).send_keys(123456) driver.find_element(By.ID, loginBtn).click() # 等待跳转到首页或出现某个登录后的元素 WebDriverWait(driver, 10).until( EC.url_contains(home) ) assert home in driver.current_url driver.quit()这里最关键的是WebDriverWait代替time.sleep。刚开始写 UI 脚本的人很容易在点击之后直接sleep(3)但这不是稳定方案。网络慢的时候 3 秒不够快的时候又白白浪费时间。显式等待能等到元素出现或跳转完成才继续执行稳定性和效率都能兼顾。5.3 如何处理非预期弹窗“自动化测试非预期弹窗导致失败”是很多人都会遇到的现象。所谓非预期弹窗就是你的脚本本来在按流程操作突然当前页面冒出一个系统提示、公告、广告、版本升级弹窗或者一个居中的 modal 遮罩导致下一个元素点不到脚本崩溃。处理这类问题有两个层次1. 可以预见的弹窗如果弹窗是固定业务规则产生的比如“是否确认提交”“需要更新版本”它们应该被当成正常业务元素来处理。在操作前先判断弹窗有没有出现出现了就按规则处理没出现就跳过。这很安全因为弹窗的内容和触发条件是确定的。# utils/dialog_utils.py from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def close_confirm_dialog_if_present(driver, timeout5): try: WebDriverWait(driver, timeout).until( EC.visibility_of_element_located((By.XPATH, //div[contains(class,modal)]//button[text()确认])) ) driver.find_element(By.XPATH, //div[contains(class,modal)]//button[text()确认]).click() except Exception: # 没有弹窗正常继续 pass2. 完全不可控的异常弹窗比如页面里突然出现一个 API 通知遮罩或者浏览器原生 alert。原生 alert 可以用 Selenium 的 alert 接口处理# utils/dialog_utils.py from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def accept_browser_alert_if_present(driver, timeout3): try: WebDriverWait(driver, timeout).until(EC.alert_is_present()) alert driver.switch_to.alert alert_text alert.text print(f处理弹窗{alert_text}) alert.accept() except Exception: pass对于使用 div 模拟的页面遮罩处理思路是先定位到弹窗容器再点击关闭按钮。不要无条件地点击页面右下角固定位置因为不同弹窗结构不一样。更稳妥的做法是维护一个“已知弹窗关闭按钮”的定位列表逐个尝试# utils/dialog_utils.py from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def close_cover_dialog_if_present(driver, timeout3): close_buttons [ (By.CLASS_NAME, close), (By.XPATH, //div[contains(class,modal)]//button[contains(class,close)]), (By.XPATH, //div[contains(class,popup)]//span[classicon-close]), ] for by, locator in close_buttons: try: element WebDriverWait(driver, 1).until( EC.element_to_be_clickable((by, locator)) ) element.click() return except Exception: continue需要记住一个原则不要为了“通过”而盲目点击弹窗。如果弹窗是业务提示点击关闭或确定可能改变页面状态。要在处理函数里输出日志并保证只在用例前置步骤中调用而不是在每个元素定位前都去点一遍。否则可能把一个正常业务弹窗误关导致后续断言失败。5.4 元素定位不稳定的通用解法UI 自动化 80% 的失败都跟元素定位有关。常见的有页面渲染慢元素已经出现在 DOM 里但还不能点击。动态 id 或动态 class每次刷新都变。iframe 嵌套直接定位不到内部元素。页面触发了接口请求点击后按钮短暂 loading无法重复点击。对应办法优先用稳定的业务属性如id、name、># appium_demo.py from appium import webdriver desired_caps { platformName: Android, platformVersion: 10, deviceName: emulator-5554, app: /path/to/your-app.apk, appPackage: com.example.app, appActivity: .MainActivity, noReset: True, } driver webdriver.Remote(http://127.0.0.1:4723/wd/hub, desired_caps) driver.find_element_by_id(com.example.app:id/username).send_keys(demo) driver.find_element_by_id(com.example.app:id/password).send_keys(123456) driver.find_element_by_id(com.example.app:id/login).click() driver.quit()这里要特别说明Appium 新版本对驱动要求更严格不同的appium版本可能需要安装对应的 driver。如果你按上面的代码跑不通优先检查自动化测试工具链版本而不是纠结语法。Airtest 的代码则更接近“看图点击”。官方提供 AirtestIDE录制一些简单流程很快。一个基础示例# airtest_demo.py from airtest.core.api import * connect_device(Android:///) start_app(com.example.app) touch(Template(res/login_button.png, record_pos(0.5, 0.6))) text(demo) text(123456) touch(Template(res/confirm.png, record_pos(0.5, 0.8)))Airtest 的好处是即使没有控件信息也能通过图像识别点击。坏处是图像匹配受分辨率和 UI 改动影响截图一旦变化脚本可能需要重新录制。所以如果你的 App 控件层级完整优先用控件定位只有控件很难取到时再考虑图像识别。7. 自动化测试框架设计与工程化从“会写脚本”到“能搭框架”是中级测试开发的分水岭。这一章会把框架设计的核心讲清楚。7.1 Page Object Model让 UI 用例可维护Page Object Model简称 POM是 Web UI 自动化最常用的设计模式。核心思想是每一个页面用一个类来管理页面上的元素定位和操作封装在类里用例层只关心业务步骤不关心具体元素。举个例子登录页面可以抽象成LoginPage# pages/login_page.py from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC class LoginPage: def __init__(self, driver): self.driver driver self.username_input (By.ID, username) self.password_input (By.ID, password) self.login_button (By.ID, loginBtn) def open(self, url): self.driver.get(url) def login(self, username, password): WebDriverWait(self.driver, 10).until( EC.visibility_of_element_located(self.username_input) ) self.driver.find_element(*self.username_input).send_keys(username) self.driver.find_element(*self.password_input).send_keys(password) self.driver.find_element(*self.login_button).click()用例层就可以写成# testcases/test_login_page.py from pages.login_page import LoginPage def test_login_success(driver): login_page LoginPage(driver) login_page.open(https://your-app/login) login_page.login(demo, 123456) assert home in driver.current_url这样的好处是如果 UI 重构导致元素定位变了你只需要改LoginPage里的定位符不需要改用例。真实项目中一个页面会有很多元素POM 能让脚本长期可维护。7.2 配置分离与 Fixture除了页面对象框架还要统一管理浏览器启动、配置读取、失败截图和日志。在 pytest 里我们可以通过conftest.py定义全局 fixture# testcases/conftest.py import os import time import pytest from selenium.webdriver import Chrome from selenium.webdriver.chrome.service import Service from webdriver_manager.chrome import ChromeDriverManager pytest.fixture() def driver(): d Chrome(serviceService(ChromeDriverManager().install())) d.maximize_window() yield d # 失败时截图 if d: d.quit()配合pytest的钩子可以在用例失败时自动截图# conftest.py 追加部分 pytest.hookimpl(tryfirstTrue, hookwrapperTrue) def pytest_runtest_makereport(item, call): outcome yield report outcome.get_result() if report.when call and report.failed: driver item.funcargs.get(driver) if driver: file_name fscreenshots/{item.name}_{int(time.time())}.png driver.save_screenshot(file_name) print(f失败截图已保存: {file_name})截图命名加上用例名和时间戳能帮你快速定位失败现场。7.3 持续集成让自动化测试自动跑自动化测试真正的价值在持续集成里。现在主流的 CI 工具有 Jenkins、GitLab CI、GitHub Actions 等。思路是代码提交后自动拉代码、执行测试、生成报告、通知结果。以 GitLab CI 为例一个极简的.gitlab-ci.yml片段stages: - test api-test: stage: test script: - python -m pip install -r requirements.txt - pytest testcases --htmlreport.html artifacts: paths: - report.html only: - merge_requests在本地执行时你也可以用 pytest 的--html参数生成 HTML 报告pytest testcases --htmlreport.html --self-contained-html有了报告团队就能看到每个版本的通过率和失败用例清单。这也意味着你的自动化测试要足够稳定宁可少跑几个高价值的用例也不要让一堆随机失败的数字出现在报告里。7.4 数据管理和环境隔离工程化还有一个重点测试数据不应写死在代码里。建议把环境相关的配置抽到config/config.yaml或环境变量中。# config/config.yaml env: test base_url: https://test-server admin: username: admin password: ${ADMIN_PASSWORD}读取配置时敏感信息从环境变量取不要把明文密码提交到代码仓库。这个习惯越早养成越好很多安全问题都出在测试代码把数据库密码、云厂商密钥写死。8. AI 自动化测试新机会与正确的期待这两年“AI 自动化测试”是很热的话题。各类工具都在尝试把大模型能力接入测试链路。常见的落地方向有AI 生成测试用例根据需求和页面控件生成基础用例。AI 辅助定位元素通过语义理解找到更稳定的选择器。AI 分析失败原因读取日志和截图判断是脚本问题还是业务 Bug。Codex Agent 这类编程助手直接在终端里根据自然语言生成测试代码。这些能力确实能减少重复劳动。比如 Playwright 的 Codegen 可以帮你录制操作生成脚本大模型可以帮你在不了解某个 API 时快速写出一段可读的测试代码。但也要认清边界AI 生成脚本需要人工审查尤其是断言和测试数据部分。如果 AI 按照错误的期望生成了一个“永远通过的用例”那它比不写还糟因为它给了你虚假的安全感。如果你想尝试用大模型辅助生成接口用例一个可参考的思路是把接口文档和一条示例用例作为上下文让模型生成更多边界用例然后人工筛选和校验。这里不针对特定厂商只给一个最小调用方式具体接口地址和密钥由你根据公司授权使用# ai_helper.py import requests def generate_test_cases(api_doc, examples): response requests.post( http://your-llm-endpoint/v1/chat/completions, headers{Authorization: Bearer YOUR_TOKEN}, json{ model: your-model, messages: [ {role: system, content: 你是资深测试工程师擅长根据接口文档生成边界测试用例。}, {role: user, content: f接口文档{api_doc}\n示例用例{examples}} ], temperature: 0.2, }, timeout30, ) return response.json()这个示例的重点是调用大模型接口时一定要把密钥放在服务端环境变量里不要提交到前端或代码库。同时AI 返回的用例只作为初稿需要执行和校验之后再进入用例库。我的判断是AI 会改变自动化测试的编写方式但不会改变测试的基本规律。业务理解、风险分析、断言设计、稳定性治理仍然是核心能力。与其焦虑“AI 会不会替代测试”不如先掌握好基础框架再用 AI 提效。9. 常见问题与排查思路这里把自动化测试实践中常见的问题整理成一个排查表方便你遇到问题时快速定位。问题现象可能原因排查方式解决方案接口用例随机失败测试数据冲突查看失败前后是否创建了同一登录账号每个用例使用唯一数据执行结束清理接口返回 401token 过期查看响应头和日志在会话中按状态码自动重新登录元素定位不到页面未加载完成打印当前 page_source使用显式等待等待元素可点击元素定位不稳定使用了动态 id观察多次运行时的 html改用稳定属性或相对定位非预期弹窗导致点击失败页面出现覆盖层通过异常信息定位卡住的元素封装弹窗处理工具记录弹窗日志浏览器驱动版本不匹配Chrome 自动更新查看 Selenium 报错中的版本信息用 webdriver-manager 自动下载驱动用例执行时间过长等待时间过多查看 pytest 耗时统计减少 sleep使用显式等待和并发执行环境变量读取失败密钥未设置打印 os.environ 中的 key在 CI 流水线中配置 Secret 变量用例之间有相互依赖上一个用例失败导致脏数据单独执行下一个用例看是否失败每个用例独立构造前置条件遇到问题先看日志再看截图最后再改脚本。不要一上来就盲目加大sleep那不是解决问题只是把问题往后拖。10. 零基础到项目实战的学习路线建议最后给想系统学习自动化测试的人一条可执行的路径而不是“从入门到放弃”。第一阶段接口自动化1 到 2 周学会用 Postman 调通接口理解请求方法、Header、Body、Cookie。学 Python 基础重点是函数、字典、列表、异常处理。学 requests 和 pytest写出至少 20 条接口用例。掌握参数化、fixture、base_url 管理、token 管理。第二阶段Web UI 自动化2 到 3 周学 Selenium 或 Playwright跑通一个真实项目的登录和查询流程。练习元素定位的多种方式理解显式等待。完成购物车添加商品、下单这类端到端流程重点处理弹窗和异步加载。引入 Page Object Model把页面操作封装成类。第三阶段移动端自动化可选1 到 2 周用 Appium 连接模拟器跑通安装、启动、登录流程。如果是游戏类项目学习 Airtest 的录制和图像识别。第四阶段框架设计与持续集成1 到 2 周搭建一个包含配置、公共方法、用例模块、数据文件、报告的 Python 测试项目。在 Jenkins 或 GitLab CI 上接入执行任务让代码提交后自动跑测试。学会看报告分析失败用例清理不稳定因素。第五阶段项目实战与总结持续选一个真实项目用接口 UI 结合的方式覆盖核心流程。把每次踩坑和解决方式记录成文档形成你自己的知识库。参与团队测试评审学会从业务风险角度挑选自动化用例。整个过程中最值得警惕的是“只囤教程不写代码”。很多人收藏了整套视频却迟迟没有在本地跑通一条用例。自动化测试是实践科学一个简单的接口用例比你收藏十篇框架文章都有用。希望这篇文章能帮你把散落的知识串起来。如果你正在准备面试或者刚接手自动化测试任务可以先从本文的接口示例开始在自己的电脑上跑通一遍再逐步扩展到 UI 和移动端。记住一个原则稳定的、有价值的自动化测试永远比花哨的、数量庞大的脚本更重要。 从接口到UI：零基础自动化测试落地实践指南
很多同学在准备自动化测试时都会遇到同一个尴尬教程看了一大堆Selenium 能跑通 DemoPostman 的接口也能调通但一旦回到真实项目还是不知道从哪下手。领导问“自动化测试覆盖率多少”你只能回答“脚本能跑”脚本跑挂了你不仅不知道日志怎么看还可能被“非预期弹窗”活活折磨一整天。这篇内容不是把工具罗列一遍完事而是想给你一条真正能落地的路径从接口自动化到 Web UI 自动化再到移动端和 AI 辅助测试最后落到框架设计和项目实战。文章里会给出完整可运行的代码示例、选型对比、常见问题排查思路也会说清楚哪些地方容易踩坑。我的核心判断是零基础入门自动化测试第一优先级是接口自动化而不是一上来就死磕 Selenium这背后的原因后面会详细展开。1. 为什么自动化测试总在“学会后又不会了”先聊一个现象。很多人学自动化测试的顺序是先学 Python 基础再学 Selenium然后试着写“打开浏览器、输入账号密码、点击登录”的脚本。学的时候很爽觉得自动化不过如此。到了真实项目里发现元素定位不稳定、测试数据要天天改、用例之间互相依赖、跑一次要十几分钟、CI 里还总是莫名其妙挂掉。于是一边改脚本一边怀疑人生。这个问题的根源不在工具而在缺少一个“工程化”的视角。自动化测试不是“把手工用例翻译成代码”它是一项需要控制成本、保证稳定、持续集成的工程活动。真实项目里一个用例的价值不只是它是否能跑过而是它是否能在每次代码变更后给你可信的反馈。为了做到这一点你需要考虑测试分层哪些用例放在接口层哪些放在 UI 层。数据准备用例执行前怎么构造数据执行后怎么清理。等待策略怎样避免固定 sleep 带来的不稳定。报告与日志失败时能不能直接定位到是前端问题、后端问题还是测试脚本问题。环境与权限测试环境、预发布环境、生产环境的配置如何隔离。换句话说你缺的不是“更多工具”而是一套能回答“为什么测、测什么、怎么稳定地测”的方法。这也很自然地引出了文章的第一个建议不要“一套工具打天下”要先做分层再选技术最后再写代码。下面的章节会按这个逻辑展开。2. 自动化测试技术全景先选型再学习自动化测试这个领域最让人觉得“学不完”的原因是技术栈实在太多。这里我们先把主流技术做一个分类方便你建立全局认知。测试层典型工具/框架适合场景学习优先级接口测试Postman、curl、Python requests、pytest、Java RestAssured后端接口回归、业务流程校验、系统间联调高单元测试JUnit、pytest、TestNG代码级逻辑校验中Web UI 测试Selenium、Playwright、Cypress关键端到端流程、表单交互、页面跳转中高移动端测试Appium、AirtestAndroid/iOS App 自动化中性能/协议级JMeter、Locust、gRPC/WebSocket 测试性能基准、容量评估可选硬件/车载/特定域CApl、UDS、示波器自动化汽车电子、嵌入式测试专项岗如果只看热度自动化测试相关搜索词里“接口自动化测试框架怎么搭建”“Selenium 自动化测试框架”“Python 自动化测试”“Appium”“Airtest”是常年热门。这说明多数人在自学时还是会从接口和 Web UI 入手这是有道理的。需要特别说明的是“接口测试优先”。理由有三个接口测试反馈速度快单次执行时间通常在秒级比 UI 脚本稳定得多。接口是系统稳定性的核心后端一次改动影响多个接口接口用例能有效兜底。接口测试对前端页面依赖低只要接口设计合理就算 UI 没开发完也能先跑。当然这不意味着 UI 自动化不重要。像购物车提交、登录注册这类端到端流程UI 自动化仍然是最终验证用户体感的手段。只不过它应该放在接口测试之后而不是用来“入门”。还有一类最近很热的“AI 自动化测试”比如用大模型生成用例、用 Codex Agent 辅助写脚本、用 Playwright 的录制与跟踪能力降低写代码成本。我的观点是AI 可以提效但不能替代你对业务逻辑和技术的判断。后面专门有一章来讲。3. 零基础环境准备与前置技能在写第一行测试代码之前先把环境搭起来。这里以 Python 为例因为它是目前自动化测试生态最友好的语言。你不需要把 Python 学得很深能写函数、能导入包、能看懂异常就够用了。3.1 安装 Python 与虚拟环境建议安装 Python 3.9 以上版本。具体版本以你电脑上能装到的稳定版为准不需要追求最新。为了避免项目之间的依赖冲突强烈建议使用虚拟环境。# Windows PowerShell python -m venv venv venv\Scripts\activate # Linux / macOS python3 -m venv venv source venv/bin/activate激活后命令行前缀会出现(venv)说明你在虚拟环境里。3.2 安装接口测试与 UI 测试依赖接口测试基础依赖主要是requests和pytest。UI 测试再安装selenium以及用于管理浏览器驱动的webdriver-manager。pip install requests pytest selenium webdriver-manager也可以把依赖写入requirements.txt方便以后重建环境requests2.31.0 pytest7.4.0 selenium4.15.0 webdriver-manager4.0.1注意版本号不要照抄具体以你安装时最新稳定版为准。webdriver-manager不是必须的但它能自动下载匹配的浏览器驱动省去手动配置 ChromeDriver 的麻烦特别适合入门阶段。3.3 接口调试工具代码写之前先用 Postman 或 Apifox 把接口调通确认请求方式、请求头、请求体和返回结构。这样做的好处是你先把业务规则摸清楚了再写自动化用例时就能把精力放在“断言什么”而不是“接口怎么调”。Postman 还有一个用处调试完的集合可以通过 Newman 在命令行里跑。这对于快速验证一组手工整理的回归用例很方便但对复杂断言和前置数据处理还是建议用 pytest 这类代码框架。3.4 项目目录规划从第一天开始就别把所有脚本堆在一个文件里。一个最小但可扩展的接口测试项目建议这样组织project/ ├── config/ │ └── config.yaml ├── testcases/ │ └── test_login.py ├── common/ │ ├── http_client.py │ └── read_config.py ├── data/ │ └── login_cases.json └── requirements.txt这个结构不复杂但已经体现了“配置分离、用例分离、公共方法分离”的思路。真实项目的框架可以在此基础上扩展。4. 接口自动化测试入门从最小请求到可维护用例接口自动化是性价比最高的一环所以我们先从这里开始。下面会用一个类似“登录接口”的示例带你走完整个最小闭环。4.1 用 requests 发送第一个接口请求先写一个最简单的脚本请求一个公开接口并打印返回内容。这里你可以把它替换成自己项目的接口地址。# test_first_request.py import requests url https://httpbin.org/get resp requests.get(url, timeout5) print(resp.status_code) print(resp.json())在命令行执行python test_first_request.py如果看到类似200和 JSON 输出说明依赖安装正常请求链路通了。这里重点是理解requests的返回对象resp.status_code是状态码resp.json()可以把 JSON 响应转成字典resp.text是原始文本。后续所有断言都基于这些字段。4.2 用 pytest 组织第一条用例直接写脚本不是自动化测试因为缺少断言、用例组织和报告。我们把刚才的请求改成 pytest 用例# testcases/test_api_demo.py import requests def test_get_request_returns_200(): resp requests.get(https://httpbin.org/get, timeout5) assert resp.status_code 200 assert resp.headers.get(Content-Type) is not None执行pytest -v testcases/test_api_demo.py看到PASSED就说明用例通过。如果断言失败pytest 会打印出期望值和实际值这是定位问题最直接的依据。对于登录类接口通常还需要传递 Header、Body 和 Cookie。这里给一个带请求头和 JSON Body 的示例# testcases/test_login.py import requests def test_login_success(): url https://your-server/api/login payload {username: demo, password: 123456} headers {Content-Type: application/json} resp requests.post(url, jsonpayload, headersheaders, timeout5) assert resp.status_code 200 assert resp.json()[code] 0 assert resp.json()[data][token] ! 注意上面的接口地址和返回结构是演示用的你要换成自己项目真实的结构。在实际项目中请求头里的Content-Type、Authorization一般从配置文件或公共方法里读取不会每个用例都写一遍。4.3 统一管理 Base URL、登录态和公共方法如果每个用例都写一遍requests.post维护成本会快速上升。更常见的做法是在conftest.py里定义公共 fixture统一处理请求地址、会话保持和登录 token。下面是一个最小示例# testcases/conftest.py import pytest import requests BASE_URL https://your-server pytest.fixture(scopesession) def base_url(): return BASE_URL pytest.fixture(scopesession) def session(): s requests.Session() # 如果有登录接口在这里先拿到 token 并放进 session headers resp s.post( f{BASE_URL}/api/login, json{username: demo, password: 123456}, timeout5, ) token resp.json()[data][token] s.headers.update({Authorization: fBearer {token}}) return s pytest.fixture() def client(session, base_url): # 简单封装让用例不直接依赖 requests def do_request(method, path, **kwargs): return session.request(method, f{base_url}{path}, **kwargs) return do_request这样用例可以简化为# testcases/test_user.py def test_get_user_info(client): resp client(GET, /api/user/me) assert resp.status_code 200你可能会问登录失败怎么办这要看你的业务设计。如果登录是绝大多数接口的前置条件就应该用一个 session fixture 统一去拿 token并在报错时及时失败避免一堆用例因为登录失败而全部报错。如果某些接口是匿名可访问的就不要走登录态单独用一个无 token 的 client。4.4 数据驱动把测试数据从代码里拆出去真实项目的用例会非常多如果每个用例都写一个函数代码会膨胀且难以维护。常见的做法是用pytest.mark.parametrize做参数化或者把数据放到 JSON/YAML 文件里。参数化示例# testcases/test_login_param.py import pytest import requests cases [ ({username: demo, password: 123456}, 200), ({username: demo, password: wrong}, 401), ] pytest.mark.parametrize(payload,expected_status, cases) def test_login_cases(payload, expected_status): resp requests.post(https://your-server/api/login, jsonpayload, timeout5) assert resp.status_code expected_status如果需要把数据放到 JSON 文件可以用json.load读取后传参。示例# testcases/test_json_data.py import json import pytest import requests BASE_URL https://your-server def load_cases(): with open(data/login_cases.json, encodingutf-8) as f: return json.load(f) pytest.mark.parametrize(case, load_cases()) def test_login_from_json(case): resp requests.post( f{BASE_URL}/api/login, jsoncase[payload], timeout5, ) assert resp.status_code case[expected_status]data/login_cases.json示例[ { payload: {username: demo, password: 123456}, expected_status: 200 }, { payload: {username: demo, password: wrong}, expected_status: 401 } ]这样的好处是测试数据修改不需要改代码非测试人员也能维护一部分用例数据。但也要注意数据驱动不是越多越好如果每个用例的业务逻辑完全不同硬塞进同一个表格只会让可读性变差。4.5 接口测试中容易忽视的坑接口自动化看起来简单但真实项目会遇到几个比较普遍的问题断言做得太浅只校验状态码为 200不校验返回字段内容结果接口返回了错误文案也能通过。依赖测试顺序用例 A 给用例 B 造数据一旦 A 失败B 全挂。建议尽量让用例独立数据通过前置接口动态构造。没有超时设置接口长时间无响应导致用例卡死。用timeout5这种显式超时。测试数据污染登录、下单、注册类用例反复写同一批数据导致第二次执行失败。想办法在用例前置里创建唯一数据或者执行后清理。忽略鉴权过期token 有效期短接口用例跑着跑着突然 401。可以在 session fixture 里根据返回码自动重新登录。这些坑看起来很小但正是它们决定了你的自动化测试“能不能真正跑在 CI 里”。5. Web UI 自动化测试Selenium 还是 Playwright接口测试能覆盖业务逻辑但覆盖不了页面交互、前端渲染和端到端流程。所以第二个必学方向是 Web UI 自动化。5.1 选型对比现在最主流的选择是 Selenium 和 Playwright。两者都能做浏览器自动化但使用体验有差异。维度SeleniumPlaywright语言支持Java、Python、JS 等Java、Python、JS、.NET元素定位稳定资料多稳定API 更现代自动等待需要写得比较细内置自动等待相对友好浏览器支持Chrome、Firefox、Safari 等Chrome、Firefox、Safari、Edge录制工具Selenium IDEPlaywright Codegen对新手友好度中中上生态成熟度极高快速上升如果你的公司已经有大量 Selenium 脚本那继续用 Selenium 没有错。如果你是从零开始搭新项目Playwright 很值得尝试因为它在等待策略和调试体验上做得好不少。不过考虑到 Selenium 仍是很多教程和招聘 JD 里的关键词本文会以 Selenium 为例讲解核心思路然后你也够很容易迁移到 Playwright。5.2 第一个 Selenium 脚本登录与断言下面是一个用 Selenium 打开登录页面、输入账号密码并断言登录成功的示例。这里只演示结构实际页面元素需要按你的项目调整。# test_web_login.py from selenium.webdriver import Chrome from selenium.webdriver.chrome.service import Service from webdriver_manager.chrome import ChromeDriverManager from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def test_login(): driver Chrome(serviceService(ChromeDriverManager().install())) driver.maximize_window() driver.get(https://your-app/login) driver.find_element(By.ID, username).send_keys(demo) driver.find_element(By.ID, password).send_keys(123456) driver.find_element(By.ID, loginBtn).click() # 等待跳转到首页或出现某个登录后的元素 WebDriverWait(driver, 10).until( EC.url_contains(home) ) assert home in driver.current_url driver.quit()这里最关键的是WebDriverWait代替time.sleep。刚开始写 UI 脚本的人很容易在点击之后直接sleep(3)但这不是稳定方案。网络慢的时候 3 秒不够快的时候又白白浪费时间。显式等待能等到元素出现或跳转完成才继续执行稳定性和效率都能兼顾。5.3 如何处理非预期弹窗“自动化测试非预期弹窗导致失败”是很多人都会遇到的现象。所谓非预期弹窗就是你的脚本本来在按流程操作突然当前页面冒出一个系统提示、公告、广告、版本升级弹窗或者一个居中的 modal 遮罩导致下一个元素点不到脚本崩溃。处理这类问题有两个层次1. 可以预见的弹窗如果弹窗是固定业务规则产生的比如“是否确认提交”“需要更新版本”它们应该被当成正常业务元素来处理。在操作前先判断弹窗有没有出现出现了就按规则处理没出现就跳过。这很安全因为弹窗的内容和触发条件是确定的。# utils/dialog_utils.py from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def close_confirm_dialog_if_present(driver, timeout5): try: WebDriverWait(driver, timeout).until( EC.visibility_of_element_located((By.XPATH, //div[contains(class,modal)]//button[text()确认])) ) driver.find_element(By.XPATH, //div[contains(class,modal)]//button[text()确认]).click() except Exception: # 没有弹窗正常继续 pass2. 完全不可控的异常弹窗比如页面里突然出现一个 API 通知遮罩或者浏览器原生 alert。原生 alert 可以用 Selenium 的 alert 接口处理# utils/dialog_utils.py from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def accept_browser_alert_if_present(driver, timeout3): try: WebDriverWait(driver, timeout).until(EC.alert_is_present()) alert driver.switch_to.alert alert_text alert.text print(f处理弹窗{alert_text}) alert.accept() except Exception: pass对于使用 div 模拟的页面遮罩处理思路是先定位到弹窗容器再点击关闭按钮。不要无条件地点击页面右下角固定位置因为不同弹窗结构不一样。更稳妥的做法是维护一个“已知弹窗关闭按钮”的定位列表逐个尝试# utils/dialog_utils.py from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def close_cover_dialog_if_present(driver, timeout3): close_buttons [ (By.CLASS_NAME, close), (By.XPATH, //div[contains(class,modal)]//button[contains(class,close)]), (By.XPATH, //div[contains(class,popup)]//span[classicon-close]), ] for by, locator in close_buttons: try: element WebDriverWait(driver, 1).until( EC.element_to_be_clickable((by, locator)) ) element.click() return except Exception: continue需要记住一个原则不要为了“通过”而盲目点击弹窗。如果弹窗是业务提示点击关闭或确定可能改变页面状态。要在处理函数里输出日志并保证只在用例前置步骤中调用而不是在每个元素定位前都去点一遍。否则可能把一个正常业务弹窗误关导致后续断言失败。5.4 元素定位不稳定的通用解法UI 自动化 80% 的失败都跟元素定位有关。常见的有页面渲染慢元素已经出现在 DOM 里但还不能点击。动态 id 或动态 class每次刷新都变。iframe 嵌套直接定位不到内部元素。页面触发了接口请求点击后按钮短暂 loading无法重复点击。对应办法优先用稳定的业务属性如id、name、># appium_demo.py from appium import webdriver desired_caps { platformName: Android, platformVersion: 10, deviceName: emulator-5554, app: /path/to/your-app.apk, appPackage: com.example.app, appActivity: .MainActivity, noReset: True, } driver webdriver.Remote(http://127.0.0.1:4723/wd/hub, desired_caps) driver.find_element_by_id(com.example.app:id/username).send_keys(demo) driver.find_element_by_id(com.example.app:id/password).send_keys(123456) driver.find_element_by_id(com.example.app:id/login).click() driver.quit()这里要特别说明Appium 新版本对驱动要求更严格不同的appium版本可能需要安装对应的 driver。如果你按上面的代码跑不通优先检查自动化测试工具链版本而不是纠结语法。Airtest 的代码则更接近“看图点击”。官方提供 AirtestIDE录制一些简单流程很快。一个基础示例# airtest_demo.py from airtest.core.api import * connect_device(Android:///) start_app(com.example.app) touch(Template(res/login_button.png, record_pos(0.5, 0.6))) text(demo) text(123456) touch(Template(res/confirm.png, record_pos(0.5, 0.8)))Airtest 的好处是即使没有控件信息也能通过图像识别点击。坏处是图像匹配受分辨率和 UI 改动影响截图一旦变化脚本可能需要重新录制。所以如果你的 App 控件层级完整优先用控件定位只有控件很难取到时再考虑图像识别。7. 自动化测试框架设计与工程化从“会写脚本”到“能搭框架”是中级测试开发的分水岭。这一章会把框架设计的核心讲清楚。7.1 Page Object Model让 UI 用例可维护Page Object Model简称 POM是 Web UI 自动化最常用的设计模式。核心思想是每一个页面用一个类来管理页面上的元素定位和操作封装在类里用例层只关心业务步骤不关心具体元素。举个例子登录页面可以抽象成LoginPage# pages/login_page.py from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC class LoginPage: def __init__(self, driver): self.driver driver self.username_input (By.ID, username) self.password_input (By.ID, password) self.login_button (By.ID, loginBtn) def open(self, url): self.driver.get(url) def login(self, username, password): WebDriverWait(self.driver, 10).until( EC.visibility_of_element_located(self.username_input) ) self.driver.find_element(*self.username_input).send_keys(username) self.driver.find_element(*self.password_input).send_keys(password) self.driver.find_element(*self.login_button).click()用例层就可以写成# testcases/test_login_page.py from pages.login_page import LoginPage def test_login_success(driver): login_page LoginPage(driver) login_page.open(https://your-app/login) login_page.login(demo, 123456) assert home in driver.current_url这样的好处是如果 UI 重构导致元素定位变了你只需要改LoginPage里的定位符不需要改用例。真实项目中一个页面会有很多元素POM 能让脚本长期可维护。7.2 配置分离与 Fixture除了页面对象框架还要统一管理浏览器启动、配置读取、失败截图和日志。在 pytest 里我们可以通过conftest.py定义全局 fixture# testcases/conftest.py import os import time import pytest from selenium.webdriver import Chrome from selenium.webdriver.chrome.service import Service from webdriver_manager.chrome import ChromeDriverManager pytest.fixture() def driver(): d Chrome(serviceService(ChromeDriverManager().install())) d.maximize_window() yield d # 失败时截图 if d: d.quit()配合pytest的钩子可以在用例失败时自动截图# conftest.py 追加部分 pytest.hookimpl(tryfirstTrue, hookwrapperTrue) def pytest_runtest_makereport(item, call): outcome yield report outcome.get_result() if report.when call and report.failed: driver item.funcargs.get(driver) if driver: file_name fscreenshots/{item.name}_{int(time.time())}.png driver.save_screenshot(file_name) print(f失败截图已保存: {file_name})截图命名加上用例名和时间戳能帮你快速定位失败现场。7.3 持续集成让自动化测试自动跑自动化测试真正的价值在持续集成里。现在主流的 CI 工具有 Jenkins、GitLab CI、GitHub Actions 等。思路是代码提交后自动拉代码、执行测试、生成报告、通知结果。以 GitLab CI 为例一个极简的.gitlab-ci.yml片段stages: - test api-test: stage: test script: - python -m pip install -r requirements.txt - pytest testcases --htmlreport.html artifacts: paths: - report.html only: - merge_requests在本地执行时你也可以用 pytest 的--html参数生成 HTML 报告pytest testcases --htmlreport.html --self-contained-html有了报告团队就能看到每个版本的通过率和失败用例清单。这也意味着你的自动化测试要足够稳定宁可少跑几个高价值的用例也不要让一堆随机失败的数字出现在报告里。7.4 数据管理和环境隔离工程化还有一个重点测试数据不应写死在代码里。建议把环境相关的配置抽到config/config.yaml或环境变量中。# config/config.yaml env: test base_url: https://test-server admin: username: admin password: ${ADMIN_PASSWORD}读取配置时敏感信息从环境变量取不要把明文密码提交到代码仓库。这个习惯越早养成越好很多安全问题都出在测试代码把数据库密码、云厂商密钥写死。8. AI 自动化测试新机会与正确的期待这两年“AI 自动化测试”是很热的话题。各类工具都在尝试把大模型能力接入测试链路。常见的落地方向有AI 生成测试用例根据需求和页面控件生成基础用例。AI 辅助定位元素通过语义理解找到更稳定的选择器。AI 分析失败原因读取日志和截图判断是脚本问题还是业务 Bug。Codex Agent 这类编程助手直接在终端里根据自然语言生成测试代码。这些能力确实能减少重复劳动。比如 Playwright 的 Codegen 可以帮你录制操作生成脚本大模型可以帮你在不了解某个 API 时快速写出一段可读的测试代码。但也要认清边界AI 生成脚本需要人工审查尤其是断言和测试数据部分。如果 AI 按照错误的期望生成了一个“永远通过的用例”那它比不写还糟因为它给了你虚假的安全感。如果你想尝试用大模型辅助生成接口用例一个可参考的思路是把接口文档和一条示例用例作为上下文让模型生成更多边界用例然后人工筛选和校验。这里不针对特定厂商只给一个最小调用方式具体接口地址和密钥由你根据公司授权使用# ai_helper.py import requests def generate_test_cases(api_doc, examples): response requests.post( http://your-llm-endpoint/v1/chat/completions, headers{Authorization: Bearer YOUR_TOKEN}, json{ model: your-model, messages: [ {role: system, content: 你是资深测试工程师擅长根据接口文档生成边界测试用例。}, {role: user, content: f接口文档{api_doc}\n示例用例{examples}} ], temperature: 0.2, }, timeout30, ) return response.json()这个示例的重点是调用大模型接口时一定要把密钥放在服务端环境变量里不要提交到前端或代码库。同时AI 返回的用例只作为初稿需要执行和校验之后再进入用例库。我的判断是AI 会改变自动化测试的编写方式但不会改变测试的基本规律。业务理解、风险分析、断言设计、稳定性治理仍然是核心能力。与其焦虑“AI 会不会替代测试”不如先掌握好基础框架再用 AI 提效。9. 常见问题与排查思路这里把自动化测试实践中常见的问题整理成一个排查表方便你遇到问题时快速定位。问题现象可能原因排查方式解决方案接口用例随机失败测试数据冲突查看失败前后是否创建了同一登录账号每个用例使用唯一数据执行结束清理接口返回 401token 过期查看响应头和日志在会话中按状态码自动重新登录元素定位不到页面未加载完成打印当前 page_source使用显式等待等待元素可点击元素定位不稳定使用了动态 id观察多次运行时的 html改用稳定属性或相对定位非预期弹窗导致点击失败页面出现覆盖层通过异常信息定位卡住的元素封装弹窗处理工具记录弹窗日志浏览器驱动版本不匹配Chrome 自动更新查看 Selenium 报错中的版本信息用 webdriver-manager 自动下载驱动用例执行时间过长等待时间过多查看 pytest 耗时统计减少 sleep使用显式等待和并发执行环境变量读取失败密钥未设置打印 os.environ 中的 key在 CI 流水线中配置 Secret 变量用例之间有相互依赖上一个用例失败导致脏数据单独执行下一个用例看是否失败每个用例独立构造前置条件遇到问题先看日志再看截图最后再改脚本。不要一上来就盲目加大sleep那不是解决问题只是把问题往后拖。10. 零基础到项目实战的学习路线建议最后给想系统学习自动化测试的人一条可执行的路径而不是“从入门到放弃”。第一阶段接口自动化1 到 2 周学会用 Postman 调通接口理解请求方法、Header、Body、Cookie。学 Python 基础重点是函数、字典、列表、异常处理。学 requests 和 pytest写出至少 20 条接口用例。掌握参数化、fixture、base_url 管理、token 管理。第二阶段Web UI 自动化2 到 3 周学 Selenium 或 Playwright跑通一个真实项目的登录和查询流程。练习元素定位的多种方式理解显式等待。完成购物车添加商品、下单这类端到端流程重点处理弹窗和异步加载。引入 Page Object Model把页面操作封装成类。第三阶段移动端自动化可选1 到 2 周用 Appium 连接模拟器跑通安装、启动、登录流程。如果是游戏类项目学习 Airtest 的录制和图像识别。第四阶段框架设计与持续集成1 到 2 周搭建一个包含配置、公共方法、用例模块、数据文件、报告的 Python 测试项目。在 Jenkins 或 GitLab CI 上接入执行任务让代码提交后自动跑测试。学会看报告分析失败用例清理不稳定因素。第五阶段项目实战与总结持续选一个真实项目用接口 UI 结合的方式覆盖核心流程。把每次踩坑和解决方式记录成文档形成你自己的知识库。参与团队测试评审学会从业务风险角度挑选自动化用例。整个过程中最值得警惕的是“只囤教程不写代码”。很多人收藏了整套视频却迟迟没有在本地跑通一条用例。自动化测试是实践科学一个简单的接口用例比你收藏十篇框架文章都有用。希望这篇文章能帮你把散落的知识串起来。如果你正在准备面试或者刚接手自动化测试任务可以先从本文的接口示例开始在自己的电脑上跑通一遍再逐步扩展到 UI 和移动端。记住一个原则稳定的、有价值的自动化测试永远比花哨的、数量庞大的脚本更重要。