做测试的朋友应该都有这种体会普通Web功能测试做到后期最烦的不是某个按钮点不到而是“场景”这个词被无限放大。放在元宇宙这类项目里这个问题会被放大到让人怀疑人生。元宇宙场景测试面对的绝不是一个页面、一条操作路径而是空间、时间、实体对象、物理规则、网络状态、多人交互共存的动态环境。后面再叠加自动化框架很多人第一反应是“真的能自动起来吗”。这篇文章我想从自己在实际项目里趟出来的经验出发聊聊元宇宙场景测试到底难点在哪以及如何设计一套以 Python Playwright AI语义定位 pytest 为核心的自动化框架。这里不写“标准答案”只写我在真实项目里验证过、踩过坑后认为可行的方案。适合正在做数字孪生、VR/AR Web端、3D可视化大屏、或者准备在元宇宙类项目里引入自动化测试的同学参考。1. 先看问题本身元宇宙场景测试到底难在哪1.1 场景不是“操作步骤”而是一套持续运行的状态机传统功能测试里我们经常把“场景”理解成一条用例的别名比如“登录成功后进入首页”。这种场景本质上是线性步骤输入、点击、断言。但在元宇宙项目里场景是一套并行运行的实时状态甚至可以说是一个状态机。一个典型的元宇宙场景至少包含空间坐标系、物体位置与朝向、光照和天气、物理碰撞规则、用户化身状态、音视频流状态、多人同步状态、后端房间状态等等。举个例子你要测试一个虚拟展厅中“用户走进某件展品1米范围内自动播放讲解视频”这个行为。传统测试会写成“进入展厅→走到展品前→断言视频播放”。但真实环境里用户进入的角度、行进速度、当时的天气切换、讲解视频是否已经播放过都会影响结果。一旦并行因素超过三五个用例数量就会指数级膨胀。所以我一直跟团队强调在元宇宙场景测试里不能把“场景”写成固定步骤而要把它描述成一个“初始状态触发条件预期终态”。测试用例与其说是“脚本”更像是在给状态机设定边界。这也是后面我们选择数据驱动、场景描述文件驱动的原因。1.2 从车测场景看复杂场景方法论FCTB儿童斜穿测试带来的启发在聊元宇宙之前我特别想说一个来自汽车测试领域的例子因为它给我们的启发非常大。我之前参与过智能驾驶仿真测试相关的项目里面有个典型场景叫FCTB全称翻译过来是“前方儿童横穿”测试。简单描述就是车辆在直行中前方路边突然出现一个儿童目标物以某个速度横穿马路系统需要及时检测并触发制动或避让。这个场景看似简单实际要控制的变量极其复杂儿童出现的时间窗口、横穿速度、车辆自身速度、路面附着系数、光照条件、目标物大小和服饰颜色甚至还要考虑儿童是走还是跑。其中任何一个参数变了系统反应都会不一样。测试团队不能把所有组合全部跑完只能通过正交设计、边界值分析挑出最危险的有限场景。更让我印象深刻的是不同地区的新车评价规程在场景设计上的差异。如果大家关注过E-NCAP和C-NCAP这两个评价体系会发现它们在类似场景上有很明显的不同取向。我不去比较谁好谁坏单从场景定义逻辑上看一个规程更偏向于在单一特定速度点做极限测试场景条件更严格、更单纯另一个规程则倾向于覆盖更广的速度区间和道路类型场景数量更多、维度更宽。这两种思路本质上反映了对“场景覆盖”和“场景深度”的不同权衡。做测试的人都能看懂这不是谁比谁先进而是目标不同导致的取舍。这件事给我的触动很大。放在元宇宙场景测试里道理完全一样我们不可能把连续空间、无限交互组合全部测一遍必须抽象出一批“高价值场景”并对每个场景的主要变量做参数化。比如“虚拟广场中100人同时在线时的NPC碰撞体表现”这一步可以拆成人数、密度、移动速度、网络延迟几个参数而不是直接写一个笨重的完整用例。1.3 元宇宙场景带来的额外挑战视觉真实感与游戏引擎边界元宇宙类项目还有一个传统测试很少碰的挑战表现层不再是单纯的HTML元素而是WebGL渲染出来的3D画面。传统自动化工具能拿到DOM节点却拿不到渲染管线里的最终像素。一个物体可能DOM上存在、位置正确但画面里因为遮挡、层级、光线问题完全看不见或者看起来穿模了。这就意味着自动化框架不能只盯DOM还需要有能力读取游戏引擎暴露的状态接口甚至做图像对比。我们在实际项目里同时用了几套“眼睛”DOM树、浏览器截图、WebGL变量注入、后端状态日志。少一样都有可能在关键时刻漏掉真实问题。2. 自动化框架怎么选为什么押注 Playwright Python AI语义 pytest2.1 先盘点老方案Selenium、Java接口框架、Playwright 各有什么位置做自动化的人基本绕不开 Selenium。它统治Web自动化很多年生态庞大文档也多。但如果你是在一个强交互的3D/WebGL项目里做测试Selenium有个让人很难受的点它对多页面、多标签、弹窗、权限授权、网络状态模拟的支持有些零碎。在这些场景下写出来的测试代码要处理很多与业务无关的浏览器细节。Java接口自动化框架当然有它的优势尤其是团队以Java为主、需要在测试平台里做深度定制时Java的强类型和工程化能力很好用。但坦白说对元宇宙这类快速变化的场景Java方案在编写速度和脚本维护成本上都不占便宜尤其当你要频繁改场景参数、做数据驱动时。Playwright 在这几年能快速起来一个重要原因是它把浏览器控制能力做得非常完整。它由一个团队统一维护API设计很一致多浏览器兼容、自动等待、录屏、网络拦截都是开箱即用。对元宇宙场景测试来说有几点是刚需需要同时控制多个浏览器上下文来模拟多用户进入同一个虚拟空间需要拦截并模拟WebSocket消息来制造网络延迟、断线重连需要截图和录屏来做3D画面的可视回归需要直接执行JavaScript来读取WebGL画布或游戏引擎暴露的实时参数。这些都是我在实际项目中确实用到的能力。Selenium不是做不了而是要做的事情太多最后代码会很重。2.2 “AI语义定位”不是噱头它解决的是选择器维护的沉没成本做Web自动化最烦的是什么十个人里有九个会说是定位。传统XPath一长串好写不好读前端改一个样式类名就全挂了。元宇宙项目里这个问题更严重因为大量界面元素是动态渲染的没有稳定的id甚至连文本内容都不一样。Playwright 自带了一套语义化定位方法比如 get_by_role、get_by_text、get_by_test_id。这些方法已经不要求你理解DOM结构而是用“人话”去找元素——按钮就叫按钮文本框就叫文本框。我可以负责任地说这一层就已经解决了我平时大概七成的定位问题。但我理解题目里说的“AI语义”不只是这点。更进一步的玩法是让大模型理解自然语言指令再把它转换成Playwright能执行的定位操作。比如测试人员只需要写“点击大厅里那个红色的语音房按钮”框架内部会先调用语义解析模块把这句话转成一组候选定位条件然后再用Playwright去执行匹配不到时自动采用截图识别或者JavaScript调用兜底。我们在项目里做了一个比较轻的实现核心逻辑是把自然语言指令拼装成Prompt调用大模型接口拿到结构化的JSON返回JSON里包含定位方式、目标文本、可选索引等信息。这个过程并不复杂关键点是返回格式必须严格约束否则后面解析会花掉一半时间。后面第三章我会贴一段简化代码。这里必须说一句实话AI语义定位适合用来“找元素”不适合用来做“结果断言”。因为模型输出的东西本质上是概率结果可能有偏差。我们只在定位阶段使用它最终断言依然依赖真实的状态数据和可视结果。2.3 pytest 在这里不只是“跑用例的工具”它还是场景编排中心pytest 对测试工程师来说通常是老朋友了。但在元宇宙场景测试框架里它承担的职责比普通项目多很多。它不只是发现和执行用例还要负责场景参数组合、环境初始化、数据清理、失败重试、报告输出。pytest 里面有三样东西非常顺手fixture、parametrize、插件机制。fixture 用来管理浏览器实例、虚拟场景进入退出、用户账号状态parametrize 用来做场景变体的组合比如同一场雪天发布会场景可以组合三种网络状态、两种用户密度插件机制则用来接入Allure报告和失败自动重跑。我们最终的架构里pytest成了中间枢纽读取场景描述文件动态生成测试用例并把执行结果回传给场景管理平台。整个过程里测试代码本身只占了一小部分更多是数据、配置和模板方法。3. 从零搭一个可落地的元宇宙场景自动化框架3.1 目录结构与核心约定我这里给一套我们在实际项目中验证过的目录结构你可以直接抄作业。它不强调代码量而是强调“场景资产”和“代码资产”分离。metaverse_test/ ├── config/ │ ├── global.yaml # 全局配置环境地址、账号池、超时时间 │ └── framework.yaml # 框架参数浏览器类型、窗口大小、录制开关 ├── scene_specs/ │ ├── virtual_expo_hall.yaml # 场景描述虚拟展厅 │ ├── multiplayer_auditorium.yaml │ └── weather_switch_lobby.yaml ├── test_cases/ │ ├── conftest.py # 公共fixture │ ├── test_scene_play.py # 用例主体负责组装场景与执行 │ └── session_helpers.py # 用户会话管理 ├── core/ │ ├── ai_locator.py # AI语义定位模块 │ ├── state_collector.py # 场景状态采集模块 │ └── engine_bridge.py # 与3D引擎的桥接层 ├── reports/ └── requirements.txt这个结构里有一套约定很重要场景规范文件里只写业务层描述不写任何定位表达式。测试用例文件里只写执行逻辑不写大段场景数据。这样分工的好处是产品经理也能看懂场景规范文件测试人员可以更专注于执行逻辑前端开发者又能拿同一份文件去校准自己的实现。3.2 场景描述文件用YAML把复杂场景结构化我们使用YAML作为场景描述的统一格式因为它比JSON更接近自然语言方便评审和改动。分享一个虚拟展厅的场景定义片段scene_name: virtual_expo_hall_audio_guide initial_state: weather: sunny crowd_density: 30 user_position: [2.5, 0, 1.0] user_avatar: default_female objects: - name: exhibit_zhou type: 3d_model position: [2.5, 0, 6.0] interaction: play_audio audio_status: idle trigger: type: proximity target: exhibit_zhou distance: 1.0 approach_speed_range: [0.3, 1.5] expected: audio_status: playing ui_toast_text: 讲解已开始 backend_state: { room_id: 1001, media_play: true } variants: - weather: rainy crowd_density: 60 network_latency: 150 - weather: snowy crowd_density: 10 network_latency: 50这套文件看起来像配置实际是在定义状态机。每个场景都是一个初始状态、一组触发条件和一组预期终态的组合。variant 字段用来声明需要遍历的变体参数。pytest 会读取到这些变体并自动生成多条用例不需要我们手工复制粘贴。这里有一个很容易踩的坑场景里的坐标和距离值。元宇宙项目里坐标单位到底是什么不同项目定义可能完全不同。有的是厘米有的是米有的是游戏引擎的“单位”。我们在YAML里约定所有位置和距离统一使用“米”并在读取时做一次单位转换避免用例数据看着对、实际跑起来完全不是那回事。3.3 核心代码简化版AI语义定位与状态断言AI语义定位模块是整个框架里比较抢眼但也是最容易失控的部分。我们一开始直接把大模型返回结果当成终极指令后来发现只要模型抽风一次整条用例就挂了。后来改成AI只负责“推荐定位意图”最终执行还是走Playwright的原生方法并有多重兜底。下面是一个简化版的核心代码只保留了关键逻辑from playwright.sync_api import Page class AILocator: def __init__(self, page: Page, llm_backendNone): self.page page self.llm_backend llm_backend def locate(self, natural_language: str): if self.llm_backend: parsed self.llm_backend.parse(natural_language) else: parsed {method: text, value: natural_language} # 优先用语义化方法全部失败再降级 if parsed[method] role: return self.page.get_by_role(parsed[role], nameparsed.get(name)) if parsed[method] text: return self.page.get_by_text(parsed[value], exactparsed.get(exact, False)) if parsed[method] test_id: return self.page.get_by_test_id(parsed[value]) # 兜底 locator self.page.locator(parsed[value]) if locator.count() 0: raise LookupError(f无法定位: {natural_language}) return locator这段代码的核心思想是AI给路由Playwright给执行底层逻辑永远不复杂。复杂的是llm_backend怎么训练或者怎么设计Prompt但那属于另一个独立模块。在早期版本里没有接入任何大模型只靠get_by_text和get_by_role就跑了很久所以千万别以为没有AI就玩不转。状态采集和断言部分是另一个重点。对3D场景我建议不要只断言画面“看见了”最好同时采集多个层面的信号def collect_scene_state(page, scene_name: str) - dict: return { dom_state: page.evaluate(window.__METAVERSE_STATE__?.objectsMap || {}), canvas_shot: page.screenshot(pathfreports/{scene_name}.png), backend_state: page.evaluate(fetch(/api/scene/state).then(r r.json())), } def assert_scene_state(actual: dict, expected: dict): for key, value in expected.items(): if key canvas_shot: continue assert actual[backend_state].get(key) value, f状态断言失败: {key}这个例子想说明的是DOM、截图、后端状态三类数据要组合使用。比如“讲解视频播放了”这个结论不能只信DOM里的播放图标也不能只信后端接口最好是三者一致。虽然增加了代码量但能过滤掉大量假阳性问题。3.4 用pytest把场景变量串联起来当场景描述文件就位后test_cases里的代码就可以写得非常干净。我们用一个公共的Fixture读取YAML再用parametrize去生成变体用例。import pytest import yaml from pathlib import Path pytest.fixture(scopemodule) def scene_spec(): spec_path Path(scene_specs/virtual_expo_hall.yaml) with open(spec_path, r, encodingutf-8) as f: return yaml.safe_load(f) def parametrize_scenes(spec): base {spec: spec} variants spec.get(variants, []) if not variants: return [base] loaded [] for idx, variant in enumerate(variants): inherited dict(base) inherited[variant_idx] idx inherited[variant] variant loaded.append(inherited) return loaded pytest.mark.parametrize(scene_context, parametrize_scenes(scene_spec)) def test_exhibit_audio_guide(page, scene_spec, scene_context): variant scene_context[variant] # 根据variant覆盖初始状态 setup_scene(page, scene_spec[initial_state], variant) trigger_proximity(page, scene_spec[trigger]) actual collect_scene_state(page, scene_spec[scene_name]) assert_scene_state(actual, scene_spec[expected])这里有一个值得注意的设计我们没有为每一个变体写一个独立函数而是通过parametrize自动展开。这样新增一个变体只需要改YAML而不是改Python代码。测试代码量被压缩到非常低对长期维护是决定性的优势。4. 常见问题与排查技巧实录4.1 遇到最多的几个坑这部分是我最想分享的因为网上文档里基本不会写。我按问题、原因、解决思路整理成了一张速查表都是实际工作中反复遇到的。问题现象根因分析排查思路与解决手法场景复位不彻底上一个用例的3D对象状态没有清空残留影响下一个用例在每个用例开始时重新加载场景而不是复用旧的页面状态AI语义定位偶尔返回错误元素大模型对同一句话在不同上下文里理解不一致只把AI作为候选推荐最终用count()和visible属性做二次校验WebGL画面和DOM状态不一致渲染层和逻辑层存在异步延迟断言前增加条件等待等后端状态变为目标值后再截画面多用户模拟时浏览器上下文互相串多个上下文共用了一个浏览器存储每个用户使用独立的context不要直接复用page坐标断言频繁失败场景里坐标单位和代码里使用单位不一致统一用“米”在引擎桥接层做单位换算录屏文件过大用例执行时间长录屏一直开着只在关键操作前后开启录屏或按场景阈值自动切割这张表我一直贴在项目白板上。后来团队里新同学遇到类似问题第一反应不是去改框架而是先来查表再决定是不是真出bug。这个习惯帮我们省掉了很多重复排查的时间。4.2 最容易翻车的三个认知误区第一把元宇宙里的“时间”当成普通参数处理。元宇宙场景里几乎所有东西都带动画插值比如角色转身、窗户打开、天气切换。你在代码里点击某个按钮后页面状态可能立刻变了但动画还在播放中此时断言必然不稳定。正确做法是所有断言都基于场景的“目标状态”而不仅仅是当前时间点的瞬时值。我们在断言层封装了一个“轮询等待目标状态”的方法最长等待10秒每秒检查一次直到预期状态出现才算通过。第二只验证前端表现不验证后端场景状态。这个坑我们踩得最惨。有一个版本前端故意隐藏了某个房间入口后端实际还允许进入这属于权限逻辑bug。如果我们只测前端按钮在不在根本发现不了。后来我们规定每条元宇宙场景用例必须至少包含一条后端状态断言。比如房间人数变化、进入事件、媒体流状态等。第三AI语义定位出现“看起来对但实际错”的结果。刚开始我们用AI定位成功率高大家很开心。后来发现在一些边界条件下AI会把“普通NPC对话按钮”识别成“玩家语音按钮”用例照样通过但测的根本不是目标功能。解决办法很简单AI返回的定位结果不能被当作最终权威必须在定位后做一次元素可靠度校验比如检查元素可见性、所在模块类型再决定是否继续。4.3 一个好的习惯场景覆盖率不是越高越好做测试的人普遍有“多测一点更保险”的心理。但在元宇宙场景里组合爆炸会给你非常真实的教训。我们曾经把一个场景做成12个变体跑一轮要40分钟最后发现一半变体之间几乎没有差异。后来我们根据历史bug分布重新筛选只保留4个高价值变体执行时间缩短到15分钟漏测率并没有上升。所以这里的经验是对场景做“聚类优先级”。先把历史上出现过问题的场景参数标红再对参数做正交筛选。宁可少测几个低价值变体也要保证关键场景的每个边界条件都覆盖到。最后我想说一点个人体会。元宇宙场景测试的自动化难点从来不在“自动化”本身而在“把场景定义清楚”。框架、工具、AI都只是放大器场景定义错了放大出来就是一整片无效用例。我们踩了很多坑之后才发现真正值钱的不是那套Playwright代码而是那一堆YAML场景描述文件和背后的评审流程。每次版本更新前测试、产品、开发坐在一起过一遍场景文件哪怕只花二十分钟都会比多跑几十条自动化用例更有用。如果你是刚起步别急着接大模型也别把框架搞得特别复杂。先拿Playwright加pytest跑通10个高价值场景把场景状态采集和断言做扎实再考虑加AI语义定位。这样每一步的收益都是可见的也不容易把自己陷进过度设计的泥潭里。
做测试的朋友应该都有这种体会普通Web功能测试做到后期最烦的不是某个按钮点不到而是“场景”这个词被无限放大。放在元宇宙这类项目里这个问题会被放大到让人怀疑人生。元宇宙场景测试面对的绝不是一个页面、一条操作路径而是空间、时间、实体对象、物理规则、网络状态、多人交互共存的动态环境。后面再叠加自动化框架很多人第一反应是“真的能自动起来吗”。这篇文章我想从自己在实际项目里趟出来的经验出发聊聊元宇宙场景测试到底难点在哪以及如何设计一套以 Python Playwright AI语义定位 pytest 为核心的自动化框架。这里不写“标准答案”只写我在真实项目里验证过、踩过坑后认为可行的方案。适合正在做数字孪生、VR/AR Web端、3D可视化大屏、或者准备在元宇宙类项目里引入自动化测试的同学参考。1. 先看问题本身元宇宙场景测试到底难在哪1.1 场景不是“操作步骤”而是一套持续运行的状态机传统功能测试里我们经常把“场景”理解成一条用例的别名比如“登录成功后进入首页”。这种场景本质上是线性步骤输入、点击、断言。但在元宇宙项目里场景是一套并行运行的实时状态甚至可以说是一个状态机。一个典型的元宇宙场景至少包含空间坐标系、物体位置与朝向、光照和天气、物理碰撞规则、用户化身状态、音视频流状态、多人同步状态、后端房间状态等等。举个例子你要测试一个虚拟展厅中“用户走进某件展品1米范围内自动播放讲解视频”这个行为。传统测试会写成“进入展厅→走到展品前→断言视频播放”。但真实环境里用户进入的角度、行进速度、当时的天气切换、讲解视频是否已经播放过都会影响结果。一旦并行因素超过三五个用例数量就会指数级膨胀。所以我一直跟团队强调在元宇宙场景测试里不能把“场景”写成固定步骤而要把它描述成一个“初始状态触发条件预期终态”。测试用例与其说是“脚本”更像是在给状态机设定边界。这也是后面我们选择数据驱动、场景描述文件驱动的原因。1.2 从车测场景看复杂场景方法论FCTB儿童斜穿测试带来的启发在聊元宇宙之前我特别想说一个来自汽车测试领域的例子因为它给我们的启发非常大。我之前参与过智能驾驶仿真测试相关的项目里面有个典型场景叫FCTB全称翻译过来是“前方儿童横穿”测试。简单描述就是车辆在直行中前方路边突然出现一个儿童目标物以某个速度横穿马路系统需要及时检测并触发制动或避让。这个场景看似简单实际要控制的变量极其复杂儿童出现的时间窗口、横穿速度、车辆自身速度、路面附着系数、光照条件、目标物大小和服饰颜色甚至还要考虑儿童是走还是跑。其中任何一个参数变了系统反应都会不一样。测试团队不能把所有组合全部跑完只能通过正交设计、边界值分析挑出最危险的有限场景。更让我印象深刻的是不同地区的新车评价规程在场景设计上的差异。如果大家关注过E-NCAP和C-NCAP这两个评价体系会发现它们在类似场景上有很明显的不同取向。我不去比较谁好谁坏单从场景定义逻辑上看一个规程更偏向于在单一特定速度点做极限测试场景条件更严格、更单纯另一个规程则倾向于覆盖更广的速度区间和道路类型场景数量更多、维度更宽。这两种思路本质上反映了对“场景覆盖”和“场景深度”的不同权衡。做测试的人都能看懂这不是谁比谁先进而是目标不同导致的取舍。这件事给我的触动很大。放在元宇宙场景测试里道理完全一样我们不可能把连续空间、无限交互组合全部测一遍必须抽象出一批“高价值场景”并对每个场景的主要变量做参数化。比如“虚拟广场中100人同时在线时的NPC碰撞体表现”这一步可以拆成人数、密度、移动速度、网络延迟几个参数而不是直接写一个笨重的完整用例。1.3 元宇宙场景带来的额外挑战视觉真实感与游戏引擎边界元宇宙类项目还有一个传统测试很少碰的挑战表现层不再是单纯的HTML元素而是WebGL渲染出来的3D画面。传统自动化工具能拿到DOM节点却拿不到渲染管线里的最终像素。一个物体可能DOM上存在、位置正确但画面里因为遮挡、层级、光线问题完全看不见或者看起来穿模了。这就意味着自动化框架不能只盯DOM还需要有能力读取游戏引擎暴露的状态接口甚至做图像对比。我们在实际项目里同时用了几套“眼睛”DOM树、浏览器截图、WebGL变量注入、后端状态日志。少一样都有可能在关键时刻漏掉真实问题。2. 自动化框架怎么选为什么押注 Playwright Python AI语义 pytest2.1 先盘点老方案Selenium、Java接口框架、Playwright 各有什么位置做自动化的人基本绕不开 Selenium。它统治Web自动化很多年生态庞大文档也多。但如果你是在一个强交互的3D/WebGL项目里做测试Selenium有个让人很难受的点它对多页面、多标签、弹窗、权限授权、网络状态模拟的支持有些零碎。在这些场景下写出来的测试代码要处理很多与业务无关的浏览器细节。Java接口自动化框架当然有它的优势尤其是团队以Java为主、需要在测试平台里做深度定制时Java的强类型和工程化能力很好用。但坦白说对元宇宙这类快速变化的场景Java方案在编写速度和脚本维护成本上都不占便宜尤其当你要频繁改场景参数、做数据驱动时。Playwright 在这几年能快速起来一个重要原因是它把浏览器控制能力做得非常完整。它由一个团队统一维护API设计很一致多浏览器兼容、自动等待、录屏、网络拦截都是开箱即用。对元宇宙场景测试来说有几点是刚需需要同时控制多个浏览器上下文来模拟多用户进入同一个虚拟空间需要拦截并模拟WebSocket消息来制造网络延迟、断线重连需要截图和录屏来做3D画面的可视回归需要直接执行JavaScript来读取WebGL画布或游戏引擎暴露的实时参数。这些都是我在实际项目中确实用到的能力。Selenium不是做不了而是要做的事情太多最后代码会很重。2.2 “AI语义定位”不是噱头它解决的是选择器维护的沉没成本做Web自动化最烦的是什么十个人里有九个会说是定位。传统XPath一长串好写不好读前端改一个样式类名就全挂了。元宇宙项目里这个问题更严重因为大量界面元素是动态渲染的没有稳定的id甚至连文本内容都不一样。Playwright 自带了一套语义化定位方法比如 get_by_role、get_by_text、get_by_test_id。这些方法已经不要求你理解DOM结构而是用“人话”去找元素——按钮就叫按钮文本框就叫文本框。我可以负责任地说这一层就已经解决了我平时大概七成的定位问题。但我理解题目里说的“AI语义”不只是这点。更进一步的玩法是让大模型理解自然语言指令再把它转换成Playwright能执行的定位操作。比如测试人员只需要写“点击大厅里那个红色的语音房按钮”框架内部会先调用语义解析模块把这句话转成一组候选定位条件然后再用Playwright去执行匹配不到时自动采用截图识别或者JavaScript调用兜底。我们在项目里做了一个比较轻的实现核心逻辑是把自然语言指令拼装成Prompt调用大模型接口拿到结构化的JSON返回JSON里包含定位方式、目标文本、可选索引等信息。这个过程并不复杂关键点是返回格式必须严格约束否则后面解析会花掉一半时间。后面第三章我会贴一段简化代码。这里必须说一句实话AI语义定位适合用来“找元素”不适合用来做“结果断言”。因为模型输出的东西本质上是概率结果可能有偏差。我们只在定位阶段使用它最终断言依然依赖真实的状态数据和可视结果。2.3 pytest 在这里不只是“跑用例的工具”它还是场景编排中心pytest 对测试工程师来说通常是老朋友了。但在元宇宙场景测试框架里它承担的职责比普通项目多很多。它不只是发现和执行用例还要负责场景参数组合、环境初始化、数据清理、失败重试、报告输出。pytest 里面有三样东西非常顺手fixture、parametrize、插件机制。fixture 用来管理浏览器实例、虚拟场景进入退出、用户账号状态parametrize 用来做场景变体的组合比如同一场雪天发布会场景可以组合三种网络状态、两种用户密度插件机制则用来接入Allure报告和失败自动重跑。我们最终的架构里pytest成了中间枢纽读取场景描述文件动态生成测试用例并把执行结果回传给场景管理平台。整个过程里测试代码本身只占了一小部分更多是数据、配置和模板方法。3. 从零搭一个可落地的元宇宙场景自动化框架3.1 目录结构与核心约定我这里给一套我们在实际项目中验证过的目录结构你可以直接抄作业。它不强调代码量而是强调“场景资产”和“代码资产”分离。metaverse_test/ ├── config/ │ ├── global.yaml # 全局配置环境地址、账号池、超时时间 │ └── framework.yaml # 框架参数浏览器类型、窗口大小、录制开关 ├── scene_specs/ │ ├── virtual_expo_hall.yaml # 场景描述虚拟展厅 │ ├── multiplayer_auditorium.yaml │ └── weather_switch_lobby.yaml ├── test_cases/ │ ├── conftest.py # 公共fixture │ ├── test_scene_play.py # 用例主体负责组装场景与执行 │ └── session_helpers.py # 用户会话管理 ├── core/ │ ├── ai_locator.py # AI语义定位模块 │ ├── state_collector.py # 场景状态采集模块 │ └── engine_bridge.py # 与3D引擎的桥接层 ├── reports/ └── requirements.txt这个结构里有一套约定很重要场景规范文件里只写业务层描述不写任何定位表达式。测试用例文件里只写执行逻辑不写大段场景数据。这样分工的好处是产品经理也能看懂场景规范文件测试人员可以更专注于执行逻辑前端开发者又能拿同一份文件去校准自己的实现。3.2 场景描述文件用YAML把复杂场景结构化我们使用YAML作为场景描述的统一格式因为它比JSON更接近自然语言方便评审和改动。分享一个虚拟展厅的场景定义片段scene_name: virtual_expo_hall_audio_guide initial_state: weather: sunny crowd_density: 30 user_position: [2.5, 0, 1.0] user_avatar: default_female objects: - name: exhibit_zhou type: 3d_model position: [2.5, 0, 6.0] interaction: play_audio audio_status: idle trigger: type: proximity target: exhibit_zhou distance: 1.0 approach_speed_range: [0.3, 1.5] expected: audio_status: playing ui_toast_text: 讲解已开始 backend_state: { room_id: 1001, media_play: true } variants: - weather: rainy crowd_density: 60 network_latency: 150 - weather: snowy crowd_density: 10 network_latency: 50这套文件看起来像配置实际是在定义状态机。每个场景都是一个初始状态、一组触发条件和一组预期终态的组合。variant 字段用来声明需要遍历的变体参数。pytest 会读取到这些变体并自动生成多条用例不需要我们手工复制粘贴。这里有一个很容易踩的坑场景里的坐标和距离值。元宇宙项目里坐标单位到底是什么不同项目定义可能完全不同。有的是厘米有的是米有的是游戏引擎的“单位”。我们在YAML里约定所有位置和距离统一使用“米”并在读取时做一次单位转换避免用例数据看着对、实际跑起来完全不是那回事。3.3 核心代码简化版AI语义定位与状态断言AI语义定位模块是整个框架里比较抢眼但也是最容易失控的部分。我们一开始直接把大模型返回结果当成终极指令后来发现只要模型抽风一次整条用例就挂了。后来改成AI只负责“推荐定位意图”最终执行还是走Playwright的原生方法并有多重兜底。下面是一个简化版的核心代码只保留了关键逻辑from playwright.sync_api import Page class AILocator: def __init__(self, page: Page, llm_backendNone): self.page page self.llm_backend llm_backend def locate(self, natural_language: str): if self.llm_backend: parsed self.llm_backend.parse(natural_language) else: parsed {method: text, value: natural_language} # 优先用语义化方法全部失败再降级 if parsed[method] role: return self.page.get_by_role(parsed[role], nameparsed.get(name)) if parsed[method] text: return self.page.get_by_text(parsed[value], exactparsed.get(exact, False)) if parsed[method] test_id: return self.page.get_by_test_id(parsed[value]) # 兜底 locator self.page.locator(parsed[value]) if locator.count() 0: raise LookupError(f无法定位: {natural_language}) return locator这段代码的核心思想是AI给路由Playwright给执行底层逻辑永远不复杂。复杂的是llm_backend怎么训练或者怎么设计Prompt但那属于另一个独立模块。在早期版本里没有接入任何大模型只靠get_by_text和get_by_role就跑了很久所以千万别以为没有AI就玩不转。状态采集和断言部分是另一个重点。对3D场景我建议不要只断言画面“看见了”最好同时采集多个层面的信号def collect_scene_state(page, scene_name: str) - dict: return { dom_state: page.evaluate(window.__METAVERSE_STATE__?.objectsMap || {}), canvas_shot: page.screenshot(pathfreports/{scene_name}.png), backend_state: page.evaluate(fetch(/api/scene/state).then(r r.json())), } def assert_scene_state(actual: dict, expected: dict): for key, value in expected.items(): if key canvas_shot: continue assert actual[backend_state].get(key) value, f状态断言失败: {key}这个例子想说明的是DOM、截图、后端状态三类数据要组合使用。比如“讲解视频播放了”这个结论不能只信DOM里的播放图标也不能只信后端接口最好是三者一致。虽然增加了代码量但能过滤掉大量假阳性问题。3.4 用pytest把场景变量串联起来当场景描述文件就位后test_cases里的代码就可以写得非常干净。我们用一个公共的Fixture读取YAML再用parametrize去生成变体用例。import pytest import yaml from pathlib import Path pytest.fixture(scopemodule) def scene_spec(): spec_path Path(scene_specs/virtual_expo_hall.yaml) with open(spec_path, r, encodingutf-8) as f: return yaml.safe_load(f) def parametrize_scenes(spec): base {spec: spec} variants spec.get(variants, []) if not variants: return [base] loaded [] for idx, variant in enumerate(variants): inherited dict(base) inherited[variant_idx] idx inherited[variant] variant loaded.append(inherited) return loaded pytest.mark.parametrize(scene_context, parametrize_scenes(scene_spec)) def test_exhibit_audio_guide(page, scene_spec, scene_context): variant scene_context[variant] # 根据variant覆盖初始状态 setup_scene(page, scene_spec[initial_state], variant) trigger_proximity(page, scene_spec[trigger]) actual collect_scene_state(page, scene_spec[scene_name]) assert_scene_state(actual, scene_spec[expected])这里有一个值得注意的设计我们没有为每一个变体写一个独立函数而是通过parametrize自动展开。这样新增一个变体只需要改YAML而不是改Python代码。测试代码量被压缩到非常低对长期维护是决定性的优势。4. 常见问题与排查技巧实录4.1 遇到最多的几个坑这部分是我最想分享的因为网上文档里基本不会写。我按问题、原因、解决思路整理成了一张速查表都是实际工作中反复遇到的。问题现象根因分析排查思路与解决手法场景复位不彻底上一个用例的3D对象状态没有清空残留影响下一个用例在每个用例开始时重新加载场景而不是复用旧的页面状态AI语义定位偶尔返回错误元素大模型对同一句话在不同上下文里理解不一致只把AI作为候选推荐最终用count()和visible属性做二次校验WebGL画面和DOM状态不一致渲染层和逻辑层存在异步延迟断言前增加条件等待等后端状态变为目标值后再截画面多用户模拟时浏览器上下文互相串多个上下文共用了一个浏览器存储每个用户使用独立的context不要直接复用page坐标断言频繁失败场景里坐标单位和代码里使用单位不一致统一用“米”在引擎桥接层做单位换算录屏文件过大用例执行时间长录屏一直开着只在关键操作前后开启录屏或按场景阈值自动切割这张表我一直贴在项目白板上。后来团队里新同学遇到类似问题第一反应不是去改框架而是先来查表再决定是不是真出bug。这个习惯帮我们省掉了很多重复排查的时间。4.2 最容易翻车的三个认知误区第一把元宇宙里的“时间”当成普通参数处理。元宇宙场景里几乎所有东西都带动画插值比如角色转身、窗户打开、天气切换。你在代码里点击某个按钮后页面状态可能立刻变了但动画还在播放中此时断言必然不稳定。正确做法是所有断言都基于场景的“目标状态”而不仅仅是当前时间点的瞬时值。我们在断言层封装了一个“轮询等待目标状态”的方法最长等待10秒每秒检查一次直到预期状态出现才算通过。第二只验证前端表现不验证后端场景状态。这个坑我们踩得最惨。有一个版本前端故意隐藏了某个房间入口后端实际还允许进入这属于权限逻辑bug。如果我们只测前端按钮在不在根本发现不了。后来我们规定每条元宇宙场景用例必须至少包含一条后端状态断言。比如房间人数变化、进入事件、媒体流状态等。第三AI语义定位出现“看起来对但实际错”的结果。刚开始我们用AI定位成功率高大家很开心。后来发现在一些边界条件下AI会把“普通NPC对话按钮”识别成“玩家语音按钮”用例照样通过但测的根本不是目标功能。解决办法很简单AI返回的定位结果不能被当作最终权威必须在定位后做一次元素可靠度校验比如检查元素可见性、所在模块类型再决定是否继续。4.3 一个好的习惯场景覆盖率不是越高越好做测试的人普遍有“多测一点更保险”的心理。但在元宇宙场景里组合爆炸会给你非常真实的教训。我们曾经把一个场景做成12个变体跑一轮要40分钟最后发现一半变体之间几乎没有差异。后来我们根据历史bug分布重新筛选只保留4个高价值变体执行时间缩短到15分钟漏测率并没有上升。所以这里的经验是对场景做“聚类优先级”。先把历史上出现过问题的场景参数标红再对参数做正交筛选。宁可少测几个低价值变体也要保证关键场景的每个边界条件都覆盖到。最后我想说一点个人体会。元宇宙场景测试的自动化难点从来不在“自动化”本身而在“把场景定义清楚”。框架、工具、AI都只是放大器场景定义错了放大出来就是一整片无效用例。我们踩了很多坑之后才发现真正值钱的不是那套Playwright代码而是那一堆YAML场景描述文件和背后的评审流程。每次版本更新前测试、产品、开发坐在一起过一遍场景文件哪怕只花二十分钟都会比多跑几十条自动化用例更有用。如果你是刚起步别急着接大模型也别把框架搞得特别复杂。先拿Playwright加pytest跑通10个高价值场景把场景状态采集和断言做扎实再考虑加AI语义定位。这样每一步的收益都是可见的也不容易把自己陷进过度设计的泥潭里。
