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