是真的吗？

Question

我注意到许多开发团队使用许多测试用例实现UAT自动化。这是用户关心的事情，但是测试不是由真正的用户完成的。例如，自动化将测试这是否正确：“当用户密码不正确时，显示错误消息”。这是一个很好的实践，但我不明白为什么这被称为UAT？

UAT的定义包括“.软件在现实世界中由其预期的受众进行测试”和“在UAT中，用户有机会在正式发布之前与软件进行交互”。

即使名称本身也表示它是用户接受测试(用户必须接受它，而不是代表用户的开发人员)

这与我经常看到的UAT测试非常不同：

• 由开发人员(而不是最终用户)编写和维护
• 在“实验室”环境中自动化，而不是真正的环境

再说一次，我不是说它有什么问题，它只是让我感到困惑，它被称为UAT。我能自己想出的唯一解释是，真正的用户很忙，很无聊，对做真正的UAT不感兴趣，所以开发人员必须通过创建测试系统的虚拟用户来填补空白。一个更好的方式来思考它是前UAT，还是模拟-UAT？

相关的问题是，在CI/CD环境中，“真实”的UAT是如何实现的？自动化和短周期似乎使真正的UAT变得不可行。对于现代CI/CD风格的SaaS应用程序，是否有人真的对真实的人做UAT？

在谈论“真实的”UAT和“模拟的”UAT时，QA使用什么术语？

我是否理解UAT，它的必要使用和它的限制是正确的？

Answer 1

我不完全同意你对UAT的定义。“真实世界”有点模糊，可能意味着“生产”，但事实并非如此-- UAT可以在一个单独的、孤立的环境中执行。UAT也可能在发布后出现，但在新用户接受并开始使用该软件或软件的特定功能之前。定义UAT的关键部分是，它是由对用户需求有深入了解的人执行的，以及系统将如何在其预期的上下文中使用，并能够评估其在该上下文中使用的适用性。

软件交付模型的类型在这里很重要。为一组特定用户构建定制软件的组织与在市场上构建供销售的软件的组织情况不同。在构建定制软件时，开发团队往往对客户和用户需求有着深刻的理解。在为市场构建软件时，开发团队需要关注满足许多潜在客户和用户需求的广泛需求，有时这些需求会发生冲突，因此您将不得不明确地不满足某人的需求。

在这两种情况下，我都会看看是谁设计、评审和批准了测试用例。如果测试用例至少得到了某个用户身份的审查和批准，那么您可以将这些测试用例的执行视为一个UAT。开发组织可以将客户的用户验收测试套件构建到他们的测试套件中，运行这些测试，并向客户提供测试执行状态的报告，作为客户开发过程的一部分。

还有一些组织提供服务验证和服务UAT.购买软件的组织可以与另一个组织签订合同，以深入了解他们的需求，并代表他们执行UAT。有时，一个大型软件供应商可能会有一个专业的服务团队来执行这些任务，或者可能是第三方，尽管他们通常不是开发组织的一部分，但我不明白他们为什么不能这样做，除非在受监管的行业中对验证和验证活动的独立性提出一些要求。

拼图的最后一部分是UAT的时间。在执行持续部署时，完全有可能执行UAT活动。特征标志可以帮助控制用户何时获得对功能的访问，并允许将功能部署到产品中，并在用户完成UAT活动并批准使用该功能后为其启用功能。有几种类型的特性标志取决于您的特定需求。

Answer 2

在我工作的地方，我们有一个名为UAT的环境，其中唯一的测试是由我(QA)完成，一旦我们在那里部署了我已经在较低的环境中测试过的内容，就可以检查环境是否稳定。这仅仅是因为企业不会提供任何人进行UAT测试。事实上，我们有一个临时环境只是为了这个目的。海事组织，UAT是由用户或被选中/培训从事用户测试的人(实际用户每天在系统上执行的过程)所做的测试，而不管在何种环境中进行。

Answer 3

相关的问题是，在CI/CD环境中，“真实”的UAT是如何实现的？自动化和短周期似乎使真正的UAT变得不可行。对于现代CI/CD风格的SaaS应用程序，是否有人真的对真实的人做UAT？

您是正确的，在CI/CD环境中，UAT传统的方式是不可能的，但是您可以通过使用拆分交付方法(如金丝雀发布或A/B测试)和从您的真正客户中获得一小部分真正的反馈来绕过它。显然，使用这种方法有风险，但另一方面，假设您正确地设置了监视和反馈，则可以得到快速可靠的反馈。