Cucumber 如何编写功能文件以及何时将其转换为步骤定义以适应不断变化的业务需求？

我正在与其他团队成员一起进行BDD web开发和测试项目

在上面，我们用小黄瓜编写特征文件，并运行cucumber生成step函数。在底部，我们编写Selenium页面模型和操作库脚本。剩下的就是用Selenium脚本填充step函数，最后运行cucumber用例

听起来很简单

当我们编写功能文件时，问题就开始了

问题1：随着项目的进行，我们客户的要求每周都在变化，包括删除旧的和添加新的

问题2：除此之外，对于某些功能，详细步骤也在不断变化

如果我们每天尝试根据更新的功能文件生成更新的step函数，问题就会变得非常严重。为了使step函数和功能文件保持同步，需要进行大量的内部清理

为了解决问题2，我记得编写小黄瓜特性文件的一个基本规则是尽可能多地使用业务领域语言。因此，我试图说服BA将功能文件写得更模糊一点，并且不要在其中包含太多特定于UI的步骤，这样我们就不需要经常修改功能文件/步骤函数。但她犹豫不决，因为客户的需求文件中包含了细节，她只是试图遵循

为了解决问题1，我没有解决办法

所以我的问题是：

有没有一种好的方法来编写特性文件，这样它就不会受到客户需求变化的影响？我们是否可以含糊其辞地忽略一些可能发生变化的细节（这样至少可以稳定阶跃函数原型），如果可以，我们能走多远

什么时候是生成步骤定义和填写内容的好时机？从一开始，还是等到功能稳定一点？如果功能不断变化，我们应该多久做一次？有没有一种方便的方法来清理过时的step功能

任何想法都很感激

---

谢谢，

如果您的客户有特定的用户界面需求，并且您与之签约提供自动化测试，那么您应该使用实际的测试自动化工具编写这些需求。如果你试图这样使用它，你只是简单的

但是，如果您只与客户签订了验证应用程序是否符合客户提供的业务规则的合同，那么Cucumber可能会帮助您

---

无论哪种情况，如果没有与客户进行真正的合作，最终都会失败。如果他们经常在transome上抛出新的业务规则或新的业务需求，而您的可见性有限或没有可见性，那么您就处于一种不双赢的局面。

您能举一个改变场景和步骤的需求示例吗？由此，人们可能会有想法。我认为，一般来说，写新的步骤（而不是改变它们）是好的。如果该步骤关注的是如何而不是什么，那么您需要更频繁地进行更改。步骤应该是“当我提交订单时”，而不是“当我单击提交按钮时”。前者提供了更大的改变空间。如果您使用的是ruby版本的cucumber，那么可以使用yard cucumber自动记录您的步骤。看看这些步骤是否被使用，以及使用了多少次，这真的很酷。因为您正试图制作这些活文档，并包含对客户很重要的细节，所以答案很简单。有一个场景详细说明和测试经常变化的“细节”，但很少进行功能测试，然后有另一个场景测试功能。换句话说，BA可以编写一个详细的场景，该场景很肤浅，可能会发生变化（可能测试编辑用户页面上表单字段的标签，但不提交表单），然后编写另一个实际测试编辑用户功能的场景。现在，您已将更改与未更改分开。