测试接口测试性能测试Mock【免费下载链接】karateTest Automation Made Simple项目地址https://gitcode.com/gh_mirrors/ka/karate点击查看免费下载本文围绕 docs/DRIVER_PLAN.md 展开。这是一份由 Karate 浏览器驱动团队维护的已确认开放缺陷清单punch list of verified-open defects记录了 CDP 驱动CdpDriver中 8 个经反复验证仍然存在的真实缺陷F1–F8以及每个缺陷的修复方案、验证命令和必须遵守的公共 API 契约。读完本文你将掌握如何复现并验证这些缺陷、每个缺陷对应的源码位置与修复思路、驱动测试的 CI 验证命令含 W3C 与 Docker e2e以及哪些 CDP 扩展接口被视作公共 API 不可随意改动。一、文档定位从重构计划到缺陷清单DRIVER_PLAN.md的定位很特殊——它曾经是一份重构计划机械式 DRY 去重、状态机抽取、测试套件削减但后来被废弃最终缩减为一份缺陷清单 消费方契约。要理解这 8 个缺陷首先得理解这段演变史当时的 CI 失败模式DriverFeatureTest是 CI 的红榜常客——100 次运行中有 34 次变红且每次抽样的失败都指向这同一个测试。重构计划的各 tranche批次本是为了让这个不稳定的子系统变得可驾驭。转折点——并行隔离修复1f2b5f9b9/a24051c4e两个提交落地后问题被根治每个池化槽位pooled slot获得独立的 incognito 浏览器上下文而不是共享默认上下文。此后55 次 CI 运行仅出现 1 次失败而且那次还是无关的报告文件名回归report-filename regression。结果不稳定因素消失重构 tranche 被整体未启动即退役retired unstarted。保留下来的是评审过程中发现的一批真实缺陷——即本文要讲的 F1–F8。从源码结构看这一结论与 CdpDriver.java 中大量针对并行池化场景的防御逻辑相互印证字段级volatile标注、browserContextId作用域限定、OOPIF 会话清理、loaderId 绑定等待等都是在并行执行摩擦中啃出来的实现细节详见 docs/DRIVER.md 的Loader-bound page-load waits章节。二、验证修复的标准操作流程文档给出了修复任何缺陷后必须跑的三条命令Docker 为 DriverFeatureTest 所必需# driver e2e需要 Docker——parallel(2) 并发熔炉 mvn test -pl karate-core -Pcicd -DtestDriverFeatureTest # 推送前完整跑一遍 cicd profile mvn -B verify -Pcicd # 触碰 Driver.java / W3cDriver.java 时必须跑的 W3C 任务 mvn -B verify -Pw3c -pl karate-core -am两条血泪教训式告诫本地跑绿不能证明并发正确性。那些随隔离修复一起移除lock标签的 feature在损坏的代码上、于快速开发机上以无锁状态全部通过。一把锁只应在修复前代码上会失败的测试面前被移除——BrowserContextIsolationTest就是为隔离工作准备的那把试金石。loader-binding 级联不是可以随手整理的地方。isDomReady()/checkDocumentReadyState()/verifyJsExecution()编码了约 6 个经过取证式发现的 Chrome 行为DRIVER.md 的Loader-bound page-load waits一节解释了每个谓词存在的原因。所有缺陷修复对它是加法绝不进入其内部改动。三、缺陷清单总览#缺陷一句话摘要修复方向验证要求F1submit()从未在任何后端生效在两个覆写中调用waitIfSubmitRequested()全量套件 -Pw3c新增submit().click()场景F2Driver.select(int)默认实现漂移只派发inputchange默认实现改用commitFieldEventsJs-Pw3celement.featureF3跨线程字段currentTargetId/currentFrame缺volatile加volatile并注释线程归属全量套件F4池重置reset不重置 frame 状态reset 前先switchFrame((String) null)全量套件 oopif.featureOopifPooledReuseTestF5drainOpenedTargets()排队了驱动未打开的标签用openerId过滤先补TabE2eTest断言tab-switch.feature 下游 e2eF6Network.enable在标签切换后丢失activateTarget()中重新武装 Network / Fetch全量套件 Network 事件 pin intercept.featureF7waitForPageLoad抛原始RuntimeException改抛DriverException全量套件F8关闭传输标签transport tab杀死驱动新增 final 字段保存 transport targetId getConnectedTargetId()全量套件 tab-switch.feature 负向测试下面逐个缺陷结合源码展开。四、F1submit()从未在任何后端生效症状submit()用于标记下一个动作会触发页面导航随后动作完成后驱动应等待文档变化。但在Driver.java中waitIfSubmitRequested()只被接入了默认的Driver.click()实现Driver.java 定义等待逻辑#L834-L838的默认click()中调用它而CdpDriver.clickCdpDriver.java与W3cDriver.clickW3cDriver.java:374都以覆写实现绕过了它。结果等待静默 no-op记录的 hash 从未被清除而且没有任何测试覆盖该路径。修复在两个覆写中调用waitIfSubmitRequested()。文档明确删除submit()曾被考虑过但被否决——它是文档化的 v1 兼容 API参见 docs/DRIVER.md 的 V1 兼容性章节。验证全量套件 -Pw3c在element.feature中针对现有表单页新增一个submit().click()场景防止它再次无声死亡。五、F2Driver.select(int)默认实现漂移症状Driver.select(int)的默认实现Driver.java:915只派发inputchange两个事件而 CDP 覆写CdpDriver.java使用Locators.commitFieldEventsJs派发完整的input/change/blur/focusout事件序列——后者是为 blur-commit 型框架失焦才提交的框架添加的。W3C 后端继承了这个过时的默认实现行为与 CDP 不一致。修复默认实现改用commitFieldEventsJs一行改动即可治愈 W3C。验证-Pw3celement.feature。F1/F2 的共同根因三份近似重复的副本文档给出了承重背景Driver接口已经为整个元素操作面提供了默认实现Driver.java:804-1035CdpDriver只重实现了其中约 15 个仅额外加了retryIfNeededBaseElement.existingW3cDriver又把这些方法重实现了一遍。三份几乎相同的副本正是滋生这两个 bug 的土壤。真正的一拷贝终态是把自动等待上提到Driver默认实现、经由一个beforeAction(locator)钩子实现但该方案会改变 W3C 的时序行为、且其测试在独立 CI 任务中运行——因此 F1/F2 先修已经流血的这两份副本。六、F3跨线程字段缺失volatile症状两个字段存在跨线程读写却没有volatile修饰currentTargetIdCdpDriver.java——由activateTarget()在场景线程写入被Target.targetCreated事件处理器在事件线程读取currentFrame#L156——被Target.detachedFromTarget处理器置 null被场景线程读写。而它们在同一字段块中的邻居mainFrameId、pageSessionId、terminated、interceptHandler等见#L89-L215全部是volatile——唯独这两个漏了。修复补上volatile并加注释标明接触这两个字段的线程各自是谁。验证全量套件。七、F4池重置不重置 frame 状态症状若一个场景结束时恰好切换进了 OOPIF跨源 iframeresetDriver()发出的setUrl(about:blank)会从 iframe 的 CDP 会话发出——导航的是 iframe 而不是页面。同源情况下currentFrame会残留到下一个场景。今天这个缺陷被 loader 绑定机制掩盖了但 reset 实际上静默地没有干它该干的活。修复在 PooledDriverProvider.java 的resetDriver()中于setUrl(about:blank)之前、现有 try/catch 之内先调用driver.switchFrame((String) null)。注意(String)强转是仓库既有风格且只有 String 重载接受 null对照 docs/DRIVER.md 的 Frame Switching 一节switchFrame(null)回退到父页面会话。修复位于 Provider 层因此对后端无关backend-agnostic。验证全量套件oopif.featureOopifPooledReuseTest后者与 DRIVER.md 中提到的DriverFeatureTest.testOopifSurvivesPooledDriverReuse同属 OOPIF 跨场景复用防护。八、F5drainOpenedTargets()排队了驱动未打开的标签症状Target.targetCreated处理器不做任何过滤CdpDriver.java因此浏览器里每一个新标签都会进入openedTargets队列。池化驱动的标签集合因构造方式而收窄兄弟槽位位于其他上下文pageTargets()按browserContextId过滤枚举但驱动自己上下文内打开的标签——即默认上下文驱动挂在人类也在用的浏览器上的正常形态也就是下文的外部消费方——仍然会被全部排队。修复openerId∈ {当前 target, 已知 OOPIF target} 是承重过滤器而不是可选的精化。文档特别警告browserContextId检查对任何默认上下文驱动都是 no-op——而start()/connect(pageUrl)的每个调用方都是默认上下文——所以它只修好了最不需要修的池化场景。优先采用openerId或两者同时context ∧ opener。处理器当前两个字段都没捕获需先从targetInfo中提取。该过滤器天然保留由被驱动页面弹出的标签这一契约——那种流程本来就是 opener 关联的。验证tab-switch.feature 下游 e2e。文档特别指出仅按 context 过滤在下游是不可证伪的unfalsifiable——对下游它是 no-op套件无论修没修都会保持绿色。因此第一步必须先给TabE2eTest加断言window.open/target_blank弹出的标签其openerId必须等于驱动的currentTargetId——今天没有任何测试观察这一点。九、F6Network.enable是承重的却在标签切换后丢失症状初始化注释:640Required for cookie operations已过时——cookie命令其实不依赖它。但外部CdpEventListener消费方依赖 Network 事件流所以 enable必须保留。真正的 bug 是反过来的activateTarget()CdpDriver.java在每次switchPage/switchPageById/close()后重新武装了 Runtime / Page / lifecycle / auto-attach唯独没有重新武装 Network——于是新会话上事件流断电。同类问题Fetch.enable也没重新武装#L4103-L4109处按需启用导致活跃的intercept()在标签切换后静默停止暂停请求。修复在activateTarget()中重新武装Network.enable修正过时注释点明真正的依赖方当interceptHandler活跃时重新武装Fetch.enable不要移除Network.enable——早先的一个草案曾提议将其视为残留物删除那是错的。验证全量套件新增switchPage之后 Network 事件仍到达的 pin 测试intercept.feature 标签切换/拦截组合检查。十、F7waitForPageLoad抛出原始RuntimeException症状waitForPageLoadCdpDriver.java:1440在失败路径抛出原始RuntimeException而同一驱动中其他所有失败路径都抛DriverException破坏了异常语义的一致性。修复改抛DriverException诊断信息不变。验证全量套件。十一、F8关闭传输标签会杀死驱动症状CDP WebSocket 是页面绑定的/devtools/page/id。关闭该标签——无论是直接关、还是switchPageById后close()——都会断开连接此后每一次 CDP 调用都报 CONNECTION_CLOSED且没有任何线索指向根因。transport targetId 在 connect 时被提取进currentTargetIdCdpDriver.java:442与:451两处但每个activateTarget都会覆写它因此该值无法持久保留close()没有守卫也没有访问器——多标签调用方只能靠解析 ws URL 反推。修复connect 时把 transport targetId 捕获进一个新的 final 字段让针对该标签的close()抛出明确的DriverException而不是留下一个下一次调用才晦涩失败的驱动暴露getConnectedTargetId()让多标签调用方能有意识地挑选幸存者。验证全量套件tab-switch.feature一个小型负向测试断言响亮失败。为何不做浏览器级 WebSocket文档明确把浏览器级 WebSocket 传输/devtools/browser/…而非页面绑定连接列为**故意搁置Parked, deliberately**的方案它确实能从类层面消除 F8连接会熬过每一次标签关闭但会改变每一个消费方的 connect 语义CdpDriver.connect的调用方今天传的是页面 URL并且与处处相关的会话路由相互作用。因此 F8 的守卫 访问器是受控的修复。十二、CDP 扩展面是公共 API文档强调CdpDriver的 CDP 专属扩展面被仓库之外的、基于 karate-core 构建的工具文档中指名 karate-max在CdpDriver自身注释中已出现消费。F5、F6、F8 正是因这个消费方而存在脱离它几乎没有意义。因此必须按公共 API 对待签名冻结列出的行为即契约。冻结表面Frozen surface以下接口的签名不得改动addCdpEventListener/removeCdpEventListener·CdpEventListener·addInitScript/removeInitScript·addBinding/removeBinding·addScriptToEvaluateOnNewDocument/remove…·objectId(locator)·getCdpClient()含CdpClient.method/browserMethod的 fluent 风格·getTargetInfos()·drainOpenedTargets()·switchPageById·getFrameOwnerBackendNodeId/describeNode·CdpDriver.connect/start/connectNewContext·isResponsive/isReady/waitUntilReady·CdpLauncher.getWebSocketUrl·CdpDriverOptions.Builder·Locators的公共 JS 生成器existsJs、findAllJs、selector、toFunction等·DialogOpenedException。行为契约Behavioral contracts外部监听器收到每一个 CDP 事件按到达顺序在单一的串行化cdp-event-*派发线程上。不得把外部派发移出该线程也不得按会话过滤事件。Network 事件流运行在被驱动的会话driven session上——这正是 F6 存在的根本原因。Init-script 注册表按名称幂等、依赖有序立即注入当前文档并注入其后每个新文档removeInitScript保留已注入的活副本。driver.js对共装模块播种的部分window.__kjs采取扩展、绝不覆盖策略ensureKjsRuntime中的守卫。自身打开对话框的脚本返回nullcdpEval中的DialogOpenedException路径未处理的对话框可通过getDialog()轮询持续观察——消费方无需注册onDialog处理器即可驱动对话框。drainOpenedTargets()持续报告被驱动页面弹出的弹窗/新标签——消费方点击后检测标签就靠它。F5 的openerId过滤器保证这一点不被破坏。switchPage(String)、getPages()、getTargetInfos()限定在驱动自己的浏览器上下文由a24051c4e改变而非浏览器全局。仅对处于自己 incognito 上下文的驱动即池化场景这正是改动的目的与旧行为有差异。已知消费方只通过connect/start构建驱动、从不创建上下文因此其全部驱动都是默认上下文该改动对它是 no-op。PageLoadStrategy.DOMCONTENT是下游的一等策略不只是本仓库套件默认跑的DOMCONTENT_AND_FRAMES。覆盖缺口Coverage gap该扩展面在开源侧几乎零覆盖——InitScriptE2eTest钉住了注册表其余只有下游测试。文档建议在InitScriptE2eTest旁补钉以下内容binding 往返addBinding→ 页面侧调用 → 外部监听器收到Runtime.bindingCalled外部监听器在初始会话和switchPage之后都能收到 Network 事件守护 F6 的重新武装部分__kjs的扩展不覆盖守卫一个DOMCONTENT策略场景。objectId(locator)→DOM.setFileInputFiles已由开源侧的inputFile()表面钉住UploadE2eTest与upload.feature针对upload.htmlCDP W3C 双通道见 docs/DRIVER.md 的inputFile()一节。验证协议Validation protocol对上述任何一处的改动不算完成直到下游消费方已基于改动重建、且其驱动 e2e 套件全绿。编译错误是便宜且显眼的这些契约才是会静默断裂的东西。十三、时间线两个关键节点2026-07-15计划最初写成重构 tranche 缺陷清单 消费方清查。同日并行隔离工作抢在 tranche 之前落地5dbb9d707——元素动作在标记的 not-found 错误上重新解析自己的 locatorf38e9c4be——setUrl()在 loader 提交data:/about:时设屏障使池化 reset 不会在场景首次真实导航发出时仍在途1f2b5f9b9——每个池化槽位获得独立 incognito 浏览器上下文clearCookies()本质是Network.clearBrowserCookies、作用于整个上下文此前每个场景启动都会擦掉并行运行的其他场景的 cookie同一提交还修了标签泄漏和webSocketUrl池 bug此前每个槽位都连到同一个页面a24051c4e——标签枚举按browserContextId限定。随后移除了 3 个隔离用lock全部由BrowserContextIsolationTest证明不必要该测试在修复前代码上失败是解锁安全的依据。Cookie.feature的第二个锁理由set 与 read 竞争从来不是时序竞争——它是另一个场景的 reset 擦掉了 cookie jar锁一直在掩盖这个 bug。2026-08-04重构 tranche 未启动即退役文件缩减为缺陷清单与消费方契约。依据a24051c4e之后 55 次 CI 运行仅 1 次失败且为无关的报告文件名回归——tranche 本想搭脚手架对抗的不稳定性已经消失。8 个缺陷全部复核确认仍存在于代码中。switchPage的上下文限定改动仍欠一次下游重建 e2e不过它被标记的契约问题已通过代码审查inspection定案。十四、给维护者的行动清单综合全文若你计划在本仓库上修复这些缺陷按依赖顺序建议先补测试后修码F5 的TabE2eTest断言、F6 的Network 事件跨switchPagepin、F1 的submit().click()场景——这些是防静默复死的哨兵动Driver.java/W3cDriver.java必须跑-Pw3c动 loader 绑定级联必须只做加法F4 在 Provider 层修复后端无关F3 一行volatileF7 换异常类型F8 涉及新字段与访问器、需同步下游消费方重建所有改动以mvn -B verify -Pcicd为最终闸门并遵循下游重建 e2e 全绿的验证协议。# 快速复现基线Docker 必需 mvn test -pl karate-core -Pcicd -DtestDriverFeatureTest关联阅读docs/DRIVER.md架构参考loader 绑定、OOPIF、池化生命周期、CdpDriver.java缺陷所在实现、Driver.java默认实现与 F1/F2 根因、PooledDriverProvider.javaF4 修复位置。赞分享测试接口测试性能测试Mock【免费下载链接】karateTest Automation Made Simple项目地址https://gitcode.com/gh_mirrors/ka/karate点击查看免费下载相关推荐OpenProject 17.1.2 安全修复与缺陷修复深度解读OpenProject 17.1.2 安全修复与缺陷修复深度解读 OpenProject 17.1.2 是 2026 02 26 发布的维护版本核心工作是修复后端前端项目管理企业应用协同办公OpenProject 9.0.2 发布解析relative_url_root 子路径部署修复与缺陷修复全览OpenProject 9.0.2 发布解析relative_url_root 子路径部署修复与缺陷修复全览 本文以 OpenProject 9.0.2 官方后端前端项目管理企业应用协同办公NumPy 1.17.5 发布说明解读缺陷修复、构建改进与升级路径分析NumPy 1.17.5 发布说明解读缺陷修复、构建改进与升级路径分析 本篇文章基于当前仓库中保留的官方发布文档 doc/source/release/1.1科学计算数据分析上一篇Driver Store Explorer3步彻底清理Windows驱动垃圾轻松释放数GB磁盘空间下一篇从零跑通WrenAI 自然语言查数据库文本转SQL完整上手指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考