Playwright+Python实战：攻克WebRTC自动化测试核心难题

1. 项目概述：为什么WebRTC自动化测试是个“硬骨头”？

如果你做过音视频应用的测试，尤其是涉及到实时通信的，那你一定对WebRTC这个名字又爱又恨。爱的是它让浏览器和移动端实现点对点的音视频通话变得如此便捷，恨的是，当你想用自动化脚本来验证它的功能是否正常时，会发现到处都是坑。这恰恰就是“突破WebRTC自动化测试核心难题”这个标题背后，我们每天都要面对的真实战场。

简单来说，WebRTC自动化测试的“硬”，硬在它的动态性和复杂性。传统的Web自动化，比如测试一个表单提交，你点击按钮，等待页面跳转或弹窗，检查结果，逻辑是线性的、状态是明确的。但WebRTC不同，它建立的是一个持续的、双向的媒体流和数据通道。你的自动化脚本不仅要模拟用户点击“开始通话”按钮，更要能判断：音视频轨道成功建立了吗？网络延迟和丢包率在可接受范围内吗？远端画面真的渲染出来了吗？有没有回声或卡顿？这些都不是一个简单的“元素可见”断言能解决的。

更棘手的是环境问题。WebRTC严重依赖硬件（摄像头、麦克风、编解码器）和网络状况。在CI/CD流水线里跑自动化，那些无头（Headless）的服务器通常没有摄像头和麦克风，你怎么模拟媒体流？网络是稳定的内网，而真实用户可能处在复杂的移动网络环境下，你又如何模拟各种网络损伤（如高延迟、丢包）来测试应用的抗性？这些就是标题里所指的“核心难题”。

而“Playwright Python实战指南”则给出了一个非常务实的解决方案组合拳。Playwright作为一个现代浏览器自动化库，它提供了对WebRTC内部状态的深度访问能力，这是老牌的Selenium难以比拟的。Python则以其丰富的生态（如opencv-python用于图像分析，pyaudio/sounddevice用于音频分析，pytest组织测试用例）和简洁的语法，成为粘合各种测试工具和进行复杂逻辑判断的理想语言。这个项目，本质上就是教你如何用Playwright+Python这套组合工具，去啃下WebRTC自动化测试这块硬骨头，把那些模糊的、感性的“通话好像没问题”，变成一系列可重复、可断言、可量化的自动化检查点。

2. 测试策略与架构设计：从混沌到有序

面对WebRTC测试的复杂性，一上来就写脚本绝对是事倍功半。首先需要的是一个清晰的测试策略和架构设计。我们的目标不是模拟人类用户的所有操作，而是精准地验证WebRTC应用的核心质量属性。

2.1 测试金字塔在WebRTC场景下的应用

我们可以借鉴经典的测试金字塔思想，但需要针对WebRTC特性进行改造：

1. 单元测试（底层）：测试你封装的WebRTC业务逻辑函数。例如，一个用于创建特定配置（如{ iceServers: [...] }）的PeerConnection的函数。这部分用纯Python的unittest或pytest即可，不涉及浏览器。确保你的配置生成逻辑是正确的。
2. 集成测试（核心）：这是Playwright的主战场。测试浏览器内WebRTC API的调用、信令交互、媒体轨道的添加与移除。例如，在一个页面内建立本地RTCPeerConnection，添加模拟的媒体流，并验证onicecandidate,ontrack等事件是否正常触发。关键点：这个层级可以使用Playwright提供的context.grantPermissions(['camera', 'microphone'])和page.addInitScript来注入代码，模拟媒体设备，从而在无头环境下运行。
3. 端到端（E2E）测试（完整流程）：模拟真实用户场景。通常需要两个独立的浏览器上下文（Context）或甚至两个Playwright浏览器实例，来扮演通话的双方。测试完整的“用户A呼叫用户B -> B接听 -> 双方音视频互通 -> 挂断”流程。这是最复杂、最耗时但也最接近真实场景的测试。

本指南的重点将放在集成测试和端到端测试上，因为这是Playwright解决WebRTC测试难题最具价值的地方。

2.2 核心测试场景拆解

我们需要将模糊的“测试通话”分解为具体的、可自动化的场景：

