如何学习/教授黄瓜小黄瓜
我希望业务分析师能够使用 Gherkin 编写 Cucumber 友好的所有功能、场景和步骤规范。
我已经在 Cucumber 的 github 网站上阅读了一些基本信息，并通过 Google 进行了快速搜索，但想知道是否有推荐的资源让非技术人员能够使用 Gherkin 编写全面的 BDD（我认为这是创建 Cucumber 测试的首选语言）。
谢谢。
I'd like to enable the business analysts to be able to write all of their specs for features, scenarios and steps that is Cucumber friendly using Gherkin.
I've read some of the basic info on the github site for Cucumber and from doing a quick Google search but wanted to know if there were recommended resources for getting non-technical folks to be able to write comprehensive BDD using Gherkin (I assume that's the preferred language for Cucumber tests to be created in).
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我对我们公司的业务分析师所做的就是通过给他们关键字来教他们结构：Given、When、Then、<对于场景，使用“strong>和”；对于功能，使用为了、作为和我想要。
然后我给他们举了一个简单的例子，并告诉他们按照他们认为应该写的方式写下自己的特征。令人惊讶的是，该结构是不言自明的，他们编写的功能成为了一个很好的开始。
唯一的大问题是它们在每个场景步骤中都包含了太多逻辑。我通过反复问“为什么？”来解决这个问题。在大多数情况下，这揭示了他们所追求的核心功能，我们相应地重写了场景。
通过给他们指导方针并让他们自己编写功能，他们自己动手并被迫思考他们所写的内容。今天，他们有了更好的理解和“为什么？”迭代不再那么常见了。
当然，您需要让业务分析师和开发人员紧密合作，并且分析师编写的功能只能作为一个开始。请记住，Cucumber 功能只是分析师和开发人员之间的通用语言。他们仍然需要经常坐在一起才能互相交谈:)
What I did with the business analysts in our company was to teach them the structure by giving them the keywords: Given, When, Then, And for Scenarios and In order to, As a and I want to for Features.
Then I gave them a simple example and told them to write down their own features as they thought they should be written. Surprisingly enough the structure was self explanatory and the features they wrote became a great start.
The only big problem was that they had contained to much logic in each scenario step. I solved that by iteratively asking "why?" which in most cases revealed the core functionality they were after and we re-wrote the scenarios accordantly.
By giving them the guidelines and letting them write the features themselves they got their hands dirty and were forced to think about what they wrote. Today they have a much better understanding and the "why?" iterations are not that common anymore.
Ofcourse you need to have the business analysts and the developers to work closely together and the features the analysts write should only act as a start. Remember that the Cucumber features are just a common language between the analysts and the developers. They still need to sit together often to be able to speak with each other :)
http://cukes.info 是教人们如何编写它们的绝佳资源。 Ben Mabey 还在 Mountain West 做了关于 Cucumber 的精彩演示 2009 年红宝石会议。
http://cukes.info is a great resource for teaching people how to write them. Ben Mabey also made a great presentation on Cucumber at Mountain West Ruby Conference 2009.
刚刚第一次使用 Cucumber 进行敏捷项目，我认为学习 Cucumber 和 Gherkin 的最好方法就是亲自动手。
我可能是错的，但我从你的问题中得到的印象是你想训练你的文学士写小黄瓜；然后他们会编写一堆功能并将其交给开发人员。
这绝对不是要走的路。最好让 BA 的开发人员和用户（如果可能的话）一起编写您的场景并随时构建它们。然后大家一起学习什么有效，什么无效。
我们尝试让 BA 编写完整的功能并交给他们。我们（开发人员）最终不得不进行重大重写，因为最终的实现与 BA 最初设想的不同。我们还必须更改步骤的语法，并在整个文件中进行查找和替换。
一次执行一个场景，让它发挥作用，然后继续下一个场景。迭代方法可以减少浪费的精力，并确保大家都了解您希望应用程序如何运行。
就如何编写步骤而言，最好从 Cucumber 附带的步骤开始，并在您处理项目时复制和调整它们以适合您的特定应用程序。没有对错之分，适合你的才是对的。 Cucumber 网站上的文档通常都很好，随着您了解更多，它们将成为宝贵的资源。
Having just worked on an agile project using cucumber for the first time I think that the best way to learn Cucumber and Gherkin is to get your hands dirty.
I may be wrong but I get the impression from your question you are wanting to train your BAs to write Gherkin; then they will write a bunch of features and hand them to developers.
This is definitely not the way to go. It is much better to have BA's devs and users (if possible) working together to write your scenarios and build them as you go. Then you all learn together what works and what doesn't.
We tried having a BA write entire features and hand them over. We (the devs) ended up having to do major rewrites because the implementation ended up different to that originally envisioned by the BA. We also had to change the syntax of the steps and do find and replace through the whole file.
Do one scenario at a time, get it working then move on to the next. An iterative approach reduces wasted effort and makes sure you all understand how you want the app to behave.
In terms of how to write steps it is best to start with the ones that come with Cucumber and copy and adapt them as you work on your project to fit your particular application. There is no right or wrong, it is what works for you. The documentation on the cucumber sites is generally good and will be a valuable resource as you learn more.
我们正在以类似的方式教授 Gherkin（用于 SpecFlow），就像 mrD 所描述的那样。
但我认为非常重要的是，观众要熟悉“示例规范”、敏捷需求分析和 BDD 的主要意图，因此我们通常首先开始讨论背景。我们还展示了一个示例 Gherkin 场景并解释了非常基础的知识（例如给定/何时/那么/但是和表格）。
然后我们采取一个简单的示例故事（每个人都非常熟悉），例如“将商品添加到购物车”（当然有一些方向），然后让他们在小组中制定接受标准。
之后，每个团队都会展示/解释他们的解决方案，我们会讨论现有的好的和坏的做法。在第二个团队之后，您可以看到几乎所有最重要（好的或坏的）实践的出现。
我还输入了得出的解决方案，并在此处展示了描述场景的替代方法（背景、场景大纲等）。如果有足够的时间，我还会展示如何自动化和自动化。在此基础上实现想象的功能。这也有助于理解一些需要遵循的重要规则，从而使自动化变得更加容易。
虽然我从来不知道会发生什么，但通常这个练习是我们 BDD 训练中最好的部分。
We are teaching Gherkin (for SpecFlow) in a similar way, how mrD has described it.
I think it is very important though, that the audience is familiar with the main intention of "Specification by Example", agile requirement analysis and BDD, so we usually start discussing the background first. We also show a sample Gherkin scenario and explain the very basics (like Given/When/Then/But and tables).
Than we take a simple example story (that is quite familiar to everyone), like "add items to shopping cart" (with some orientation, of course) and let them formulate the acceptance criteria in small groups.
After that every team shows / explains their solutions and we discuss the good and bad practices that were present. After the second team, you can see almost all of the most important (good or bad) practices appearing.
I also type in the concluded solution, and show here alternative ways of describing the scenarios (background, scenario outline, etc.). If there is enough time, I also show how to automate & implement the imagined functionality based on that. This also help to understand some important rules to follow, that makes the automation much easier.
Although, I never know upfront what will happen, usually this exercise is the best part of our BDD training.
RSpec 书中有几个与业务分析师相关的章节：
http://pragprog.com/book/achbd/the-rspec-book
The RSpec book has a couple of chapters in it that are relevant to Business Analysts:
http://pragprog.com/book/achbd/the-rspec-book
我认为最好的学习方法就是开始写作。小黄瓜Cucumber 很容易学习，但很难掌握，因此尽快了解实际示例非常重要。
虽然从编写第一个场景开始很重要，但您还需要一些资源来建立良好的习惯并了解关键实践。我写了一本可以提供帮助的书。我希望“编写出色的规范” ，学习小黄瓜和黄瓜的好方法。它涵盖了模式和反模式以及编写出色场景的关键技术。 :) 如果您有任何疑问，可以随时在 Twitter 上联系我。
如果您有兴趣购买“编写伟大的规范”，使用促销代码 39nicieja2 可以节省 39% :)
其他很棒的资源：
I think the best way to learn is to start writing. Gherkin & Cucumber are easy to learn but difficult to master, so it’s important to get to practical examples as soon as possible.
While it’s important to get started by writing your first scenarios, you also need some resources to establish good habits and understand key practices. I wrote a book that could help. “Writing Great Specifications” is, I hope, a good way to learn Gherkin and Cucumber. It covers patterns and antipatterns as well as key techniques for writing great scenarios. :) If you have any questions, you can always hit me up on Twitter.
If you are interested in buying “Writing Great Specifications,” you can save 39% with the promo code 39nicieja2 :)
Other great resources:
学习 Gherkin 的最佳方法是先阅读 Behat 文档：http://behat.readthedocs.org
然后阅读cucumber网站的官方文档：https://cucumber.io/docs/reference
此外，您还可以阅读 Guru99 文章来编写您的第一个 Cucumber 脚本：http: //www.guru99.com/your-first-cucumber-script.html
Best way to learn Gherkin is to read the Behat documents first: http://behat.readthedocs.org
Then read official documents from cucumber site: https://cucumber.io/docs/reference
Also, you can read Guru99 article to write your first cucumber script: http://www.guru99.com/your-first-cucumber-script.html