错误 – 您的自动化测试真的在测试吗？

引言

看到你的自动化测试仪表盘始终是绿色的，会带来很大的满足感，业务部门认为测试人员编写了良好、可靠的测试，他们的软件没有问题。 问题是，如果你实际上没有验证任何值得注意的东西，要获得一个始终通过的测试并不难。 显然，您需要在测试中执行的验证完全取决于您的需求和验收标准，因此没有必须和不必须检查的明确列表。 为了坚持我们在之前文章中熟悉的内容，让我们使用术语“断言”。

虽然没有正确或错误的断言，但绝对有好和坏的断言。

让我们看一个具体的例子，以对页面执行操作后预期的string进行断言，在本例中，成功下单。 我们的验收标准规定，成功下单应显示一个string，内容是：

“Thank you for your order! You will receive confirmation by email shortly!”

我们可以在测试结束时进行如下断言：

Assert.IsTrue(orderConfirmationPage.ConfirmationText.Contains
(“Thank you for your order! You will receive confirmation by email shortly!”);

现在，以上方法是可行的，并且只要我们的确认页面包含该string就会通过。 但问题在于，它是否*包含*该string。 如果我们的string返回为：

“Yo shopper. Just thought we’d say “Thank you for your order! 
You will receive confirmation by email shortly!” 
But in the mean time, you could have gone elsewhere and got it a lot cheaper, we’re overpriced!”

但因为我们只检查我们的string是否包含该消息，它仍然会通过。 它不在乎它之前或之后有什么，只要在某个时刻，该string存在即可。

这意味着基本上，你根本没有真正测试什么。 更好的断言是：

Assert.IsTrue(orderConfirmationPage.ConfirmationText.Equals
(“Thank you for your order! You will receive confirmation by email shortly!”);

现在，我们的断言只有在我们的string完全是我们传入的内容时才能通过。 没有多余的内容，没有拼写错误，什么都没有。 因此，我们的断言立即成为对我们订单放置页面的更好测试。

但重要的是要指出，即使在这个最简单的例子中，我们的测试断言也可以更加彻底，以确保更好的测试覆盖率。 假设我们的订单确认页面有自己的 URL，并且除了这一点之外，它还有一个“继续购物”按钮，该按钮仅在该页面上才会显示。 我们可以通过添加以下内容来进一步改进我们测试的验证：

Assert.IsTrue(orderConfirmationPage.ConfirmationText.Contains
(“Thank you for your order! You will receive confirmation by email shortly!”);
Assert.AreEqual($”{homePageUrl}/orderconfirmation”, orderConfirmationPage.Url)
Assert.IsTrue(orderConfirmationPage.ContinueShoppingButton.Exists()

现在，我们不仅确保我们的文本是正确的，而且还确保我们已正确导航到正确的页面，并且页面上存在预期的按钮。 因此，我们可以完全确信，如果我们的测试通过，我们正在测试所有内容，现在如果我们的测试失败，则肯定存在问题。

不仅断言可能证明是测试验证不佳的问题。 测试用例本身也可能存在问题。 如果测试用例特别难以自动化，那么可能会尝试以至少可以自动化其一部分或其修改版本的方式来调整它。 这样做的麻烦在于，通过偏离原始测试用例，您不仅偏离了需要测试的内容，而且现在您可能会得到一个从来没有人真正要求或想要的测试用例。

这些也是容易通过的测试类型，因为它们做的事情很少，或者根本没有测试为其编写的应用程序/系统中的任何值得注意的东西。 这就是为什么在项目开始时，甚至在每个 sprint 或迭代开始时，确定你的测试策略至关重要，这样你就可以尽早识别出这些不适合自动化的领域。

本文的主要重点是强调在编写自动化测试时，不仅要进行验证，而且要进行正确的验证是多么重要。 永远不要编写旨在始终通过的测试，而是要牢记测试用例和验收标准来编写它们。 这样，您依靠开发的正确性和高质量来使您的测试通过，而不是依靠薄弱的测试。

这篇文章错误 – 你的自动化测试真的在测试吗？首次出现在Learn Automation。