【发布时间】：2016-03-15 13:33:55
【问题描述】：
我正在与其他团队成员一起开展 BDD Web 开发和测试项目。
最重要的是，我们在 gherkin 中编写特征文件并运行 cucumber 来生成阶跃函数。在底部，我们编写 Selenium 页面模型和动作库脚本。剩下的就是用 Selenium 脚本填写 step 函数，最后运行 cucumber 案例。
听起来很简单。
当我们编写功能文件时，问题就开始了。
问题 1：随着项目的进行，我们客户的要求每周都在变化，包括删除旧的和添加新的。
问题 2：除此之外，对于某些功能，详细步骤也在不断变化。
如果我们尝试每天根据更新的特征文件生成更新的阶跃函数，问题就会变得非常糟糕。为了使步骤函数和特征文件保持同步，需要做很多清理工作。
为了处理问题2，我记得编写小黄瓜特征文件的一个基本规则是尽可能使用业务领域语言。所以我试图说服 BA把 feature 文件写得模糊一点，不要在里面包含太多 UI 特定的步骤，这样我们就不需要经常修改 feature 文件/步骤功能。但她犹豫了，因为客户的需求文件包含详细信息，而她只是尝试遵循。
解决问题1，我没有办法。
所以我的问题是：
是否有编写功能文件的好方法，使其受客户需求更改的影响较小？能不能写得比较模糊，省略一些可能会改变的细节（这样至少可以稳定step函数原型），如果可以，能走多远？
何时是生成步骤定义和填写内容的好时机？从一开始，还是等到功能稳定一点？如果功能不断变化，我们应该多久做一次？有没有一种方便的方法来清理过时的步进函数？
感谢任何想法。
谢谢，
【问题讨论】：
-
你能举一个改变场景和步骤的需求的例子吗？由此，人们可能会有想法。我认为，总的来说，编写新步骤（而不是更改它们）是件好事。如果该步骤侧重于如何，而不是什么，那么您需要更频繁地进行更改。步骤应该是“当我提交订单时”而不是“当我点击提交按钮时”。前者提供了更多的改变空间。如果您使用的是 ruby 版本的黄瓜，您可以使用 yard-cucumber 自动记录您的步骤。查看是否正在使用步骤以及使用了多少次真的很酷。
-
由于您正在尝试制作此活文档并包含对客户很重要的详细信息，因此答案很简单。有一个场景详细说明和测试经常变化的“细节”，但很少进行功能测试，然后有另一个场景来测试功能。换句话说，BA 可以编写一个浅显且会更改的详细场景（可能测试编辑用户页面上表单字段的标签，但不提交表单），然后再编写另一个实际测试编辑用户功能的场景。现在你已经将变化与不变分开了。