我们正在从经典的“瀑布”模型转变为更加面向敏捷的理念。我们决定尝试 BDD（Cucumber），但在迁移一些“旧”方法时遇到了一些问题。最大的问号是手动测试如何集成到循环中。
假设项目经理定义了功能和一些基本的场景大纲。我们与测试团队一起为此功能定义了大约 40 个场景。有些无法自动测试，这意味着它们必须手动测试。当您只有功能文件时执行手动测试，感觉不对。例如，我们希望能够查看过去的测试失败率。大多数测试用例管理器都支持这些特性，但它们不能使用特性文件。在外部测试用例管理器中维护手动测试用例，将导致功能文件和测试用例管理器之间永无止境的更新问题。
我很想知道是否有人能够覆盖这个“中间地带”以及如何覆盖。
这不是一个非常不寻常的案例。即使在敏捷中，也可能无法自动化每个场景。我正在与之合作的 Scrum 团队通常在功能文件中将它们标记为 @manual 场景。我们已将自动化套件（Cucumber - Ruby）配置为在运行夜间作业时忽略这些标签。正如您所提到的，这样做的一个问题是，当测试人员在本地记录结果时，我们不知道手动测试的结果是什么。
我对此的建议是以 YML 或任何其他适合目的的文件格式记录每次迭代的结果。该文件应该是自动化套件的一部分，并且应该在存储库中进行检查。因此，首先将结果与自动化套件一起记录下来。稍后，当您有资源和时间时，您可以在自动化套件中添加一项功能，以读取此文件并生成包含其他自动化结果或单独生成的报告。在此之前，您的版本控制应该可以帮助您跟踪所有以前的结果。
希望这可以帮助。
要添加到@Eswar 的答案，如果您使用的是 Cucumber（或其兄弟姐妹之一），一种选择是手动执行测试运行程序并包括提示测试人员检查某些方面。然后他们根据自己的判断通过/失败测试。
这通常对美学方面很有用，例如跨浏览器渲染、元素对齐、使用的正确图像等。
正如@Eswar 提到的，您可以通过标记这些测试从您的自动化运行中排除它们。
有关示例，请参见本文。
不能自动化的测试用例不适合黄瓜测试。我们有很多这样的边缘案例。让 Selenium 很好地验证 PDF 文档几乎是不可能的。CSV 下载也是如此（并非不可能，但不值得努力）。在这一点上，外观测试只需要人眼即可。使用屏幕阅读器进行可访问性测试最好也手动完成。
为此，请务必在用于跟踪工作项的任何工具中记录用户故事中的验收标准。编写手动测试用例。Azure DevOps、Jira、IBM Rational Team Concert 之类的公司有办法记录手动测试计划，将它们链接到故事，并记录执行手动测试的结果。
我会从黄瓜测试中删除手动测试用例，并依赖故事的验收标准，并将故事链接到某种手动测试用例，无论是在工具还是电子表格中。
有时你只需要妥协。
我们使用带有测试计划的 Azure DevOps + 一些自定义代码将黄瓜测试同步到 ADO。我可以描述我们是如何在我们的项目中实现它的：
您可以使用类似于以下示例的方法： http: //concordion.org/Example.html
当您使用构建或持续集成系统来跟踪您的测试运行时，您可以为包含文本比较（例如“通过”或“失败”）的手动案例添加简单的规范/测试。然后，您需要在每次手动测试运行后更新规范，将其签入，并在您的构建/持续集成系统中启动测试。然后手动结果将与自动测试执行的结果一起记录。
如果您使用 Concordion+ ( https://code.google.com/p/concordion-plus/ ) 之类的工具，您甚至可以编写一个摘要规范，其中可能包含每个手动测试的场景。每一个都将在您的测试执行环境中报告为单独的测试结果。
干杯
对我们来说，我们经常发现不能自动化的手动案例是异常案例，或者是依赖外部环境的案例（例如数据畸形、网络连接不通、维护、首次引导……）。这些情况需要特殊设置来模拟发生时的环境。
理想情况下，我相信有可能涵盖所有内容，因为您已准备好尽可能地实现它。但实际上，我们更喜欢混合手动-自动测试用例的混合方法通常需要付出太多的努力。但是，我们确实会尝试通过设置单独的环境来模拟异常情况并针对它们编写自动化测试，从而随着时间的推移将这些异常情况转换为自动情况。
尽管如此，即使有这样的努力，也会有无法模拟的情况，我相信工程师的技术测试应该涵盖这些情况。
截屏似乎是一个好主意，您仍然可以自动进行验证，但需要加倍努力。例如，当使用 Selenium 时，您可以添加 Sikuli（注意：您不能运行无头测试）来比较结果（图像）或使用机器人截屏（java.awt）使用 OCR 读取文本并断言或验证（TestNG）