我是Specflow和BDD的忠实粉丝。在各种项目中，它对我很有帮助。
我还没有解决的一个挑战是以某种方式组织我的特征文件和场景，这使得它易于导航和探索。想象一年后，其他人想要来参加并了解该系统。从哪儿开始？什么是最重要的，什么不重要？功能之间有什么关系？系统是否处理特定方案？作者是否考虑过这个问题？
任何人都可以分享一些专注于此的技巧，阅读或工具吗？
答案 0 :(得分：9)
这个问题确实是关于个人偏好的，但我的答案是如何让我的目录更容易理解。
通过我一直在研究的项目，我不得不考虑这样的问题。我知道后来，其他人会通过黄瓜目录查看更多或修复各种错误。
一般来说，我们采用了这种方法（我将以我们的CucumberJS结构为例）：
project
| features
| | elements
| | | pages
| | | | home.js
| | | | index.js // grab all of the things in the pages directory
| | | | search.js
| | | index.js // grab everything in elements directory and the index of pages
| | | urls.js
| | | test_customers.js
| | feature_files
| | | home
| | | | homepage_links.feature
| | | | homepage_accessibility.feature
| | | | homepage_check_welsh_translation.feature
| | | search
| | | | search.feature
| | | | search_security.feature
| | step_definitions
| | | common // Won't go into this, but we have a library of reusable steps and functions in here for different projects that we can just port over from git
| | | project
| | | | pages
| | | | | search
| | | | | | search_steps.js
| | | | | | search_security_steps.js
| | | | | home
| | | | | | home_steps.js
| | | | | | home_accessibility_steps.js
| | | | navigation_steps.js
| | | | login_steps.js
| | support
| | | env.js // Timeouts
| | | hooks.js // Setup/Teardown for scenarios
| | | world.js // Setting up the drivers
| reports
| | 2017
| | | 03
| | | | 05
| | | | | report.html
| | | | | report.js
| | | | 06
| | | | | report.html
| | | | | report.js
| | | | 07
| | | | | report.html
| | | | | report.js
| | report.json
| screenshots
| | failed
| | | 2017-03-05
| | | | search_security_xss_204057.png
| | | 2017-03-06
| | | | search_security_xss_100532.png
| | | | search_security_xss_101054.png
| | | | search_security_xss_101615.png
| | search_security
| | | 2017-03-06
| | | | search_security_xss_100528.png
| | | | search_security_xss_101050.png
| | | | search_security_xss_101611.png
| | | | search_security_xss_101841.png
| .gitignore
| README.md
说你是一个项目的新手，所以你想找出已编写的场景。 你知道它是功能集的一部分，所以你沿着那条路走下去，你正在寻找功能文件，所以你沿着那条路走下去。您对如何针对搜索功能测试安全性感兴趣，因此您可以访问该文件并找到该文件。
在我们的文件夹结构的其余部分，它是相同的理论。一切都正是你所期望的。
答案 1 :(得分：1)
这是一个大问题，我想我没有直接的答案，但是以下一些考虑因素帮助我们塑造了功能文件。其中很多取决于偏好和项目的特定需求。
功能文件与用户故事不同。
摘自this excellent article，来自Matt Wynne（《黄瓜书》的作者）：
当Aslak创建Cucumber时，他将文件从.story重命名为.feature。这不是偶然的事情，也不是无聊的怪事：这是因为有区别。
用户故事是一种计划工具。它们一直存在直到被实施，然后消失，被代码吸收。
黄瓜功能是一种交流工具。它们描述了系统今天的运行情况，因此，如果您需要检查系统的工作方式，则无需阅读代码或在实时系统上打孔。根据功能的计划和实施方式来组织您的功能会干扰此目的。
编写包含商务语言的声明式特征文件可能比理想的目录结构更容易发现场景
随着项目的增长（越来越多的人开始做出贡献），直接浏览到方案的位置变得越来越困难。接下来的最好的事情？搜索它。如果您的场景更具说明性，而次要命令则更容易。来自this article from SauceLabs：
测试应主要集中在需要完成的事情上，而不是如何完成的细节上。当非开发人员阅读它们时，它们应该基本上是可以理解的。
以更高的抽象水平编写的紧凑型方案的优点在于，您可以在功能文件开始变得拥挤之前将其中的更多内容放入功能文件中。对于系统测试，我们很幸运地将高级小黄瓜与页面对象模式配对，因为它为所有细节提供了一层。
如果场景和功能与UI使用相同的业务语言，则更容易找到它们
如果您在UI中有一个名为“删除”的操作，在测试中有一个“删除”的操作，在生产代码中有一个“存档”的操作，那么开发人员或业务人员可能很难找到与该操作相关的场景。如果测试始终遵循用户界面，则可能更容易搜索场景（假设使用BDD工具的普通团队成员比用户界面对源代码更为熟悉）。
答案 2 :(得分：0)
我的方法是按照用户类型来组织端点操作：应用程序/页面，因为从根本上来说，测试是检查每个宁静的API如何在何处/何时由谁调用。
就个人而言，我也喜欢Robot Cucumber。