规格示例：如何管理低级别详细信息

Question

我需要一个BDD/ATTD /规范专家的建议。 （对不起了很长的文章，我不知道如何表达的问题较少的话）

问题描述

我们一直都在一个中等规模的项目约1年。 该团队使用受验测试驱动的基于流程的过程（以详细测试用例的形式编写）。

而现在，随着需求的变化，我们开始遇到这些测试的可维护性问题。

1. 他们是（非常）硬盘读取一个绝对不作为产品 规格多日的要求结果
2. 稍有变化 重构的测试过于加上实施细则

我们怎么看它解决

为了解决我们要我们的测试转化成可执行的规范问题。 所有的书/文章我读过（例如，通过例如通过戈杰科·阿德齐奇规范）建议，我们不与低级别的详细信息，告诉相当如何产品应当执行的，而不是什么超载规格产品应该符合商业期望。

这似乎是合理的，因为规格可能会更具可读性和可维护性，并且反映了业务目标，而不是过分指定时的软件设计。 但是，这些低级别的细节不能被丢弃 - 虽然它们并未被业务用户明确地询问，但它们仍然是可预期的。例如，如果用户按下“处理按钮”，则最好禁用并且“取消按钮”被启用，直到处理完成。像这样的细节在规范中似乎是不必要的，但对于应用程序被客户接受是必需的。

我们在每个级别使用（A）TDD，并且仅用于编写代码以进行测试。现在不用详细的测试，我们会有更多的抽象可执行文件规范，而且根本不知道把低级细节放在哪里。

问题

因此，能不能有人建议管理水平低的要求是不能去了说明书的好的做法呢？

Answer 1

我想描述的步骤为When user presses 'Process button'绝对是告诉我们系统应该如何实现，而不是描述什么产品应为企业做的。我们从这一步中知道什么？只有我们在UI上的某处有按钮（不是链接，不是其他控件），其上有文字Process。没有关于商业。更糟糕的是，它非常脆弱。如果您将按钮的文本更改为Start，则此步骤将无效。如果您更改控制类型，则相同。

点击按钮不是商业目标。那么，如何描述业务目标呢？我认为When user starts processing bills是很好的步骤定义。如果您更改UI，则此行为将保持不变。它不再脆弱。只有步骤的实施才会改变。