在基于行为的测试中，看起来错误情景的数量呈指数增长。
根据AslakHellesøy，BDD was created将自动验收测试，功能要求和软件文档结合起来。
2003年，我成为XP社区中一小群人的一员，他们正在探索更好的TDD方法。 Dan North将此命名为BDD。我们的想法是将自动验收测试，功能需求和软件文档组合成一种非技术人员和测试工具可以理解的格式。
软件开发团队使用JBehave作为BDD测试工具（感谢Dan North）。
因为可能有很多可能的负面选择;看起来JBehave测试套件中的负面场景数量可能会增长很多。运行测试套件以及修改产品所花费的时间随着这种增长情况而增加。特别是，我觉得作为产品的文档很难维护。
由于不同团队的误解，我不确定这是否滥用BDD / JBehave概念;或者可能是应该的样子。
假设应用程序具有通过REST服务订购项目的行为。
PUT /order
{
// JSON body with 3 mandatory parameters and 2 optional parameters
}
我们可以提出许多负面情况。
同样，我们可以为这三个参数编写3 ^ 3个场景;它随着参数的数量呈指数增长。
然后我们可以将可选参数组合到方程式中并提出更多场景（比如使用null，empty和invalid-format值的可选参数）。
根据可用资金，会有情景。
根据交付的可能性，将有方案。
我想更多地了解所有这些负面情况（+更多）是否应该成为基于JBehave的测试套件的一部分？如果是这种情况，有关如何使其更易于维护的任何建议/想法？
它有助于了解被测试的应用程序在其自身的验证过程中内部执行的操作，特别是验证顺序。
在三个必需参数的简化示例中，您实际上只需要三个场景：每个参数一个。如果您知道如果参数1无效，应用程序将失败，则在另一个场景中测试参数2时无需再次检查，因为第二个参数在第一个参数失败时永远不会被验证，因此不是三次三，你只需要三个：
1）无效，有效，有效。 2）有效，无效，有效。 3）有效，有效，无效。
也就是说，除非，应用程序检查所有三个参数并相应地报告一个或多个参数无效。作为现在进行自动化的开发人员，我可以告诉你，除非我认为多个无效参数的概率很高，否则我只会一次检查一个参数，并在第一个无效参数时出错。有了会计软件的编写，有时候验证所有参数并相应地报告是合乎逻辑的，但这是例外而不是规则。如果您知道应用程序正在检查什么，以及以什么顺序，您可以编写更好的测试脚本，但我意识到这并不总是可行的。
仍然存在看似无限种类的无效数据的问题，因此即使在我的简化示例中，您仍然可以进行大量测试，但在这种情况下，可以使用无效值的参数进行处理。您仍然可以将其限制为仅三个方案，每个方案都有任意数量的无效参数进行测试。
我希望我能正确理解你的问题并提供一些有用的信息。