基于Playwright的WebRTC自动化测试：模拟设备、网络与多用户场景实践

1. 项目概述：当WebRTC遇上Playwright，实时通信测试的破局之路

如果你正在开发或维护一个依赖WebRTC（Web实时通信）技术的应用，比如视频会议、在线教育、远程协作或者实时游戏，那你一定对测试这件事感到头疼。这玩意儿不像普通的表单提交或者页面跳转，点一下等结果就行。WebRTC测试是个多维度的复杂工程：它涉及音视频流的采集、编码、网络传输、解码、渲染，还要处理NAT穿透、信令交互、网络抖动和丢包。传统的基于Selenium的UI自动化测试，在模拟摄像头、麦克风权限，以及精确控制网络带宽和延迟方面，往往力不从心，更别提深入获取媒体流的内部状态（比如码率、帧率、丢包率）了。

这就是为什么我们需要把目光投向Playwright。它不仅仅是一个“更好的Selenium”，而是一个为现代Web应用（尤其是那些重度依赖媒体和网络API的应用）量身定制的自动化与测试框架。我最近在一个大型视频会议项目的质量保障中，深度使用了Playwright with Python来构建WebRTC自动化测试体系，实实在在地解决了从基础功能验证到复杂场景模拟的一系列难题。这篇文章，我就来拆解其中的三大核心技术，分享如何用Playwright Python搭建一套可靠、高效且可维护的WebRTC自动化测试方案，无论是测试工程师还是开发工程师，都能从中找到可以直接“抄作业”的实践。

2. 核心技术一：模拟真实环境的媒体设备与权限控制

WebRTC测试的第一个拦路虎就是媒体设备。你不可能要求每台测试机都配备高清摄像头和降噪麦克风，更不可能在CI/CD流水线里插满USB设备。Playwright在这方面提供了两种优雅的解决方案：使用虚拟（Fake）设备，或者注入自定义媒体流。选择哪种，取决于你的测试目标。

2.1 虚拟设备：快速启动功能测试

对于绝大多数功能测试（例如，验证“开始通话”按钮点击后，本地视频画面能否正常显示），使用虚拟设备是最快捷、最稳定的方式。它的原理是让浏览器使用内置的虚拟视频和音频源，而不是调用真实的硬件。

import asyncio from playwright.async_api import async_playwright async def test_basic_webrtc_connection(): async with async_playwright() as p: # 启动浏览器，关键参数在这里 browser = await p.chromium.launch( headless=False, # 调试时可设为False观察界面 args=[ '--use-fake-ui-for-media-stream', # 关键：跳过真实的权限弹窗UI '--use-fake-device-for-media-stream', # 关键：使用虚拟的摄像头和麦克风 '--use-file-for-fake-video-capture=/path/to/test.y4m', # 可选：指定虚拟视频文件 '--use-file-for-fake-audio-capture=/path/to/test.wav' # 可选：指定虚拟音频文件 ] ) # 创建上下文时，直接授予权限，避免弹窗干扰 context = await browser.new_context( permissions=['camera', 'microphone'] ) page = await context.new_page() await page.goto('https://your-webrtc-app.com') # 此时，页面调用 navigator.mediaDevices.getUserMedia 将直接获得虚拟流，无需人工交互 await page.click('button#start-video') # 可以断言视频元素是否处于活跃状态 video_element = page.locator('video#local-video') await expect(video_element).to_have_js_property('readyState', 4) # HAVE_ENOUGH_DATA await browser.close()

实操心得与避坑指南：

1. headless模式的选择：在调试阶段，建议使用headless=False以便观察浏览器行为。但在CI/CD环境中，务必使用headless=True（或headless='new'）以提高性能并避免无头环境下的潜在问题。Playwright的“new”头less模式兼容性更好。
2. 虚拟文件源：--use-file-for-fake-video-capture参数非常有用。你可以准备一个Y4M格式的测试视频循环播放。这能确保每次测试的视频内容一致，便于做图像质量分析的基准对比。没有这个参数，虚拟设备生成的是动态彩色条纹，每次可能不同。
3. 权限上下文隔离：通过browser.new_context(permissions=...)授予权限，而不是在page层面处理。这样做的好处是，同一个浏览器实例下的不同上下文（可以理解为不同的隐身窗口）可以拥有独立的权限集，非常适合模拟多个用户同时测试的场景。

