做过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协议：- # Windowschrome.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操作
[code]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"
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ |
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
