什么是 Beta 测试？
自从 Web 2.0 兴起以来，beta 测试的实践越来越受欢迎。然而，关于 β 测试真正是什么以及它可以提供什么好处的困惑已经几乎以同样的速度增长。
自从 Web 2.0 兴起以来，beta 测试的实践越来越受欢迎。然而，关于 β 测试真正是什么以及它可以提供什么好处的困惑已经几乎以同样的速度增长。1. 什么是 Beta 测试？
Beta 测试应该是什么样子或者应该如何设置它没有标准。但是，从本质上讲，beta 测试是为当前或潜在用户的样本提供已完成或接近完成的产品，以评估其在现实世界中的表现。要被归类为 beta 测试，测试应至少满足以下标准：
该应用必须“功能齐全”，并且相当稳定。
Beta测试人员应该属于应用程序的目标客户。
Beta测试人员应将该应用程序用于实际场景。
2. Alpha 与 Beta 测试
当您尚未准备就绪时，开始您的 Beta 测试阶段将对测试结果产生巨大影响。因此，在我们开始讨论 beta 测试的不同类型和方法之前，我们必须首先将其与 alpha 测试区分开来。
Alpha 测试是测试阶段，在测试阶段之前。alpha 版本通常缺少许多功能，并且几乎总是太麻烦和不稳定，无法可靠地使用。传统上，内部开发人员和/或测试人员使用混合的黑盒和白盒测试技术来发现错误和崩溃。但是，对于包含高度信任的技术用户的外部测试人员而言，alpha 测试并非闻所未闻。
另一方面，测试版应该是功能完整的，包括为发布版本计划的所有功能。测试由外部测试人员和最终用户独家使用黑盒测试进行，这基本上意味着他们将使用您的应用程序用于其预期目的，或者换言之，真实场景。因此，虽然发现错误是测试的主要目的之一，但您的测试版不能太过错或不稳定而无法使用或过多地影响用户体验。
3. Beta 测试的类型
您可以通过多种方式设置Beta测试，并仍然满足前三个要求。这通常取决于每个应用程序的具体要求，以及您希望通过Beta测试实现的目标。
值得注意的是，beta程序可以包含几种不同类型的beta测试。这些可以分阶段进行，每个阶段都涉及应用程序的不同方面。Beta测试通常根据其访问限制或beta测试的目的进行分类，但这些测试是相互排斥的。
3.1 封闭式与开放式 Beta 测试
封闭式 Beta 测试是指您只授予有限数量的测试人员访问您的测试版应用。这可以通过以先到先得的方式设置注册限制，或者手工挑选具有某些技能或专业知识的测试人员，例如技术精湛。
封闭式 Beta 测试更适合于有限范围的 beta 测试，通常是技术性的。由于每个测试仪发现的独特问题的数量随着测试仪数量的增加而减少，因此至少在最初限制测试仪的数量是有意义的。但是，如果施加此限制，则必须亲自挑选您将要包含的测试人员或将其放入申请流程中。
此类测试也适用于不希望限制测试范围但仍然太小而无法处理大量测试人员的团队。限制 beta 测试人员的数量将帮助您避免使用大量的传入反馈来压倒您的小团队。如果您的目标是不容易大规模分析的定性反馈，则尤其如此。
另一方面，公开测试不限制访问并允许任何人注册。这是观看用户如何与您的应用互动并收集有关其使用模式的定量数据的绝佳方式。它还可以测试您的应用程序的扩展程度以及基础架构和后端如何处理该规模。
公开测试通常遵循封闭的测试阶段，很少单独依赖。它们的规模可以让您更深入地了解应用程序在现实生活中的使用方式，并发现应用程序中一些不太常见的错误和崩溃。但是，开放式 beta 测试可能非常复杂，无法有效处理，尤其是对于较小的开发团队。经过深思熟虑的流程来处理测试人员及其反馈对于成功进行公开测试至关重要。
3.2 技术与产品与营销 Beta 测试
对 beta 测试进行分类的另一种方法是它们的范围。有限的范围允许您专注于应用程序的特定需求或在连续阶段进行测试。
以技术为重点的 beta 测试通常需要少量精通技术的用户或测试人员。这些技术测试人员更善于发现错误并提交高质量的错误报告，同时对错误有更高的容忍度。
查找错误和崩溃是 beta 测试的最着名的好处，并且在向范围添加任何内容之前通常首先进行技术 beta 测试。
在技术方面得到处理之后，是时候进行产品 beta 测试了。这重点关注应用程序的功能及其为用户提供的价值。产品 beta 测试主要用于验证您对用户需求的假设以及您的应用可以提供的帮助。
在这里，您可以尝试了解真实用户如何与您的应用进行互动，以及他们的使用是否符合您的假设。您可以使用它来评估哪些功能对用户更重要，以及他们希望向应用添加哪些功能。
最后，营销 beta 测试是您评估和改进营销方法并围绕您的应用创建宣传的机会。营销 beta 测试通常是公开测试，但与普遍看法相反，情况并非总是如此。实际上，一些开发人员限制访问以引起稀缺感。
营销测试可用于在发布前评估您的营销信息和渠道。这有助于您在发布应用时识别最有效的消息和效果最佳的频道。此外，您可以使用它们征求评论和推荐，并吸引早期采用者加入您的应用。
4. 敏捷开发中的 Beta 测试
在传统的瀑布式软件开发中，beta 测试是在发布之前举行的一次性交易。但是，在具有迭代版本的敏捷框架中，这已不再适合。同时，测试应用的每个次要版本并不总是可行的。这对于 beta 测试适合敏捷开发的地方产生了某种混淆。
当然，在敏捷环境中进行 beta 测试的正确时间取决于您正在开发的应用程序类型和您的发布节奏。例如，B2B 用户需要一定程度的稳定性，特别是涉及影响其业务目标的功能时。
在敏捷环境中，您可以为引入新功能的主要版本保留 beta 测试，使用“永久 beta 测试”方法或两者兼而有之。
4.1 测试主要版本
当您的团队没有能力处理持续的 Beta 测试时，可能需要为主要版本保留 beta 测试。对于 B2B 应用程序或那些可能会频繁更改可能会破坏用户工作流程的应用程序，它也是首选。但是，请记住，这需要更长的 beta 测试周期才能获得足够有用的反馈，因为还有更多需要测试。
4.2 永久 Beta
永久 beta 测试是正在进行的测试，其中每个版本在发布之前都经过 beta 测试。当然，这是理想的场景，可以最大限度地缩短 beta 测试周期的持续时间，但确实有其缺点。首先，只引入小错误修复和改进的版本将从回归测试之外的测试中获得很少的价值。此外，要测试的高频率的 beta 版本会导致“测试仪疲劳”并增加测试仪的烧坏率。
4.3 混合方法
混合方法试图通过与一小组技术用户进行永久测试，并针对功能发布进行更大，更具包容性的 beta 测试，从而实现两全其美。这使您可以在引入的每个构建中持续测试错误和崩溃，并为引入重大更改的构建收集更广泛的反馈。这将最大限度地减少测试仪烧坏，同时缩短测试周期的持续时间。
5. Beta 测试的示例
5.1 Lyft
作为大规模 beta 测试的最佳示例之一，Lyft 拥有一个成熟的 beta 程序，拥有数千名 beta 测试人员。他们开始对内部测试人员进行 alpha 测试一周，然后再将其推广到测试版并将其分发给测试人员。
当 beta 版本准备就绪时，会将其发送给一组技术人群以及测试版用户。Crowdtesters 处理测试的技术部分，并尝试通过简单，可重复的步骤，而beta测试人员帮助发现定期使用应用程序时出现的问题。
此测试阶段持续一周，然后在分阶段部署中将构建推送到生产阶段。在另一周的时间内，该应用程序相继发布给逐渐扩大的用户群，然后是 100％ 的用户。
5.2 Envoy
Envoy 是一款 B2B 办公管理应用程序，可简化和数字化办公室管理。他们的团队采用简单的beta测试流程，适用于B2B产品。
Envoy 通过 dogfooding 步骤开始测试过程，所有员工都会收到应用程序的测试版测试版。
他们还将相同的构建发送给参与 beta 测试的一小组可信用户。然而，特使的 beta 测试不是时间盒，取决于没有错误作为 beta 测试的退出标准。
即使在将应用程序发布到生产环境之后，Envoy 仍会继续进行测试，以确保快速解决问题。作为 B2B 应用程序，与用户保持密切关系并提供额外响应非常重要。
6. 入门
7. Instabug 如何帮助我们 ？
Instabug 是用于移动应用程序中的错误报告和用户反馈的顶级beta测试工具。它提供市场上最有用的元数据，卓越的客户支持以及与您的Beta测试人员聊天的应用内通信渠道。
Instabug 是用于移动应用程序中的错误报告和用户反馈的顶级7.1 错误和崩溃报告
通过每个报告，您可以自动接收全面的数据，以帮助更快地解决问题，包括重现错误的步骤，网络请求和控制台日志以及环境详细信息。对于错误报告，您的 Beta 测试人员还可以发送屏幕录像和注释屏幕截图以提供更多背景信息。
7.2 应用内调查和功能请求管理
从您的应用内部收集 Beta 测试人员的用户反馈，以最大限度地减少中断并提高参与率。通过可针对特定测试人员细分的调查和功能请求投票来了解用户的痛点和愿望，获得强大的洞察力来增强您的产品路线图。
其他
作者：Sherief Abul-Ezz