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

Question

我最近遇到了 JBehave，我认为我们应该使用它。所以我请来了我们团队的测试人员，他也认为应该使用这个。

以此为出发点，我要求测试人员为测试应用程序（鲍勃叔叔的保龄球游戏卡塔）编写故事。归根结底，我们会尝试将他的测试与保龄球比赛进行对比。

我期待这样的测试：

Given a bowling game
When player rolls 5
And player rolls 4
Then total pins knocked down is 9

相反，测试人员带有“逻辑测试”，换句话说，他并没有那么具体。但是，用他的话来说，这是一个有效的测试。

Given a bowling game
When player does a regular throw
Then score should be calculated appropriately

我的问题是模棱两可，什么是“常规投掷”？什么是“适当”？如果其中一个步骤失败，这意味着什么？

但是，测试人员说，人类确实理解，并且我正在寻找“物理测试”的地方，而写起来更麻烦。

我可以用滚动两次 4 映射“常规”（仍然没有备用，也没有罢工），但感觉就像我又在做我不想做的翻译。

所以我想知道，你是如何处理这个问题的？您如何编写 JBehave 测试？当编写这些测试的不是您，而您必须将它们映射到您的代码时，您是否有任何经验？

Answer 1

他的测试是有效的，但需要一定的领域知识，这是任何框架都不具备的。自动化测试应该是明确的，将它们视为示例。编写它们比编写“逻辑测试”成本更高，但从长远来看，这是值得的，因为它们可以随意重放，非常快速，并立即提供反馈。

你应该和他一起编写第一个测试，把它放在正确的方向上。也许你可以给他你的测试，并要求他通过添加新的测试来增加覆盖率。

Answer 2

验收标准所需的明确程度取决于开发团队和业务利益相关者之间的信任度。

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

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

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

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

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

Answer 3

我讨厌“期望值”中的“适当地”这样的模糊词。 “适当地”只是测试的“毒词”的一个例子，如果不消除，这种“方法”会传播开来，有效地扼杀测试。对于人类测试人员来说可能“足够了”，但这种“测试用例”只有在第一次尝试探索性“冒烟测试”时才可接受。

无论是可再现的、系统的和自动化的，每个测试用例都必须是具体的。（不仅仅是“应该”..假设“将”的软性是可以允许的? 相反，我使用 现在时 “shall be” 甚至更好的 strict “is”，作为确认/拒绝的声明。）并且一旦涉及到自动化，这条规则是绝对的。

您的测试人员所做的是一个“测试区域”，一个“场景模板”，而不是一个真正的测试用例：因为可以产生这么多可能的测试结果...... 在您的场景中，您是具体的：那是一个非常具体的真实“测试用例”。可以自动化您的测试用例，很好：您可以将它委托给一台机器并根据需要自动评估它。 （来自持续集成服务器的自动报告）

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

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

• 空；
• 带有一个字符，但还是太短了；
• 对于服务器来说太长，但允许在表单中进行复制粘贴和进一步编辑；
• 带有无效字符...

我推荐的方法是准备一组通过数据：即使生成它们（从 DB 或什至随机），您可以预测的任何内容都将通过测试，即“快乐场景”。将数据放在一边，作为数据模板，并使用它来初始化表单，填充它，然后分解一些单个值：创建“失败”的测试用例。对每个单个输入执行 10 次，对于 10 个输入中的每个输入（甚至在尝试交叉规则之前 100 个测试用例）......然后，在服务器拒绝表单的 100 次之后，填写传递数据的形式，没有扭曲它们，因此最终可以接受形式。 （server-app接受了submit changes状态，所以需要作为最后一个，在同一个app-state上测试所有101个case）

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

• 空场景模板，
• 和一个100行数据的表：
  • 10 列输入数据：仅操作一个值，在表格中逐行传递（即听说过格雷码？），
  • 可能将继承历史记录保存在行描述中，行从哪里派生以及如何派生，通过哪个操作值。
  • 也是第 11 列，“预期结果”列填充：通过/失败预期状态、预期错误/验证消息、参考要求、测试覆盖率跟踪。 （即见过 FitNesse 吗？）
  • 还可能是实际检测结果的列，在执行测试时，用于跟踪单行测试用例的历史记录。 （所以前面提到的 CI 服务器）

要结合一侧的“空场景骨架”和另一侧的“驱动测试的数据表”，确实需要某种机制。并且您的数据需要导入。因此，您可以在 excel 中准备行，理论上也可以导入，但为了更轻松，我建议使用 CSV、属性、XML 或任何机器和人类可读格式、文本格式。

Answer 4

他的“逻辑测试”与测试计划或 TODO 列表中的短语“测试常规保龄球得分”具有相同的信息内容。但它要长得多，因此更糟。

只有在测试团队负责生成包含更多信息的测试时，才使用 jbehave 才有意义。否则，获取 TODO 列表并在 JUnit 中对其进行编码会更有效。

Answer 5

我喜欢“预期值”中的“适当地”之类的词。您需要使用 cucumber 或其他包装器作为通用文档。如果您使用它来覆盖和指定所有可能的场景，您可能会浪费大量时间滚动浏览数百个功能文件。