2.2 自定义媒体流注入：精准控制测试数据

当你的测试需要验证特定的媒体处理逻辑时，比如测试美颜滤镜效果、或验证客户端能否正确处理某种特定编码格式的视频，虚拟设备可能就不够用了。这时，我们需要在页面加载前，向浏览器上下文中注入脚本，彻底重写getUserMediaAPI。

async def test_with_custom_media_stream(): async with async_playwright() as p: browser = await p.chromium.launch(headless=True) context = await browser.new_context(permissions=['camera', 'microphone']) # 在页面加载任何内容之前，注入自定义脚本 await context.add_init_script(""" // 创建一个返回自定义MediaStream的函数 window.createCustomMediaStream = async (constraints) => { const canvas = document.createElement('canvas'); canvas.width = 640; canvas.height = 480; const ctx = canvas.getContext('2d'); // 模拟一个动态变化的视频帧（例如，移动的方块） function drawFrame(timestamp) { ctx.fillStyle = '#2d2d2d'; ctx.fillRect(0, 0, canvas.width, canvas.height); const x = (timestamp / 50) % canvas.width; ctx.fillStyle = '#4CAF50'; ctx.fillRect(x, 100, 100, 100); ctx.fillStyle = '#fff'; ctx.font = '20px Arial'; ctx.fillText(`Test Frame: ${Math.floor(timestamp)}`, 50, 50); } // 创建CanvasCaptureMediaStreamTrack const stream = canvas.captureStream(30); // 30 fps const track = stream.getVideoTracks()[0]; // 模拟一个简单的音频轨道（静音） const audioContext = new (window.AudioContext || window.webkitAudioContext)(); const oscillator = audioContext.createOscillator(); const dst = oscillator.connect(audioContext.createMediaStreamDestination()); oscillator.start(); const audioTrack = dst.stream.getAudioTracks()[0]; // 根据constraints决定返回哪些轨道 const tracks = []; if (constraints.video !== false && constraints.video !== undefined) { tracks.push(track); } if (constraints.audio !== false && constraints.audio !== undefined) { tracks.push(audioTrack); } return new MediaStream(tracks); }; // 重写getUserMedia navigator.mediaDevices.getUserMedia = async (constraints) => { console.log('[Playwright Mock] getUserMedia called with:', constraints); return await window.createCustomMediaStream(constraints); }; """) page = await context.new_page() await page.goto('https://your-webrtc-app.com') # 现在，页面中的任何getUserMedia调用都会得到我们自定义的流 # 我们可以进一步，在注入的脚本里暴露钩子函数，让测试代码能动态控制流的内容 await page.evaluate("""() => { window.injectedStreamController = { changeVideoColor: function(color) { // 实现改变Canvas绘制颜色的逻辑 console.log('Changing video color to', color); } }; }""") # 在测试过程中，可以动态改变媒体流 await page.evaluate("""() => window.injectedStreamController.changeVideoColor('#FF5733')""") await browser.close()

注意事项：

• 执行时机至关重要：add_init_script必须在page.goto之前调用，确保脚本在页面自身的JavaScript执行前就已生效。
• 模拟的完备性：自定义流需要模拟MediaStreamTrack的常用方法和事件（如stop(),onended），否则页面代码调用这些方法时可能会出错。上面的示例是一个简化版，生产级测试需要更完整的模拟。
• 与真实API的差异：完全重写API可能会掩盖一些真实的浏览器兼容性问题。因此，这套方案更适合用于验证业务逻辑，最终的兼容性测试仍需结合真实或虚拟设备进行。

3. 核心技术二：精细化网络模拟与性能指标采集

