具有手动测试的BDD？

Question

我们正在从经典的“瀑布”模型转变为更注重敏捷的哲学。我们决定尝试使用BDD（黄瓜），但是在迁移某些“旧”方法时会遇到一些问题。最大的问号是手动测试如何集成到周期中。

假设项目经理定义了功能和一些基本的方案大纲。在测试团队中，我们为此功能定义了大约40种方案。有些无法自动测试，这意味着它们必须手动进行测试。当您仅有功能文件时，请执行手动测试，感觉不对。我们希望能够看到例如过去的测试失败率。大多数测试案例管理器都支持此类功能，但不能使用功能文件。在外部测试案例管理器中维护手动测试用例，将导致功能文件和测试案例管理器之间永无止境的更新问题。

我很想知道是否有人能够掩盖这种“中间立场”以及如何解决。

Answer 1

这不是一个非常不寻常的案例。即使在敏捷中，也可能无法自动化所有场景。与我合作的 Scrum 团队通常在功能文件中将它们标记为 @manual 场景。我们已将自动化套件 (Cucumber - Ruby) 配置为在运行夜间作业时忽略这些标签。这样做的一个问题是，正如您所提到的，我们不知道手动测试的结果是什么，因为测试人员会在本地记录结果。

我对此的建议是以 YML 或任何其他适合此目的的文件格式记录每次迭代的结果。该文件应该是自动化套件的一部分，并且应该在存储库中进行检查。因此，首先，您将结果与自动化套件一起记录下来。稍后当您有资源和时间时，您可以向自动化套件添加一个功能来读取此文件并生成带有其他自动化结果或单独的报告。在此之前，您的版本控制应该可以帮助您跟踪所有以前的结果。

希望这可以帮助。

Answer 2

要添加到@Eswar的答案中，如果您使用的是Cucumber（或其同级之一），则一种选择是手动执行测试运行程序，并包括提示以便测试人员检查某些方面。然后，他们根据自己的判断通过/未通过测试。

这通常对于美学方面很有用，例如跨浏览器渲染，元素对齐，使用的正确图像等。

正如@Eswar所提到的，您可以通过标记这些测试将它们从自动化运行中排除。

请参阅本文的示例。