什么是 Beta 测试？类型、流程和结束标准

什么是 Beta 测试？

Beta 测试是正式发布之前，把基本完成的产品或功能交给开发团队以外的一小批真实用户使用。测试者在自己的设备上、用自己的数据和习惯来用，团队借此发现内部测试没发现的缺陷、让人困惑的流程和缺失的部分。

这个叫法来自上世纪 50 年代 IBM 给测试阶段的命名：A 是产品的内部测试，B 是外部用户参与的测试。如今「Beta」用得很宽泛：既可以指 50 个客户参加的两周封闭测试，也可以是一个挂了好几年的「公测版」标签。国内常说的「内测」「公测」，大致对应封闭 Beta 和公开 Beta。

Alpha、Beta、金丝雀和正式发布

Beta 测试的几种类型

• 封闭测试：挑选的一批人，通常是老客户或排队名单里的人，有时要签保密协议。好沟通，人少到可以逐个跟进。
• 公开测试：谁都能加入。适合测负载、覆盖更多机型，也有宣传作用，但反馈更杂。
• 专项测试：只测一个功能或一个风险点，比如新接入的支付渠道、重写过的同步引擎。
• 营销型测试：主要为了早期用户和口碑，产品决策其实已经定了。

怎样组织一次 Beta 测试

1. 先写目标和结束标准：满足什么条件才能发布？在看到任何数据之前就定下来。
2. 找对测试用户：和目标用户一致，平台、规模、地区都要对得上。全是重度用户的 Beta 会掩盖新手引导的问题。
3. 给版本埋好点：确保 Beta 版本能上报版本号、崩溃和新功能的关键事件，这样才能把测试用户和其他人分开看。
4. 跑两到六周：修复以新的 Beta 版本发出，并告诉测试者改了什么。
5. 两条渠道收反馈：结构化的（崩溃率、任务完成率、激活率）和非结构化的（应用内反馈、客服聊天、简短访谈）。
6. 做决定：发布、延长测试，或者砍掉这个功能。把理由写下来。

结束标准示例

示例数据：某 App 用 3.8.0-beta 版本对新的离线模式做四周封闭测试，400 名测试用户；对照组是当前线上版本 3.7.2。

这张表的意义在于决策规则：有两项没通过，所以测试再延长一个版本，而不是按原计划发布，哪怕新功能的使用情况看起来不错。

应用商店的测试轨道

• 苹果 TestFlight：可以通过邮件或公开链接邀请最多 10,000 名外部测试者；外部测试版本要经过 Beta 审核，每个版本可用 90 天。
• Google Play 管理中心：提供内部测试（最多 100 人，几分钟内可用）、封闭测试（名单或 Google 群组）和公开测试（任何人都能从商店页面加入）。
• 国内安卓渠道多用各应用市场的内测功能或自建下载页分发，原理相同：限定人群、限定版本。

在 TapCub 里衡量 Beta 测试

• 按版本区分测试用户：应用统计 › 用户分析 › 版本分布 列出每个版本的活跃用户占比、崩溃数和首次出现日期；点 Beta 版本那一行，整页就按这个版本筛选。参见跟踪 App 版本。
• 对比稳定性：应用统计 › 质量与归因 › 稳定性 显示无崩溃用户占比（1 − 崩溃用户 ÷ 活跃用户）、ANR、卡顿和启动耗时；按版本筛选，就能把 Beta 和线上版本放在一起比。参见无崩溃率。
• 排除内部设备：App 的排除规则可以按设备或 App 版本匹配（版本支持末尾通配），自己 QA 用的手机不会混进 Beta 数据。
• 衡量新功能的激活：用事件分析看新功能的事件，并筛选 Beta 版本。

资料来源

• Apple Developer，TestFlight。
• Google Play 管理中心帮助，设置开放式测试、封闭式测试或内部测试。