BDD 与手动测试？答案

【问题标题】：BDD with Manual Tests?BDD 与手动测试？
【发布时间】：2015-03-02 14:41:38
【问题描述】：

我们正在从经典的“瀑布”模型转变为更加面向敏捷的理念。我们决定尝试 BDD（Cucumber），但在迁移一些“旧”方法时遇到了一些问题。最大的问号是手动测试如何集成到循环中。

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

我很想知道是否有人能够覆盖这个“中间地带”以及如何覆盖。

【问题讨论】：

为什么不能自动测试它们？那里有很多测试工具，您可能根本不知道有什么东西可以满足您的需求。
例如，我们没有足够的人力在一个周期内将它们全部自动化（这意味着现在将自动化一些，在下一个周期中自动化一些），或者我们发现一些测试非常面向 UI 需要一个人正确地验证它们。手动测试执行是在完美的 BDD 环境中进行的吗？还是只调试失败的自动化测试？
所以基本上你正在过渡到自动化测试？对于此时需要人工判断的测试，在过程的某些阶段截取屏幕截图怎么样？我知道你可以用 Splinter 做到这一点，如果其他浏览器自动化库也能做到这一点，我不会感到惊讶。然后有人可以通过这些屏幕截图来检查它们。或者Wraith 可能会做你想做的事。
@MatthewDaly，截屏是一个不错的选择，问题是我们将有很少的“通过”测试用例（因为截屏成功了，Cucumber 完成了他想要做的事情），但随后测试人员必须检查屏幕截图，并且可能无法通过测试。这将再次导致阶段之间的手动更新步骤（手动测试人员需要以某种方式将 Cucumber 测试标记为失败并且跟踪在外部工具上）。

标签： testing cucumber bdd manual-testing

【解决方案1】：

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

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

希望这会有所帮助。

【讨论】：

谢谢@Eswar。所以这基本上就是我们的目标。我们有一个我们在这里使用的测试用例管理器，所以我猜我们有一个更好的选择来保存迭代结果。

【解决方案2】：

无法自动化的测试用例不适合黄瓜测试。我们有很多这样的边缘案例。让 Selenium 很好地验证 PDF 文档几乎是不可能的。 CSV 下载也是如此（并非不可能，但不值得努力）。在这一点上，外观测试只需要人眼即可。使用屏幕阅读器进行辅助功能测试最好也手动完成。

为此，请务必在用于跟踪工作项的任何工具中记录用户故事中的验收标准。编写手动测试用例。 Azure DevOps、Jira、IBM Rational Team Concert 之类的公司有办法记录手动测试计划，将它们链接到故事，并记录执行手动测试的结果。

我会从黄瓜测试中删除手动测试用例，并依赖故事的验收标准，并将故事链接到某种手动测试用例，无论是在工具还是电子表格中。

有时你只需要妥协。

【讨论】：

【解决方案3】：

我们使用带有测试计划的 Azure DevOps + 一些自定义代码将黄瓜测试同步到 ADO。我可以描述一下我们是如何在项目中实现它的：

