从根本上说，Beta 测试是由真实用户在真实环境中对产品进行的测试。这种类型的测试有很多名称——用户验收测试 (UAT)、客户验收测试 (CAT)、客户验证和现场测试（在欧洲很常见）——但基本组成部分或多或少相同。所有这些都涉及到对前端用户界面 (UI) 和用户体验 (UX) 进行用户测试，以查找和解决潜在问题。测试发生在软件开发生命周期 (SDLC) 的各个迭代中，从一个想法转变为设计，贯穿开发阶段，直到单元测试和集成测试之后。
产品生命周期管理 (PLM) Beta 阶段是获取目标市场反馈并规划未来道路的绝佳机会。在此阶段的测试范围很广，从前端或 UI 相关的测试（包括 UI 功能、视觉外观和感觉以及 UI 级别的交互），到 UX（包括使用 A/B 或拆分测试、假设、用户行为跟踪和分析、热图、用户流程和细分偏好以及探索性测试和反馈循环的用户测试）。
如果您问大多数人为什么 Beta 测试和相关工具如此重要，他们会说出诸如缩短 Beta 周期、减少时间投入、提高测试人员参与度、改进反馈循环和可见性等原因。然而，Beta 测试如此关键的所有原因都可以归结为两个主要问题，这两个问题在 SDLC 的 Beta 测试阶段都非常突出
- 人类与技术的交汇点
- 可用性和质量标准
人类与技术的交汇点
Samir Dash。 CC0 1.0
人类用户与在 Beta 测试中验证或确认的产品方面的情感联系更紧密。此外，当我们从传统的软件方法定义严重性时，在 UAT/Beta 期间测试的区域大多属于 3 类和 4 类。但是，由于这些区域也触及核心人类方面，因此非常重要。
这个视频，一个男孩戴上眼镜来矫正色盲，说明了我所说的技术触动人类情感的能力。眼镜技术解决了“可访问性”问题，这在 Beta 测试中会进行评估。可访问性影响着很多人；美国人口普查数据显示，五分之一的人患有残疾，但很少有网站符合 WC3 的可访问性指南。
观看此视频可能会促使开发人员、设计师和测试人员提出问题：“我们能为这对父子做些什么？” Beta 测试验证并确认技术满足目标用户的需求。
可用性和质量标准
Samir Dash。 CC0 1.0
国际标准化组织 (ISO) 关于质量与可用性之间关系的标准的演变。在 1998 年，ISO 将效率、有效性和满意度确定为可用性的主要属性。仅仅一年后，在 1999 年，提出的模型从内部软件质量和外部因素的角度探讨了质量问题。
在 2001 年，ISO/IEC 9126-4 标准定义了可用性和质量之间可感知的细微差别，表明可用性和质量之间的差异是一个上下文问题。它还区分了外部质量和内部质量，并定义了相关指标。根据此标准，外部质量只能通过在预期使用的环境中使用产品来衡量。因此，如果不结合正确的上下文进行可用性/HCI 测试，质量控制过程是不完整的。请注意，“上下文”是 Beta 测试的基础（即，“真实用户在真实环境中”），这加强了 Beta 测试的理由。
Beta 测试的挑战
现在我们已经概述了 Beta 测试如此重要的原因，接下来让我们探讨一下 Beta 测试所涉及的挑战。请注意，包括 ISO/IEC 9126 在内的已定义标准是静态的——没有一个标准真正描述了产品开发周期中各个阶段与特定项目里程碑上适当可用性措施之间的关系。此外，这些标准对于如何解释来自特定可用性指标的分数给出的指导相对较少。并且，就可用性作为质量因素而言，请注意，可用性是质量的一个方面，其中必须解释指标。
当今顶级的 Beta 测试工具将解释权留给客户或最终用户自行决定。这是我们在 Beta 测试中面临的最大挑战：我们如何从实际且有效的问题和疑虑中过滤掉纯粹的感知？大多数问题都与用户测试、拆分测试和前端测试有关；没有足够智能的优化、单窗口解决方案来有效处理所有这些问题。真实环境中的真实用户通常无法理解 Beta 测试的所有方面。由于我们正在测试他们的视角，因此无法使用来自某些基准/标准的数据来验证它。
Sogeti、Capgemini 和 HPE 发布的《2015-16 年世界质量报告》指出，人们对 Beta 测试的期望正在发生巨大变化。它表明客户需要一种更可靠的方式来测试质量和功能，以及在真实的面向客户的环境中进行定期的可用性和用户测试。
技术、开发和交付机制与方法的复杂性和挑战日益增加，正在影响整个测试场景，而不仅仅是 Beta 测试阶段。根据《2017-18 年世界质量报告》，测试环境和测试数据仍然是质量保证和测试的致命弱点，而敏捷开发中的测试挑战日益增加更是雪上加霜。现在需要软件质量测试的自动化、移动性、普遍性以及智能化。许多人认为，基于分析的自动化解决方案将为整体质量保证和测试，特别是为 Beta 测试产生更智能的质量保证和更智能的测试自动化，即使测试处理产品的函数方面。
流行的 Beta 测试解决方案在基准测试功能方面以及可用性和用户测试方面存在很大的真空。基本上，流行的 Beta 测试解决方案缺乏“智能”和自动化；在使用认知技术、自动化和机器学习的智能测试方面有很大的空间。
如果我们从相应角色的角度评估用户需求，其他挑战将变得显而易见。例如，即使我们假设该解决方案正在验证产品的功能方面，最终用户或客户也可能无法识别它。产品负责人、客户或最终用户（他们是“真实环境中的真实用户”）可能对底层技术没有足够的了解来签署其测试结果。这就像一个经典的二手车客户的例子，他想看看引擎盖下，即使他没有识别问题的知识。
为了使 Beta 测试工具能够为最终用户提供正确的信息以做出关于产品的决策，该工具应该让用户安心，同时验证产品。不幸的是，许多试图解决一些小问题以增强用户能力的小工具（例如，分析 CSS 以识别对齐问题的 Google Chrome 扩展程序）很分散。现实情况是，没有可用的单窗口扩展程序或基于小部件的解决方案来解决用户赋权问题。大多数工具都是为开发人员或测试人员设计的，而不是为没有专门技能的客户设计的，因此对于普通客户/最终用户来说是难以理解的。
随着对 DevOps 的关注，许多持续集成 (CI)/持续交付 (CD) 解决方案正在开发中，并与其他解决方案集成，以应对技术堆栈、语言、框架等日益增长的复杂性。在 CI/CD 模型中，测试中的自动化解决方案主要参与 SDLC 的“预 Beta”阶段。此外，运行它们通常需要熟练的开发人员或测试专家，这在 Beta 测试中效果不佳，因为您要在其中衡量“真实环境中的真实用户”。
即使假设我们在 Beta 测试中启用了所有这些自动化功能，也需要考虑另一个挑战：自动化的大量数据会产生“信息爆炸”，许多用户难以获得产品的特定上下文的整合、有意义的视图，因为需要考虑的信息太多。为了解决这些挑战，我们需要智能、互联、单窗口的 Beta 测试解决方案，其中包含最终用户无需极客帮助即可理解的自动化。
展望理想的 Beta 测试解决方案
在过去的几年里，我一直在研究 BetaStudio，这是一个理想 Beta 测试解决方案的模型和概念验证 (POC)。理想的解决方案将
- 利用来自 SDLC 和 PLM 所有阶段的数据，整合标准和规范，并集成最终用户测试数据，为客户提供更有意义的见解。
- 由真实用户在真实环境中测试真实应用程序。
- 以客户和最终用户为中心。
- 测试应用程序的“软性”方面（可用性、可访问性、外观等）。
- 足够智能，可以将应用程序的这些软性方面与功能测试数据进行比较和分析。
- 使用机器学习和认知技术来提供有意义的建议，而不仅仅是传递有关错误和潜在问题的信息。
Samir Dash。 CC0 1.0
BetaStudio 的愿景触及了上述所有“理想解决方案”标准，以及不同角色（例如客户、最终用户、开发人员、测试人员、产品负责人、项目经理、支持工程师等）在整个 PLC 中的所有交互点。它利用自动化以及机器学习组件，例如计算机视觉 (CV) 和自然语言处理 (NLP)，来收集信息，这些信息可以由认知技术处理，从而生成有关产品的见解和相关建议。该系统还整合了来自标准和规范以及 SDLC 设计阶段生成的设计基准的数据，以便可以生成有意义的见解。
将这一愿景变为现实
我们才刚刚开始将这一愿景转化为现实的旅程。
Samir Dash。 CC0 1.0
第一步将涉及创建设计基准，该基准基于在设计阶段获得的信息，并生成将产品功能与此设计基准进行比较的指标。
第二步，将对产品在运行时实时进行的自动和手动跟踪数据进行分类和整理。
第三步涉及创建支持用户反馈周期和用户测试方面的功能（例如，探索性、拆分测试功能）。
第四步将是收集所有相关标准和规范（例如，Web 内容可访问性指南第 508 条；Web 可访问性倡议规范 ARIA；设计原则；W3C 合规性；JS 标准；CSS 标准和网格；代码优化指标错误代码和规范；设备特定指南，例如，Apple 人机界面指南等）
第五步是构建关键组件，例如 CV 和 NLP 单元，这些单元将处理在所有这些阶段收集的所有数据，并生成所需的指标和推论。
第六步涉及构建单元以生成模型，以映射数据并将其与指标进行比较。
最后一步是构建认知单元，该单元可以比较数据并应用正确的模型和指标来执行数据过滤，并生成可以作为可操作的输出共享给最终用户/客户的见解。
在为 BetaStudio 进行实验时，我探索了不同的方面并构建了一些基本的 POC。其中之一 Specstra 是 BetaStudio 组件，可以帮助从设计文件创建设计基准。
Samir Dash。 CC0 1.0
Specstra 专注于测试产品的视觉外观和感觉。通常，这些类型的问题中有 30% 以上是非功能性的，并且主要是外观上的，因此没有可靠的解决方案或标准来对其进行基准测试。至少，在 Beta/UAT 测试期间标记的事项中有三分之一主要是外观和对齐问题，包括 3 类和 4 类类型。这些问题主要是因为所涉及的两个角色——开发人员和设计师——用一条虚构的细线定义了他们自己的界限。
大约 45% 的开发人员不知道如何在代码中实施设计原则或 UX 的启发法，因此他们依赖分散的工具、解决方案或 UI 模式来为他们的代码创建“设计急救”。同样，50% 的设计师不了解大多数关于设计的不断发展的技术解决方案，例如使用 CSS 网格来适应不同的设备、屏幕分辨率等。
大约 70% 的项目不包括详细的设计规范以进行基准测试，部分原因是详细说明设计规范需要成本和技能。当提供带有规范的详细设计时，很多时候设计不标准化，而且大多数设计没有清晰详细的规范。此外，由于使用不同的工具来执行设计，因此并非总是容易找到一个集中位置来获取所有设计信息以进行基准测试。
在我的概念验证中，Specstra 的作用很像基于云的视觉设计风格指南生成器，它使用第三方设计源文件，并允许用户使用他们首选的设计工具（例如，Photoshop、Sketch、Illustrator、PDF 等）。
了解更多信息
如果您想了解有关 Specstra 的更多信息，请观看此演示视频
您可以在此视频中了解有关 BetaStudio 的更多信息
您还可以阅读我在 IBM Medium 频道的设计文章 “Specstra”——在设计行业中试验自动化。
最后，作为一个开源项目，BetaStudio 的代码可在 GitHub 上获取；请随时在那里探索它。
开发理想的 Beta 测试解决方案将需要时间和精力，并且这个概念会随着时间的推移而发展。但是，连接和探索如何使其成为现实的旅程正在顺利进行中。如果您有任何想法或问题，或者想加入这个旅程，请在下面的评论区分享您的想法。
本文基于 2017 年 12 月 7 日在班加罗尔 RedHat QE CampX 上发表的论文。
评论已关闭。