如何设计UI自动化测试，以便在流中随机选择可选步骤？

Question

背景:在一些情况下(主要是端到端的UI测试)，许多测试路径(可选测试步骤的选择)可能由于组合而庞大，但是预期的结果是相同的，很少的。在这些场景中，我强烈认为需要引入一个随机性元素来选择测试路径，因为在遵循特定的随机路径时，我们正在手动发现越来越多的问题，而标准的自动化E2E测试主要是按照主流程通过的。

上下文:在包含步骤的端到端场景中，假设A-Z中的任何步骤都可能有可选的子步骤，阿-g可以在web/移动应用程序上运行，所以如果我们改变用户旅程中的任何子步骤，我们就会在某些特定的子步骤选择上发现问题，但在general.Also中，由于手工或自动化的巨大组合，我们无法运行每个独特的选择组合。

问题陈述:在端到端UI测试中，设计备选子步骤选择中的随机性的标准/公认的共同智慧是什么？

编辑:添加更有意义的示例

一个漫长的用户旅程，由多个步骤组成，每个步骤都可以在web或移动应用程序上独立完成。此外，在移动领域做一些步骤并不能在web应用程序中反映出来，反之亦然。

Answer 1

就我个人而言，我得出的结论是，通过UI测试随机性是一个糟糕的测试实践。我发现它会导致长时间的缓慢测试，这些测试是不可重复的，并且会增加值得怀疑的价值。正如Pieter所说，UI测试已经足够缓慢和不需要增加更多的随机性了！

根据这些教训，我现在的做法是：

• 使用基于“示例”的测试，测试预先知道的特定条件
• 当您需要进行数据组合测试时，使用单元和集成测试来测试变体。
• 避免使用'Faker‘和其他随机程序。确定您要测试的内容，并测试它

我发现很多人对通过UI测试随机性感到非常兴奋-嘿，看，几乎没有代码，我可以测试1000个不同的组合！然而，我的经验是，尽管看上去很令人兴奋，但这可以避免为你想知道工作的特定条件添加快速的特定测试，如果它们不想知道，就会提供快速反馈。许多导致故障的随机生成器代表着不太可能出现的错误，这些错误会得到足够的服务，同时也会产生一个普遍的错误。它们可以导致写作..。从而维持..。很多不真实的场景。

例如，美元数额。公司可以确定可接受的格式是99，999.99，即高达99,999.99，逗号是可选的。考虑到不需要尝试ssdfdf.23、123.aa、76.1234等，尽管它们可能都是由随机字符串生成器生成的。我发现ok测试(有效) 23.40 0.30 12,435.34和(无效) 'a‘123,456.78和.401更好

我发现，即使应用程序实际上具有随机性，上面的内容也是正确的。例如，如果应用程序显示“单击此按钮以选择任意颜色”。你可以测试一下。您可以看到结果是否在有效的名称范围内。但这会增加什么价值呢？如果随机例程被打破，并且总是给出相同的值，该怎么办？这让你开始浪费大量的时间。我发现更好的方法是选择红色，下一页显示红色图标。

当你说“我强烈认为需要引入随机性元素来选择测试路径。”我想知道更多你为什么这么想？此外，给出的例子-付款类型是一个有趣的例子，毕竟没有实际用户随机选择！所以我说你的测试也不应该，它应该像一个真正的用户一样，知道它想要使用什么样的支付类型。

Answer 2

增加随机性有很多种方法--但如果你这样做了，就必须处理随机性:-)

您没有提到什么是您的域，所以让我们假设旧的最爱:购物车。

您可以通过以下方式添加随机性：

• 搜索已知产品类型之一(从已知列表中随机选择)
• 从找到的列表中随机选择一种精确的类型(从计算列表中选择随机类型)
• 购买随机(小)项目数(普通旧随机数)
• 对于加分，做以上多次(随机)次数，其中一些尝试将使用相同的产品类型，一些相同的产品项目与相同(或不同)计数。

然后，您需要使您的代码足够聪明，以解释结果(看看它们是否正确)。

OP希望添加步骤的随机顺序:创建子步骤/工作流，并随机选择它们。

现在你还有更大的山要爬。这种解决方案的复杂性显著增加:创建、维护代码的成本，特别是解释故障的成本将需要进行大量的研究。我无法想象会有什么情况值得付出代价。如果项目有额外测试的预算，IMHO将更好地用于添加更多的可预测类型的测试，而不是随机工作流。

Answer 3

一些考虑因素：

• 根据我的经验，要使UI测试稳定是非常困难的；即使您一次又一次地运行同一组测试，一些测试也会随机地以未知的原因失败。这很难调试和修复。如果现在要将测试的执行路径随机化，那么就不太容易发现原因不明的重复随机附带故障，因为每次测试都不是以相同的方式运行。
• 当您运行测试套件时，当您得到一个由被测试软件中的缺陷引起的故障时，就不清楚故障在那里存在了多长时间了。缺陷可能已经在生产中了，也可能是刚刚被引入的。由于您不知道它是什么时候引入的，所以不能简单地检查最后一次提交，看看可能导致它的原因。
• 我建议您看看是否可以将测试分成越来越小的测试套件。小套间可以经常运行，而较大的套房可以更少地运行(也许是夜间)。如果有任何失败的测试，您可以准确地看到最后一次成功运行的时间，并且可以检查在两次运行之间做了哪些更改。
• 与开发人员讨论在技术测试中涵盖更多、功能ui测试更少的可能性(如果您还没有这样做的话)。
• 如果有可能存储最后使用的执行路径，我只会考虑使用随机的测试执行顺序。如果确实发生了故障，您希望能够像以前一样运行完整的测试集，用于调试和修复确认测试。