我们有手动测试人员，他们只是在 MTM 和 tfs sprint 中写下他们的测试用例。我们必须从那里进行测试，并以 Specflow（BDD 形式）自动化故事。
1) 手动测试人员不会在一个故事中编写所有测试用例。他们通常为相同的功能创建不同的故事。那么在自动化过程中，我们的特征文件应该是怎样的呢？
2）目前我可以说我们只是对方法进行单元测试，但我们将如何处理系统测试的高端场景。如何处理整个流程 说“当我将产品添加到购物车时”这实际上意味着客户已经在产品描述页面中，并且在选择数量后正在将产品添加到购物车。我们目前已经构建了“我在产品页面”和“我选择数量”和“我将产品添加到购物车”等场景
3）还有要运行的烟雾测试用例。那么我们如何选择或识别将与 Smoke 测试一起运行的测试用例。我们的 Smoke 功能文件将如何？如何重用其他方法？我们不会为 smoke 编写相同的测试用例，我们只想重用其他的 smoke 测试方法。
我对这件事完全陌生，所以如果我对我写的内容不清楚，请把它放在评论中，我会编辑它。
请帮助我管理我的测试用例、功能文件和场景。
您可以创建一个功能文件并将您的各种故事作为场景。如果一个故事可以分解为各种测试，那么每个故事都可以有一个功能文件。这取决于您的上下文以及您试图通过测试实现的抽象和细节级别。我通常会尝试拥有非常集中的功能文件，专注于测试一个概念。如果我最终在一个功能中包含太多场景，我会寻找可以移动到另一个功能文件的分组和可以组合成通用场景、步骤或数据驱动测试的重复。
“高端场景”将包括 UI 中上述场景的自动化。如果您想知道如何自动化场景，这取决于您的 UI。如果您有 Web UI，那么质量专家推荐的 Selenium Webdriver 是一个不错的选择。为了使您的测试保持可维护性，您应该研究Page Objects。
SpecFlow 支持的许多测试运行器提供了一种对测试进行分类的方法，并允许您按类别运行测试。要使用此功能，您可以将标签添加到您的功能或场景中以对您的测试进行分类。您可以将@Smoke 添加到影响冒烟测试的功能和场景中。然后在您的脚本中运行测试，您将使用命令行参数让您的测试运行器仅运行标记为 Smoke 的测试。
您的烟雾功能文件将类似于您的其他测试。如果您重用已在 SpecFlow 中编写的步骤，它将自动绑定并重用该步骤的方法。只要您的冒烟测试以与其他测试类似的方式编写，您就应该能够轻松地重用您的步骤方法。