BDD手动测试？

Question

我们正在改变经典的瀑布式瀑布。模式转变为更加敏捷的哲学。我们决定尝试一下BDD（黄瓜），但是我们在移植一些旧的＆＃39;方法。最大的问号是手动测试如何整合到周期中。

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

我有兴趣听听是否有人能够覆盖这个中间地带＆＃39;以及如何。

Answer 1

要添加@Eswar的答案，如果您正在使用Cucumber（或其中一个兄弟姐妹），一个选项是手动执行测试运行器并包含测试人员的提示检查某些方面。然后他们根据他们的判断通过/不通过测试。

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

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

有关示例，请参阅this article。

Answer 2

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

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

希望这会有所帮助。

Answer 3

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

为此，请务必使用用于跟踪工作项的任何工具在用户故事中记录接受标准。编写一个手动测试用例。诸如Azure DevOps，Jira，IBM Rational Team Concert之类的公司及其同类可以记录手动测试计划，将其链接到故事并记录执行手动测试的结果。

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

有时候您只需要妥协。

Answer 4

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

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

Answer 5

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

理想情况下，我认为有可能涵盖所有内容，因为您已准备好尽可能地实现目标。但实际上，我们更倾向于采用混合手动自动测试用例的混合方法。但是，我们尝试通过设置单独的环境来模拟异常情况并针对它们编写自动化测试，将这些异常情况随时转换为自动异常情况。

尽管如此，即使有这样的努力，也会出现无法模拟的情况，我相信它们应该被工程师的技术测试所覆盖。

Answer 6

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

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

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

干杯

Answer 7

拍摄屏幕快照似乎是一个好主意，您仍然可以自动进行验证，但还需要加倍努力。例如，当使用Selenium时，您可以添加Sikuli（注意：您无法进行无头测试）以比较结果（图像），或使用Robot（java.awt）拍摄屏幕快照。使用OCR读取文本并断言或验证（TestNG）< / p>