• 连接建立测试：能否成功交换SDP？ICE协商是否成功？连接状态是否变为connected？
• 媒体流测试：本地能否获取视频轨道（即使是用虚拟设备）？远端ontrack事件是否被触发？视频元素是否成功接收到媒体流并开始播放？
• 数据通道测试：如果应用使用了RTCDataChannel，测试双向消息的发送与接收是否准确、及时。
• 质量与性能测试：这是难点也是重点。如何量化评估？我们可以通过Playwright获取性能指标（如WebRTC.getStats()），并结合图像/音频分析库进行判断。
  • 视频质量：通过Canvas截取视频帧，使用OpenCV计算关键指标，如连续多帧的PSNR（峰值信噪比）或SSIM（结构相似性），来判断远端画面是否静止（卡顿）、模糊或花屏。
  • 音频质量：难度更高。可通过分析音频数据的振幅，判断是否有声音（静音检测），或通过更复杂的库进行简单的回声或噪音检测模拟。
• 异常与恢复测试：模拟网络中断、摄像头/麦克风权限被拒绝、ICE重启等异常情况，验证应用的错误处理和恢复机制是否健全。

2.3 技术栈选型与工具链搭建

为什么是Playwright + Python，而不是其他组合？

• Playwright的优势：
  • 多浏览器支持：Chromium, Firefox, WebKit一套API搞定，确保跨浏览器一致性。
  • 强大的网络与设备模拟：可以非常方便地模拟网络状况（延迟、丢包、离线），以及授予摄像头/麦克风权限，这是WebRTC测试的基石。
  • 访问浏览器上下文：可以直接在页面上下文中执行JavaScript，获取RTCPeerConnection、MediaStream等原生对象，调用getStats()API，这是实现深度断言的关键。
  • 自动等待与可靠性：内置的自动等待机制减少了“flaky tests”（不稳定的测试）的出现。
• Python的优势：
  • 丰富的科学计算与多媒体库：opencv-python(图像处理),numpy(数值计算),scikit-image(图像质量评估),pydub/librosa(音频处理)。这些库让我们有能力去分析媒体流的质量。
  • 成熟的测试框架：pytest功能强大，夹具（fixture）机制非常适合管理复杂的浏览器和页面生命周期。
  • 胶水语言特性：可以轻松集成其他工具，比如用ffmpeg-python来处理更复杂的媒体文件，用allure-pytest生成漂亮的测试报告。

基础工具链搭建：

# 1. 安装Playwright Python库及浏览器 pip install playwright playwright install chromium # 建议先专注于一个浏览器 # 2. 安装测试框架及辅助库 pip install pytest pytest-asyncio pytest-html opencv-python numpy # 3. (可选) 用于更高级的媒体分析 pip install scikit-image pydub

注意：在CI服务器（如GitHub Actions, Jenkins）上运行无头测试时，可能需要额外安装一些系统依赖（如libgl1-mesa-glx）来支持OpenCV等库的运行。建议使用Docker容器来固化测试环境，避免环境差异。

3. 实战环境搭建与模拟设备配置

纸上谈兵结束，我们开始动手。第一个拦路虎就是：在通常没有真实摄像头和麦克风的自动化环境中，如何让WebRTC代码认为它有可用的媒体设备？

3.1 使用虚拟视频和音频设备

Playwright提供了两种主要方式来模拟媒体设备：

方法一：使用预定义的虚拟设备（推荐）这是最简洁的方式。Playwright启动浏览器上下文时，可以直接指定使用虚拟的摄像头和麦克风。

import asyncio from playwright.async_api import async_playwright async def main(): async with async_playwright() as p: # 启动浏览器，设置使用虚拟设备 browser = await p.chromium.launch(headless=False) # 调试时可先设为非无头 context = await browser.new_context( permissions=["camera", "microphone"], # 关键配置：指定虚拟设备 record_video_dir="videos/", # 可选：录制测试视频 viewport={'width': 1280, 'height': 720}, device_scale_factor=2, # 使用虚拟媒体流 args=['--use-fake-ui-for-media-stream', '--use-fake-device-for-media-stream'] ) page = await context.new_page() await page.goto('https://your-webrtc-app.com') # ... 后续测试逻辑 await browser.close() asyncio.run(main())

--use-fake-ui-for-media-stream参数会跳过真实的权限弹窗。--use-fake-device-for-media-stream会提供虚拟的、播放一段测试视频（通常是一个彩条或移动的方块）的摄像头和生成正弦波音频的麦克风。这对于测试“媒体流能否成功获取并传递”已经足够了。

