问硒测试应该是自主的吗？

EN

在我看来，同时连接几个测试并不是一个好主意。让我们考虑这样一个场景，其中您有三个测试用例：测试用例1、测试用例2和测试用例3。

考虑一个场景，其中您只想运行测试用例3。如果脚本不是自治的，那么在您执行测试用例1和测试用例2之前，您将不可能运行测试用例3。因此，尝试将您的测试用例链接在一起是违反直觉的。

创建方法来登录并在站点的不同部分之间导航，只需一次又一次地重用这些方法。它将帮助您更好地理解和组织测试脚本。尽管执行起来可能会更耗时，但它们更灵活，而且独立的测试脚本总是更容易理解。

每个人都有自己的测试脚本编写风格，因此可能会有不同的看法。这只是我的建议。

我认为这里的正确方法是将测试需要做什么的规范(测试用例，以及设置和销毁活动)从如何运行它们的规范中分离出来(这样的规范可以称为“测试执行策略”)。

这样做的另一个原因是，通常不可能将测试用例从设置操作中分离出来。相反，您有一大堆可以执行的操作:一些测试应用程序，一些准备这样的测试，还有一些同时执行这两个操作。

例如，web应用程序工作流通常如下所示

通过与站点交互，

1. 打开特定的URL并以特定的身份注销登录某些活动(这可以重复indefinitely)
2. (optionally)

所有这四个步骤本身都是有效的测试用例:它们可能会以暗示应用程序行为不当的方式失败。但是，它们不能单独运行:步骤1必须在步骤2之前执行，而步骤2必须在步骤3或4之前运行。这两个步骤是相关的。

因此，尝试各种执行策略是有意义的：

• 按顺序运行所有这些步骤；如果失败，则将失败归咎于执行的最后一步。因此我们得到测试序列1，2，3，4。
• 对于每个步骤，创建单独的测试序列来测试该步骤:所以我们得到测试序列1；1，2；1，2，3；1，2，4。

第二种策略可以称为“自主”策略。其他策略也是可能的:例如，你可能想同时运行1，2，4和1，2，3，4。

测试用例的规范将列出所有测试用例以及它们之间的依赖关系。

最好通过列出前提条件来列出依赖项:在执行测试步骤之前必须满足的应用程序状态的特定条件。一些前置条件最初是有效的，有些是后置条件(它们将在成功执行特定步骤后有效)。依赖关系是一个前提条件，也是一个后置条件。

例如，登录状态是步骤3和4的前提条件，是步骤2的后置条件。因此，您最终得到了测试步骤和条件的图形。

实际上，这是一个超图，因为每个步骤都可能与多个前置条件和后置条件相关联。

此外，每个步骤可以具有可变的输入和可变的可观察输出。您将使用输出来确定当前状态。

因此，如果每个步骤最多有一个前置条件和一个后置条件，并且有多个前置条件和后置条件，那么结果就是一个Mealy machine，类似于colored Petri net或abstract state machine。

如果应用程序设计良好，您需要达到的所有相关状态都是

• there
• observable：：您可以设计和执行步骤，以便您可以设计和执行步骤，以便它们的输出将有效地告诉您您是否已成功达到

状态

然后，测试基本上包括遍历超图并观察输出，以验证所有可能的步骤将应用程序带入预期状态。

测试执行策略是一种系统地遍历超图的方法，以确保每个可能的步骤都得到了测试。

最终的目标是测试你需要测试的所有东西。但这并不一定意味着你需要让测试尽可能的自动化。如果您可以确信您总是可以将测试序列的失败归咎于执行的最后一步，那么第一个策略也是可行的，而且速度要快得多。

事情可能会变得更加复杂：

对于更复杂的图形，在执行策略之间的选择也变得更加复杂您要测试的不是特定步骤，而是通过图形的特定路径(但这意味着您确实应该指定一个隐藏的前提条件)

• 您可能想要使用不同的输入数据执行相同的步骤，或者根据先前步骤的输出选择步骤

这就是将测试步骤的规范从测试执行规范中分离出来的原因。我认为，以一种或另一种形式指定这些东西，远比您的测试序列最终是否尽可能地自动化要重要得多。

所以让我有点惊讶的是，Selenium文档中没有对此进行讨论。

保持测试自主性的另一个好处是，它让你可以独立地并行执行。并行运行将帮助您减少执行时间，即使在保持测试独立的情况下也是如此。

如果您有依赖测试，那么其中一个测试的结果也会影响第二个测试用例。如果每个测试用例独立运行，那么异常故障不会导致多个测试用例失败。

此外，您可以使用软断言，并尝试在测试中创建逻辑场景，如果它们符合逻辑，则在一个测试中验证多个内容。手动用例并不总是应该一对一地映射到自动化测试。

正如Fahim正确提到的那样，它与风格有关，也与您试图自动化的内容有关。