WebRTC的核心挑战在网络。用户可能处在4G、5G、Wi-Fi或糟糕的公共网络下。Playwright提供了强大的网络模拟能力，可以精确控制带宽、延迟、丢包率，让我们能在可控环境下复现各种网络问题。

3.1 模拟复杂网络条件

Playwright的BrowserContext对象提供了set_network_conditions方法，这是进行网络模拟的主力。

import asyncio from playwright.async_api import async_playwright class WebRTCNetworkTest: def __init__(self): self.metrics = [] async def run_network_scenario(self, scenario_name, download_kbps, upload_kbps, latency_ms, packet_loss_rate=0): """运行特定网络场景下的测试""" async with async_playwright() as p: browser = await p.chromium.launch(headless=True) # 注意：网络条件是在context级别设置的 context = await browser.new_context( permissions=['camera', 'microphone'], # 通过viewport模拟不同设备，网络测试常结合进行 viewport={'width': 1920, 'height': 1080} ) page = await context.new_page() # 1. 先以良好网络条件加载页面，建立基础连接 await page.goto('https://your-webrtc-app.com', wait_until='networkidle') await page.click('button#start-call') await page.wait_for_selector('.peer-connected', timeout=10000) # 2. 应用目标网络条件 print(f"Applying network condition: {scenario_name}") await context.set_network_conditions( offline=False, download_throughput=download_kbps * 1024, # 转换为bps upload_throughput=upload_kbps * 1024, latency=latency_ms ) # 注意：Playwright原生API不支持直接设置丢包率。需要通过路由（route）拦截并随机丢弃请求来模拟。 # 这里先记录，后续会讲到高级模拟方法。 # 3. 在恶劣网络下稳定运行一段时间，收集数据 await asyncio.sleep(30) # 模拟持续30秒的恶劣网络 # 4. 采集关键性能指标（下一节详述） stats = await self._collect_webrtc_stats(page) stats['scenario'] = scenario_name self.metrics.append(stats) # 5. 恢复良好网络，测试恢复能力 await context.set_network_conditions( offline=False, download_throughput=50 * 1024 * 1024, # 50 Mbps upload_throughput=10 * 1024 * 1024, # 10 Mbps latency=5 ) await asyncio.sleep(10) recovery_stats = await self._collect_webrtc_stats(page) print(f"Recovery stats for {scenario_name}: {recovery_stats}") await browser.close() async def run_all_scenarios(self): """定义并运行一系列典型网络场景""" scenarios = [ ('Excellent (Fiber)', 50000, 10000, 5, 0), # 光纤：50Mbps下行，10Mbps上行，5ms延迟 ('Good (4G)', 10000, 2000, 50, 0.1), # 4G：10Mbps下行，2Mbps上行，50ms延迟，0.1%丢包 ('Average (3G)', 2000, 500, 150, 0.5), # 3G ('Poor (2G)', 500, 100, 300, 1), # 2G ('Very Poor', 100, 50, 500, 2), # 极差网络 ] for scenario in scenarios: name, dl, ul, lat, loss = scenario await self.run_network_scenario(name, dl, ul, lat, loss) self._generate_report()

3.2 高级网络模拟：丢包、抖动与节流

Playwright原生API对丢包和网络抖动的支持有限。要实现更真实的模拟，我们需要结合使用路由拦截（Route）和自定义逻辑。

async def simulate_packet_loss_and_jitter(page, loss_rate=0.01, jitter_ms=50): """ 通过拦截WebSocket和HTTP请求模拟丢包和抖动。 注意：这主要影响信令和数据通道，对SRTP/RTP媒体流的模拟需要更底层的方法。 """ # 拦截所有请求 await page.route("**/*", lambda route: handle_route(route, loss_rate, jitter_ms)) async def handle_route(route, loss_rate, jitter_ms): import random, time request = route.request # 模拟丢包：随机丢弃一定比例的请求 if random.random() < loss_rate: print(f"[Network Sim] Packet lost for: {request.url}") # 可以选择直接abort，或者返回一个错误响应 await route.abort() return # 模拟网络抖动：随机增加延迟 delay = random.randint(0, jitter_ms) / 1000.0 # 转换为秒 if delay > 0: await asyncio.sleep(delay) # 继续处理请求 await route.continue_()

