我们正在转向BDD。目前使用specflow和visual studio通过Jenkins运行我们的自动化测试，并在Quality Center中以更传统的方式编写了1000多个测试，回归测试将及时转换为BDD。 我正在寻找一个存储库（类似于Quality Center中的测试计划）来存放我们所有的测试用例/功能文件。它必须与Specflow和Jira兼容。人们将什么作为可管理的测试用例存储库用于测试？
干杯。
答案 0 :(得分：1)
我不是100％确定我理解你的问题，不熟悉你所谈论的一些工具，但是当你有可执行规范时，你的测试用例存在于存储在代码库中的特征文件中。这是一个重点，你的测试用例是执行的东西，所以它们总是最新的。
答案 1 :(得分：1)
@ Sam-Holder说的很好;除此之外，因为我熟悉这个问题以及你所谈论的工具。
您可能习惯于质量中心包含大量测试脚本，其中一些测试脚本通过，其中一些测试脚本尚未通过。
当您使用自动方案进行BDD时，它们几乎总是通过。现代敏捷流程不需要QC所做的一半事情。
一种非常常见的做法是将场景放入Jira故事，直到它们自动。他们是短暂的。一旦故事完成，没有人会看过Jira。代码库是真实的单一存储库，Jira中的任何东西都会被忽略。
将自动方案检入与代码相同的代码库中。如果场景变为红色（失败），团队会尽快使其成为绿色。它们为代码提供了生动的文档。看看你是否能找到一个人向你展示詹金斯在行动中的样子，你会得到一个更好的画面。通常，Jira编号会添加到签到注释中，以提供一定程度的可跟踪性。
我认为将任何手动测试用例与自动化测试用例一起检查是一种很好的做法（尽管请问他们为什么不自动化;如果您在QC中自动化它们，您通常可以使用SpecFlow）。这有助于测试用例（场景）为代码提供实时文档。事实上，摆脱＆＃34;测试＆＃34;是BDD出现的部分原因，因为BDD真的是通过对话进行分析和探索。它提供测试作为一个很好的副产品。
要回答这个问题，目前最常用的工具是Git（至少对于新手来说）。它是开发人员正在使用的版本控制。 SVN / Mercurial也是版本控制的好东西。让开发者帮助你。
如果你仍然在孤岛中工作而不与开发者交谈，不使用像SpecFlow 这样的BDD工具 - 你会发现他们更难跟上到目前为止，因为你的步骤可能过于详细，英语比重构更难以重构。
更好的是，使用BDD工具并与开发人员以及了解问题的BA / SME /产品负责人交谈。让他们帮助您编写方案。当您开始进行对话时，即使是遗留代码，您也会开始理解BDD的工作原理。
这是我在using BDD with legacy systems上撰写的一篇博文，可能对您有所帮助。这是关于the BDD lifecycle的博客文章：探索，规范和测试示例。这里有一个让你开始如何推导出这个＆＃34;给定，何时，然后＆＃34;语法使用real conversations。