Selenium + Chrome 自动化中常用 ChromeOptions 参数说明（实践总结）
在基于 Selenium 的 UI 自动化测试中，Chrome 默认的用户交互行为并不完全适合自动化执行。常见问题包括：系统级弹窗阻塞、浏览器提示条遮挡元素、CI 环境不稳定等。
本文结合实际项目，总结一组在自动化测试框架层常用的 ChromeOptions 参数，说明它们的作用和适用场景。
一、为什么这些参数要放在“框架层”而不是用例层
ChromeOptions 控制的是浏览器启动行为和全局特性，例如：
- 是否弹出系统协议确认框
- 是否显示“被自动化控制”的提示条
- 是否启用 GPU、沙箱等底层特性
这些问题一旦出现，往往会导致整条测试链路阻塞或不稳定，而不是某一个用例的问题。因此：
ChromeOptions 参数应该在 Driver 初始化阶段统一注入，属于测试框架的基础能力，而不是用例逻辑。
二、常用 ChromeOptions 参数说明
1️⃣--disable-features=ExternalProtocolDialog
作用
关闭 Chrome 的External Protocol Dialog，即当页面触发mailto:、tel:等外部协议时弹出的“选择应用程序”系统对话框。
解决的问题
- Selenium 无法感知和操作该系统级弹窗
- 自动化用例会卡死，后续步骤全部失败
适用场景
- 页面包含
mailto:链接 - 企业系统集成了外部客户端协议
结论
自动化测试中强烈建议启用，这是典型的“自动化专用参数”。
2️⃣--disable-default-apps
作用
禁用 Chrome 内置的一些默认 Web 应用（如 Gmail、YouTube PWA）。
说明
- 与 External Protocol Dialog 没有直接对应关系
- 更多是减少默认应用参与协议处理的可能性
结论
可作为稳定性优化项，但不是解决外部协议弹窗的关键参数。
3️⃣--disable-gpu
作用
禁用 GPU 硬件加速。
解决的问题
- CI / 虚拟机环境中 GPU 不可用或驱动不稳定
- 页面渲染异常、偶发崩溃
结论
在自动化和 CI 场景下属于常规参数。
4️⃣--disable-dev-shm-usage
作用
避免 Chrome 使用/dev/shm（共享内存）。
解决的问题
- Docker / Linux 环境下
/dev/shm空间过小导致浏览器崩溃
结论
CI / 容器环境必备参数。
5️⃣--no-sandbox
作用
关闭 Chrome 沙箱机制。
说明
- 某些 Linux / 容器环境下，沙箱会导致 Chrome 无法启动
风险
- 降低安全隔离能力
结论
仅用于测试环境，不要用于真实用户浏览器。
6️⃣ 关闭“被自动化控制”提示条（InfoBar）
常见提示为：
“Chrome is being controlled by automated test software”
该提示会遮挡页面，影响元素定位。
推荐做法（新版本 Chrome）
options.AddExcludedArgument("enable-automation");options.AddAdditionalOption("useAutomationExtension",false);说明
enable-automation是触发该提示的关键开关--disable-infobars在新版本 Chrome 中已不稳定或被忽略
结论
不要在用例里“点掉”提示条，应该在 Driver 初始化阶段直接关闭。
7️⃣--disable-blink-features=AutomationControlled（谨慎使用）
作用
- 减少页面通过
navigator.webdriver等特征识别自动化
注意
- 属于“反自动化检测规避”范畴
- 不适合默认开启
结论
内部系统一般不需要，只有在明确遇到检测干扰时才考虑。
三、推荐的参数分类思路
为了可维护性，建议在框架中按目的分类，而不是零散添加：
- 稳定性参数：GPU、sandbox、dev-shm
- 自动化阻塞消除：ExternalProtocolDialog、通知、翻译
- UI 干扰消除：automation infobar
- 特殊场景参数：headless、反检测相关
这样在出现问题时，可以快速定位是哪一类参数引入的行为变化。
四、总结
- 系统级弹窗、浏览器提示条属于自动化必须在框架层解决的问题
- ChromeOptions 是测试框架二次开发的重要组成部分
- 不建议在用例层通过 UI 操作去“修补”这些问题
