尧图网站建设 
先说个我经历过的事。前两年有个团队找我帮忙复盘自动化测试项目他们用例写了上千条但每次跑完报告一片红点开一看一半不是功能挂了而是数据被别个用例改了、元素等不到、断言写得太脆。到最后大家都不看这个报告了自动化测试就变成了一个“每天定时失败”的仪式。这不是个例。很多人第一次接触自动化测试第一反应就是把手工用例一条条“翻译”成脚本觉得自动化测试用例就是“手工用例的代码版”。但真正跑起来才发现这两者的设计逻辑完全不一样。自动化测试用例不是把步骤写成代码就完事而是一套“可重复执行、结果可判断、失败了能快速定位”的测试策略载体。它的核心价值是用机器的时间换人的时间用稳定可靠的回归能力守住核心功能。换句话说它不追求“覆盖全部”而追求“每一分维护成本都花在刀刃上”。这篇内容就是围绕“自动化测试用例到底要怎么写”展开的。我会从顶层设计思路、场景拆分方法、实际落地时最容易出问题的细节到怎么用 AI 辅助生成用例、常见问题怎么排查一次性把这些年的实战经验都倒出来。适合刚接触自动化测试的新人也适合已经在写脚本但觉得维护成本越来越高的中级工程师。1. 动笔之前先把测试策略想清楚1.1 到底哪些用例适合做自动化我以前也犯过“什么都想自动化”的毛病。后来被现实教育了几次才明白自动化测试不是取代手工测试而是把手工测试里那部分最重复、最稳定、最费时的验证工作接过来。判断一个用例适不适合自动化我一般看四个维度是否高频回归、是否业务关键、是否结果可精确判断、执行环境是否稳定。适合自动化的典型用例包括核心业务流程的冒烟验证、跨版本回归的功能点、需要大量数据组合的参数化场景、接口层面的契约校验、需要每次发布前反复执行的检查项。不适合自动化的场景则往往是探索性测试、一次性的临时性验证、依赖大量主观视觉判断的界面体验检查、极少执行且业务逻辑变动极快的临时功能。我建议用一个最简单的标准来过滤如果这个用例三个月内你至少会手动跑十次那就值得考虑自动化如果一年都跑不了一次别折腾了写成自动化就是给团队埋雷。下面这个表是我平时用来判断“要不要自动化”的快速参考用例特征适合自动化不适合自动化执行频率高频、固定回归低频、临时验证结果判断可用文本、数据、接口响应精确断言依赖感官、主观审美判断数据要求可构造、可控、可清理需要复杂真实脏数据、海量随机数据环境稳定性测试环境稳定、版本可控强依赖第三方、经常不稳定业务稳定度需求稳定、界面结构变化小页面频繁改版、流程经常调整1.2 优先级分层自动化测试不是越全越好“最全”这个说法其实是个陷阱。真正的“全”指的是对核心业务风险的覆盖够全而不是用例数量上的堆砌。我习惯把自动化用例分成 P0、P1、P2 三层。P0 是冒烟级用例必须全绿跑挂了发布流程就要停P1 是核心业务回归要求高稳定、低误报P2 是功能细节和边缘场景容忍一定程度的波动但也要有淘汰机制。我见过一些团队的自动化用例库只有“增量”没有“减量”用例越加越多维护成本像滚雪球一样膨胀但实际跑出来的价值并没有等比例增加。原因很简单每一条自动化用例都包含定位器、数据、断言、等待逻辑四部分每一步都可能因为产品变化而失效。所以我在评审自动化用例时一定会问三个问题这条用例半个月后还有价值吗如果失败了能精准指出是哪个功能坏了吗维护它的成本是它捕获缺陷概率的多少倍回答不了就直接砍掉这不是浪费是在控制负债。1.3 顶层设计的三条路线数据驱动、关键字驱动、行为驱动自动化测试用例写到一定规模后真正比拼的就不再是单条脚本多漂亮而是整体架构多抗造。目前业界用得比较多的三条路线分别是数据驱动、关键字驱动和 BDD行为驱动开发。简单说数据驱动是把“测试数据”和“操作逻辑”分开一套脚本跑多组数据关键字驱动则是把“打开页面”“输入内容”“点击按钮”“断言结果”这些动作抽象成关键字用表格或配置文件组合成用例BDD 则是用接近自然语言的格式描述行为典型工具是 Cucumber。选哪条路线没有绝对对错得看团队的组成。如果团队里大部分是测试开发能力一般的业务测试同学关键字驱动会更友好如果团队里人人能写代码数据驱动配合 PO 模式最灵活。我个人的习惯是UI 自动化优先用 PO 模式加数据驱动接口自动化优先数据驱动加契约测试BDD 用于跨部门协作的场景让产品和开发都能看懂用例在做什么。不管选哪条核心目标都一样——用例的维护成本要低于手工回归的成本否则自动化就没有存在意义。2. 把业务场景拆成可自动化执行的用例2.1 从需求文档到测试场景的拆解方法很多人在写自动化测试用例的时候习惯直接打开页面照着操作路径开始录脚本。这种方式不能说错但写出来的用例往往只能覆盖“happy path”一遇到数据变化或异常流程就不行了。更靠谱的做法是先回到需求本身把业务逻辑拆成可验证的场景再把场景映射到自动化脚本上。具体操作是拿到需求之后先列主流程再列分支流程和异常流程。比如一个电商下单功能主流程就是“搜索商品→加购→去结算→提交订单→支付成功”分支包括优惠券抵扣、多地址切换、修改数量异常包括库存不足、支付超时、接口返回错误码。每个流程都要明确前置条件、触发操作、期望结果。拆完之后再筛一遍把适合自动化的场景挑出来排好优先级。举个例子。刚做接口自动化时我喜欢盯着一个接口反复造参数来测后来发现真正容易出问题的往往是多个接口串联起来的交互场景。比如“下单”这个接口本身没问题但从“加购”到“提交订单”之间如果中间态的 token 过期或库存状态不一致整个流程就挂了。所以在场景拆解时不要只站在单接口或单页面的视角要用一条完整的用户操作链去走一遍才能真正模拟出线上用户的使用体验。2.2 自动化测试用例的基本结构模板不管是用 Python、Java 还是其他语言自动化测试用例的数据结构其实非常固定。一个完整可维护的用例至少要包含以下要素用例编号、所属模块、用例名称、优先级、前置条件、测试数据、操作步骤、预期结果、断言方式、依赖关系。把这些字段用表格管理起来无论写脚本还是写文档都不会乱。我平时在项目里用的用例模板是这样的字段说明示例用例编号唯一标识TC-LOGIN-001模块功能模块登录认证用例名称描述验证点登录成功-正确账号密码优先级P0/P1/P2P0前置条件执行前的状态已打开登录页测试数据输入数据用户名: zhangsan密码: 123456操作步骤操作序列1. 输入用户名 2. 输入密码 3. 点击登录预期结果业务结果页面跳转到首页右上角显示用户昵称断言方式验证什么首页导航栏存在用户昵称文本这个模板最大的价值不是格式好看而是逼着你在写脚本之前就想清楚这条用例需要什么样的数据环境期望结果怎么验证如果断言失败是功能真坏了还是用例自身的问题想不清楚这些后面写出来的脚本大概率是跑得通但测不准的“假自动化”。2.3 用例命名看到名字就该知道测什么命名这件事看着小实际影响很大。自动化用例一旦超过一百条靠名字检索就成了最常用的定位手段。我见过大量命名成 test_1、test_login、check_user 的用例跑挂了查半天都不知道是哪个场景出了问题。好的命名应该是一个“可读的断言”比如test_login_success_with_valid_credentials、test_add_item_to_cart_then_remove_it、test_checkout_with_expired_coupon。命名规范还有个隐形的好处它会强制你把业务维度拆得更细。因为只有场景拆得足够单一时你才能用一句英文把用例目的写清楚。如果一个用例名字里出现了“and”和“then”好几个连接词说明这条用例塞了太多逻辑建议拆开。我在评审用例时会直接抽查命名从命名基本就能判断这个团队的用例设计水平。3. 从设计到脚本落地真正绕不开的细节3.1 元素定位和等待机制稳定性的第一道关口UI 自动化里最经常报的错就是找不到元素报错信息千篇一律地写着NoSuchElementException。刚开始写用例的时候我以为是定位表达式写错了后来排查多了才发现一半以上的情况是元素还没渲染出来脚本就去点击了另一半才是表达式写得不准确。解决这个问题核心既不是换一个更聪明的定位器也不是盲目加等待而是把“显式等待”变成标配。显式等待的意思是用代码主动等待某个条件成立比如元素可见、可点击、文本出现再继续下一步。相比无脑用time.sleep(3)显式等待更快也更稳页面加载快了不会浪费时间加载慢了也不会误报。在 Selenium 里我会封装一个通用方法比如wait_for_element_clickable所有用例统一调用而不是每个用例各写各的等待逻辑。这样遇到因等待不够导致的偶发失败只需要在一个地方调整参数不用满项目找。元素定位本身也有讲究。我一般不推荐用绝对路径或者拿一连串的 HTML 结构来做定位因为页面布局稍微一调就全挂了。更稳的做法是优先用 id、data-testid 这类业务标识其次是稳定的 CSS 选择器和相对定位最少依赖文本内容去定位。为什么文本往往是会变的今天显示“提交订单”明天为了转化率改成“立即支付”你的脚本就得跟着改。现在不少前端团队已经习惯在关键控件上增加>import requests import pytest def test_create_order_with_valid_stock(): # 准备数据 payload { user_id: u_10001, product_id: p_8888, quantity: 1, coupon_id: } # 执行下单接口 resp requests.post(https://api.test.com/order/create, jsonpayload) order_data resp.json() # 断言一HTTP 状态码 assert resp.status_code 200 # 断言二业务状态码 assert order_data[code] 0 # 断言三订单核心字段 assert order_data[data][order_status] pending_payment assert order_data[data][total_amount] 1999 # 断言四数据库落库一致性假设已封装 db 模块 db_order db.query_order(order_data[data][order_id]) assert db_order[order_status] pending_payment assert db_order[total_amount] 1999UI 自动化的断言其实也有层次。最弱的是断言元素存在最强的是断言完整的业务状态。比如一个“用户修改密码”的用例只断言“保存成功”弹窗出现是不够的最好再用新密码走一遍登录接口确认密码真的改掉了。所谓“测试用例测的是业务不是界面”就是这个意思。3.4 可读性和维护性给三个月后的自己写代码自动化测试脚本表面上是给机器执行的本质上却是给人维护的。我经常提醒团队“你现在写的每一条用例三个月后大概率是你自己来改。”来想想那个场景如果脚本里全是driver.find_element(By.ID, xxx)这种裸代码、没有任何注释、变量名全是 a、b、c到那时候你还能看懂它在测什么吗所以从第一天开始我建议就用工程化的标准来要求测试代码。具体来说第一要素是命名可读不用多说第二要素是页面对象和公共方法要下沉不要在用例里堆细节第三要素是日志要做好。至少要在关键步骤处输出日志比如“正在执行登录操作, 用户: xxx”这样用例跑挂了你可以根据日志快速定位是卡在登录、下单还是支付环节。接口自动化里我还习惯在断言失败时打印请求参数和返回报文这个信息帮助我在排查问题时节省了大量时间。还有一点容易被忽视用例之间的独立性。自动化测试用例最好是互不依赖的能独立运行也能独立失败。如果用例之间存在隐式的执行顺序依赖一旦中间某条挂了后面的用例全都会跟着挂排查起来一头雾水。现在测试框架普遍支持依赖控制或者按顺序执行但我的建议是尽量保持用例的独立性把公共的前置操作放到 fixture 里而不是上一条用例的“尾巴”里。4. 进阶玩法让 AI 帮你跑通“从需求到用例”的最后一公里4.1 AI 在自动化测试里的真实边界这几年 AI 辅助测试的热度非常高像“AI自动化测试平台搭建”“LangChain自动生成测试用例”“自己搭建Agent进行自动化测试”这些方向已经有不少团队在尝试。我自己也实践过一段时间说点真实感受AI 在自动化测试里最擅长的不是“全自动跑测试”而是把那些本身就有清晰规则的重复性工作自动化掉。比如根据接口文档生成参数化测试用例、根据需求描述生成场景化的用例初稿、把自然语言转成测试步骤、辅助推荐合适的元素定位表达式。真正需要人来做的是业务逻辑的梳理、边界条件和异常场景的设计以及 AI 生成内容的筛选与验证。理解了这一点就不会对 AI 有过高期待也不会问出“AI 能不能完全替代手工测试”这种没有意义的问题。它更像一个特别擅长草拟框架的助手而不是一个能直接负责质量的同事。4.2 用 LangChain 生成测试用例的实践思路我看很多文章讲“LangChain 自动生成测试用例”听起来很玄拆开看其实就是一个流程把需求文本或接口定义喂给大模型通过提示词模板让它输出结构化的测试用例再通过脚本把输出的内容转成测试代码或测试用例表格。中间可以不用 LangChain直接调大模型 API 也行但 LangChain 这种框架提供了一个相对标准化的链路方便你管理提示词、解析输出结果和做后处理。实际操作大概分四步。第一步准备输入数据可能是接口文档的 JSON 结构也可能是需求描述文本第二步设计提示词模板明确让模型输出什么格式、包含哪些字段第三步调用模型生成结果解析成结构化的 JSON第四步人工审核并落成标准的测试用例文档或可执行的测试数据文件。我试过一个例子给模型一个登录接口的字段定义让它生成“用户名、密码、验证码”的组合测试用例包括必填校验、长度校验、特殊字符、错误密码、正确密码等场景生成速度很快覆盖的常规场景也比较全。提示词模板可以很简单下面是一个参考思路你是一名资深的软件测试工程师。请根据以下接口信息生成测试用例。 接口名称登录接口 请求方式POST 请求参数username: 字符串, 必填; password: 字符串, 必填; captcha: 字符串, 必填 业务规则用户名和密码正确则登录成功密码连续错误5次后账号锁定验证码有效期5分钟。 请输出 JSON 数组每个元素包含case_title, preconditions, steps, expected_result, priority 五个字段。生成的输出虽然不一定能直接用但至少把一套常规用例的骨架搭好了。需要人审的通常是两点一是业务规则相关的边界条件有没有漏二是期望结果是不是真的符合产品逻辑。这两个点恰好是大模型最容易一本正经胡说八道的地方。所以我的经验是AI 负责写“面”人负责补“点”。这样效率提升非常明显。4.3 自己搭建 Agent 做自动化测试的实践建议再进一步不少人开始尝试让 Agent 自动执行“理解需求→编写用例→执行测试→收集结果→给出结论”的闭环。这个方向很吸引人但以我目前的实践经验完全无人值守的自动化 Agent 在绝大多数团队里还不靠谱比较可行的路径是“人机协同的半自动流程”。什么意思就是用 Agent 去完成用例生成、脚本草稿、失败日志初筛这几类相对机械的环节但关键的用例设计评审、断言逻辑确认、失败结果判定仍然需要人来把关。比如在小程序或 Web 应用里用 AI 辅助自动化测试的典型流程可以是输入一个功能描述AI 生成一套测试场景列表→测试工程师挑选并调整场景→AI 把已确认的场景生成对应的测试脚本骨架→工程师补充断言和业务数据→执行后 AI 自动汇总失败日志并推断可能原因→工程师做最终定位和修复。每一步里 AI 都在做事但每一步都有人类确认的节点。这样既发挥了大模型擅长的文本生成和理解能力也避开了它在真实业务判断上的短板。最后提醒一句用 AI 生成测试脚本时定位器、等待逻辑、数据隔离这些工程化约束依然存在。AI 写出来的代码同样要遵循 PO 模式同样要显式等待同样不能把测试数据写死。所谓“AI 自动化测试”本质上是把工程化积累的规范交给模型去执行而不是让模型另搞一套不讲规矩的脚本。5. 常见问题与排查技巧实录5.1 自动化用例执行不稳定的排查表自动化用例跑起来不稳定是几乎每个测试团队都会遇到的事。这里我把平时归类过的高频问题、常见原因和排查思路整理成一个速查表方便大家在实际工作中对照排查现象常见原因排查思路建议元素找不到页面加载慢、定位器失效查看失败截图和日志复现定位表达式改用显式等待优先用> 自动化测试用例设计与实战：从策略拆解到AI辅助落地
先说个我经历过的事。前两年有个团队找我帮忙复盘自动化测试项目他们用例写了上千条但每次跑完报告一片红点开一看一半不是功能挂了而是数据被别个用例改了、元素等不到、断言写得太脆。到最后大家都不看这个报告了自动化测试就变成了一个“每天定时失败”的仪式。这不是个例。很多人第一次接触自动化测试第一反应就是把手工用例一条条“翻译”成脚本觉得自动化测试用例就是“手工用例的代码版”。但真正跑起来才发现这两者的设计逻辑完全不一样。自动化测试用例不是把步骤写成代码就完事而是一套“可重复执行、结果可判断、失败了能快速定位”的测试策略载体。它的核心价值是用机器的时间换人的时间用稳定可靠的回归能力守住核心功能。换句话说它不追求“覆盖全部”而追求“每一分维护成本都花在刀刃上”。这篇内容就是围绕“自动化测试用例到底要怎么写”展开的。我会从顶层设计思路、场景拆分方法、实际落地时最容易出问题的细节到怎么用 AI 辅助生成用例、常见问题怎么排查一次性把这些年的实战经验都倒出来。适合刚接触自动化测试的新人也适合已经在写脚本但觉得维护成本越来越高的中级工程师。1. 动笔之前先把测试策略想清楚1.1 到底哪些用例适合做自动化我以前也犯过“什么都想自动化”的毛病。后来被现实教育了几次才明白自动化测试不是取代手工测试而是把手工测试里那部分最重复、最稳定、最费时的验证工作接过来。判断一个用例适不适合自动化我一般看四个维度是否高频回归、是否业务关键、是否结果可精确判断、执行环境是否稳定。适合自动化的典型用例包括核心业务流程的冒烟验证、跨版本回归的功能点、需要大量数据组合的参数化场景、接口层面的契约校验、需要每次发布前反复执行的检查项。不适合自动化的场景则往往是探索性测试、一次性的临时性验证、依赖大量主观视觉判断的界面体验检查、极少执行且业务逻辑变动极快的临时功能。我建议用一个最简单的标准来过滤如果这个用例三个月内你至少会手动跑十次那就值得考虑自动化如果一年都跑不了一次别折腾了写成自动化就是给团队埋雷。下面这个表是我平时用来判断“要不要自动化”的快速参考用例特征适合自动化不适合自动化执行频率高频、固定回归低频、临时验证结果判断可用文本、数据、接口响应精确断言依赖感官、主观审美判断数据要求可构造、可控、可清理需要复杂真实脏数据、海量随机数据环境稳定性测试环境稳定、版本可控强依赖第三方、经常不稳定业务稳定度需求稳定、界面结构变化小页面频繁改版、流程经常调整1.2 优先级分层自动化测试不是越全越好“最全”这个说法其实是个陷阱。真正的“全”指的是对核心业务风险的覆盖够全而不是用例数量上的堆砌。我习惯把自动化用例分成 P0、P1、P2 三层。P0 是冒烟级用例必须全绿跑挂了发布流程就要停P1 是核心业务回归要求高稳定、低误报P2 是功能细节和边缘场景容忍一定程度的波动但也要有淘汰机制。我见过一些团队的自动化用例库只有“增量”没有“减量”用例越加越多维护成本像滚雪球一样膨胀但实际跑出来的价值并没有等比例增加。原因很简单每一条自动化用例都包含定位器、数据、断言、等待逻辑四部分每一步都可能因为产品变化而失效。所以我在评审自动化用例时一定会问三个问题这条用例半个月后还有价值吗如果失败了能精准指出是哪个功能坏了吗维护它的成本是它捕获缺陷概率的多少倍回答不了就直接砍掉这不是浪费是在控制负债。1.3 顶层设计的三条路线数据驱动、关键字驱动、行为驱动自动化测试用例写到一定规模后真正比拼的就不再是单条脚本多漂亮而是整体架构多抗造。目前业界用得比较多的三条路线分别是数据驱动、关键字驱动和 BDD行为驱动开发。简单说数据驱动是把“测试数据”和“操作逻辑”分开一套脚本跑多组数据关键字驱动则是把“打开页面”“输入内容”“点击按钮”“断言结果”这些动作抽象成关键字用表格或配置文件组合成用例BDD 则是用接近自然语言的格式描述行为典型工具是 Cucumber。选哪条路线没有绝对对错得看团队的组成。如果团队里大部分是测试开发能力一般的业务测试同学关键字驱动会更友好如果团队里人人能写代码数据驱动配合 PO 模式最灵活。我个人的习惯是UI 自动化优先用 PO 模式加数据驱动接口自动化优先数据驱动加契约测试BDD 用于跨部门协作的场景让产品和开发都能看懂用例在做什么。不管选哪条核心目标都一样——用例的维护成本要低于手工回归的成本否则自动化就没有存在意义。2. 把业务场景拆成可自动化执行的用例2.1 从需求文档到测试场景的拆解方法很多人在写自动化测试用例的时候习惯直接打开页面照着操作路径开始录脚本。这种方式不能说错但写出来的用例往往只能覆盖“happy path”一遇到数据变化或异常流程就不行了。更靠谱的做法是先回到需求本身把业务逻辑拆成可验证的场景再把场景映射到自动化脚本上。具体操作是拿到需求之后先列主流程再列分支流程和异常流程。比如一个电商下单功能主流程就是“搜索商品→加购→去结算→提交订单→支付成功”分支包括优惠券抵扣、多地址切换、修改数量异常包括库存不足、支付超时、接口返回错误码。每个流程都要明确前置条件、触发操作、期望结果。拆完之后再筛一遍把适合自动化的场景挑出来排好优先级。举个例子。刚做接口自动化时我喜欢盯着一个接口反复造参数来测后来发现真正容易出问题的往往是多个接口串联起来的交互场景。比如“下单”这个接口本身没问题但从“加购”到“提交订单”之间如果中间态的 token 过期或库存状态不一致整个流程就挂了。所以在场景拆解时不要只站在单接口或单页面的视角要用一条完整的用户操作链去走一遍才能真正模拟出线上用户的使用体验。2.2 自动化测试用例的基本结构模板不管是用 Python、Java 还是其他语言自动化测试用例的数据结构其实非常固定。一个完整可维护的用例至少要包含以下要素用例编号、所属模块、用例名称、优先级、前置条件、测试数据、操作步骤、预期结果、断言方式、依赖关系。把这些字段用表格管理起来无论写脚本还是写文档都不会乱。我平时在项目里用的用例模板是这样的字段说明示例用例编号唯一标识TC-LOGIN-001模块功能模块登录认证用例名称描述验证点登录成功-正确账号密码优先级P0/P1/P2P0前置条件执行前的状态已打开登录页测试数据输入数据用户名: zhangsan密码: 123456操作步骤操作序列1. 输入用户名 2. 输入密码 3. 点击登录预期结果业务结果页面跳转到首页右上角显示用户昵称断言方式验证什么首页导航栏存在用户昵称文本这个模板最大的价值不是格式好看而是逼着你在写脚本之前就想清楚这条用例需要什么样的数据环境期望结果怎么验证如果断言失败是功能真坏了还是用例自身的问题想不清楚这些后面写出来的脚本大概率是跑得通但测不准的“假自动化”。2.3 用例命名看到名字就该知道测什么命名这件事看着小实际影响很大。自动化用例一旦超过一百条靠名字检索就成了最常用的定位手段。我见过大量命名成 test_1、test_login、check_user 的用例跑挂了查半天都不知道是哪个场景出了问题。好的命名应该是一个“可读的断言”比如test_login_success_with_valid_credentials、test_add_item_to_cart_then_remove_it、test_checkout_with_expired_coupon。命名规范还有个隐形的好处它会强制你把业务维度拆得更细。因为只有场景拆得足够单一时你才能用一句英文把用例目的写清楚。如果一个用例名字里出现了“and”和“then”好几个连接词说明这条用例塞了太多逻辑建议拆开。我在评审用例时会直接抽查命名从命名基本就能判断这个团队的用例设计水平。3. 从设计到脚本落地真正绕不开的细节3.1 元素定位和等待机制稳定性的第一道关口UI 自动化里最经常报的错就是找不到元素报错信息千篇一律地写着NoSuchElementException。刚开始写用例的时候我以为是定位表达式写错了后来排查多了才发现一半以上的情况是元素还没渲染出来脚本就去点击了另一半才是表达式写得不准确。解决这个问题核心既不是换一个更聪明的定位器也不是盲目加等待而是把“显式等待”变成标配。显式等待的意思是用代码主动等待某个条件成立比如元素可见、可点击、文本出现再继续下一步。相比无脑用time.sleep(3)显式等待更快也更稳页面加载快了不会浪费时间加载慢了也不会误报。在 Selenium 里我会封装一个通用方法比如wait_for_element_clickable所有用例统一调用而不是每个用例各写各的等待逻辑。这样遇到因等待不够导致的偶发失败只需要在一个地方调整参数不用满项目找。元素定位本身也有讲究。我一般不推荐用绝对路径或者拿一连串的 HTML 结构来做定位因为页面布局稍微一调就全挂了。更稳的做法是优先用 id、data-testid 这类业务标识其次是稳定的 CSS 选择器和相对定位最少依赖文本内容去定位。为什么文本往往是会变的今天显示“提交订单”明天为了转化率改成“立即支付”你的脚本就得跟着改。现在不少前端团队已经习惯在关键控件上增加>import requests import pytest def test_create_order_with_valid_stock(): # 准备数据 payload { user_id: u_10001, product_id: p_8888, quantity: 1, coupon_id: } # 执行下单接口 resp requests.post(https://api.test.com/order/create, jsonpayload) order_data resp.json() # 断言一HTTP 状态码 assert resp.status_code 200 # 断言二业务状态码 assert order_data[code] 0 # 断言三订单核心字段 assert order_data[data][order_status] pending_payment assert order_data[data][total_amount] 1999 # 断言四数据库落库一致性假设已封装 db 模块 db_order db.query_order(order_data[data][order_id]) assert db_order[order_status] pending_payment assert db_order[total_amount] 1999UI 自动化的断言其实也有层次。最弱的是断言元素存在最强的是断言完整的业务状态。比如一个“用户修改密码”的用例只断言“保存成功”弹窗出现是不够的最好再用新密码走一遍登录接口确认密码真的改掉了。所谓“测试用例测的是业务不是界面”就是这个意思。3.4 可读性和维护性给三个月后的自己写代码自动化测试脚本表面上是给机器执行的本质上却是给人维护的。我经常提醒团队“你现在写的每一条用例三个月后大概率是你自己来改。”来想想那个场景如果脚本里全是driver.find_element(By.ID, xxx)这种裸代码、没有任何注释、变量名全是 a、b、c到那时候你还能看懂它在测什么吗所以从第一天开始我建议就用工程化的标准来要求测试代码。具体来说第一要素是命名可读不用多说第二要素是页面对象和公共方法要下沉不要在用例里堆细节第三要素是日志要做好。至少要在关键步骤处输出日志比如“正在执行登录操作, 用户: xxx”这样用例跑挂了你可以根据日志快速定位是卡在登录、下单还是支付环节。接口自动化里我还习惯在断言失败时打印请求参数和返回报文这个信息帮助我在排查问题时节省了大量时间。还有一点容易被忽视用例之间的独立性。自动化测试用例最好是互不依赖的能独立运行也能独立失败。如果用例之间存在隐式的执行顺序依赖一旦中间某条挂了后面的用例全都会跟着挂排查起来一头雾水。现在测试框架普遍支持依赖控制或者按顺序执行但我的建议是尽量保持用例的独立性把公共的前置操作放到 fixture 里而不是上一条用例的“尾巴”里。4. 进阶玩法让 AI 帮你跑通“从需求到用例”的最后一公里4.1 AI 在自动化测试里的真实边界这几年 AI 辅助测试的热度非常高像“AI自动化测试平台搭建”“LangChain自动生成测试用例”“自己搭建Agent进行自动化测试”这些方向已经有不少团队在尝试。我自己也实践过一段时间说点真实感受AI 在自动化测试里最擅长的不是“全自动跑测试”而是把那些本身就有清晰规则的重复性工作自动化掉。比如根据接口文档生成参数化测试用例、根据需求描述生成场景化的用例初稿、把自然语言转成测试步骤、辅助推荐合适的元素定位表达式。真正需要人来做的是业务逻辑的梳理、边界条件和异常场景的设计以及 AI 生成内容的筛选与验证。理解了这一点就不会对 AI 有过高期待也不会问出“AI 能不能完全替代手工测试”这种没有意义的问题。它更像一个特别擅长草拟框架的助手而不是一个能直接负责质量的同事。4.2 用 LangChain 生成测试用例的实践思路我看很多文章讲“LangChain 自动生成测试用例”听起来很玄拆开看其实就是一个流程把需求文本或接口定义喂给大模型通过提示词模板让它输出结构化的测试用例再通过脚本把输出的内容转成测试代码或测试用例表格。中间可以不用 LangChain直接调大模型 API 也行但 LangChain 这种框架提供了一个相对标准化的链路方便你管理提示词、解析输出结果和做后处理。实际操作大概分四步。第一步准备输入数据可能是接口文档的 JSON 结构也可能是需求描述文本第二步设计提示词模板明确让模型输出什么格式、包含哪些字段第三步调用模型生成结果解析成结构化的 JSON第四步人工审核并落成标准的测试用例文档或可执行的测试数据文件。我试过一个例子给模型一个登录接口的字段定义让它生成“用户名、密码、验证码”的组合测试用例包括必填校验、长度校验、特殊字符、错误密码、正确密码等场景生成速度很快覆盖的常规场景也比较全。提示词模板可以很简单下面是一个参考思路你是一名资深的软件测试工程师。请根据以下接口信息生成测试用例。 接口名称登录接口 请求方式POST 请求参数username: 字符串, 必填; password: 字符串, 必填; captcha: 字符串, 必填 业务规则用户名和密码正确则登录成功密码连续错误5次后账号锁定验证码有效期5分钟。 请输出 JSON 数组每个元素包含case_title, preconditions, steps, expected_result, priority 五个字段。生成的输出虽然不一定能直接用但至少把一套常规用例的骨架搭好了。需要人审的通常是两点一是业务规则相关的边界条件有没有漏二是期望结果是不是真的符合产品逻辑。这两个点恰好是大模型最容易一本正经胡说八道的地方。所以我的经验是AI 负责写“面”人负责补“点”。这样效率提升非常明显。4.3 自己搭建 Agent 做自动化测试的实践建议再进一步不少人开始尝试让 Agent 自动执行“理解需求→编写用例→执行测试→收集结果→给出结论”的闭环。这个方向很吸引人但以我目前的实践经验完全无人值守的自动化 Agent 在绝大多数团队里还不靠谱比较可行的路径是“人机协同的半自动流程”。什么意思就是用 Agent 去完成用例生成、脚本草稿、失败日志初筛这几类相对机械的环节但关键的用例设计评审、断言逻辑确认、失败结果判定仍然需要人来把关。比如在小程序或 Web 应用里用 AI 辅助自动化测试的典型流程可以是输入一个功能描述AI 生成一套测试场景列表→测试工程师挑选并调整场景→AI 把已确认的场景生成对应的测试脚本骨架→工程师补充断言和业务数据→执行后 AI 自动汇总失败日志并推断可能原因→工程师做最终定位和修复。每一步里 AI 都在做事但每一步都有人类确认的节点。这样既发挥了大模型擅长的文本生成和理解能力也避开了它在真实业务判断上的短板。最后提醒一句用 AI 生成测试脚本时定位器、等待逻辑、数据隔离这些工程化约束依然存在。AI 写出来的代码同样要遵循 PO 模式同样要显式等待同样不能把测试数据写死。所谓“AI 自动化测试”本质上是把工程化积累的规范交给模型去执行而不是让模型另搞一套不讲规矩的脚本。5. 常见问题与排查技巧实录5.1 自动化用例执行不稳定的排查表自动化用例跑起来不稳定是几乎每个测试团队都会遇到的事。这里我把平时归类过的高频问题、常见原因和排查思路整理成一个速查表方便大家在实际工作中对照排查现象常见原因排查思路建议元素找不到页面加载慢、定位器失效查看失败截图和日志复现定位表达式改用显式等待优先用>