很多团队的内测节奏乱，根源不在测试本身，而在提测这一步没规矩：包随手一扔、说明全靠口头，测试拿到包第一件事是回来问开发。把提测流程理顺，后面的分发、反馈、回归都会顺很多。这篇文章给一份可以直接照抄的衔接清单。
提测前要准备什么
提测不是「把包发给测试」一句话的事，交付物至少包括：
- 安装包：APK 或 IPA，文件名带版本号，如
app-release-1.4.2.apk，避免和旧包混淆； - 提测单：写明本次改动范围、已知问题与重点验证项；
- 配套信息：测试账号、测试环境地址，以及涉及的证书与描述文件状态说明；
- 回归范围：哪些功能点必须重测，哪些历史问题已知、无需再报。
其中提测单和回归范围最容易被省掉，也最容易被测试追问。省掉它们省下的五分钟，往往要用后面两天的反复沟通来偿还。
提测单怎么写：让测试少问三遍
不需要复杂模板，一张表说清四件事：
| 字段 | 写什么 | 反例 |
|---|---|---|
| 版本信息 | 1.4.2（build 1420） |
只写「最新版」 |
| 改动范围 | 新增订单导出、修复定位偏移 | 「改了一些 bug」 |
| 重点验证 | 导出功能在弱网下的表现 | 所有功能都标重点 |
| 已知问题 | 列表页刷新偶发偏慢 | 隐瞒不写 |
写得越具体，测试的提问越少，来回拉扯的时间就越短。
冒烟验证：提交前的最后一关
提测包如果在测试手里连启动都失败，流程等于白跑。开发提交前先做 5 分钟冒烟：
- 在一台干净设备上全新安装一次，确认能装、能启动；
- 从旧版本覆盖升级一次，确认本地数据不丢；
- 点一遍主流程：登录、核心业务、退出；
- 核对包名、版本号与环境指向没有拿错。
冒烟不过的包不要提测，这是最低门槛。
提测时机怎么约定
比模板更容易被忽略的是「什么时候提」。没有约定的小团队，经常出现开发一天提三次、测试被迫中断回归的情况。两个可落地的约定：
- 固定节奏：每周固定两轮提测时间点，错过自动排入下一轮；
- 完整度门槛：核心路径跑通、不缺配置项，才允许发起提测。
约定一旦定下就写进团队文档，新成员入职第一天就能看到，比口头传承可靠。
提测通过后，包怎么发到测试团队手上
冒烟通过、提测单就位，就进入分发环节。把安装包上传到虾分发（https://xiafenfa.com），系统解析后自动生成分发二维码和链接，可配合下载密码与下载次数限制控制发放范围；测试用户扫码即装，不需要逐个传文件。后续每个新版本重复上传即可，多版本并行时还能在后台随时启停旧版本，避免测试装错包。
常见问题
| 问题 | 处理方式 |
|---|---|
| 测试反馈的问题开发复现不了 | 先核对双方的版本号与环境指向是否一致 |
| 提测后又临时加需求 | 新需求排入下一轮，本轮只验证提测单范围内的内容 |
| 测试说装不上 | 按提测单核对安装包与证书状态，再排查机型适配 |
建议 提测流程的价值在于稳定而非复杂：先用一页提测单跑两周，再根据扯皮最多的问题补充条目。流程顺了，再配合虾分发这类内测分发平台的二维码分发能力，从代码提交到测试装上包，整体时间可以明显缩短。