方法二：通过CDP（Chrome DevTools Protocol）注入自定义流如果你需要更定制化的视频内容（比如特定的测试图案），或者需要分析发送的特定视频帧，可以通过CDP注入一个由你程序生成的MediaStream。

async def inject_custom_video_stream(page): # 这是一个高级用法，需要熟悉CDP和Canvas API # 大致思路：在页面内创建一个Canvas，绘制内容，然后通过captureStream()获取MediaStream # 再通过CDP将本地PeerConnection的sender替换为该自定义流。 # 代码较为复杂，通常只在有特殊图像识别需求时使用。 pass

对于绝大多数质量测试场景，方法一配合后续的图像分析已经足够。

3.2 网络状况模拟：制造真实的“坏”环境

稳定的局域网环境发现不了问题。Playwright的context对象可以轻松模拟各种网络状况。

async def simulate_network_conditions(context): # 模拟一个较差的3G网络 await context.set_offline(False) # 确保在线 await context.route('**', lambda route: route.continue_()) # 确保路由正常 # 通过CDP直接设置网络模拟（更底层的方式） cdp_session = await context.new_cdp_session(context.pages[0]) await cdp_session.send('Network.emulateNetworkConditions', { 'offline': False, 'downloadThroughput': 750 * 1024 / 8, # 750 Kbps 下载 'uploadThroughput': 250 * 1024 / 8, # 250 Kbps 上传 'latency': 100 # 100ms 延迟 }) # 注意：此模拟会影响该页面所有请求，包括信令服务器和STUN/TURN服务器。

重要提示：网络模拟的粒度。你可以选择只对媒体流（可能通过特定的TURN服务器域名）进行限速，而保持信令通道畅通。这需要更精细的路由（context.route）规则。通常，先进行全局模拟，如果信令因此超时失败，再考虑拆分。

3.3 使用Pytest Fixture管理复杂资源

测试WebRTC会涉及多个页面、上下文、以及自定义的媒体分析器。使用pytest的fixture来管理它们的生命周期能让代码清晰且可复用。

# conftest.py import pytest import asyncio from playwright.async_api import async_playwright, Page @pytest.fixture(scope='session') def event_loop(): """为异步测试创建事件循环""" loop = asyncio.get_event_loop_policy().new_event_loop() yield loop loop.close() @pytest.fixture(scope='session') async def browser(): async with async_playwright() as p: browser = await p.chromium.launch(headless=True) # CI环境用True yield browser await browser.close() @pytest.fixture async def context(browser): context = await browser.new_context( permissions=["camera", "microphone"], args=['--use-fake-ui-for-media-stream', '--use-fake-device-for-media-stream'] ) yield context await context.close() @pytest.fixture async def page(context): page = await context.new_page() yield page await page.close() @pytest.fixture async def two_party_context(browser): """创建一个包含两个独立页面的上下文，模拟通话双方""" context = await browser.new_context( permissions=["camera", "microphone"], args=['--use-fake-ui-for-media-stream', '--use-fake-device-for-media-stream'] ) page_a = await context.new_page() page_b = await context.new_page() yield (page_a, page_b) await context.close()

这样，在你的测试用例中，只需要声明需要哪个fixture，pytest会自动完成创建和清理。

4. 核心测试用例实现详解

环境搭好了，现在进入核心环节：如何用Playwright和Python写出有价值的WebRTC测试断言。

4.1 基础连接与媒体流测试

我们先实现一个最基本的测试：在一个页面内，创建PeerConnection，添加本地流，并断言相关事件发生。

