在Karate中,我们如何与BA合作以实现业务场景的自动化

Question

在使用Karate时,我们能够对Web服务进行大部分验证,我们能够成功地将Karate与Selenium webdriver集成,并使用java类进行数据库断言.对于DB,我们将结果集作为列表返回,方法是将每一行转换为hashmap,Karate将其作为json数组.因此验证变得简单.我们在QA方面的大多数需求都是使用空手道实现的.

然而,今天我们介绍的时候,对于一个更大的社区,其中一个开发者提出了一个问题.他是JBehave,BDD,jsonpath,java,Web服务等方面的专家.我们也认为他的问题在我们的背景下非常相关.然而,空手道的方法是不同的,根据我们的知识它可能不起作用.

在我们的上下文中,我们需要让BA使用业务术语考虑他们的业务场景来编写BDD,然后QA/Dev可以将这些作为脚本转换.(我们通常使用黄瓜+硒/放心等方法).举例来说,如果我有一个特征文件和10分的情况在,人在业务方面将无法理解验证看到空手道的步骤的细节/或另一个词纯英文文本会更多一点不言自明他们.我们需要这种方法,因为我们试图从故事层面本身实施流程变更.

你能分享一下你的想法吗？

Answer 1

简短回答:空手道不适合BDD.

我在这里写了一篇详细的博客文章:是的,空手道不是真正的 BDD

请仔细阅读,并与将受益的人分享.是的,空手道窃取了Cucumber 的BDD 语法,但后来采取了不同的方向.

您可以通过Java API在幕后使用Karate作为Cucumber步骤定义.或者,如果你想使用REST保证,全力以赴的东西.

我的个人意见是,请不要.你会浪费时间做这件事:

• 确保"BA友好"Gherkin 真正 "简单英语"并处于正确的抽象层次(取决于你问的人).准备好就无论您的黄瓜方案是否包含"特定于实现"的细节进行无休止的 争论.
• 实际上让你的BA-s编写Gherkin或者至少与开发团队合作编写它们.顺便说一句,正是这种协作是您从BDD获得的最大价值 - 而不是规范的自动化作为可执行测试.所以如果你能真正做到这一点(从你的BA获得时间和Gherkin专业知识),那么恭喜!没有多少球队可以解决这个问题.
• 当然,小黄瓜只是冰山一角,你需要去写所有的步骤定义.你会看到空手道文件的这一部分概述了空手道和黄瓜之间的差异.
• 我有一个强烈的观点,即BDD对API测试的价值很小(也可能是负面).UI测试(面向人类)与API测试(面向机器)之间的巨大差异在于,您正在编写一个明确的"合同".此合约最好用技术术语(JSON/schema)表示,而不是BDD强迫您进行的故意抽象.API的最终用户或消费者通常是另一个程序员!是的,有必要将API视为一种产品 - 但BDD只是把事情做得太过分了.特别是在微服务方面,你很少会遇到一个比普通的"CRUD"更复杂的东西.
• 问自己这个问题 - 您是否期望您的BA-s在项目的需求定义阶段后继续阅读Gherkin？请记住,BDD应该在编写单行代码之前实践.如果Gherkin已经实现了建立协作,共享理解和示例的目的 - 只需将其转换为正常的自动化测试,不要回头!

编辑:看看这里的第二个例子,看看当你使用Cucumber测试什么应该是一个简单的单元或集成测试时会发生什么.

希望有帮助:)