内测分发

内测分发这件事，内测分说白了就是内测分把还没正式上线的App塞到别人手机里。听起来简单，内测分做起来全是内测分坑。

上个月帮一个朋友处理他团队的内测分内测包。二十几个测试人员，内测分分布在三个城市，内测分用的内测分手机从iPhone 12到红米K60都有。他一开始的内测分做法很原始——把apk文件扔进微信群，让大家自己下载安装。内测分结果当天晚上就炸了锅：iOS用户打不开，内测分安卓用户里有一半被系统拦截，内测分提示“未知来源应用存在风险”。内测分更离谱的内测分是，有个测试人员装了旧版本，内测分覆盖安装失败，直接把聊天记录给清空了。

这就是内测分发最真实的起点。你以为只是传个文件，实际上要解决的是设备兼容、系统权限、版本管理、安装引导这一连串问题。

那些分发方式，各有各的脾气

最早大家用TestFlight，苹果官方渠道，听起来最靠谱。但用过的人都知道，它有个让人抓狂的审核机制。一个内部测试包，有时候要等一两天才通过审核。版本更新频繁的时候，测试人员刚装好上一个版本，新版本又卡在审核队列里。而且TestFlight的邀请链接经常被邮件系统当成垃圾邮件拦截，测试人员收不到邀请码是家常便饭。

后来国内出现了很多第三方分发平台，蒲公英、fir.im、还有一堆我叫不上名字的。它们的逻辑是把安装包上传到云端，生成一个短链接或二维码，测试人员扫码就能装。方便是真方便，但问题也很明显：这些平台的证书签名经常掉。什么叫掉签名？就是测试人员昨天还能正常打开App，今天一点图标就闪退，提示“无法验证应用开发者”。原因通常是苹果封杀了平台使用的企业证书。你这边测试正跑到关键流程，那边所有人突然都打不开应用了，那种感觉就像开车上高速发现油箱漏了。

还有一种做法是自建分发页面。把ipa和apk文件放在自己的服务器上，写个简单的下载页，根据User-Agent判断设备类型，分别给出对应的安装方式。iOS需要走itms-services协议，安卓直接给下载链接。这套方案可控性最强，但维护成本不低。光是处理iOS的plist文件配置和证书管理，就够折腾一阵子。

真正麻烦的是版本追踪

分发出去只是第一步。测试人员装的是哪个版本，这个信息如果收集不到，后面收到的反馈就没法定位。我见过一个团队用在线表格让测试人员手动填写版本号，结果填上来的格式五花八门——“最新版”“昨天那个”“v2.3.1(20240115)”“不知道”。这种数据拿回来等于没有。

比较务实的做法是在App内部做一个版本检测和上报机制。启动时自动把版本号、设备型号、系统版本回传到服务端。测试人员不需要做任何额外操作，你就能知道谁在用哪个版本。如果发现某个测试人员还在用三天前的包，直接给他推送一条更新提醒就行。

另外说一个容易被忽略的细节：安卓的覆盖安装。如果新旧版本的签名不一致，覆盖安装会直接失败，而且不会自动卸载旧版本。测试人员看到的现象是“安装失败”，但不知道原因。解决办法是确保每次打包用的keystore文件一致，或者在分发页面上明确提示“请先卸载旧版本再安装”。

安全边界在哪里

内测包毕竟不是正式版，里面可能带着测试服务器的地址、调试开关、甚至一些没做完的功能入口。这些东西泄露出去，轻则被人截图发到社交平台，重则被逆向工程扒出接口。所以分发链接最好加上访问密码或者有效期限制。蒲公英这类平台支持设置下载密码，自建页面的话可以用Nginx做个简单的Basic Auth。别嫌麻烦，总比出事之后补救强。

还有一点，测试人员的设备UDID要提前收集好。iOS的Ad Hoc分发需要把设备UDID加到描述文件里，否则装不上。很多团队等到分发那一刻才开始收UDID，挨个问测试人员怎么查UDID——这事儿在iPhone上操作路径还挺深，不少人找不到。提前一天发个图文教程，能省掉大量沟通成本。

内测分发没有什么一劳永逸的方案。团队规模、测试频率、设备类型、预算，这些变量组合起来，适合的工具和流程都不一样。但核心原则就一条：让测试人员用最少的操作装上正确的版本，然后把版本信息准确地传回来。围绕这个原则去选工具、搭流程，基本不会跑偏。