WebdriverIO TestingBot Service 使用指南云端测试元数据上报与本地安全隧道搭建【免费下载链接】webdriverioNext-gen browser and mobile automation test framework for Node.js项目地址: https://gitcode.com/GitHub_Trending/we/webdriverioTestingBot 是面向 Web 与移动端的云测试平台而wdio/testingbot-service是 WebdriverIO 官方为其提供的深度集成服务它能在测试运行期间把 job 的元数据name、passed、tags、public、build、extra实时同步到 TestingBot 平台并在需要访问本地被测环境时自动拉起 TestingBot Tunnel。读完本文你将掌握该服务的安装、配置、两个核心选项的用法并从源码层面理解它是如何统计失败、打测试注解、构建 REST 请求以及管理隧道生命周期的。安装把wdio/testingbot-service作为devDependency加入你的package.json推荐使用 npmnpm install wdio/testingbot-service --save-dev该包依赖wdio/logger、wdio/types、webdriverio以及隧道启动库testingbot-tunnel-launcher版本约束为^1.1.7见 package.json。从该包的engines声明可以看到它要求 Node.js 版本不低于18.20.0且以 ESMtype: module方式发布因此配置文件中应使用export const config { ... }的写法。WebdriverIO 本身的基础安装与入门指引可参考 GettingStarted。基础配置要使用该服务需要在wdio.conf.js中配置两项云平台凭据并把连接 hostname 指向 TestingBot 的接入点userTestingBot 的 API Key即TB_KEYkeyTestingBot 的 API Secret即TB_SECREThostname固定设置为hub.testingbot.comservices注册testingbot服务如需使用 TestingBot Tunnel 建立本地与被测虚拟机之间的安全连接再开启tbTunnel: true一个最小可用的配置示例如下// wdio.conf.js export const config { // ... user: process.env.TB_KEY, key: process.env.TB_SECRET, hostname: hub.testingbot.com, services: [ [testingbot, { tbTunnel: true }] ], // ... };建议把凭据放入环境变量而不是写死在配置文件里这样既避免密钥泄露也便于在 CI 中注入。examples/cloudservices/testingbot.js给出了不使用 Testrunner、直接通过webdriverio的remote()API 连接 TestingBot 的独立示例其中同样是设置hostname: hub.testingbot.com、user: process.env.TESTINGBOT_KEY、key: process.env.TESTINGBOT_SECRET对应的运行命令可参考 examples/cloudservices/README.md 中的说明。服务选项Options服务通过services: [[testingbot, { ... }]]数组的第二项传入配置对象其类型定义位于 types.ts。为了让 WebdriverIO 的 TypeScript 用户获得完整类型提示该包还在 index.ts 中通过declare global把TestingbotOptions合并进了WebdriverIO.ServiceOption接口。tbTunnel设为true时服务会在测试开始前启动 TestingBot Tunnel在被测机器与 TestingBot 运行浏览器测试的虚拟机之间建立一条安全的加密连接。典型使用场景是被测 Web 应用运行在你的本地环境或内网中云端浏览器需要能访问到它。TypeBooleanDefaultfalse隧道是否真的启动还取决于user/key是否已配置。在 launcher.ts 的onPrepare钩子中判断逻辑是if (!this.options.tbTunnel || !config.user || !config.key) { return }即只要三者任一缺失就静默跳过隧道启动不会报错。tbTunnelOpts当需要调整隧道行为时例如改变 Selenium 中继端口、写日志文件通过该对象传入 TestingBot Tunnel 的启动参数。它会被合并进最终传给testingbot-tunnel-launcher的选项中。TypeObjectDefault{}完整的可用字段见 types.ts 中TunnelLauncherOptions的定义常见项如下字段类型默认值说明apiKey/apiSecretstring—TestingBot API 凭据未显式传入时服务会自动用配置中的user/key补齐tunnelIdentifierstring随机生成当前隧道的唯一标识形如TB-tunnel-随机串verbosebooleanfalse输出更详细的隧道日志se-portnumber4445隧道 Selenium 中继监听端口logfilestring—把隧道日志写入指定文件proxystring—上游代理格式如localhost:1234fast-fail-regexpsstring—逗号分隔的域名列表这些域名请求将不经过隧道直连tunnelVersionstring—切换隧道版本如1.19或2.12.x 需 Java 8readyFilestring—隧道就绪时会 touch 该文件可用于外部进程感知就绪状态dnsstring—自定义 DNS 服务器例如8.8.8.8noproxystring—不启动本地代理要求用户自备运行在 8087 端口的代理noBumpbooleanfalse不让 TestingBot 用自己的证书覆盖 SSL 流量noCachebooleanfalse不缓存静态内容示例指定隧道标识、端口与日志文件。services: [ [testingbot, { tbTunnel: true, tbTunnelOpts: { tunnelIdentifier: my-tunnel, se-port: 4445, logfile: ./logs/tb-tunnel.log } }] ],隧道生命周期与 capability 注入隧道由独立的 launcher 类管理该类在 index.ts 中被导出为launcher属性供 WebdriverIO 在 worker 进程启动前调用。启动onPreparelauncher.ts 先生成隧道标识若用户未通过tbTunnelOpts.tunnelIdentifier指定则生成TB-tunnel-随机数然后把apiKey、apiSecret与tunnel-identifier合并到隧道启动参数中接着遍历全部 capability把tunnel-identifier注入到每个 capability 的tb:options里。这意味着测试会话发起时云端就知道该把浏览器流量路由到哪条隧道。代码还使用 Node.js 内置的perf_hooks打点在隧道成功启动后打印耗时日志TestingBot tunnel successfully started after Nms。能力覆盖onPrepare对 capabilities 的处理兼容单浏览器、普通数组配置以及 multiremote 嵌套结构保证每种形态下tb:options都会被正确补全。这一点在 tests/launcher.test.ts 中有专门用例验证即使 capability 原本已带有build等tb:options字段tunnel-identifier也会被合并进去而不会覆盖原有内容。关闭onCompletelauncher.ts 在测试全部结束后调用隧道实例的close回调完成优雅退出若隧道从未启动则直接返回。运行期 Job 元数据同步服务的主体是 service.ts 中的TestingBotService类它挂在测试框架的生命周期钩子上工作。构造函数从config中读取user/key并据此计算_isServiceEnabled只要两者齐全服务即被启用service.ts。失败统计服务通过多个钩子累计整个 session 的失败次数afterSuite当 suite 对象带error属性时计数 1service.tsafterTest测试结果passed: false时计数 1service.tsafterScenarioCucumber 场景失败时计数 1service.ts。在after钩子中还有一个针对 Mochabail的特殊处理若用户开启了mochaOpts.bail失败即中止afterTest/afterSuite可能根本来不及执行此时只要after收到非零的result就直接把失败数强制置为 1确保 job 被正确标记为失败service.ts。测试上下文注解为了让 TestingBot 报告能显示当前正在执行的用例服务在测试开始前通过浏览器执行一段注解脚本beforeTestMocha/Jasmine 下注入tb:test-contextsuite - titleJasmine 使用fullName源码里还对 Jasmine 顶层 suite 名为Jasmine__TopLevel__Suite的特殊情况做了处理改用真实测试名还原 suite 名称service.tsbeforeFeature/beforeScenarioCucumber 下分别注入tb:test-contextFeature: name和tb:test-contextScenario: nameservice.ts。注解通过setAnnotation调用浏览器的executeScript执行在多远程multiremote模式下会针对每个浏览器实例分别注入service.ts。REST 上报与鉴权测试结束后after钩子根据累计失败数调用updateJob把结果上报给 TestingBot请求地址为https://api.testingbot.com/v1/tests/sessionId方法为PUTservice.ts请求头携带Content-Type: application/json; charsetutf-8并对user:key做 Base64 编码后放入Authorization: Basic encodedservice.ts请求体由getBody构建test.name取 suite 标题test.success为1通过或0失败并会把 capability 中存在的name、tags、public、build、extra字段逐一拷贝进test对象service.ts。这正是 README 中updates the job metadata (name, passed, tags, public, build, extra)一句的底层实现上报完成后_failures会重置为 0service.ts。会话重载与多远程支持onReload当调用browser.reloadSession()使 session 更新时onReload钩子会以旧 sessionId 再补报一次 job并在标题后追加(N)序号标识重载次数多远程下还会先通过新 sessionId 反查对应的浏览器实例名service.ts。Multiremoteafter与onReload在isMultiremote为真时会对每个浏览器实例分别调用updateJob并把browserName作为前缀加入标题例如chromeA: suiteservice.ts。上述行为均有对应的单元测试覆盖失败计数、bail 场景、多远程分实例上报、REST 地址与 Basic Auth 头等见 tests/service.test.ts可作为理解服务行为的权威参考。小结wdio/testingbot-service用两个类把 TestingBot 集成拆解得非常清晰launcher 负责隧道生命周期与tb:options注入service 负责测试期间的注解、失败统计与 job 元数据 REST 上报。你只需在配置里提供user/key、把hostname指向hub.testingbot.com并注册服务即可获得云端跑测 本地隧道 结果回写的完整闭环若涉及多浏览器或会话重载该服务也都内置了对应的处理逻辑。源码入口为 index.ts相关实现可继续阅读 service.ts 与 launcher.ts。【免费下载链接】webdriverioNext-gen browser and mobile automation test framework for Node.js项目地址: https://gitcode.com/GitHub_Trending/we/webdriverio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 WebdriverIO TestingBot Service 使用指南：云端测试元数据上报与本地安全隧道搭建
WebdriverIO TestingBot Service 使用指南云端测试元数据上报与本地安全隧道搭建【免费下载链接】webdriverioNext-gen browser and mobile automation test framework for Node.js项目地址: https://gitcode.com/GitHub_Trending/we/webdriverioTestingBot 是面向 Web 与移动端的云测试平台而wdio/testingbot-service是 WebdriverIO 官方为其提供的深度集成服务它能在测试运行期间把 job 的元数据name、passed、tags、public、build、extra实时同步到 TestingBot 平台并在需要访问本地被测环境时自动拉起 TestingBot Tunnel。读完本文你将掌握该服务的安装、配置、两个核心选项的用法并从源码层面理解它是如何统计失败、打测试注解、构建 REST 请求以及管理隧道生命周期的。安装把wdio/testingbot-service作为devDependency加入你的package.json推荐使用 npmnpm install wdio/testingbot-service --save-dev该包依赖wdio/logger、wdio/types、webdriverio以及隧道启动库testingbot-tunnel-launcher版本约束为^1.1.7见 package.json。从该包的engines声明可以看到它要求 Node.js 版本不低于18.20.0且以 ESMtype: module方式发布因此配置文件中应使用export const config { ... }的写法。WebdriverIO 本身的基础安装与入门指引可参考 GettingStarted。基础配置要使用该服务需要在wdio.conf.js中配置两项云平台凭据并把连接 hostname 指向 TestingBot 的接入点userTestingBot 的 API Key即TB_KEYkeyTestingBot 的 API Secret即TB_SECREThostname固定设置为hub.testingbot.comservices注册testingbot服务如需使用 TestingBot Tunnel 建立本地与被测虚拟机之间的安全连接再开启tbTunnel: true一个最小可用的配置示例如下// wdio.conf.js export const config { // ... user: process.env.TB_KEY, key: process.env.TB_SECRET, hostname: hub.testingbot.com, services: [ [testingbot, { tbTunnel: true }] ], // ... };建议把凭据放入环境变量而不是写死在配置文件里这样既避免密钥泄露也便于在 CI 中注入。examples/cloudservices/testingbot.js给出了不使用 Testrunner、直接通过webdriverio的remote()API 连接 TestingBot 的独立示例其中同样是设置hostname: hub.testingbot.com、user: process.env.TESTINGBOT_KEY、key: process.env.TESTINGBOT_SECRET对应的运行命令可参考 examples/cloudservices/README.md 中的说明。服务选项Options服务通过services: [[testingbot, { ... }]]数组的第二项传入配置对象其类型定义位于 types.ts。为了让 WebdriverIO 的 TypeScript 用户获得完整类型提示该包还在 index.ts 中通过declare global把TestingbotOptions合并进了WebdriverIO.ServiceOption接口。tbTunnel设为true时服务会在测试开始前启动 TestingBot Tunnel在被测机器与 TestingBot 运行浏览器测试的虚拟机之间建立一条安全的加密连接。典型使用场景是被测 Web 应用运行在你的本地环境或内网中云端浏览器需要能访问到它。TypeBooleanDefaultfalse隧道是否真的启动还取决于user/key是否已配置。在 launcher.ts 的onPrepare钩子中判断逻辑是if (!this.options.tbTunnel || !config.user || !config.key) { return }即只要三者任一缺失就静默跳过隧道启动不会报错。tbTunnelOpts当需要调整隧道行为时例如改变 Selenium 中继端口、写日志文件通过该对象传入 TestingBot Tunnel 的启动参数。它会被合并进最终传给testingbot-tunnel-launcher的选项中。TypeObjectDefault{}完整的可用字段见 types.ts 中TunnelLauncherOptions的定义常见项如下字段类型默认值说明apiKey/apiSecretstring—TestingBot API 凭据未显式传入时服务会自动用配置中的user/key补齐tunnelIdentifierstring随机生成当前隧道的唯一标识形如TB-tunnel-随机串verbosebooleanfalse输出更详细的隧道日志se-portnumber4445隧道 Selenium 中继监听端口logfilestring—把隧道日志写入指定文件proxystring—上游代理格式如localhost:1234fast-fail-regexpsstring—逗号分隔的域名列表这些域名请求将不经过隧道直连tunnelVersionstring—切换隧道版本如1.19或2.12.x 需 Java 8readyFilestring—隧道就绪时会 touch 该文件可用于外部进程感知就绪状态dnsstring—自定义 DNS 服务器例如8.8.8.8noproxystring—不启动本地代理要求用户自备运行在 8087 端口的代理noBumpbooleanfalse不让 TestingBot 用自己的证书覆盖 SSL 流量noCachebooleanfalse不缓存静态内容示例指定隧道标识、端口与日志文件。services: [ [testingbot, { tbTunnel: true, tbTunnelOpts: { tunnelIdentifier: my-tunnel, se-port: 4445, logfile: ./logs/tb-tunnel.log } }] ],隧道生命周期与 capability 注入隧道由独立的 launcher 类管理该类在 index.ts 中被导出为launcher属性供 WebdriverIO 在 worker 进程启动前调用。启动onPreparelauncher.ts 先生成隧道标识若用户未通过tbTunnelOpts.tunnelIdentifier指定则生成TB-tunnel-随机数然后把apiKey、apiSecret与tunnel-identifier合并到隧道启动参数中接着遍历全部 capability把tunnel-identifier注入到每个 capability 的tb:options里。这意味着测试会话发起时云端就知道该把浏览器流量路由到哪条隧道。代码还使用 Node.js 内置的perf_hooks打点在隧道成功启动后打印耗时日志TestingBot tunnel successfully started after Nms。能力覆盖onPrepare对 capabilities 的处理兼容单浏览器、普通数组配置以及 multiremote 嵌套结构保证每种形态下tb:options都会被正确补全。这一点在 tests/launcher.test.ts 中有专门用例验证即使 capability 原本已带有build等tb:options字段tunnel-identifier也会被合并进去而不会覆盖原有内容。关闭onCompletelauncher.ts 在测试全部结束后调用隧道实例的close回调完成优雅退出若隧道从未启动则直接返回。运行期 Job 元数据同步服务的主体是 service.ts 中的TestingBotService类它挂在测试框架的生命周期钩子上工作。构造函数从config中读取user/key并据此计算_isServiceEnabled只要两者齐全服务即被启用service.ts。失败统计服务通过多个钩子累计整个 session 的失败次数afterSuite当 suite 对象带error属性时计数 1service.tsafterTest测试结果passed: false时计数 1service.tsafterScenarioCucumber 场景失败时计数 1service.ts。在after钩子中还有一个针对 Mochabail的特殊处理若用户开启了mochaOpts.bail失败即中止afterTest/afterSuite可能根本来不及执行此时只要after收到非零的result就直接把失败数强制置为 1确保 job 被正确标记为失败service.ts。测试上下文注解为了让 TestingBot 报告能显示当前正在执行的用例服务在测试开始前通过浏览器执行一段注解脚本beforeTestMocha/Jasmine 下注入tb:test-contextsuite - titleJasmine 使用fullName源码里还对 Jasmine 顶层 suite 名为Jasmine__TopLevel__Suite的特殊情况做了处理改用真实测试名还原 suite 名称service.tsbeforeFeature/beforeScenarioCucumber 下分别注入tb:test-contextFeature: name和tb:test-contextScenario: nameservice.ts。注解通过setAnnotation调用浏览器的executeScript执行在多远程multiremote模式下会针对每个浏览器实例分别注入service.ts。REST 上报与鉴权测试结束后after钩子根据累计失败数调用updateJob把结果上报给 TestingBot请求地址为https://api.testingbot.com/v1/tests/sessionId方法为PUTservice.ts请求头携带Content-Type: application/json; charsetutf-8并对user:key做 Base64 编码后放入Authorization: Basic encodedservice.ts请求体由getBody构建test.name取 suite 标题test.success为1通过或0失败并会把 capability 中存在的name、tags、public、build、extra字段逐一拷贝进test对象service.ts。这正是 README 中updates the job metadata (name, passed, tags, public, build, extra)一句的底层实现上报完成后_failures会重置为 0service.ts。会话重载与多远程支持onReload当调用browser.reloadSession()使 session 更新时onReload钩子会以旧 sessionId 再补报一次 job并在标题后追加(N)序号标识重载次数多远程下还会先通过新 sessionId 反查对应的浏览器实例名service.ts。Multiremoteafter与onReload在isMultiremote为真时会对每个浏览器实例分别调用updateJob并把browserName作为前缀加入标题例如chromeA: suiteservice.ts。上述行为均有对应的单元测试覆盖失败计数、bail 场景、多远程分实例上报、REST 地址与 Basic Auth 头等见 tests/service.test.ts可作为理解服务行为的权威参考。小结wdio/testingbot-service用两个类把 TestingBot 集成拆解得非常清晰launcher 负责隧道生命周期与tb:options注入service 负责测试期间的注解、失败统计与 job 元数据 REST 上报。你只需在配置里提供user/key、把hostname指向hub.testingbot.com并注册服务即可获得云端跑测 本地隧道 结果回写的完整闭环若涉及多浏览器或会话重载该服务也都内置了对应的处理逻辑。源码入口为 index.ts相关实现可继续阅读 service.ts 与 launcher.ts。【免费下载链接】webdriverioNext-gen browser and mobile automation test framework for Node.js项目地址: https://gitcode.com/GitHub_Trending/we/webdriverio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考