如何为你的应用进行测试版（Beta）测试

要进行测试版测试，首先要确定你需要了解什么，邀请一小群与你真实用户相符的人，给他们一个清晰的首要任务，并在固定的时间表上将反馈收集到一个地方。修复阻碍他们的问题，分轮次扩大测试范围，并在你预先写下的退出标准达成时结束测试版——而不是在你失去耐心时结束。

测试版并不是软启动。它是一个有开始、有结束、并且要回答一个问题的结构化实验。

测试版适合在哪个阶段

验证要回答的是这个问题是否值得解决。测试版要回答的则更具体：这个版本的产品，在真实条件下，能否为真实的人解决这个问题？上线则在这之后进行，通常是在答案基本为“是”之后。

在邀请任何人之前，先自己进行测试——如何在上线前测试你的应用涵盖了这一点。测试人员不应该是那个发现注册功能坏了的人。

第1步：写下测试版必须回答的问题

选择两到三个问题。计划中的其他内容都由它们决定。

虚构示例： 一款为小型咖啡馆设计的排班应用，设定了两个目标：“经理能否在第一次使用时，无需帮助就发布一周的排班表？”以及“员工在第二周是否会自己打开应用？”

第2步：选择测试版的类型

对于第一款产品，通常以几轮进行的封闭测试版最为合适。

第3步：招募合适的测试人员

最好的测试人员现在就有这个问题，符合你的目标用户，并且在测试期间有时间试用应用。可以在以下地方寻找他们：

• 你的候补名单或邮件列表——参阅如何在上线前建立受众。
• 你在验证阶段访谈过的人。
• 用户聚集的小众社区，并遵守其关于推广的规则。
• 直接邀请你人脉中符合画像的人。

问几个筛选问题，以便挑选出合适的组合：他们的角色、目前如何解决这个问题、会用什么设备，以及这个问题出现的频率。邀请那些回答与你的目标用户相符的人，并避免让测试版充斥着其他创始人，除非他们恰好就是目标用户。

邀请模板

你好，[姓名]——你注册时提到了[问题]。我正在为[产品]开启一个小型私人测试版，它能[结果]。测试时间从[开始]到[结束]。我希望测试人员每周至少用它完成一次[真实任务]，并在每周五填写一份简短的检查。作为回报：测试期间免费使用，并享有[创始人优惠价/延长的免费期]。有兴趣吗？

请诚实地说明所需的时间投入。清楚知道自己报名了什么的人，会给出更好的反馈。

第4步：准备测试版工具包

在发出第一份邀请之前，请准备好以下内容：

• 欢迎信息，包括链接、登录方式、第一个要尝试的任务，以及如何报告问题。
• 已知问题列表，避免测试人员把同一个问题报告十次。
• 一个反馈渠道。 一个表单、一个共享聊天群或一个电子邮件地址——只用一个地方，而不是五个。
• 错误报告模板。 请他们说明做了什么、预期是什么、实际发生了什么、设备和浏览器，以及截图。如何撰写好的错误报告提供了一个可以分享的版本。
• 基础分析或日志，这样你无需依靠记忆也能看到发生了什么。
• 关于数据的明确说明。 如果测试期间数据可能被重置，请告诉测试人员；不要让他们在未完成的应用中录入敏感信息。
• 条款和隐私基础内容。 一份简短的测试协议和隐私说明；如果你处理个人数据，请查阅当地规定或咨询专业人士。

第5步：分轮进行

分轮进行可以让你在更多人遇到问题之前先修复它们。

在第1轮中，请两三位测试人员在首次使用应用时共享他们的屏幕。保持安静，观察他们在哪里犹豫。这往往是整个测试版中最有价值的一个小时。

第6步：按固定节奏收集反馈

随意的“有什么反馈吗？”得到的回答通常很模糊。请改用简短、定期的检查：

每周检查（示例问题，均为虚构）

1. 本周你用[产品]做了什么？
2. 哪里令人沮丧或让人困惑？
3. 是否缺少了某个导致你无法完成任务的功能？
4. 如果你再也不能使用它，你会有什么感受？（非常失望／有些失望／完全不失望）
5. 其他任何内容？

将人们说的与他们做的结合起来看。一个说“很棒”却从不登录的人，同样在告诉你一些信息。

第7步：对收到的反馈进行分类

把每一条反馈都放进同一个列表，并每周进行一次整理。

在测试版期间，要克制住添加大功能的冲动。每增加一个新功能，都会让人更难判断核心产品是否正常工作。

第8步：形成闭环

当测试人员看到自己的反馈被采纳时，他们会持续提供反馈。

• 每轮结束后发送一份简短的更新日志：“你报告的X已修复。”
• 当某人的报告促成了修复时，私下点名感谢他们。
• 告诉测试人员测试版何时结束、他们的数据和账户会怎样处理，以及他们的优惠是什么。

第9步：判断是否准备就绪

在测试版开始前写下你的退出标准，并在结束时诚实地逐条核对。模板如下：

• 没有已知的阻断性问题或数据丢失错误
• 大多数新测试人员能在没有帮助的情况下完成核心任务
• 相当一部分测试人员在之后的几周内会自行回来使用
• 主要的困惑点已修复并经过重新测试
• 注册、密码重置以及任何付款流程都能端到端地正常工作
• 你对产品面向谁，有一个用测试人员自己的话表述的清晰信息

如果大多数方框都已勾选，就进入引导的打磨阶段，并准备公开上线。如果回访使用率很低，那是产品问题，而不仅仅是错误清单——在上线之前，请回到访谈环节。

使用Mythex进行测试版

如果你正在使用Mythex构建，有几项功能与测试版非常契合：

• 第1轮的预览链接。 分享按钮会创建一个指向实时预览的链接，无需Mythex账户即可访问，因此早期测试人员可以在你发布之前试用尚未完成的作品。为每组人员创建一个链接，并在结束时删除——预览文档解释了链接如何唤醒项目并消耗积分。
• 较长的轮次请发布应用。 已发布的应用拥有自己的地址，适合测试人员在数周内持续使用。
• 每轮之前进行App测试。 在聊天中输入/test，智能体会在你的预览中操作并报告有问题的流程，这是在邀请任何人之前很有用的检查（App测试文档）。
• 检查点。 如果在测试版期间某次修复导致其他功能出错，可以回滚到较早的检查点。

将测试人员的错误报告直接粘贴到聊天中，让智能体复现并修复它，然后告诉测试人员修复已上线。

常见问题