import pytest @pytest.mark.asyncio async def test_local_media_stream_creation(page: Page): """ 测试能否在页面内成功获取虚拟媒体流并创建PeerConnection。 """ await page.goto('about:blank') # 空白页即可 # 在页面上下文中执行JS，模拟前端WebRTC逻辑 result = await page.evaluate(""" async () => { try { // 1. 获取本地媒体流（使用虚拟设备） const localStream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true }); // 断言流存在且有轨道 if (!localStream || localStream.getTracks().length === 0) { return { success: false, error: 'Failed to get media stream' }; } // 2. 创建RTCPeerConnection const pc = new RTCPeerConnection(); // 添加本地流的所有轨道到PC localStream.getTracks().forEach(track => pc.addTrack(track, localStream)); // 3. 监听关键事件，用Promise包装以便异步获取结果 const events = { iceGatheringStateChange: [], connectionStateChange: [], trackEvent: null }; pc.onicegatheringstatechange = () => events.iceGatheringStateChange.push(pc.iceGatheringState); pc.onconnectionstatechange = () => events.connectionStateChange.push(pc.connectionState); pc.ontrack = (e) => events.trackEvent = e; // 4. 创建Offer（仅本地，不交换） const offer = await pc.createOffer(); await pc.setLocalDescription(offer); // 简单等待一下，让事件有机会触发 await new Promise(resolve => setTimeout(resolve, 1000)); return { success: true, streamTrackCount: localStream.getTracks().length, iceStates: events.iceGatheringStateChange, connectionStates: events.connectionStateChange, gotTrack: !!events.trackEvent }; } catch (err) { return { success: false, error: err.toString() }; } } """) assert result['success'] == True, f"JS execution failed: {result.get('error')}" assert result['streamTrackCount'] >= 1, "Should have at least one media track" # ICE收集状态应该经历过 'new' -> 'gathering' -> 'complete' assert 'complete' in result['iceStates'], "ICE gathering should reach 'complete' state" # 因为我们只添加了发送轨道，没有远端，所以不会触发ontrack。这是符合预期的。 # 如果需要测试接收，需要更复杂的双端测试。

这个测试验证了在Playwright提供的虚拟设备环境下，WebRTC的基础API可以正常工作。

4.2 端到端通话测试

这是更真实的场景。我们需要两个页面，模拟完整的信令交换（这里我们用最简单的“页面内直接传递”来模拟信令服务器）。

@pytest.mark.asyncio async def test_peer_to_peer_connection(two_party_context): """测试两个对等端能否成功建立连接并交换媒体流。""" page_a, page_b = two_party_context # 定义一个JS函数，用于在单个页面内创建PeerConnection和媒体流 create_peer_js = """ (async () => { const stream = await navigator.mediaDevices.getUserMedia({video: true, audio: true}); const pc = new RTCPeerConnection(); stream.getTracks().forEach(track => pc.addTrack(track, stream)); return { pc, stream }; })() """ # 在两个页面分别创建Peer A和Peer B peer_a = await page_a.evaluate(create_peer_js) peer_b = await page_b.evaluate(create_peer_js) # 为了方便，我们将PeerConnection对象在页面中的引用ID传回来，实际不能直接传递对象。 # 更实际的做法是将所有信令逻辑放在页面内JS执行，通过evaluate返回结果。 # 下面是一个简化的、通过Playwright作为“信令中转”的示例： # 在Page A创建Offer offer = await page_a.evaluate("""async (pcHandle) => { const pc = window.peerConnections[pcHandle]; // 假设pc存储在全局变量中 const offer = await pc.createOffer(); await pc.setLocalDescription(offer); return offer; }""", peer_a['pc_handle']) # 需要事先将pc对象存储在window下并返回handle # 将Offer传给Page B await page_b.evaluate("""async (offer) => { const pc = window.peerConnections['peerB']; await pc.setRemoteDescription(new RTCSessionDescription(offer)); const answer = await pc.createAnswer(); await pc.setLocalDescription(answer); return answer; }""", offer) # ... 再将Answer传回Page A设置 # 代码较长，核心是模拟信令交换。 # 更优雅的方式：使用Playwright的`page.expose_function`在浏览器中注册一个Python回调函数， # 让页面JS直接调用这个回调来传递信令消息，实现页面间的通信。 # 例如： # def signal_callback(msg): # # 根据msg内容，转发到另一个page # asyncio.create_task(other_page.evaluate(f"receiveSignal({json.dumps(msg)})")) # await page_a.expose_function("sendSignal", signal_callback) # 然后页面内JS就可以：window.sendSignal({type: 'offer', sdp: offerSdp});

由于篇幅限制，完整的信令中转代码较长。但其核心模式是：利用Playwright在Node.js/Python环境与浏览器页面环境之间搭建桥梁，模拟信令服务器的转发行为。对于简单的测试，也可以使用page.evaluate在两个页面之间直接传递序列化的SDP和Candidate数据。

4.3 媒体质量自动化评估

这是体现Python生态优势的地方。我们结合Playwright截图和OpenCV进行视频质量分析。

场景：检测远端视频是否卡顿（静止）。原理：连续截取远端视频元素的多帧画面，计算它们之间的差异（如MSE，均方误差）。如果连续多帧差异极小，则可能卡顿。

