在自动化测试的圈子里待久了你会发现一个特别有意思的现象十个人的UI自动化脚本里有八个人的第一个用例都是从“登录”开始的但登录恰恰是整套自动化体系里最脆弱的环节。验证码、二次校验、短信、扫码、企业微信审批、单点登录跳转……任何一个环节抽风后面的所有用例直接全军覆没。所以“UI自动化-跳过登录进行项目的后续操作”这个需求几乎在每个项目里都会被提出来我今天就好好聊聊这件事。先把这个需求翻译成人话我想测的是“登录之后”的页面和流程但我不想每次跑脚本都从登录开始想直接把系统“变成已登录”的状态然后专心做后续操作。听起来很简单但里面藏着方案选型、会话机制、并发隔离、测试数据预置等一堆问题。这篇文章不是给你背概念的而是把我自己在多个项目里用过的方案、踩过的坑、调整过的细节全部摊开来写一遍。1. 一句话说清问题UI自动化为什么总卡在登录这一步在聊方案之前先把“为什么要跳过登录”这个根源问题掰开揉碎地讲清楚。因为很多人一开始就把这件事想窄了以为跳过登录只是为了“省时间”实际上远不止这一点。1.1 三个你绕不开的真实痛点第一个痛点是时间成本。一个正常的企业级系统登录链路普遍包括打开登录页、输入账号密码、拖动滑块或输入图形验证码、等待二次认证或短信验证码、点击确认、等待跳转、处理首次进入的弹窗引导。这一套走下来快则三十秒慢则两分钟。如果你的自动化用例有三百条其中有八十条需要登录态每一条多花四十秒那就是接近一小时的时间。这不是简单的“能忍耐”就能解决的问题它直接决定了你的回归测试频率——是从每天跑变成每周跑还是从每小时跑变成一天跑一次。第二个痛点是稳定性。登录环节是所有UI自动化用例里失败率最高的环节没有之一。图形验证码识别不了、滑动验证码轨迹不像人类、短信平台延迟、扫码需要人工介入、企业微信审批没通过、服务端风控把测试账号给临时封了……任何一个问题都会让用例挂在“登录”这一步。而登录一旦失败后面的断言全部失效。我在某项目的回归测试里统计过登录环节贡献了将近一半的失败用例跳过登录之后整条流水线的成功率肉眼可见地提高了二十个百分点以上。第三个痛点是环境依赖。很多系统的登录不只依赖前端还依赖外部认证服务、企业内网环境、SSO单点跳转。自动化环境一旦换了网络或者权限收紧登录链路可能整个不可用。但系统内部的很多主流程——查询、创建、编辑、导出——并没有那么强的外部依赖。跳过登录其实是在帮你把自动化测试和“脆弱且不可控”的外部认证环境做解耦。1.2 跳过登录到底解决的是什么跳过登录不是“绕过安全机制”而是把“获取登录态”这件事从UI层剥离出去换一种更高效、更稳定的方式去获得“已登录”这个前置条件。这和手动测试里“我让开发给我把登录状态锁一下”其实是同一个思路只是自动化测试需要把这件事做得更规范、更可重复。说白了你在生产环境不能这么干但在测试环境系统的目标之一就是“让测试人员更容易地测试功能”跳过登录页、直接获得测试所需状态是测试环境基础设施的一部分不是漏洞也不是偷懒。明确了这个前提后面所有的技术方案才立得住。2. 五种跳过登录的方案横向拆解从最省事到最可控跳过登录的方案五花八门我在不同项目里基本都试过。这里先给你一个全景图避免你一上来就扎进某个方案的细节里最后发现方向选错了。按“从简单到复杂、从笨办法到精细方案”的顺序排大概是下面五种。方案核心思路实现成本稳定性适用场景浏览器Profile复用复用带登录态的浏览器数据目录或用户目录最低中单机、少量用例、本地调试登录态文件注入保存Cookie/LocalStorage/StorageState后注入低中高中小规模前后端同域或Cookie鉴权为主接口换取Token再注入通过登录接口直接换Token再用Token初始化浏览器会话中高大多数前后端分离项目Token鉴权登录态中继服务独立账号服务维护统一登录态供多个执行机统一获取中高高分布式执行、并发跑量、多环境多账号测试后门/数据桩测试环境提供免登录开关或内置测试身份最低(工程上需要开发配合)极高测试专用环境团队内部系统有人会觉得“直接用测试后门最省事”但实际上很多项目的前端根本不提供这个入口开发也不一定愿意给你加。所以后门方案虽然有但往往取决于团队协作不是你想用就能用。真实项目里最常用的是接口换Token注入和登录态文件注入这两条技术路线。后面我会把这两条路线的原理和实操写透顺带把中继服务的思路也讲清楚。2.1 选型背后的三个判断标准方案不是越多越好关键是看你的项目到底适合哪个。我一般看三个维度。第一个维度是鉴权方式。系统是纯Cookie会话还是Token比如放在Header或LocalStorage里还是混合模式。Cookie会话相对简单浏览器层面就能搞定Token就不只要管Cookie还要管JS运行时里存的那份Token一旦过期可能出现“Cookie还在但页面接口全部401”的诡异情况。第二个维度是执行方式。本地单机跑还是Jenkins或者流水线分布式跑。单机跑你直接复用本地Profile就行但要上流水线每台机器的执行环境都是全新的就必须考虑登录态如何动态准备、如何传递。第三个维度是账号模型。一个测试账号跑全部用例还是按业务域分配多账号。如果只有一两个核心账号方案可以粗暴一点如果有成百上千个数据隔离的账号你必须要做账号池和登录态的动态分配这时候中继服务几乎是必然选择。3. 实操路线一Cookie/Token注入式登录态移植现在进入动手环节。先说最经典、也最容易理解的Cookie注入方案。它的核心思想是我先用任意方式拿到一套合法的登录凭证Cookie然后在每次启动浏览器时把这套凭证“塞”进新的浏览器会话里。听起来很直白吧但真正做的时候坑往往藏在细节里。3.1 第一步拿到一套有效的登录态获取登录态的方式有两种一种叫手动捞取适合本地调试一种叫接口换取适合自动化。手动捞取的逻辑很简单你手动打开浏览器完成登录然后用工具比如开发者工具Network面板或者浏览器插件把这个域名的Cookie抓出来保存成文件或环境变量。Selenium里最常见的做法是先把登录流程跑一次然后把driver.get_cookies()的结果用pickle或者JSON存起来后面直接用。以Python Selenium为例保存登录态的代码大概是这样的import pickle from selenium import webdriver driver webdriver.Chrome() # 正常走一遍登录流程或者直接人工登录 driver.get(https://demo.test-project.com/login) # 登录成功后调用这一句把当前所有Cookie保存下来 with open(cookies.pkl, wb) as f: pickle.dump(driver.get_cookies(), f) driver.quit()这段代码本身没什么稀奇但真正要注意的是Cookie的归属域。很多系统的Cookie不是全部挂在主域名下可能有login.demo.test-project.com、api.demo.test-project.com这些子域。你如果只用driver.get_cookies()不加筛选地保存注入的时候也原样注入通常没问题但一旦你只保存了部分域名的Cookie注入完可能仍然是未登录状态。所以我建议保存的时候加个断言确认关键Cookie存在。接口换取Token则稍微复杂一点但更“正规”。一般登录接口长这样import requests resp requests.post( https://api.demo.test-project.com/auth/login, json{ username: autotest_user, password: your_password, captcha: # 如果测试环境可以关闭验证码的话置空 } ) token resp.json()[data][token]但这里有个问题UI自动化里接口拿到的Token不一定能被前端识别。前端登录后Token不是只存在Cookie里很多SPA应用会把Token放到LocalStorage或SessionStorage里而且可能还要附带用户信息、权限信息等。所以在接入注入逻辑之前你先得搞清楚前端的鉴权存储模型——是纯Cookie、是LocalStorage、还是两者都有。这个排查方法很简单手动登录一次打开开发者工具的Application面板看Storage和Cookie区域都存了啥。3.2 第二步把登录态注入到新浏览器会话拿到了登录态下一步就是注入。我用Selenium写个标准示例import pickle from selenium import webdriver driver webdriver.Chrome() # 注意必须先打开一次目标域名否则没有domain上下文Cookie加不进去 driver.get(https://demo.test-project.com) # 清空旧Cookie避免残留干扰 driver.delete_all_cookies() with open(cookies.pkl, rb) as f: cookies pickle.load(f) for cookie in cookies: # Selenium的add_cookie对httpOnly、sameSite这些属性的支持各版本有差异 # 通常需要把不受支持的key先弹掉 if sameSite in cookie: del cookie[sameSite] try: driver.add_cookie(cookie) except Exception as e: print(fcookie添加失败: {cookie.get(name)}, {e}) driver.refresh() # 到这里应该已经是登录态 assert 欢迎回来 in driver.page_source这里有一个非常关键的先后顺序很多人第一次写都搞错必须先driver.get(域名)一次再去add_cookie。原因是Selenium加Cookie时浏览器需要有一个“当前站点”的上下文Cookie必须挂在某个Domain上。如果你一上来就add_cookie会直接报InvalidCookieDomainException。3.3 Token注入的两种细分姿势如果你面对的是Token鉴权系统注入方式还要再分两种情况。第一种情况Token是放在LocalStorage里的。那么你用Selenium执行一段JavaScript来设置driver.execute_script( localStorage.setItem(token, arguments[0]);, token_value )注意Token值如果含特殊字符最好用JSON.stringify包装过再传入否则容易把脚本搞坏。另一个细节是设置了LocalStorage后不能简单refresh就完事有些前端框架在初始化时会读取Storage里用户信息做二次校验如果只放了Token没放用户信息还是可能弹回登录页。第二种情况Token是放在HTTP请求头里的。这种情况稍麻烦前端登录后后续每个请求都带一个Authorization: Bearer xxx。如果你想跳过登录直接获取后续页面数据可以用CDPChrome DevTools Protocol在请求发出前统一注入Headerdriver.execute_cdp_cmd( Network.setExtraHTTPHeaders, {headers: {Authorization: fBearer {token}}} )这个方案的效果是浏览器发出的所有请求都会自动带上这个Header页面加载时就已经是登录态了。但缺点也很明显注入后对当前浏览器进程是“全局”的你要在用例开始前注入结束前记得清除否则会影响同session下其他用例。提示Token方案有个绕不开的命门——Token过期。Cookie方案里浏览器会自动续期一部分会话Cookie但Token的刷新逻辑通常在前端代码里你单纯注入一个Token一旦它过期且没有刷新机制用例就会莫名失败。所以Token方案一定要配套一个“Token即将过期时重新获取”的兜底逻辑。4. 实操路线二Storage-State与会话复用方案Selenium的Cookie注入是最经典的做法但你如果用的是Playwright有个更优雅的方案叫Storage-State。它本质上就是把整个浏览器的Cookie、LocalStorage、SessionStorage、IndexedDB等全部打包存到一个JSON文件里下次直接一个参数加载回来免去手动一个个Cookie去add的麻烦。4.1 Playwright的Storage-State用法先看保存登录态的过程from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessFalse) context browser.new_context() page context.new_page() page.goto(https://demo.test-project.com/login) # 手动登录或者通过某种方式登录 # 登录成功后 context.storage_state(pathstate.json) browser.close()执行完之后state.json里已经包含了该上下文的所有持久化数据。然后在新会话里一行代码直接加载context browser.new_context(storage_statestate.json) page context.new_page() page.goto(https://demo.test-project.com/home) # 此时已经是登录态这个方案的优点是省心你不用担心哪个Cookie该放哪个不该放一个快照全搞定。它特别适合那种“登录后一堆前端状态都变了”的重型系统——比如登录后菜单权限、用户头像、消息数量之类的信息全在Storage里Cookie注入方案可能还需要你额外去补这些数据Storage-State直接全量还原。4.2 Selenium的Profile复用以及它的兄弟方案如果你还在用Selenium又想达到类似“全量还原”的效果就得走浏览器Profile复用的路。Selenium启动Chrome时可以指定一个--user-data-dir参数让浏览器使用一份固定的用户数据目录from selenium import webdriver from selenium.webdriver.chrome.options import Options options Options() options.add_argument(--user-data-dir/path/to/your/profile) driver webdriver.Chrome(optionsoptions) # 第一次运行时手动登录一次之后这个目录里就保留了登录态 driver.get(https://demo.test-project.com/home)体验上其实不错尤其是本地开发调试场景跑起来非常顺手。但它有个致命的代价Profile目录是“有状态”的一旦损坏或锁定就全完。多进程并行跑自动化时如果两个driver用了同一个Profile目录Chrome会直接报错“Profile is already in use”。所以这套方案基本只适合单人、单机、串行执行的场景。实际上还有一种跟Profile复用类似思路的另外一条路线就是复用浏览器实例本身。通过某种方式启动一个长期运行的Chrome实例测试脚本不断连接这个实例来跑用例登录态自然就一直保留着。但维护成本会更高我这里不推荐新手去搞。4.3 会话复用方案的局限在哪里会话复用和Storage-State这类方案的共同局限在于执行环境的稳定性。你存的是“某一时刻”的登录快照但服务端的会话可能已经失效或者权限配置已经发生变化你的本地快照却还是老的。尤其是分布式流水线上每台执行机都要重新拉取一份最新的登录快照文件管理本身就成了新的麻烦。所以我的建议是本地调试、快速验证用Storage-State或Profile复用而真正的CI流水线、多机并行等严肃场景还是老老实实用接口动态换登录态或者搭一个登录态中继服务。5. 登录态中继把“跳过登录”从hack变成工程前面讲的几个方案本质上都还停留在“单机单次”的范畴。一旦你的自动化用例量大、执行机多、账号多你会发现一个新的问题登录态不是用来“省”的而是用来“发”的。这时候就需要一个账号与登录态的中继服务。5.1 中继服务的整体架构这么说吧中继服务的核心职责就三件事管账号、管登录态、管分发。它内部会维护一批测试账号每个账号都有对应的登录态存储执行机发起请求时中继服务会分配一个空闲账号的登录态给对应用例用例跑完后中继服务负责回收登录态、判定登录态是否过期、是否需要重新登录。这个逻辑拆开来大致是这样一个流程测试用例启动前向中继服务请求一个有效的登录态。中继服务从账号池里挑一个可用账号检查其登录态是否有效。如果有效直接返回如果失效由中继服务内部完成一次登录刷新登录态后返回。执行机拿到登录态注入到浏览器console context或请求层。用例执行结束后把登录态归还给中继服务中继服务更新最后使用时间和状态。你可能会想这玩意儿不就是一个“登录态的Redis缓存”吗本质确实类似但你别小看它。它解决的几个实际问题都很关键登录态不落地在测试脚本里账号密码不散落在代码仓库里多机器并发时不会多个进程抢一个账号互相踢下线。5.2 账号池设计与并发隔离的细节中继服务最容易翻车的地方就是并发隔离没做好。举个例子你有两个用例同时需要操作同一个账号结果为了跳过登录两边都从服务端拿到了同一个账号的同一个登录态两边同时发起操作服务端会判定异地登录把先登录的那边踢下线。这就不是你跳过不跳过登录的问题了而是你根本不该让两个用例同时共享同一个账号。所以账号池设计的第一原则是一个账号同一时刻只能被一个执行进程占用。用数据库或者Redis做锁取号的时候给账号加锁归还的时候解锁。并发不够就加账号账号不够就加锁排队。第二原则是登录态要按账号维度隔离存储。不是说你把整份登录态塞到一个全局变量里就行得能支持“按账号查询、按账号更新”。不然你在A账号的会话里不小心用了B账号的Token排查问题的时候会非常痛苦。第三原则是定期心跳续期。很多登录态其实是会随着时间自然过期的如果等你用的时候才发现过期你还得现场重新登录这就失去了跳过的意义。中继服务应该有一个后台任务周期性检查账号池里所有登录态的有效性快到期的自动续期或重新登录保证“取出来就能用”。5.3 还没到那一步前用“接口预处理”垫一下并不是所有项目都需要一步到位整个中继服务。很多时候你只是想“让用例不要从登录页开始”这时一个轻量级的接口预处理逻辑就够用了。所谓接口预处理是在测试用例的setup阶段调用登录接口获取Token再调用几个业务准备接口把测试数据也一起准备好。典型的流程是import requests from selenium import webdriver def setup_test_data(): # 1. 获取登录态 token get_token_from_api() # 2. 调用业务接口准备数据 requests.post( https://api.demo.test-project.com/order/create, headers{Authorization: fBearer {token}}, json{sku: SKU001, qty: 2} ) # 3. 返回token供UI层注入 return token def test_create_order_flow(): token setup_test_data() driver webdriver.Chrome() driver.execute_cdp_cmd( Network.setExtraHTTPHeaders, {headers: {Authorization: fBearer {token}}} ) driver.get(https://demo.test-project.com/order/list) # 直接断言列表里是否出现了SKU001 assert SKU001 in driver.page_source这种做法把“跳过登录”和“测试数据准备”两件事合在一起办了非常省事。它的稳定性主要取决于你系统接口的稳定性——接口要是也时常抖动那你就得考虑接口重试和失败降级。6. 全链路避坑常见故障与排查技巧实录方案讲了一堆最后还是要把这些年人人都会遇到的坑一个个摆出来。我把这些问题按“症状→原因→解法”的方式整理成一个速查表后面再挑几个展开细说。症状常见原因对策Cookie注入后页面仍然未登录Cookie域名/路径与当前访问地址不一致用开发者工具核对Cookie的Domain和Path属性注入后接口大量401Token存在LocalStorage里但请求头没带用CDP注入请求头并确认前端读取Token的字段名用例执行一段时间后突然全部失败登录态自然过期增加登录态有效期检查和自动续期逻辑两个用例同时跑互相把对方踢下线同一账号被并发会话使用账号池加锁或按用例拆分独立账号新机器上执行登录态文件不存在登录态文件未纳入版本管理或未上传到执行环境把登录态获取做成首次前置步骤而不是手动保存跳过登录后依然被判定为人机异常跳过登录不表示跳过风控操作行为模式异常调整操作节奏模拟真实用户行为必要时走白名单Playwright加载storage_state后界面错乱存储里带上了过多无效状态按域名过滤存储数据或者重新生成快照6.1 “Cookie明明加进去了为什么还是没登录”——最隐蔽的一个坑这个问题的诡异之处在于你去浏览器里看Cookie列表里确实有登录凭证但刷新后前端还是找不到登录态。最常见的原因是前端把自己的登录态标志存在了LocalStorage里而不是Cookie里。很多前端框架默认会把Token存在localStorage里你要是只往Cookie里塞当然没用。排查方向很简单手动登录一次看开发者工具Application面板把“登录后新增存储项”都列出来哪些是Cookie、哪些是LocalStorage、哪些是SessionStorage然后按上面的方法分别注入。再一个隐蔽点有些页面在加载时会根据URL参数或者请求头判断是否初始化用户信息如果你跳过登录页直接访问内部页它可能根本不触发用户信息初始化逻辑。这种时候要么补一个“初始化用户信息的接口调用”要么做一次页面范围内的localStorage注入后让前端自己走初始化分支。6.2 “跳过登录后用例跑得飞快但断言全挂在边界数据上”这个问题不是登录方案本身的bug而是跳过登录以后带来的衍生问题。正常UI登录时系统可能会弹“首次登录引导”、“新手教程弹窗”、“消息未读数红点”之类的组件这些组件只有登录后首次进入才会触发。如果你用Storage-State直接还原了一个“已经登录且所有引导都完成过”的状态那没问题但如果你只用Cookie注入没有把前端的状态变量存进去那么每个用例进入页面时系统都会弹一堆引导把原有的元素定位全部打乱。解决方案有两个要么在用例开始时用脚本统一关闭引导组件要么在做Storage-State快照时先手动把所有引导关一遍再保存。后者更省事因为后续每次加载都是“干净的已登录状态”。6.3 “登录态文件在本地怎么跑都行一上流水线就废”这是因为流水线执行机的环境和本地不同。本地是同一个浏览器Profile、同一个文件路径、同一个域名解析但流水线是全新容器或全新虚拟机文件不存在、域名解析可能连到不同的测试环境、甚至Chrome版本都不同保存的Cookie格式也可能不兼容。所以我在项目里的做法是登录态文件一律不提交到代码库。生成登录态的前置脚本会放在流水线的“准备阶段”执行每次跑之前先动态生成一份最新的登录态再注入到测试进程。要保存成文件的话文件路径也放到临时目录不占用仓库。这样做还有一个好处就是登录态永远是“最新的”不会因为过期导致用例莫名失败。6.4 关于风控和验证码我必须多说两句很多人把“跳过登录”理解成“绕过验证码”这是完全错误的。跳过登录只是让你以更高效的方式进入“已登录状态”但如果你的系统在后续操作中还有行为风控、频率限制、滑块校验这些依然会触发。特别是你用自动化脚本疯狂刷接口或者极快地点击页面风控系统照样能识别出来。应对方法是在测试环境做两件事一是把当前测试账号加入白名单二是设置操作间隔。自动化测试里每个步骤之间加一个小小的等待不是浪费时间而是模拟真实操作节奏。另外如果在测试环境能关闭二次校验就关掉关不掉的再考虑在登录环节用人工介入或者测试专用通道。7. 写在最后的经验之谈经过这么多项目的折腾我自己的体会很简单跳过登录这个需求技术实现从来不是最难的最难的是把方案嵌入到你的测试工程体系里并且让它在长期运行中保持稳定。不要一上来就想搞“最炫”的中继服务先搞清楚你的账号模型、执行方式和前端存储模型再用Cookie注入或Storage-State跑通最小闭环等量上来了再迭代。最后再分享一个很实用的小技巧无论你用哪种方案都要在用例执行前加一个“登录态有效性校验”最快的方式就是访问一个需要登录态的页面并检查关键元素或接口返回。别等到第一个断言失败才发现会话过期了那时候你排查半天最后只换来一句“哦Token过期了”真的不值得。