在外行眼里自动化测试是解放测试工程师的神器脚本一跑躺平收工。但真正在一线带过自动化测试项目的人都知道这个项目可能是团队里死得最快、最惨的一个。90%的失败率不是一个精确的统计数字而是行业里流传多年的一句话可这句话背后是无数个“轰轰烈烈启动、悄无声息废弃”的真实项目。我自己就亲眼见过好几个投入几十上百人日最后只剩下一个没人敢跑的测试套件和一堆永远修不完的红灯脚本。所以我想把这几年踩过的坑系统性地聊一聊。为什么这么多自动化测试项目会失败不是脚本写不好而是从选型到设计、从指标到维护整个链路里到处是隐蔽的坑。这篇内容适合正在搭建自动化测试框架的测试开发工程师、被领导点名要“上自动化”但不知道怎么落地的测试负责人以及刚入行想少走弯路的QA同学。我会把失败拆成几个层次每个层次都给出可落地的解决办法。1. 失败的第一层原因把自动化测试当成“录制回放”的脚本工具1.1 录制回放为什么“今天能跑明天就崩”我见过太多项目是从录制回放开始的。Selenium IDE、Appium Inspector、Airtest这些工具都有录制能力操作一遍页面脚本就自动生成了。乍一看效率极高两小时就能“写”出一套用例。但问题恰恰出在这里录制工具生成的脚本本质是把你的操作翻译成坐标、控件树节点或者固定的等待时间它没有语义不理解业务更不理解页面的结构。举个真实的例子。有次我用录制工具生成了一条购物流程脚本跑得很顺畅。结果前端同事第二周改了一个按钮的文案从“立即购买”改成“马上购买”录制脚本里的文本定位就直接失效了。我花了整整一下午重新录制这条用例。更离谱的是类似的按钮在页面上有七八个前端顺手调整了一个CSS类名又崩一片。录制回放还有一个致命弱点固定等待。录出来的脚本里全是sleep 3秒、sleep 5秒网络快的时候白白浪费时间网络慢的时候照样失败。你改也不是不改也不是。当团队用这种方式堆到100条用例时维护成本就开始指数级上升——不是3倍的维护量是10倍。最后的结果往往是没人敢动套件每次跑完都是几十个红灯大家假装没看见直到领导问起来才去修。更深层的问题是录制回放把“测试意图”和“页面实现”死死绑在了一起。测试意图应该是“用户能否完成下单支付”而页面实现随时会变。如果你不在中间加一层抽象只要页面结构一变测试意图就跟着崩。这不是工具的问题是用法的问题。1.2 自动化测试的本质是软件工程不是写脚本很多团队把自动化测试当作“写脚本”这是最根本的认知错误。自动化测试代码和业务代码没有本质区别它同样需要设计、分层、评审、重构和维护。你写业务代码的时候不会把一万行逻辑全部塞进一个文件里你怎么写测试脚本的时候就这么干了正确的做法是把自动化测试当成一个独立的软件项目来运营。首先需要分层测试数据管理一层页面对象一层用例逻辑一层公共方法一层。每一层的职责要清晰页面对象层负责元素定位和页面操作用例层只关心业务步骤和断言这样前端改了元素你只需要改一个页面对象文件而不是100条用例。可维护性之外还有可观测性。自动化测试跑失败的时候你至少需要以下信息失败在哪个步骤、当时的页面截图、页面的HTML源码、完整的控制台日志、网络请求的上下文。没有这些排查问题全靠瞎猜。我见过太多项目失败日志只有一行AssertionError没有任何截图也没人愿意去翻日志结果红灯挂在那里一周都没人管。说实话如果一条自动化用例出了问题你不能在5分钟内定位到原因那这个套件就是在消耗团队的生命。工程化的核心目标不是“写更多的用例”而是“让现有用例稳定、可维护、可观测”。2. 失败的第二层原因选型混乱什么火上什么2.1 先搞清楚你到底要测什么UI自动化、接口自动化还是单元测试很多项目一上来就直奔UI自动化因为UI自动化最直观录个视频发给领导看效果特别有成就感。但UI自动化恰恰是整个测试金字塔里成本最高、稳定性最差、反馈最慢的一层。一个正常的业务系统UI自动化的编写成本通常是接口自动化的3到5倍而执行一次完整UI回归可能需要半小时以上还没算上环境不稳定带来的重跑。接口自动化是绝大多数项目性价比最高的选择。它直接绕过界面通过HTTP、RPC或消息队列验证业务逻辑速度快、稳定性好、维护成本低。一个下单接口的自动化用例跑一次只需几百毫秒而对应的UI用例可能要跑几分钟中间任何一个弹窗、加载动画、网络波动都能让它失败。所以在资源有限的情况下我的建议是先搭接口自动化再补核心UI流程。往上走还有单元测试和契约测试。单元测试能在代码提交阶段就发现逻辑错误契约测试能保证服务间接口的兼容性。但这些需要研发团队配合QA如果没有足够的代码能力很难独立推进。你需要认清自己的处境如果你是团队的测试负责人能推动研发一起做就往底层多投入如果只能靠QA自己搞那就老老实实把接口自动化和核心UI回归做好。盲目追求全链路覆盖结果必然是全链路都烂。2.2 工具选型的真实逻辑Selenium、Appium、Playwright、Airtest怎么选工具选型是一个特别容易被带偏的环节。网上一搜“自动化测试框架”铺天盖地都是Selenium但Selenium真的适合你吗不一定。我按自己实际使用体验整理了一个对比表工具适用场景最大优势最大痛点SeleniumWeb端传统项目生态成熟浏览器兼容全面等待机制老旧需要自己封装PlaywrightWeb端现代项目自动等待Trace Viewer调试多浏览器社区比Selenium小一些Appium移动端App支持iOS、Android、H5真机/模拟器环境组合太复杂Airtest游戏、部分App图像识别不需要源码图像定位不稳定回调慢Playwright是我现在做新项目时的首选。它的自动等待机制能帮你消灭一大半sleep代码结构也干净。更实用的是Trace Viewer跑完一条用例之后能回放整段浏览器操作排查问题效率极高。Selenium也不是不能用但如果你的团队没有精力去封装显式等待、重写日志系统我劝你直接用Playwright。Appium和Airtest的坑更隐蔽。移动端的碎片化是超乎想象的同一个Android版本在不同厂商的ROM上表现都不一样iOS系统升级又频繁纯UI层的移动自动化维护成本非常非常高建议只在核心冒烟场景使用Airtest做图像识别兜底快速验证“App还能不能正常打开、登录、进入主页面”。不要试图用Appium把整个App的所有功能都自动化那基本等于自杀。2.3 语言与框架要和团队能力匹配而不是和潮流匹配选型的时候经常遇到这种情况团队里全是Python背景但网上教程推荐JavaTestNG于是硬着头皮上了Java。结果写出来的代码充满了“复制粘贴”因为没人真正理解Java的依赖注入和TestNG的配置体系。这不是语言的问题是选型的问题。我的原则很简单团队谁会就选谁的语言。如果你团队里只有Python那就用pytestrequests做接口自动化用Playwright做UI自动化这套组合已经能覆盖八成需求了。如果团队是Java体系那就用RestAssuredTestNG或者Spring Cloud Contract没必要为了“潮流”去切换语言。框架层面也要节制。很多新项目上来就要搞DockerKubernetesJenkins全链路还没开始写用例先把基础设施折腾了一个月。实际上一个pytest项目配合GitLab CI或者Jenkins的定时任务已经能解决90%的自动化执行问题。先把“每天能自动跑一遍、结果能自动发出来”这件事做扎实再谈分布式执行和容器化编排。我见过太多团队把大量精力花在“框架很漂亮”上结果实际用例只有二十几条而且全是冒烟级的。记住框架是给用例服务的不是反过来。3. 失败的核心技术坑“非预期弹窗”与稳定性设计3.1 非预期弹窗有哪些为什么能让整个项目废掉“非预期弹窗导致失败”在中文测试圈搜索量极高这个关键词背后的惨痛经历估计每个做过UI自动化的同学都懂。什么是非预期弹窗就是你脚本里压根没计划处理的弹窗版本更新提示、活动弹窗、功能引导、权限申请、评价邀请、Cookie同意甚至是崩溃后的恢复弹窗。它们不知道什么时候就会出现一次更新弹窗就能让你的整条自动化流程全部错位。弹窗的破坏力在于它不是让脚本“报错”而是让脚本“跑错”。你本来要点击“提交订单”结果弹窗遮住了按钮脚本可能点到弹窗的关闭按钮并切走了页面最后断言失败。更麻烦的是弹窗的问题是偶发性的环境不同、账号不同、用户配置不同弹窗出现的时间也不同。你修完一个明天又来一个新的。当这类失败频繁出现时团队会进入一个恶性循环用例红了一堆大家第一反应是“又是弹窗吧”而不是去分析业务逻辑是不是真的坏了。久而久之自动化测试结果失去了公信力连正常失败也没人信了。项目自然就慢慢废掉。别笑这几乎是所有死掉的UI自动化项目的心路历程。3.2 治理非预期弹窗的4个实用策略弹窗问题不能靠“发现一个修一个”要用体系化的方式治理。我实战下来比较有效的策略是下面四个第一个是测试环境开关治理。这是治本的办法。跟开发团队约定测试环境提供一套开关配置能一键关闭所有活动弹窗、更新提示、功能引导。很多公司的弹窗都挂在配置中心或活动服务上QA完全可以申请一个专用的测试环境配置把这些干扰源全部关掉。只要环境干净了弹窗问题直接减少七成。第二个是通用弹窗检测函数。不管测试环境关得多干净总有些弹窗是关不掉的比如权限弹窗、系统级弹窗。所以要写一个公共函数专门扫描当前页面上常见的弹窗元素发现就关闭。每次点击操作之前调用一次把弹窗的影响降到最低。这个函数的代码我放在3.3节可以直接抄。第三个是页面对象模型上的弹窗处理层。常规的Page Object只封装业务页面但弹窗是横跨所有页面的所以要单独做一个popup_handler层让所有页面对象都能调用它。不要在每一条用例里自己去定位“以后再说”“我知道了”这些按钮那样光是弹窗元素定位的维护就能拖垮你。第四个是兜底恢复机制。如果正常操作超时了不要立刻失败先进入弹窗扫描分支尝试识别并关闭常见弹窗然后重新执行点击。这相当于给自动化脚本加了一层“免疫系统”能挡住大部分不可控的弹窗干扰。当然兜底逻辑要控制重试次数防止死循环。3.3 一段可落地的弹窗兜底代码示例以PlaywrightPython为例我写了一个通用的弹窗兜底函数核心思路是“先正常操作超时后扫描弹窗并重试”。这段代码可以直接放到你的utils目录下使用。# popup_handler.py import logging from playwright.sync_api import Page, TimeoutError as PlaywrightTimeoutError logger logging.getLogger(__name__) # 常见的弹窗文案/选择器按团队实际情况扩充 POPUP_PATTERNS [ text立即更新, text以后再说, text我知道了, text跳过, text同意并继续, text取消, .modal-close, [aria-labelClose], ] def close_popup_if_present(page: Page, timeout: int 3) - bool: 扫描并关闭当前页面上的常见弹窗成功则返回True for pattern in POPUP_PATTERNS: try: locator page.locator(pattern).first if locator.is_visible(timeouttimeout): locator.click(timeouttimeout) logger.info(已关闭弹窗: %s, pattern) return True except Exception: # 元素不存在或不可见继续尝试下一个模式 continue return False def safe_click(page: Page, selector: str, retries: int 3): 先尝试点击目标元素超时后扫描弹窗并重试 for attempt in range(retries): try: page.locator(selector).click(timeout5000) return except PlaywrightTimeoutError: logger.warning(第 %s 次点击失败扫描弹窗, attempt 1) closed close_popup_if_present(page) if not closed: if attempt retries - 1: raise这段代码的逻辑很简单每次点击目标元素失败时先扫描一遍常见弹窗关掉之后重试。它的价值不在代码本身而在于“每次失败都先处理弹窗”这个设计思路。用了这个函数之后我项目的核心流程通过率从82%提到了97%以上。当然真正的治本还是环境治理弹窗兜底只是兜底不能当作清理弹窗的唯一手段。4. 失败的组织原因没有度量也没有维护机制4.1 自动化测试的度量指标什么值得看什么一文不值很多项目做失败不是因为技术不行而是不知道该怎么衡量这件事做得好不好。领导问“自动化进展怎么样”回答永远是“写了200条用例”。但200条用例能说明什么如果全是重复的冒烟用例根本不测核心逻辑那这200条就是一堆数字垃圾。我在团队里看自动化项目只关心五个指标通过率、稳定性、执行时长、维护成本、真实Bug发现数。通过率要达到95%以上低于你就要停下来查稳定性指同一版本连续三天跑脚本通过率能不能保持一致证明你的用例不依赖环境顺序执行时长上核心回归套件应该控制在30分钟以内超过1小时的套件基本没人看结果维护成本是每周修脚本花了多少人时超过开发时间的20%就说明设计有问题最后是真实Bug发现数自动化测不出Bug那就只配叫“冒烟工具”不配叫“测试”。反过来有几类指标一文不值用例总数、覆盖率百分比、单次执行通过率。覆盖率再高如果全在最容易测的路径上核心场景全是漏洞那这个覆盖率就是骗自己的玩艺。我见过一个项目覆盖率90%听起来吓人但最关键的支付链路根本没覆盖因为支付流程不好造数据被团队“战略性放弃”了。4.2 CI/CD集成让自动化从“玩具”变成“体检”如果自动化脚本只是放在本地跑那它永远只能算玩具因为人总有偷懒的时候。真正让自动化产生价值的动作是把它挂到CI/CD流水线里让它变成持续集成的一部分。我的建议是分三个层次逐步完善。第一层是定时执行每天晚上凌晨跑一遍完整回归套件第二天早上大家上班之前把结果发到群里。第二层是提交触发在MR阶段只跑快速冒烟测试5分钟出结果开发提交代码的时候能立刻知道有没有破坏核心功能。第三层是失败通知集成到IM机器人和邮件红灯了要有人响应。失败重跑策略也要认真设计。Flaky用例不要一失败就无限重跑这是自欺欺人。我最多允许重试两次而且重试通过的用例会自动标记为“flaky”每周汇总一次。如果一个用例连续一周都在重试标记里那说明它要么是环境问题要么是定位方式有问题必须停下来修而不是让它靠运气“绿”。报告系统同样重要。Allure报告是个不错的选择能在报告里展示截图、日志、每个步骤的耗时大家才愿意点开看。如果报告只是一个纯文本的“PASS/FAIL”列表那团队很快就不会再去看了。4.3 维护机制自动化不是一次开发、终身使用业务系统每天都在变自动化脚本如果不跟着变三天就烂。但“跟着变”这件事需要有制度和owner来保障。首先要有一个明确的负责人。自动化测试项目绝对不能没人管即使不是专职也要指定一个owner。这个人要对套件的整体健康负责定期梳理用例状态删除废弃用例推动稳定性问题修复。没有owner的项目就像没有人扫地的屋子只会越来越脏。其次要做代码评审。测试脚本一样要Review。我见过最恐怖的情况是团队里只有一个人会写自动化他写的脚本别人看不懂他一离职整个套件就瘫痪了。代码评审不是为了挑刺而是保证代码风格统一、逻辑清晰至少要有两个人能接手维护。最后是变更联动机制。当产品需求变更、前端页面改动的时候测试脚本必须同步更新。最好能在需求评审阶段就通知自动化负责人而不是等脚本红灯了才发现页面改了。变更联动做得好的团队每次版本发布前后自动化通过率几乎不受影响做不好的团队版本发布日就是自动化项目祭日。5. 面对AI自动化测试新机会但也有新的坑5.1 AI在自动化测试里的真实角色辅助生成、自愈、诊断最近AI自动化测试成了热门话题从Codex Agent自动写测试到Playwright结合AI做自愈再到各种AI测试平台确实给这个领域带来了新的可能。很多人问我怎么看我的观点是AI确实能解决一部分痛点但它的角色是“辅助”不是“替代”。目前比较成熟的AI能力有三个方向。第一是自然语言生成用例你描述“用户登录后添加商品到购物车并结算”AI帮你生成Selenium或Playwright代码这个对新项目起步很有用能快速搭出雏形。第二是定位器自愈当元素定位失效时AI会自动对比前后的DOM结构变化预测并修复选择器这直接针对UI自动化维护成本最高的环节。第三是失败诊断脚本失败后AI分析截图和日志自动归类失败原因是环境问题还是业务问题节省大量人工排查时间。这些能力用到实处确实能把自动化项目的维护成本降一个量级。以前修10条失败用例可能要我一下午现在AI帮我自动分析归类再给出修复建议可能一小时就能搞定。效率提升是真实的。5.2 AI解决不了的问题需求盲区、环境造数、人的信任但AI解决不了的根本矛盾它依然是“放大器”——你有一个好的自动化体系AI能帮你做得更好你有一个烂的自动化体系AI只是帮你更快地生成一堆垃圾。最典型的坑是需求盲区。AI不知道业务真正重要的是什么你让它生成用例它会照着最常见的路径生成但核心业务逻辑里那些“刁钻”的边界场景AI根本不会主动覆盖。它不会问“如果用户余额不足但是有优惠券支付应该走哪条分支”因为它没有业务语境。自动化测试的本质是“把业务需求翻译成可执行断言”这个翻译过程AI目前做不了只有懂业务的人才能做。环境造数问题AI也解决不了。接口自动化跑得稳不稳很大程度取决于测试数据能不能稳定准备。很多团队连测试库都连不上每次跑之前都要手工造数据AI再强数据没准备好脚本一样红灯。我见过一个项目用AI生成了几百条用例结果80%都因为没有测试账号导致执行失败最后全部删掉重来。更隐蔽的是信任问题。如果AI自动修复了定位器测试变绿了那这个绿色是真的代表功能正常还是AI修错了元素导致断言失效团队对AI自动修复的结果会产生不信任感时间长了大家又开始忽略绿灯回到“自动化是玄学”的旧状态。所以AI落地必须配合可追溯、可审计的机制。5.3 落地AI的正确姿势小步试点可度量验证AI落地最忌讳“上来就全上”。我的建议是先在维护成本最高的环节做小范围试点比如失败脚本自动诊断、定位器自愈这两个是无论什么项目都能用上、而且ROI最高的方向。选2到3条核心业务流用AI辅助跑两周记录两件事维护耗时降了多少通过率有没有提升。用数据说话行就扩大范围不行就及时止损。另外一个原则是AI生成和修复的脚本必须有人Review。不能让AI直接往main分支提交代码。这不是不信任AI而是因为测试代码的错误定价非常高一个错误的断言可能让一个严重Bug蒙混过关这个风险谁都扛不起。我个人的判断是未来三五年内AI会把自动化测试的维护成本拉下来一大截但自动化测试的骨架依然是工程化的设计、合理的分层、稳定的数据环境。AI是加分项不是救命稻草。如果你的自动化项目本身已经摇摇欲坠别指望AI能救活它先对照前面几个章节把体系搭好再说。6. 从0到1搭建一套能活下来的自动化测试体系6.1 范围评估什么项目值得做自动化什么不值得你得多花点时间想清楚一个问题手上的项目到底适不适合做自动化不是所有项目都适合选错了项目后面做得再精细也是白费。适合自动化的项目长这样需求相对稳定核心功能半年内不会大改长期有回归需求每次发版都靠人工重复验证跨端场景多人肉测容易遗漏接口契约清晰数据结构相对固定。反过来哪些不适合快速原型验证产品还在摸索方向UI一天一改一次性活动页面活动结束就下线要求一周发三次版、需求频繁变更的敏捷项目自动化脚本根本追不上变化速度。落地顺序也有讲究。我建议严格执行“先接口、再UI、最后边缘场景”的顺序。拿电商项目举例先把下单、支付、退款、优惠券这些逻辑的接口自动化做好保证核心业务流程的逻辑永远不出错然后再补UI冒烟覆盖“用户能打开App、能登录、能完成一单支付”这条最核心的路径最后有余力再去覆盖筛选、搜索、详情页这些边缘场景。顺序反了必然事倍功半。6.2 分层架构与最小目录结构不用追求一开始就设计一个完美无缺的框架但基本的目录规范必须有。我会给团队定一个最小目录结构让每个人进来都能很快找到自己该改的文件。autotest/ ├── api/ # 接口封装层一个业务接口对应一个类 │ ├── __init__.py │ ├── order_api.py │ └── login_api.py ├── page_objects/ # UI页面对象层一个页面对应一个类 │ ├── __init__.py │ ├── login_page.py │ └── cart_page.py ├── testcases/ # 用例层按模块拆文件 │ ├── __init__.py │ ├── test_login.py │ └── test_order.py ├── data/ # 测试数据使用yaml/json/数据库封装 │ ├── accounts.yaml │ └── test_data.py ├── utils/ # 公共工具 │ ├── __init__.py │ ├── waiters.py │ ├── popup_handler.py │ └── report.py ├── conftest.py # pytest的fixture定义 ├── requirements.txt └── pytest.ini这套结构里最核心的约束是依赖方向testcases依赖page_objects和apipage_objects和api依赖utilsdata被各层共享。元素定位只存在于page_objects里业务断言只存在于testcases里日志、等待、弹窗处理只存在于utils里。这样改了元素定位用例层一点都不用动改了业务逻辑页面对象层不动。我见过太多项目把所有元素定位直接写在用例文件里那和把数据库代码写在界面逻辑里是一个味道只是在等待重构日的到来。6.3 稳定性设计的3个关键点等待、数据隔离、失败恢复写用例之前先把稳定性设计的三个基础打牢否则你后面加多少用例都是在沙滩上盖楼。第一是等待策略。固定sleep是最差的做法直接禁用。优先级是显式等待高于隐式等待高于固定sleep。用Selenium的时候WebDriverWait配合expected_conditions是标准姿势用Playwright就更省心它自带自动等待但碰到复杂异步逻辑仍然要显式等。记住一个原则等的是一个条件不是等一个时间。条件满足了立刻往下走不满足就超时失败而不是傻等5秒。第二是数据隔离。每条用例必须使用独立的测试账号和测试数据用完之后清理。不要让用例A的数据影响用例B否则遇到“第一次跑通过第二次跑失败”这种问题你查上一天都查不出来。常见做法是每个用例前置准备数据后置清理数据。如果环境不支持动态造数那就用独立的测试账号池每个线程分配一个账号保证互相不污染。第三是失败恢复。每条用例失败时必须自动收集现场截图、页面HTML、调用栈、关键日志。运行结束后自动汇总到报告里。真出问题的时候这些现场信息能帮你10分钟定位而不是花半天去复现。Playwright的trace模式尤其好用开启后可以完整录制页面操作过程排查问题效率翻倍。7. 常见问题与排查技巧实录7.1 元素定位一直失败的7个排查路径写完自动化脚本之后遇到最多的就是元素定位失败。这里我把排查路径整理成一张清单按顺序排查解决大部分定位问题绰绰有余。一是动态ID很多前端框架会生成一次性的ID比如idbtn_123456这种ID每次刷新都会变必须改用稳定的class、name或者data-testid。二是iframe如果元素在iframe里你直接定位肯定找不到必须先切换到对应的frame。三是Shadow DOM现代前端组件库经常用Shadow DOM封装普通选择器进不去需要用pierce或相应的Shadow DOM定位方式。四是新开的窗口或标签页点击按钮之后浏览器开了新页面但你的脚本还停留在旧页面需要显式切换。五是懒加载元素在页面上要滚动到可视区域才会渲染没滚动之前不在DOM里。六是样式和文案选择器里写死了某个CSS类名或按钮文字前端只要改一个类名或者改一个字就崩。七是悬浮或者动画元素被遮挡或者还在过渡动画里点击不生效。每次遇到定位失败先不要急着改选择器按上面这条路从头走一遍。我发现大部分定位问题都是“忘了切iframe”或者“用了动态ID”这种低级错误。真正需要花大力气解决的情况很少。7.2 偶发失败Flaky到底怎么查偶发失败是自动化项目里最折磨人的问题。昨天跑得好好的今天没改任何代码突然红了重跑一遍又绿了。这种用例如果不处理团队对自动化结果的信任会一点一点被磨光。查Flaky问题不能靠猜要靠证据。我的标准做法是先看截图和视频确认失败现场是什么状态然后看日志定位到失败的具体步骤再看网络请求是不是请求超时或者返回了错误码最后看执行环境是不是测试环境同时在跑其他任务导致资源争抢。大多数Flaky问题跑完这套排查流程基本都能找到根源常见来源无非是网络延迟、环境脏数据、非预期弹窗、资源加载超时这几个。对于临时缓解可以允许Flaky用例重试两次但必须标记出来并且每周统计一次Flaky列表列入修复计划。绝对不能允许一个用例长期靠重试维持绿色这会让自动化结果彻底失真。我见过一个项目重试策略被滥用到一个用例最多能跑13次成功率不到50%还硬撑着“变绿”这种情况真不如直接把用例删了。7.3 执行时间太长怎么优化自动化套件规模上来之后执行时间会是新的瓶颈。一套几百条的UI用例串行执行可能要跑三四个小时等出结果的时候黄花菜都凉了。核心回归一定要控制在30分钟内否则大家真的不会去看结果。优化方向有三个。一是并行执行用pytest-xdist多进程跑或者用Selenium Grid、Playwright的worker并发把用例拆成多个进程并行执行。并行执行前先确认你的测试账号和测试数据支持并发不然账号互相挤下线结果只会更糟。二是分层执行把冒烟测试、核心回归、全量回归分开平时只跑冒烟和核心回归大版本发布前才跑全量。三是按需触发只有影响核心功能的代码变更才触发UI回归其他变更跑接口自动化就够了。我现在带的项目线上核心回归套件有300多条UI用例加上1000多条接口用例总耗时控制在25分钟以内。靠的就是并行执行加合理分层。如果执行时间超过一个小时绝大多数团队成员不会看结果自动化就变成了一个“自嗨”的摆设。我个人这几年最大的体会是自动化测试失败从来不是技术问题而是预期管理和工程化水平问题。别指望一套自动化能测出所有Bug它的核心价值是把重复劳动自动化让测试工程师把精力集中在探索性测试和真正复杂的业务场景上。如果你接受不了“前期投入大、后期才能见效”这个节奏那还不如不开始。最后分享一个我给自己团队定的“红不过三”原则连续三天通过率低于90%就停止新增用例把现有脚本的稳定性修好再继续。我以前不懂这个道理脚本越堆越多红灯越亮越久最后整条流水线直接废弃。希望这篇文章能让你的自动化测试项目成为活下来的那10%。