Expo SDK 发布质量保障QA实战指南从 Expo Go 到 Development Builds 的全量验证清单【免费下载链接】expoAn open-source framework for making universal native apps with React. Expo runs on Android, iOS, and the web.项目地址: https://gitcode.com/GitHub_Trending/ex/expo本文是 Expo 开源仓库内 Quality Assurance.md 的深度解读与实操展开聚焦于 SDK 发版周期中的两大 QA 场景Expo Go客户端冒烟测试与 Development Builds开发构建/自定义开发客户端。读完本文你将掌握et check-packages包级检查、React Native 开发工具与热更新链路验证、test-suite/native-component-list回归策略、Expo Home 冒烟以及通过expo-test-runner与prebuild搭建两个开发构建测试应用并逐条执行开发菜单验证场景的完整方法。QA 在 Expo 发布流程中的定位在 Expo 的发布体系中QA 并不是一次性的随性测试而是 Release Workflow 的第 1 阶段Stage 1的正式环节在切断sdk-XX发布分支后、对代码做版本化versioning之前先执行本指南目的是在版本化之前发现回归——这样之后若再出现问题可以确认是版本化流程引入的而非历史遗留每次 SDK 发布都会产生版本化 QA针对新 SDK 版本与非版本化 QA针对main分支UNVERSIONED状态两种形态二者共享同一份验证清单QA 中发现的问题需要记录并与团队共享可顺手修复的应直接修复或自认领 Issue参见 Release Workflow 1.2。配合本指南阅读的另一份文档是 Release Branches它定义了发布分支的命名与维护规则QA 期间修改的修复通常需要 cherry-pick 回sdk-XX分支。Expo Go 质量保障六大检查项1. 包级健康检查et check-packagesQA 的第一步不是手动点 UI而是先在仓库层面确认“每一个包都能构建、通过类型检查与单测”。命令在仓库根目录执行et check-packages这条命令来自仓库内toolsexpotools包其在 tools/package.json 中暴露et与expotools两个可执行入口。其实际实现位于 tools/src/commands/CheckPackages.ts它会通过 Turborepo 任务图实现见 tools/src/Turbo.ts依次执行build、typecheck、depscheck、test、lint、format等任务。有几个来自源码的关键事实值得注意build与typecheck永远执行源码注释明确写着“buildregenerates the committed build output, so it always runs”且各包的build/产物是按需生成并缓存的并不提交进仓库这正是文档所说“build output is generated and cached on demand rather than committed”的由来默认按增量模式运行当不指定具体包名时筛选范围为./packages/**并基于--since指定的提交默认main分支 HEAD通过affected计算受影响的包避免每次全量检查核心包expo、expo-modules-core可通过--core无条件纳入检查避免增量筛选漏掉它们。et check-packages支持的全部选项来自 CheckPackages.ts选项说明[packageNames...]位置参数指定要检查的包名如et check-packages expo-font expo-image-s, --since commit增量检查的基准提交默认main-a, --all检查所有包并忽略--since-c, --core总是额外检查核心包expo与expo-modules-core--no-test跳过test任务--no-lint跳过lint任务--fix-lint以--fix模式运行 lint会独立于其他任务执行避免透传污染--no-format跳过format任务--fix-format以--write模式运行 format--no-dependency-check跳过depscheck任务命令还有check、cp两个别名失败时 Turborepo 会打印具体错误并退出非零状态码成功则输出All checks passed。2. React Native 开发工具链路验证版本化 QA以新 SDK 版本创建一个空项目并在开发模式下运行非版本化 QA直接在本仓库的native-component-list中测试。随后按以下子项逐条验证前两项是重点Fast Refresh快速刷新确认已开启 → 保存代码变更并确认即时生效 → 故意写一个语法错误确认错误浮层弹出 → 修复语法错误确认无需任何操作错误即消失 → 关闭 Fast Refresh 后保存变更应不生效 → 手动 Reload 后变更出现 → 再保存一次变更并重新开启 Fast Refresh变更应自动出现。原地 JS 调试Debug JS in-place按j或从 Expo Go 的开发者菜单打开 DevTools → 给应用加个按钮并打断点确认断点命中 → 点击网页上的 Reload确认整个应用被重载。其他开发工具打开 Performance Monitor 并点击若干操作观察性能数据用同样的方式验证 Element Inspector。重载Reloading保存变更后手动 Reload 确认生效修改 app config 中的启动屏颜色后手动 Reload确认立即生效开启 Production mode 后 Reload再关闭后 Reload确认两种模式下都能正常加载。Expo CLI 终端热键用终端 UI 的热键完成 reload、打开 inspector 等操作。3. 运行test-suite模块级自动化测试test-suite是 Expo 的“每个原生模块一个测试用例”式回归套件进入 apps/test-suite其app.json当前的sdkVersion为UNVERSIONED见 apps/test-suite/app.json根据 QA 形态修改sdkVersion非版本化 QA 用UNVERSIONED版本化 QA 改成新的 SDK 版本号运行npx expo start在真机/模拟器的 Expo Go或开发客户端中逐个模块跑测试。模块覆盖可以从 apps/test-suite/tests 目录看出其广度既有Basic.js、Application.js这类基础入口也有Asset.ts、Audio.ts、Image.tsx、Calendar.js、Contacts.js、FileSystem.ts、Haptics.js、Fetch.ts等原生模块测试。QA 关注点每个模块的测试列表能正常进入、用例能通过、失败信息可读而不是把时间花在逐个新功能的人工探索上。4. 逐屏检查native-component-list示例native-component-listNCL是 Expo 自带的“API 陈列馆”几乎每个 Expo 模块与 React Native 核心组件都有可交互示例进入 apps/native-component-list其 app.json 当前同样为sdkVersion: UNVERSIONED并且设置了scheme: ncl、platforms: [android, ios, web]与 EAS projectId同样按 QA 形态更新sdkVersion运行npx expo start逐屏检查所有示例包括 React Native 核心组件——因为很多模块在单元测试覆盖不到的地方最容易在这里露馅。NCL 的示例源码体量很大apps/native-component-list/src 下有数百个*.tsx屏幕因此建议优先关注本次 release 中被改动/重构的模块。注意sdkVersion字段很关键在 Release Workflow 1.4 中正式发版前还要把 NCL 的sdkVersion改成正式 SDK 号并expo publish到community与applereview账号供苹果评审与外部试用。5. 冒烟测试 Expo HomeExpo Home 是 Expo Go 客户端内嵌的主界面工程相关代码集中在 apps/expo-go发布态记录在仓库根的 dev-home-config.json发布命令et publish-dev-home/et publish-prod-home见 Release Workflow 2.1。QA 建议对本地版本local version的 Home 运行分别以登录/未登录状态点击 Home 上的每一项在几个应用之间切换包括本地应用与已发布应用打开随机链接、做各种“非常规操作”确认错误提示信息语义清晰文档原话Be creative检查登录后的“设置settings”页。6. 在独立 release 构建中测试开发模式Dev Client/Expo Go跑得通不代表 release 构建没问题——生产构建会开启 minification、关闭 dev 相关能力。本步骤要求将 native-component-list 以 release 模式编译然后逐个访问每个屏幕做冒烟测试。这能提前暴露生产构建下的 JS 崩溃、原生链接缺失如expo prebuild后 Pods/Gradle 依赖不全、代码拆分或 Hermes 字节码等问题。release 构建可以理解为通过npx expo run:ios --configuration Release之类的配置在本地或 EAS Build 上产出后安装验证。Development builds 质量保障“开发构建”development builds即内嵌expo-dev-client的构建是 Expo 面向真实原生工程的主流开发形态因此 QA 清单更长、更细。两条总体原则准备两个应用见下方“测试应用”并跑通全部测试场景且优先使用真机而非模拟器真机才能测三指长按、摇一摇、相机扫码等能力如果是新 SDK 发版要针对最新版本的项目模板测试文档强调npx create-expo-app默认拉到的模板不一定是你要测的确切版本。测试应用一不含 expo-updates 的核心功能应用第 1 个应用刻意不带expo-updates用于检验开发客户端本身的核心功能是否正常。创建方式yarn expo-test-runner create-project -a dev-client-e2e --path path where the project will be createdexpo-test-runner是仓库内的一个包见 packages/expo-test-runner/package.json二进制名为expo-test-runner。其create-project子命令实现在 CreateProject.ts它从测试运行器的配置中按-a, --app查找应用预设当前为detox预设的模板工程然后在--path指定的目录生成测试应用。生成后进入项目目录运行npx uri-scheme add dev-client-release注册测试用的 URL schemeuri-scheme在仓库内同样以包形式存在见 packages/uri-scheme在测试工程主目录运行npx expo start启动 bundler。测试应用二基于 create-expo-app prebuild 的应用第 2 个应用走“标准模板 手动链接开发客户端包 prebuild”路线用npx create-expo-app以最新 SDK 创建全新工程手动链接expo-dev-client相关依赖打开package.json在dependencies中把以下开发客户端相关包及需要时使用的关联包指向仓库内的本地路径确保测试的是最新源码而非 npm 上可能过期的版本expo-dev-clientpackages/expo-dev-clientexpo-dev-launcherpackages/expo-dev-launcherexpo-dev-menupackages/expo-dev-menuexpo-dev-menu-interfacepackages/expo-dev-menu-interfaceexpo-updatespackages/expo-updates仅当最新版本与expo-dev-client的package.json内置版本不同时才需要expo-updates-interfacepackages/expo-updates-interface按需expo-structured-headerspackages/expo-structured-headers按需expo-manifestspackages/expo-manifests按需运行npx expo prebuild生成原生工程。文档特别提醒iOS 上可能会遇到源文件重复duplicated sources的问题解决方式是同时在 Podfile 中手动链接这些包——这正是为什么第 2 步要求“手动”而非完全信任自动链接的原因。测试场景清单逐条执行1. 应用可编译分别通过 Xcode、Android Studio 编译再用npx expo run:ios与npx expo run:android从 CLI 构建构建完成后应自动启动进入应用。2. UI 工作正常首次启动应看到dev-menu的欢迎屏未登录时应能在dev-launcher里检测到本地 bundler应能登录登录后记得同时通过终端登录应能看到 development session 检测到的 bundler应能唤出开发菜单——通过摇一摇手势、或三指长按模拟器测不了此项Android 上扫描 QR 码应打开 Expo Go 的相机屏应能从我们自己的菜单呼出原生 react-native 菜单应能修改 dev menu 的选项摇一摇、三指长按、launch 时显示菜单——后者需要先加载某个应用来验证。3. 能加载应用分别加载npx expo start启动的应用、npx react-native start启动的应用、以及已发布应用运行eas update后把 manifest URL 粘进 dev-launcher UI。4. 最近加载过的项目应出现在 launcher 主屏。5. 应用加载后 dev menu 功能可用reload、performance monitor、element inspector、fast refresh、back to launcher、remote debugging 逐项验证。6. WebSocket 控制仅使用npx expo start时reload、打开 dev menu、performance monitor、element inspector 应通过命令行/快捷键生效。7. 深链接deep link保留在 dev-launcher 主屏可见期间收到的最后一个 deep link 应被暂存并在下一次打开的应用中传递过去同时 UI 上应有指示器。8. 语法错误处理加载含语法错误的应用时应看到错误屏且能返回 launcher、也能 reload 应用——这正是第 2 节 Expo Go Fast Refresh 错误处理逻辑在开发客户端侧的对应验证。执行建议与 QA 记录从 Release Workflow 第 1 阶段的描述可以确认这条 QA 的工作纪律逐项执行而不是抽样QA 是发布流程中最重要的环节文档要求“please dont ignore any steps”尤其要聚焦本周期被改动/重构过的能力记录并共享发现将每条问题记录并与团队同步快速修复可当场完成或自认领区分 QA 形态同一份清单同时服务于版本化与非版本化 QA二者的差异只在运行载体空工程/版本号 vsnative-component-list/UNVERSIONED善用自动化与人工的结合包级健康et check-packages与模块级test-suite由工具覆盖开发工具链路、UI、加载、深链接与错误处理则由本清单的人工步骤兜底。总而言之这份 Quality Assurance.md 提供了一条从“包构建正确”到“用户实际点按体验正确”的完整验收链路。把上述清单固化到你的 SDK 发版流程中就能在版本化与 beta 阶段之前以可复现的方式把大多数回归拦截在发布之外。【免费下载链接】expoAn open-source framework for making universal native apps with React. Expo runs on Android, iOS, and the web.项目地址: https://gitcode.com/GitHub_Trending/ex/expo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
