做自动化测试这些年我最大的感受是真正拉开团队差距的往往不是框架选得有多花哨而是用例本身写得好不好。框架只是承载用例的容器用例编写才是自动化测试的核心战场。很多人一上来就铺几百条用例跑起来一片红修脚本比验业务还累最后整个自动化项目被贴上“维护成本太高”的标签。这篇内容我尽量把用例编写这件事讲透从设计思路、元素定位、数据管理、断言写法到稳定性排障和AI辅助写用例全部结合我实际踩过的坑来聊适合正在搭自动化体系、或者用例老是跑不稳的朋友参考。1. 自动化测试用例设计先想清楚这三件事1.1 什么用例值得自动化我早期犯过一个特别典型的错误试图把手工测试用例全部搬到自动化脚本里。结果就是脚本数量暴涨但实际价值很低很多用例跑一次挂一次光排障就耗掉大半天。后来我给自己定了一个筛选逻辑一条用例同时满足下面三个条件才值得自动化场景高频主流程、核心功能、每次发版都要回归的路径。登录、下单、支付这类基本属于必选。步骤稳定操作路径不经常变UI元素相对固定。如果一个功能这周改字段、下周改布局自动化的维护成本会远超收益。回归价值大曾经出过严重线上问题、跨模块交互复杂、数据流转链路长的功能每次改动都可能引入回归风险。反过来有些用例我建议直接放弃自动化一次性探索性测试、视觉主观判断很强的UI走查、需要大量人工经验判断的模糊场景。这类用例用自动化去做纯属给自己找罪受。1.2 用例优先级用ROI来排这里涉及一个很实在的问题用例编排优先级。我的做法是按ROI投入产出比排打个比方把自动化用例当成投资组合每一条都在消耗“脚本编写时间维护时间”回报是“省下的手工回归时间发现缺陷的提前量”。我常用的一张优先级评估表大概长这样优先级判断条件示例自动化比例建议P0核心链路用户高频操作一旦出错影响面大登录、注册、支付、加购、订单提交100%覆盖P1跨模块业务流容易受周边改动影响退款流程、优惠券叠加、会员权益触发70%覆盖P2低频但逻辑复杂需要造复杂数据支撑积分兑换、活动抽奖、对账查询30%覆盖P3边缘场景、纯展示类、视觉细节空态展示、文案长度限制、样式校验有限覆盖或手工排优先级还有一个隐性好处当回归时间不够时你能立刻决定先跑哪批用例。我经常跟团队说P0的用例跑挂了必须停下所有事情去排查P2跑挂了先看是环境原因还是真Bug复杂度完全不同。1.3 测试金字塔别只会写UI用例UI自动化测试贵在“脆”——页面一改脚本大概率报废。所以我一直建议按测试金字塔的比例来分配用例层级底层接口/服务层自动化量大、稳定、执行快应该占比最高。中间层核心业务组件集成测试比如订单状态流转。顶层UI端到端用例数量要克制只覆盖关键用户路径。很多人对接口自动化的重视度不够总觉得“要模拟用户操作必须走界面”。但实际体验下来你只要验证了登录接口返回token、下单接口扣减库存、状态流转正确UI层需要覆盖的路径就少了很多。UI自动化真正不可替代的场景是验证前端交互逻辑和前后端联调的结果而不是把所有逻辑都压在UI层去验证。2. 动手前的准备定位、数据和环境2.1 元素定位策略稳定第一写UI用例前最先要解决的是元素定位。定位符稳不稳直接决定用例能活多久。我通常按这个优先级来选定位策略优先使用稳定的自定义属性很多团队的代码会在按钮、输入框上埋># page/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.CSS_SELECTOR, button[data-testidlogin-btn]) self.error_toast (By.CSS_SELECTOR, div[data-testiderror-msg]) self.user_avatar (By.CSS_SELECTOR, div[data-testiduser-avatar]) def login(self, username, password): self.input_username(username) self.input_password(password) self.click_login() def input_username(self, username): el WebDriverWait(self.driver, 15).until( EC.visibility_of_element_located(self.username_input) ) el.clear() el.send_keys(username) def input_password(self, password): el WebDriverWait(self.driver, 15).until( EC.visibility_of_element_located(self.password_input) ) el.clear() el.send_keys(password) def click_login(self): btn WebDriverWait(self.driver, 15).until( EC.element_to_be_clickable(self.login_button) ) btn.click() def is_login_success(self): return WebDriverWait(self.driver, 15).until( EC.visibility_of_element_located(self.user_avatar) ).is_displayed() def get_error_message(self): toast WebDriverWait(self.driver, 15).until( EC.visibility_of_element_located(self.error_toast) ) return toast.text页面对象的好处是当登录页面需要大改时你只需要动LoginPage这一个类所有依赖它的用例脚本可以完全不动。这个隔离效果在项目迭代频繁的时候尤其值钱。用例层编写# test_login.py import pytest from selenium import webdriver from selenium.webdriver.chrome.options import Options from page.login_page import LoginPage pytest.fixture def driver(): chrome_options Options() chrome_options.add_argument(--headlessnew) chrome_options.add_argument(--window-size1920,1080) d webdriver.Chrome(optionschrome_options) yield d d.quit() class TestLogin: def test_login_success(self, driver): driver.get(https://example.com/login) page LoginPage(driver) page.login(user_20250607113033, Test123456) assert page.is_login_success(), 登录成功但没有看到用户头像 def test_login_with_wrong_password(self, driver): driver.get(https://example.com/login) page LoginPage(driver) page.login(user_20250607113033, wrong_pass) err page.get_error_message() assert 用户名或密码错误 in err, f提示文案不对, 实际是: {err}这是我实际项目里比较有代表性的一对用例一条覆盖正向主路径一条覆盖核心异常路径。注意我在断言里给的报错信息——不是简单写assert page.is_login_success()而是把失败时实际看到的内容也打出来。这样用例挂了之后你看日志就知道是登录没成功还是文案不对不用重新跑一遍。等待策略别用sleeP再讲一个UI自动化里极其重要的细节不要动不动就sleep(5)。固定等待是最容易写、但最坑的方式。网络快慢、加载时间、渲染时间都会波动固定等5秒快了浪费4秒慢了照样超时。用显式等待Explicit Wait的方式代码会清晰很多WebDriverWait(driver, 15).until( EC.visibility_of_element_located((By.CSS_SELECTOR, div[data-testiduser-avatar])) )意思是最多等15秒每0.5秒检查一次元素直到它变得可见再往下走。要用隐式等待implicitly_wait的话注意它和显式等待混用会出现“等待时长叠加”的坑我一般只用显式等待写关键节点。失败截图自动保留用例挂了最痛苦的是人不在电脑前复现又要重跑。我的习惯是在失败钩子里自动截图保存命名带上时间戳和用例名pytest.hookimpl(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: timestamp time.strftime(%Y%m%d_%H%M%S) driver.save_screenshot(freports/screenshots/{item.name}_{timestamp}.png)这个截图功能成本极低但在排查稳定性问题时帮了我无数次。你可以想象一下一条用例凌晨4点跑挂了第二天早上你打开报告截图已经自动保存在那里。你都不用查日志一眼就知道是登录弹窗被遮挡了还是元素压根没渲染出来。4.2 接口用例token与资源状态的验证UI自动化虽然直观但不得不承认在数据准备和大规模回归上接口自动化的性价比高得多。我建议用requests直接测接口配合pytest组织用例。先建立公共请求会话很多接口需要登录态所以我会先写一个公共的请求封装自动处理token# api/client.py import requests class APIClient: BASE_URL https://api.example.com def __init__(self, tokenNone): self.session requests.Session() if token: self.session.headers.update({Authorization: fBearer {token}}) def login(self, username, password): resp self.session.post( f{self.BASE_URL}/login, json{username: username, password: password} ) resp.raise_for_status() token resp.json()[data][token] self.session.headers.update({Authorization: fBearer {token}}) return resp.json()写接口用例接口用例比UI用例更容易做到数据驱动我一般把一组输入期望值放在parametrize里跑# test_api_login.py import pytest from api.client import APIClient class TestLoginAPI: def test_login_success(self): client APIClient() resp client.login(user_20250607113033, Test123456) assert resp[code] 0 assert resp[data][token], token为空, 登录可能未生效 pytest.mark.parametrize(username,password,expected_code,expected_msg, [ (user_20250607113033, wrong_pass, 1001, 用户名或密码错误), (not_exist_user, Test123456, 1002, 用户不存在), (, Test123456, 1003, 用户名不能为空), (user_20250607113033, , 1003, 密码不能为空), ]) def test_login_invalid_params(self, username, password, expected_code, expected_msg): client APIClient() resp client.session.post( f{client.BASE_URL}/login, json{username: username, password: password} ) body resp.json() assert body[code] expected_code assert expected_msg in body[message]这里有个容易忽略的点即使HTTP状态码返回200也要校验业务码和提示文案。如果某个字段拼错了HTTP状态可能是正常的让你发现不了问题。接口用例是拦截这类问题成本最低的方式。接口用例断言别只断言status_code我见过特别多只写assert resp.status_code 200的接口用例。这种用例的覆盖能力非常有限。举个例子你调用“创建订单”接口就算内部参数校验失败、库存不足、优惠券过期返回的HTTP状态码也可能是200只是业务错误码不同。你只断言200等于完全没有校验业务结果。接口用例的断言至少应该包含HTTP状态码是否符合预期。业务返回码code字段是否符合预期。关键业务字段是否出现且值是否正确。数据库或下游系统状态是否发生预期变化按需。4.3 用例组织与运行报告用例一旦变多管理就会变成新的难题。我的文件夹结构一般是这样tests/ ├── api/ │ ├── test_login_api.py │ ├── test_order_api.py │ └── test_payment_api.py ├── ui/ │ ├── test_login_ui.py │ ├── test_checkout_ui.py │ └── conftest.py ├── data/ │ ├── login_data.json │ └── order_data.json └── page/ ├── login_page.py └── checkout_page.py用例命名上我强烈建议统一用test_功能点_场景_预期结果的格式。比如test_order_submit_with_empty_cart_returns_error。这样无论过多久回来看用例的意图都是一目了然的配合pytest的-k参数还能轻松筛选单条用例来跑。报告方面我比较习惯用pytest-html配合失败截图。不过报告这个东西够用就好不要过度追求花哨。真正有价值的不是报告样式而是报告里每条失败用例能否给出足够定位问题的信息。5. 稳定性踩坑与排查实录5.1 六类常见失败原因自动化测试跑到后期稳定性才是最大的敌人。我梳理一下遇到最多的六类失败原因基本每次排障都逃不出这几个方向失败类型典型表现根因方向元素找不到NoSuchElementException定位器失效、页面结构变化、元素在iframe中、元素尚未渲染等待超时TimeoutException网络慢、异步加载未完成、等待条件写错数据冲突第二次跑就失败数据未清理、唯一约束冲突、前置数据被外部任务改掉环境依赖本地过CI挂测试环境账号过期、第三方服务不可用、功能开关没开并发冲突并行跑时偶发失败共享数据、共享账号、共享浏览器缓存断言过强低危变更导致大量失败断言了不该断言的文案、颜色、排序、时间戳5.2 排查顺序与日志设计用例失败之后我的排查顺序是固定的先看是不是环境问题检查CI通知、测试环境服务状态、第三方依赖是否正常。环境问题占比很高如果不先排除后面全白看。再看是不是数据问题打开测试环境对应的数据库或后台管理页面确认用例依赖的数据还在不在。如果是造数时用了固定账号别人跑挂了把数据锁住了这种情况很常见。然后看是不是定位问题从失败截图和HTML dump里看页面当前的状态元素是否真的存在是否存在多个匹配项。最后才怀疑代码逻辑如果以上都排除了那就有可能是业务逻辑真的变了断言写得太死或者前端的交互路径改了。这个顺序看起来简单但很多人一上来就盯首页调用栈结果排了半天发现是环境挂了浪费时间。另外日志记录是稳定性排查的基石。很多人不重视日志只靠报错信息定位问题但报错信息经常只有一行Element not found你能知道它找不到哪个元素吗我习惯在关键操作前打日志比如“开始点击登录按钮”“文本框输入完成”“等待支付结果出现”。这样即使失败从日志里也能还原出用例到底执行到了哪一步。5.3 重试、拍屏、环境检查的取舍很多团队为了“稳定”喜欢在用例失败后自动重试。我的态度是重试可以有但不能盲目。如果用例本身有缺陷重试只会掩盖问题让自动化陷入“失败-重试-通过-下次再失败”的循环你还以为挺稳定。我给重试设了两个前置条件确认失败类型属于偶发环境抖动比如超时、网络中断而不是业务断言失败。重试逻辑带上原因标记最终报告里能区分“首次失败重试成功”和“直接失败”。我更看重的其实是“失败现场留痕”。在我现在的框架里每个用例失败会自动做三件事保存当前页面截图。导出当前页面HTML源码方便离线排查元素是否存在。输出当前URL和关键cookie信息用于还原登录态。这三样东西看着不起眼但在环境问题高发的项目里基本可以解决80%的“玄学失败”。有一回我在CI上发现一条用例隔三差五就失败一次本地怎么跑都通过。后来打开失败现场的HTML dump发现页面弹出了一个第三方活动弹窗把登录按钮挡住了。这个弹窗只在特定时间点出现本地永远复现不了但截图和HTML一对比原因瞬间清楚了。这就是现场留痕的价值。6. 用AI辅助写用例但不让AI替你做决定6.1 什么场景适合让AI先生成初稿最近一年多我个人写自动化用例的工作流变化很大。像Claude、Codex、Cursor这些AI工具已经能用得比较成熟了。我的经验是AI最适合干三类事根据页面结构或接口文档生成用例初稿。把HTML片段、接口文档或OpenAPI描述扔给它让它列出可测场景和对应代码。修复明显的定位和等待问题。比如元素选择器因为页面改版废弃了把失败日志和截图描述给它经常能直接给出可用的新选择器。批量生成数据驱动用例。把参数列表和校验规则给它它可以一次性生成一组规范的parametrize用例。比较经典的用法是让AI根据接口文档生成用例骨架这是登录接口文档 POST /login - 参数username(string, 必填), password(string, 必填) - 返回code(0表示成功), message, data.token 请帮我生成pytest的数据驱动测试用例。覆盖 1. 正确账号密码 2. 错误密码 3. 用户不存在 4. username为空 5. password为空 要求断言包括code和message。这种任务AI完成度相当高省掉了不少机械劳动的功夫。6.2 实用提示词和示例再举个例子。比如你用Selenium写UI用例想让AI辅助写一个“商品加入购物车并结算”的用例初稿可以这样给提示我在用pytest Selenium Page Object模式写自动化用例。 现有login_page.py封装了登录操作 现在需要新增一个下单流程用例 1. 登录 2. 搜索商品 3. 点击第一个商品加入购物车 4. 进入购物车结算 5. 地址选择默认地址 6. 提交订单 7. 断言订单提交成功页出现“支付”按钮 请按Page Object模式生成search_page.py、cart_page.py、checkout_page.py的代码片段并生成对应的test_purchase_flow.py。AI生成的初稿通常能满足大概80%的需求。剩下20%需要人来处理比如元素定位是否使用了稳定属性、等待条件是否合理、断言是否覆盖了核心业务结果。我把这个流程叫“AI生成骨架人来定业务”。6.3 AI输出的用例一定要人工复审哪些点AI写代码有一个特点它非常擅长生成看上去合理、但业务语义可能完全不对的代码。结合我自己的使用经验人工复审的时候一定要盯这几个点业务断言是否准确。这是最关键的一环。AI可能生成了assert resp.code 200但业务上是code 0才是成功它完全不知道。测试数据的唯一性。AI很容易生成写死的用户名testuser这种数据跑第二次就会冲突必须改造成带随机后缀的唯一数据。等待条件是否合理。AI经常会用sleep(3)这种偷懒写法需要把它替换成显式等待否则用例稳定性很难保证。用例之间是否独立。AI生成代码时喜欢“顺手套用”前一个用例的数据造出来的用例连带着有了隐式依赖必须拆开。我在实际工作里现在是这样把控AI用例质量的AI生成的每条用例都要过一遍“业务评审”——不是看代码风格而是确认断言反映的是不是真实业务规则。这一条守住了AI在自动化测试里的价值才会大于风险。另外AI在排查失败用例时也很有用。我经常把一段失败的Traceback加上截图描述丢给它让它帮忙判断失败原因。不过这里同样要警惕AI给出的原因分析只是建议还是要结合自己的现场日志做最终判断千万别把它当权威。它更像是你旁边一位高水平的同事能帮你打开思路但做决定的永远是你自己。我现在写用例的基本工作流差不多就是先按核心链路梳理出P0用例清单再用接口自动化覆盖80%的规则验证UI层只留真正的关键用户路径。写脚本时用POM结构管理页面元素断言紧盯业务状态而不是界面细节。跑完自动留痕失败先查环境再查逻辑最后用AI帮忙搞定初稿和定位器修复但所有业务断言都由我自己拍板。如果你刚起步做自动化最简单有效的一步是选一条你最常点的核心流程按四段式结构把用例写完整配好截图留存和明确的断言先跑起来再谈铺量和增强。自动化用例不是写得越多越好而是每条都能稳定地守住一个业务结果。