import cv2 import numpy as np from PIL import Image import io async def check_video_stuck(page: Page, video_selector: str, duration_secs=3, threshold=5.0): """ 检查指定视频元素在给定时间内是否卡住。 :param page: Playwright页面对象 :param video_selector: 视频元素的CSS选择器 :param duration_secs: 监控时长 :param threshold: 平均帧间MSE阈值，低于此值认为卡顿 :return: (is_stuck, average_mse) """ frames = [] for i in range(duration_secs * 2): # 每秒取2帧 # 1. 对视频元素截图 screenshot_bytes = await page.locator(video_selector).screenshot() # 2. 将字节数据转换为OpenCV图像格式 (灰度图，减少计算量) img = Image.open(io.BytesIO(screenshot_bytes)).convert('L') frame = np.array(img) frames.append(frame) await page.wait_for_timeout(500) # 等待500ms # 3. 计算连续帧之间的MSE mse_values = [] for i in range(1, len(frames)): # 计算两帧图像的均方误差 mse = np.mean((frames[i-1].astype("float") - frames[i].astype("float")) ** 2) mse_values.append(mse) average_mse = np.mean(mse_values) if mse_values else 0 is_stuck = average_mse < threshold return is_stuck, average_mse # 在测试用例中使用 @pytest.mark.asyncio async def test_video_playback_not_stuck(page): # ... 假设已经建立了连接，并定位到远端的<video>元素 is_stuck, mse = await check_video_stuck(page, '#remoteVideo', duration_secs=2) assert not is_stuck, f"Video appears to be stuck (average MSE: {mse:.2f})"

注意事项：

1. 阈值（threshold）需要校准：虚拟摄像头产生的测试图案（彩条）可能本身就有规律性变化，MSE可能不高。最好先用“正常流动”的虚拟流和“故意卡住”的流（比如用静态图片作为源）来测定一个合适的阈值。
2. 性能考虑：截图和图像计算是CPU密集型操作，不宜过于频繁或长时间进行。选择关键的2-3秒进行采样即可。
3. 更高级的指标：对于真实内容，可以考虑SSIM。OpenCV和scikit-image都提供了相关函数。

音频测试更为复杂，一个基础的静音检测可以通过分析AudioBuffer的数据进行，但需要从MediaStream中获取音频数据，这通常需要借助AudioContext和ScriptProcessorNode，在自动化环境中实现成本较高。初期可以优先保障视频通道的测试覆盖。

4.4 获取并断言WebRTC统计信息

RTCPeerConnection.getStats()API是金矿，它能提供大量关于连接质量、编解码器、带宽、丢包等详细信息。Playwright可以轻松获取这些数据。

async def get_webrtc_stats(page: Page, pc_handle): """获取指定PeerConnection的统计信息。""" stats = await page.evaluate("""(pcHandle) => { const pc = window.peerConnections[pcHandle]; if (!pc) return null; return pc.getStats(null).then(report => { const result = {}; report.forEach(stat => { result[stat.id] = { ...stat }; }); return result; }); }""", pc_handle) return stats # 在测试中断言关键指标 stats = await get_webrtc_stats(page, 'peerA') # 找到出站视频的统计项（类型为 'outbound-rtp' 且 mediaType 为 'video'） outbound_video_stats = [s for s in stats.values() if s.get('type') == 'outbound-rtp' and s.get('mediaType') == 'video'] if outbound_video_stats: stats_obj = outbound_video_stats[0] # 断言视频已发送字节数大于0 assert stats_obj.get('bytesSent', 0) > 0, "No video data seems to have been sent." # 可以检查 packetsSent, roundTripTime, 等 print(f"Video sent: {stats_obj.get('bytesSent')} bytes, Packets: {stats_obj.get('packetsSent')}")

通过定期抓取并分析stats数据，可以绘制出通话过程中的质量趋势图，这对于性能测试和长期监控非常有价值。

5. 常见问题排查与实战技巧

在实际操作中，你会遇到各种各样的问题。这里记录一些典型的“坑”和解决思路。

5.1 权限问题与弹窗处理

问题：即使使用了--use-fake-ui-for-media-stream，某些网站或浏览器版本可能仍有权限提示。解决：确保在创建浏览器上下文时已经授予权限。

