遵循 BDD 时单元测试与端到端（集成本身）之间的关系

Question

我的问题也与谁在典型的 BDD 中做什么有关。我的理解，产品负责人提出用户故事（可能会或可能不会在 Gherkin 中），QA 编写端到端测试的场景（在功能文件中），Dev 编写他的代码（如何以及在哪里，他是否也遵循 BDD ？）。此时，如果开发人员编写自动化单元测试，QA 是否可以将其用于端到端，或者它们可以完全不同？我的问题是 Dev 和 QA 在遵循 BDD 的同时如何在编码方面利用彼此的工作。我不知道如何连接这些点。让我们以基于 JAVA 的应用程序为例，QA 已经使用 Cucumber 和 Selenium Webdriver 进行自动化测试。

Answer 1

如果您正在练习 BDD，那么您将首先创建规范（定义行为），然后才实现此行为（即编写生产代码）。在哪个级别定义行为不太相关，尽管在单元测试级别，大多数人会称之为“TDD”（尽管它不一定是测试驱动，因为“测试”是您要编写的代码的设计）。开发人员和 QA 将合作定义行为并实现测试和生产代码。理想情况下，我希望在不同级别进行不同的测试，最终（最高）级别是 E2E 测试。我也会确保不要重新测试所有内容在每个级别上，但只测试在那个级别上有意义的事情。例如：计算值的方法应该进行单元测试，该值如何在前端显示将在前端进行测试（仍然可以是单元测试），如何从后端获取值将是集成测试等。您可能有兴趣在此处阅读有关 BDD 的更多信息：https : //docs.cucumber.io/bdd/，在此处的任何相关博文中：https ://docs.cucumber.io/community/ blog-posts/或 The Cucumber Book / The Cucumber for Java Book。

Answer 2

我正在一个应用 BDD 的项目中工作。当 BA 创建工单并记下所有方案时，会将其分配给开发人员。同时，QA 还创建一个 QA 票证来与该 DEV 票证相关的工作。但是只有在 DEV 票证的代码正在审查或已经完成时，QA 才会开始编写自动化测试。这是因为该功能需要可用于测试。当 QA 开始编码时，应该完成该票的所有单元测试。因此，为了利用 DEV 和 QA 的工作，我们提出了一个解决方案。虽然它是在试点，但没有正式应用。QA 需要参与单元测试评审。这意味着她/他需要查看所有单元测试并在她/他认为需要添加或删除更多案例时发表评论。并且 QA 可以在单元测试中获得测试覆盖率，并根据该覆盖率决定编写自动化测试。在这里，QA 需要积极参与并决定在 e2e 中测试什么。如果您可以与开发人员面对面讨论以获得单元测试覆盖率会更容易，但我认为审查代码更客观。还有 f2f ，没有任何 DEV 愿意告诉 QA 他的工作。但是，此解决方案需要 QA 工程师的更多技能。不是任何 QA 都能阅读和理解 DEV 代码。

这是我们QA团队在当前项目中给出的想法，不知道有没有项目应用这个。这真是个好问题。我还想从其他也希望利用 QA 和 DEV 工作的人那里听到更多的意见/想法。

Answer 3

开发人员和 QA 人员之间的 BDD/TDD 对等编程如何产生 e2e 测试自动化。

这可能需要

1. E2e 服务和应用程序部署自动化（一次性 - 非常适合在任何工程师笔记本电脑上工作）

2. 用例设置

• 设置行为应用程序状态（更新数据存储/数据库中的数据/数据库模式，如果功能使用密钥开关，则配置文件）

• 决定行为输入和输出的明确定义

• 定义特征触发和验证规则

• 实现应用逻辑

• 使用已实现的逻辑验证验证规则

我可能听起来有很多想法要一次做，因此很多人会不鼓励实施 e2e，我想如果使用正确的工具集，这个过程可以非常容易实施。