Protractor 端到端测试基础设施架构深度解析：从组件到进程通信的全链路

测试【免费下载链接】protractorE2E test framework for Angular apps项目地址https://gitcode.com/gh_mirrors/pr/protractor点击查看免费下载导读本篇文章以 Protractor 官方文档《How It Works / Infrastructure》为骨架结合仓库源码与配置实现系统拆解 Protractor 作为 AngularJS 端到端测试框架的运行时基础设施架构三大核心组件Test / Server / Browser如何各司其职一次简单的click()背后如何产生三次 WebDriver 命令以及 Protractor 如何通过额外的同步命令保证测试与 Angular 应用的稳定性。读完本文你将掌握 Protractor 与 Selenium WebDriver 的协作模型、进程间通信协议以及waitForAngular同步机制的底层实现原理为排查测试超时、同步失败类问题打下基础。一、基础设施总览Protractor 与 Selenium 的职责划分Protractor 是一个面向 AngularJS 应用的端到端测试框架它以 Node.js 程序的形式运行原生支持 Jasmine 和 Mocha 两类测试框架详见 docs/frameworks.md。而 Selenium 是一个通用的浏览器自动化框架它包含三大组成部分Selenium Server、WebDriver APIs和WebDriver 浏览器驱动。Protractor 本身并不直接操作浏览器而是与 Selenium 协作构建一套可以模拟用户与运行在浏览器或移动设备中的 Angular 应用交互的自动化测试基础设施。这套设施的分工如下┌─ Test测试进程───────────────┐ ┌─ Server ─────┐ ┌─ Browser ─────────────────────┐ │ Node.JS │ │ Selenium │ │ WebDriver Browser Driver │ │ ├─ Protractor │ │ Server * │ │ └─ AngularJS App被测应用 │ │ └─ WebDriverJS * │ │ │ │ │ └────────────────────────────────┘ └──────────────┘ └───────────────────────────────┘ * WebDriverJS 即 Selenium * 可本地(standalone) * Selenium WebDriver 驱动 WebDriver API 的 JS 绑定 运行也可远程(Sauce Chrome 等浏览器实现 Labs)运行上图来自 docs/components.png直观展示了三个功能区块的层级关系Test 区块测试代码运行在Node.JS中最外层是Protractor其内部依赖WebDriverJS即 Selenium WebDriver API 的 JavaScript 绑定。Server 区块Selenium Server是连接测试脚本与浏览器的中间节点既可以本地以 standalone 方式运行也可以通过 Sauce Labs 等远程服务运行。Browser 区块浏览器通过WebDriver Browser Driver与 Selenium Server 通信驱动的实现因浏览器而异Chrome 对应 chromedriver 等其内部加载的是被测的AngularJS App。围绕这一架构原文档特别提醒使用 Protractor 时需要始终牢记三点Protractor 是 WebDriverJS 的包装器wrapper。WebDriverJS 是 Selenium WebDriver API 的 JavaScript 绑定编写测试前应通读 WebDriverJS 用户指南了解其 API 风格。WebDriver 命令是异步的。它们被调度在控制流Control Flow上并返回 promise而非原始值。详见 WebDriver Control Flow。测试脚本向 Selenium Server 发送命令再由 Selenium Server 与浏览器驱动通信——这正是下文要展开的进程通信链路。二、进程通信测试脚本、服务器与浏览器三进程协作一个使用 Selenium WebDriver 的测试涉及三个进程测试脚本进程、服务器进程和浏览器进程。它们之间的通信关系如下上图来自 docs/processes.png的关键信息可以归纳为Test 进程即你的测试进程使用你所选语言的 WebDriver API 绑定Protractor 场景下就是通过 Node.js 使用 JavaScript 绑定。Server 进程即 Selenium Server运行在本机selenium-server-standalone.jar或远程服务如 Sauce Labs上。Browser 进程被浏览器驱动扩展后的浏览器。驱动的具体实现取决于浏览器Chrome 对应chromedriver二进制文件Firefox 对应 geckodriver/扩展等。两条链路的通信协议分别为Test → Server通信方式取决于 Selenium Server 的运行方式。Node.js 与本地 standalone Selenium Server 之间走HTTP 通信。Server → Browser通信使用WebDriver Wire ProtocolJSON Wire Protocol一种 JSON 协议。命令最终由Browser Driver解释并执行。Selenium Server 的职责是解释来自测试的命令并将其转发给一个或多个浏览器。在 Protractor 场景下seleniumAddress配置项指向的正是这个服务器地址如http://localhost:4444/wd/hub。三、一次点击三次命令Protractor 的额外同步步骤3.1 为什么需要额外的一步与普通的 Selenium 测试不同Protractor 会在对浏览器执行任何操作之前先运行一段额外命令以确保被测应用已经稳定stabilized——即 Angular 已经完成所有超时timeout和异步请求的处理可以安全地继续测试。以下面这行测试代码为例element(by.css(button.myclass)).click();这一行代码最终会产生三条命令发送给 Browser Driver序号WebDriver 命令作用1/session/:sessionId/execute_asyncProtractor 让浏览器执行一段自定义 JavaScript询问 Angular 何时处理完所有 timeout 与异步请求、应用准备就绪然后测试才能继续2/session/:sessionId/element发送查找元素button.myclass的命令3/session/:sessionId/element/:id/click发送执行点击操作的最后命令也就是说Protractor 的每个 WebDriver 动作查找、点击、输入等都被隐式地包裹在等待 Angular 稳定的同步步骤中。3.2 源码中的对应实现上述第一条命令在仓库中有完整实现。在 lib/browser.ts 的waitForAngular方法见 lib/browser.ts#L514-L542中Protractor 通过私有的executeAsyncScript_方法向浏览器发送EXECUTE_ASYNC_SCRIPT命令对应 Wire Protocol 中的/session/:sessionId/execute_asyncasync waitForAngular(opt_description?: string): Promiseany { let description opt_description ? - opt_description : ; if (!await this.waitForAngularEnabled()) { return true; } let runWaitForAngularScript async(): Promiseany { ... let rootEl await this.angularAppRoot(); return this.executeAsyncScript_( clientSideScripts.waitForAngular, Protractor.waitForAngular() ${description}, rootEl); }; ... }而真正在浏览器端运行的等待逻辑位于 lib/clientsidescripts.js 的waitForAngular函数见 lib/clientsidescripts.js#L135。该脚本会先等待 AngularJS 1.x 的 testability 就绪再对 AngularJS 2.x 执行waitForAngular2回调见 lib/clientsidescripts.js#L142-L221从而同时兼容新旧版本 Angular 应用functions.waitForAngular function(rootSelector, callback) { // Wait for angular1 testability first and run waitForAngular2 as a callback var waitForAngular1 function(callback) { ... }; var waitForAngular2 function() { ... }; ... waitForAngular1(waitForAngular2); // Wait for angular1 and angular2 };此外waitForAngular还内置了超时与错误处理当浏览器端脚本执行超时例如 Chrome 报asynchronous script timeout时会转换为明确的错误信息抛出见 lib/browser.ts#L543-L549。这正是测试中常见的等待 Angular 同步超时问题的来源之一。四、连接驱动的多种方式DriverProvider 架构理解了进程通信模型后一个关键问题是Protractor 是如何建立这些连接的仓库通过DriverProvider驱动提供器抽象了所有连接方式。在 lib/driverProviders/README.md 中明确了其接口契约setupDriverEnv()在测试框架加载前调用负责预启动环境如本地 Selenium Server避免首个测试超时getNewDriver()setupDriverEnv之后立即调用一次以生成初始 driver测试中途用户请求额外浏览器时也会再次调用getExistingDrivers()/quitDriver()/teardownEnv()负责 driver 实例的获取与回收其中teardownEnv必须调用 driver 的quit方法。所有 DriverProvider 的公共基类在 lib/driverProviders/driverProvider.ts它封装了getNewDriver通过selenium-webdriver的Builder构建驱动可选用 Blocking Proxy、quitDriver、teardownEnv等通用逻辑。具体采用哪种 Provider由 lib/driverProviders/index.ts 的buildDriverProvider函数根据配置动态决策见 lib/driverProviders/index.ts#L29-L66其决策优先级如下配置条件选用的 DriverProvider适用场景directConnect: trueDirect跳过 Selenium Server直连 Chrome/Firefox 驱动seleniumAddressseleniumSessionIdAttachSession挂接到已存在的 Selenium 会话seleniumAddressHosted连接已在运行的 Selenium ServertestobjectUsertestobjectKeyTestObject远程云端设备TestObjectkobitonUserkobitonKeyKobiton远程云端设备KobitonbrowserstackUserbrowserstackKeyBrowserStack远程云端BrowserStacksauceUsersauceKeySauce远程云端Sauce LabsseleniumServerJarLocal本地启动 standalone Selenium ServermockSeleniumMock模拟 Selenium测试/调试用以上均未配置Local兜底尝试本地 standalone 启动这些配置项的定义与完整注释见 lib/config.ts其中seleniumServerJar、seleniumAddress、sauceUser/sauceKey、browserstackUser/browserstackKey、directConnect五种是主要的连接方式。如果同时配置了多种连接参数buildDriverProvider还会通过logWarnings发出警告提示存在多余参数。4.1 Local本地 standalone Selenium ServerLocalProvider 在 lib/driverProviders/local.ts 中实现它通过addDefaultBinaryLocs_自动定位seleniumServerJar、chromedriver、geckodriver的二进制位置默认取自webdriver-manager的下载目录若缺失会提示运行webdriver-manager update然后启动SeleniumServer并取得其地址写入seleniumAddress见 lib/driverProviders/local.ts#L108-L146。相关配置项包括seleniumServerStartTimeout等待本地 Server 启动的超时默认 30000ms见 lib/config.ts#L33-L38localSeleniumStandaloneOpts透传给 SeleniumServer 的port、args如-browserTimeout60与jvmArgs如指定 IE 驱动路径见 lib/config.ts#L48-L67chromeDriver/geckoDriver分别指定 chromedriver 与 geckodriver 路径会以-Dwebdriver.chrome.driver/-Dwebdriver.gecko.driver系统属性的形式传给 Selenium jar。4.2 Direct免服务器的直连模式DirectProvider 在 lib/driverProviders/direct.ts 中实现它绕过 Selenium Server由 Protractor 进程直接创建浏览器驱动会话。从源码看Direct仅支持chrome与firefox两种browserName见 lib/driverProviders/direct.ts#L30-L44其他浏览器会抛出BrowserError。这正是原文档注释中directConnect 仅适用于 Firefox 和 Chrome的底层原因。4.3 Hosted连接已有 Selenium ServerHostedProviderlib/driverProviders/hosted.ts实现最为轻量它的setupDriverEnv仅记录一条日志Using the selenium server at ...实际的连接工作由基类DriverProvider.getNewDriver通过Builder.usingServer(seleniumAddress)完成——这也印证了测试脚本 → Selenium Server → 浏览器驱动这条进程链路见 lib/driverProviders/driverProvider.ts#L48-L70。五、异步与稳定性两条不可忽视的配套机制基础设施架构中还有两条与稳定性直接相关的配套机制这里一并说明WebDriver 控制流Control Flow由于所有 WebDriver 命令都是异步的WebDriverJS 维护一个待执行 promise 队列来控制执行顺序Protractor 会适配 Jasmine让每个 spec 在退出前自动等待控制流清空并让 Jasmine 的expect理解 promise详见 WebDriver Control Flow。如需禁用控制流可在配置中设置SELENIUM_PROMISE_MANAGER: false配置项见 lib/config.ts并参考 spec/ts 目录下的无控制流测试示例。Plugins 同步钩子waitForAngular还会调用插件系统的waitForPromise与waitForCondition见 lib/browser.ts#L537-L542让自定义插件也能参与等待应用稳定的过程。六、总结一条命令的完整生命周期把整条链路串起来Protractor 中任何一条测试动作如点击按钮的完整生命周期是Test 进程Node.jsProtractor 在正式动作前先通过waitForAngular发送execute_async命令等待 Angular 处理完所有 timeout 与异步请求Test → Server命令经 HTTP 发送给 Selenium Server或经directConnect直连驱动Server → BrowserSelenium Server 将命令按 JSON Wire Protocol 转发给浏览器驱动Browser浏览器驱动执行命令查找元素、执行点击操作页面上的 AngularJS 应用结果回传执行结果沿原链路返回并在控制流中按 promise 序列依次兑现。理解这一基础设施模型是后续配置多浏览器multiCapabilities、远程云平台Sauce Labs / BrowserStack、直连模式directConnect以及排查同步超时问题的共同基础。相关配置项全集可查阅 lib/config.ts驱动连接方式的接口契约详见 lib/driverProviders/README.md。赞分享测试【免费下载链接】protractorE2E test framework for Angular apps项目地址https://gitcode.com/gh_mirrors/pr/protractor点击查看免费下载相关推荐Kubernetes client-go 架构深度解析从 REST 客户端到 Controller 基础设施的设计全貌Kubernetes client go 架构深度解析从 REST 客户端到 Controller 基础设施的设计全貌 client go 是 Kuberne开发工具版本控制研发协作Base UI 端到端测试指南Playwright Vite 的 e2e 基础设施解析Base UI 端到端测试指南Playwright Vite 的 e2e 基础设施解析 端到端e2e测试是验证 Base UI 组件在真实浏览器环境下前端UI组件Kubernetes E2E 测试框架 test/e2e/framework 源码级解析面向 Ginkgo 的端到端测试基础设施Kubernetes E2E 测试框架 test/e2e/framework 源码级解析面向 Ginkgo 的端到端测试基础设施 Kubernetes 仓库中云原生容器编排集群管理微服务上一篇DSO安装与配置终极指南解决所有依赖问题下一篇3 步快速把真实地图变成 MinecraftArnis 真实地形生成手把手指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考