【问题标题】:Why to group related tests为什么要对相关测试进行分组
【发布时间】:2019-04-30 14:10:46
【问题描述】:

使用 TestNG 组或 JUnit 类别对测试进行分组的用例有哪些?

我通常使用 JUnit 类别按功能按测试分组:单元测试、集成测试等。但在我目前的团队,我们刚刚进行了一次对话,团队决定我们要一直运行所有测试,因为他们没有看到分组测试的任何好处。

所以我很想知道这里的人们是否将他们的测试分组以及为什么。

【问题讨论】:

    标签: java oop testing junit architecture


    【解决方案1】:

    有多种测试,JUnit 和 TestNG 都支持它们。 对于单元测试,您可以全部运行它们并在几秒钟或几分钟内获得反馈。 当涉及到集成或端到端测试时,由于时间因素,您可能希望对测试进行分组。

    假设您有单元测试、API 测试,甚至是 GUI 测试。

    虽然每个构建都可以运行单元测试,但其他测试可能需要很长时间。

    例子:

    在一个项目中,我进行了 300 多个 GUI 测试,并行运行它们需要 2 个小时。当我们为特定组件引入修补程序并且我们需要尽快部署它时 - 我们将只针对该组件运行回归测试。这时候分组可能会派上用场。

    另一个例子: 在我当前的项目中,我有数据驱动的 API 测试。要测试一个组件,我必须使用自动化测试执行 5000 个请求,并且最多需要 30 分钟。它仅适用于 1 个组件,我们目前大约有 14 个。想象一下,运行一个完整的测试套件。

    对于持续集成/持续开发来说,在每次构建时运行所有类型的完全回归测试的解决方案会很困难。

    另一种方法是仅运行冒烟测试,但您仍然必须对测试进行分组或创建特定的 Runner 类(就像 JUnit 运行器或 Cucumber 运行器一样)以仅运行部分测试。

    自动化测试的全部目的是在开发的版本不包含由于质量回归导致的错误时提供快速反馈。如果我们必须等待几个小时才能收到反馈。如果我们做不到,我们将不得不延迟每个版本/构建(取决于我们何时运行这些测试),这甚至可能与我们与客户商定的 SLA 发生冲突。

    更具体地说: 假设我们在支付系统中存在严重错误,并且根据 SLA,我们必须在 8 小时内修复此类严重错误。开发人员修复错误,创建应用程序构建以部署到测试环境,我们希望确保我们没有引入任何新错误。自动化测试的完全回归,包括单元测试、API 测试和 GUI 测试可能需要几个小时,但我们只有这几个小时来向我们的客户(生产环境)介绍更改。我们可以运行一组有关付款的测试,而不是运行整个测试套件。

    希望对你有帮助

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2010-10-23
      • 1970-01-01
      • 1970-01-01
      • 2011-11-19
      • 1970-01-01
      相关资源
      最近更新 更多