我正在为一个新的企业应用程序创建一个自动化框架。我正在使用 Selenium(Webdriver)、Java、Maven 和 TestNG。我读到我需要让我的测试保持小型和自主，这样我就可以独立运行它们。
登录应用程序是最耗时的过程。如果我必须登录并重新开始每个测试，这会使我的测试套件需要一段时间才能运行。此外，如果我已经登录并导航到应用程序的某个部分，我还不如执行一些测试，而不是在一次测试后关闭浏览器并每次都导航回来。
我应该坚持简短的自主测试还是寻找其他方式来构建测试？
【问题讨论】：
标签： testing selenium selenium-webdriver testng browser-automation
在我看来，同时链接几个测试并不是一个好主意。让我们考虑一下您拥有三个测试用例的场景：Test Case 1、Test Case 2 和 Test Case 3。
假设您只想运行 Test Case 3。如果脚本不是自治的，那么在您执行 Test Case 1 和 Test 之前，您将无法运行 Test Case 3案例2。因此，尝试将测试用例链接在一起是违反直觉的。
创建方法来登录和在网站的不同部分之间导航，然后一遍又一遍地重复使用这些方法。它将帮助您更好地理解和组织您的测试脚本。尽管执行起来可能更耗时，但它们更灵活，独立的测试脚本总是更容易理解。
每个人都有自己编写测试脚本的风格，因此意见可能会有所不同。这只是我的建议。
【讨论】：
我认为这里正确的方法是将测试需要做什么的规范（测试用例，还有设置和拆卸活动）与如何运行它们的规范分开（这样的规范可能被称为'测试执行策略'）。
这样做的另一个原因是，通常实际上不可能将测试用例与设置操作分开。 相反，您可以执行一系列操作：一些测试应用程序，一些为此类测试做准备，还有一些两者兼而有之。
例如，Web 应用程序工作流通常看起来像
所有四个步骤本身都是有效的测试用例：它们可能以暗示应用程序行为异常的方式失败。 但是，它们不能单独运行：第 1 步必须在第 2 步之前执行，第 2 步必须在第 3 步或第 4 步之前运行。这些步骤是相互依赖的。
因此尝试各种执行策略是有意义的：
第二种策略可以称为“自主”策略。其他策略是可能的：例如您可能希望同时运行 1、2、4 和 1、2、3、4。
测试用例的规范会列出所有的测试用例以及它们之间的依赖关系。
最好通过列出先决条件来列出依赖关系：在执行测试步骤之前必须满足的应用程序状态的特定条件。一些先决条件最初成立，有些是后置条件（它们将在成功执行特定步骤后成立）。依赖是前置条件，也是后置条件。
例如，登录状态是第 3 步和第 4 步的前提条件和第 2 步的后置条件。 因此，您最终会得到一张测试步骤和条件的图表。
实际上是一个超图，因为每个步骤都可能与多个前置条件和后置条件相关联。
此外，每一步都可能有可变的输入和可变的可观察输出。输出将用于确定当前状态。
所以结果是Mealy machine，如果每个步骤最多有一个前置条件和一个后置条件，并且有多个前置条件和后置条件，则更类似于colored Petri net 或abstract state machine。
如果应用程序设计良好，那么您需要达到的所有相关状态都是
然后，测试基本上包括遍历超图并观察输出以验证所有可能的步骤是否使应用程序进入预期状态。
测试执行策略是遍历该超图的系统方法，以确保每个可能的步骤都得到测试。
目标是最终测试您需要测试的所有内容。但这并不一定意味着您需要使测试尽可能自主。如果您有信心始终可以将测试序列的失败归咎于执行的最后一步，那么第一个策略也是可行的，而且速度要快得多。
事情可能会变得更复杂：
这就是将测试步骤规范与测试执行规范分开的更多原因。我认为以一种或另一种形式指定这些东西远比你的测试序列最终是否尽可能自主更重要。
所以我有点惊讶 Selenium 文档中没有讨论这些内容。
【讨论】：
保持测试自治的另一个好处是它使您能够独立地并行执行。并行运行将帮助您缩短执行时间，即使在保持测试独立的情况下也是如此。
如果您有依赖测试，那么其中一个测试的结果也会影响第二个测试用例。如果每个测试用例独立运行，那么异常失败不会导致多个用例失败。
此外，您可能会使用软断言，并尝试在测试中创建合乎逻辑的（可能更大一点）场景，在一个测试中验证多个事物是否符合逻辑。 手动案例并不总是应该一对一地映射到自动化测试。
正如 Fahim 正确提到的那样，它与风格以及您尝试自动化的内容有关。
【讨论】：