重要提示：上述方法模拟的是HTTP/WebSocket层的丢包和延迟，这对于测试信令服务器的交互和DataChannel非常有效。但要模拟媒体流（RTP/RTCP）的丢包和抖动，Playwright的浏览器上下文API无法直接做到。这通常需要更底层的工具，例如：

1. 使用系统级网络模拟工具：在运行Playwright的宿主机或容器内，使用tc(Linux Traffic Control) 或Network Link Conditioner(macOS) 来塑造整个网络接口的流量。这会影响所有进出浏览器的数据包，包括媒体流。
2. 使用Docker网络：在Docker容器中运行浏览器，并利用容器的网络命名空间配合tc进行模拟。
3. 专门的测试服务/设备：对于实验室环境，可以使用如Apposite Technologies的硬件模拟器或类似的软件方案。

在大多数自动化测试场景中，如果主要验证应用层逻辑（如网络切换时的UI提示、重连机制），使用Playwright的set_network_conditions结合HTTP层拦截已经足够。如果需要端到端的媒体质量评估，建议将系统级网络模拟作为测试环境的一部分进行配置。

3.3 采集WebRTC内部统计信息

这是评估通话质量的核心。我们需要从浏览器的RTCPeerConnection中获取RTCStatsReport。

async def _collect_webrtc_stats(self, page): """从页面中收集WebRTC统计信息""" stats = await page.evaluate("""async () => { // 假设页面上有一个全局可访问的peerConnection对象 // 实际中，可能需要通过页面暴露的API或遍历window对象来找到它 if (!window.myPeerConnection) { console.warn('PeerConnection not found in window object.'); return null; } const report = await window.myPeerConnection.getStats(); const result = { timestamp: Date.now(), inbound: {}, outbound: {}, candidatePair: {} }; report.forEach(stat => { // 收集入站视频流统计 if (stat.type === 'inbound-rtp' && stat.kind === 'video') { result.inbound.video = { bitrate: stat.bytesReceived * 8 / (stat.timestamp - (result.inbound.video?.lastTimestamp || stat.timestamp)) || 0, packetsLost: stat.packetsLost, jitter: stat.jitter, framerate: stat.framesPerSecond, resolution: `${stat.frameWidth}x${stat.frameHeight}` }; result.inbound.video.lastTimestamp = stat.timestamp; } // 收集出站视频流统计 if (stat.type === 'outbound-rtp' && stat.kind === 'video') { result.outbound.video = { bitrate: stat.bytesSent * 8 / (stat.timestamp - (result.outbound.video?.lastTimestamp || stat.timestamp)) || 0, packetsSent: stat.packetsSent, }; result.outbound.video.lastTimestamp = stat.timestamp; } // 收集候选对信息（关键的网络层指标） if (stat.type === 'candidate-pair' && stat.nominated) { result.candidatePair = { currentRoundTripTime: stat.currentRoundTripTime, availableOutgoingBitrate: stat.availableOutgoingBitrate, requestsReceived: stat.requestsReceived, responsesReceived: stat.responsesReceived }; } }); return result; }""") if stats: # 计算平均码率等衍生指标 self._calculate_derived_metrics(stats) return stats

实操心得：

• 访问RTCPeerConnection对象：这是最大的挑战。如果被测应用没有将peerConnection暴露在全局作用域（window），你需要与开发团队协商，在测试构建版本中注入一个钩子函数，或者通过遍历window对象和已知的变量名来尝试查找。
• 定时采集：你需要在一个循环中定期调用这个统计收集函数，以绘制出码率、丢包率随时间变化的曲线，这对于分析网络条件变化的影响至关重要。
• 指标解读：currentRoundTripTime(RTT) 和availableOutgoingBitrate是判断网络健康度的黄金指标。RTT突然飙升通常意味着拥塞，可用带宽下降则可能导致视频质量自动降级。

4. 核心技术三：多浏览器实例与复杂场景编排

