问使用JBehave编写逻辑测试有意义吗？

EN

接受标准所需的明确程度取决于开发团队和业务涉众之间信任的级别。

在您的示例中，业务假设开发人员/测试人员对保龄球有足够的了解以确定正确的结果。

但想象一下一个更复杂的领域，比如金融。为此，最好有更明确的例子，以确保对需求有一个很好的理解。

或者，假设您有一个场景：

Given I try to sign up with an invalid email address
Then I should not be registered

为此，开发人员/测试人员可能比业务涉众更了解什么构成有效或无效的电子邮件地址。您仍然希望针对各种地址进行测试，但这可以在步骤定义中指定，而不是在场景级别公开。

他的测试是有效的，但需要一定的领域知识，这是任何框架都没有的。自动化测试应该是显式的，把它们当作例子。编写它们比编写“逻辑测试”花费更多，但从长远来看，这是值得的，因为它们可以很快地被随意地重放，并立即给出反馈。

你应该和他一起写第一批测试，让它朝着正确的方向发展。也许你可以给他你的测试，并要求他增加新的测试覆盖范围。

我讨厌“期望值”中的“适当”这样含糊的字眼。“适当”只是测试的“有毒词汇”的一个例子，如果不消除，这种“方法”就会变得广泛，从而有效地扼杀一般的测试。对于人类测试人员来说，这可能“足够了”，但这种“测试用例”只有在一开始尝试探索“冒烟测试”时才能被接受。

无论可重现性、系统性和自动化程度如何，每个测试用例都必须是特定的。(不仅仅是“应该”)。假设“会”的柔软性是可以允许的？相反，我用现在时态应该是“还是更严格的”是“，作为确认/拒绝的声明”)。一旦涉及到自动化，这个规则就是绝对的。

您的测试人员所做的，是一个“测试区域”，一个“场景模板”，而不是真正的测试用例:因为可以产生许多可能的测试结果.在您的场景中，您是非常具体的:这是一个非常具体的真正的“测试用例”。自动化您的测试用例是可能的，很好:您可以自动将它委托到机器上，并根据需要对其进行评估。(从连续集成服务器获得自动报告的额外奖励)

但是“空测试场景模板”呢？它也有一些价值:它是一个“场景模板”，是一个准备由数据填充的空骨架:所以我喜欢将这些情况命名为"DDT"：“数据驱动的测试”。

想象一下要测试的web表单，它的10个输入都有验证，有交叉验证.还有提交按钮。每个输入可以有10个测试用例：

• empty;
• with a char，但无论如何仍然太短；
• 对于服务器来说太长了，但允许在表单内复制粘贴和进一步编辑；
• 具有无效的字符.

我推荐的方法是准备一组传递数据:即使生成数据(从DB甚至随机生成)，您可以预测的任何内容都将通过测试，即“愉快的场景”。将数据保存在一边，作为数据模板，并使用它初始化表单，填充表单，然后停止某些单一的值:创建测试用例“失败”。对于每一个输入，每一个输入执行10次(100个测试-甚至在尝试跨规则之前).然后，在服务器拒绝表单100次后，通过传递数据填充表单，而不失真数据，从而最终可以接受表单。(接受服务器-app上的提交更改状态，因此需要作为最后一个状态来测试同一应用程序状态下的所有101种情况)

要以这种方式进行测试，您需要两件事：

• 空场景模板、
• 和一个由100行数据组成的表:输入数据的
  • 10列:仅操纵一个值，作为逐行传递表(例如，听说过灰色代码吗？)，
  • 可能会将继承历史记录保存在行描述中，从哪里派生以及如何操作值。

  H 129还有第11列，“预期结果”列填充:传递/失败预期状态，预期错误/验证消息，引用需求，进行测试-掩护追踪。(也就是说，在执行测试时，FitNesse?)

  • And可能也是实际检测结果的列，以跟踪单行测试用例的历史。(所以CI服务器提到了already)

​

要将一边的“空场景骨架”与另一边的“数据表驱动测试”结合起来，确实需要某种机制。你的数据需要被导入。因此，您可以在excel中准备行，理论上也可以导入这些行，但为了方便起见，我建议您使用CSV、属性、XML或任何机器可读的格式、文本格式。