UI自动化测试中，有哪些核心技能几乎能涵盖所有测试场景呢？

做过UI自动化测试的同学，大概率都有过这样的崩溃时刻： 明明手动操作一遍就能成功的场景，写成自动化脚本就频繁报错；元素定位明明没错，却总出现“元素不可见”“超时加载”；想模拟浏览器的特殊操作（比如清除缓存、模拟网络异常），翻遍资料也找不到简洁的实现方式；跨浏览器兼容测试更是麻烦，每个浏览器都要单独调试，耗时又费力。 UI测试本身就繁琐，再加上这些“卡脖子”问题，不仅拖慢测试进度，还会让测试效率大打折扣——很多时候，我们不是在写脚本，就是在调试脚本的路上。 其实不用这么内耗，今天给大家分享UI测试必备的两个Agent Skill技能：chrome-cdp 和 playwright-cli，能很好的解决上述这些痛点，让我们可以把更多精力放在核心测试场景上。 无论是新手入门，还是老测试优化工作流，掌握这两个技能，都能让你的UI测试效率翻倍，下面就来拆解一下。 一、先说说：当前UI测试的核心痛点 在介绍这两个skill之前，我们得先梳理清楚当前UI测试的核心痛点有哪些，因为只有知道问题在哪，才能明白这两个技能的价值所在，看看你日常工作中是不是也经常遇到这些情况： 元素定位难，脚本稳定性差：传统UI自动化依赖元素定位工具（如selenium、playwright），但遇到动态元素、隐藏元素、iframe嵌套，就容易定位失败；甚至浏览器渲染延迟，都会导致脚本报错，调试成本极高。 浏览器操作受限，场景覆盖不全：想模拟浏览器的高级操作（如模拟网络卡顿、清除localStorage、截图录屏、模拟手机端适配），传统工具要么实现复杂，要么根本不支持，导致很多边缘场景无法覆盖。 跨浏览器兼容测试繁琐：不同浏览器（Chrome、Firefox、Edge）的内核不同，脚本在一个浏览器能跑通，在另一个浏览器就报错，需要单独适配，重复工作量大。 脚本编写效率低，上手门槛高：传统自动化脚本需要手动编写大量代码，新手入门慢；而且脚本复用性差，换一个测试场景，就要重新编写或大幅修改。 调试不便，问题定位难：脚本报错后，只能一步步打印日志排查，无法直观看到浏览器的运行状态，很难快速定位是元素问题、环境问题，还是脚本逻辑问题。 这些痛点，本质上是“工具适配性不足”和“操作复杂度高”导致的。 而chrome-cdp和playwright-cli，正是针对性解决这些问题的两个测试“神器”——一个专注于Chrome浏览器的深度操控，一个专注于跨浏览器的高效自动化，两者搭配，几乎能覆盖所有UI测试场景。 两个工具的项目地址放在文章末尾，文章较长，建议先点赞收藏，慢慢看 二、chrome-cdp: Chrome浏览器的“底层操控神器” 1. 什么是chrome-cdp？ chrome-cdp 全称 Chrome DevTools Protocol（Chrome开发者工具协议），简单来说，它是Chrome浏览器提供的一套“底层接口”，允许我们通过代码（或命令）直接操控Chrome浏览器的所有行为——包括页面渲染、网络请求、元素操作、调试日志等，相当于直接“接管”Chrome的核心功能。 它不是一个独立工具，而是Chrome内置的协议，我们可以通过Python、JavaScript等语言调用它的接口，实现传统UI测试工具做不到的高级操作。很多知名测试工具（如Playwright、Puppeteer），底层其实都依赖了chrome-cdp。 2. 能解决哪些UI测试痛点？ chrome-cdp 最核心的价值，是“突破传统工具的限制”，可以解决以下几个核心痛点： 解决“元素定位不稳定”：直接通过浏览器底层接口获取元素，不受动态渲染、隐藏元素影响，定位成功率大幅提升； 解决“浏览器高级操作难”：轻松实现模拟网络异常（断网、卡顿）、清除缓存/本地存储、截图录屏、模拟手机端设备等操作； 解决“调试不便”：可实时获取浏览器的运行日志、网络请求详情，报错后能快速定位问题根源，不用再盲目排查。 3. 基础用法（新手友好，快速上手） chrome-cdp 的用法有两种：一种是通过命令行直接调用（适合快速调试），另一种是通过代码调用（适合集成到自动化脚本）。 3.1 命令行用法（快速调试） 首先，确保你的Chrome浏览器已安装，然后打开命令行，输入以下命令，启动Chrome并开启CDP协议： # Windows chrome.exe --remote-debugging-port=9222 --user-data-dir=c:/chrome_data # Mac/Linux /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome_data # Linux服务器无头模式 google-chrome-stable --headless=new --remote-debugging-port=9222 --no-sandbox 说明： --remote-debugging-port=9222：指定调试端口为9222，后续通过这个端口连接Chrome； --user-data-dir：指定Chrome的用户数据目录，避免影响本地正常使用的Chrome配置。 --headless=new：新版无头模式（支持完整功能） 启动后，打开浏览器访问 http://localhost:9222，就能看到当前Chrome的所有标签页，点击任意标签页，即可进入CDP调试界面，可直接查看网络请求、元素信息、执行JS命令等。 3.2 集成到自动化脚本 场景1：性能指标自动化采集 使用CDP采集Web性能数据，替代手动F12操作 class PerformanceTester: def __init__(self, cdp: CDPController): self.cdp = cdp def measure_page_load(self, url: str): """测量页面加载性能""" # 启用性能监控 self.cdp.send("Performance.enable") self.cdp.send("Network.enable") # 清除缓存（模拟首次访问） self.cdp.send("Network.clearBrowserCache") # 记录开始时间 start_time = time.time() # 导航到页面 self.cdp.send("Page.navigate", {"url": url}) self.cdp.wait_event("Page.loadEventFired", timeout_s=30) # 获取Performance API数据 timing_result = self.cdp.eval(""" JSON.stringify(performance.timing) """) timing = json.loads(timing_result) # 计算关键指标 navigation_start = timing["navigationStart"] metrics = { "DNS查询": timing["domainLookupEnd"] - timing["domainLookupStart"], "TCP连接": timing["connectEnd"] - timing["connectStart"], "首字节时间(TTFB)": timing["responseStart"] - navigation_start, "DOM解析": timing["domContentLoadedEventEnd"] - timing["domInteractive"], "完整加载": timing["loadEventEnd"] - navigation_start, "总耗时": time.time() - start_time } # 获取资源加载详情 entries_result = self.cdp.eval(""" JSON.stringify(performance.getEntriesByType('resource').map(r => ({ name: r.name, duration: r.duration, size: r.transferSize }))) """) resources = json.loads(entries_result) return { "页面": url, "指标(ms)": metrics, "资源数": len(resources), "慢资源": [r for r in resources if r["duration"] > 1000][:5] # Top5慢资源 } # 批量性能测试 def test_batch_performance(urls: list): cdp = CDPController(ws_url) tester = PerformanceTester(cdp) results = [] for url in urls: result = tester.measure_page_load(url) results.append(result) print(f"📊 {url}: 加载耗时 {result['指标(ms)']['完整加载']}ms") # 生成性能报告 with open("performance_report.json", "w") as f: json.dump(results, f, indent=2, ensure_ascii=False) return results 场景2：与Selenium 4集成（增强现有框架） Selenium 4原生支持CDP，可以无缝集成 from selenium import webdriver from selenium.webdriver.chrome.service import Service from selenium.webdriver.common.by import By # 启动浏览器 driver = webdriver.Chrome(service=Service("./chromedriver")) # 获取CDP会话 dev_tools = driver.devtools # 创建CDP会话 dev_tools.create_session() # ===== 示例1：模拟地理位置 ===== def test_geo_location(): # 设置地理位置为上海 driver.execute_cdp_cmd("Emulation.setGeolocationOverride", { "latitude": 31.2304, "longitude": 121.4737, "accuracy": 100 }) driver.get("https://map.baidu.com") # 验证地图是否定位到上海 # ===== 示例2：模拟弱网环境 ===== def test_slow_network(): # 启用网络监控 dev_tools.send(dev_tools.network.enable()) # 模拟3G网络 driver.execute_cdp_cmd("Network.emulateNetworkConditions", { "offline": False, "latency": 200, # 200ms延迟 "downloadThroughput": 780 * 1024 / 8, # 780 Kbps "uploadThroughput": 330 * 1024 / 8 # 330 Kbps }) driver.get("https://your-app.com") # 测试在弱网下的加载表现 # ===== 示例3：拦截并修改请求 ===== def test_request_interception(): # 启用Fetch域 driver.execute_cdp_cmd("Fetch.enable", { "patterns": [{"urlPattern": "*api*", "requestStage": "Request"}] }) # 添加监听器（需要通过WebSocket或Selenium的EventListener） driver.get("https://your-app.com") # 验证特定API请求是否携带了正确参数 # ===== 示例4：性能指标采集 ===== def test_performance_metrics(): # 启用性能监控 driver.execute_cdp_cmd("Performance.enable") driver.get("https://your-app.com") # 获取性能指标 metrics = driver.execute_cdp_cmd("Performance.getMetrics", {}) print("性能指标:", metrics) # 获取页面加载时间 timing = driver.execute_script(""" return JSON.stringify(performance.timing) """) 场景3：与Playwright集成（深度控制） Playwright底层基于CDP，可以直接访问原始CDP会话 from playwright.sync_api import sync_playwright def test_with_cdp_session(): with sync_playwright() as p: browser = p.chromium.launch() context = browser.new_context() page = context.new_page() # 创建CDP会话（直接访问Chrome DevTools Protocol） cdp_session = context.new_cdp_session(page) # ===== 高级网络控制 ===== # 启用网络监控 cdp_session.send("Network.enable") # 模拟特定网络条件 cdp_session.send("Network.emulateNetworkConditions", { "offline": False, "downloadThroughput": 1.5 * 1024 * 1024 / 8, # 1.5 Mbps "uploadThroughput": 750 * 1024 / 8, # 750 Kbps "latency": 150 # 150ms延迟 }) # ===== 性能监控 ===== cdp_session.send("Performance.enable") page.goto("https://example.com") # 获取性能指标 metrics = cdp_session.send("Performance.getMetrics") print("Chrome性能指标:", metrics) # ===== 模拟设备 ===== cdp_session.send("Emulation.setDeviceMetricsOverride", { "width": 390, "height": 844, "deviceScaleFactor": 3, "mobile": True, "screenOrientation": {"angle": 0, "type": "portraitPrimary"} }) # 截图验证移动端渲染 page.screenshot(path="mobile_view.png", full_page=True) browser.close() 场景4：视觉回归测试（结合截图对比） class VisualRegressionTester: def __init__(self, cdp: CDPController): self.cdp = cdp self.baseline_dir = "./visual_baselines" self.current_dir = "./visual_current" def capture_full_page(self, name: str): """捕获完整页面截图（包含视口外内容）""" # 获取页面完整尺寸 metrics = self.cdp.send("Page.getLayoutMetrics") content_width = metrics["contentSize"]["width"] content_height = metrics["contentSize"]["height"] # 设置视口为页面完整尺寸 self.cdp.send("Emulation.setDeviceMetricsOverride", { "width": content_width, "height": content_height, "deviceScaleFactor": 1, "mobile": False }) # 截图 self.cdp.screenshot(f"{self.current_dir}/{name}.png") # 恢复默认视口 self.cdp.send("Emulation.clearDeviceMetricsOverride") def compare_with_baseline(self, name: str): """对比当前截图与基线""" from PIL import Image import pixelmatch baseline = Image.open(f"{self.baseline_dir}/{name}.png") current = Image.open(f"{self.current_dir}/{name}.png") diff = pixelmatch(baseline, current, threshold=0.1) if diff > 100: # 差异像素数阈值 raise AssertionError(f"❌ 视觉回归测试失败: {name}, 差异像素: {diff}") print(f"✅ 视觉测试通过: {name}") # 使用示例 def test_ui_regression(): cdp = CDPController(ws_url) tester = VisualRegressionTester(cdp) # 测试关键页面 pages = [ ("首页", "https://app.com/home"), ("商品详情", "https://app.com/product/123"), ("购物车", "https://app.com/cart") ] for name, url in pages: cdp.send("Page.navigate", {"url": url}) cdp.wait_event("Page.loadEventFired") time.sleep(2) # 等待动画完成 tester.capture_full_page(name) tester.compare_with_baseline(name) 4. 在UI自动化测试中的应用场景 chrome-cdp 通常更适合“Chrome浏览器专属场景”的自动化，尤其是需要高级操作的场景，比如： 异常场景测试：模拟网络断连、网络延迟、弱网环境，测试页面的异常提示和恢复机制； 缓存相关测试：清除localStorage、sessionStorage，测试页面的缓存逻辑是否正常； 截图录屏自动化：测试过程中自动截图、录屏，用于测试报告留存或问题复现； 复杂元素操作：处理iframe嵌套、动态加载元素，避免传统定位工具的报错问题； 调试优化：实时获取浏览器日志、网络请求，快速定位自动化脚本的报错原因。 三、playwright-cli: 跨浏览器UI自动化“神器” 1. 什么是playwright-cli？ playwright-cli 是 Microsoft 推出的 Playwright 自动化测试工具的命令行版本，Playwright 本身是一个跨浏览器自动化工具，支持Chrome、Firefox、Edge、Safari等所有主流浏览器，而playwright-cli 则是它的“命令行简化版”——无需编写复杂代码，通过命令就能快速实现UI自动化，同时也支持代码集成，兼顾新手友好和实用性。 它的核心优势是“跨浏览器兼容”和“脚本自动生成”，能大幅降低UI自动化的上手门槛，提升脚本编写效率，解决传统自动化工具“跨浏览器适配难”的痛点。 2. 能解决哪些UI测试痛点？ 如果说chrome-cdp 专注于Chrome的深度操控，那么playwright-cli 就是“全能型选手”。 它重点解决了以下几个痛点： 解决“跨浏览器兼容测试繁琐”：一套脚本，可直接运行在Chrome、Firefox、Edge等所有主流浏览器，无需单独适配； 解决“脚本编写效率低”：支持“录制脚本”，手动操作一遍，自动生成自动化脚本，新手也能快速上手； 解决“元素定位难”：内置强大的元素定位引擎，自动识别动态元素、隐藏元素，无需手动编写定位表达式； 解决“脚本稳定性差”：自动等待页面加载、元素渲染，避免因渲染延迟导致的报错，脚本成功率极高。 3. 在UI自动化测试中的应用场景 playwright-cli 适合“全场景、跨浏览器”的UI自动化，尤其是需要规模化、高效执行的场景，比如： 跨浏览器兼容测试：一套脚本，批量运行在所有主流浏览器，快速排查浏览器兼容问题； 常规UI自动化脚本编写：通过录制功能，快速生成脚本，减少手动编码工作量，适合新手或高频场景； 回归测试：将常用测试场景录制为脚本，每次版本更新后，一键运行，快速完成回归测试； 多环境测试：支持指定环境（开发、测试、生产），一键切换，无需修改脚本； 并行测试：支持多浏览器、多用例并行执行，大幅缩短测试时间，提升测试效率。 4. 基础用法（新手友好，3步上手） playwright-cli 的用法非常简单，核心分为“安装→录制→运行”三步，全程无需复杂配置，新手也能快速上手。 # 1. 安装Playwright CLI npm install -g @playwright/cli@latest npx playwright install # 安装浏览器 # 2. 体验UI模式（强烈推荐） npx playwright test --ui # 3. 录制你的第一个测试 npx playwright codegen https://testfather.cn 常用命令一览： 命令 功能 npx playwright test 运行所有测试 npx playwright test --ui UI模式交互式运行 npx playwright codegen 录制生成测试代码 npx playwright show-trace 查看测试追踪 npx playwright test --debug 调试模式运行 问题1：调试困难 传统方式：测试挂了，看日志猜原因，复现靠运气。 解决方案： Playwright CLI的UI模式：每一步操作都有前后截图，鼠标悬停就能看到DOM状态变化 CDP的Debugger Domain：可以在特定代码行设置断点，精确控制执行流程 # 开启UI模式，像看视频一样看测试执行 npx playwright test --ui 问题2：元素定位不稳定 传统方式：Thread.sleep(3000)硬等，或者XPath一写就失效。 解决方案： Playwright的自动等待：内置智能等待机制，元素可操作时才执行 CDP的DOM查询：通过Runtime.evaluate直接执行JS获取元素，绕过复杂的Selector # Playwright CLI直接执行JS获取元素 playwright-cli eval "document.querySelector('#app').innerText" 问题3：多浏览器兼容性 传统方式：Chrome一套、Firefox一套、Safari又一套。 解决方案： Playwright CLI的Project配置：一份配置，指定Chromium/Firefox/WebKit CDP的通用性：Edge、Opera等Chromium内核浏览器都支持CDP # 同时跑三个浏览器 npx playwright test --project=chromium --project=firefox --project=webkit 问题4：性能测试工具割裂 传统方式：Lighthouse、PageSpeed、WebPageTest来回切换。 解决方案： CDP的Performance Domain：浏览器原生指标采集，直接获取Chrome性能时间线、内存堆快照 Playwright的Tracing：自动生成性能追踪文件，可视化分析 # 生成性能追踪文件 npx playwright test --trace=on npx playwright show-trace trace.zip 5. 实战用法 场景1：快速验证页面功能（零代码） 需求：测试登录流程是否正常，不写一行代码。 # 1. 录制操作生成代码 npx playwright codegen https://your-app.com/login # 2. 直接在命令行执行测试 npx playwright test --headed --grep "login" 效果：Playwright自动打开浏览器，执行操作，生成可复用的测试脚本。 场景2：AI驱动的智能测试（自然语言转自动化） 需求：用自然语言描述，让AI自动执行测试。 结合Playwright CLI与AI Skills # 用户输入："打开百度，搜索'UI自动化'，截图保存" # AI自动生成并执行： playwright-cli open https://www.baidu.com playwright-cli type "#kw" "UI自动化" playwright-cli click "#su" playwright-cli screenshot --full-page 核心价值：测试人员用自然语言描述场景，AI自动转换为可执行命令 场景3：深度网络层测试（CDP高级用法） 需求：验证前端错误监控是否上报，拦截并分析上报请求。 // 通过CDP监听网络请求 const CDP = require('chrome-remote-interface'); async function testErrorReporting() { const client = await CDP(); const { Network, Page } = client; // 开启网络监控 await Network.enable(); // 拦截所有请求 Network.requestWillBeSent((params) => { if (params.request.url.includes('error-report')) { console.log('✅ 错误上报请求已捕获:', params.request); } }); // 导航到测试页面 await Page.navigate({ url: 'https://your-app.com' }); } 效果：可以验证错误监控、性能上报、埋点数据等前端"黑盒"行为。 场景4：移动端适配测试（视口模拟） 需求：测试页面在不同手机上的显示效果。 # Playwright CLI调整视口模拟iPhone playwright-cli resize 375 667 # iPhone SE尺寸 playwright-cli screenshot --full-page mobile-view.png # 或者使用内置设备配置 npx playwright test --project="Mobile Safari" 场景5：CI/CD集成（无头模式+报告） 需求：在Jenkins/GitHub Actions中自动运行测试。 # 无头模式运行，生成HTML报告 npx playwright test --reporter=html # 查看报告 npx playwright show-report # 多Worker并行，提速 npx playwright test --workers=4 四、实战建议：两个Skills搭配使用 chrome-cdp 和 playwright-cli 不是对立的，而是互补的——将两者搭配使用，chrome-cdp给了你浏览器底层的"上帝视角"，playwright-cli给了你高效便捷的"操作界面"。两者结合，既能应对复杂的底层协议操作，又能享受现代自动化工具的便捷性。 能覆盖几乎所有UI测试场景，实现效率最大化，给大家一个实战搭配建议： 常规自动化场景：用 playwright-cli 录制脚本，实现跨浏览器兼容测试、常规回归测试，快速生成脚本，减少编码工作量； Chrome专属高级场景：用 chrome-cdp 补充高级操作，比如模拟网络异常、清除缓存、复杂元素调试等，解决playwright-cli 无法实现的细节场景； 脚本优化：用 playwright-cli 生成基础脚本，再用 chrome-cdp 的接口优化脚本细节（如提升定位稳定性、添加异常处理），让脚本更健壮； 调试排错：遇到脚本报错，先用 chrome-cdp 查看浏览器底层日志、网络请求，快速定位问题根源，再用playwright-cli 调整脚本。 五、新手入门建议 UI自动化测试的终极形态，不是写更多的代码，而是让工具理解你的意图。 chrome-cdp和playwright-cli，一个代表深度，一个代表广度。装上它们，你会发现：原来UI测试可以这么丝滑。 名称 项目地址 chrome-cdp https://github.com/pasky/chrome-cdp-skill playwright-cli https://github.com/microsoft/playwright-cli 如果是UI测试新手，建议先从 playwright-cli 入手——它的录制功能能让你快速上手，感受到自动化测试的便捷，建立信心；等熟悉了基础操作后，再学习 chrome-cdp，补充高级操作能力，两者结合，就能轻松应对所有UI测试场景。 如果是有一定经验的测试同学，建议直接掌握两者的搭配用法——用playwright-cli 提升效率，用chrome-cdp 解决难点，能大幅优化你的工作流，摆脱重复劳动，把精力放在更有价值的测试设计上。 UI测试的核心是“高效、稳定、全面”，而chrome-cdp 和 playwright-cli，正是帮你实现这一目标的两个关键技能。赶紧动手尝试起来，相信你会发现，UI测试其实可以很轻松～ 更多、更详细、全面的AI测试、AI编程、AI技能进阶系统化实战教程，欢迎加入：「狂师. AI进化社」一起探讨学习！