真实的WebRTC应用往往是多用户的。测试单人通话只是第一步，我们需要模拟会议室、多人游戏等场景。Playwright可以轻松创建和管理多个独立的浏览器上下文或实例，来模拟不同的用户。

4.1 模拟多用户加入会议室

import asyncio from playwright.async_api import async_playwright class MultiUserConferenceTest: async def setup_users(self, user_count=3): """创建多个独立的浏览器上下文来模拟多个用户""" self.users = [] async with async_playwright() as p: for i in range(user_count): # 每个用户拥有独立的浏览器上下文，完全隔离（cookies, localStorage, 权限等） browser = await p.chromium.launch(headless=True) context = await browser.new_context( permissions=['camera', 'microphone'], viewport={'width': 800, 'height': 600}, # 可以为每个用户设置不同的地理位置（如果需要） geolocation={'latitude': 40.7 + i*0.1, 'longitude': -74.0 + i*0.1}, locale='en-US' ) # 为每个上下文设置不同的网络条件，模拟用户在不同网络下 if i == 0: await context.set_network_conditions(download_throughput=10*1024*1024, upload_throughput=2*1024*1024, latency=20) # 用户0，好网络 elif i == 1: await context.set_network_conditions(download_throughput=2*1024*1024, upload_throughput=512*1024, latency=100) # 用户1，一般网络 page = await context.new_page() await page.goto('https://your-meeting-app.com') self.users.append({ 'id': f'user_{i}', 'browser': browser, 'context': context, 'page': page }) async def test_conference_join_and_media(self): """测试所有用户加入会议室并检查媒体流""" join_tasks = [] for user in self.users: # 并行执行加入操作，模拟真实场景 task = asyncio.create_task(self._user_join_meeting(user, 'test-room-123')) join_tasks.append(task) # 等待所有用户加入完成 await asyncio.gather(*join_tasks) print("All users joined the meeting.") # 验证每个用户的本地视频是否就绪 for user in self.users: local_video = user['page'].locator('video#local-video') await expect(local_video).to_be_visible(timeout=15000) await expect(local_video).to_have_js_property('readyState', 4) # 验证每个用户都能看到其他用户的视频（远程视频） # 假设页面为每个远程用户动态生成一个 video 元素，其id包含对方用户ID for i, user in enumerate(self.users): for j, other_user in enumerate(self.users): if i != j: remote_video_selector = f'video[data-peer-id="{other_user["id"]}"]' remote_video = user['page'].locator(remote_video_selector) # 等待远程视频元素出现并开始播放 await expect(remote_video).to_be_attached(timeout=20000) # 可以进一步检查视频是否正在播放 is_playing = await remote_video.evaluate("""v => !v.paused && v.readyState > 2""") assert is_playing, f"User {user['id']} cannot see playing video from {other_user['id']}" print("All media streams verified.") async def _user_join_meeting(self, user, room_id): """单个用户加入会议室的流程""" page = user['page'] await page.fill('input#room-id', room_id) await page.fill('input#username', user['id']) await page.click('button#join-button') # 等待加入成功的UI反馈 await page.wait_for_selector('.in-meeting', timeout=10000)

4.2 模拟用户交互与异常场景

自动化测试不仅要覆盖“阳光路径”，更要覆盖“风雨路径”。

