应使用requests+beautifulsoup而非selenium测试html静态页面，因其轻量、快速（20ms vs 800ms）、断言直接、无需浏览器开销，且更契合静态页“验证输出结果”的本质需求。
HTML静态页面本身没有后端逻辑和动态交互，直接套用Selenium或Playwright做“UI自动化测试框架”容易走偏——它不是不能跑，而是90%的封装、等待、重试逻辑都成了冗余负担。真正该做的，是轻量、可维护、能快速验证渲染正确性的检查体系。
为什么不用Pytest+Selenium跑静态页测试
静态页测试的核心诉求是：内容是否准确、链接是否有效、结构是否合规、样式是否加载。Selenium启动浏览器、管理driver、处理隐式等待、截图对比……这些开销对纯HTML页面来说属于过度设计。
-
Selenium启动 Chrome 实例平均耗时 800ms+，而一次requests.get()+BeautifulSoup解析只要 20ms -
find_element类方法在无 JS 渲染的静态页里，和直接查soup.find("h1", class_="title")效果一致，但前者要写 fixture、处理异常、关 driver - 你无法用
assert "Welcome" in driver.page_source稳定断言——页面可能含异步 JS 注入内容，但静态页根本不该有这类逻辑
用requests + BeautifulSoup做基础校验
这是最贴合静态页本质的组合：不模拟浏览器，只验证 HTML 输出结果。适合 CI 中快速冒烟、PR 检查、部署后自检。
- 安装只需：
pip install requests beautifulsoup4 - 读取本地文件或远程 URL 都支持：
requests.get("http://localhost:8000/index.html")或open("index.html").read() - 定位元素更直白：
soup.select("nav a[href^='/product']")比driver.find_elements(By.CSS_SELECTOR, "nav a[href^='/product']")少 3 行 setup 代码 - 断言语义清晰：
assert len(soup.select("footer .copyright")) == 1，失败时直接打印soup.prettify()定位问题
如何验证静态页的链接有效性
静态站最常见问题是死链（尤其是 Markdown 转 HTML 后相对路径出错），人工点一遍不现实，自动化必须覆盖这一项。
- 提取所有
a[href]和img[src]属性值，过滤掉锚点（#top）、协议外链（https://）和 data URI - 对剩余路径做本地映射判断：若当前在
/docs/guide.html，href="../api/index.html"应解析为./api/index.html，再用os.path.exists()检查 - 对外链用
requests.head(url, timeout=5)，跳过 3xx 重定向（加allow_redirects=False），只关注 200/404 - 注意：不要并发发大量请求，GitHub Pages 或 Netlify 静态托管通常无速率限制，但本地开发服务器（如
python -m http.server）不支持并发
生成可读性高的失败报告
静态页测试失败往往不是“脚本崩了”，而是“文案写错了”“导航少了一级”“图片路径拼错了”。报告得让人一眼看懂哪里不对。
- 避免用
pytest-html：它默认把整个 HTML 渲染成 iframe，实际你只想看到<h2>错误标题</h2>和预期值 - 推荐用
print(f"❌ 缺失 <meta name="description">，当前有 {len(meta_desc)} 个")直接输出到控制台 - CI 场景下加
--tb=short即可，不需要堆砌截图或视频——静态页没状态变化，截图只是重复显示源码 - 若需存档，用
json.dump({"url": url, "missing_links": broken_list}, fp)生成简洁的 JSON 报告，方便下游系统消费
真正难的不是写几个 assert，而是定义清楚哪些该验、哪些不该验。比如「所有按钮都有 aria-label」听起来合理，但若团队没统一无障碍规范，这条规则就会变成没人维护的僵尸断言。静态页测试的价值，在于守住底线——链接通、结构对、关键文案在，其余交给人工抽检或设计走查。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