context = await browser.new_context( permissions=["camera", "microphone"], # ... 其他参数 )

如果弹窗仍然出现，可以使用page.wait_for_event('dialog')来监听并自动接受或拒绝，但更推荐通过上述启动参数和上下文权限彻底避免弹窗。

5.2 信令交换超时或失败

问题：在端到端测试中，Offer/Answer或Candidate交换失败。排查：

1. 检查SDP格式：确保通过page.evaluate传递的SDP字符串是完整的，没有被意外截断或转义。使用JSON.stringify和JSON.parse来安全传递。
2. 检查ICE Candidate：确保onicecandidate事件触发了，并且Candidate被正确收集和转发。有时在本地回环测试时，不需要STUN服务器，但如果你配置了，要确保STUN服务器地址可达（在CI环境中可能被墙）。
3. 使用更简单的网络：在测试初期，可以尝试禁用复杂的网络模拟，在纯净环境下先跑通信令流程。
4. 增加日志：在页面JS中大量使用console.log，然后在Playwright中监听console事件来获取日志：page.on('console', lambda msg: print(msg.text))。

5.3 无头模式下的媒体流问题

问题：在headless: true模式下，虚拟摄像头工作不正常，getUserMedia返回的流没有轨道。解决：这是Chromium无头模式的一个已知限制。解决方案是使用无头新模式。

browser = await p.chromium.launch(headless=True) # 传统的无头模式，可能有问题 # 改为 browser = await p.chromium.launch(headless=False) # 调试用 # 或，对于CI，使用无头新模式（如果支持） browser = await p.chromium.launch(headless='new') # Chromium 112+ 支持

如果无头新模式仍不行，最后的备选方案是使用xvfb-run（在Linux CI上）来虚拟一个显示环境，然后以非无头模式运行。

5.4 测试不稳定（Flaky Tests）

问题：测试有时成功有时失败，尤其是涉及定时和网络状态判断的断言。解决：

1. 使用Playwright的自动等待：多用page.wait_for_selector,page.wait_for_function，少用固定的page.wait_for_timeout。例如，等待远端视频元素开始播放：

   await page.wait_for_function("""() => { const video = document.querySelector('#remoteVideo'); return video && video.readyState > 2 && !video.paused; }""", timeout=10000)

2. 重试机制：对于非核心的、易受瞬时状态影响的断言（如特定的stats数值），可以使用pytest的@pytest.mark.flaky装饰器或自己实现简单的重试逻辑。
3. 隔离测试环境：确保每个测试用例使用独立的浏览器上下文(context)，避免测试间相互干扰。

5.5 性能与资源清理

问题：运行大量测试后，内存或进程占用过高。解决：

1. 严格关闭资源：确保每个测试结束后，page,context,browser都被正确close()。使用pytestfixture的yield模式可以很好地管理。
2. 避免全局浏览器实例：如果测试套件很大，考虑为每个测试或每组测试创建独立的浏览器实例，虽然启动稍慢，但稳定性更高。
3. 监控Stats内存泄漏：频繁调用getStats()并保存大量结果对象可能导致内存增长。在测试中，只保留需要断言的关键数据即可。

5.6 集成到CI/CD流水线

关键点：

1. 依赖安装：在CI配置中（如.github/workflows/test.yml），除了安装Python包，别忘了运行playwright install chromium。
2. 系统依赖：如果用到OpenCV，可能需要安装系统库，例如在Ubuntu Runner中：

   - name: Install system dependencies run: | sudo apt-get update sudo apt-get install -y libgl1-mesa-glx libglib2.0-0

3. Artifacts：将测试失败的截图、录制的视频、日志文件作为Artifacts上传，便于排查。

   # 在pytest配置或fixture中 @pytest.hookimpl(tryfirst=True, hookwrapper=True) def pytest_runtest_makereport(item, call): outcome = yield report = outcome.get_result() if report.when == "call" and report.failed: # 如果测试失败，截图 if "page" in item.funcargs: page = item.funcargs["page"] screenshot_path = f"screenshots/{item.name}.png" await page.screenshot(path=screenshot_path, full_page=True) # 将路径添加到报告 report.extra = getattr(report, 'extra', []) + [screenshot_path]

WebRTC自动化测试确实充满挑战，但通过Playwright对浏览器底层的强大控制力，加上Python生态丰富的分析工具，我们已经可以系统性地构建起一道质量防线。从基础的连接测试到复杂的媒体质量评估，这套方法论能帮助你将模糊的感官体验转化为客观的、可追溯的数据指标。记住，关键不是追求100%模拟真实用户，而是建立一套稳定、可重复的自动化检查点，快速捕捉回归问题，把宝贵的手动测试时间留给更复杂的场景探索和用户体验评估。