1

我最近遇到了 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 测试？当这些测试不是由您编写，而您必须将它们映射到您的代码时，您是否有任何经验？

4

5 回答 5

2

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

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

于 2011-09-17T07:13:22.160 回答
1

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

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

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

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

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

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

于 2011-09-17T10:17:28.193 回答
1

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

无论是可重现的、系统的和自动化的，每个测试用例都必须是具体的。（不仅仅是“应该” .. 假设可以允许“将”的柔软度？相反，我使用现在时 “应该”或更严格的“是”作为确认/拒绝的声明。）这条规则在自动化方面是绝对的。

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

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

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

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

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

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

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

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

于 2017-07-10T16:04:59.910 回答
0

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

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

于 2012-06-16T08:01:23.940 回答
0

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

于 2017-09-01T07:56:26.907 回答