手动测试的BDD？

Question

我们正在从传统的“瀑布模型”转向更加敏捷的理念。我们决定尝试使用BDD（Cucumber），但在迁移某些“旧”方法时遇到了一些问题。最大的问题是如何将手动测试集成进周期中。

假设项目经理定义了功能和一些基本的场景概述。与测试团队一起，我们为此功能定义了约40个场景。其中一些无法自动化测试，这意味着它们必须进行手动测试。当你只有功能文件时执行手动测试感觉不对劲。例如，我们希望能够看到以往测试失败的比例。大多数测试用例管理器都支持这些功能，但它们无法与功能文件配合使用。将手动测试用例维护在外部测试用例管理器中，会导致功能文件和测试用例管理器之间永无止境的更新问题。

我很想听听是否有人能够解决这个“中间地带”的问题，并知道如何解决。

- Okiba

---

为什么不能自动化地测试它们？市面上有很多测试工具，也许你只是不知道有些工具可以做到你想要的功能。 - Matthew Daly

例如，我们没有足够的人力在一个周期内将它们全部自动化（这意味着现在自动化一些，下一个周期再自动化一些），或者我们发现一些测试非常依赖UI，需要一个人来正确验证它们。手动测试执行是否在完美的BDD环境中进行？还是只有调试失败的自动化测试？ - Okiba

那么基本上你正在转向自动化测试的过程中？对于那些需要人类判断的测试，考虑在流程的某些阶段拍摄屏幕截图如何？我知道你可以用Splinter做到这一点，如果其他浏览器自动化库也能做到这一点，我也不会感到惊讶。然后有人可以查看这些屏幕截图进行检查。或者也许Wraith可以满足你的需求。 - Matthew Daly

@MatthewDaly，截图是一个很好的选项，问题在于我们将会有一些“通过”的测试用例（因为截图成功了，而Cucumber也完成了预定的任务），但之后测试人员必须检查这些截图，也许会失败。这将再次导致两个阶段之间的手动更新步骤（手动测试人员需要以某种方式将Cucumber测试标记为失败，并在外部工具中跟踪）。 - Okiba

Answer 1

这并不是一个非常不寻常的情况。 即使在敏捷开发中，也可能无法自动化每个场景。 我们正在使用的Scrum团队通常会将它们标记为特性文件中的@manual场景。我们已经配置了自己的自动化套件（Cucumber - Ruby），以忽略这些标签在运行夜间作业时。其中一个问题是，正如您所提到的那样，我们不知道手动测试的结果是什么，因为测试人员在本地记录结果。

我的建议是，对于每个迭代的结果都要在YML或任何适合的文件格式中进行记录。这个文件应该是自动化套件的一部分，并且应该被检入存储库中。因此，您可以随着自动化套件的开始记录结果。稍后，当您有资源和时间时，您可以添加一个功能来阅读此文件并生成报告，无论是与其他自动化结果一起还是单独提交。 到那时，您的版本控制应该帮助您跟踪所有先前的结果。

希望这可以帮到您。

- Eswar

---

谢谢@Eswar。那基本上就是我们所追求的方法。我们这里使用一个测试用例管理器，所以我猜对我们来说更好的选择是将迭代结果保存在其中。 - Okiba

Answer 2

为了补充@Eswar的答案，如果你正在使用Cucumber（或其类似工具），一种选择是手动执行测试运行器并包含提示让测试人员检查某些方面。然后根据他们的判断来通过/未通过测试。

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

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

请参见这篇文章以获取示例。

- Matt

---

这是一个好建议，但如果你必须在构建系统中运行测试套件（没有人参与），它可能不太有用。 - hidro

谢谢你的回答Matt。正如@hidro所提到的，我们在构建系统中运行测试。但是感谢提供的链接，我会看一下cucumbumbler能做些什么。 - Okiba

如果你需要一个完全自动化的测试套件，按定义来说你不能有任何手动测试... 如果你需要手动测试，就需要一个人来运行它们。Cucumber可以满足一半需求，并仍然允许您记录结果并生成报告等。 - Matt

Answer 3

无法自动化的测试用例不适合使用cucumber进行测试。我们有很多这些边缘情况。让Selenium很难有效验证PDF文档。CSV下载也是一样（不是不可能，但不值得努力）。外观测试只需要人眼就可以了。屏幕阅读器的无障碍性测试也最好手动完成。

为此，请确保在用于跟踪工作项的任何工具中记录用户故事中的验收标准。编写手动测试用例。Azure DevOps、Jira、IBM Rational Team Concert等工具都有记录手动测试计划、将其链接到故事并记录执行手动测试结果的方法。

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

有时你只需要妥协。

- Greg Burghardt

Answer 4

我们使用Azure DevOps与测试计划以及一些自定义代码来将cucumber测试同步到ADO。我可以描述一下我们在项目中如何实现：

我们首先从黄瓜文件开始。每个用户故事都有自己的特性文件。特性中的场景是故事的验收标准。我们最终得到了很多特性文件，因此我们使用命名约定和文件夹来组织它们。

我们在特性文件的顶部用一个标签注释用户故事，例如@Story-1234。

我们编写了一个命令行实用程序，它读取带有这些标签的黄瓜文件。然后，它获取与故事相关联的所有测试套件的测试计划。在ADO中，一个故事只能链接到单个测试套件。如果该故事没有对应的测试套件，我们的工具会创建一个。

对于每个场景，该工具都会创建一个ADO测试用例，然后在场景中注释测试用例ID。这为每个用户故事创建了惊人的可追溯性，因为相关的测试用例会自动链接到Azure DevOps UI中的故事。

虽然我们没有这样做，但我们可以使用我们的黄瓜场景步骤填充TestCase。这是一种描述要执行的步骤的基本XML结构。如果我们想要使用Azure DevOps Test Case UI手动执行测试用例，这将非常有用。由于我们主要关注自动化，我们依赖于我们特性文件中的步骤，而我们的ADO测试用例最终成为回到黄瓜场景的符号链接。

因为我们的黄瓜测试是用C#（SpecFlow）编写的，所以我们可以获得黄瓜测试代码的完整类名和方法。我们的工具能够使用自动化详细信息更新Azure DevOps Test Case。

任何未准备好进行自动化或必须手动完成的测试用例，我们都会在场景中注释@ignore或@manual标签。

使用Azure DevOps Pipelines，我们使用Visual Studio Test任务运行我们的测试。这里的重点是我们执行Test Plan选项。此选项获取测试计划中具有自动化的测试用例，然后执行特定的黄瓜测试。开箱即用的功能会使用测试结果更新测试用例状态。

在执行自动化之后，我们使用Azure DevOps中的Test Plan Report，该报告显示了随时间推移的测试用例执行状态，并且可以区分自动化测试用例和手动测试用例。

我们执行任何剩余的手动测试用例以完成测试计划。

- bryanbcook

Answer 5

截屏似乎是一个不错的主意，您仍然可以自动化验证，但需要额外努力。例如，使用Selenium时，可以添加Sikuli（注：无法运行无头测试）来比较结果（图像），或使用Robot（java.awt）拍摄屏幕截图，使用OCR读取文本并进行断言或验证（TestNG）。

- Itumeleng Mothibi

Answer 6

对我们来说，通常发现无法自动化的手动用例是异常情况，或者依赖于外部环境的情况（例如畸形数据、网络连接不可用、维护、首次指南...）。这些情况需要特殊设置来模拟它们发生时的环境。

理想情况下，我相信可以覆盖所有情况，只要你准备尽可能地努力实现它。但在现实中，往往需要太多的努力，我们更喜欢混合手动-自动测试用例的方法。然而，我们会尝试将这些异常情况转换为自动化用例，通过设置单独的环境来模拟异常情况，并编写自动化测试来对其进行测试。

尽管如此，即使付出了这样的努力，仍然会有一些情况无法模拟，我认为这些情况应该由工程师进行技术测试。

- hidro

---

感谢hidro的回答。那些手动测试你是怎么处理的？BDD要求所有内容都在特性文件中。所以你会在特性文件中跟踪它们并标记结果在哪里？ - Okiba

我们创建场景（有时只是虚拟步骤，有时是完整步骤），但将步骤标记为待处理，以便在未来准备好时清除待处理项。这与用 // TODO 评论代码的方式相同。 - hidro

对于测试结果，这只是一种惯例，我们记录需要手动测试的内容，并在主要部署之前进行检查。对于日常开发，我们会跳过它们（可能不是最佳实践）。 - hidro

Answer 7

您可以使用类似以下示例的方法： http://concordion.org/Example.html 当您使用构建或持续集成系统来跟踪测试运行时，您可以添加包含文本比较（例如“通过”或“失败”）的简单规范/测试，以用作您的手动案例。然后，您需要在每次手动测试运行后更新规范，检查它并启动您的构建/持续集成系统中的测试。然后，手动结果将与自动化测试执行的结果一起记录。

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

干杯

- user3632158