测试beta测试_重新想象不断变化的自动化世界中的Beta测试

测试beta测试

从根本上讲，beta测试是对真实用户在真实环境中执行的产品的测试。 这种测试类型有很多名称-用户接受测试（UAT），客户接受测试（CAT），客户确认和现场测试（在欧洲很常见），但是基本组成部分几乎相同。 所有这些都涉及对前端用户界面（UI）和用户体验（UX）的用户测试，以发现并解决潜在问题。 测试是在软件开发生命周期（SDLC）中的各个迭代过程中进行的，从构思转变为设计的阶段，跨越开发阶段，再到单元测试和集成测试。

产品生命周期管理（PLM）Beta阶段是从目标市场获得反馈并计划未来之路的绝佳机会。 这个阶段的测试范围很广，从前端或与UI相关的测试（涉及UI功能，视觉外观和UI级交互）到UX（包括使用A / B进行用户测试或拆分测试） ，假设，用户行为跟踪和分析，热图，用户流和细分受众群以及探索性测试和反馈循环）。

如果您问大多数人，为什么Beta测试和相关工具很重要，他们会说诸如缩短Beta周期，减少投资时间，增加测试人员的参与度，改善反馈循环和可见性之类的事情。 但是，beta测试如此重要的所有原因都可以归结为两个主要问题，这两个问题在SDLC的beta测试阶段都是很重要的：

1. 人与技术的交汇处
2. 可用性和质量标准

人与技术的交汇处

^{萨米尔·达什（Samir Dash）。 CC0 1.0}

人类用户与Beta测试中经过验证或验证的产品各方面之间的情感联系更加紧密。 同样，当我们从传统软件方法定义关键性时，在UAT / beta中测试的区域大部分属于Class 3和Class4。但是，由于它们也涉及人类的核心方面，因此它们非常重要。

此视频男孩戴眼镜来矫正色盲说明了什么。我是指技术的触摸人类情感的能力。 眼镜技术解决了“可访问性”，这在beta测试中得到了评估。 可访问性影响许多人。 美国人口普查数据表明， 五分之一的人有残障，但很少有网站符合WC3的无障碍指南。

观看此视频可能会导致开发人员，设计师和测试人员问：“我们可以为这个父子做些什么？” Beta测试验证并验证该技术是否满足目标用户的需求。

可用性和质量标准

^{萨米尔·达什（Samir Dash）。 CC0 1.0}

随着时间的推移，有关质量与可用性的国际标准组织（ISO）标准已经发展。 1998年，ISO将效率，有效性和满意度确定为可用性的主要属性。 仅仅一年之后的1999年，该建议模型就根据内部软件质量和外部因素来接近质量。

在2001年，ISO / IEC 9126-4标准将可用性和质量之间的差异定义为可察觉的细线，这表明可用性和质量之间的差异是上下文的问题。 它还区分了内部质量和内部质量以及定义的相关指标。 在此标准下，只能通过在预期使用环境中使用产品来衡量外部质量。 因此，如果没有在正确的环境中进行可用性/ HCI测试，则质量控制过程将不完整。 请注意，“上下文”是beta测试的基础（即“真实环境中的真实用户”），这加强了beta测试的必要性。

Beta测试的挑战

既然我们已经概述了Beta测试如此重要的原因，那么让我们探究与之相关的挑战。 请注意，包括ISO / IEC 9126在内的已定义标准都是静态的，没有一个真正描述产品开发周期中各个阶段与特定项目里程碑处适当的可用性度量之间的关系。 此外，这些标准就如何从特定可用性指标解释分数给出的指导原则相对较少。 并且，针对可用性作为质量因素的特定含义，请注意，可用性是必须解释度量标准的质量方面。

当今顶级的beta测试工具由客户或最终用户自行决定是否进行解释。 这是Beta测试中的最大挑战：我们如何从实际和有效的问题与疑虑中滤除纯粹的看法？ 大多数问题与用户测试，拆分测试和前端测试有关。 没有足够聪明的优化单窗口解决方案来有效地处理所有问题。 真实环境中的真实用户通常无法理解Beta测试的所有方面。 由于我们正在测试他们的观点，因此无法使用某些基准/标准中的数据对其进行验证。

Sogeti，Capgemini和HPE的《 2015-16年世界质量报告》指出，对beta测试的期望正在发生巨大变化。 它建议客户在真实的，面向客户的环境中，希望有一种更可靠的方法来测试质量和功能，以及定期的可用性和用户测试。

技术，开发，交付机制和方法的变化所带来的复杂性和挑战不断增加，不仅影响Beta测试阶段，还影响着整个测试方案。 根据《 2017-18年世界质量报告》 ，测试环境和测试数据仍然是质量保证和测试的致命弱点，而敏捷开发中测试的挑战也日益加剧。 现在，在软件质量测试中对自动化，移动性和普遍性以及智能性提出了需求。 许多人认为，即使是在测试涉及产品功能方面的情况下，基于分析的自动化解决方案也可以为整个QA和测试，尤其是Beta测试提供更智能的QA和更智能的测试自动化。

在基准测试功能方面以及可用性和用户测试方面，流行的Beta测试解决方案之间存在很大的空白。 基本上，流行的beta测试解决方案缺乏“智能”和自动化。 使用认知技术，自动化和机器学习的智能测试有足够的空间。

如果我们从相应角色的角度评估用户需求，其他挑战将变得显而易见。 例如，即使我们认为解决方案正在验证产品的功能方面，最终用户或客户也可能无法识别它。 作为“真实环境中的真实用户”的产品所有者，客户或最终用户可能对底层技术没有足够的了解以认可其测试结果。 这就像一个购买二手车的顾客的经典例子，尽管他不具备识别问题的能力，但他还是想在引擎盖下寻找东西。

对于一个Beta测试工具，该工具可以使最终用户获得正确的信息来做出有关产品的决定，该工具应使用户放心，同时还可以验证产品。 不幸的是，许多试图解决一些小问题以增强用户能力的小型工具（例如，用于分析CSS以确定对齐问题的Google Chrome扩展程序）分散了。 现实情况是，没有可用的单窗口扩展或基于窗口小部件的解决方案来解决用户授权问题。 大多数工具是针对开发人员或测试人员的，而不是针对没有专门技能的客户，因此，普通客户/最终用户无法理解它们。

以DevOps为重点，许多持续集成（CI）/持续交付（CD）解决方案正在开发中，并与其他解决方案集成，以解决技术堆栈，语言，框架等日益复杂的问题。在CI / CD模型中，自动化测试中的解决方案主要参与SDLC的“测试前”阶段。 此外，运行它们通常需要熟练的开发人员或测试专家，这在测试“真实环境中的真实用户”的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。 其中一个SpecSpec是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的中型渠道上阅读我的文章“ Specstra” —在设计行业的设计行业尝试自动化 。

最后，作为一个开源项目， BetaStudio的代码可在GitHub上获得 ； 随时在那里进行探索。

开发理想的Beta测试解决方案需要花费时间和精力，并且概念会随着时间的推移而发展。 但是，连接和探索如何实现它的旅程正在进行中。 如果您有想法或问题，或者想加入旅程，请在下面的评论部分中分享您的想法。

本文基于2017年12月7日在班加罗尔RedHat QE CampX上发表的论文。

翻译自: https://opensource.com/article/18/1/beta-testing-automation

测试beta测试