使用 TestNG 组或 JUnit 类别对测试进行分组的用例是什么？
我通常使用 JUnit 类别按功能对测试进行分组:单元测试、集成测试等。但在我目前的团队中，我们刚刚进行了一次对话，团队决定我们要一直运行所有测试，因为他们看不到分组测试有任何好处。
所以我很想知道这里的人是否将他们的测试分组以及为什么。
最佳答案
有多种测试，JUnit 和 TestNG 都支持它们。 在单元测试的情况下，您可以运行它们并在几秒钟或几分钟内获得反馈。 当涉及到集成或端到端测试时，由于时间因素，您可能希望对测试进行分组。
比方说，您有单元测试、API 测试，甚至 GUI 测试。
虽然每个构建都可以运行单元测试，但其他测试可能会花费太长时间。
例子:
在一个项目中，我有超过 300 个 GUI 测试，并行运行它们需要 2 个小时。当我们为特定组件引入修补程序并且我们需要尽可能快地部署它时 - 我们会仅为该组件运行回归测试。那时分组可能会派上用场。
另一个例子: 在我当前的项目中，我有数据驱动的 API 测试。为了测试一个组件，我必须通过自动化测试执行 5000 个请求，最多需要 30 分钟。它仅适用于 1 个组件，目前我们大约有 14 个组件。想象一下，运行一个完整的测试套件。
对于持续集成/持续开发而言，针对每次构建的完整回归运行各种测试的解决方案将很困难。
另一种方法是只运行冒烟测试，但您仍然必须对测试进行分组或创建特定的 Runner 类(就像 JUnit runner 或 Cucumber runner)以仅运行部分测试。
自动化测试的全部目的是在开发的版本不包含质量下降导致的错误时提供快速反馈。如果我们必须等待几个小时才能获得反馈。如果我们做不到，我们将不得不延迟每个版本/构建(取决于我们何时运行这些测试)，这甚至可能与我们与客户商定的 SLA 发生冲突。
更具体地说: 假设我们在支付系统中有一个严重错误，并且根据 SLA，我们必须在 8 小时内修复这样的严重错误。开发人员修复错误，创建应用程序构建以部署到测试环境，我们希望确保我们没有引入任何新错误。自动化测试的完全回归，包括单元测试、API 测试和 GUI 测试可能需要几个小时，但我们只有这几个小时来向我们的客户(生产环境)介绍更改。我们可以运行一组关于付款的测试，而不是运行整个测试套件。
希望对你有帮助
关于java - 为什么要对相关测试进行分组，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/55913196/