桌面应用测试开发工具【免费下载链接】appium-desktopAppium Server in Desktop GUIs for Mac, Windows, and Linux项目地址https://gitcode.com/gh_mirrors/ap/appium-desktop点击查看免费下载Appium Desktop 是一个基于 Electron 的桌面应用为 Appium Server 提供图形化界面与 App 检查器。本文以仓库根目录的 CONTRIBUTING.md 为骨架结合当前仓库的实际源码与配置如 package.json、app/main.js、app/main/appium.js 与 test/e2e 下的测试用例系统讲解其架构设计、本地开发流程、测试与调试方法、打包发布机制以及面向 i18next Crowdin 的本地化工作流帮助你快速上手并合规地提交代码、文档或翻译。一、先读懂架构Electron 主进程与渲染进程Appium Desktop 本质上是一组 Electron 应用。理解 Electron 的基础架构是参与开发的第一步应用由运行 Node.js 的main主进程以及若干个renderer渲染进程组成——渲染进程本质上是显示 HTML/CSS 并运行 JS 的浏览器窗口UI 就存活在渲染进程中。主进程与渲染进程之间通过 Electron 内置的进程间通信IPC机制交互。在 UI 层面Appium Desktop 使用React配合Redux管理 UI 状态与交互使用Ant Design提供各类现成 UI 组件。当前仓库中可以直接印证这一分层主进程入口 app/main.js 负责创建BrowserWindow、加载index.html与splash.html并通过initializeIpc(mainWindow)注册 IPC 通道主进程侧的 Appium 服务逻辑集中在 app/main/appium.js它通过ipcMain.on(start-server, ...)与ipcMain.on(stop-server, ...)接收渲染进程指令并直接调用appiumServer(args, true)在主进程线程内启动 Appium Server渲染进程侧app/renderer/containers/Root.js 用ProviderConnectedRouter组织 React/Redux 树app/renderer/store/configureStore.js 汇集各模块 reducer。为什么要走这条技术路线CONTRIBUTING.md 给出了明确理由Electron 能跨平台打包Mac / Windows / LinuxAppium 本身用 JS 编写沿用同一语言可以依赖 Appium 社区维护代码并遵循其编码规范Web 技术栈普及度高用 HTML/CSS/JS 构建 UI 比原生 UI 的门槛低得多主进程运行在 Node 中可以将 Appium 作为严格依赖直接import而不是把它当子进程来管理——这对速度和错误处理都更有利开发者体验有趣、上手快。另外需要致谢项目工具链起步于electron-react-boilerplate其中很多辅助脚本至今仍以原样沿用。项目打包配置多平台 target、产物命名、github publish 提供方集中在 package.json 的build字段中后文「打包与发布」一节会继续展开。二、搭建本地开发环境参与开发前的环境准备非常简洁CONTRIBUTING.md 只要求两步克隆仓库git clone 本项目仓库地址例如git clone https://gitcode.com/gh_mirrors/ap/appium-desktop.git再进入项目目录安装依赖执行npm install。从 package.json 可以看到安装完成后postinstall脚本还会自动执行三件事git submodule update --init --recursive拉取gui-common等 git 子模块渲染进程的公共组件、测试辅助与默认配置都依赖它node ./check-engines package.json package.json校验 Node/npm 版本是否符合要求rimraf node_modules/jimp/browser清理 jimp 的多余目录避免打包体积异常。仓库在 package.json 中声明了运行环境约束Node 12.x、npm 6.x。如果你的本地环境低于该版本check-engines会给出明确提示请先升级再继续。三、日常开发工作流3.1 启动开发模式npm run dev该命令会同时启动应用本体和一个开发服务器当你修改 UI 代码时改动会以「热重载hot reload」的方式即时反馈到运行中的应用。多数情况下只改 UI 无需重启应用如果确实需要杀掉脚本重新运行即可。从 package.json 的脚本定义可以看到dev的真实链路# 先分别构建主进程与渲染进程 npm run build:dev:main npm run build:dev:renderer # 然后并行启动开发版 Electron带 --inspect、主进程 watch、渲染进程 watch concurrently --kill-others npm run start:dev npm run watch:main npm run watch:renderer其中start:dev脚本package.json会设置RUNNING_LOCALLYtrue FORCE_NO_WRONG_FOLDERtrue NODE_ENVdevelopment并以electron --inspect ./启动——这正是后文主进程调试端口 5858 的来源。补充说明仓库还提供了npm run dev-wrong-folder设置WRONG_FOLDERtrue用于特意模拟「应用被放在错误目录如非 /Applications下运行」的场景。渲染进程侧 app/renderer/containers/Root.js 中的shouldShowWrongFolderComponent()会依据WRONG_FOLDER、FORCE_NO_WRONG_FOLDER环境变量及app.isInApplicationsFolder()决定是否渲染 WrongFolder 提示组件。3.2 提交前的代码检查在提交commit之前务必对代码运行 lint 检查可以在仓库根目录或对应 app 目录下执行npm run test:lint对应脚本为eslint app testpackage.json即同时对app/源码目录与test/测试目录执行 ESLint 检查。此外仓库通过 husky 配置了 Git 钩子pre-commit钩子会自动执行npm run test:lintpackage.json从机制上保证不合规代码无法轻易提交。3.3 以生产模式验证在真正提 PR 之前建议以非开发模式跑一遍应用确认「发布形态」下一切正常npm run build # 准备资源parcel 构建主进程与渲染进程到 dist/ npm start # 启动生产版本应用npm run build实际串联build:prod:main与build:prod:rendererpackage.json使用 parcel 将 app/main.js 与app/renderer/*.html打包到dist/目录npm start则设置RUNNING_LOCALLYtrue FORCE_NO_WRONG_FOLDERtrue后用electron ./加载本地构建产物。注意生产模式下主进程会借助shell-env与fix-path恢复 Shell 环境变量与 PATH见 app/main.js以应对从打包应用启动时环境变量缺失的问题。四、运行测试单元测试与端到端测试4.1 单元测试对某个 app 运行单元测试npm test它通过run-s test:*串联所有test:*脚本package.json。同时注意pre-push钩子配置为npm testpackage.json推送前会强制执行完整测试。4.2 端到端e2e测试npm run e2e该命令的完整定义是package.jsoncross-env E2E_TIMEOUT600000 NODE_ENVtest RUNNING_IN_SPECTRONtrue \ mocha --reporter mocha-multi-reporters \ --reporter-options configFile./test/mochareporters.json ./test/e2e它基于SpectronElectron 官方测试框架驱动真实应用E2E_TIMEOUT600000为整个测试过程预留了 10 分钟超时测试报告通过 test/mochareporters.json 同时输出spec与mocha-junit-reporterJUnit 格式供 CI 解析测试夹具fixture定义在 test/e2e/pre-e2e.test.jsbefore/after钩子负责启动与关闭 Spectron 应用用例则位于 test/e2e/main-e2e.test.js。从源码看e2e 用例覆盖了两个关键场景test/e2e/main-e2e.test.js启动服务端通过页面对象点击#startServerBtn选择器定义在 test/e2e/pages/main-page-object.js等待#serverMonitorContainer出现并断言页面源码包含Welcome to AppiummacOS 打包回归测试当平台为 darwin 且设置了SPECTRON_TEST_PROD_BINARIES时对比release/mac/.../WebDriverAgent与node_modules中appium-xcuitest-driver的WebDriverAgent目录是否一致回归 appium/appium-desktop#417防止发布产物中 WebDriverAgent 缺失PrivateHeaders。如果只是修改 UI 而没动服务逻辑运行npm test与npm run e2e即可基本覆盖变更面提交 PR 前请务必保证功能测试通过。五、调试技巧5.1 调试渲染进程Renderer渲染进程运行在 Chromium 中可以像调试普通网页一样使用Chrome DevTools运行npm run dev时应用启动后会自动打开 DevTools 窗口开发模式下主进程入口会调用electron-debug见 app/main.js如果 DevTools 被关闭可在应用窗口上右键 →Inspect Element重新打开。5.2 调试主进程Main主进程是 Node.js 环境CONTRIBUTING.md 给出了两条路线方式一通过 Chrome DevTools运行npm run dev——开发模式会把--inspect端口设为5858见start:dev脚本 package.json在 Chrome 浏览器打开chrome://inspect点击Open dedicated DevTools for Node添加连接localhost:5858即可在其他标签页中逐步调试主进程代码。方式二通过 VSCode打开调试Debug面板选择dev启动配置直接在主进程源码上设置断点VSCode 会接管调试。Node.js 官方文档提供了「调试主进程VSCode」的专题说明遇到断点不生效、端口占用等问题时建议查阅对应章节Electron 文档tutorial/debugging-main-process-vscode。调试主进程时尤其值得关注 app/main/appium.js 中的 IPC 逻辑start-server处理器会在临时目录创建日志文件、注册logHandler把 Appium 日志按 250ms 间隔批量写入LOG_SEND_INTERVAL_MS并在启动成功后通过settings.set(SERVER_ARGS, args)持久化参数见 app/shared/settings.js。六、打包与发布6.1 本地打包Appium Desktop 使用Electron Builder构建应用。在本地为当前平台打包执行npx electron-builder build --publish never--publish never表示只构建、不上传产物。构建完成后产物会输出到release/目录由 package.json 中build.directories.output release指定文件打包列表见build.filesdist/、node_modules/**/*、main.js等。当前仓库在 package.json 中声明的多平台构建目标如下平台目标格式产物命名macOSdmg、zip${productName}-mac-${version}.${ext}Windowsnsis安装向导、zip${productName}-windows-${version}.${ext}LinuxAppImage${productName}-linux-${version}.${ext}其中productName为Appium Server GUI。若要在本地交叉构建多个平台例如在 Linux 上构建 macOS/Windows 产物请按 Electron Builder 官方「Multi-Platform Build」文档配置对应的构建环境如 macOS 构建需在 macOS 上进行、Windows 签名工具等本文不再展开。6.2 发布流程发布到GitHub Releases的流程是自动化的手动更新 CHANGELOG对应仓库根目录的 CHANGELOG.md——CONTRIBUTING.md 明确说明 changelog 需要手工编写提交一个 git tagCI见 ci-jobs/ci.yml 与 ci-jobs/package.yml检测到 tag 后为所有平台构建产物并上传到 GitHub Releases。发布相关元数据同样在 package.json 中publish.provider github、owner appium、vPrefixedTagName truetag 带v前缀。应用内自动更新逻辑见 app/main/auto-updater 模块发布后的新版本会被已有安装包通过electron-updater检测到。七、提交代码与协作流程7.1 Pull Request 流程Fork 本项目在分支上做出修改然后发送Pull Request动工之前请先阅读Appium 官方 Style GuideAppium 项目docs/en/contributing-to-appium/style-guide.md保持代码风格一致发送 PR 之前务必保证功能测试通过运行方式见上文第四节所有参与行为包括代码提交受 Code of Conduct行为准则约束在代码被合入之前需要签署 Contributor License Agreement贡献者许可协议CLA——当你创建 PR 时GitHub Bot 会给出具体签署指引。CI 侧ci-jobs/pr-validation.yml 会在每个 PR 上执行校验lint 测试确保合并前代码质量达标。7.2 提交 Bug 报告与功能请求使用 GitHub Issue 跟踪器提交 Bug 报告或功能请求。提交 Bug 报告时请遵循官方issue 模板填写尽可能包含复现步骤、操作系统与 Appium Desktop 版本、Appium 服务端日志应用内「Logs」标签页可直接查看界面示意见 docs/images/screen-logs.png等关键信息以便维护者快速定位。八、本地化i18n工作流Appium Desktop 使用i18next库管理翻译配合react-i18next在 React 组件中取用翻译渲染进程初始化见 app/configs/i18next.config.renderer.js主进程初始化见 app/configs/i18next.config.js两者都使用i18next-node-fs-backend从assets/locales/语言/translation.json加载资源。参与本地化需要遵守以下规则所有可翻译资源存放在assets/locales/en/translation.json英文为源语言。当前仓库assets/locales/下已有 19 个语言包de、en、es-ES、fa、fr、hi、it、ja、kn、ko、ml-IN、pa-IN、pl、pt-BR、pt-PT、ru、te、zh-CN、zh-TW受支持语言的清单可增删在app/configs/app.config.js模块中维护。在当前仓库布局下app/configs/app.config.js 将默认配置转发自gui-common子模块通过postinstall中的git submodule update --init --recursive拉取语言偏好则持久化在settings中默认值为en见 app/shared/settings.js 的PREFERRED_LANGUAGE默认项只允许编辑英文资源。其他语言由外部翻译管理服务Crowdin托管只能由自动化脚本改动人工不要直接编辑assets/locales/非 en/下的文件深入了解 i18next 的用法前建议通读官方文档中的核心章节功能总览、翻译函数 essentials、插值interpolation、格式化formatting、复数plurals以及react-i18next的Trans组件用法组件内嵌 HTML 翻译。与 Crowdin 同步的两个脚本package.json职责如下npm run crowdin-update # 将英文源翻译上传到 Crowdin npm run crowdin-sync # 将 Crowdin 上的翻译同步回仓库其执行节奏在 CONTRIBUTING.md 中有明确约定crowdin-update更新源语言每次合并到 master 分支时执行crowdin-sync同步译文每周定时执行一次。从 crowdin-update-resources.js 的源码可以看到上传脚本依赖两个环境变量CROWDIN_PROJECT_ID与CROWDIN_PROJECT_KEY缺失时会直接抛错它读取assets/locales/en/translation.json并以 multipart 表单 POST 到 Crowdin API 的update-file接口同步脚本则位于gui-common子模块内npm run crowdin-sync指向./gui-common/crowdin-sync-translations.js。因此本地手动执行这些命令前需要先向维护者获取 Crowdin 项目凭据。九、提交前自检清单综合全文向 Appium Desktop 提交代码、文档或翻译前请确认以下事项已阅读并同意 Code of Conduct后续将签署 CLA本地npm install成功含 gui-common 子模块拉取Node 12、npm 6npm run dev开发模式下功能正常UI 改动已通过热重载验证npm run test:lint无 ESLint 报错pre-commit 钩子也会强制检查npm test与npm run e2e全部通过若涉及翻译只改动assets/locales/en/translation.json其余语言交由 Crowdin 脚本同步如需本地打包验证执行npx electron-builder build --publish never产物检查无误后再推送 PR。遵循以上流程你就能以符合 Appium 社区规范的方式为这个跨平台桌面测试工具贡献代码、文档与多语言支持。赞分享桌面应用测试开发工具【免费下载链接】appium-desktopAppium Server in Desktop GUIs for Mac, Windows, and Linux项目地址https://gitcode.com/gh_mirrors/ap/appium-desktop点击查看免费下载相关推荐Electron Forge 贡献指南从本地开发联调到 monorepo 发布流程的完整实践Electron Forge 贡献指南从本地开发联调到 monorepo 发布流程的完整实践 Electron Forge 是一个社区驱动的开源项目用于构建开发工具桌面应用前端构建React Query Devtools源码架构分析理解开发工具的内部实现原理React Query Devtools源码架构分析理解开发工具的内部实现原理 React Query Devtools是React Query生态系统中一款后端前端Web框架开发工具Fontsource 贡献指南从本地开发到自动化发布的完整工作流Fontsource 贡献指南从本地开发到自动化发布的完整工作流 Fontsource 是一个 Node.js TypeScript 的 pnpm mon前端CLI开发工具上一篇终极免费内存管家Mem Reduct让你的Windows电脑告别卡顿下一篇HS2-HF补丁3步解锁《Honey Select 2》完整游戏体验的最佳方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考