我们先从黄瓜文件开始。每个用户故事都有自己的功能文件。 Feature 中的场景是故事的接受标准。我们最终会得到很多功能文件，因此我们使用命名约定和文件夹来组织它们。
我们在 Feature 文件的顶部使用用户故事的标签进行注释，例如 @Story-1234
我们编写了一个命令行实用程序，可以读取带有这些标签的黄瓜文件。然后它会获取测试计划中链接到故事的所有测试套件。在 ADO 中，一个故事只能链接到一个测试套件。如果该故事不存在测试套件，我们的工具会创建一个。
对于每个场景，该工具都会创建一个 ADO 测试用例，然后使用测试用例 ID 对场景进行注释。这为每个用户故事创造了惊人的可追溯性，因为相关的测试用例会自动链接到 Azure DevOps UI 中的故事
虽然我们不这样做，但我们可以使用黄瓜场景中的步骤定义填充 TestCase。它是描述要采取的步骤的基本 XML 结构。如果我们想使用 Azure DevOps 测试用例 UI 手动执行测试用例，这将非常有用。由于我们主要关注自动化，因此我们依赖功能文件中的步骤，并且我们的 ADO 测试用例最终成为返回黄瓜场景的符号链接。
因为我们的黄瓜测试是用C#（SpecFlow）编写的，所以我们可以获得黄瓜测试代码的完整类名和方法。我们的工具能够使用自动化详细信息更新 Azure DevOps 测试用例。
任何尚未准备好自动化或必须手动完成的测试用例，我们都会使用@ignore 或@manual 标签对场景进行注释。
使用 Azure DevOps Pipelines，我们使用 Visual Studio 测试任务来运行我们的测试。这里的重点是我们执行测试计划选项。此选项获取测试计划中具有自动化功能的测试用例，然后执行特定的黄瓜测试。开箱即用的功能可根据测试结果更新测试用例状态。
通过自动化运行后，我们使用 Azure DevOps 中的测试计划报告显示测试用例随时间的执行状态，并可以区分测试自动化和手动测试用例。
我们执行所有剩余的手动测试用例以完成测试计划

【讨论】：

【解决方案4】：

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

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

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

有关示例，请参阅 this article。

【讨论】：

这是一个很好的建议，但如果您必须在构建系统中运行您的测试套件（无需人工参与），它可能就没那么有用了。
感谢马特的回答。正如@hidro 提到的，我们在构建系统中运行测试。但是谢谢你的链接，我会看看黄瓜能做什么。
好吧，如果你需要一个完全自动化的测试套件，根据定义你不能有任何手动测试...如果你需要手动测试，你需要一个人来运行它们。 Cucumber 可以中途遇见你，仍然可以让你记录结果和生成报告等。

【解决方案5】：

对我们来说，我们经常发现不能自动化的手动案例是异常案例，或者是依赖外部环境的案例（例如数据格式错误、网络连接不可用、维护、首次引导...）。这些情况需要特殊设置来模拟发生时的环境。

理想情况下，我相信有可能涵盖所有内容，因为您已准备好尽可能多地实现它。但实际上，我们更喜欢混合手动-自动测试用例的混合方法通常需要付出太多的努力。但是，我们确实会尝试通过设置单独的环境来模拟异常情况并针对它们编写自动化测试，从而随着时间的推移将这些异常情况转换为自动情况。

尽管如此，即使如此努力，也会有无法模拟的情况，我认为工程师应该进行技术测试。

【讨论】：

感谢 hidro 的回答。您如何处理这些手动测试？ BDD 要求所有内容都在功能文件中。所以你在 Feature 文件中跟踪它们并将结果标记在哪里？
我们创建场景（有时只有一个虚拟步骤，有时是完整步骤），但将这些步骤标记为待处理，以便将来我们准备好时清除待处理的步骤.使用 // TODO 评论代码的方式相同
对于结果，这只是一个约定，我们记下需要手动测试的内容，并在主要部署之前进行检查。对于日常开发，我们会跳过它们（可能不是最佳做法）

【解决方案6】：

您可以使用类似于以下示例的方法： http://concordion.org/Example.html

当您使用构建或持续集成系统来跟踪您的测试运行时，您可以为包含文本比较（例如“通过”或“失败”）的手动案例添加简单的规范/测试。然后，您需要在每次手动测试运行后更新规范，将其签入，并在您的构建/持续集成系统中启动测试。然后手动结果将与自动测试执行的结果一起记录。

如果您使用 Concordion+ (https://code.google.com/p/concordion-plus/) 之类的工具，您甚至可以编写一个摘要规范，其中可能包含每个手动测试的场景。每一个都将在您的测试执行环境中报告为单独的测试结果。

干杯

【讨论】：

【解决方案7】：

截屏似乎是个好主意，您仍然可以自动进行验证，但需要加倍努力。例如，当使用 Selenium 时，您可以添加 Sikuli（注意：您不能运行无头测试）来比较结果（图像）或使用机器人截屏（java.awt）使用 OCR 读取文本并断言或验证（TestNG）

【讨论】：