async def test_screen_sharing(self): """测试用户发起屏幕共享，其他人能否看到""" sharer = self.users[0] await sharer['page'].click('button#share-screen') # 处理屏幕选择弹窗（Playwright可以模拟选择整个屏幕、应用窗口或标签页） # 注意：headless模式下屏幕共享可能受限，需要特定标志或使用非headless模式。 # 这里假设应用使用getDisplayMedia，并且我们通过之前add_init_script的方式模拟了它。 # 验证共享者界面显示“正在共享”状态 await expect(sharer['page'].locator('.screen-share-active')).to_be_visible(timeout=5000) # 验证其他用户界面出现屏幕共享视频 for viewer in self.users[1:]: screen_share_video = viewer['page'].locator('video.screen-share') await expect(screen_share_video).to_be_visible(timeout=10000) is_playing = await screen_share_video.evaluate("""v => !v.paused""") assert is_playing, f"Viewer {viewer['id']} cannot see playing screen share." async def test_network_disconnect_recovery(self): """模拟用户网络中断并重连""" victim = self.users[1] # 1. 记录当前状态 initial_peers = await victim['page'].locator('.remote-peer').count() # 2. 模拟网络中断（关闭浏览器上下文级别的网络） await victim['context'].set_network_conditions( offline=True # 关键：设置为离线 ) print(f"Network disconnected for {victim['id']}") await asyncio.sleep(10) # 保持离线10秒 # 3. 验证应用是否检测到断线并显示相应UI（如“连接中断”） await expect(victim['page'].locator('.connection-lost')).to_be_visible(timeout=8000) # 4. 恢复网络 await victim['context'].set_network_conditions(offline=False) print(f"Network restored for {victim['id']}") # 5. 验证自动重连或提示用户手动重连 # 方案A：等待自动重连成功 await victim['page'].wait_for_selector('.connection-reestablished', timeout=30000) # 方案B：可能需要用户点击重连按钮 # await victim['page'].click('button#reconnect') # await victim['page'].wait_for_selector('.in-meeting', timeout=15000) # 6. 验证媒体流恢复 await expect(victim['page'].locator('video#local-video')).to_have_js_property('readyState', 4, timeout=15000) final_peers = await victim['page'].locator('.remote-peer').count() assert final_peers >= initial_peers, "Peer count did not recover after reconnect." async def cleanup(self): """清理所有浏览器实例""" for user in self.users: await user['context'].close() await user['browser'].close()

编排与并发技巧：

• 使用asyncio.gather：对于可以并行执行的操作（如多个用户同时加入房间），使用asyncio.gather能显著缩短测试总时间。
• 资源管理：每个浏览器实例和上下文都会消耗内存和CPU。在测试完成后，务必调用close()方法妥善关闭，避免资源泄漏。可以考虑使用async with语句块来管理生命周期。
• 测试数据隔离：每个浏览器上下文是隔离的，这意味着它们的cookie、localStorage、sessionStorage互不影响，完美模拟了多个独立用户设备。

5. 构建健壮的测试框架与持续集成

将上述技术点组合起来，形成一个可维护、可扩展的自动化测试框架，并集成到CI/CD流水线中，才能发挥最大价值。

5.1 测试框架设计

我推荐使用pytest作为测试运行器，它功能强大，插件生态丰富（如pytest-asyncio用于异步支持，pytest-html用于生成报告）。

# conftest.py - 定义pytest fixtures import pytest import asyncio from playwright.async_api import async_playwright @pytest.fixture(scope='session') def event_loop(): """为异步测试创建事件循环""" loop = asyncio.get_event_loop_policy().new_event_loop() yield loop loop.close() @pytest.fixture(scope='function') # 每个测试函数一个独立的浏览器上下文 async def browser_context(): async with async_playwright() as p: browser = await p.chromium.launch(headless=True) context = await browser.new_context( permissions=['camera', 'microphone'], viewport={'width': 1280, 'height': 720}, record_video_dir='videos/' # 可选：录制测试视频 ) yield context await context.close() await browser.close() @pytest.fixture async def page(browser_context): page = await browser_context.new_page() yield page await page.close() # test_webrtc_basic.py import pytest class TestWebRTCBasic: @pytest.mark.asyncio async def test_single_peer_connection(self, page): """测试点对点连接建立""" await page.goto('https://app.example.com/p2p') await page.click('#startButton') # ... 具体的断言逻辑 assert await page.locator('.status').text_content() == 'connected' @pytest.mark.asyncio @pytest.mark.parametrize('network_condition', ['good', 'average', 'poor']) async def test_connection_under_network_stress(self, page, network_condition): """参数化测试：在不同网络压力下测试连接""" # 根据参数设置网络条件 condition_map = {'good': (5000, 1000, 20), 'average': (1000, 500, 100), 'poor': (300, 100, 300)} dl, ul, lat = condition_map[network_condition] await page.context.set_network_conditions(download_throughput=dl*1024, upload_throughput=ul*1024, latency=lat) await page.goto('https://app.example.com/p2p') await page.click('#startButton') # 断言在限定时间内应能连接成功，或优雅降级 try: await page.wait_for_selector('.connected', timeout=30000) assert True except: # 在极差网络下，连接可能失败，但应用应显示相应提示 await page.wait_for_selector('.connection-failed', timeout=5000) assert await page.locator('.error-message').is_visible()

