Question

我正在使用BDD构建测试套件，并且我知道如果您的测试用例相互依赖是很不好的，但是在某些情况下，我看不到任何其他方式来做到这一点，例如：

说我有3种情况：一种正在注册网站，第二正在检查电子邮件以确认电子邮件并单击它，而第三种 >确保我可以使用该新创建的帐户登录。我将它们作为3种不同的方案，但是如果这3种方案没有按顺序运行，那么它将无法正常工作，这意味着它们彼此依赖。因为如果您不先注册，将没有验证电子邮件，并且如果您不先注册并进行验证，则无法登录。我当然可以将其变成一个大场景，但是我也听说过对多个断言进行长时间测试的不良做法。

那么在这种情况下某人应该怎么做？我看不出这些测试如何简短而独立？

我唯一想到的是制作一个“背景”部分，该部分实际上为每个场景创建一个随机的新帐户，但是如果我的测试套件中总共有数百个场景，我将看不到它会如何最好在每次并行运行测试时同时创建数百个帐户（我认为这是我们使测试简短而独立的重要原因）。

Answer 1

进行长时间的测试，直到它们花费更少的执行时间并对每个读取您的BDD方案的逻辑上有意义的人，都是不错的选择。

如果要使测试小而简单，可以进行有序测试，然后指定要按什么顺序执行测试。

但是，作为最佳实践，您的测试应该彼此独立。这意味着您应该能够随时以任何顺序运行任何测试。这样，更改一项测试不会影响其他测试。

Answer 2

每次测试都应像制导导弹一样，针对特定的应用领域。它不应与其他模块链接。

我遵循以下流程：

1. Generate test data (Backend - By running a SQL file) 
2. Perform test 
   - UI Test (Login > Navigate to the module > Test > Logout)
   - API test (Generate auth token > perform test > Delete token)
3. Remove test data (Backend - By running a SQL file)

如果没有其他方法，并且当前测试必须依赖先前的测试，那么我将使用dependsOnMethods标记（testNG）

@Test(dependsOnMethods = { "PreviousTest" })

Answer 3

我发现真正务实地对待这些东西有帮助，并有一些有关如何务实的准则。

跳过简单的事情。如果它没有变化，则不需要进行测试，尽管仍然需要进行测试。它需要记录在案，并且如果它发生更改，它可能会运行一些测试，但是如果它是众所周知的且非常稳定的解决方案，则将其放入库中并从构建中删除。或使用别人写的东西。存在许多开放源代码可以提供帮助。微服务也可以独立测试。

如果有疑问，请对其进行测试，但是... 如果它正在更改 lot ，请不要使其自动化，直到它变得更加稳定为止。这可能是需要最多经验的东西。知道何时开始进行测试。我之所以喜欢Gherkin，主要是因为它可以让我进行对话，然后写下场景，而实际上并没有自动开始。

关注价值。从您，您的客户或同事所关心或最担心的事情开始。您正在谈论创建帐户并登录网站。那不仅非常稳定，而且不会赚到任何钱。您有一个用户。他们已登录。他们在 for 中登录了什么？从这里开始，做所有可以简化上下文的操作，您可能会处在一个更好的位置。

价值在于新的东西。您为企业，员工，客户或其他系统提供的功能是他们以前所没有的。这就是为什么您在做自己在做的事情。找出它是什么，然后开始。

对于诸如设置帐户和登录之类的事情，可以将它们变成更长的时间smoke-test or customer journey；要么在一开始就运行以检查您的系统是否在不稳定的环境中就位，或者在这些环境发生变化时很少运行（也许是一整夜）。那不是BDD，但这是迈向可靠构建的务实一步，没关系。

BDD与测试无关。这是进行对话并以保持活动状态的方式捕获这些对话的重要内容的一种方式。尽量使方案中充满重要的部分。如果感觉平衡不正确，请更改它，看看是否有帮助。

如何使测试场景简短而独立？

3 个答案: