组织验收测试(Specflow/Cucumber)
现在，我开始越来越多地使用BDD技术(规范流程和Cucumber)，我开始考虑我创建的项目/解决方案的组织，并确保我将来以某种方式验证它。
例如，Sprint 1启动，我们决定使用spec flow/c#编写验收测试。因此，我们构建了一系列功能文件，它们一起包含了Sprint 1中的所有用户故事，从那时起，它们就可以以自动化的方式运行。我要问的问题是：
1)当sprint 2开始时会发生什么？我们是否会继续在sprint 1中构建的解决方案中添加新的特性文件和代码，并创建新的子文件夹，以便将每个Sprint中的特性分离开来？或者有其他的方法来做这个…潜在地，我们可以在解决方案中为我们的系统的每一个区域有子文件夹，并以这种方式添加到自动化套件中？
( 2)在命名约定方面：( a)推荐的解决方案/项目命名约定是什么，因为随着时间的推移，解决方案/项目可能有大量的特性，每个特性都着眼于系统的不同领域？对于特性，这些功能的名称应该与用户故事标题或id相对应吗？( b)在6个月内，有什么好的方法可以参考这些验收测试？显然，业务用户不希望拖网浏览Visual项目，那么这些验收测试可以导出到html网页吗？
感谢人们的任何建议。
回答 1
Stack Exchange QA用户
发布于 2018-07-26 07:17:53
1)完成sprint 1之后，应该发布组件的新版本，因为所有sprint都应该交付新版本的产品。此外，如果您已经完成了顺序冲刺，那么您也应该已经完成了在您的sprint范围内感觉到的所有特性。因此，拥有新的sprint意味着拥有新的特性，从而具有新的特性文件。
( 2)这是主观的东西。这可能取决于产品的复杂程度和结构。关于如何组织特征结构，应该有一些单一的方法。也不只是用于BDD测试，而是用于手动测试和开发，用于代码repos等。这将使您可以轻松地从任何工具引用到任何其他工具(比如让Story in Jira很容易地将其映射到BDD框架中的测试)
关于将来的测试，有一种强大的测试标记机制，因此您可以只使用一个免费的文本来标记测试(例如，您可以用sprint号、特性或区域标记测试)，然后根据满足当前需求的标记对旧测试进行范围调整。
https://sqa.stackexchange.com/questions/34939
复制
腾讯云开发者
