我正在为新的企业应用程序创建自动化框架。我正在使用Selenium(Webdriver),Java,Maven和TestNG。我已经读过,我需要保持我的测试小而自主,所以我可以独立地运行它们。
登录应用程序是最耗时的过程。如果我必须登录并为每个测试重新开始,那么我的测试套件需要一段时间才能运行。此外,如果我已经登录并导航到应用程序的某个部分,我可能也会执行一些测试,而不是在一次测试后关闭浏览器并每次都返回导航。
我应该坚持使用简短的自主测试还是找到另一种方法来构建测试?
答案 0 :(得分:4)
在我看来,同时连接几个测试并不是一个好主意。让我们考虑一下您有三个测试用例的场景:测试用例1 ,测试用例2 和测试用例3 。
考虑一个您只想运行测试用例3 的场景。如果脚本不是自治,则在执行测试用例1 和测试之前,您将无法运行测试用例3 案例2 。因此,尝试将测试用例链接在一起是违反直觉的。
创建方法以登录并在站点的不同部分之间导航,并且一遍又一遍地重复使用这些方法。它将帮助您更好地理解和组织测试脚本。即使执行它可能更耗时,但它们更灵活,并且独立的测试脚本总是更容易理解。
每个人都有自己的编写测试脚本的风格,因此意见可能会有所不同。这只是我的建议。
答案 1 :(得分:2)
我认为这里正确的方法是将测试需要做的规范(测试用例,还有设置和拆除活动)与如何运行它们的规范分开(这样的规范可能被称为'测试执行策略')。
执行此操作的另一个原因是,通常无法将测试用例与设置操作分开。 相反,您可以执行一系列操作:一些测试应用程序,一些准备此类测试,另一些同时执行这两项操作。
例如,Web应用程序工作流通常看起来像
所有这四个步骤都是有效的测试用例:它们可能会以暗示应用程序行为不端的方式失败。 但是,它们不能单独运行:步骤1必须在步骤2之前执行,2必须在3或4之前运行。步骤依赖。
因此尝试各种执行策略是有意义的:
第二种策略可称为“自主”策略。其他策略是可能的:例如你可能想要同时运行1,2,4和1,2,3,4。
测试用例的规范将列出所有具有它们之间依赖关系的测试用例。 最好通过列出前提条件列出依赖项:在执行测试步骤之前必须保留的应用程序状态的特定条件。一些先决条件最初持有,一些是后置条件(它们将在成功执行特定步骤后保持)。依赖是一个先决条件,也是后置条件。 例如,登录状态是步骤3和4的前提条件以及步骤2的后置条件。 因此,您最终得到了测试步骤和条件的图表。一些测试步骤是应用程序测试:它们失败的特定方式表明应用程序没有按预期运行。但是,由于其他原因,步骤可能总是失败。
然后,测试执行策略是一种系统的方式来走这个图,以确保每一步都经过测试。
目标是最终测试您需要测试的所有内容。但这并不一定意味着您需要尽可能使测试尽可能自主。如果您可以确信在执行的最后一步中始终可以归咎于测试序列的失败,那么第一个策略也是可行的,而且速度要快得多。
事情可能会变得更复杂:
这就是将测试步骤的规范与测试执行的规范分开的更多原因。我认为这些事物的某些特定形式比你的测试序列最终是否尽可能自主更为重要。
所以我有点惊讶Selenium文档中没有讨论过这个问题。
答案 2 :(得分:0)
保持测试自主的另一个好处是它可以让您独立执行并行执行。并行运行可以帮助您缩短执行时间,即使在保持测试独立的同时也是如此。
如果你有依赖测试,那么一个的结果也会影响第二个测试用例。如果每个测试用例独立运行,那么怪胎故障不会导致多个案例失败。
此外,您可以使用软断言并尝试在测试中创建逻辑(可能更大)的场景,如果逻辑上符合要求,则在一个测试中验证多个事物。 手动案例并不总是应该一对一地映射到自动化测试。
正如法希姆提到的那样,它与风格以及你想要自动化的内容有关。