5.2 集成到CI/CD流水线

在GitHub Actions、GitLab CI或Jenkins中，你需要确保环境具备必要的依赖。

# .github/workflows/webrtc-e2e.yml 示例 name: WebRTC E2E Tests on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Set up Python uses: actions/setup-python@v4 with: python-version: '3.10' - name: Install system dependencies (for Playwright browsers) run: | sudo apt-get update sudo apt-get install -y libgbm-dev libnss3 libatk-bridge2.0-0 libdrm-dev libxkbcommon-x11-0 libasound2 - name: Install Python dependencies run: | pip install -r requirements.txt pip install playwright pytest pytest-asyncio pytest-html - name: Install Playwright browsers run: python -m playwright install chromium --with-deps - name: Run WebRTC E2E tests run: | pytest tests/webrtc/ -v --html=report.html --self-contained-html env: # 传递测试所需的配置，如被测应用URL、测试房间密码等 TEST_APP_URL: ${{ secrets.TEST_APP_URL }} - name: Upload test artifacts if: always() # 即使测试失败也上传 uses: actions/upload-artifact@v3 with: name: playwright-report path: | report.html videos/ # 如果录制了视频 screenshots/ # 如果测试失败时截图

5.3 常见问题排查与技巧实录

在实际操作中，我踩过不少坑，这里分享几个高频问题的解决方案：

1. 权限弹窗处理失败：

   • 现象：测试卡住，等待用户允许摄像头/麦克风。
   • 解决：确保在browser.new_context()时通过permissions参数预先授予权限。如果应用在页面加载后动态请求权限，可以使用page.context.grant_permissions(['camera', 'microphone'])。最根本的方法是使用--use-fake-ui-for-media-stream启动参数彻底绕过弹窗。

2. Headless模式下视频黑屏或无法播放：

   • 现象：在CI的无头环境中，视频元素的readyState始终为0。
   • 解决：首先确认使用了虚拟设备参数（--use-fake-device-for-media-stream）。其次，某些WebRTC库或浏览器在headless模式下可能需要额外的标志来启用GPU和媒体功能。尝试添加这些Chrome启动参数：--enable-gpu-rasterization，--enable-features=VizDisplayCompositor。如果问题依旧，考虑在调试期使用headless='new'或headless=False进行对比。

3. 无法获取页面内的RTCPeerConnection对象：

   • 现象：page.evaluate()中找不到window.myPeerConnection。
   • 解决：这是测试架构问题。有三种策略：
     • 合作式：与开发团队约定，在测试环境构建中，将关键的连接对象挂载到window的一个特定属性下（如window.__testPeerConnection）。
     • 侵入式：在页面加载前通过add_init_script注入代码，劫持RTCPeerConnection构造函数，将创建的实例收集到一个全局数组中供测试脚本访问。
     • 非侵入式：通过遍历window对象，寻找可能是RTCPeerConnection的实例（判断其是否有getStats等方法）。这种方法最脆弱，但有时是唯一选择。

4. 测试不稳定，时好时坏：

   • 现象：断言偶尔失败，尤其是涉及网络状态或元素可见性的断言。
   • 解决：
     • 增加超时时间：WebRTC建立连接、交换候选地址需要时间，特别是在模拟慢网络时。将wait_for_selector、wait_for_function的超时时间设置得足够长（例如15-30秒）。
     • 使用更健壮的定位器：避免使用基于文本或容易变化的CSS选择器。优先使用>