【UI自动化相关】

一、UI框架介绍与发现的问题

1、分层设计

复制代码

 UI 自动化框架（Python+Pytest+Selenium）

分层设计
├─ config/                 # 环境/账号/数据库连接
├─ core/                   # 二次封装 Selenium → BasePage
│   ├─ base_page.py        # 显式等待、重试、失败截图、日志
│   ├─ element.py          # 统一管理定位方式（CSS/XPATH 互备）
├─ pages/                   # PO 模式，一个页面对应一个 class
├─ test_cases/              # 只放测试步骤 + 断言，无定位器
├─ test_data/               # YAML/JSON 数据驱动
├─ utils/                   # 随机身份证、银行卡、OCR 识别、邮件通知
├─ reports/                 # Allure 原始文件 → Jenkins 插件可视化
└─ scripts/                 # 一键本地 docker-selenium 网格 & 失败重跑

2、核心功能

① 数据驱动：@pytest.mark.parametrize + YAML，单 case 平均代码行数从 120 → 35。

② 失败重跑：pytest-rerunfailures + 截图 + 日志自动挂载到 Allure。

③ 分布式：Selenium Grid 4 本地 4 节点，10 条用例并行 → 单轮从 38 min ↓ 11 min。

④ 业务脚手架

⑤ 质量门禁：

3、case失败率增高，如何排查？

python 复制代码

case 失败率突然升高，排查思路？

思路：分层过滤 → 数据说话 → 工具链定位 → 预防动作。

落地句子："上月 Pipline 失败率从 2% 飙到 14%，我按'三层漏斗'排查：

① 环境层：
对比上次成功镜像，发现前端静态资源 CDN 换域名，新域名被公司代理拦截→白屏；
让运维把新域名加入代理白名单，一层解决 60% 失败。

② 代码层：
Allure 里失败截图全是'请稍后'loading，定位到后端限流中间件升级，接口 RT 99 线 400 ms→1.2 s；
把 base_page 里显式等待最长 10 s 调到 20 s，并把重试次数 2→3，二层解决 30%。

③ 用例层：
剩余 10% 是数据冲突：A、B 两 case 都用同一银行卡号提现，数据库 UNIQUE 锁；
在 utils 里把'银行卡号'改成雪花算法生成唯一后缀，三层解决最后 10%。
整体失败率回到 1.8%，并补充一条监控：每天跑 50 轮 Smoke，失败率>5% 自动发飞书告警。"

4、从selenium迁移到playwright怎么做？

python 复制代码

思路：评估 → 双跑 → 分模块 → 统一封装 → 老框架下线。


落地句子："迁移分五步，预计 6 个月完成：

Step1： 技术评估
        用 2 周把 20 条核心 case 用 Playwright 重写
        结论：速度↑55%，CPU↓30%，视频/Trace 自带，ROI 为正。

Step2 ：封装统一
        沿用 PO 思想，新建 playwright/pages、playwright/cases，
        把 base_page 改成同步+异步双通道，支持 pytest-asyncio。

Step3 ：数据与脚本分离
        原 YAML 数据层不动，只把读取层抽象成 DataProvider，Selenium/Playwright 共用，
        零数据迁移成本。

Step4 ：双跑门禁
        Jenkins 加并行 stage：Selenium 标记 legacy，Playwright 标记 next；
        要求 next 通过率 100% 且运行时长<=legacy 60% 才允许合并。

Step5 ：灰度与下线
        按模块灰度：先开户→再交易→再后台；
        每阶段跑 1 周生产对比监控，0 缺陷则切流量 20%→50%→100%；
        最终 legacy 框架仅保留 10 条兼容性 case，其余下线，机器资源释放 40%。"

5、Grid 节点资源竞争怎么解决？

Grid 节点资源竞争 = 同一台机器（节点）上同时跑的浏览器进程太多，把 CPU、内存、端口、甚至 /dev/shm 都用光了，导致 WebDriver 会话建不起来或跑着跑着就崩

python 复制代码

思路：先抛现象 → 根因分析 → 三级治理 → 数据验证。

落地句子：

"去年双十一前 4节点并发  常报 SessionNotCreatedException。


排查发现三处资源竞争：
1、浏览器进程残留：teardown 里只 driver.quit()，但 Chrome 有 5% 概率僵尸进程；
→ 需要加 --no-sandbox --disable-dev-shm，同时用 systemd 定时任务每 30 min 清理一次僵尸进程。

2、CPU 抢占：节点 4C8G，开 4 个 Chrome 即满载；
→ 需要降并发度 4→2，并把 Xvfb 分辨率从 1920×1080 调到 1280×720，CPU 利用率 95%→68%。

3、端口耗尽：WebDriver BiDi 默认起 9222+ 随机口，Grid 同一节点并发高时口耗尽；
→ 需要升级 Selenium 4.11，显式指定端口区间 9200-9250，并扩大内核端口范围 net.ipv4.ip_local_port_range。
做完后 Grid 稳定性 97.2%→99.8%，并发 10→16 条用例时间反而缩短 3 min。"

6、怎么发现是资源竞争而不是代码 bug？"

python 复制代码

给出现场套路：

监控三板斧

top/htop 一眼看 CPU、内存飙红。

dmesg -T | grep -i kill 确认 OOM-killer 是否出手。

ss -s 或 cat /proc/net/sockstat 看端口使用是否逼近 3 万。