如何打包可执行React Native应用供无开发环境人员安装测试

分平台打包选型 #

Android 端 #

• 直接生成APK格式安装包，不要打AAB格式（AAB是应用商店上传专用格式，普通用户无法直接安装）。
  • 日常功能测试需要看报错日志、保留调试菜单的话，直接打debug包：在项目根目录执行cd android && ./gradlew assembleDebug，生成的安装包路径为android/app/build/outputs/apk/debug/app-debug.apk
  • 需要验证正式版性能、交互表现的话，打release签名包：提前在android/gradle.properties配置好签名密钥信息，执行cd android && ./gradlew assembleRelease，生成的APK在同目录的release文件夹下。
• APK没有分发限制，直接通过聊天软件、网盘发送即可，Android 8.0以上版本安装时仅需要手动给安装渠道开启「允许安装未知来源应用」权限，提前告知测试人员即可，不需要额外操作。

iOS 端 #

受iOS系统签名机制限制，无法直接发裸安装包，根据测试人员范围选对应方案即可：

• 测试人员数量少、能提前收集到手机UUID的场景，打Ad-Hoc类型的IPA包：把测试设备的UUID加到苹果开发者账号的设备列表，用Ad-Hoc描述文件打包签名，生成的IPA通过常规签名安装工具辅助即可直接安装。
• 不想收集UUID、测试人员不固定的场景，直接走TestFlight内部测试通道：打包后上传到App Store Connect，把测试人员的Apple ID加到内部测试组，对方收到邮件邀请后，安装TestFlight App就能直接下载安装，最多支持100个内部测试名额，全程不需要碰开发相关配置，是iOS端最省心的测试分发方式。
• 注意不要打App Store正式提交类型的包，这类包没有测试签名，无法直接安装使用。

多分支场景提效方案 #

项目存在多个开发分支时，手动本地打包效率太低，可以搭一套自动化打包流程省时间：

• 用现有代码仓库配套的CI能力（比如GitLab CI、GitHub Actions）或者自建Jenkins服务，配置触发规则：只要开发提交代码后打特定前缀的tag（比如test/功能名），就自动拉取对应分支代码，执行双端打包逻辑，打完自动生成下载链接、iOS包自动同步到TestFlight，开发只需要把下载链接发给测试人员即可，不用每次在本地等十几分钟打包。
• 安装包命名统一带上分支名、版本号、打包时间，比如xx应用_feat支付分支_v2.1.0_20240520.apk，避免测试人员装错版本。

面向非技术测试人员的配套说明 #

• 不需要测试人员安装npm、git、IDE这类开发工具，拿到安装包/链接直接操作即可：Android点APK按提示开权限安装，iOS点TestFlight邀请链接直接跳转安装。
• 测试不同分支版本时，Android直接覆盖安装就行，iOS在TestFlight里切换对应版本即可，不需要卸载旧包。
• 遇到安装失败问题，优先核对系统版本是否符合要求、安装包签名是否匹配、iOS设备是否在测试名单内，不需要让测试人员接触代码、开发环境相关内容。

内容的提问来源于stack exchange，提问作者ACArtur